Hoe concreet of abstract moet een architectuur zijn?
Alcedo Coenen
Een architectuur (enterprise, business, informatie, applicatie, technische etc.) kan zoals bekend op drie soorten verschijningsvormen duiden:
- een voorschrift of “voorschrijving”: een reeks voorschriften over hoe een enterprise samenhangend in elkaar zou moeten zitten.
- een naschrift of beschrijving: een overzichtelijke beschrijving van hoe de samenhang van een enterprise in elkaar zit.
- een verschijning: hoe een enterprise en haar samenhang zich daadwerkelijk manifesteren en worden ervaren.
Architectuur Waarde Meting
Architectuur in de voorschrijvende vorm is meestal bedoeld om een verandering te beginnen en om de verandering te voorzien van de nodige voorschriften. De kwaliteit van zo’n voorschrift is sterk afhankelijk van twee factoren:
- de bruikbaarheid van die voorschriften
- de verbinding tussen de voorschriften en de veranderdoelen.
De door Solventa ontwikkelde Architectuur Kwaliteits Meting is een instrument om de kwaliteit van een voorschrijvende architectuur te meten in termen van bruikbaarheid en doelbinding. Daarvoor is een aantal criteria en vuistregels verzameld die uit de praktijk komen van het maken en beoordelen van architecturen. In verschillende achtereenvolgende blogs zal telkens één zo’n set vuistregels worden toegelicht.
In deze blog sta ik stil bij de mate van concreetheid en abstractie. Het is intuïtief meteen te begrijpen dat voorschriften die te abstract zijn het nadeel kunnen hebben dat ze niet bruikbaar zijn voor de mensen die de voorschriften moeten volgen (de “ontwerpers”). Met “ontwerpers” bedoel ik niet alleen IT-engineers en informatie-analisten, maar ook verandermanagers en procesontwerpers. Een plaatje als het volgende zal weinig vertrouwen wekken bij de “ontwerpers”.
Voorbeeld dat te abstract is voor bouwers
Om bruikbaar te zijn voor ontwerpers moeten de gebruikte concepten op zijn minst worden gedefinieerd, en moeten de relaties die met andere concepten worden gelegd concreter benoemd worden. Bovendien hebben ontwerpers meer detail nodig om bijvoorbeeld de service “Request handling” te kunnen ontwerpen. Op dezelfde manier is te begrijpen dat een architectuur die te concreet is uitgewerkt, voor de ontwerpers misschien wel goed te volgen is, maar voor de beslissers, die een overzicht willen hebben en op de realisatie (verandering) willen sturen, veel te onoverzichtelijk. Bijvoorbeeld:
Balans
Voor de bruikbaarheid van architectuur is het dus zaak om een delicate balans te bereiken tussen concreetheid en abstractie. De balans kan ook naar andere kant doorslaan: als de specificatie te veel in detail is uitgewerkt, mag dat voor de bouwers comfortabel zijn, maar dan is er sprake van een detail-ontwerp en niet meer van architectuur. Het nadeel daarvan is dat de ontwerper geen ontwerp-vrijheid meer heeft, en de architectuur te specifiek wordt zodat die te snel moet worden aangepast als er omstandigheden wijzigen. Zo kan een architectuur ook zo abstract zijn, dat het voor beslissers geen handvaten meer biedt voor zinnige beslissingen. De gebruikelijke best practice om deze balans te bereiken is door beide doelgroepen (de beslissers en de ontwerpers) apart te addresseren met hun eigen architectuur-ontwerpen en toelichtingen. De architectuur wordt dan als het ware een tweeluik, met voor elke doelgroep een aparte ingang.
