Artikel

Architectuur op een Agile manier

Het lijkt erop dat Architectuur en Agile software ontwikkeling twee gescheiden werelden zijn die ook nog eens vaak met elkaar botsen. De praktijk wijst echter uit dat ze elkaar kunnen helpen.

Agile projecten, meestal aangepakt met SCRUM als methodiek, hebben last van te weinig focus op lange termijn en te weinig totaal overzicht. Aan de andere kant heeft de "Architectuurwereld", ondanks vele intenties voor business wendbaarheid, juist vaak last van starheid en koffiedik kijken. Dit artikel geeft aanknopingspunten voor de combinatie van Agile en architectuur.

Wat is Agile software ontwikkeling?

De essentie van Agile software ontwikkeling zoals beschreven in Agile Manifesto (http://www.agilemanifesto.org) ligt voornamelijk in meer aandacht voor mensen en interactie tussen de mensen. Dit gedachtegoed is gebaseerd op de principes ontwikkeld door Toyota. Hoewel Toyota op dit moment lastige tijden doormaakt is men het erover eens dat dit bijzondere gedachtegoed Toyota tot de grootste autofabrikant van de wereld heeft gemaakt.

Agile software ontwikkeling is inmiddels een feit. De meest bekende Agile methodiek: SCRUM, ontwikkeld door Jeff Sutherland en Ken Schwaber, is bijzonder succesvol. Bedrijven zoals Bol.com, ASR, ProRail ervaren grote productiviteitsverbeteringen, kwaliteitsverhogingen en algemene tevredenheid bij de toepassing van Agile en SCRUM.

Conflicten tussen Architectuur en Agile

Volgens het Agile gedachtegoed of beter gezegd “lean” (The Toyota Way) is alles waar het om draait de werkende software in productie waar een gebruiker iets aan heeft. Alle andere processen en producten en daarmee ook architectuurprocessen en -producten zijn secondair en dus minder belangrijk. Hierdoor worden deze producten vaak als “waste” bestempeld.

Een ander essentieel conflict is de omgang met veranderingen. Agile zegt: “veranderingen gedurende een project zijn goed”. Architectuur lijkt te zeggen: “veranderingen zijn wel oké”, maar in praktijk worden ze op zijn minst niet gestimuleerd en meestal bewust tegengehouden in voordeel van het volgen van een oorspronkelijk ontwerp of besluit.

En het laatste conflict, in Agile software wereld worden besluiten zo laat mogelijk genomen, terwijl de architectuurwereld zoveel mogelijk vooraf wil uitdenken alvorens te gaan bouwen.

Agile software ontwikkeling heeft architectuur nodig

Extremisten onder de Agilisten vinden dat je software “gewoon” moet gaan bouwen en we zien wel waar we met architectuur uitkomen. Volgens hen is architectuur een van de subtaken van software bouwers. Echter, Agile mensen met echte ervaring weten dat dit niet werkt. Tenzij software bouwers allemaal architectuurervaring hebben en hier regelmatig aandacht voor hebben, ligt het recept voor een zooitje klaar.

Overige Agile mensen vinden architectuur wel belangrijk, maar weten vaak niet hoe hiermee effectief om te gaan zonder weer in een waterval te springen.

Architectuurwereld heeft Agile gedachtegoed nodig

Laten we eerlijk zijn: Welke (enterprise) architectuur wordt niet bestempeld als een “ivoren toren” architectuur of neigt die kant op te gaan? Er zijn er bitter weinig. Voor alle duidelijkheid, een succesvol toegepast architectuurproces zoals TOGAF of DYA of gebruik van het Zachman “schema” hoeft helemaal niet te betekenen dat er toegevoegde waarde voor de business is. Er is veel “waste” in de architectuurwereld.

Architectuur, the agile way

Wat we nodig hebben is een aantal beginselen geredeneerd vanuit architectuurperspectief met een Agile en Lean mindset:

“Everybody, all together, early on” - James O. Coplien

De essentie hiervan is dat architectuur het resultaat is van de samenwerking tussen alle belanghebbenden vroeg in het project / programma. Dit resultaat is dan ook lichtgewicht. Het resultaat bevat slechts significante besluiten dat de systemen vormgeven. De mate waarin iets wel of niet significant is, wordt bepaald door de veranderkosten.

Dienstverlenende opstelling van architecten

Een Lean architect heeft vooral aandacht voor belanghebbenden, beschouwt architectuur als een resultaat van samenwerking met bouwers, initieert, faciliteert en coördineert het architectuurproces. Dezelfde architect heeft wel een duidelijke beknopte visie die bij iedereen tot de verbeelding spreekt en gebruikt gezond verstand en eenvoud bij communicatie. Dus geen dure woorden, modellen en tekentechnieken. Een Agile Architect heeft ook aandacht voor de architectuur in de gebouwde software en niet slechts zijn documenten.

Veranderende samenhang in plaats van “Big Design Up-Front”

Een architectuur in de software wereld is totaal iets anders dan een architectuur in de bouwwereld. In de software wereld is de business complexiteit en daarmee vooral gevraagde wendbaarheid groter, en de kosten van verandering lager. Daarom is het prima om de softwarebouw te starten met slechts significante besluiten om vervolgens lerende de architectuur verder in te vullen. Dit iteratieve proces vraagt nog meer discipline dan een architectuurproces waarin vooraf een uitgewerkt architectuur wordt bepaald. Deze manier van werken haalt bijzonder veel “waste” weg.

Architectuur is de software; niet het document

Is het je opgevallen dat de architect zijn documenten “de architectuur” noemt in plaats van “de architectuurbeschrijving”? Als we naar een gebouw kijken, dan is het antwoord op de vraag “Waar is de architectuur?”: “Je staat er naar te kijken!!!”. De oorspronkelijke tekening is slechts een bijzaak. Met andere woorden, de architectuurbeschrijving is slechts een poging om de werkelijke architectuur uit te beelden. Zolang er een mismatch is, heeft de beschrijving weinig waarde. Daarom staat op dat moment de gebouwde software op de nummer 1 positie en de beschrijving hoort zich daarop aan te passen. De mogelijke verbeteringen horen in de software plaats te vinden. Al te vaak is men trots op documenten terwijl de daadwerkelijke software is mislukt.

Modellen & tools zijn goed, maar gezond verstand is leidend

Het klinkt goed, maar wat is eigenlijk “gezond verstand”? Het is die ene persoon en hopelijk meer die goed kunnen uitleggen waarom we een model of tool gebruiken en welke bijdrage het in deze specifieke situatie levert. De praktijk is helaas dat we al te vaak modellen en tools gebruiken zonder dit te weten met als gevolg dat we soms volledig verstrengeld raken in discussies over tools en modellen zelf alsof daar gebruikers van je systeem iets aan zouden moeten hebben.

Conclusie

De genoemde beginselen zorgen er niet alleen voor dat de Agile wereld en Architectuur dichter bij elkaar komen, maar ook dat het architectuurwerk zelf effectiever en efficiënter is. Uiteindelijk is het allerbelangrijkste: het architectuurwerk wordt hiermee veel leuker :-).

Categorie:   
Auteur(s)
afbeelding van viktorgrgic
Viktor Grgic
LeanArch b.v. - Eigenaar

Viktor Grgic is een zelfstandige Agile/Lean IT architect die in zijn werk als software architect Agile principes hanteert. Viktor heeft in zijn loopbaan als architect vele software projecten geleid. Onder andere leiding gegeven aan architectuurteam van Nieuw Handelsregister bij Kamer van Koophandel, lead SOA / integratie architectrol vervult bij ProRail en vele architecten gecoacht in hun werk. Viktor's werk kenmerkt zich door sterke focus op de mensen, eenvoud in alles, risico's onderkennen en realisme in wat met software mogelijk is. Viktor's expertise is met name service-orientatie / SOA, EAI, domein modellering, ontwikkelstraten, ontwikkelmethodieken en systeemontwikkeling van met name JEE systemen.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.