Agile Architectuur. Maar hoe?

Juli 2010 - In dit Whitebook beschrijven we de mogelijkheid om architectuur ‘Agile’ aan te pakken. Enterprise Architecture wordt vaak verward met het beschrijven van de ideale situatie, maar hoe die te bereiken? Initiatieven om architectuur binnen een organisatie te laten landen stranden met regelmaat omdat er getracht wordt deze met een ‘Big Bang’ te implementeren. Zoiets omvangrijks kan echter niet in één keer landen binnen een organisatie. Dus hoe maken we dit klein?

 
De immense, maar indrukwekkende architectuur van het Gemeentehuis van Den Haag.

Binnen grote projecten is het opstellen van een gedegen architectuur vaak één van de eerste stappen die ondernomen worden. Onder de noemer ‘Project Start Architectuur’ documenteert de betrokken architect uitgebreid de onderliggende infrastructuur, applicaties en informatievoorziening. Dit vergt veel tijd en dus geld, maar is lang niet altijd nodig. Het kan effectiever. Het is mogelijk om op een andere manier naar Enterprise Architecture binnen projecten te kijken, maar alleen als we het juist aanpakken.

Agile softwareprojecten kenmerken zich door in te spelen op verandering en het beoordelen op het daadwerkelijk toevoegen van waarde. Architectuur voegt zelf zelden direct waarde toe, hierdoor zal het niet een direct meetbaar eindproduct van een project zijn. Wanneer Lean principes worden losgelaten op de vaste architectuur elementen, begrijpen we al snel dat dit niet strookt.

Architectuur binnen projecten heeft echter wel degelijk toegevoegde waarde. Deze is te vinden in het aanreiken van keuzes en om deze te vergemakkelijken. Het is dus zaak om een goede balans te vinden tussen ‘zomaar wat doen’ en ‘overmatig bedenken en documenteren’.

Business Case

Met behulp van de Business Case is vast te leggen waar de architectuur aan dient te voldoen. Ten eerste de hamvraag: is het project verantwoordelijk voor het opstellen van de enterprise architectuur of niet? Dit is onwaarschijnlijk. Het project is echter wél verantwoordelijk voor het gedeelte van de architectuur welke geraakt wordt door de oplossing die ontwikkeld wordt.

Binnen de Business Case is, als het goed is, vastgelegd wat de kosten en baten van het project zijn. De architectuur dient deze te ondersteunen. De totale kosten van een oplossing (TCO) zijn samen met het rendement (ROI) van het project van belang om de begrenzingen van de architectuur te bepalen. Op het moment dat de Business Case duidelijk is, kan dit gebruikt worden als leidraad voor de architectuur.

Wat beschrijft de Architectuur?

Enterprise Architecture

Als we spreken over architectuur binnen ICT wordt vaak gedacht aan infrastructuur en applicatiemodellen. Dit is slechts een beperkte blik binnen Enterprise Architecture. Naast de technologische benadering van architectuur zijn namelijk de business- en informatie-architectuur minstens zo belangrijk.

De logische opbouw van Enterprise Architecture

Alle Enterprise Architecture raamwerken zijn gebaseerd op dezelfde principes; namelijk dat zowel bedrijfsprocessen, informatiebehoefte, applicatieopbouw en techniek met elkaar in verbinding staan. Deze opbouw is uniform. Businessarchitectuur drijft de opbouw van de informatiearchitectuur. Deze bepaalt weer de applicatiearchitectuur, welke ondersteund wordt door de technische opbouw en infrastructuur.

Maak het Agile

De meeste Enterprise Architecture raamwerken, zoals TOGAF en Zachman, staan bekend als groot en log. Dit is niet altijd waar, maar traditioneel gezien worden deze raamwerken nogal zwaar ingezet. Het is ook mogelijk om te kijken naar architectuur vanuit een ‘agile’ benadering.

Het Agile Manifesto stelt, onder andere, dat individuen en interactie belangrijker zijn dan processen en gereedschappen. Dat werkende software belangrijker is dan uitgebreide documentatie. Deze principes zijn goed te vertalen naar het opstellen van een project start architectuur.

Op deze manier is het mogelijk om architectuur te beoordelen op de mate waarin zij verandering en waarde ondersteunen. Hiermee kan ook gewerkt worden in fases, cycli en iteraties zoals wij die kennen in agile softwareontwikkeling. Agile Enterprise Architecture zegt dan ook dat slechts de gedeelten van de architectuur ontworpen dienen te worden die nodig zijn voor de oplossing die gecreëerd gaat worden. Niet in fases zoals deze erkend worden in de klassieke benadering van architectuur, maar in werkbare pakketten.

De basisvragen

 
De Basisvragen die aan het begin van ieder project gesteld moeten worden. Deze leggen de basis van de architectuur.

Binnen alle elementen van Enterprise Architecture dienen een aantal basis vragen beantwoord te zijn. Dit is een relatief simpel proces waar alle betrokkenen aan mee kunnen werken. Dit betreft de vragen:

• Wie zijn de verschillende actoren in het proces? (Wie gaat de oplossing realiseren en wie is de klant?)
• Wat beslaat het systeem wat ontwikkeld gaat worden? (Welke data en processen worden geraakt?)
• Waarom wordt dit project uitgevoerd? (Wat is het doel van het project?)
• Wanneer wordt het proces gebruikt? (Wanneer moet de oplossing aangeboden worden aan de organisatie? Wanneer zal de gebruiker actief zijn?)
• Waar wordt de oplossing gebruikt? (Binnen welk gebied van de organisatie? Welke elementen van de organisatie zijn betrokken bij de oplossing en welke systemen worden geraakt? Op welke lokatie? Waar in het proces? Waar in de gehele informatiestructuur?)
• Hoeveel is er nodig? (Geld, gebruikers, data, …)
• Hoe wordt de oplossing gerealiseerd? (Met welke techniek? Welke kennis? Wat is er al?)

Als deze vragen beantwoord zijn hebben we de basis waarop de architectuur gebouwd kan worden. Dit is de beredenering van de gewenste functionaliteit. Nu zijn we er nog niet, maar de essentie staat.

Hoe ontwikkelen we een Architectuur?

Net zoals het ontwikkelen van software, is tijdens een Agile project ook het opstellen van de basis voor architectuur een aangelegenheid voor een team. Het is een groepsproces. Gedurende één of meerdere sessies worden de verschillende actoren en stakeholders door alle lagen van de architectuur geholpen.

Allereerst wordt een globale blauwdruk neergelegd waar de basis in staat voor de verdere ontwikkeling van de architectuur. Zowel personen vanuit de Business, en IT dienen bij deze blauwdruk betrokken te zijn. Het ontwikkelen van de blauwdruk is tweerichtingsverkeer. Dit houdt in dat het de eisen en wensen van alle lagen van de architectuur benadrukt.

Architectuur is tweerichtingsverkeer.

Doordat we handelen volgens de agile principes geldt ook hier dat de architectuur aan verandering onderhevig is. Nieuwe inzichten kunnen worden opgepakt en snel verwerkt worden binnen de blauwdruk.

In korte tijd kunnen de principes voor Business-, Data-, Applicatie- en Technische architectuur worden ontwikkeld. Het is hiervoor zaak dat de betrokken actoren ook daadwerkelijk onderdeel van het projectteam zijn en op alle lagen van de architectuur betrekking hebben.

De grenzen van de Architectuur

Elk systeem kent haar begrenzingen. Zo ook de architectuur van een organisatie. Aangezien het meestal voor zal komen dat een architectuur wordt opgesteld binnen een organisatie die reeds in bedrijf is, kent dit ook haar limieten die gesteld moeten worden.

Zo is het van belang om te achterhalen wat de levensduur van de architectuur zal zijn. Op het moment dat dit niet te bepalen is, kunnen we een gedeelte achterhalen door vast te stellen wat de (verwachte) levensduur is van de oplossing die gecreëerd gaat worden.

Een ander essentieel onderdeel is de gewenste “agility” van de architectuur; het vermogen te veranderen. Dit aanpassingsvermogen dient bekeken te worden in relatie tot de kosten en baten van het project, samen met de verwachte levensduur. Door in te spelen op verandering zullen toekomstige projecten goedkoper uit kunnen vallen dan wanneer we dit niet doen.

Naast de nieuwe elementen voor het opstellen van een architectuur, hebben we ook te maken met een levende organisatie. Denk hieraan in beperkingen in keuzevrijheid die te maken hebben met de bestaande architectuur, gekozen technieken, huidige kennis en gehanteerde standaarden.

Deze begrenzingen geven ons een raamwerk waarin een (nieuwe) bedrijfsarchitectuur opgesteld kan worden. Op het moment dat deze duidelijk zijn kan het project gekoppeld worden aan een levendige en flexibele architectuur.

Hoe implementeren we de Agile Architectuur?

Oftewel, hoe eet je een olifant? Simpel: in kleine stukken. Op het moment dat de agile principes worden gehanteerd bij het ontwikkelen van de Enterprise Architecture is het mogelijk om iteratief een aanpasbare architectuur neer te zetten die een lang leven beschoren (kan) zijn. Middels één of enkele interactieve sessies aan het begin van een project kan in zeer korte tijd een blauwdruk worden neergezet die ons leert hoe om te gaan met principes binnen de kaders die de organisatie en het project ons geeft.

Voorbeeld van een sessie om de basis Architectuur te bepalen.

Waarde creëren is een essentieel onderdeel van agile software projecten. Agile architectuur moet dit faciliteren. De klassieke aanpak van Enterprise Architecture tracht een ideaal plaatje te schetsen waar de organisatie aan moet voldoen. Mede hierdoor komt het vaak voor dat architectuur belemmerende maatregelen oplegt aan projecten. Terwijl het juist zou moeten faciliteren. Door Enterprise Architecture te benaderen vanuit de wetenschap dat het aanpasbaar en dynamisch is, volgens de principes van het Agile Manifesto, kunnen we dit wel realiseren.

Het opstellen van een Project Start Architectuur is een goede zaak, mits deze de vrijheid biedt om te evolueren naar volwassenheid. Door stapje voor stapje voortgang te boeken kunnen we eerder acteren op fouten die gemaakt worden.

Samenvatting

Mits goed aangepakt, kan Enterprise Architecture zeker een bijdrage leveren aan organisaties. Op het moment dat de Agile principes gehanteerd worden binnen het opstellen van de architectuur zal in korte tijd een waardevolle toevoeging voor de organisatie ontstaan. Enterprise Architecture is te groot om in een keer voor een volledige organisatie te realiseren. Op het moment dat we de elementen kleiner maken en het een proces maken voor de gehele organisatie kunnen we met kleine stappen grote vooruitgang boeken.

Referenties

• The Open Group Architecture Framework, http://www.opengroup.org/
• Agile Manifesto, http://agilemanifesto.org/
• Agile Enterprise Architecture, http://www.agileea.com