De opkomst van Evolutionary Architectures

Wat is Evolutionary Architectures en hoe is het ontstaan? Om duurzame applicaties te kunnen schrijven moet de basis – de architectuur- wendbaar zijn. Zodat applicaties kunnen evolueren met hun omgeving en niet een rigide blok vormen. Evolutionary Architecture kan daarvoor zorgen en onze solution architect, Tim, kroop in zijn pen om het voor jullie uit de doeken te doen.

De Applicatie Architectuur

Om beter te kunnen vertellen over het concept “Evolutionary Architectures” start ik graag bij het begin: de applicatie-architectuur.
Als Solution Architect zou je denken dat ik in alle eenvoud in staat ben om neer te schrijven wat een applicatie-architectuur juist is. De realiteit leert echter dat “architectuur” een abstract concept is, een begrip waar niet altijd écht helemaal consensus over bestaat.
We kunnen met enige veiligheid stellen dat applicatie-architectuur bestaat uit de fundamentele structuren van een applicatie. De architect zorgt voor die fundamenten op basis van de verschillende vereisten en noden van de applicatie. Die fundamenten worden eerst in een ontwerp (of design) vastgelegd en gedocumenteerd. Daarna wordt de architectuur uitgewerkt en ontwikkeld.
Architectuur kan beschouwd worden als een “enabler”. Iets dat het mogelijk maakt om functionaliteiten correct en snel op te leveren, maar dat zélf niet persé doet. Het zorgt dan weer wél voor het naleven van bepaalde vereisten en is zonder enige twijfel een bepalende factor voor de snelheid en flexibiliteit die ontwikkelaars ervaren bij het opleveren van functionaliteiten. Hoe beter die fundamentele structuren, hoe sneller functionaliteiten kunnen worden opgeleverd. Dat laatste wordt in onderstaande grafiek mooi gevisualiseerd:

Het concept “architectuur” is hierbij hopelijk al duidelijker geschetst. Maar het blijft een moeilijk en abstract begrip. Volgende quote van Ralph Johnson brengt nog iets meer diepgang:

“Architecture is the decisions that you wish you could get right early in a project.”- Ralph Johnson

Architectuur wordt dus gepercipieerd als belangrijk! Iets dat je liefst juist hebt in het begin van het project en iets dat, zo lijkt het toch, moeilijk is om te veranderen.

Functionaliteiten en vereisten

Voor we verder gaan lijkt het een goed idee om even stil te staan bij wat ik versta onder functionaliteiten en vereisten.

Functionaliteiten of “functional requirements” zijn de verschillende dingen die een applicatie moet kunnen doen. Het kan gaan over berekeningen, gegevensmanipulaties, bedrijfsprocessen, gebruikersinteracties, etc. Meestal staan functionele vereisten direct in relatie met “business value”.
In het kort gaat het hier over wat een systeem moet kunnen doen.

Vereisten of “technical requirements” zijn de technische uitdagingen waarmee rekening moet worden gehouden om een project tot een goed einde te brengen. Dit kunnen aspecten als prestatie, betrouwbaarheid en beschikbaarheid zijn.
In het kort gaat het hier over hoe een systeem iets zou moeten doen.

Ontwikkelaars zullen bij het schrijven van code zich meer richten op het opleveren van functionaliteiten. De architect zal bij het ontwikkelen van de architectuur zich meer richten op het naleven van de vereisten.

Evolutie van architectuur

Lange tijd volgde de software-industrie het idee dat architectuur iets was dat moest worden ontwikkeld alvorens de eerste regel code geschreven kon worden. Het stond vast, het was de basis, het fundament. Je kan het huis pas bouwen nadat de kelder en de verschillende bouwblokken stevig op hun plek staan. Die fundamenten bleven doorgaans onveranderd doorheen de cyclus van een project.

Het vooraf ontwikkelen van een applicatie-architectuur was mede gebaseerd op het idee dat vereisten en functionaliteiten moesten worden vastgelegd voordat het project écht kon beginnen: de befaamde “Waterfall”-benadering. Eerst werden alle vereisten en functionaliteiten gecapteerd en vastgelegd, daarna werd de architectuur ontwikkeld, daarna volgde het echte schrijven van code en het uiteindelijke opleveren van functionaliteiten.

Met de opkomst van agile methodologieën kwam daar verandering in. Vaste en vooraf gedefinieerde vereisten maakten plaats voor regelmatige verandering en flexibiliteit. Verandering binnen het opleveren van een project werd helemaal omarmd.

Hierbij werd ook de noodzaak van architectuur in zijn geheel in vraag gesteld. Hoe kan je een architectuur ontwikkelen zonder dat al de vereisten in kaart zijn gebracht? Hoe kan een solide basis tegelijkertijd flexibel zijn?

Evolutionary Architecture

Verschillende nieuwe benaderingen rond architectuur werden uitgedacht en zijn volop in opkomst. “Agile Architecture”, “Continuous Architecture”, “Emergent Architecture” en “Evolutionary Architecture” zijn hier voorbeelden van. Bij al deze benaderingen gaat men ervan uit dat verandering zelf een constante is. Architectuur kan evolueren of bewegen in een bepaalde richting.
De focus ligt op het ontwerpen van een architectuur die iteratief mee verandert binnen die agile werking. We laten de architectuur mee “evolueren” met het ontwikkelwerk. We spreken van evolutionaire architecturen (Evolutionary Architectures).

In schril contrast met de “oude” manier van werken staat de architect ook steeds dichter bij het ontwikkelteam. Samen met hen probeert hij/zij te zorgen dat de architectuur net als de code kan reageren op veranderende vereisten én de noden van de ontwikkelaars zelf.

Binnen ontwikkeling zelf bestaat een gelijkaardig concept, namelijk Evolutionary Software. Dit zou je kunnen omschrijven als een code-base die constant in verandering is. Code die evolueert met het team en de veranderende functionaliteiten. Maar die toch zorgt voor snelle oplevering, zonder belangrijke dingen te breken en kwaliteit te blijven garanderen. Processen en technieken als Test-driven development, Domain-driven design en Behavior-driven development werden geïncorporeerd om die kwaliteit te garanderen. We streven naar continue verandering zonder al te hoge risico’s.

Met Evolutionary Architecture bedoelen we iets gelijkaardigs, maar de verandering is gericht op die “fundamenten”. Een evolutionaire architectuur ondersteunt incrementele verandering als belangrijkste principe. Verschillende dimensies en domeinen worden met de hulp van verschillende tools gequoteerd en als “fit” beschouwd. “Fitness functions” worden gebruikt om de architecturale gezondheid te evalueren en om het naleven van de vereisten continu te blijven garanderen.

Naast de opkomst van agile methodologieën worden er ook nog eens steeds complexere applicaties gebouwd. Het technologielandschap is constant in beweging en de vroegere “design first, build later” mind-set is gewoon praktisch niet meer haalbaar.

Slot

Ik ben ervan overtuigd dat een kwalitatieve applicatie-architectuur van vitaal belang is en blijft voor het succesvol opleveren van een project. Een architectuur moet gracieus kunnen omgaan met verandering zodat de applicatie kan inspelen op dat complexe landschap en dat de agile mind-set gevolgd kan worden.
Applicaties moeten kunnen evolueren met hun omgeving. Ze mogen niet als een vaste en onbeweeglijke rots blijven staan.

Darwin said it best:

“It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change.” -Charles Darwin