‘Agile architectuur’ is geen nieuw begrip. Wat het precies is, daar verschillen de ideeën nog wel over. Waar de meeste architecten en agilisten het wel over eens zijn is de volgende redenering:
Maar hoe dan? In de cursus ‘Architectuur en Agility’ merk ik steeds weer dat dit één van de hamvragen is waar (enterprise) architecten mee worstelen. De impliciete gedachte lijkt vaak te zijn: “Ik kom al om in het werk, en nu moet ik ook nog eens allerlei <Agile stuff> erbij gaan doen”. Wat ik ze voorhoud dat dat niet gaat werken. We reiken een reeks van best practices aan die invulling geven aan het begrip ‘Agile enterprise architectuur’. Over één ervan wil ik het hier hebben. Ik noem dat in goed Nederlands:
Decision Driven Architecture
Het uitgangspunt is dat Big Design Up Front niet werkt. Niet in een wereld die in rap tempo zo complex is geworden en zo snel verandert dat het de menselijke maat te boven gaat om het in blauwdrukken te vangen. Het is geen toeval dat Agile is opgekomen in hetzelfde tijdsgewricht dat de centraal geleide economieën ten onder zijn gegaan, dat kennis en macht verplaatsen van de bolwerken naar de netwerken, en dat de mainframes plaats hebben gemaakt voor gedistribueerde architecturen. Met andere woorden: Agile is geen hype maar een nieuw paradigma, en dat geldt ook voor architectuur!
Dat gezegd hebbende zou het natuurlijk mooi zijn als we toch een doelarchitectuur zouden hebben, zodat we onderweg een toetsingskader hebben waaraan we kunnen afmeten welke ontwerpbeslissingen de juiste zijn. Een legitieme vraag is dus: ‘welke vorm van doelarchitectuur is nog wel haalbaar als we de ambitie van een volledige blauwdruk laten varen?’
Er zijn verschillende antwoorden gegeven op deze vraag:
- Geen. De beste architectuur ontstaat emergent. Dit antwoord was populair in de tijd van het Agile Manifesto, maar is al jaren geleden – ook door de oorspronkelijke auteurs – ruimschoots geamendeerd.
- Principes. Principes kunnen krachtige stuurinstrumenten zijn, omdat ze gemakkelijk te formuleren zijn, en omdat ze echt richting kunnen geven. In de praktijk kleven er ook ernstige nadelen aan. Om er een paar te noemen: de consequenties ervan worden niet begrepen door degenen die ze vaststelt, ze worden niet gehandhaafd, of ze worden toegepast zonder de context in beschouwing te nemen.
- Lokaal-specifieke modellen. Daarbij stappen we af van de ambitie om compleet te zijn, en we blauwdrukken alleen nog dat stukje dat we echt nodig hebben. Dat is een benadering die kan werken, maar vraagt om voldoende governance om het ook duurzaam te maken. Elke keer opnieuw het wiel uitvinden is gewoon te duur, dus enige vorm van een enterprise geheugen is noodzakelijk.
Mijn antwoord op deze vraag is: een decision driven architectuur.
De vraag die ik me stel als mij gevraagd wordt om – vaak in veel te weinig tijd – een doelarchitectuur op te leveren, is: wat is nu relevant voor deze organisatie? Hoe lever ik iets op dat richting geeft, en wat concreet bijdraagt aan wat mensen nu bezighoudt? Dus ga ik op zoek naar de zaken waarover de komende periode, zeg 6 maanden, een beslissing genomen moet worden. Ik zoek ook wel top down (wat willen we als bedrijf) maar vooral bottom up (vraagstukken waar we in projecten tegen aan lopen). Al dat er teveel worden ga ik samen met de klant prioriteren. Wat kan niet uitgesteld worden? Waar zijn de afhankelijkheden, belangen of risico’s het grootst? En natuurlijk: waar is een architectuurperspectief gewenst? Dat leidt dan tot een geprioriteerde backlog van onderwerpen waarop we vanuit architectuur met een bijdrage moeten komen. Dat kan van alles zijn: een voorstel om ergens serieus tijd in te gaan stoppen, een voorlopig beleidsvoorstel, een schets van waar we naar toe willen, een aantal scenario’s, een advies, etc.
Op deze manier ben je als architectuurafdeling Agile bezig. Je bent transparant. Je draagt bij aan wat belangrijk is voor de organisatie. Je herprioriteert voortdurend. En ook lange termijn zaken blijven in beeld: ze worden opgepakt als de business owners en dat is inclusief de directie, vinden dat het voldoende prioriteit heeft.
Consequenties
Deze benadering heeft natuurlijk ook consequenties. Bijvoorbeeld: de doelarchitectuur komt nooit af. Dat applicatielandschap wordt steeds maar voor zoverre ingevuld als we het nodig hebben. Is dat erg? Nee, maar het voelt soms wel ongemakkelijk. Je kán iets missen. Maar goed, als ik naar Rome wil, heb ik ook niet de hele kaart van Europa nodig, alleen maar van de route en een stukje omgeving. Volledigheid is dus een ambitie die je los moet laten.
Een andere consequentie is dat onderwerpen niet in één keer besloten hoeven, maar ook niet kunnen worden. We vragen om besluiten in stapjes. Zo stond bij een klant de vraag op de agenda wat te doen met big data. Diverse business units hadden daar uiteenlopende ideeën bij, maar nog geen concrete initiatieven genomen. De enterprise architect heeft de initiatieven in beeld gebracht en inzichtelijk gemaakt dat er gemeenschappelijke zaken zijn die je het beste samen kan oppakken. De directie besloot om samen één competence center in te richten en te financieren. Meer was op dat moment niet nodig. Besluiten over kostentoerekening, technologie en bemensing kunnen later genomen worden. Met deze incrementele benadering leverden we geen blauwdruk op van een BI-omgeving, maar we waren wel op tijd, en dat werd gewaardeerd. Die BI-omgeving komt er wel, daar zijn we bij.
Je kan vinden dat je met deze Decision Driven Architectuur benadering geleefd wordt door de waan van de dag. Ik zou dat net even anders willen formuleren: Met een Decision Driven Architectuur ben je in staat optimaal mee te leven met wat de organisatie belangrijk vindt, nu én in de toekomst. Dat lijkt me een vereiste in deze Agile tijden.
Ook interessant
Bekijk hier hele gehele Architectuur portfolio of lees hier meer Architectuur gerelateerde blogs!