Blog

Agile Architectuur – tegenstelling of ideale combi?

Auteur Joost Lommers Joost Lommers is enterprise designer en Enterprise Architecture consultant bij Trivento. Joost vindt het leuk om diep onbekend terrein in te trekken en is altijd op zoek naar een waarden-volle oplossing – met menselijke maat en klantgericht, nooit alleen technologiegedreven.

In een digitale wereld die steeds meer aandacht schenkt aan agile werken, lijkt digitale architectuur steeds meer onder druk te staan. De grootste reden hiervoor is één van de principes van het Agile Manifesto: "The best architectures, requirements, and designs emerge from self-organizing teams". Vaak samengevat als "architecture is self-emergent". Nu ben ik de eerste die toegeeft dat we niets hebben aan "ivoren toren architectuur", maar het gaat mij te ver om te stellen dat architectuur vanzelf ontstaat. Volgens mij geldt namelijk, iets wat je aandacht geeft groeit en bloeit, iets wat je negeert verdort. Een goede balans is vervolgens nodig om iets dat groeit en bloeit niet te laten woekeren.

Big Design Up Front (BDUF) werkt niet

Misschien een open deur, maar toch even om mijn positie direct duidelijk te maken: Big Design Up Front werkt niet. Eenvoudigweg omdat je te lang bezig bent met ontwerpen, de wereld ondertussen verandert, betrokkenen nieuwe kennis en ervaring opdoen die leidt tot nieuwe eisen en wensen, et cetera. En met alleen denken kom je er niet, je zult moeten experimenteren, toetsen, afstemmen. Alleen met de voeten in de modder leer je of iets echt werkt of niet. Dat geldt niet alleen voor het bewijzen dat nieuwe technologie in de praktijk werkt, maar ook om opdrachtgevers en eindgebruikers te laten ervaren hoe een digitale dienst werkt. ICT is vaak zo abstract en virtueel dat alleen het werken met (op z'n minst) een prototype of Minimal Viable Product (MVP) je een gevoel geeft van hoe het daadwerkelijk functioneert. In de DSDM aanpak heet dat IKIWISI, I Know It When I see It. Maar ondanks de meerwaarde van, kleine, incrementele, tastbare resultaten wil dat niet zeggen dat No Design Up Front wel werkt.

No Design Up Front werkt ook niet

Natuurlijk, soms kan No Design Up Front best werken, maar alleen binnen "laboratorium omstandigheden" of in hele beperkte settings. En met een volwassen team. Het agile manifesto zegt namelijk niet "architecture is self-emergent", het zegt dat "the best architectures ... emerge from self-organizing teams". Dat is iets heel anders, en het legt de verantwoordelijkheid voor architectuur bij het team. Een team dat dan binnen de dagelijkse waan van een sprint moet ontdekken dat er over architectuur nagedacht moet worden. Of dat de gemaakte producten en diensten bij nader inzien een andere architectuur nodig hebben om succesvol doorontwikkeld te worden. Bij maatwerk software ontwikkeling gaan we dan over tot refactoring, een mooi woord voor het herontwerpen en -coderen van (een deel van de) reeds gemaakte software. En daar kan dat goed werken. Maar veel ontwikkeltrajecten die ik ken zijn niet puur maatwerksoftwareontwikkeling. Vaak moet er rekening gehouden worden met bestaande systemen die nu eenmaal werken zoals ooit gemaakt. Of een deel van het product bestaat uit ingekochte software die niet op stel en sprong door de leverancier wordt aangepast. Dan helpt vooruitdenken, aangezien je de innovatiesnelheid (of -traagheid) van de leverancier zult moeten volgen.

Just enough & just-in-time architectuur

Bij Trivento Spark! zoeken we naar het evenwicht, en zullen we alleen voor-denken over die zaken die er toe doen. Dus de architectuur niet verder uitdenken dan strikt noodzakelijk. Want ook hier geldt "..maximize the amount of work not done". Ga niet ontwerpen aan zaken die je nog niet kunt overzien, en zorg ervoor dat je architectuurbesluiten uitstelt tot het laatst mogelijke moment.

En ook al lijken bovenstaande inzichten vooral uit de software architectuurhoek te komen, vergis je niet. Ook binnen Enterprise Architectuur spelen deze afwegingen een rol. Zo biedt Sogeti's Dynamische Architectuur (DYA) aanpak letterlijk de vuistregel om just enough & just-in-time architectuur te ontwikkelen. Zoals je in onderstaande plaat kunt zien, kun je keuzes maken in zowel het aantal architectuurdomeinen dat je wilt uitwerken, en in de diepgang van ieder domein. Zoals algemene principes voor alle domeinen, concrete beleidslijnen (ik noem ze zelf SMART guidelines) voor een aantal domeinen en complete architectuurmodellen voor alleen de domeinen die dat echt nodig hebben. Want hoe lager je in deze tabel komt, hoe meer werk het is. En als je steeds meer (voortijdig) in details treedt, wordt de kans steeds groter dat je het (later) mag bijstellen.

DYA

Een andere "good practice" uit DYA is om missende architectuuronderdelen niet als architectuurteam uit te denken, maar te oogsten uit de resultaten van delivery projecten die toch lopen. Door principes en beleidslijnen mee te geven, kun je achteraf de ontwerpen weer oogsten. Want de steeds uitgebreidere privacy en compliancy richtlijnen resulteren in steeds meer documentatie. En daar valt dan weer lekker uit te oogsten.

Bijpraten over de bovenstaande ideeën?

Als Trivento hebben we veel ervaring met agile architectuur in verschillende ontwikkel- en voortbrengingsprocessen. Neem contact op voor een vrijblijvend gesprek over hoe we jouw organisatie hiermee verder kunnen helpen.

Dit artikel delen?

Ben je opzoek naar meer?

Bekijk hier een selectie van onze ebooks.

Digital Business met Microservices

Download nu

Van traditionele organisaties naar digitale winnaars

Download nu

Stappenplan voor digitaal succes

Download nu