September 2009: NGI-rapport "Wegwijzer voor methoden bij Enterprise Architectuur"

Info: Van Haren Publishing, 1e oplage, augustus 2009, ISBN 978-90-8753-097-6, diverse schrijvers NGI-werkgroep

 

Hoofdstuk 1: Inleiding

Dit hoofdstuk bevat een nogal tendentieuze inleiding voor dit rapport. Het nodige wordt zonder veel uitleg of onderbouwing als waarheid geponeerd, terwijl toch nogal wat kanttekeningen geplaatst kunnen worden bij wat in dit hoofdstuk gezegd wordt. Daarna wordt verteld dat dit boek goed inzicht geeft in het gebruik en de toepasbaarheid van enterprise-architectuurmethoden. Omdat maar elf methoden meegenomen zijn, waarvan de meeste ook nog uit eenzelfde hoek komen, is te betwijfelen of dit rapport inderdaad goed inzicht geeft in de wereld van enterprise-architectuurmethoden. Een zo compleet mogelijk overzicht geeft het niet.

Opmerkingen

Blz 1:

1. "Enterprise architectuur wordt door steeds meer organisaties gezien als een belangrijk stuurinstrument". Deze opmerking is nogal ambigu. In organisaties zien we steeds meer dat men de informatievoorziening vanaf strategisch niveau zodanig wil richten dat het inrichten ervan alleen nog onder strakke regie van de organisatie zelf plaats vindt. Het is bekend dat veel weten van de inrichting van een informatievoorziening, bijvoorbeeld met IT, geen echt grote rol speelt bij het voeren van deze soort regie. Het is immers de kennis van de informatie van een organisatie die dit sturen, regie voeren vanaf strategisch niveau, mogelijk maakt.

Kennis van informatie past niet in wat enterprise architectuur genoemd wordt, en die kennis is daar dan ook niet of nauwelijks in opgenomen. Daarom moet de meest logische uitleg van de hier gemaakte opmerking over "enterprise architectuur als stuurinstrument" op tactisch niveau in organisaties terug te vinden, en dat klopt ook steeds meer in de praktijk.

De regie van de organisatie vanaf strategisch niveau baseert zich dus op kennis van haar informatie en niet of nauwelijks op kennis van IT en/of andere in te zetten hulpmiddelen en oplossingen. Enterprise architectuur helpt vooral tactisch/operationele managers bij het sturen van projecten en exploitatie.

2. Er staat dat het vakgebied van de architect enterprise architectuur is. Ik neem aan dat dit een foutje van de auteurs is en dat hier het vakgebied van de enterprise architect bedoeld wordt.

N.a.v. De gekwalificeerde titel enterprise architect staat in de praktijk voor IT-ers die vooral werken aan IT-oplossingen binnen een IT-infrastructuur die een organisatie ondersteunt (IT-Business Alignment). In kringen van The Open Group is gesproken of het beter zou zijn om de enterprise architect voortaan IT-enterprise architect te noemen. Dit zou inderdaad meer recht doen aan het werk van deze functionaris, waarbij natuurlijk ook de naam enterprise architectuur in IT-enterprise architectuur zou moeten veranderen. Deze aanpassing is uiteindelijk niet doorgevoerd.

3. De opgenomen quote van John Zachman uit 1987: "To keep the business from desintegrating, the concept of information systems architecture is becoming less of an option and more of a necessity". Ik heb John's verhaal de laatste jaren diverse keren gehoord en heb alle reden om te aan te nemen dat hij hier tegenwoordig niet meer zo strict over denkt.

4. Het ontstaan van methoden, talen en hulpmiddelen wordt door de auteurs als een belangrijke ontwikkeling bij het verder professionaliseren van enterprise-architectuur gezien. Tegelijk wordt aangegeven dat het moeilijk blijkt om organisaties en architecten voor de juiste methode te laten kiezen. De opgenomen quote van Jaap van Rees "De methode doet het niet" uit 1983 vertelt juist dat het om de professionele mens en niet om de methode gaat. En die uitspraak blijft juist.

Verderop in de tekst staat dat de auteurs het feitelijk eens zijn met Van Rees: het is de architect die het doet, niet de methode. Afgezien van het punt dat het niet om de persoon maar om de professional gaat: als deze uitspraken van de auteurs samengevoegd worden lijkt het erop alsof de auteurs de uitspraak van Van Rees niet echt begrijpen.

