De toegevoegde waarde van de Agile Start Architectuur

Agile en Architectuur worden regelmatig gezien als tegenstelling. Toch benoemen zowel het Agile Manifesto als vele Agile methoden dat architectuur aandacht verdient. Zeker daar waar sprake is van meerdere teams die werken aan ontwikkeling van hetzelfde systeemlandschap, ontstaat de behoefte aan een overkoepelende architectuur. Tijdens een Wednesday Evening Training (WET) zijn we hiermee aan de slag gegaan. In deze trainingsavonden worden technieken en methoden op een praktische wijze besproken, bediscussieerd en geleerd (*1).

Wat is het probleem?

Vanuit de praktijk blijkt dat, in een omgeving waarin meerdere teams zelfstandig ontwikkelen, deze teams hun eigen koers varen bij het toepassen van standaarden. Dit is bijvoorbeeld het geval wanneer koppelingen tussen systeemdelen worden ontwikkeld. Koppelingen creëren afhankelijkheden tussen systeemonderdelen, terwijl je de teams het liefst zo zelfstandig en onafhankelijk mogelijk wilt laten werken. Dit vergt duidelijke afspraken tussen teams om hen optimaal productief te laten zijn. Daarmee ontstaat de vraag: “Hoe zorg je ervoor dat teams in een Agile omgeving binnen hun bandbreedte van handelen blijven, en tegelijkertijd bijdragen aan de doelarchitectuur?”

Architecten zijn veelal opgeleid om te opereren in een watervalomgeving: eerst de architectuur op orde, gedocumenteerd, en dit vervolgens opleggen aan de uitvoerende teams. Architecturen worden vaak laat (of niet) opgeleverd, beperkt gebruikt en het bijhouden ervan is een uitdaging.

Agile teams zijn juist gewend met een minimum aan documentatie te werken. Ten onrechte wordt vaak het uitgangspunt “geen documentatie” gehanteerd.

De Agile Start Architectuur (ASA)

Een Agile Start Architectuur (ASA) kan hierbij helpen. Het vormt namelijk een belangrijk communicatiemiddel tussen de verschillende organisatieniveaus en teams in een Agile/SAFe context. Het ondersteunt wat belangrijk is vanuit bovenliggende lagen, zoals portfolio, programma, release train, om in de onderliggende lagen (b.v. de teams) te gebruiken en rekening mee te houden.

De ASA kun je zien als de vastlegging van afspraken op het gebied van architectuur en vormt zo een leidraad met aanvullende bouwregels en aanvullende acceptatiecriteria voor het product. Voor succes van de ASA is het nodig dat het team deze leidraad begrijpt, accepteert, en actief gebruikt. Actief in de zin dat ideeën van het team ook in de ASA worden opgenomen. De architect moet daar natuurlijk voor openstaan.

We hebben het over ‘Just in time’ architecture en ‘Just enough’ documentatie, en over vastlegging voor het team en het nageslacht. Maar over wat voor soort documentatie hebben we het dan? Hebben we het dan nog steeds over de documenten die we intussen al decennia kennen?

Wanneer werkt het?

Goed samenspel van richting geven en vrijheid geeft het team vertrouwen in de architect en in de architectuur.

Om ervoor te zorgen dat de teams actief aan de slag gaan met de ASA moet je als architect dicht bij de teams staan. Dicht genoeg om afspraken met de teams te kunnen maken en deze in de loop van de ontwikkeling te kunnen toetsen en bijstellen, en tegelijkertijd ver genoeg van de teams om hun onafhankelijkheid en objectiviteit niet te belemmeren.

Een architect moet zich dus committeren aan een team, samen met het team de ASA als levend document onderhouden en tegelijk voldoende afstand bewaren om ook het toetsen te kunnen doen en de teams bij te kunnen sturen.

De rol van de architect

In de praktijk zal een architect dus niet ‘in’ een team zitten. Een architect zal zich niet met de dagelijkse werkzaamheden van een team bemoeien, maar wel regelmatig langskomen om af te stemmen. Hierbij vormt de ASA een gezamenlijk communicatiemiddel waarin zowel de ideeën van de teams als de richting van de architectuur is vastgelegd. Een architectuur is immers constant in ontwikkeling, waarbij architectuurbesluiten en -bouwstenen (oplossingsrichtingen) gedurende de tijd worden verfijnd en aangepast.

Concreet voorbeeld: de methode “Agile Project management” (Agile PM), voortgekomen uit DSDM, onderkent hiervoor de ‘architectenrollen’ Technical Coordinator en Technical Advisor.

In de praktijk

Vastlegging kan op veel verschillende manieren. Natuurlijk in tekstdocumenten, maar ook in Wiki’s, Excel sheets, websites, PowerPointpresentaties, architecture model editors/workbenches et cetera. Moderne platforms bieden meer dan voldoende mogelijkheden om informatie voor de verschillende betrokkenen zowel toegankelijk als gemakkelijk onderhoudbaar kan maken. Waar het om gaat is de informatie (en documentatie) doelgericht te maken en actueel te houden. Je moet als architect en als team daarom constant het doel van de documentatie voor ogen hebben en houden, en deze kort-cyclisch verbeteren. Het maken van documenten is hierbij dus geen doel. Sterker nog: het is vaak beter om gebruiksvriendelijk te verwijzen naar bestaande documentatie dan weer een nieuw hoofdstuk toe te voegen. Let wel: het opstellen en bijhouden van architectuurdocumentatie, en dus ook een ASA, vormt GEEN onderdeel van de backlog, maar zijn onderdeel van de “Definition of Done”.

Een ASA biedt een praktische, toepasbare basis voor het vastleggen van afspraken over de toepassing van architectuur. Deze afspraken worden samen gemaakt, samen nageleefd en samen kortcyclisch verder ontwikkeld. Het maakt de architectuur, de teams en de hele organisatie wendbaarder.

In essentie kan een ASA gezien worden als een checklist in een context van relevante documentatie. De ASA helpt zowel de architect als de teams een weg te vinden in plaats van de hele wereld te willen beschrijven. Alleen zaken die echt belangrijk zijn, voor nu en in de (nabije) toekomst, worden genoemd. Onder de laatste categorie vallen bijvoorbeeld ook nog openstaande vragen die vanuit architectuur moeten worden beantwoord. Dit leidt tot user stories voor het team om deze vraagstukken mee te nemen in de realisatie van het product.

Natuurlijk klinkt bovenstaande allemaal simpel en snel te regelen. In de praktijk vergt het een andere manier van denken. Zowel voor de architect, de teams, als de andere ontvangers en gebruikers van de ASA in de organisatie.

Just do it! Dare to change!

(*1) De Wednesday Evening Training sessies geven een mooie gelegenheid om te bespreken waar je tegenaan loopt om een ASA in te voeren en dit op te lossen en de vraag te beantwoorden hoe je dan weet dat de ASA hetgeen is dat je als product in bredere context wilt hebben. Is het volledig en goed genoeg? Tijdens een trainingsavond zijn we aan de hand van een praktijkvoorbeeld aan de slag gegaan om een ASA op te zetten. Wil je meer weten over onze Wednesday Evening Training? Lees dan dit artikel: https://www.werkenbijcapgemini.nl/blogs/De-woensdagavond-training.

Wij vormen een team consultants bij Capgemini die voor de uitdaging staan ​​om Agile en Architectuur te combineren tot de rol van Agile Architect. De komende tijd publiceren we een serie blogs over de impact die Agile heeft op de rol van de Architect.

Ons team bestaat uit:

Ben Kooistra Wiger Levering Timo Haakman Hans van Zanten René Beltman Joop Koster

Gert-Jan Kooren Vassil Stoitsev Martin Brommer Jeroen Dijkstra Hans van Rijs Mirko van der Maat

Hans van Rijs

Expert in Enterprise Architecture, Microsoft Technologies, Software Architecture

I advice our clients on software technology, architecture and help their architects and ICT specialists to optimize their architecture processes and standards.
I helped ProRail and its partners to standardize and implement a nation wide damage & repair exchange format.