Skip to content

Trautwein Interactive

Sections
Personal tools
You are here: Home » Weblog

Waarom zijn IT architecten zo weinig geliefd?

Document Actions
Deze observatie is geschreven door een architect voor andere architecten. Het is geen aanklacht tegen u, de lezer. Als u geen IT architect bent, hoeft u zich niet aangesproken te voelen, hoewel het onderstaande directies en projectleiders mogelijk tot nadenken stemt. Bent u wel architect dan is het vanzelfsprekend ook niet tegen u gericht. Ik twijfel er niet aan dat u uw werk perfect verricht en dat ik daar niets aan kan toevoegen. Ik richt me op al die andere architecten die kwalitatief net wat minder zijn dan u.

Waarom zijn IT architecten zo weinig geliefd?

Iedere grote organisatie heeft IT architecten, die richting moeten geven aan de IT ontwikkeling. Iedereen in Nederland merkt direct of indirect de plannen waar de architecten van de overheid voor verantwoordelijk zijn, met de beschikbaarheid van diensten als DigiD, eHerkenning, Digipoort en Digikoppeling. Ik heb met alle vier oplossingen veel ervaring en we kunnen het er over eens zijn dat de ideeën er achter goed zijn, hoewel je in IT altijd kunt discussiëren over de uitwerking. De architecten hebben goed werk verricht. Maar waarom was de implementatie van Digipoort, eHerkenning en het nieuwe eIDAS dan zo moeilijk? En waarom heb ik in andere omgevingen zo vaak meegemaakt dat architecten gezien werden als hinderlijke paljassen, waar iedereen zo weinig mogelijk mee te maken wilde hebben? Waar komt die aversie vandaan?

Gebaseerd op eigen ervaring en reacties van collega’s denk ik dat de volgende punten zorgen voor dat negatieve beeld:

  1. De naam architect is overgenomen uit de bouwwereld, maar ook die beroepsgroep worstelt met een imago probleem, dat aan die naam kleeft. De eerste indruk is dan niet positief;
  2. De architectenwereld heeft de neiging zichzelf neer te zetten als omnipotente zieners. Ook heb ik architecten ontmoet die uitstraalden dat zij zich gehinderd voelen door het eenvoudige voetvolk, inclusief hun collega’s, dat te beperkt is hun visionaire vergezichten uit te voeren;
  3. Architecten schieten vaak te kort in uitleg waarom bepaalde keuzes zijn gemaakt. Er wordt vaak verwezen naar de beslissing op directieniveau dat de architectuur verplicht is. Dat zet kwaad bloed;
  4. Architecten lijken zich weinig van de praktijk aan te trekken en lijken zelden geïnteresseerd te zijn om er lering uit te trekken;
  5. Architecten onttrekken zich aan verantwoordelijkheid bij het uitvoeren van de richtlijnen. Typisch is dat binnen een project de architect af en toe komt binnen vallen, aanpassingen eist, maar vervolgens niet beschikbaar is voor de uitwerking ervan of verantwoordelijkheid voor de gevolgen. De term “ivoren toren” is dan vaak de vriendelijkste kwalificatie;

Het ontstaan van de IT-architect

Laten we beginnen te stellen dat de architectenrol noodzakelijk en natuurlijk is, In alle omgevingen waar werk wordt verricht zie je dat op de werkvloer sommige mensen zich ontwikkelen tot uitstekende werkers die voorzien van de juiste middelen hun werk snel en goed uitvoeren. Spectaculaire voorbeelden daarvan zijn op het internet ruim te vinden: Zoek maar eens op uw favoriete videosite naar “fastest workers” of “cooking skills” om een stoet professionals langs te zien trekken van bouwvakkers en fabrieksarbeiders tot aan koks en poffertjesbakkers die met onmenselijke precisie en snelheid hun dagelijkse werk doen.

