Insights & Data Blog

Insights & Data Blog

Meningen op deze blog weerspiegelen de opvattingen van de schrijver en niet per definitie die van de Capgemini Group

De schoonheid van architectuur

Categorie: BIM
De schoonheid van architectuur
 
Functionaliteit, degelijkheid en schoonheid zijn volgens de Romein Vitruvius de drie principes van architectuur voor de gebouwde omgeving. Ruim 2000 jaar later zijn ‘functionaliteit’ en ‘degelijkheid’ ook passende principes van ICT architectuur. Maar wat is een passend alternatief voor ‘schoonheid’? Esthetisch? ‘Een sexy oplossing’ klinkt niet professioneel, maar bij een echt goede oplossing kan dat wel aangeven wat iemand er van vindt.
Of is ‘schoonheid’ niet van toepassing en gaat het vooral om de acceptatie van het resultaat? Wat kan een architectuurmethode daaraan bijdragen? En is dat zichtbaar te maken?
 
Er is een groot verschil tussen de traditionele architectuur en de IT architectuur: het grootste deel van een IT-oplossing is voor velen niet zichtbaar. Daarnaast heeft iedere stakeholder een rol-eigen ‘kijk op de zaak’. Dit maakt een gesprek over ‘de’ architectuur al gauw complex.
 
Een rapport kan er mooi of strak uitzien. Wat maakt bij oplevering dat de opdrachtgever de oplossing accepteert?
Bij een klant hoorde ik dat het 2 weken kostte voordat de juiste kleur oranje werd weergegeven. De kleur was wel heel belangrijk! Een aanpassing van het beeldscherm bleek de oorzaak en de oplossing te zijn. Bij een andere klant moest de kolom LAND niet als laatste, maar als eerste kolom in de invoertabel. De klant had daar ook een aantal goede argumenten voor. Maar tijdens de requirements analyse was daaraan nietgedacht.
Anders dan in veel methoden die ik ken, heeft de fase ‘acceptatie’ een duidelijke plek in de methode DEMO (Design & Engineering Methodology for Organizations). Volgens DEMO wordt in deze fase het transactieproces tussen opdrachtgever en uitvoerder afgesloten, of juist hervat. De set aan requirements aan het begin van het transactieproces biedt geen garantie voor succes van het op te leveren resultaat. Veel requirements zijn aan het begin vaak ook niet volledig. Deze moeten dus nader besproken worden. Communicatie is dus belangrijk.
 
Vaak zijn er diverse stakeholders tegelijk betrokken en moet de gevraagde oplossing passen in zowel de context van de business als in de technische context. Vanuit de architectuur worden daarnaast allerlei algemenere principes aangedragen die, met reden, er aanvullend voor moeten zorgen dat de oplossing past binnen de organisatie. Het resultaat: een lange lijst functionele, non-functional en technische requirements.
 
Door de betrokkenheid van alle stakeholders en door de lange lijst van requirements lijkt de complexiteit alleen maar toe te nemen. En daardoor wordt de architectuuraanpak zelf gauw het onderwerp van discussie. In mijn beleving leidt een goede architectuuraanpak echter leidt niet tot complexiteit, maar maakt de complexiteit zichtbaar! Ook dat vereist goede communicatie.
 
Om de aanpak en de lijst van requirements in beter behapbare blokken op te bouwen, onderscheidt men in de architectuur diverse lagen en domeinen. Vaak zijn dergelijke indelingen vastgelegd in een zogenoemd framework. Vrijwel elke architectuurmethode heeft z’n eigen framework. Enkele voorbeelden van lagen: business laag, applicatie- en data laag en infrastructuur laag. Het domein Security en Governance krijgen ook een plek.
Net als frameworks biedt ook de architectuur modelleertaal Archimate een verdieping van elk van bovengenoemde lagen: de actieve componenten en structuren, gedragsconcepten (zoals functionaliteit en interactie) en de passieve entiteiten (data oriëntatie).
Ik vind deze indeling van een bepaalde ‘schoonheid’ getuigen, voor mij een eye-opener, omdat je hiermee wordt aangezet om helder te maken welke soort eigenschap van een object je bekijkt: het object zelf, z’n functionaliteit en gedrag of de data die ermee gemoeid is. Met deze nuancering kan miscommunicatie worden voorkomen omdat het vraagstuk vanuit verschillende invalshoeken kan worden bekeken.
Denk bijvoorbeeld aan het gebruik van een excel sheet. Het kan dienen als rapport, het kan gebruikt worden om berekeningen sneller uit te voeren maar ook om data in op te slaan of om data mee uit te wisselen (bijvoorbeeld als csv-file).
 
Nu het totale probleem is opgesplitst, zijn er per deelgebied veel minder stakeholders betrokken. De kans is groter dat de communicatie soepeler verloopt en effectiever is. Als alle niet relevante informatie uit de andere gebieden buiten beschouwing blijft, ontstaat er meer ruimte voor de essentie per gebied: het gaat erom de juiste beslissingen te maken en het overzicht te bewaren.

De kunst is om het overzicht zichtbaar te maken, visuele communicatie.
En is deze functioneel, to the point en van een bepaalde schoonheid, dan kan ik daarvan genieten!

Over de auteur

Frank Fledderus
Frank Fledderus
Sinds 1997 ben ik werkzaam geweest bij diverse klanten in verschillende sectoren. Daardoor heb ik veel ervaring opgedaan met architectuur, informatie analyse en business intelligence. En mijn nieuwsgierigheid zorgt ervoor dat dat nooit verveelt!

Plaats een reactie

Uw e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *.