ICT-trajecten hebben baat bij een gedeeld beeld tussen de betrokken partijen – figuurlijk, maar ook letterlijk. Een goede visualisatie drukt dat beeld uit in relevante concepten die alle betrokkenen begrijpen.
Die relevante concepten variëren per geval. Soms gaat het om processen, soms om systemen of servers. Soms gaat het om heel specifieke zaken, zoals de ‘brandweer- en ambulancekolom’ of ‘het risico op botsingen tussen treinen’. Zulke situatie-afhankelijke concepten zijn cruciaal voor een gedeeld beeld over het nu en de toekomst. In een visualisatie moet de weergave van zo’n concept dan ook voor zichzelf spreken. Als ‘boef’ een relevant concept is, dan moet er ook een boef op de plaat staan en niet een rechthoekje met een cilindersymbool en het woord ‘boef’ erin.
ICT-architecten gebruiken vaak architectuurtalen om zulke visualisaties te maken. Belanghebbenden moeten meegaan in de concepten, abstracties en verbanden die uit het conceptueel raamwerk en meta-model van zo’n taal volgen. De vraag lijkt niet langer: ‘Hoe ziet ons bedrijf eruit?’, maar: ‘Uit welke bedrijfsfuncties en bedrijfsobjecten is onze dienstverlening aan externe actoren opgebouwd?’.
Platen waarbij de methodiek de boventoon voert, ook in de weergave, missen hun doel. Bij een begrijpelijke plaat vraagt niemand zich af wat het achterliggende meta-model is en of dat wel consequent is gevolgd. Dat doen alleen architecten. Overigens: iedere goede plaat, juist óók een begrijpelijke, heeft wel degelijk een onderliggend meta-model dat consistent is toegepast. Het is alleen bijna nooit hetzelfde en beperkt zich zeker niet tot de traditionele blokken en pijltjes.
ICT-architecten mogen onderling best in architectentaal praten, als dat helpt. Maar niet met anderen. Dat wat essentieel is in de belevingswereld van de verschillende belanghebbenden vormt de basis voor een effectieve visualisatie. De vormgeving wordt daarbij zo goed mogelijk op die belevingswereld afgestemd. Een plaat heeft pas zin, als hij begrepen wordt.