Een plaat is een proces

Als ICT-architecten praten over het maken van visualisaties voor bestuurders, duurt het niet lang voor de term ‘Nijntjeplaatje’ valt. Dit vanuit de arrogante veronderstelling dat bestuurders de complexiteit van ICT niet kunnen doorgronden.

Het klopt dat bestuurders en ICT-architecten elkaar vaak niet begrijpen. Daar zijn allerlei oorzaken voor, maar niet dat bestuurders geen complexiteit aan kunnen. Als er complexe zaken te bespreken of te besluiten zijn, dan doet een Nijntjeplaatje daar geen recht aan. Sterker, oversimplificatie is een recept voor onvrede en zelfs mislukking verderop in het traject. Een architectuurvisualisatie kan en mag best complex zijn – anders dan bij Dick Bruna bestaat het publiek niet uit peuters. Zolang die complexiteit maar voortkomt uit de dagelijkse praktijk van het publiek en niet uit de gekozen visualisatie, de daarvoor gebruikte methodiek en bijbehorende beeldtaal. De plaat moet de essentie laten zien van de problematiek en dat begrijpen bestuurders zeker.

Succesvolle, complexe visualisaties vragen een samenwerkingsproces tussen de opsteller en belanghebbenden. De waarde van zo’n samenwerkingsproces kan niet overschat worden. In discussies ontstaat zicht op de belangrijke concepten, de cruciale verbanden en daarbij passende visualisaties. Tussentijdse schetsen zorgen ervoor dat iedereen het eindresultaat mee ziet ontstaan en ook kan herkennen. Dat vraagt inspanning en tijd van architect én betrokkenen. Bovenal vraagt het een rechte rug in tijden dat oneliners en ongenuanceerde quotes populairder zijn dan een complexe boodschap.

Zoek de pijngrens op

Van nature vermijden mensen pijn. Als het veel moeite kost om een nieuwe versie van het CRM-systeem te implementeren, dan is het verleidelijk om de volgende upgrade maar een keertje over te slaan. Als het aansluiten op de servicebus in het verleden veel ellende heeft opgeleverd, is de kans groot dat nieuwe koppelingen de bus zullen omzeilen. Zo loopt de technische schuld in het landschap op. Langzaam maar zeker ontstaan er no go-areas: systemen, koppelingen, processen en andere zaken die niemand durft aan te passen omdat de risico’s te groot zijn dat er iets misgaat.

De oplossing is tegenintuïtief: juist de dingen die moeilijk zijn en pijn doen, moeten we veel vaker doen. Door ervaring op te doen worden ze steeds iets gemakkelijker. Door het slim aan te pakken, worden de risico’s beperkt.

Om de pijn te verzachten, kunnen grote taken in kleine brokken worden opgedeeld. Dus niet in een keer van versie 1.3 naar versie 10.5 springen, maar eerst leren wat het betekent om naar 2.0 over te stappen.

Het is verstandig om voor elke verandering een vangnet te creëren dat het mogelijk maakt om fouten te detecteren en terug te keren naar de uitgangssituatie als dat nodig is. Handelingen zoveel mogelijk automatiseren maakt risico’s kleiner, taken herhaalbaar en het werk interessanter.

Dit betekent ook dat er investeringen nodig zijn in tools voor bijvoorbeeld regressietesten, automatische deployment en continu monitoren om de gebruikservaring van het landschap in beeld te brengen. Een vakman werkt met professioneel gereedschap. Het traditioneel defensieve IT-beheer moet offensief leren spelen om de technische schuld terug te dringen.