Het uithoudingsvermogen van goed architectuur ontwerp

In een agile-wereld is architectuur geschiedenis, iets uit het verleden waar we met gemengde gevoelens aan terugdenken. Waarom hebben we architectuur nodig in IT-land? Dat is de vraag die Martin Fowler zich stelt in zijn keynote op OSCON. Of is dat iets te kort door de bocht? De vraag is interessant, omdat architectuur in agile geen grote rol speelt.

Het 11de principe van het Agile Manifesto gaat over de rol van architectuur: “The best architectures, requirements, and designs emerge from self-organizing teams.” Letterlijk vertaald: “De beste architecturen, vereisten en ontwerpen ontstaan uit zelforganiserende teams.”

Architectuur ontstaat?
Cruciaal is het woord “ontstaan”. Architectuur ontstaat. Ontstaat, dat voelt als iets passiefs. Iets wat je overkomt. Het klinkt een beetje als: zorg nou maar voor een zelf organiserend team, dan komt die architectuur vanzelf. Waarom dit principe? Om dit te snappen is het goed ons te beseffen dat het Agile Manifesto alweer dateert uit 2001. In die tijd was het gebruikelijk dat er vooraf een architectuur werd gemaakt. Die werd gevolgd door een gedetailleerd ontwerp van de op te leveren software. En een team moest dat daarna op die manier maken. Ook wel aangeduid met BUFD, Big UpFront Design.

Destijds zag men dat zo’n gedetailleerd ontwerp in de praktijk vaak niet de gewenste kwaliteit had. Het bood eenvoudig niet de gewenste flexibiliteit en onderhoudbaarheid. Of het is te flexibel, waardoor het toevoegen van nieuwe features veel complexe configuratie vereist. Of het is juist niet flexibel genoeg, waardoor nieuwe features veel impact hebben op bestaande code. Maar omdat er een gedetailleerd ontwerp ligt, is er een barrière om van dat ontwerp af te wijken. Het Agile Manifesto zegt eigenlijk dat het ontwerp moet ontstaan, gedreven door de wensen in het project. Hoe complexer de wensen, hoe complexer het ontwerp zal worden. De balans tussen flexibiliteit en onderhoudbaarheid wordt vanzelf opgezocht.

Vanzelf?
Maar ontstaat die architectuur en dat ontwerp nu vanzelf? Kunnen we in een team gewoon aan de slag gaan en via de kortst mogelijke route wensen implementeren en dan verwachten dat we het juiste ontwerp krijgen?

Nee, en dat is ook niet wat het principe uit het Agile Manifesto bedoelt. Een goed ontwerp is wel degelijk hard werken. Maar het is niet iets dat je in één keer vooraf doet, het is een activiteit die uitgesmeerd wordt over de hele duur van het project. En stapsgewijs uitgevoerd wordt, gestuurd door de situatie. Steeds als er een nieuwe eis is geïmplementeerd, wordt gekeken hoe het ontwerp aansluit bij de behoefte. En hoe dat geoptimaliseerd kan worden. Door refactoring worden het verbeterde ontwerp meteen doorgevoerd.

Het nut van aandacht voor design blog

Daarmee ontstaat wel een nieuwe vraag. De vraag of die refactoring wel zo nodig is. Kunnen we het ontwerp niet echt laten ontstaan? En daarmee komen we terug bij de keynote van Martin Fowler. Hij toont een grafiek uit zijn blogartikel met de titel “Design Stamina Hypothesis”, de ontwerpuithoudingshypothese. Hoewel niet door cijfers onderbouwd, beschrijft Martin hier de hypothese dat software die niet bewust ontworpen en verbeterd wordt, uiteindelijk leidt tot het langzaam vertragen van het creatieproces van nieuwe eisen. Software, die ontstaat zonder aandacht voor ontwerp, zal volgroeien met Technical Debt.

image

Wat geldt voor software geldt voor het hele IT-landschap
Deze curve geldt niet alleen voor software design, maar ook voor Enterprise Architectuur. Als je geen aandacht geeft aan de samenhang van het geheel van bedrijfsprocessen, applicaties en systemen, dan ontstaat een systeem dat suboptimaal functioneert. Denk aan organisaties die hun applicatielandschap laten groeien zonder plan. Die er voor kiezen om voor elke behoefte een tool in te zetten die het beste past bij die behoefte, zonder het totaalplaatje te beschouwen en bij te sturen. Elk volgende vraagstuk wordt complexer, omdat een netwerk van afhankelijkheden onzekerheid introduceert.

Zet dat af tegen organisaties die hun (veranderende) bedrijfsprocessen en -functies in beeld hebben en begrijpen hoe hun applicatielandschap dat ondersteunt. Organisaties die voortdurend evalueren hoe dat applicatielandschap er optimaal uit ziet en daar op bij sturen. Die iets meer tijd nemen om een functie in een bestaande applicatie onder te brengen in plaats van de introductie van een nieuw tooltje. Die daarmee complexiteit verminderen en dus wendbaarder worden.

Software architectuur en ontwerp zorgt er voor dat onze software beter aansluiten bij de behoefte, Enterprise architectuur zorgt voor een actueel, flexibel en beheersbaar applicatielandschap. Zonder die aandacht vertraagt de organisatie totdat het zichzelf uit de markt geprezen heeft.

Hoe agiler de wereld, hoe belangrijker architectuur.