Lichte architectuur door onderscheid tussen vorm en structuur

Volgens de woordenboeken is "vorm" de zichtbare, uiterlijke gedaante van onderdelen die een samenhangend geheel zijn. Het verschil met "structuur" is subtiel en heeft betrekking op de complexe interne samenstelling ofwel de manier waarop een samengesteld geheel is opgebouwd.

Wat het IT architectuurwerk zo onnodig complex maakt is dat we ons bij initiële creatie van architectuur - dit betreft zowel enterprise als onderliggende vormen - onnodig bezighouden met structuur in plaats van enkel vorm. De meesters van dit onderscheid creëren geen BUFD (Big Up-Front Designs) en maken architectuur dat voor iedereen begrijpelijker is. De vorm is het wat en waarom. De structuur is de hoe.

Voorbeeld van een BUFD:
De klant wenst een niet te grote, stoere auto om voornamelijk mee op vakantie te gaan. De architect (of een SCRUM team) neemt besluiten over de exacte motor, aandrijving op achterwielen, neon koplampen, tank van 70 liter, technologie om dashboard informatie te tonen, enzovoort. Voor de klant zijn meeste van deze besluiten niet relevant. De klant haakt op architectuurvlak af door het gebrek aan inzicht wat en waarom iets relevant is voor de wensen die zij heeft.

Voorbeeld van een lichtgewicht architectuur:
Iemand gaat in gesprek met de klant en het onderhoudsbedrijf om meer informatie achter hun wensen te krijgen. Met die extra informatie maakt men een schets van de auto (rood, grote glimmende wielen, bijzondere koplampen) en een doorvertaling van de wensen naar de exacte kwaliteits requirements:
- op zijn minst 1000 km met een volle tank kunnen reizen
- 70 liter bagageruimte
Het opgeleverde document is een visiedocument dat iedereen tot de verbeelding spreekt, maar niet concreet aangeeft hoe ieder aspect moet worden ingevuld. Men moet nog per aspect over de structuur nadenken, voortdurend besluiten nemen en met elkaar afstemmen hoe die ingevuld worden.

De vorm van structuur niet kunnen onderscheiden heeft in praktijk vervelende gevolgen. Bij het ontbreken van de vorm gaat iedereen onbewust een eigen beeld vormen. Hoe kun je anders nadenken over welke afmetingen de motor moet hebben als je niet een aanname doet over de grootte en vooral de vorm van de totale auto? Er ontstaan vervolgens discussies over de structuur met allemaal verschillende vormen. Zolang discussies over architectuur verlopen als een complete geheel van zowel vorm als structuur, is er waarschijnlijk niemand die alles kan behappen. De gevolgen zijn geloofsdiscusies, denkfouten en gebrek aan realiteit en samenhang. Bij complexe business problemen zijn mensen geneigd om vooral complexe oplossingen te bedenken, zogenaamde "just-in-case" architecturen. Waarom doet men dat? Ze kunnen het simpelweg niet overzien. De enige oplossing lijkt dan het wegabstraheren van technische uitdagingen door middel van steeds meer out-of-box technologie. Deze neiging is des te sterker als de architect weinig gevoel heeft met de werkelijkheid van systeemontwikkeling.
Hetzelfde geldt voor zelfsturende teams waarin architectuur geleidelijk ontstaat. De besluiten worden of vanuit de lokale gezichtspunt genomen met ook nog de beperkte vooral specialistische kennis. Er is dan gebrek aan samenhang, rationale en koppeling naar stakeholders.

In principe worden architecten al gevraagd om vooral over vorm na te denken. Het is die opmerking van een IT-manager: Ik kan je niet meer volgen, mag ik van jou een jip-en-janneke plaatje. Hij vraagt hier eigenlijk om een vorm. IT-manager wil weten wat hij krijgt, en niet hoe het werkt. Helemaal mooi zou zijn als de architect vooral over de invulling van stakeholdersbelangen zou praten en daarmee de vorm zelf in communicatie een bijzaak wordt.
De praktijk is echter dat veel architecten vanuit engineering komen. Het is hun comfort zone. In engineering draait alles om het structuren en structuren of specialisatie op een specifiek technologie of een cross-cutting concern zoals performance. Het is dan bijzonder lastig om de details van structuren los te laten en vooral te hebben over de essentie: "Beste klant, u heeft een Alfa Romeo 159 station nodig met deze snelheid, zachte veringen en stoelen, zoveel bagageruimte, enz. En dat wij 70 liter tank inbouwen is een bijzaak. Het gaat erom dat u met een tankbeurt meer dan 1000 km kunt afleggen.

Tegelijkertijd kan de vorm voor een persoon de structuur voor een ander zijn. Dit heeft te maken met zogenaamde “viewpoints”. Voor een procesarchitect is de vorm een samenhang en een globale definitie van alle business processen, terwijl voor een systeemarchitect de automatisering van een specifiek business proces of zelfs slechts een stap in dat business proces de vorm is. Een architect zou zich in principe met enkel 1 niveau van vorm tegelijkertijd bezig moeten houden. Dat is namelijk al voldoende complex.

Het meest bijzondere voordeel van het onderscheid tussen vorm en structuur heeft te maken met de stelling dat architecten niet nodig zouden zijn. Architecten lopen in de weg wanneer een klant zo snel mogelijk bediend wordt. De reden waarom architecten dan alleen tot last zijn is omdat zij zich bezighouden met zaken die engineers nog beter kunnen. Ze houden zich bezig met de structuur in plaats van de vorm, de invulling van stakeholdersbelangen en de rationale.

Viktor Grgic, www.leanarch.eu