Architectuuroverzichten op A3’s helpen om de toenemende complexiteit van systemen behapbaar te houden, zegt Gerrit Muller. De werkwijze is echter alleen weggelegd voor ervaren systeemarchitecten. Muller houdt een pleidooi voor werken met A3’s en schetst voordelen, maar ook valkuilen.
Hoe verbeter je de wereld? In kleine stappen. Hoe maak je systeemarchitecten slagvaardiger? Door ze een klein, maar effectief gereedschap aan te reiken. Gerrit Muller sprak afgelopen november op de Bits&Chips Smart Systems-conferentie over het nut van overzichten maken op A3’s – vellen papier van 297 bij 420 millimeter. Muller is hoogleraar aan de University of South-Eastern Norway in het Noorse Kongsberg en is een dag in de week verbonden aan TNO-Esi. Systeemarchitecten maken volgens hem te weinig gebruik van architectuuroverzichten op A3, maar het helpt volgens hem echt om de complexiteit beter de baas te kunnen.
Muller zou Muller niet zijn als hij niet meteen ook vraagtekens zou zetten bij zijn eigen stelling. ‘Is dit de heilige graal, de silver bullet?’, vraagt hij zich af over het hulpmiddel dat hij aanreikt. ‘Als dit de oplossing is voor alle kwalen, dan zouden de meeste systeemarchitecten allang dit soort A3’s maken. Ik weet dat een paar mensen het doen, maar veel minder dan nuttig zou zijn. Ik denk dat het voor ieder bedrijf waarde heeft om architecture overviews op A3 te maken.’
Toch is Muller best stellig. Als systeemarchitecten overzichten maken op A3’s en op verschillende abstractieniveaus, dan slagen ze er beter in om de ingewikkelde systemen te maken die ook werkelijk functioneren in die buitenwereld.
Software apocalypse
Het centrale probleem is ieder bekend: we ontwikkelen systemen die ons intellectuele vermogen te boven gaan. De systeemarchitect moet grip en overzicht houden op die uitdijende complexiteit. Hij moet er ook voor zorgen dat het systeem in complexe omgevingen functioneert. ‘Dat is de kern’, zegt Muller. ‘We maken systemen die we niet meer begrijpen.’
Muller wijst op een vorig jaar herfst verschenen artikel in The Atlantic met de verontrustende titel ‘The coming software apocalypse’. In dat stuk staat dat coderen, een vijftig jaar oude werkwijze, ons beperkt. ‘Als we een systeem ontwerpen en programmeren, dan zijn we bezig met regeltjes neerschrijven. Maar dat is helemaal niet wat we willen. We willen een systeem dat specifiek gedrag gaat vertonen.’
Het is volgens Muller belangrijk dat we ons daar een voorstelling van kunnen maken. Dat we snappen wat er kan gebeuren. ‘Ik geef veel les aan techneuten. Vaak zijn ze analytisch heel goed, maar ze hebben hun fantasie in hun kindertijd achtergelaten. Terwijl verbeelding verschrikkelijk bruikbaar is als je complexe systemen ontwerpt. Dat je je kunt voorstellen dat er plots een kind kan oversteken voor de autonome auto die je aan het ontwikkelen bent.’
Beheersbare brokken
Voor overzicht hebben mensen beheersbare brokken nodig. Daniel Borches ontwikkelde er een kleine tien jaar geleden tijdens zijn promotie op de Universiteit Twente een methode voor. Hij werkte destijds ook bij Philips aan mri-scanners. Borches stelde voor om overzichten op een A3 te maken. Die moesten dan de belangrijkste views bevatten: overzichten van onderdelen en verbindingen, het dynamische gedrag en de eigenschappen. Muller: ‘Dat is het kernidee van een architecture overview: iets verteerbaars. Een A3 is niet groot, je laat plaatjes en grafieken zien en je mag geen 6-punts letters gebruiken, maar gewoon 12-punts fonts. Dat dwingt je om je te beperken en datgene te tonen dat essentieel is voor het onderwerp.’
In organisaties wemelt het meestal van de plaatjes. Vaak zijn die statisch: blokdiagrammen met een hiërarchie. ‘Op die overzichten stikt het van de onderdelen. Allemaal componenten met hun verbindingen en interfaces om te zien hoe alles aan elkaar vastzit’, aldus Muller. ‘Wat die overzichten niet vertellen, is hoe het werkt. Hoe die dingen met elkaar interacteren. Dan heb je het over dynamisch gedrag.’
Dynamisch gedrag uitbeelden is inzichtelijk maken hoe de boel werkt. Bij een autonoom rijdende auto heb je het dan over de manier waarop het systeem zich met vele sensoren een beeld vormt van de omgeving. De rijrichting is bekend, de wagen classificeert drempels, paaltjes, voetgangers, fietsers, enzovoorts en kiest aan de hand van zijn wereldmodel een route en snelheid.
‘In heel veel organisaties kun je in de documentatie nauwelijks informatie vinden over dynamisch gedrag’, is Mullers ervaring. ‘Als je het vraagt, dan pakken mensen een statisch plaatje en gaan ze wijzen: ‘Kijk, ik heb hier een sensor, van daar gaat het naar die ecu. Die doet iets magisch en dat is dan de uitkomst … Al pratend en wijzend vertellen ze hun verhaal.’
Mullers boodschap is om dat ondersteunende verhaal – de dingen die meestal niet op papier staan – te visualiseren. Dat betekent de belangrijkste interacties vangen in een paar modellen, vooral om aan de hand daarvan het gedrag te beredeneren en uit te leggen. ‘Als we het iets anders doen, wat gebeurt er dan? Wat kunnen we dan verwachten?’, somt Muller de vragen op die daarbij zullen opduiken. Er zit volgens hem ‘wel wat naars aan’. Het dynamische gedrag is nooit helemaal te vangen; er zijn per definitie oneindig veel opties. ‘Dus moet je een selectie maken van het belangrijkste dynamische gedrag.’
Stabilisatiesysteem
Het dynamische gedrag bepaalt de functionaliteit, maar uiteindelijk gaat het om een derde laag: de kwaliteiten. Hoe goed werkt het systeem? Hoeveel kan het verwerken? Slimme systemen moeten ook betrouwbaar, veilig en inbraakbestendig zijn. Muller: ‘Herkent de auto met zekerheid een mens? Welke kant loopt hij op? Hoe betrouwbaar is die uitkomst? Hoe vaak is die conclusie fout? Hoe vaak voorspelt het systeem dat die voetganger op de stoep blijft, terwijl die er toch van afstapt?’
‘De meeste mensen, eigenlijk hele organisaties, denken statisch in onderdelen en komen tot een specifiek gedrag. Ontwerpers willen weten wat de false positives en false negatives zijn. Ze willen getalsmatig nadenken over hoe goed hun systeem is. Daarmee kunnen ze een kwaliteit toeschrijven aan het gedrag. In feite is dát ook waar de klant in geïnteresseerd is en dat is waar de systeemontwerper voor verantwoordelijk is.’
Muller heeft de ervaring dat heel veel managers hun architecten aanspreken op de decompositie en interfaces. Maar in feite gaat het daar volgens hem niet om. ‘Ik zeg: je moet eigenlijk kunnen uitleggen hoe die dingen samen leiden tot een betrouwbaar systeem. Dat je een autonome auto hebt ontworpen die geen voetgangers of andere auto’s aanrijdt en je ook snel van a naar b brengt. Dat is de kern.’
Kristian Frøvold, een student van Muller, gebruikte A3-overzichten om een ankerbesturingssysteem voor boorplatforms te beschrijven. Hij deed dat voor het Noorse Kongsberg Maritime, een automatiseerder in de scheepvaart en specialist in systemen om vaartuigen op zee in extreme omstandigheden op een stabiele positie te houden. Bij Kongsberg hadden ze bedacht dat ze hun stabilisatiesysteem ook konden gebruiken voor anchor handling, grote gevaartes om booreilanden op hun plaats te houden.
Frøvold werkte het idee in een paar maanden uit op A3-overzichten. Aan de hand daarvan evalueerden ze bij Kongsberg het systeem. Muller: ‘Kernuitkomst was dat anchor handling een leuk idee was. Maar met het oorspronkelijke idee en ontwerp zou de klant uitermate ontevreden zijn geweest. Daar kwamen ze pas achter door het helemaal uit te denken en te bespreken aan hand van A3-overzichten. Door vragen te stellen, realiseerden ze zich dat ze een gebrek aan marktfocus hadden en dat hun methode te snel en te makkelijk was. Daar hebben die A3’s dus echt geholpen.’
Grachten en gridpatronen
Allemaal mooi en aardig, maar voor veel mensen zijn architectuuroverzichten toch slechts blokken en lijntjes op een heel hoog abstractieniveau. Je hebt er weinig aan, want er blijft altijd wel een of ander duivels detail verborgen waardoor de boel in de praktijk toch niet werkt. Mullers antwoord: zorg dus dat je het juiste detail in je architecturele denkproces opneemt. ‘Maar hoe doe je dat in systemen die miljoenen tot honderden miljoenen details hebben?’, vraagt Muller zich hardop af. De oplossing die hij aandraagt: neem de meest kritieke details mee. Hoe? ‘Een deel van het antwoord is werken met meerdere abstractieniveaus en zorgen dat je verbanden legt tussen de details en het hele systeem.’
Een typische systeemspecificatie voor een product heeft duizend details. Data- en factsheets leggen uit wat het systeem kan en doet. Bij de meeste organisaties zit dat in cadsystemen en managementsystemen voor broncode. Alle boutjes, moertjes en statements staan in databases. ‘Het gaat makkelijk om tien miljoen tot een miljard details om het statisch te beschrijven. Alleen de ervaren rotten weten hoe ze daarmee de gewenste systeemeigenschap bereiken. Ze kennen de onderdelen en softwaremodules om het voor elkaar te krijgen. Meestal kost het wel veel pijn om dat te realiseren. In werkelijkheid is het probleem veel groter, want de meeste bedrijven maken niet één systeem, maar een hele familie.’
Architecten moeten dealen met complexe systemen, maar vooral met complexe omgevingen. Als mensen zijn ze in staat om dat te vereenvoudigen. Ze classificeren wandelaars, fietsers en autobestuurders, wellicht in enkele varianten, zodat ze er beter over kunnen nadenken. ‘We definiëren een paar stakeholders en hun eigenschappen en dat linken we dan aan het systeem. Maar al die stakeholders zijn individuen met hun eigen karakteristieken. Dat maakt dat de wereld vele malen complexer is met veel meer details, dan de systemen zelf’, aldus Muller.
Systeemarchitectuur is die zeer complexe buitenwereld en complexe binnenwereld aan elkaar koppelen. Muller: ‘Architectuur is in essentie dat ik begrijp dat Delft een stad is met bruggetjes, grachten, nauwe straatjes en huizen en dat ik een autonome auto moet maken die onder die omstandigheden moet kunnen rijden, maar net zo functioneert in Phoenix met al zijn gridvormige straatpatronen.’
Bij het combineren van de buiten- en binnenwereld blijft de architect heel vaak op een hoger abstractieniveau. ‘Aan beide kanten, bij de stakeholders en systeemeigenschappen, zijn er die kleine details die je even mee moet nemen. Echte systeemarchitecten ruiken de details die ertoe doen. Als iets cruciaal is, nemen ze dat op een hoger abstractieniveau mee.’
Gasturbines
Daarmee komen we terug op Mullers advies: werken met meerdere abstractieniveaus en verbanden leggen tussen de details en het geheel. Hij raadt aan om voor het hoogste niveau slechts één A3 te maken. Dit overzicht legt uit hoe het systeem met de stakeholders werkt. ‘Daarop kun je wellicht wat details uit de buitenwereld meenemen en alvast anticiperen op details in de binnenwereld. Bij een autonoom rijdende auto weet je dat er lidar, radar en video in zit en dat zon, regen en wind een rol spelen. Dag of nacht ook, want je maakt beelden van de omgeving.’
Op een hoogniveau-A3 is het systeem nooit helemaal te mappen. Muller: ‘Daarom zet je elke kwaliteit ook uiteen op een A3. Je legt daarop uit hoe je veiligheid, security, betrouwbaarheid, enzovoorts bereikt. Dat kun je dan verder uitwerken in A3’s waarbij je technisch uitlegt hoe je dat voor elkaar gaat krijgen.’
Muller wijst als voorbeeld naar de studie van Vickram Singh. Deze student maakte A3-architectuuroverzichten voor gasturbines. De A3’s waren bovendien dynamisch: via hyperlinks kon je erdoorheen klikken.
De turbinefabrikant waarvoor Singh dat deed, was gewend om het systeemontwerp te vatten in piping and instrumentation-diagrammen. ‘Dat is de manier waarop de hele industrie werkte. Als je dan vragen stelt als: ‘Hoe komt het systeem op gang?’ en ‘Hoe kom je van geen druk naar een beetje druk?’, dan blijkt ineens dat je in het begin een oliecircuit nodig hebt dat ervoor zorgt dat je bij de start druk kunt opbouwen. Een mechanisme dat de boel op gang brengt. Zonder drukopbouw gaat het niet werken, maar die verschillende stadia kon je niet aflezen uit de piping-diagrammen.’
Singh werkte de stadia uit die het systeem doorloopt van starten tot stoppen. Er bleken een aantal relevante modes te zijn: de druk loopt op in het systeem, de turbine komt op gang, opereert onder druk en bouwt weer af. De bijbehorende drukprofielen in de tijd liet Singh ook terugkomen in een van de overzichten.
De overzichten overtuigden het bedrijf ervan om acht wijzigingen in het systeemontwerp aan te brengen, vertelt Muller. ‘Aan de hand van de A3’s konden we simpelweg doorvragen. Hoe werkt dit? Hoe werkt dat? Op welke manier komt het systeem op gang? Op welke manier draait het? Wat is de functie van dit deel?’ Met de acht wijzigingen bereikte de leverancier een hoger kwaliteitsniveau. ‘Dat is de waarde van het maken van die A3’s.’
Minder technisch
Het lijkt te mooi om waar te zijn: ga met een paar A3’s aan de slag en je houdt grip op de complexiteit. Waarom worden ze dan toch zo weinig toegepast? Welke drempels zijn er? Muller denkt dat een gebrek aan ervaring meespeelt. ‘Maar weinig mensen begrijpen de context tussen systeemdetails en buitenwereld. Dan blijven de A3’s die ze maken oppervlakkig. Ze zien er mooi uit, maar dekken de lading niet. Het dynamische gedrag en de kwaliteitsattributen worden vaak niet volledig begrepen.’
Ook vraagt de aanpak rust en een begrip voor de noodzaak om de oefeningen te doen. Met snel een A3 maken kom je volgens Muller vaak tot verkeerde oplossingen. ‘Ik zie ook dat heel veel mensen niet makkelijk visualisaties kunnen maken. Zinnige plaatjes die uitleggen hoe het werkt. Dat heb je wel nodig, want anders werkt die hele A3-aanpak niet.’
Mullers conclusie is dat werken met architectuuroverzichten een simpel en krachtig middel is dat helpt om met complexiteit om te gaan. ‘Maar je hebt wel de vaardigheden van een systeemarchitect nodig. Dat betekent dat je de dingen goed moet kunnen visualiseren, conceptueel moet kunnen denken en kunt inzoomen en uitzoomen. Dat je details moet kunnen bekijken en het grote plaatje moet kunnen zien en het systeem vanuit alle kanten moet kunnen pakken.’
Muller sluit zich aan bij Ger Schoeber, die in een interview met Bits&Chips uitlegt dat systeemarchitectuur minder technisch is en veel meer businesscontext bevat dan de meeste mensen zich realiseren: ‘Ja, het is ook technisch, maar het gaat om het begrijpen van die veel bredere context.’