INHOUD
Terug naar community
Magazine
Proceedings
Blogarchief
Scripties
Zoeken
THEMAS
De CIO spreekt
De architect antwoordt
De business bepaalt
Effect van architectuur
SOA
BPM
Methoden
Architectuurprincipes
Financiële sector
Overheidssector
Zorg sector
Meest gelezen artikelen
 
 
Magazine
Report a comment

Thank you for taking the time to report the following comment to the administrator of this site.
Please complete this short form and click the submit button to process your report.

Naam:
 
Email
 
Reason for reporting comment
 
 
 

Comment in question
Geschreven door Steven van 't Veld op 23-04-2009 12:47
 
 
Beste Peter, 
 
Met je laatste reactie laat je precies zien wat ik bedoel. Het verschil dat we hebben is de gerichtheid van de architect op verandering. Waarom zou iets in de IT-infrastructuur, of het nu software, hardware, bestand, netwerk of nog iets anders is, een probleem zijn? Ja, voor mensen die binnengeroepen worden om problemen op te lossen lijkt dat zo. Verkeerslichten worden ook stoplichten genoemd omdat je lang naar rood moet kijken en groen direct voorbij kunt rijden. Een IT-infrastructuur biedt ondersteuning, vigerende oplossingen. Als daar een op te lossen probleem mee is kan je die oplossing misschien inderdaad een ooit valide oplossing noemen, maar men is er wel nog steeds mee geholpen. Nog steeds, want probeer zoiets maar eens uit te zetten…. 
 
Als je de focus van verandering afhaalt en legt op stabiliteit, groei en verbetering wordt het beeld ineens totaal anders. Je hebt dan een beeld, een architectuur en dat ga je hoogstens bijstellen. Dat bijstellen kan tot het realiseren van veranderingen van de IT-infrastructuur leiden, of iets anders. Een verandering kan ook door opleiding geregeld worden, of door verhuizen of het kopen van aanvullende magazijninrichting.  
 
Architectuur is een beeld van een (gekozen) werkelijkheid. Ongeacht hoe goed of slecht die werkelijkheid ook is. Dus iedere organisatie heeft haar architectuur van haar informatievoorziening. Je kunt architectuur expliciet(er) maken zodat deze bijvoorbeeld beter gedeeld kan worden. En als je dan een beter beeld hebt wordt het simpeler om binnen dat beeld aan te geven wat moet veranderen. Het expliciet vaststellen van zo’n verandering kan tot een bestek, een specificatie van eisen, een requirement document leiden; een analyse, dus, op basis waarvan die verandering aangepakt kan worden. Met als resultaat een aangepaste situatie zoals die van tevoren vastgesteld is binnen en waarvan van tevoren een bijgesteld beeld is gemaakt.  
 
Architectuur is daarmee iets dat er is, en dat goed bijgehouden zal moeten worden. Het doel is niet verandering, het doel is dat je weet hoe het in elkaar zit en dat je er zo controle (noem het regie) over krijgt. En natuurlijk gaat dat over dezelfde concepten. Die worden echter nogal anders gebruikt en ingezet. Zoiets als wat we vroeger in projecten informatie analyse noemden en wat nu organisatiebreed wordt ingezet. Dat ik ook waarom ik TOGAF, DYA en de meeste andere methoden zwaar beperkend vind. Het zijn methoden die als doel hebben veranderingen te realiseren. Ze gaan uit van een probleem en werken naar een oplossing. En dat is precies waar organisaties NIET op zitten te wachten. Het is het doel van IT en van IT-leveranciers om projecten te doen, het doel binnen een organisatie is om de juiste informatie op het juiste moment op de juiste plaats te hebben. Oplossingen die dat doen zijn daarbij belangrijk, maar goed genoeg is goed genoeg. Ook ooit valide oplossingen kunnen nog steeds goed ondersteunen, al is misschien niet de nieuwste technologie gebruikt, of past de oplossing niet optimaal: je hebt er als organisatie wel iets aan. Gewoon praktisch.  
 
De hang naar veranderen is feitelijk zwaar beperkend voor organisaties. In mijn ervaring hebben organisaties in hun primaire informatievoorziening nooit meer dan 10 of 12 soorten informatie, vaak zelfs maar 3 of 4. Door de hang naar het creëren van oplossingen hebben organisaties 100-en, 1.000-en, soms zelfs 10.000-en oplossingen opgebouwd waarin steeds weer dezelfde informatie zit. Wat is dan het nu om er nog een bij te zetten? Of een bestaande oplossing te vervangen zonder naar andere, vergelijkbare oplossingen te kijken? IT-infrastructuren zijn al zo complex, en ze worden door op veranderingen gerichte methoden vooral complexer. Tot we echte IT-infarcten krijgen, en daar zitten een aantal organisaties ontzettend dicht tegenaan. Methoden die gericht zijn op verandering hebben het niet in zich om echt naar simpeler en beter te kijken, terwijl veel toch vaak relatief gemakkelijk te realiseren is. En daarom beperken ze wat mogelijk is, en noem is ze zwaar beperkend. Hopelijk krijgen we na de kredietcrisis niet ook nog een informatiecrisis, om bovenstaande redenen. 
 
Steven van ’t Veld 
Steven.van.t.Veld@AIM.nl

 
Gerelateerde artikelen