Maand: juni 2017

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.

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.

In het oog is in het hart

Verrassend vaak zit de top van een bedrijf ook letterlijk in de top: de bovenste verdiepingen van een kantoor zijn veelal gereserveerd voor de hogere managementlagen. Dat ICT vaak in de kelder wordt geplaatst, zou je nog positief kunnen uitleggen als  “ICT vormt het fundament waarop moderne organisaties zijn gebouwd”. Op het moment dat de ICT-afdeling in een aftands bijgebouw op een aparte locatie zit, houdt dat denken echt op.

Dat afstanden in een organogram ook vertaald worden naar fysieke afstanden, heeft onbedoelde neveneffecten.

Uit onderzoek dat is gedaan op universiteitscampussen blijkt dat mensen die een kamer dichtbij een gedeelde keuken krijgen, meer vrienden maken en sneller een partner vinden. Meer persoonlijk contact leidt sneller tot wederzijdse sympathie: we vinden aardig wie we vaker zien. Dat geldt op het werk evengoed. We hoeven niet massaal verliefd te worden, maar wederzijdse sympathie bevordert de samenwerking.

Als ICT in de kelder zit en de directie op zolder, groeien de twee langzaam maar zeker uit elkaar – niet zo gek dat de kwaliteit van de besluitvorming rond ICT vaak te wensen over laat. Als ICT niet in de gebouwen zit waar het echt gebeurt (bijvoorbeeld in het ziekenhuis) wordt het nog erger. Hoe weet je dan nog wat er speelt op de werkvloer? Hoe krijg je dan nog passende oplossingen voor actuele problemen?

Voor architecten is een informeel netwerk dat door de hele organisatie loopt essentieel. Dat gaat niet vanzelf, dat moet je helpen ontstaan door de fysieke afstand te verkleinen. Kom uit de kelder, of zorg voor een werkplek in het hart van de organisatie. Een dag meelopen op een productieafdeling, een middag naast de koffieautomaat werken op de financiële afdeling, aanschuiven bij de heisessie van personeelsmanagement – aanwezigheid op de werkvloer en op de hoogste verdieping zorgt voor verbinding met de praktijk. En dat is een goede basis voor vertrouwen, samenwerken en invloed.

In de beperking toont zich de meester

Veel architectuurmethodes en referentiearchitecturen bevatten een of ander raamwerk. Een indeling in verschillende aandachtsgebieden bijvoorbeeld, vaak iets als bedrijf, informatie en techniek. Of een definitie van de verschillende soorten elementen waaruit een architectuur kan bestaan, zoals eisen, principes, processen, diensten, logische functies en gegevenselementen. Meestal een combinatie van beiden.

Zo’n raamwerk vergemakkelijkt het werk van een architect. Het helpt bijvoorbeeld discussies te structureren door telkens de nadruk te leggen op één duidelijk gedefinieerd perspectief. Een raamwerk helpt doelen, randvoorwaarden en oplossingen uit elkaar te halen. Mits goed gebruikt, kan een raamwerk helpen om de consistentie van het geheel te bewaken.

Raamwerken hebben ook een gevaar in zich. Het is moeilijk weerstand bieden aan de neiging om alle onderdelen in te vullen, om te beginnen linksboven in het raamwerk en pas te stoppen als je rechtsonder aangekomen bent en onderweg ieder vlakje volledig ingekleurd hebt. Dat is dan ook precies wat er in architectuurtrajecten te vaak gebeurt. Het raamwerk is een doel op zich geworden.

Dat is niet alleen verspilling van tijd, geld en intelligentie, het zorgt er ook voor dat veel belanghebbenden afhaken. Zij moeten input leveren over iets dat op dat moment helemaal geen issue is en geen waarde toevoegt, terwijl datgene waar ze naar op zoek zijn – een richtinggevend principe op een bepaald vlak, een keuze voor een bepaalde technologie – nog (lang) niet op de agenda staat.

Architectuur gaat altijd om essentie, zelden om compleetheid. Werk uit waaraan behoefte is, tot een niveau dat waarde toevoegt.

Ceci n’est pas…

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.