Evolutionaire Architectuur: ondersteuning van constante verandering

Wat drijft verandering? 

Alles verandert uiteindelijk. Zoals Einstein zei: het is de enige constante. Sommige dingen veranderen doordat de organisatie zelf het initiatief neemt, andere dingen zullen onvrijwillig veranderen. Er zijn twee soorten veranderingen waar uw organisatie mee te maken heeft: 

• Bedrijfsgedreven verandering: dit omvat nieuwe verdienmodellen, disruptieve concurrenten, nieuwe kanalen, veranderende klantbehoeften, marktregulering en productinnovatie. Deze veranderen de zakelijke vereisten en gebruiksscenario's die u met uw architectuur aanpakt. 

• Verandering van het ecosysteem: het technische domein verschuift en evolueert naarmate programmeertalen, bibliotheken, framework-tools en besturingsomgevingen veranderen. Een dokwerker hielp bijvoorbeeld om containertechnologie naar de massa te brengen. Als gevolg hiervan heeft dit een revolutie teweeggebracht in de manier waarop we computer resources gebruiken. 

Verandering kan een zeer sterke impact hebben vanwege het zogenaamde Dynamic Equilibrium. Een term die doorgaans wordt gebruikt in de scheikunde en andere natuurwetenschappen, gaat ook op in software- architectuur. Dynamisch evenwicht betekent dat wanneer je een fijn uitgebalanceerde toestand verandert, je continue aanpassingen nodig hebt om een stabiele toestand te behouden. Net als Yin en Yang is het software-universum dynamisch in plaats van statisch. In een constante staat van verandering, zal uw software architectuur op elk gegeven moment dus verschillen. Dus hoe ga je om met verandering? 

Omgaan met de onbekende onbekenden 

Architectuur is iets wat je het minst wil veranderen, omdat het het moeilijkste en duurste is om te veranderen. Dat is de reden waarom veranderingen in het ecosysteem echte problemen kunnen veroorzaken voor software- architectuur, voor ondernemingen. Hoe meer dingen veranderen, hoe minder het mogelijk wordt om aan langetermijnplanning te doen. De voorspelbaarheid gaat verloren. Hoe kun je een vijfjarenplan voor je architectuur hebben als het gemakkelijk omvergeworpen kan worden door een ondoorgrondelijke innovatie? Of als je te vroeg nieuwe technologieën adopteert, je misschien wel op het verkeerde paard aan het wedden bent. Je kunt bijvoorbeeld niet voorspellen wat de volgende meest populaire taal zal zijn. Maar wanneer de verschuiving plaatsvindt, moet je nog steeds het hele ecosysteem dat volgt plannen. 

De enige oplossing is om op een kostenefficiënte manier een architectuur te bouwen die anticipeert op verandering en evolutie. Rebecca Parsons, Patrick Kua en Neal Ford van Thoughtworks noemen dit idee de evolutionaire architectuur. Met deze architectuur kunt u zich snel aanpassen aan veranderingen zonder dat u de toekomst hoeft te voorspellen om onzekere investeringen te doen. Voorspelbaarheid maakt plaats voor evolueerbaarheid.

Evolutionaire architectuur versus eerdere architectuur 

Het leidende principe van een evolutionaire architectuur is het ondersteunen van geleide, incrementele, niet-doorbrekende verandering langs meerdere dimensies. Om de implicaties te begrijpen, doen we een stap terug en bekijken we de eerdere architecturen. De eerste is natuurlijk de “big ball of mud”, een softwaresysteem dat geen waarneembare architectuur heeft. Het is compact en herkenbaar aan de hoge koppeling van zijn bouwstenen. Eén wijziging vereist veel aanpassingen die de hele applicatie in gevaar kunnen brengen: het is breekbaar. 

De tweede architectuur om mee te vergelijken is de gelaagde architectuur die de functies presentatie, applicatieverwerking, bedrijfslogica en gegevensbeheer scheidt. Het biedt eendimensionale evolueerbaarheid. De architectuur werkt nog steeds wanneer je de dimensie van de lagen afzonderlijk benadert. Maar in de praktijk sijpelen veranderingen in interfaces op een lager niveau door naar hogere niveaus. En wanneer u nieuwe functies op één laag introduceert, kan dit wijzigingen op elke andere laag forceren. Als u bovendien het principe van Domain-Driven Design (DDD) in overweging neemt, waarbij de zakelijke domeinen van de gebruikers centraal staan, zult u merken dat één domein waarschijnlijk verspreid is over meerdere lagen. Eén verandering in het zakelijke domein zal alle lagen beïnvloeden: het is niet evolueerbaar. 

Overweeg nu een evolutionaire architectuur zoals microservices. Er is een begrensde context die operationeel onderscheiden is. Services zijn ontkoppeld en domeingericht, wat betekent dat het wijzigen van een bestaande service geen gevolgen heeft voor andere services. Het is alsof je Lego verwisselt. 

De principes van de evolutionaire architectuur 

Het belangrijkste idee is dat architecturale elementen later veranderbaar zijn. Wanneer je evolutionaire verandering inbouwt in je architectuur, worden veranderingen goedkoper en gemakkelijker. Er zijn verschillende concepten rond de evolutionaire architectuur: 

• API: Door API's te gebruiken als framework voor interactie met de applicaties, kunnen de gegevens en functionaliteit gemakkelijk worden benaderd door andere applicaties. 
• Cloud: Vooral wanneer u uw microservices naar de Cloud brengt, kan uw architectuur optimaal profiteren van typische Cloud voordelen zoals schaalbaarheid, veerkracht en hoge beschikbaarheid. 
• Headless commerce: Wanneer je microservices toepast voor e-commerce, kun je het CMS loskoppelen van de presentatie laag, in een zogenaamde headless commerce 
• Event-driven architecture (EDA): Deze aanpak richt zich op business events waar de organisatie gewoon op moet inspelen. Een gebeurtenis gestuurde architectuur bedient zijn klanten realtime en maakt het mogelijk om de bedrijfslogica als globale logica te definiëren. 

Hoewel al deze ontwikkelingen en benaderingen de zakelijke wendbaarheid zullen geven die organisaties vandaag zoeken, biedt het concept van de evolutionaire architectuur het overkoepelende principe. Het draait allemaal om aanpassingsvermogen aan verandering. De volgende vijf kenmerken zijn leidend bij het ontwerpen van een evolutionaire architectuur: 

1. Fitheid functies: Deze specificeert hoe de doel-architectuur eruitziet en zal als zodanig sterk verschillen per organisatie. Sommige systemen vereisen zware beveiliging, andere hoge beschikbaarheid of bepaalde uptimeniveaus. Het vooraf nadenken over fitheid functies leidt tot besluitvorming en timing, en helpt u om de belangrijkste vereisten te behouden naarmate het systeem zich ontwikkelt. 

2. Laatste verantwoordelijke moment: Traditioneel neemt u architecturale beslissingen voordat u een code schrijft. In een evolutionaire architectuur wacht je op het laatste verantwoordelijke moment om beslissingen te nemen. Waarom? Nou, omdat er waarschijnlijk meer gedetailleerde informatie beschikbaar is om rekening mee te houden. De uitdaging is echter om te bepalen welke beslissingen je kunt uitstellen. Fitnessfuncties zouden hier leidend moeten zijn. 

3. Breng de pijn naar voren: Sommige dingen zijn moeilijk om te doen en kunnen pijn veroorzaken. Wanneer u dit eerder en vaker doet, identificeert u sneller de problemen die dit veroorzaken. Naarmate je beter wordt in het oplossen van deze problemen, word je aangemoedigd om de pijn weg te automatiseren. 

4. Continue opleveringen: Dit stelt u in staat om de bredere praktijk van de evolutionaire architectuur te ondersteunen, aangezien het twee nieuwe architecturale attributen introduceert: testbaarheid en inzetbaarheid. In een testbare architectuur kun je de meeste defecten ontdekken met geautomatiseerd testen. In een implementeerbare architectuur kunt u een bepaalde service implementeren zonder noemenswaardige orkestratie of downtime. Het maakt ook experimenten en A/B-testen mogelijk. 

5. Georganiseerd rond zakelijke mogelijkheden: Met Domain-Driven Design wordt modulariteit gecreëerd op domeinniveau in plaats van langs technische lagen. Dat vereist het opzetten van cross-functionele teams per bedrijfsdomein en verschuift de focus van eenmalige projecten naar lopende projecten. Je bouwt het, je voert het uit. Als gevolg hiervan wordt het maken van niet-doorbrekende wijzigingen langs goed gedefinieerde grenzen vereenvoudigd. 

Tijd is alles 

De evolutionaire architectuur verbetert de cyclustijd om een enkele wijziging herhaaldelijk en betrouwbaar in productie te krijgen. Het doet dit door langzame feedback cycli, koppeling en samenhang weg te nemen: de belangrijkste obstakels voor aanpassing aan verandering. Elk onderdeel van de architectuur kan met de tijd evolueren, onafhankelijk van zijn omgeving. De drastische verkorting van de time-to-market en het nieuwe aanpassingsvermogen zullen uw organisatie echte wendbaarheid en zakelijke wendbaarheid brengen. Dat stelt u in staat om efficiënt in te spelen op veranderingen, nieuwe features op het juiste moment te introduceren en uw concurrentie te verslaan. Want met een evolutionaire constructie kun je je eigen tempo bepalen. 

Dit is het eerste artikel in onze serie artikelen over evolutionaire architectuur. Op deze pagina kun je uitgebreid leren over de onderliggende principes zoals microservices, API, Cloud-commerce, headless-commerce en event-driven.