English version


Nederlandse versie

Steven's Weblog (Nederlands)

Iedereen kan informatie van deze weblog overnemen onder de voorwaarde dat hij/zij blijft verwijzen naar deze weblog.

 

29 September 2006: Enterprise (IT) Architectuur: Keep it Simple. PLEASE!?!

De laatste maanden komt het steeds vaker voor dat ik met organisaties praat over hoe moeilijk Enterprise (IT) Architectuur wel niet is. Vooral de methoden die aangeboden worden maken dingen complex en duur, en bovendien dient er erg veel tijd aan besteed te worden. En dat alles is eigenlijk nogal frustrerend, want waarom zou een methode iets complexer maken in je eigen omgeving dan dat je weet dat het is? Je eerste reactie bij dat soort methoden moet dan toch zijn dat er iets drastisch mee mis moet zijn. En aan zoiets moet je dan steeds weer je tijd besteden. Jammer.

Architectuur moet mensen en organisaties goed inzicht en overzicht verschaffen waarmee je het juiste, in een verdedigbare tijd en tegen een acceptabele kosten kunt neerzetten. Maar dit uitgangspunt lijken we gewoon vergeten te zijn. De complexiteit vliegt je steeds vaker om de oren als je het over architectuur hebt. En echt de enige reden die ik me daarvoor kan bedenken is dat er zo onmogelijk veel geld mee verdiend wordt.

Wat doet een Enterprise (IT) Architectuur methode vandaag in de praktijk? In grote lijnen het volgende:

  • Het opnieuw op een rij zetten van wat we al aan IT hebben. Vaak betekent dat dat veel nog een keer gedocumenteerd wordt.
  • Het hoognodige verzamelen van wat de "gebruikers" van IT nu eigenlijk willen.
  • Een volledig uitgewerkt boekwerk maken waarin staat hoe de IT er in de toekomst uit zal gaan zien.

Nu verandert IT zeer regelmatig, zodat nieuwe IT al verouderd is als het ingevoerd wordt. Het toekomstplaatje is dan ook altijd anders dan het huidige, sterker nog: het toekomstplaatje zelf verandert zeer regelmatig. Als je een Architectuur Methode volgt, dan komt er altijd een advies uit dat nieuwe IT aangeschaft moet worden. Voeg daar outsourcing aan toe omdat dat het allemaal nog beter en goedkoper zou maken, en het eindoordeel is vanaf het begin duidelijk: organisatie, maak uw borst maar nat, want het gaat geld kosten. Met onze "Enterprise (IT) Architectuur" weten we precies wat we willen en kunnen, en dus bewijzen we daarmee voor eens en voor altijd dat steeds nieuwe IT gekocht moet worden. Vaak wordt daar dan ook nog bij vermeld dat die nieuwe IT uw organisatie zelf ook nog beweeglijk (agile) maakt, dus iedereen is gek die niet die miljoenen of zelfs miljarden op tafel legt om dat allemaal te realiseren.

En steeds weer kan je dan onzin roepen.

