Door de adoptie van het agile werken is de werkwijze van de architect aan het veranderen. Agile teams wachten niet op late architectuurdocumenten. De belangrijkste beslissingen zijn dan immers al genomen. Hoe zorgt een architect ervoor relevant te blijven in organisaties? Hoe kunnen applicaties worden ontwikkeld vanuit een gedragen architectuur, die omarmd is door de agile teams?

Hieronder ga ik in op de vier dimensies van de agile-architectuuraanpak die het werk van de architect richting geven door:

    • architectuur te zien als een stroom van ontwerpbeslissingen;
    • de economische factoren (risico’s en kosten) de focus te laten bepalen;
    • de architectuurinzet af te stemmen op de noodzaak (just enough, just in time) en tijdigheid van ontwerp- en inrichtingsbeslissingen;
    • nadrukkelijk samen te werken met de agile teams.

Mijn ervaring is dat architectuur en agile werken prima samengaan als er een ‘just enough/just in time’-balans wordt gevonden.

Te veel

Te veel architectuur of te veel agile denken: het is beide niet goed (zie figuur 1). De kunst is het vinden van een balans met behulp van onderstaande perspectieven, waardoor een korte en steile leercurve binnen de projecten ontstaat, standaards waar nodig worden toegepast en directe feedback op de architectuurproducten komt. Zo kunnen deze aangepast worden aan de dagelijkse realiteit met een balans in werken met architectuur en agile principes zonder de businessrationale uit het oog te verliezen.

Figuur 1. Te veel architectuur of te veel agile denken

Architectuur als stroom van ontwerpbeslissingen

De projectarchitect schreef traditioneel zijn projectstartarchitectuurdocument naar aanleiding van gedegen vooronderzoek, en afstemming met technische specialisten en enterprise-architecten. Daarbij werd de huidige en toekomstige situatie concreet in kaart gebracht en voorzien van richtinggevende principes en richtlijnen. Dit duurde vaak een aantal maanden, terwijl de businessbehoefte steeds nijpender werd. Het gevolg daarvan was dat project- en agile teams vanuit terechte druk van de opdrachtgever niet langer konden wachten en zelf aan de slag gingen.

Just in time, just enough

Op basis van de meer traditionele architectuurmethoden zijn architecten gewend om gedurende de eerste maanden van een project een projectstartarchitectuur te ontwikkelen. Ontwikkelteams willen echter snel van start en dan kunnen nog niet alle architectuurbeslissingen genomen worden. De agile-architectingaanpak komt hieraan tegemoet door adoptie van het ‘just in time, just enough’-principe.

Ook verandert de wijze waarop architecten ontwerpbeslissingen nemen in projecten. Niet alle beslissingen worden aan het begin van het project genomen maar op het moment waarop dat nodig is. Meestal is dat wanneer issues of discrepanties met ontwerpen in andere agile teams worden geadresseerd. Of als er voldoende inzicht is gekomen in de actuele situatie waardoor concrete en treffende principes en richtlijnen opgesteld worden in samenwerking met de ontwerpers en ontwikkelaars.

Hierdoor ontstaat ook direct commitment voor de realisatie conform de architectuur, sluit de architectuur optimaal aan op de actuele situatie en wordt geborgd dat inrichtingskeuzes aansluiten bij de doelarchitectuur van de organisatie.

“De architect wordt regisseur van ontwerpbeslissingen”

Ontwerpbeslissingen komen in deze aanpak tot stand op het moment dat agile teams dat nodig hebben en de samenhang en bijbehorende schaalvoordelen optimaal worden geborgd. Door te starten met een minimale set van ontwerpbeslissingen in een beknopt en leesbaar document kunnen de kaders van de oplossingsrichting al worden gezet. Door snel te starten wordt inzicht gekregen in de praktische beperkingen en kan de architectuur hiermee omgaan en aangevuld worden.

Kortom, het ‘just enough, just in time’-principe draait om nieuwe inzichten en daarmee omgaan.

Deze aanpak is nodig doordat het fundament van architecturen in het verleden zodanig zijn gebouwd dat zij niet gemakkelijk gewijzigd kunnen worden als zij eenmaal zijn geïmplementeerd. Het moet dus in één keer goed gebeuren. Later wijzigen is duur. Daarnaast zijn grote architecturen meestal niet op een agile werkwijze te realiseren.

Niet voor alle problemen is agile werken het antwoord. Denk maar aan grote data lakes waarvan realisatie toch geruime tijd in beslag neemt. Aan de andere kant geeft agile werken ontwerpers en ontwikkelaars zoveel vrije ruimte als mogelijk. Daardoor kan de architect het overzicht houden en zich richten op samenhang en synergie in gebruikte technologie en hergebruik van al bestaande oplossingen.

In de praktijk zorgt deze aanpak ervoor dat de essentiële issues geïdentificeerd en geprioriteerd worden waarmee de best mogelijke oplossingen worden onderzocht. Zo kan concreet worden gekozen voor de best passende oplossing, en zijn gemaakte keuzes ook achteraf verklaarbaar (zie figuur 2).

Figuur 2. Aanpak van essentiële issues

Economische factoren

Het ontbreken van de economische focus in veel architectuuraanpakken zorgt voor het ontbreken van de beloofde baten tijdens de realisatie. Veel opgeleverde projecten blijken een duur en complex IT-landschap op te leveren.

Binnen de agile-architectingaanpak ligt de focus van architectuurbeslissingen op realisatie van zo eenvoudig mogelijke toepassingen. Toepassingen die recht doen aan de eisen van de opdrachtgever, snelle start en realisatie, en bovendien binnen de doelarchitectuur van de organisatie passen. En ook waarbij expliciet aandacht is besteed aan de risico’s en kosten tijdens realisatie, onderhoud en beheer.

Dit uit zich in applicaties die toekomstvast en goed onderhoudbaar zijn tegen zo laag mogelijke kosten, door tijdens het ontwerpen elke nieuwe component kritisch op de toegevoegde waarde te beoordelen en te kijken wat de risico’s zijn van alternatieve, goedkopere oplossingen. Ook wordt gekeken naar de impact van de ontwerpbeslissing op de exploitatiekosten van de toepassing als gevolg van het minimaliseren van in- en externe complexiteit door beperking van afhankelijkheden en relaties.

Dit zorgt ook voor minimale veranderingen voor het totale IV-landschap, de bedrijfsvoering en het onderhoud en de exploitatie van de totale applicatieportfolio. Bovendien wordt gekeken hoe bestaande legacy (in vaktermen ook wel technical debt genoemd) kan worden vervangen door meer toekomstvaste constructies.

Aanpak van legacysystemen

Ook legacysystemen worden in de agile architecting aangepakt. Het gaat erom grip te krijgen op het vervangen van te complexe of hopeloos verouderde en daardoor te dure constructies. Vervanging van componenten van deze constructies is expliciet onderdeel van de solution-backlog die de agile teams realiseren.

Door het classificeren van features en het schatten van de benodigde capaciteit kan een realistische inschatting worden gemaakt van de benodigde capaciteit in de agile tams. Op basis daarvan wordt een sprintplanning opgesteld met een mix van features. Niet alleen features die direct nieuwe functionaliteit leveren of meer kwalitatieve eisen invullen, maar ook features die delen van legacysystemen vervangen door meer toekomstvaste, flexibele componenten.

Afhankelijk van de fase van het project zal de mix variëren. In het begin van een project zal het belang van snelle levering van businessfeatures hoger zijn dan wanneer het project richting het in beheer nemen gaat.

Samenwerken met agile teams

Architectuur wordt in agile projecten steeds meer een kwestie van teamwork. De rol van de architect verandert! Deze rol verschuift naar die van regisseur van ontwerpbeslissingen en het prioriteren van de solution-backlog en sprint-backlog. Oftewel, het prioriteren van zaken die gedaan moeten worden in projecten om tot resultaat te komen.

Daarbij wordt een mix van activiteiten onderkend. Van features die direct toegevoegde waarde voor de gebruikers opleveren en meer architecturale functionaliteit om te voldoen aan de kwalitatieve eisen van de constructie (zoals schaalbaarheid en flexibiliteit) tot het verhelpen van onderkende defecten en het opruimen van oude of complexe onderdelen – technical debt – die de organisatie veel kosten aan beheer en onderhoud.

Figuur 3. Vinden van een balans in agile werken

Het gaat bij technical debt niet alleen om zwaar verouderde systemen. Het kan ook ontstaan doordat kortetermijnoplossingen nodig zijn om de organisatie te helpen bij acute uitdagingen en er structureel onvoldoende tijd of geld is om een meer toekomstvaste oplossing te realiseren. In dat geval kan vervanging van de features van de kortetermijnoplossing in agile teams plaatsvinden als daar ruimte ontstaat wanneer er minder druk op deze teams staat en niet de volledige capaciteit benut wordt.

Hier kan een architect doelgericht op sturen in de samenstelling van de backlogs. De architect wordt een regisseur van ontwerpbeslissingen doordat hij/zij niet alle ontwerpbeslissingen kan en hoeft te nemen bij een groeiend aantal agile teams.

Ontwerpers en ontwikkelaars zijn heel goed zelf in staat om ontwerpbeslissingen te onderkennen en te nemen. Wel dient de architect de samenhang te bewaken en te controleren of realisatie conform de gewenste situatie en doelarchitectuur, en conform afspraak met de opdrachtgever nagekomen kan worden. Hoe hoger het aantal teams, des te meer verantwoordelijkheden worden gedelegeerd.

Samenvatting

Samengevat zorgt agile architecting dat architectuurwerk een stroom van ontwerpbeslissingen is, die zorgt voor richting in de ontwikkeling van informatiesystemen door agile teams. De focus van de architectuurbeslissingen ligt op zo laag mogelijke kosten van de door te voeren verandering, de exploitatiekosten van de nieuwe toepassing en minimalisering van risico’s in het doorvoeren van veranderingen.

Door te starten met een minimale set van ontwerpbeslissingen in een beknopt en leesbaar architectuurdocument, kunnen de kaders van de oplossingsrichting al worden gezet. Daardoor wordt de slagvaardigheid van de organisatie vergroot.

Door samenwerking met de agile teams worden ontwerpbeslissingen op het juiste niveau genomen en borgt de architect vooral de samenhang daarin. Zo krijgt hij of zij ook ruimte om de noodzakelijke contacten met de klantorganisatie te onderhouden, af te stemmen met collega’s en bij te blijven in de ontwikkelingen van het vakgebied.

REAGEREN

Plaats je reactie
Je naam