Methodische plaatjes werken niet

Methodische plaatjes werken niet


01 mei 2013

IT is zo verweven met moderne bedrijfsvoering dat geen bestuurder het zich kan permitteren zich er niet in te verdiepen. Het wordt hem echter niet makkelijk gemaakt. Architecten verwarren besturen met simplificeren en voorzien bestuurders van abstracte informatie en vage keuzemogelijkheden. De vraag is wat bestuurders moeten met platen vol principes, logische domeinen, informatiefuncties en lagen. Wat heb je daaraan als je moet beslissen over een miljoeneninvestering in een nieuw systeem? Of als je moet uitleggen waarom in de krant staat dat de informatievoorziening op instorten staat?

Dan heb je meer aan daadwerkelijk inzicht in de echte informatievoorziening van een organisatie. Wat zijn de belangrijkste systemen? Hoe hangen die samen? Waar zitten de echte knelpunten, risico’s of ontwikkelpunten? Een goede visualisatie kan bestuurders helpen deze vragen te beantwoorden. Zo’n visualisatie ontstaat niet door een standaard(architectuur) model te gebruiken en volgens een vaste structuur in te vullen. Visualisatiemethodieken die zich daarop richten, dreigen een verkeerde afslag te nemen.

Gedeeld beeld

Beslissingstrajecten hebben baat bij een gedeeld beeld tussen de betrokken partijen – figuurlijk, maar ook letterlijk. Een visualisatie die erin slaagt dat beeld uit te drukken in de relevante concepten die alle betrokkenen begrijpen, helpt verschillen in kennis en achtergrond te overbruggen. Die relevante concepten variëren per geval. Soms gaat het om processen, soms om systemen, soms om servers. En soms om hele specifieke zaken, zoals ‘risico’s op botsende treinen’ of de ‘brandweer- en ambulancekolom’. Dergelijke situatie-afhankelijke concepten komen bijna per definitie niet voor in standaardmodelleertalen, maar zijn juist cruciaal voor de begrijpelijkheid van een visualisatie. Net zo cruciaal is dat de visuele weergave van zo’n concept voor zich spreekt. Als ‘boef’ een relevant concept is, dan moet er ook een boef op de plaat staan en niet een rechthoekje met het woord ‘boef’ erin. En als er zaken wordt gedaan met leverancier Jansen, dan moet het logo van de firma Jansen worden gebruikt. Als het lukt een gedeeld beeld op te stellen, dan wordt dat beeld vaak zelf ook onderdeel van de (beeld)taal van de organisatie. De kaart van het applicatielandschap dient ineens als achtergrond om op aan te geven waar knelpunten zitten of waar het meeste geld aan wordt uitgegeven. De behoefte aan inzicht in dergelijke dwarsverbanden ontstaat veelal spontaan en niet omdat iemand van tevoren mogelijke dwarsverbanden in een modelstructuur heeft gegoten.

Nijntjeplaatjes

Daarmee is meteen het recept voor een mislukte architectuurvisualisatie duidelijk: werk volgens een standaardmodel, druk de te visualiseren zaken uit in tevoren gedefinieerde concepten en geef die weer door vaste diagramtechnieken te gebruiken, liefst met gebruikmaking van een standaardsjabloon en -formaat, kies consistentie en theoretische correctheid boven uitdrukkingskracht en simplificeer en abstraheer waar mogelijk, vertrouw erop dat de details in notatie van modelleertalen breed begrepen worden, en vul koste wat kost alle beschikbare viewpoints, views en modellen van het gekozen raamwerk in. Niemand zal zich herkennen in deze aanpak, maar toch is dit wat er vaak gebeurt. Voor het opstellen van een visualisatie wordt gekozen voor een bepaalde methodiek. Door die methodiek te volgen worden alle belanghebbenden gedwongen mee te gaan in de concepten, abstracties en verbanden daaruit. De vraag is niet langer ‘hoe ziet ons bedrijf eruit?’, maar ‘uit welke bedrijfsfuncties en bedrijfsobjecten is onze dienstverlening opgebouwd?’. Alsof je een grafisch ontwerper opdracht geeft een infographic over het Amerikaanse kiessysteem te maken en erbij vertelt dat hij alleen logische informatiefuncties en services mag gebruiken. Recente initiatieven om architectuurvisualisatiemethodieken te ontwikkelen volgen ditzelfde, doodlopende pad. Meer raamwerken, metamodellen en concepten. Maar waar ging het nu ook weer om? Er is geen bestuurder (of informatiemanager of afdelingsmanager of medewerker in de uitvoering) die bij een begrijpelijke plaat vraagt waar het onderliggende metamodel is en of dat wel consequent is gevolgd. Dat doen alleen architecten. Die praten vaak ook neerbuigend over ‘Nijntjeplaatjes’. Maar wie heeft gelijk? De architect die klaagt dat niemand zijn werk snapt? Of Dick Bruna die met slechts een paar lijnen de essentie van zijn verhaal aan een miljoenen publiek weet over te brengen?

Grafische mogelijkheden
Er zijn veel grafische mogelijkheden om een boodschap visueel te ondersteunen. Gebruik van een visuele representatie voor concepten (boef) bijvoorbeeld of het gebruik van omvang en plaatsing: groot en centraal (kernsysteem) is belangrijker dan klein en aan de rand. Een schetsmatige weergave lokt discussie uit (visievorming), een blokje met ‘…’ drukt uit dat er meer vergelijkbare dingen zijn, maar dat het niet uitmaakt welke precies (essentie). Dit soort mogelijkheden is in architectuurmethodieken en daarop gebaseerde tools meestal maar zeer beperkt bruikbaar.

