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.