Heeft Agile Architectuur nodig om succesvol te zijn? (deel 2)

Agile en TOGAF ADM

De kern van de TOGAF is de Architecture Development Method, ADM. Het lijkt op een watervalbenadering, maar dat hoeft niet per se zo te zijn. De afzonderlijke fasen en groepen van fasen kunnen op een agile manier en in sprints worden afgerond.

Een van de primaire doelstellingen van fase A is een consensus over de “visie”. Men zou kunnen stellen dat een fase A een “epic” definieert. Alternatief, zou een andere fase A een “User Story” kunnen definiëren. Fase A kan de “Programmaverhoging” voor een ” Agile Release Train” definiëren. Elk van deze dingen kan op verschillende niveaus in kaart worden gebracht in Fase A: Architectuurvisie. Overgebracht naar SAFe Agile, kon Fase A ook de definitie van “strategische onderwerpen op bedrijfsniveau” of “waardestromen op het niveau van het programma portfoliomanagement” in kaart brengen en vereenvoudigen. TOGAF’s “Capability-Based-Planning” helpt hierbij.

Vanuit een bedrijfsarchitectuur en IT-perspectief is capaciteitsgerichte planning een krachtige manier om ervoor te zorgen dat het strategische bedrijfsplan de onderneming van boven naar beneden leidt. Het kan ook worden aangepast met behulp van capability engineering om te profiteren van opkomende bottom-up innovaties. Ongeacht hoe de organisatie zelf is gestructureerd, moet het de levering van zakelijke mogelijkheden beheren waarvan de implementatie coördinatie en afstemming tussen alle bedrijfsonderdelen vereist. De functies zijn idealiter bedrijfsgericht. Een van de belangrijkste uitdagingen is dat de voordelen vaak op bedrijfsniveau worden bereikt en niet op afdelings- of afdelingsniveau. Als gevolg hiervan werken projecten in sector- of afdelingsgerichte portefeuilles vaak meer vanuit hun eigen perspectief dan vanuit het perspectief van de onderneming. Het managen van de levering van een capaciteit is een uitdaging, maar het verankeren van een op capaciteit gebaseerd perspectief in een bedrijf is een krachtig mechanisme om synergetisch afgeleide bedrijfswaarde te bereiken die zich vertaalt in winstgevendheid en voorraadwaarde.

Bij elke agile iteratie op elk niveau – en bij elke ADM-Iteratie op elk niveau – moeten belanghebbenden en hun eisen worden betrokken. Sommige stakeholders kunnen worden beschouwd als “Epic Owners” of “Persona” in een “User Story”.

Stakeholder management is van cruciaal belang in TOGAF. Wie faalt in het stakeholdermanagement loopt het risico dat de gestelde doelen niet gehaald worden. Juist daarom mislukt 80% van de transformatieprojecten – en bij Agile draait alles om stakeholdermanagement. In een agile context zijn Epic-eigenaren direct betrokken bij het gehele agile ontwerpproces. Agile zegt dat en TOGAF zegt precies hetzelfde.

Eisen en ontwerp ontstaan wanneer we in agile sprints en ADM-cycli itereren. Altijd direct en continu verbonden met onze stakeholders – schouder aan schouder, in dezelfde ruimte, in dezelfde Scrum-teams.

Er moet worden bepaald in hoeverre de fasen B, C en D relevant zijn en wat er met betrekking tot deze architectuurdomeinen of “concerns” (concerns) moet gebeuren. Idealiter is het resultaat van fase D al gedefinieerd en mag worden aangenomen dat de technische architectuur vrij duurzaam, reeds gegeven en herbruikbaar is. De teams in uw sprints richten zich dus alleen op fase B en C – de business architectuur, applicatie architectuur en data architectuur. Dat hoeft natuurlijk niet zo te zijn. Je kunt net zo goed agile ontwerpen en itereren voor het leveren van een infrastructuurtechnologie of -platform, maar ik denk niet dat Agile echt voor dat doel is ontworpen.

Het is waarschijnlijk dat fase D: technologie-architectuur een soort “architecture epic” is dat we apart zullen realiseren. Ik denk niet dat fase D vaak in een sprint of programmastap wordt ontworpen of gerealiseerd. Ik ben er eerder van overtuigd dat een agile sprint zich zal richten op business architectuur, applicatie architectuur en informatie/data architectuur. Fases B en C.

Het is noodzakelijk om te bepalen wat beschikbaar en gegeven is (baseline) en waar ze naartoe willen (target). In feite vindt de ontwikkeling zelden plaats op nieuwe locaties. Daarom kan het goed zijn om te weten wat we aannemen. Er kunnen beperkingen of vereisten zijn die bekend moeten zijn, er kunnen reeds aangenomen principes zijn die moeten worden nageleefd, Fases B en C kunnen in kaart worden gebracht bij Agile/Scrum praktijken. Men zou kunnen zeggen dat fase B en C – uitgevoerd in parallel – een “sprint” kunnen definiëren en dat fase B en C – uitgevoerd in parallel – een iteratieve “agile release train” (ART) kunnen definiëren, d.w.z. een “programma verhoging”.

Besloten kan worden dat Fase B – Business Architecture – alleen wordt uitgevoerd in agile iteraties. Dit kan met name het geval zijn op het niveau waar strategische bedrijfsthema’s worden gedefinieerd of waar aandacht wordt besteed aan het veranderen van de belangrijkste waardetoevoegende stromen op het niveau van ‘programmaportfoliomanagement’. Op dit niveau is het strategische ‘wat’ misschien interessanter dan het tactische ‘hoe’.

Ik denk dat wie een aspect van de business architectuur verandert, bijna altijd een aspect van de applicatie en informatie/data architectuur zal veranderen. En dit is precies waar wendbaarheid nodig is. De meeste flexibele releasetreinen die ik zie combineren – en richten zich bijna uitsluitend op – business architectuur, applicatie architectuur (presentatie, business rules, workflow) en informatie en data. Zo itereren ze voortdurend over de fasen B, C en zelden D.

Na enkele incrementele iteraties van fase B, C en eventueel D is het noodzakelijk om in fase E een aantal alternatieve opties te overwegen voor het doorvoeren van de wijzigingen in een agile release trein. Dit kan het controleren van een aantal verschillende opties voor het samenstellen en hergebruiken van architectonische bouwstenen uit de TOGAF Architecture repository omvatten. Welke onderdelen realiseren het beste het “minimaal haalbare product”, welke onderdelen moeten worden weggelaten of verwijderd en weer in de Kanban-Backlog worden geplaatst? Soms is fase E niet nodig en kan deze worden gecombineerd met fase F. In een Agile + DevOps omgeving worden fase E en fase F hetzelfde.

Wat in fase F gepland is, kan onmiddellijk en volledig door een DevOps-team worden ontwikkeld, geïmplementeerd, getest en als afzonderlijke iteraties parallel aan de ADM-cyclus beschikbaar worden gesteld. Het is belangrijk dat de informatie die nodig is in de ADM-fasen F en G altijd beschikbaar is om eventuele aanpassingen in de architectuur en/of het architecturale kader te waarborgen. Men kan zich dus voorstellen dat de fasen F en G als “DevOps iteratie” van de ADM worden beschouwd. En DevOps is agile. Als je echt agile wilt zijn, moet je proberen DevOps te bereiken.

In fase H: Architecture Change Management, kan de achterstand van Kanban worden beheerd. Ik beschouw Fase H als de plaats waar de “architectonische schulden” worden geregistreerd. Architectuurschuld wordt niet eens genoemd in TOGAF. Maar het is een algemene term die door architecten over de hele wereld wordt gebruikt. Soms noemen ze het “technische schuld” of “bedrijfsschuld”. Als eenmaal de incrementen zijn geïmplementeerd in de productieomgeving, bekijkt het team in Fase H onmiddellijk de Kanban-achterstand en begint het met de planning en uitvoering van de volgende agile releasetrein, de volgende programma increment, de volgende Epic en de volgende sprint, de volgende Fase A.

Agile and TOGAF: No contradiction

In die zin is er geen sprake van een conflict tussen architecturale kaders en behendigheid, aangezien beide proberen verschillende problemen op verschillende niveaus op te lossen. Op het niveau van Strategische Architectuur en Segment Architectuur gaat het bij enterprise architecture om de vrij langlevende definitie van business principles en standaarden, applicatiebouwstenen, infrastructuur en de standaarden waarbinnen agile teams werken. Agile methoden gaan meer over de meest efficiënte organisatie van een softwareontwikkelingsteam en zijn daarom het meest geschikt op het niveau van de capability architecture voor snelle iteraties.

Enforcement and governance

Ondanks deze scheiding is er een punt waarop de twee benaderingen met elkaar kunnen botsen, vooral als het gaat om de handhaving van de strategische en gesegmenteerde architectuur en governance.

Hoewel we willen dat agile teams autonoom en zelfsturend zijn, maken ze nog steeds deel uit van een bredere organisatie. Agile teams in grote organisaties kunnen nooit volledig autonoom zijn omdat ze opereren binnen de grenzen van gegevens, conventies, technologieën, regels en strategieën die voor de hele organisatie zijn vastgesteld. TOGAF probeert een structureel proces te definiëren om deze grens transparant en inclusief te maken.

Nalevingscontroles zorgen ervoor dat de beste praktijken worden toegepast, dat aan de normen wordt voldaan en dat een gemeenschappelijke infrastructuur wordt gebruikt. Dit kan een zeer gedetailleerd proces zijn – een volledige nalevingscontrole omvat een checklist van meer dan honderd elementen, waaronder hardware, informatiebeheer, beveiliging en technische procedures.

TOGAF is van plan om de standaardchecklist aan te passen om de aandacht te richten op gebieden met een hoog risico, met de bedoeling om een extern panel van architecten op een zeer gedetailleerd niveau van achterstanden van flexibele ontwikkelingsteams te brengen. Architectonische governance is noodzakelijk en goed als het gaat om de bredere context die de teams niet kunnen herkennen. Het is minder geschikt als het gaat om ontwikkelingsaspecten waar de teams zelf de erkende experts zouden moeten zijn.

Heeft Agile architectuur nodig om succesvol te zijn?

Heeft Agile architectuur nodig om succesvol te zijn? “Ja!” zou ik zeggen, en de vraag uitbreiden: “Wat voor soort architectuur heeft Agile nodig om succesvol te zijn? Agile vraagt om een stabiele architectuur die de manier ondersteunt waarop Agile-praktijk resultaten en toegevoegde waarde oplevert. Het type architectuur dat dit zal doen moet een combinatie zijn van een agile, reactieve architectuurstijl ondersteund door een meer traditionele, gestructureerde benadering van architectuur. De uitdaging is, zoals bij veel zaken, om de juiste mix te vinden.