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.
Ja, en hier zit juist het punt waar ik het niet mee eens kan zijn: het direct in verband brengen van architectuur met veranderen. Dat is ook precies de zware beperking die een methoden DYA, TOGAF en vrijwel elke andere “architectuur”methode als uitgangspunt neemt.
Laat ik het anders zeggen. Stel je eens de vraag wat de architectuur is van iets dat bestaat: een kerk, software, een IT-infrastructuur of nog iets anders. Mensen gaan dan kenmerken opnoemen. In lijn met reeds lang bestaande ideeën gaan die kenmerken vooral over wat functioneel geboden wordt, wat de structuur is, hoe mooi het is (en waarom) en hoe het geheel past in zijn omgeving. Stel nu dat je kenmerken wilt beschrijven van iets dat er nog niet is, iets dat er misschien moet komen. Wat je dan moet beschrijven zou eigenlijk hetzelfde moeten zijn als wat je op zou schrijven als het wel bestaat. Dus wederom met kenmerken als functie, structuur, schoonheid en harmonie.
Als dit zo kan, dan is architectuur en verandering dus vooral iets anders. Zeker in onze informatie & IT-sector, want daar zou eigenlijk de architectuur van het geheel er moeten zijn. Niet alleen van de delen, maar juist en vooral van het geheel. En daarbinnen kunnen zaken aangepast (moeten) worden. Die veranderingen binnen het geheel vaststellen is in feite het bestek, de specificatie van eisen voor de door te voeren verandering.
Naar onze informatie & IT-sector heeft de architectuur van een gehele informatievoorziening feitelijk weinig of niets te maken met informatie techniek. Pas als e.e.a. verder uitgewerkt wordt om een bestek van eisen te kunnen krijgen zullen een minimale set eisen toegevoegd kunnen of misschien moeten worden om de juiste verandering te bewerkstelligen. Minimaal, want waarom zou een organisatie zich druk moeten maken over welke processor, welk operating system, welk netwerk, welke dbms, welke programmeertaal enz., tenminste zo lang het maar in het geheel past (de harmonie). Regie is dan dat je binnen het geheel passende bestekken hebt die verwezenlijkt kunnen worden zodat ontstaat wat je als organisatie wenst, en waar je geld voor uitgeeft.
De verandering is gemiddeld ongeveer 20% van alle geld dat uitgegeven wordt. Verwacht mag worden dat dit “bedrag” uiteindelijk kan dalen, maar omdat de hoop er nog steeds is dat dan ook de exploitatiebedragen zullen dalen zal de totale hoeveelheid geld misschien minder worden, terwijl het percentage aan verandering misschien wel gelijk blijft. Nu wil het geval dat DYA zich kompleet en volledig beperkt tot het veranderen, en dus niet met de 80% andere kosten doet. TOGAF lijkt me wat breder, maar dat zou best eens een foute inschatting kunnen zijn. En ik ken maar weinig andere “methoden”, “architecturen” die meer afdekken naast dat veranderen. En daarmee is architectuur op dit moment maar een fractie van wat het zou moeten zijn: het totale beeld van een informatievoorziening. En daarmee zeg ik ook dat TOGAF geen universeel wondermiddel KAN zijn, want het dekt maar een heel klein deel van alles in de informatie & IT-sector af.
Daarmee deel ik dus je kritiek op de huidige architectuur methoden, maar om een echt kompleet andere reden en rationale. Dit soort methoden vergelijken is daarom op zich interessant, maar duidelijk ook zeer beperkt in scope als je echt naar wat ik de informatie & IT-sector noem en voor de informatievoorzieningen van en binnen organisaties daarbinnen. Het kan weinig meer zijn dan een vervolg van het boek Vergelijking van Systeemontwikkelingsmethoden dat door NGGO in 1989 onder mijn redactie geschreven is. Op zich wel relevant voor, m.i., vooral de IT-sector, maar het heeft nog zeer weinig met architectuur te maken. Net als DYA, TOGAF, GEM en hoe de 100-en architectuurmethoden tegenwoordig ook genoemd worden.