Logo

Formaliseren van de governance: “Agile onder architectuur” (6/7)

Samenwerking tussen mensen is de kern van iedere agile methodiek. In de voorgaande artikelen ben ik ingegaan op wat de rol van architectuur is om de samenwerking te richten en hoe je daar als architect naar mijn mening op een succesvolle manier een bijdrage aan kan leveren.

Maar samenwerking alleen is niet voldoende. Stel je voor dat je in een project of organisatie moet werken waar er geen enkele vorm van documentatie is van wat er opgeleverd is, van hoe het werkt en er geen plannen zijn voor toekomstige ontwikkeling.
Ik denk niet dat de organisatie of het project heel lang succesvol zal zijn.

agile onder architectuur - formaliseren

De truc is om datgene te documenteren wat essentieel is en ook niet meer dan dat. Te organiseren wat nodig is om mensen hun werk te kunnen laten doen en beslissingen te laten nemen, maar ook niet meer dan dat. Het werk te plannen om te identificeren waar knelpunten zitten en te bepalen wat de gevoeligheid is voor veranderingen, maar ook niet meer dan dat.

Architectuurdocumenten als middel voor communicatie

Architectuurdocumenten helpen om vast te leggen welke keuzen er gemaakt zijn, wat de redenen zijn geweest om die keuze te maken en om kaders en aannames vast te leggen, zodat toekomstige ontwikkelingen getoetst kunnen worden.
Architectuurdocumenten zijn communicatiemiddelen. Ze werken als een geheugensteun om de waan van de dag niet de overhand te laten nemen en niet steeds dezelfde discussie te hoeven voeren.

De gelaagdheid van architectuurdocumenten

Er zijn verschillende soorten architectuurdocumenten die ieder horen bij een ander niveau van verantwoordelijkheid. Volgens ISO/IEC/IEEE 42010 is de definitie van architectuur:

“fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution”

De logische consequentie is dat een enterprise architectuur dit beschrijft voor de organisatie als geheel, de domeinarchitectuur voor een afgebakend bedrijfsproces of groep van bedrijfsprocessen en de oplossingsarchitectuur voor een specifieke oplossing binnen een domein.

Documentatie als meetlat voor veranderingen

Als je het uitgangspunt hanteert dat je alleen datgene documenteert wat essentieel is en niet meer dan dat, dan leg je in een enterprise architectuur alleen vast wat essentieel is om de wendbaarheid van de organisatie te borgen. Hetzelfde geldt voor de domeinen en de oplossingen.

Je creëert een meetlat om de mate van impact van een verandering te bepalen. Bij iedere verandering check je of dit leidt tot een noodzakelijke aanpassing op enterprise, domein of oplossingsniveau. Een aanpassing op enterprise architectuur niveau heeft een veel fundamenteler consequentie dan de aanpassing van een specifieke oplossing. De koerswijziging op het evolutiepad is bij een aanpassing in de enterprise architectuur majeur en bij de aanpassing van een oplossing hooguit een kleine correctie of het slechten van een hobbel.

Het niveau waarop de impact plaats heeft zorgt voor een duidelijk beeld tussen welke teams afstemming moet plaatsvinden om de verandering door te voeren. En waar je de verantwoordelijkheid voor het absorberen van de verandering kan leggen.

Als je als team(s) verantwoordelijk voor een oplossing werkt met standaarden, templates en ontwikkelpatronen, dan hoef je in de implementatie alleen maar de afwijkingen op de templates en de ontwikkelpatronen te documenteren. Het scheelt niet alleen ontzettend veel werk, het maakt het aanpassen of uitbreiden van functionaliteit van de oplossing veel transparanter, waardoor je sneller en met hoge mate van betrouwbaarheid het product kan laten evolueren. Je bent wendbaarder in de uitvoering.

Wendbaarheid zit in het bloed

Bij het ‘precies genoeg’ vastleggen van beslissingen in architectuurdocumenten moet je als architect niet alles zelf willen doen. Keuzen voorschrijven en achteraf controleren of deze ook zo zijn uitgevoerd is dodelijk voor je wendbaarheid. Je creëert dan weer de top-down structuur waar het agile manifest zich tegen afzet.

Keuzen die gemaakt zijn en passen binnen het kader van een domein- of oplossingsarchitectuur worden gedocumenteerd door het team zelf. Pas wanneer een verandering vraagt om een aanpassing aan het kader vraagt het team aan de architect om in actie te komen. Samen met teamleden of teams ga je aan de slag om alternatieven te verkennen middels prototypes. Gezamenlijk maak je de keuze voor de aanpassing aan het kader. De verwerking van de consequentie van de keuze is weer aan het team of de teams.

Wendbaarheid moet in het bloed van het team gaan zitten, het architectuurdenken is belangrijker dan documenteren. Het is de verantwoordelijkheid van de architect om het team zijn eigen denkproces vast te laten leggen, zodat het team het eigen geheugen opbouwt. Hiermee kan een team zelf verantwoordelijkheid nemen voor het bepalen van de impact van verandering. Keuzen die gevalideerd zijn door een team borgen de toekomstige aanpasbaarheid van de oplossingen die ze maken. Door de architectuurdocumenten te gebruiken als afbakening van de keuzeruimte kan een team zelf signaleren wanneer afstemming met andere teams gezocht moet worden. Als ieder team zo werkt ben je als organisatie agile, onder architectuur.




Reacties via Twitter @MartijntenNapel of e-mail reacties@preachwhatyoupractice.nl