Denkt u werkelijk dat het voor grof geld herdocumenteren van uw IT volgens een of andere Architectuur aanpak zoveel oplevert? Toegegeven, er zullen fouten uit de huidige IT gehaald worden en die kunnen, als ze opgelost worden, inderdaad tot verbeteringen leiden, maar om daar nou maanden of zelfs jaren aan te besteden. Denkt u dat het vullen een ruim 20 jaar oud IT-raamwerk (Zachman's 36 te vullen vakjes, waaraan sommigen er nog 36, 72 of 108 toegevoegd hebben) u goed overzicht en inzicht geeft? Of denkt u dat de "Architecturen", ik noem ze echt veel liever modellen, van The Open Group (TOGAF) dit voor u doet? Of IAF, xAF, Archimate, of nog een andere? Denkt u dat het in 20 of meer stukken knippen van de IT-wereld waarbij per stuk 18 niveaus van volwassenheid (maturity) uitgewerkt worden u echt verder helpt om te excelleren als organisatie? Hoe denkt u dat het komt dat er straks alleen al in Nederland 30.000 Enterprise (IT) Architecten rondlopen die hier groot geld mee verdienen?

Waar we tegenwoordig te vaak aan leiden is aan angst. We hebben zo weinig vertrouwen in onze eigen kracht dat we ons onder laten dompelen in details omdat we het dan in ieder geval zeker weten. Maar met die zekerheid missen we het essentiële punt van ons functioneren: we dienen toegevoegde waarde te hebben in de functie we, al of niet op basis van een vast contract, bekleden. We zijn Pareto's principe, de 80/20 regel, kennelijk vergeten: we hoeven maar 20% te weten om 80% procent goed te regelen. En voor ons geldt vaak zelfs een 90/10 of een 95/5 regel. Maar onze angst voor als het fout gaat is zo groot, dat we er alles aan doen om die laatste procenten er ook bij te nemen. Ongeacht wat het kost, of oplevert.

Kijk nu eens naar de Cirkel van Invloed van goeroe Stephen R. Covey. Rond IT staan we allemaal in zijn cirkel van betrokkenheid, en we schijnen niet naar de cirkel van invloed te willen. Als organisatie zelf pro-actief de zaken weer in handen nemen dan kunnen er inderdaad fouten mee gemaakt worden. En wat dan nog? Is het dan beter dat anderen die fouten voor je maken? Kwestie van verantwoordelijkheid? Als dat zo is, dan doen we toch echt iets fundamenteel fout.

Maar goed, terug naar mijn praktijk. Iedere keer weer moet je uitleggen dat architectuur een gedeeld beeld is van een werkelijkheid. Dat heeft op zich niet veel met documentatie, modellen, tools enz. te maken. Elke organisatie heeft namelijk al een beeld. Alleen is dat meestal niet gedeeld, werkt men er niet expliciet mee.

Neemt u nu eens een bestaande organisatie in gedachten. Die organisatie doet zijn werk, probeert zijn doelen te halen. Beter of slechter, het is niet anders. Als dit zo is, dan weet men toch ook hoe de informatievoorziening werkt, en welke ondersteuning de organisatie van die informatievoorziening krijgt? Ja, een totaal en consistent beeld van een informatievoorziening is alleen te krijgen als je de kennis en ervaring van de mensen in de organisatie samenvoegt; er één beeld van maakt. Doe je dat door een paar jaar te besteden aan het herdocumenteren van de IT die een organisatie heeft? Waarom zou je? Weten waar je het over hebt, eens goed door die organisatie stappen, met de mensen praten en je je kunt je erg snel een beeld vormen van wat er is, wat mist, hoe het bij elkaar past en ga zo maar door. In termen van de organisatie, want je hoeft ook de werking van de motor van je auto niet te kennen als je met een auto van Utrecht naar Den Haag wilt rijden.

En dan de werkelijke verandering. Als je een gedeeld beeld van je werkelijkheid hebt, ga er dan ook zo goed mogelijk mee om. Stap uit die cirkel van betrokkenheid in die cirkel van invloed, en ga je informatievoorziening pro-actief besturen. Ja, dat zal vechten worden met je IT-leveranciers. Maar leveren die dan de beweeglijke (agile) IT op die u nodig hebt om als organisatie goed te kunnen functioneren? De ervaring is dat overal de handrem op staat, en dat haast alle organisatie sterk gehinderd worden door hun eigen IT. En als je dan zelf de touwtjes weer in handen hebt doordat je je kennis van je informatie (je informatiearchitectuur) zelf onder controle hebt en weet wat er aan de hand is, pas dan ben je in staat om te zien wat moet gaan veranderen. Pas dan ben je in staat om te bepalen of outsourcing of zelfs offshoring goed voor je organisatie is. Dan heb je ook de kracht om je leveranciers precies te vertellen wat je nodig hebt, want dat weet je dan immers. Architectuur is dan iets van de organisatie zelf, en nooit en te nimmer iets van leveranciers.

Is architectuur dan duur? Is het nieuw? Moet die volgende methode ook echt de organisatie ingesleept worden? Misschien, maar meestal niet. Samen weten, samen je afspraken op een rij zetten (en beheren), samen een beeld van de eigen werkelijkheid hebben: duur, nieuw? Als dat zo is, dan is er iets grondig mis met uw huidige werkelijkheid. En een nieuwe methode doet dingen alleen anders, maar vaak met hetzelfde beoogde resultaat. Bezint er ge begint, maar vooral: hou het simpel! Als dingen complex zijn dan weet u dat, dat kan geen verrassing zijn. Maar het meeste is echt simpel genoeg.

 

Uw naam:
Uw E-mail:
Uw reactie: