Auteur: Admin

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.

Overzicht over het bestaande

ICT is zo verweven in de moderne bedrijfsvoering dat elke bestuurder zich erin moet verdiepen. Dat wordt ze 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 in de krant leest dat de informatievoorziening op instorten staat?

Dan heb je meer aan daadwerkelijk inzicht in de échte informatievoorziening van een organisatie. Wat zijn de belangrijkste systemen? Hoe hangen die samen? Waar zitten de knelpunten en de risico’s? Een goed overzicht van het huidige ICT-landschap geeft bestuurders antwoorden op zulke vragen en helpt hen besturen. Sowieso begint goede architectuur in het bestaande; overzicht over het huidige ICT-landschap is ook om andere redenen cruciaal. Bepaling van een bedrijfsvisie, het opstellen van een ICT-strategie, impactanalyse voor geplande veranderingen, consolidatieprogramma’s na overnames en fusies: het zijn voorbeelden van situaties waarbij bestaande ICT-systemen een sleutelrol spelen en waarbij overzicht dus hoognodig is.

Verrassend vaak ontbreekt dit overzicht – zeker op het niveau van de beslissers, maar ook bij architecten. Met een Excelsheet met de 600 in beheer zijnde applicaties – van Acrobat Reader tot en met de primaire bedrijfssystemen – is niet voldoende aandacht besteed aan het huidige landschap. Wee de architect die niet op een whiteboard een zinnige schets van het applicatielandschap en de knelpunten daarin kan maken.

Nieuw is beter

ICT-architecten zijn  gericht op de toekomst en streven naar een mooi, geordend en flexibel landschap. Ontwerpers en ontwikkelaars vinden vooral het ontwikkelen van nieuwe systemen leuk, met nieuwe technologie en hulpmiddelen. En beslissers lijken technologie bijna per definitie oninteressant te vinden.

Deze ingrediënten vormen een potentieel gevaarlijke mix. Veel architecturen stralen minachting uit voor de bestaande informatievoorziening. Bestaande, werkende applicaties worden bestempeld als ‘legacy’ waar zo snel mogelijk afscheid van genomen moet worden.

Natuurlijk is er vaak van alles aan te merken op bestaande systemen. Maar ze werken wel: juist deze systemen houden de organisatie draaiende, al zijn er vaak jaren van pijnlijke ervaringen voor nodig geweest om ze zover te krijgen.

Met een nieuwe architectuur die, misschien, hopelijk, tegemoetkomt aan de huidige knelpunten, ben je er nog lang niet. Ook binnen die nieuwe architectuur zijn applicaties nodig van dezelfde omvang en complexiteit als de oude applicaties. En die zijn, ook met moderne middelen, niet zonder slag of stoot te realiseren. Het opnieuw specificeren en programmeren van de in de huidige systemen vervatte kennis leidt vaak tot grote, risicovolle projecten. Veel van de grote mislukkingen in de overheids-ICT vallen in deze categorie.

Een onwelkom bijeffect van ‘alles moet anders’-architecturen is dat ze zelf vervullend zijn. Omdat er iets nieuws wordt gemaakt, wordt onderhoud en doorontwikkeling van bestaande systemen stilgelegd. Die vertonen daarom steeds meer kenmerken van de legacysystemen waarvoor ze worden uitgemaakt en worden daarmee onterecht een extra motivatie om het eens helemaal opnieuw te gaan doen. Als de vernieuwing is mislukt, moeten de verwaarloosde systemen alsnog worden afgestoft.

Een realistische architectuur start bij wat er is en lost stelselmatig knelpunten op: meer evolutie dan revolutie. Een droombeeld kan helpen richting te geven aan alle individuele verbeterstappen, maar werkende systemen moeten daarbij worden gekoesterd.

Even voldoende architectuur

Een goede visualisatie van het applicatielandschap maakt inzichtelijk welke systemen een organisatie heeft en hoe die met elkaar samenhangen. Dat is vaak ook meteen even voldoende architectuur.

Het heeft geen zin meer architectuurproducten op te stellen als intussen iedereen willekeurige projecten kan opstarten. Als een organisatie al niet gewend is om naar het applicatielandschap als geheel te kijken, dan helpen toekomstgerichte architectuurproducten zoals principes niet. Na een eerste architectuurstap is dus niet een tweede architectuurstap nodig, maar een stap in de organisatie van de besluitvorming.

Op eenzelfde manier heeft teveel investeren in besluitvorming ook weinig nut. Waarom veel werk maken van bijvoorbeeld business cases, als de inhoud van projecten niet meegewogen wordt bij besluiten? Als bij projectportfoliomanagement vooral gekeken wordt of het juiste documenttemplate is gebruikt, in plaats van of de voorgestelde verandering goed is voor het applicatielandschap als geheel? Na een eerste stap in de besluitvorming is dus niet een tweede stap nodig, maar iets anders.

