Logo

De impact van de culturele waarden van wendbaarheid: het architectuurdenken (5/7)

Mensen en hun onderlinge interactie boven processen en hulpmiddelen”

Mensen in hun kracht zetten betekent ze autonomie geven. Maar autonomie levert vaak problemen met de coördinatie op. Om te voorkomen dat iedereen autonoom een andere kant op gaat is het richten van de collectieve energie noodzakelijk. De rol van architectuur in een wendbare omgeving is het bevorderen van samenwerking en afstemming tussen mensen en teams.

Tot nu toe heb ik voornamelijk over governance, over structuren en processen geschreven. Oftewel over de rechterkant van bovenstaande zin uit het Agile manifest.
Het succes van een wendbare organisatie wordt bepaald door de cultuur, de waarden die spreken uit de linkerkant van de zinnen van het manifest. Wendbaar zijn is 80% cultuur en 20% kader.

agile onder architectuur - architectuur denken

De cultuur die hoort bij een wendbare organisatie dwingt af dat het architectuurproces op een passende manier wordt ingericht. Als de cultuur van wendbaarheid goed is ingebed in een organisatie, merk je dat aan de beleving en de uitvoering van het proces. Ook al zien de stappen in het architectuurproces er op papier misschien wel hetzelfde uit, de beleving en de uitvoer van het proces is wel degelijk anders dan wanneer wendbaarheid niet in de bedrijfscultuur is verankerd. Ik noem die beleving het architectuurdenken.

Het architectuurdenken is het doorleven van de spelregels om autonoom keuzes te maken. Als iedereen in een zelfsturend team kan helpen om te duiden wat haalbaar is en wat voordelen of beperkingen zijn van keuzes voor aanpasbaarheid, inpasbaarheid en toepasbaarheid van oplossingen, dan heb je de wereld gewonnen in wendbaarheid.

In alle agile methoden zit de boodschap dat ‘change will happen’. Het architectuurdenken moet borgen dat zelfsturende teams niet alleen nu wendbaar zijn, maar ook robuust zijn in het absorberen van verandering. Dat zorgt er voor dat ze wendbaar blijven in de functionaliteit die ze leveren.

Agile methoden zijn gericht op het creëren van passende en bruikbare producten. Het stimuleert denken vanuit use cases, in plaats van vanuit technologie. Architectuur is daarbij een middel om op basis van use cases te bepalen welke technologische oplossingen passend zijn.

Je moet een balans vinden in de focus op aan de ene kant leveren wat nodig is en aan de andere kant klaar zijn voor toekomstige verandering. Eenkennige focus op het leveren van functionaliteit vermindert de wendbaarheid op termijn. Je verliest daarmee namelijk de capaciteit om tijdig nieuwe functionaliteit te leveren. Eén van de principes van het Agile manifesto is niet voor niets:

“Voortdurende aandacht voor een hoge technische kwaliteit en voor een goed ontwerp versterken agility.”

Evolutie betekent ook dat je de gebruikte technologie aanpast bij wat op een bepaald moment of bij een bepaalde koers passend is. Af en toe herbouwen om wendbaar te blijven hoort nu eenmaal bij een omgeving waar technologie de motor van verandering is. Veel organisaties hebben moeite met accepteren dat teams tijdelijk geen nieuwe functionaliteit leveren om te borgen dat ze wendbaarheid blijven en tempo van levering niet laten vertragen door al teveel technische schuld.

Het architectuurdenken kan teams helpen niet alleen naar de functionele eisen vanuit use cases (wat moet het doen), maar ook naar de niet-functionele eisen (hoe moet het werken) te kijken. Voorbeelden van niet-functionele eisen zijn bijvoorbeeld de eisen die gesteld worden aan de actualiteit van gegevens, of aan de kwaliteit van gegevens.

Niet-functionele eisen zijn slechts een middel om een gedragen beeld te krijgen van waar een passende oplossing aan moet voldoen op een bepaald moment in de tijd. Ook deze eisen zullen wijzigen. Weten wanneer je moet afwijken, tijdelijk of in koers, dat is het onnoembare culture aspect van het architectuurdenken.

Het verkennen van de organisatieomgeving is een dagelijkse taak als je veranderingen aan wil zien komen. Als je dat niet doet overvalt de verandering je en loop je bij voortduring achter de feiten aan in plaats van wendbaar te zijn. In een technology push periode zoals nu, is continu evalueren van nieuwe en alternatieve methoden en technieken onderdeel van het dagelijks werk van een team. Je moet begrijpen wat nieuwe technologie je brengt in zowel waarde als in beperkingen om de impact op je organisatie in te kunnen schatten. Continue evaluatie van technologie moet een waarde zijn van de organisatie en niet, zoals nu vaak het geval is, ervaren worden als ten koste gaand van productiviteit.

Een probaat middel om te evalueren is het doen van Proof of Concepts, of Proof of Values. Om een semantische discussie te voorkomen noem ik het prototypes. Het doel van prototypes is om de interactie en discussie tussen en met gebruikers aan te zwengelen:

  • Proberen en selecteren — proeven van nieuwe mogelijkheden, samen met gebruikers.
  • Toetsen en bewijzen — alternatieve oplossingen toetsen tegen de eisen.

Zoals het past binnen een Agile werkwijze zijn de prototypes kort-cyclisch en pragmatisch ingestoken. In het architectuurdenken ligt de focus altijd op waarde voor gebruik. Als er geen waarde is dan is de investering minimaal. Als er wel waarde is, dan wil je deze zo snel mogelijk kunnen oogsten.
In het architectuurdenken is pragmatiek ingebakken, waarbij de consequenties van keuzen voor de gehele organisatie in het oog gehouden worden.

De impact van veranderingen die een team te boven gaan zullen door teams gezamenlijk bepaald moeten worden. Maar hoe doe je dat? Het antwoord wordt uitgewerkt in het volgende en laatste inhoudelijke deel van de serie. Het formaliseren van de governance structuur: wendbaar onder architectuur.




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