|
Pagina 2 van 10
In 1982 schreef Jaap van Rees het roemruchte artikel ‘de methode doet het niet’. Sinds die tijd is er een ware vloedgolf aan methodenboeken op de markt verschenen. Veel methoden zijn trouwens activiteitgeoriënteerd, dus uitermate geschikt om op basis van uurtje-factuurtje op mechanische wijze body shopping uit te voeren. Het is dan ook niet voor niets dat veel methodes door softwarehuizen zijn bedacht dan wel worden gepropageerd.
‘De methode doet het niet’ geldt des te sterker voor projecten die een hoge mate van creativiteit en situatieafhankelijkheid vergen. Trouwens wie haalt het in zijn hoofd als hij een fysieke architect uitnodigt een ontwerp te maken voor zijn droomhuis hem de vraag te stellen: welke methode gebruik je? Behalve een doorgeschoten theoreet of een nieuwsgierige concurrent is daar toch geen enkele zakelijke opdrachtgever of nuchtere businessmanager in geïnteresseerd. De dikte van een methodenboek is meestal recht evenredig met de mate van betutteling van de toepasser. Het boekwerk TOGAF 9.0 telt ruim 700 pagina’s2 en is zo zwaar dat je het fysiek kunt gebruiken om er tegenstanders mee knock out te slaan. Handig bij de eeuwigdurende methodenstrijd.
Op 2 februari 2009 werd versie 9.0 van TOGAF ten doop gehouden in San Diego als opvolger van versie 8.1.1, resulterend in een grote hoeveelheid extra details. Het formuleren zal een forse inspanning hebben gevergd. Probeer maar eens wereldwijd consensus te krijgen over zoiets principieels als een methodologie, zeker als er honderden partijen bij betrokken zijn. Uit de wandelgangen heb ik vernomen dat door de forse bijdragen van Capgemini en SAP het proces toch redelijk snel verlopen is.
Ik geloof heilig in ‘open source’, maar bij ‘open methodologie’ zet ik toch grote vraagtekens: democratie3 leidt meestal tot niets. Trouwens, bij de analyse van ADM kwam bij mij spontaan de afgezaagde grap naar boven: een kameel is een paard ontworpen door een democratische groep.
Bij het doorworstelen van die 728 pagina’s TOGAF wordt de lezer getrakteerd op een tamelijk onevenwichtige, weinig samenhangende en nogal gedateerde verzameling teksten met te weinig diepgang. Het informatieverkeer - de bloedsomloop van elke onderneming – ontbreekt geheel. Digitale werkruimten - de persoonlijke digitale werkruimte in het bijzonder - worden niet eens genoemd omdat de gebruiker volledig buiten beeld blijft. Architectuurprincipes lijken gezien het aantal pagina’s dat daar werkelijk aan is gewijd een ondergeschoven kindje, terwijl serieuze architectuurvisualisaties en waardevolle architectuurconcepten niet eens aan bod komen. ADM, het hart van TOGAF, is een onduidelijk mengseltje van architectuur, engineering, IT-governance en projectmanagement. Ik ben trouwens nog geen weldenkende architect tegengekomen die mij de logica achter dit schema heeft kunnen uitleggen noch de plausibiliteit van de verschillende pijltjes. Trouwens, het hele TOGAF-document overziend valt mij op dat 38,9% handelt over IT-Governance en projectmanagement, 39,4% over engineering en slechts 21,7% over architectuur.
Gelukkig biedt TOGAF een redelijk triviaal, rigide stappenplan voor alle architectuurfasen, zalig voor het uurtje-factuurtje in elkaar zetten van een architectuur.
Als je de rol en taken van een architect in TOGAF beschouwt, dan krijgt de architect naast zijn eigen werkzaamheden ook een groot deel van de werkzaamheden van de CIO, de businessconsultant, -strateeg, de programmamanager, de engineer en zelfs de innovator op zijn bord. Kortom, hij wordt de belangrijkste man na de CEO. Dat lijkt mij toch wel een beetje opgeklopt?
Toegegeven, er zitten ook nuttige ideeën in TOGAF 9.0, maar ja die kans loop je snel bij 728 pagina’s met een dergelijke heterogene groep.
Rond TOGAF ontstaat een ware IT-sekte: je bent in TOGAF of je begrijpt niets van het vakgebied. Sommige TOGAF-bekeerden stellen zelfs dat iedere professionele architect eigenlijk in TOGAF zou moeten zijn gecertificeerd4. Ik heb op dit moment überhaupt nog moeite met het certificeren van architecten, laat staan het certificeren op basis van een boek.
Ik hoopte dat na het uiteenspatten van de internetbubbel we weer met de benen op de grond waren gekomen. Helaas, al heel snel kregen we het luchtkasteel ‘second life’, gevolgd door een SOA-besmetting en nu dan een kind met een waterhoofd ‘TOGAF’. Waar heeft de business - die IT toch broodnodig heeft - dit aan te danken? Ik neem aan dat de opdrachtgever van architectuur nuchterder zal reageren op deze TOGAF-gekte met een houding ‘architecten, dat jullie onderling met TOGAF bezig zijn boeit mij weinig, maar val mij er niet mee lastig!’5. Ik voorzie trouwens een goudmijn voor opleidingsinstituten6 en consultants, want iedere onderneming die haar IT een beetje op orde wil hebben, kan volgens de TOGAF-indoctrinatiemachine niet zonder TOGAF7. Wellicht zullen sluwe consultants instrumenten propageren waarmee TOGAF-compliancy of zelfs de TOGAF-maturity kan worden gemeten?8
Een roemruchte vakbroeder bij Capgemini schreef mij dat er nu een echte wereldstandaard is op het gebied van architectuur. Hij bedoelde natuurlijk een wereldstandaard opgesteld/opgelegd door de bouwers9 van deze wereld. En dat terwijl architectuur toch eigenlijk thuishoort aan de vraagkant. NORA 2.0 had als waarschuwende ondertitel: ‘vóór en dóór architecten’. Ik vind dat in de bijsluiter van TOGAF 9.0 dient te worden opgenomen: ‘vóór en dóór bouwers, uitermate schadelijk voor de creativiteit van architecten’.
Concluderend: TOGAF is een architectuurframework dat zijn wortels heeft in een technisch architectuurframework ontwikkeld door DoD, dat eigenlijk slechts bedoeld was als hulpmiddel voor het informatiemanagement. Het lijkt mij twijfelachtig dat TOGAF ooit deze valse start zal kunnen overstijgen. Als ik de losse eindjes in dit document overzie, vrees ik voorts dat TOGAF 10.0 minstens 1000 pagina’s gaat tellen.
Mijn advies is te stoppen met dit initiatief en een (wereld)standaard te ontwikkelen vanuit de vraagkant, dus een standaard ontwikkeld door onafhankelijke architecten10 en gedragen door de businessmanagers van grote ondernemingen/instellingen.
1 Gepubliceerd in verkorte vorm in de Automatisering Gids, 27 maart 2009, nummer 13, pagina 16.
2 Naast die 700 pagina’s is er trouwens nog ruimte voor duizenden pagina’s nadere uitleg.
3 Plato constateerde al 2500 jaar geleden dat democratie de één na slechtste regeringsvorm is en dat geldt zeker voor IT-projecten/IT-beslissingen.
4 Jammer genoeg moeten alle TOGAF 8.1.1 gecertificeerden opnieuw examen doen in TOGAF 9.0. En dat terwijl ‘TOGAF 8.1.1 gecertificeerd’ veel gründlicher klinkt dan ‘TOGAF 9.0 gecertificeerd’.
5 Er zijn drie categorieën architectuurdocumenten: voor de opdrachtgever/businessmanagers, voor de architecten onderling, voor de bouwer. TOGAF is alleen voor de architecten onderling!
6 Ik vrees opleidingen door docenten die nauwelijks voldoende praktijkervaring hebben met architectuur. Je weet wel, van die beroepspraters: ‘geef mij de transparanten en ik doe wel even de cursus, maakt niet uit waarover’.
7 En, er wordt nog steeds makkelijker verdiend met praten dan met werken.
8 Was dat ook al niet met SOX?
9 Die bouwinvloed zit trouwens ook overduidelijk in DYA, de architectuurmethode met de grootste mindshare in Nederland. Onderwerpen als ‘strategische dialoog’, ‘ontwikkelen zonder architectuur’, ‘projectstartarchitectuur’ en de te grote nadruk op het applicatielandschap tonen dat wij hier te maken hebben met een architectuuraanpak opgesteld door een bouwer uitsluitend ten behoeve van het bouwen.
10 Onafhankelijke architecten zijn architecten die volledig zelfstandig opereren of die op de loonlijst staan van een onafhankelijk, onpartijdig architectenbureau dan wel architecten die in dienst zijn van een consultancybureau dat geen bouwactiviteiten uitvoert (direct noch indirect).
|