Behalve deze uitvoerders, zullen de meer beschouwende werkers ook gaan nadenken “hoe het beter kan.” Maar de meeste industrieën wordt beperkt door de beschikbaarheid van hun grondstoffen. De leveranciers en de praktische kanten van de zaak hebben een grote invloed op de markt terwijl het slechts weinig organisaties gegeven is hun toeleveranciers te verplichten grote aanpassingen door te voeren of geheel nieuwe zaken uit te vinden. Het is duidelijk dat de horeca blij zou zijn met de vierkante tomaat en de bouw met cement dat uithardt na een druk op een knop in een app, maar tussen droom en daad staan wetten in de weg en praktische bezwaren.

De grondstoffen voor de IT industrie daarentegen zijn op ieder kantoor aanwezig. Overal staan tekstverwerkers met aanvullende software waarmee een plan eenvoudig is te schrijven. De overige grondstof zijn de ideeën die in ieders hoofd opborrelen, Dus komen IT-ers weinig beperkingen tegen tijdens met bedenken van het ideale IT productie proces. En aangezien IT-projecten notoir moeilijk en kostbaar zijn, is er volop belangstelling voor mensen die een betere methodiek weten te bedenken. In een kleine organisatie zullen mensen die architectuurrol vervullen naast hun verdere werk, maar in grote organisaties ontstaat vanzelf de architect als specialist, met als taak om het heden te verbeteren en op de toekomst te anticiperen zodat de organisatie zijn IT mogelijkheden maximaal inzet.

We zoemen in op een paar redenen waarom architecten dan toch niet geliefd zijn.

De besmette naam

Vlinderdasje

De architect in de bouw heeft bij de man in de straat een slechte naam. Een architect wordt gezien als een mislukte kunstenaar met vlinderdas die lelijke gebouwen neerzet waar een gezond mens nooit in zou willen wonen of werken. Omdat ieder lelijk gebouw door een architect is ontworpen en je zelden hoort dat een architect zijn excuses aanbiedt voor een minder gelukt ontwerp, blijft dit idee in stand. Dit imago van een veelpratende blaaskaak die voor eigen genoegen luchtkastelen bouwt, kleeft ook aan de IT architect.

Visie versus de harde werkelijkheid

Vlinderdasje

Mensen hebben de prachtige en machtige eigenschap om abstract te kunnen nadenken over de wereld. Zwevend boven de moeizame dagelijkse werkelijkheid verschijnen er prachtige schetsen op de schetsboek en whiteboard. Creativiteit en visie kunnen alleen bloeien zonder dat bezwaren hen neerslaan. En zonder beide komen mensen en organisaties niet verder, maar zijn ze gedoemd tot in de eeuwigheid hun dagelijkse sleur te herhalen.
Maar in die verheven geestestoestand onderschat men snel hoeveel moeite het kost nieuwe zaken te realiseren of te onderhouden. Iedereen die wel eens vol enthousiasme aan een groot project is begonnen kan hier van meepraten. Thuis op de bank biedt die onderschatting vermaak als de basis voor televisieprogramma’s als “Help, mijn man is klusser” of “Ik vertrek.”

De werkelijkheid doet zijn best om ons te leren hoe hard zij is, maar mensen zijn er meesters in die lessen te vergeten. Ik ben vast niet de enige die al talloze keren is verrast over de tijd en moeite die het kostte een tekst of een computerprogramma te schrijven of een idee tot in detail uit te werken. Als een project zo groot is als een IT architectuurplan, dan heeft de harde praktijk een uitgebreid arsenaal valkuilen, voetangels en klemmen die geduldig liggen te wachten om iemand de kans te geven leergeld te betalen.

Maar de beschreven vergeetachtigheid die iedereen treft, heeft ook een ander gevolg. De realist zal slechts zelden zijn visie kunnen “verkopen” aan het management of de werkvloer. Slechts weinig leidinggevenden zullen een plan steunen dat realistisch de hoeveelheid tijd en moeite beschrijft van een onzekere onderneming waar de organisatie nog geen ervaring mee heeft. Vrijwel iedereen ziet liever het inspirerende punt aan de horizon, waar we ons al struikelend en stommelend naartoe op weg begeven. En daar aangekomen, zijn we vergeten hoe moeilijk de weg was, op wat onvermijdelijke zuurpruimen na, waar gelukkig niemand naar luistert.