Luisteren

Want daar gaat het om bij een goede visualisatie: de essentie weten te bepalen en die zo helder mogelijk en met aandacht overbrengen. Een goede visualisatie ontstaat niet door een voorgevormde structuur in te vullen. De belangrijkste eigenschap voor degene die zo’n visualisatie opstelt is dan ook goed kunnen luisteren. Wat essentieel is in de belevingswereld van de verschillende belanghebbenden vormt de basis voor een visualisatie; de vormgeving wordt vervolgens zo goed mogelijk op die belevingswereld afgestemd. Aangezien het uiteindelijk gaat om visie- of besluitvorming ten aanzien van IT is het niet ondenkbeeldig dat er (uiteindelijk) ook IT-concepten in een visualisatie terechtkomen, maar die zijn niet het uitgangspunt. Op deze manier ontstaat een basisstructuur die herkenbaar is voor de belanghebbenden. Een applicatielandschap van een gemeente bijvoorbeeld dat bestaat uit deellandschappen voor burgerzaken, de sociale dienst en parkeerbeheer, en niet (alleen) uit frontoffice, midoffice en backoffice. Of een weergave van een veiligheidsregio waarin de opdeling in meldkamer, brandweer, ambulance en GHOR centraal staat en niet die in intake, risicobeheersing, incidentbeheersing en normaliseren. Zo’n basisstructuur kan en mag overigens best complex zijn – anders dan bij Dick Bruna bestaat het publiek niet uit peuters. Als het maar complexiteit is die voortkomt uit de dagelijkse praktijk van het publiek en niet uit de gekozen visualisatie. 

Echt vak

Bij het maken van een goede architectuurvisualisatie spelen – net als bij het maken van een infographic – factoren als smaak en creativiteit een belangrijke rol. Dat wil niet zeggen dat een goede visualisatie niet systematisch tot stand komt. Net als grafisch ontwerpen een echt vak is, met regels en hulpmiddelen, is het opstellen van een goede architectuurvisualisatie dat ook. Bij het maken van een plaat, of het nou de basisstructuur is of een aanvullende laag, wordt de facto een nieuwe (domeinspecifieke) taal ontworpen. Gaandeweg ontstaan de regels waaraan de uiteindelijke visualisaties moeten voldoen. Dit zijn regels op lexicaal, syntactisch en semantisch niveau. Platen moeten kloppen ten opzichte van de regels. Pijlen die bijvoorbeeld gegevensoverdracht of triggers representeren mogen alleen objecten van de bijpassende soort (zoals actoren en systemen) verbinden. De concepten krijgen zoveel mogelijk hun eigen weergave. De visualisatie van vergelijkbare (maar niet dezelfde) concepten ligt dicht bij elkaar: waar een rechthoek met een dichte lijn een bestaand systeem representeert, wordt een stippellijn gebruikt voor een systeem in ontwikkeling. De regels van de taal spreken bij voorkeur voor zich door het gebruik van herkenbare symbolen, voorzien van korte teksten. Waar nodig worden ze toegelicht in een kleine legenda. Het beoogde effect is dat de betrokkenen inconsistenties herkennen en zelfs nieuwe concepten aandragen. Naast regels zijn er ook heuristieken die helpen bij het ontwikkelen van visualisaties. Een belangrijke is het weergeven van de omgeving. In een goede plaat wordt de omgeving van een systeem of landschap geduid en worden de verbanden getekend.

Spelen met regels

Hoewel de visualisatie uiteindelijk precies is, is het spelen met de regels gedurende de ontwikkeling cruciaal. Zo kan eenzelfde organisatieonderdeel meerdere keren op een plaat voorkomen, als het meerdere diensten verleent. Ook zijn er veel grafische handigheden mogelijk die in één oogopslag duidelijkheid geven. Maar ook hier gaan architectuurmethodieken mank. Wat grafisch gezien geen enkel probleem is, is nauwelijks in de beschikbare modellen te vatten. Laat staan in tools en visualisaties die ermee gemaakt kunnen worden. Hetzelfde geldt voor spelen met (in) consistentie. Bewuste inzorgvuldigheid en inconsistentie helpt de betrokkenen de concepten scherp te krijgen. Wat is nu precies een doelgroep? Wat zijn de kanalen waarlangs we werken? Wat zijn de relevante overdrachtsmomenten naar de productieomgeving? Modellen en tools kunnen echter vaak heel slecht omgaan met inconsistentie. De succesvolste visualisaties zijn het resultaat van een samenwerkingsproces tussen de opsteller en verschillende belanghebbenden. De waarde van dat proces kan niet overschat worden. Door discussies ontstaat zicht op de belangrijke concepten, de cruciale verbanden en de passende visualisaties. Tussentijdse schetsen zorgen ervoor dat iedereen het eindresultaat herkent. Dit vergt tijd. Het hergebruiken van een bestaande succesvolle visualisatie is misschien sneller, maar de kans dat de belanghebbenden hun verhaal in het eindresultaat herkennen is klein.




Krijg inzicht en structuur in uw bestaande applicatielandschap