Diagnose, Ontwerp en Verandering

De kracht van een beeld

Goed inzicht in een product of dienst zonder misverstanden is cruciaal. Maar hoe komt het toch dat veel afbeeldingen gemaakt door architecten uitblinken in enorme doolhofplaten of afbeeldingen die vroeg of laat leiden tot verkeerde conclusies?

Een afbeelding hoe applicaties voor een mobiele telefoon werken is redelijk complex. Toch is het noodzakelijk om via een visualisatie eenvoudig de verschillende onderdelen weer te geven. Vanuit deze visualisatie is ook direct duidelijk wat kan en wat beter moet vanuit architectuur.

FirefoxOS

 

Vanuit bovenstaande afbeelding is te zien hoe applicaties gemaakt met FirefoxOS gebruik maken van de Operating Systeem functies en hardware devices van een mobiel.  Voor technische architecten is direct te zien  hoe FirefoxOS applicaties gebruik kunnen maken van allerlei mogelijkheden die een mobiele telefoon kan bieden, zoals GPS of camera. Dit geeft ook direct een startpunt voor de beveiligingsarchitectuur van FirefoxOS applicaties en risico’s die door ontwikkelaars geïntroduceerd kunnen worden. De kleuren en pijlen geven de relaties in de gelaagde opbouw aan. Bovenstaande plaat is een technisch overzicht vanuit architectuur waaruit een ontwikkelaar kan zien hoe zijn applicaties gebruik kan maken van onderliggende technologie.

Cruciaal bij het maken van een visualisatie is het bepalen van het doel van een model.  De kracht van een model ligt nog altijd in hoe gewenste modeldoelstellingen gevisualiseerd worden. Voor visualiseren zijn afhankelijk van het doel van het model weinig regels. Zo is het mogelijk om gebruik te maken van Rich pictures , maar een visualisatie kiezen die aan veel regels voldoet kan soms ook zeer handig zijn. Bijvoorbeeld een UML deployment model of een Archimate 2.0 model.

Een goede visualisatie heeft vaak de volgende kenmerken:

  • Verschillende doelgroepen ‘lezen’ het model op dezelfde wijze.
  • Is eenduidig in bij keuze voor abstractie niveau (‘kunst van het weglaten’)
  • Conceptueel, logisch en fysieke modellering lopen niet door elkaar.

Binnen de IT architectuur gebeurt het wel eens dat doel en middel worden omgedraaid. Vooral wanneer het aankomt op het visualiseren wordt vaak veel nadruk gelegd op middel, bijvoorbeeld modeltaal, tekenwijze of ‘een wonder-teken-pakket voor alle problemen’. Pas hier voor op.

Complexe problemen laten zich niet altijd eenvoudig visueel weergeven. Iedere probleemsituatie is uniek en juist dit gegeven maakt dat het vooraf modelleren via een standaard wijze niet altijd tot oplossing van de problematiek leidt. De kracht van een visualisatie is vaak dat de belangrijke stakeholders beter in staat zijn om hun bijdrage in het geheel te zien. En vervolgens het proces richting probleemoplossing beter vorm gegeven kan worden.

Een vorm om complexe problemen weer te geven is via modelleer hulpmiddelen vanuit de systeemdynamica. Hieronder een voorbeeld van de schets van een regionale woningmarkt.

 

 houdini woningmarkt model

 

Deze afbeelding vereist uitleg aangezien de specifieke pijlen en tekens in een SD diagram niet algemeen bekend zijn. Gevaar is dan dat verkeerde conclusies vanuit een goed model worden getrokken.

De wijze waarop modellen verkeerd kunnen worden geïnterpreteerd is een gedeelde verantwoordelijkheid: Natuurlijk ligt de primaire verantwoordelijkheid bij het visualiseren van een model natuurlijk bij de architect of ontwerper. Maar een model mag natuurlijk nooit gebruikt worden als vervanging van het kritisch denken over een situatie. Dit geldt voor technische afbeeldingen en conceptuele afbeeldingen. Stel altijd kritische vragen: Wat zeggen pijlen? Hoe werkt het systeem nu écht? Wat is weggelaten en waarom?

Een goed model helpt om de beoordeling in een bepaalde situatie scherper te krijgen. De intuïtie wordt getest en ook mentale denkbeelden kunnen worden aangescherpt vanuit een model. Maar een dialoog blijft cruciaal om complexe problemen daadwerkelijk te kunnen oplossen.