5. Volgens de auteurs hangt het veelal van de volwassenheid van een organisatie af welke methode men kiest. Dit is een losse opmerking in dit rapport, zonder verdere uitleg:
• Er staat niet om welke soort volwassenheid het gaat: business (daarbinnen kunnen vele soorten volwassenheid bestaan), informatie, IT? Gezien het onderwerp van het boek zal het om de volwassenheid van organisaties in relatie tot IT gaan.
• Je vraagt je af wat nu precies bedoeld wordt met deze stelling van de auteurs. Bedoelen zij dat meer IT-volwassen organisaties een zwaardere methode kiezen? Mijn ervaring heeft me juist geleerd dat meer IT-volwassen organisaties juist ook voor zelf gekozen manieren van werken kiezen die aan elkaar gekoppeld worden; zij weten immers wat een bepaalde methode moet doen, en hoe zo'n methode dan past in "hun" methodiek. Of zijn het de IT-onvolwassen organisaties die voor de grote methode kiezen? Met gewoonlijk als gevolg dat er een soort methode-stoomwals door een organisatie ramt die zich daar, al is het van de weeromstuit, meestal enorm tegen gaat verzetten. Onduidelijk.

Dit punt is van de auteurs blijft onduidelijk. De uitspraak blijft ook hangen zonder omdat geen toelichting gegeven wordt van wat precies bedoeld wordt terwijl e.e.a. op meer manieren uitgelegd kan worden.

Deze opmerking van de auteurs kan overigens vrij eenvoudig uitgelegd worden via de kleurentheorie van Prof. dr. Léon de Caluwé. Mensen die vooral in en met structuur denken en werken worden door hem met de kleur "blauw" beschreven. IT-professionals behoren typisch tot een beroepsgroep die met structuur bezig is. Blauw is daarom de kleur die uitstekend bij de meeste IT-professionals past. In organisaties zijn echter mensen met allerlei andere kleuren: rood, groen, geel, wit. Omdat mensen met een gelijke kleur elkaar vaak snel (kunnen) begrijpen is het logisch dat een organisatie waar veel "blauwe" mensen werken (zoals ingenieursbureaus, verkeer, waterstaat, bouw enz.) gemakkelijker openstaan voor de manier van denken van IT-ers dan andere. Zij begrijpen immers wat structuur is, en kunnen daarom de gedachten van IT-professionals sneller volgen.

Omdat er veel organisaties met "anders gekleurde mensen" bestaan is dat nog geen reden om culturele aspecten aan te wijzen als een sterk complicerende factor om IT-methoden in te voeren. IT-methoden, dit rapport gaat over enterprise-architectuurmethoden, zijn er vooral voor IT-professionals. Of die IT-professionals in staat zijn om, terwijl zij gebruik maken van methoden/technieken/hulpmiddelen, te communiceren met hun organisatie hoort bij hun blauwe kleur, en of en hoe ze met anders gekleurden kunnen omgaan. Het is dan niet de methode maar de IT-professional die de "vertaling" moet maken (zie Van Rees). In de praktijk komt dat heel simpel neer op iets als: kan ik, IT-professional, een bepaalde schemasoort direct gebruiken in mijn communicatie met mijn organisatie/gebruiker, of kan ik maar beter de inhoud van een schema bespreken en dat schema voor mezelf houden? Zo is de aanname dat alles via visueel maken helder gemaakt kan worden een typisch blauwe opvatting die lang niet altijd werkt.

De cultuur van een organisatie zo bepalend laten zijn voor het gemak waarmee bepaalde IT-methoden ingevoerd kunnen worden is dan ook wel erg kort door de bocht. Zoals gezegd zijn IT-methoden immers voor IT-professionals, en dus voor mensen met een vergelijkbare denk en werkrichting. Cultuur kan dan alleen een rol spelen als die IT-professionals dit soort methoden door de organisatie zelf laten beoordelen. Omdat er vaak een gapend gat zit tussen IT en organisatie is deze opmerking vanuit IT logisch zijn, tenminste als IT van de organisatie vraagt dat zij een IT taal leren praten. En dat is inderdaad een probleem.

IT is tegenwoordig steeds vaker een "hulpmiddel onder de motorkap". IT moet daarbij, als component, gewoon effectief meedoen aan de behoefte van een organisatie om de juiste informatie op het juiste moment op de juiste plaats te hebben. Omdat bij enterprise architectuur niet of nauwelijks informatiekundige methoden, technieken en hulpmiddelen passen (die horen daar overigens ook niet thuis) zullen informatiekundige methoden en enterprise-architectuurmethoden goed op elkaar aangesloten moeten worden. Sterker nog, het is mogelijk dat veel van wat met informatiekundige methoden vastgelegd is via algoritmen doorvertaald kan worden naar IT-methoden. Daar zijn hele goede voorbeelden van. In dat geval zal het beschrijven van een huidige cq. toekomstige IT-infrastructuur met een enterprise-architectuurmethode nauwelijks meer nodig zijn; de vertaling wordt immers automatisch gedaan.

Daarom is het niet de cultuur van een organisatie die het kiezen en invoeren van enterprise-architectuurmethoden, of, algemener, IT-methoden vooral beperkt, het is de notie van enterprise architecten zelf die de IT-wereld leidend willen laten zijn voor het inrichten enz. van organisaties die beperkt. En ja, het opleggen van structuur in een niet-blauwe omgeving is lastig; men is er niet aan gewend, en wil er vaak niets mee. Sterker nog, met huurt informatie- en IT-professionals in om dat voor hen te doen. En als die professionals dan terugkomen en hen alsnog met structuur confronteren is men niet blij.

7. Quote Van Rees "De methode doet het voor informatie-architecten niet, voor systeemaannemers doet de methode het wel".

   Architecten naast aannemers. In de IT-sector worden softwarehuizen, systeemhuizen, IT-consultancybureaus en IT-opleidingsbureaus samen IT-leveranciers genoemd. Dit zijn de aannemers in de IT-sector. Dit zijn ook de organisaties die enterprise architectuur en enterprise- en IT-architecten aan de markt aanbieden. Plus methoden, technieken en hulpmiddelen om het werk van deze architecten te vergemakkelijken. Informatie-architecten zijn informatiekundigen. Zij passen niet of nauwelijks in waar IT-leveranciers mee bezig zijn omdat zij samen met een organisatie op een rij zetten wat die organisatie met haar informatie wil. Als je dit vergelijkt met de bouwwereld is het de informatie-architect die het best vergelijkbaar is met de bouwkundig architect, terwijl een bouwaannemer vergeleken kan worden met een IT-leverancier. Het vreemde in de IT-sector is dat de enterprise architect bij IT-leveranciers gevonden kan worden; het zijn dus "architecten" die voor aannemers werken cq. die zich met aannemers verbonden hebben. Zoiets mag in de bouwwereld niet voorkomen. Daar wordt het gebonden zijn van een architect met een aannemer, en dat is m.i. terecht, op alle manieren tegengegaan.

   Voor systeemaannemers doet de methode het wel. Logisch. Aannemers doen projecten om nieuwe oplossingen te bouwen of om iets bestaands te vernieuwen. Dat moet methodisch aangepakt worden omdat het werk vaak zo complex is dat het anders snel fout zou gaan. Daarom zoeken aannemers naar goede methoden voor hun projecten, net als dat IT-leveranciers methoden, technieken en hulpmiddelen willen hun IT-projecten. Dit laat trouwens onverlet dat de methode het ook niet doet voor de medewerkers van IT-leveranciers. Ook zij zullen immers zelf moeten weten waar ze mee bezig zijn, en of ze dat nu bijvoorbeeld met de ene of de andere aanpak doen wordt dan minder relevant.

   In de quote van Van Rees worden daarom twee onvergelijkbare grootheden naast elkaar gezet: mensen (informatie-architecten) naast organisaties (systeemaannemers/IT-leveranciers). Het blijkt niet uit de tekst dat de auteurs dit zo begrepen hebben.

Blz 2:

Natuurlijk kan iemand die een methode wil opzetten niet zonder kennis, vaardigheid en ervaring (algemener gezegd: Kennen en Kunnen). Daarmee zal zo iemand in staat moeten zijn om binnen haar/zijn methodologie cq. methodiek aan te wijzen waar de methode toe dient. Maar daarmee zal hij/zij toch echt ook iets moeten doen met haar/zijn kennis, vaardigheid en ervaring om tot een samenstel van goed passende voorschriften en regels te komen die samen de "nieuwe methode" vormen.

De auteurs gaan verder met de volgende twee uitspraken:

• Een architect kan niet zonder methode als een methode een combinatie van (zijn of haar) kennis, vaardigheid en ervaring is.
• Een goede architect kan gemakkelijk zonder methode als een methode een standaard proces is dat, als het stap voor stap gevolgd wordt, min of meer vanzelf tot de juiste resultaten leidt. Waarbij het klakkeloos volgen van een proces niet vanzelf tot succes leidt.

Dit is nogal verwarrend. Resp.:

• Methode = combinatie kennis, vaardigheid en ervaring, dus van het Kennen en het Kunnen van een professional. Als we dit aanvullen met het Zijn, de persoon van de professional, spreken we dan niet over zoiets als de competentie van een professional? We zouden alleen over een methode kunnen spreken als die competentie, zoals gezegd, omgezet wordt naar een verzameling van voorschriften en regels zoals aangegeven in de algemene definitie van het begrip methode.
• Methode = standaard proces dat min of meer vanzelf tot de juiste resultaten leidt. Als een methode zo strak kan zijn zou ik voorstellen om die methode te programmeren. Echter, als het klakkeloos volgen van zo'n methode niet automatisch tot succes leidt, hoe kan het dan zijn dat zo'n standaard proces min of meer tot de juiste resultaten leidt?

Zeker, een professional (dus ook een enterprise architect) kan niet zonder competentie. Maar competentie is geen methode, het is wat de professional Kent, Kan en wie zij/hij Is. En wat heb je aan een methode die min of meer vanzelf tot het juiste resultaat leidt, waarbij dat resultaat niet automatisch een succes is? Zo'n methode wil ik niet, want wat zou ik ermee moeten. Verwarrend.

9. De redenering dat kennis van enterprise-architectuurmethoden standaardbagage is voor enterprise architecten, en dat het daarom voor hen van groot belang is om deze methoden grondig te kennen is een kort-door-de-bocht redenering die past bij de denk- en werkwijze van methode-ontwikkelaars en -verkopers. Vakmensen die hun vak (beter) willen leren kennen zullen dat op basis van de basis van hun vak moeten doen. Daarbij zijn ervaringen van anderen en methoden in feite ter adstructie, ter verbreding en verdieping van wat iemand al weet.

Het is een algemeen slechte zaak om te proberen een vak te leren op basis van methoden, technieken en/of hulpmiddelen. Zo leer je het opzetten van een conceptueel informatiemodel cq. implementatiemodel niet door een database met Oracle, Sybase of DB2 in te richten. Je leert ook niet programmeren met coderen in Java, C++ of Delphi te beginnen. Enzovoort. Het is natuurlijk wel goed om je vak-kennis en -ervaring aan te vullen met de ideeën en ervaring van mensen en organisaties die hun manier van denken en werken op een rij hebben gezet.

Kortom: wie denkt dat hij/zij een IT-vakmens cq. enterprise architect wordt door een TOGAF, DYA, Archimate, BIP enz. cursus te volgen, hoe goed dit cursussen ook kunnen zijn, komt bedrogen uit.

9. Dit rapport bevat slechts 11 van de vele IT-methoden, -technieken en -hulpmiddelen die zich enterprise-architectuurmethode zouden kunnen noemen. Dit is een zeer beperkte verzameling van alle methoden die bestaan. Daarbij komt dat de meeste van de in dit rapport meegenomen methoden op de markt worden gebracht door één of zeer weinig IT-leveranciers. Dit rapport, bijvoorbeeld deze inleiding, ademt ook sterk de mening van een paar IT-leveranciers(s) uit omdat anderen, ondanks de in dit rapport opgenomen interviews, niet aan het woord komen. Dat is jammer. Een gemiste kans waardoor het doel van dit rapport, overzicht en inzicht geven in bestaande enterprise-architectuurmethoden, niet gehaald kan worden.