Want zonder borging van kwaliteit in lopende projecten zijn investeringen in zowel architectuur als besluitvorming zinloos. Waarom architectuurkaders opstellen en zorgvuldig besluiten nemen als projecten vervolgens hun goddelijke gang mogen gaan? Projecten maken hun eigen ontwerpkeuzes onder druk van veranderende eisen en omstandigheden. Architectuur noch besluitvorming zorgen ervoor dat projecten dan binnen de lijntjes blijven kleuren.

Architectuur, besluitvorming én borging in projecten moeten in samenhang worden ingericht. Op alle vlakken moeten stappen worden gezet en zijn concrete maatregelen nodig om de dwarsverbanden te leggen. Pas dan komt de organisatie als geheel vooruit.

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.

Het principe van weinig principes

Principes vormen een krachtig instrument om keuzes vast te leggen en uit te dragen. Ze stellen anderen in staat om te toetsen of hun eigen gedrag in lijn is met de richting die de organisatie op wil en om zich zo nodig aan te passen. Architectuur gaat bij uitstek over het maken van fundamentele keuzes die richting geven aan het werk van anderen. Het is dan ook niet verwonderlijk dat principes een populair instrument zijn onder architecten.

In de praktijk wordt het instrument van principes vaak te losjes gebruikt. Er worden veel te veel principes opgesteld die nauwelijks richting geven, niet inspireren en al helemaal niet te handhaven zijn. Dat wordt vaak opgelost door de spelregel ‘pas toe of leg uit’ in te voeren: het geeft niet als een principe niet gevolgd wordt, zolang maar duidelijk is waarom niet. Dat is dodelijk voor de geloofwaardigheid van de architect.

Een echt principe is altijd geldig. Zo rijden we in Nederland aan de rechterkant van de weg en is diefstal verboden. Architectuurprincipes moeten ook dergelijke fundamentele geldigheid hebben. Als er één principe straffeloos met voeten kan worden getreden, boeten alle andere ook in aan kracht.  Stel daarom alleen principes in die ook echt gehandhaafd gaan worden. Meestal zijn dat er niet veel, een handvol misschien. Hoe krachtiger het gereedschap is, hoe zorgvuldiger men ermee om moet gaan.

World peace

Architecten houden van principes. Kernachtige, scherp geformuleerde uitspraken die richting geven aan de verdere uitwerking en evolutie van een systeem. Principes zijn nodig omdat architectuur gaat over de fundamentele organisatie en niet een volledig uitgewerkte blauwdruk kan bieden. Principes helpen de mensen op de bouwplaats om keuzes te maken tijdens de uitwerking en realisatie.

Principes moeten er daarom toe doen. Ze moeten ergens, bij iemand, pijn doen. Een voorbeeld uit de werkelijke wereld zijn de regels die de architect César Manrique heeft geformuleerd om het natuurlijke landschap van het eiland Lanzarote te behouden. Een van die regels verbiedt gebouwen met meer dan vier verdiepingen. Dat doet projectontwikkelaars pijn: zij willen graag grote toeristische complexen aanleggen.

ICT-architecten vinden dit soort harde uitspraken vaak lastig. Zeker meer technisch ingestoken kaders (“gij zult de servicebus gebruiken”) worden niet goed begrepen en leiden makkelijk tot conflicten. Veel ICT-principes zijn daarom van het kaliber “World peace”. Je kunt er niet tegen zijn, maar ze geven ook geen richting. Ze doen niemand pijn.

Kijk eens naar een van de eerste Noraprincipes: BP01 Afnemers krijgen de dienstverlening waar ze behoefte aan hebben. Tja. Stel we draaien het om: afnemers krijgen niet de dienstverlening waar ze behoefte aan hebben. Dat slaat natuurlijk nergens op – en de conclusie is dan ook dat het oorspronkelijke principe een open deur intrapt.

Principes zijn nuttig en nodig, maar het moeten er niet te veel zijn, ze moeten geen open deur intrappen en echt pijn doen.

Te hoog vliegen

Vanaf grote hoogte lijkt alles op elkaar. En als alles op elkaar lijkt, dan kan het mooi op dezelfde manier geautomatiseerd worden.

De overheid kent verschillende soorten uitkeringen toe – volgens verschillende verzekeringen en regelingen; dat zijn toch dezelfde dingen? Iedere GGD heeft vergelijkbare taken, kunnen ze dan ook niet dezelfde systemen gebruiken? En alle producten van een verzekeringsmaatschappij, kunnen die niet ook op dezelfde manier geautomatiseerd worden?

Op architectuurniveau lijken dit redelijke aannames. Abstract gezien is het wáár dat alle vergunningsprocessen bestaan uit een intake-, beoordelings- en toekenningsstap. Of dat een applicatielandschap moet voorzien in gebruikersinterfaces, diensten, orkestratie en gegevensopslag.

In de praktijk leidt deze manier van denken tot spectaculaire mislukkingen. Wat op papier gelijk leek, blijkt in de werkelijkheid soms fundamenteel verschillend. Omdat het om totaal andere aantallen gaat. Of om andere gebruikersgroepen, of om heel specifieke (wettelijke) eisen of andere gewenste kwaliteitseigenschappen.

Architectuur gaat over essenties en architecten moeten zich niet met alle details bemoeien. Maar sommige details doen er wel degelijk toe en kunnen zelfs tot op het hoogste niveau de haalbaarheid van automatiseringsprojecten bepalen. Sommige details zijn essentieel. Maar om welke details gaat het dan precies? Met denken alleen is dat moeilijk te bepalen, daarvoor moet je de praktijk in en ervaren hoe het in werkelijkheid zit.

Hoog vliegen mag, maar alleen met zeer regelmatige tussenlandingen.

De architect is een team

Veel mensen in de IT vinden het trekken van parallellen tussen echte architecten (die uit de fysieke wereld, zie www.architectenregister.nl) en IT-architecten ongepast. IT is anders, software is oneindig flexibel, de tijdshorizon is anders, kortom: verschillen genoeg.

Maar er zijn wel degelijk lessen te leren uit de “echte architecten”-praktijk. Eén belangrijke les is: je doet het met elkaar, in een team. Bij voorkeur werkend in één atelier, met alle benodigde vaardigheden en kennisgebieden aan één tafel. Maquettes maken, 3D-rendering, doorrekenen van constructies, presentaties houden, pitches geven, kennis inbrengen over wet- en regelgeving, afstemming met bestuurders en ga zo maar door. Een combinatie van technische inhoud, communicatievaardigheden en realisatiekracht.

Bij IT-architectuurafdelingen zie je dit teamdenken nog onvoldoende terug. IT-architecten specialiseren zich op inhoudelijke onderwerpen en zo zijn bij een beetje bedrijf dan ook bedrijfsarchitecten, procesarchitecten, softwarearchitecten, infrastructuurarchitecten en security-architect actief. En ga zo maar door. Groot gevaar is een gebrek aan samenhang tussen de producten die vanuit al die diverse perspectieven worden gemaakt, met alle risico’s van dien. Bovendien is focus op inhoud nutteloos als we geen aandacht besteden aan hoe bestuurlijke urgentie ontstaat, hoe draagvlak gecreëerd kan worden, hoe alle betrokkenen meegenomen kunnen worden, hoe projecten kunnen worden bijgestuurd, et cetera.

Invloed krijg je niet zomaar, dat moet je verdienen. Zorg als IT-architecten dan ook dat je een goede analyse maakt van de vaardigheden in de groep. Doe een 360 graden krachtenveldanalyse, kijk naar wie wat het beste kan en zet elkaar daarvoor in. De architect is namelijk een team.

Vormgeving doet ertoe

ICT’ers in het algemeen – en ICT-architecten in het bijzonder – zijn van de inhoud. Van de rationele argumenten, van de uitgewerkte analyse, van de modellen en visualisaties. Architectuurmethodieken en -talen zijn daar veelal een afspiegeling van, met veel aandacht voor correctheid, volledigheid en consistentie. Daar is niets mis mee. Sterker: het is vaak cruciaal, vooral voor de realisatie.

Niet-ICT-ers laten zulke modellen veelal links liggen. Ze zijn niet aantrekkelijk, moeilijk te begrijpen en de nuances van een architectuurtaal zijn aan hen niet besteed. Zodra het publiek breder is dan alleen ICT-architecten, is het belangrijk om anders met vormgeving om te gaan. Laat je niet leiden door de beperkingen van een formele taal, maar kies een vorm die effectief is.

Een mooie plaat wordt meer bekeken dan een technisch correcte weergave. Het vrijer omgaan met vorm kan een plaat ook begrijpelijker maken. Een kader met het woord ‘justitiabele’ is voor velen minder duidelijk dan een illustratie van een boef. Iets dat groot en centraal geplaatst wordt, is belangrijker dan kleinere zaken aan de rand. Een slordige, schetsmatige weergave laat zien dat er ruimte is voor discussie: het is nog niet af. Een blokje met drie puntjes (…) drukt uit dat er meer van dit soort dingen zijn en dat het niet uitmaakt welke precies.

Mensen geven onbewust betekenis aan zulke elementen. Daar kun je gebruik van maken om fraaie, begrijpelijke visualisaties te maken.

Dit is geen pleidooi voor mooi vormgegeven, inhoudsloze platen, maar wel voor het belang van smaak en creativiteit bij het maken van een goede architectuurvisualisatie. Een belangrijke boodschap verdient een effectieve vorm.