Omnipotent

een toverstok

De eisen die aan een architect gesteld wordt grenzen aan het onmenselijke. Als we bijvoorbeeld de TOGAF standaard erbij pakken moet een architect onder andere:

  1. Een visionair zijn met een duidelijk idee waar de organisatie naar toe moet;
  2. Uitstekend op hoogte zijn van alles wat binnen de organisatie speelt en belangrijk is;
  3. Tot in details op de hoogte zijn van de ontwikkeling buiten de organisatie;
  4. Een uitstekende programmaleider zijn om alle projecten opgestart om het architectuurplan te realiseren te kunnen ondersteunen;
  5. In staat zijn aan de directie een sluitend voorstel te doen voor de toekomstige ontwikkelingen van de ICT;
  6. In staat zijn om alle stappen met betrekking tot de verwezenlijking van zijn plannen te voorzien en te plannen binnen de organisatie, budget en tijd voor de komende jaren;

De laatste persoon die over al deze vaardigheden beschikte heeft in 6 dagen een universum geschapen en had het relatief eenvoudig. Hij of zij was eigen baas, waardoor punt “5” niet van toepassing was.

Helaas heb ik vaak ervaren dat architecten zich niet bij de onhaalbaarheid van de eisen neerleggen. In plaats daarvan wordt de illusie in stand gehouden dat zij het complete overzicht in de palm van hun hand houden. Zodra de praktijk en lastige details de architectuurplannen lijken te doorkruisen wordt er gekozen voor een defensieve houding. Critici wordt de mond gesnoerd, alternatieven worden niet gehoord en er worden eisen doorgedrukt met als belangrijkste argument dat management het besloten heeft. Ook heb ik meegemaakt dat architecten simpelweg wegliepen en op geen enkel overleg meer verschenen.
Deze houding roept actieve weerstand op in alle geledingen van een organisatie, waarna iedereen, behalve het hoger management, zijn best gaat doen om de architecten te ontlopen.

Oplossingen

Er zijn meerdere oplossingen mogelijk, maar ik denk dat ze allemaal door dezelfde open deur tuimelen dat een architect af moet dalen uit zijn geriefelijke ivoren toren en net als iedereen in de modder komt staan. Bovendien weten we al dat de “waterval” methode voor complexe IT systemen vaak niet goed werkt. Waarom verwachten we dat deze aanpak wel functioneert voor een meerjarige architectuurplan?

Servicegericht en “Agile”

Met het architectuurplan in de hand moeten architecten de uitvoering actief ondersteunen om de doelen te bereiken. De goede architect ziet de plannen als een service aan de organisatie en moet dus service gericht zijn. Een goede architect neemt verantwoordelijkheid voor de uitvoering en trekt er samen met de rest van de organisatie lering uit. Hij of zij staat open voor suggesties en aanpassingen zodat een optimale oplossing gerealiseerd kan worden. Dat heeft als bijkomende voordeel dat plannen, business case en KPI’s verbeterd kunnen worden en dus waardevoller zijn. Die aanpassingen worden gewoon in de ontwikkeling opgenomen, waar management indien nodig zijn goedkeuring aan geeft.

Blinde vlekken

Mijn ervaring is verder dat architecten behalve voor de realisatie vaak nog twee blinde vlekken hebben. Ten eerste lijkt er weinig aandacht te zijn voor het beheer van IT. Dat is opmerkelijk omdat de meeste kosten van een IT systeem in het beheer zitten. Het project dat de oplossing realiseert is mogelijk kostbaar, maar heeft eenmalige kosten. De beheerkosten lopen gedurende de hele levensduur van de oplossing door en komen doorgaans veel hoger uit, zeker als het beheer moeilijk is omdat bij het realiseren van de oplossing niet goed over beheer is nagedacht.

Ten tweede lijken architecten niet helder te krijgen welke informatie belangrijk is voor succes van de oplossing. Mijn theorie is dat architecten zo veel architectuurdocumentatie moeten produceren, dat de behoefte van andere partijen aan concrete informatie ondergesneeuwd raakt. Dus zijn er geen korte, eenvoudige beschrijvingen m.b.t. de doelen en inhoud van de architectuur die geïnteresseerden snel tot zich kunnen nemen. Ook ontbreekt vaak de technische en beheerinformatie nodig om de oplossing te kunnen gebruiken. Zoals boven geconstateerd, verwacht geen verstandig mens dat een architect al deze documentatie zelf schrijft, maar voor de organisatie lijken mij kwalitatief hoogwaardige handleidingen en stappenplannen noodzakelijke “deliverables.”

Uit de praktijk: Praktisch kennis moet beschikbaar zijn

Ik heb ervaren dat soms voor de hand liggende kennis niet beschikbaar is voor partijen die een nieuwe oplossing moeten gaan gebruiken. Ik heb UWV aangesloten op Digipoort en Omgevingsloket Online op zowel eHerkenning als eIDAS. In al deze gevallen was het platform nog nieuw en nog niet voorbereid op het faciliteren van zo’n grote partij. Wat me telkens opviel, was dat de technische informatie, die iedereen nodig heeft om aan te sluiten, nauwelijks beschikbaar was. Ik heb diverse keren met projectleiders en architecten van deze platformen aan tafel gezeten om er achter te komen dat niemand de detailkennis kon leveren die nodig was. In één extreem geval werden iedere vergadering met nieuwe mensen dezelfde schema’s getekend en dezelfde presentaties uitgedeeld, zonder dat de benodigde informatie beschikbaar kwam. In twee gevallen kon ik de koppeling alleen realiseren toen ik de contactgegevens kreeg van de meest technische man van de leverancier die de oplossing gerealiseerd had. In beide gevallen was deze persoon zwaar overbelast omdat alle problemen op zijn bordje terecht kwamen. In de hele organisatie van honderden betrokkenen, was er verder niemand die op detail niveau de oplossing kende. De governance en projectleiding moeten op dat punt veel beter, niet achteraf, maar tijdens de opbouw van het project.
Kwaliteit is belangrijk ook voor documentatie
Er is een groot verschil tussen een beschrijving wat de functie van een bericht of een veld is en uitleg welke waardes dientengevolge er verwacht worden. Als niemand duidelijk opschrijft welke waardes uitgewisseld worden, zie je dat alle betrokken partijen fouten gaan maken die vervolgens met veel kosten en vertraging weer opgelost moeten worden. Bij alle drie de gevallen kwamen er nog ingrijpende technische aanpassingen terwijl de aansluiting al gerealiseerd werd, wat voor hogere kosten zorgde bij iedereen.
Overigens leren organisaties wel, want bij het aansluiten van eIDAS in de zomer 2018, was mijn indruk dat de organisatie het probleem wel onderkende, maar dat door onwennigheid, Europese bureaucratie en tijdsdruk nog geen goede oplossing had uitgewerkt. Niettemin is de beschikbare documentatie van eIDAS tot op de dag van vandaag niet specifiek genoeg om zonder hulp een dienst te kunnen aansluiten.

Cultuurverandering

Hierboven som ik een aantal voor de hand liggende oplossingen op. Mijn indruk is dat veel collega’s deze problemen ook min of meer erkennen. Maar nu ik deze dagen weer de (architectuur) standaarden door lees, valt het me duidelijk op dat er een cultuur verandering nodig is in de manier waarop architecten worden opgeleid. Het cursusmateriaal schetst een beeld van de architect als messias, in staat om alles en iedereen naar het beloofde land te leiden. Het lijkt mij dat het de beroepsgroep zou passen een bescheidener houding aan te nemen en met enige nederigheid alle taken op te pakken die nodig zijn om de uitvoering van de architectuur zo succesvol mogelijk te maken.

Created by keest
Last modified 2019-05-13 13:58
« September 2019 »
Su Mo Tu We Th Fr Sa
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30          
 
 

Powered by Plone

This site conforms to the following standards: