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 2: Het nut van een enterprise-architectuurmethoden

In het algemeen is dit een zeer zwak hoofdstuk. Op hoofdpunten:

• De auteurs gaan uit van drie vergelijkbare definities van architectuur terwijl er honderden zijn. Dit leidt tot een vierde definitie, die, natuurlijk, vergelijkbaar is. Waarmee men de rest van de wereld, alle andere ideeen en gedachten, links laat liggen. Een enorme beperking, echte tunnelvisie.

 

Opmerkingen

Blz 7:

1. Er staat "Het begrip Architectuur kent meer dan één betekenis.". Dan wordt gezegd dat de eerste betekenis uit de bouwwereld komt, maar dat dat begrip hier verder buiten beschouwing wordt gelaten. Dat is jammer, want het begrip Architectuur in de bouw is een mooi begrip. De auteurs van dit rapport beperken zich tot de informatica (ik neem aan dat de auteurs hiermee de Informatie- en IT-wereld bedoelen).

   Als men zich al tot de "informatica" beperkt is niet logisch dat verderop in het boek de geschiedenis van het begrip Architectuur beschreven wordt vanuit de oudheid, waarbij toch echt over bouwkunde wordt gesproken omdat men toen nog niet zo expliciet over "informatica" sprak. Het is te hopen dat het begrip Architectuur zo geen homonieme betekenis(sen) krijgt, al weet ik dat dat ijdele hoop is.

NB. Ik wil hier toch een idee neerschrijven dat me ooit ingegeven is en dat ik nog steeds gebruik. Stel je voor dat je naar een schitterend oud gebouw staat te kijken. Als je wilt opschrijven wat je dan ziet en hoe dat overkomt krijg je een beschrijving van wat je ziet in termen van waar het gebouw voor bedoeld is (functie), hoe het gebouw in elkaar zit (structuur), hoe mooi het is (schoonheid) en hoe goed het past in haar omgeving (harmonie). Lees boeken over (bouwkundige) architectuur, die komen in grote lijnen hier op neer. Ze beschrijven het beeld van een gebouw, en als je dat goed op papier zet kan een lezer zich dat beeld vormen door te lezen wat geschreven is.

Wat is nu een Architect? Simpel: dat is iemand die dat beeld van dat gebouw heeft voordat het gebouwd is. Een bouwarchitect staat dus voor een (al of niet leeg) stuk land, en bedenkt/weet wat daar gebouwd moet worden zodat het later zo beschreven kan worden als hiervoor aangegeven is. En dat niet alleen, zij/hij weet ook hoe hij/zij dat gebouw op dat stuk land kan/moet realiseren. De architect is gewoonlijk niet de eigenaar van het stuk land, of het latere gebouw. Het beeld dat die architect heeft is gevormd met die eigenaar. Soms in concurrentie met andere architecten, soms alleen. Als er meer zijn, dan zal de eigenaar moeten kiezen zodra hun beelden overgedragen zijn. Zodra besloten is voor een gebouw, dan zal die architect de bouw begeleiden. Want hij/zij is immers degene die weet wat het moet worden omdat zij/hij dat samen met de eigenaar zo afgesproken heeft. En met dat beeld gaat de architect voor en met de eigenaar op zoek naar de aannemer die het gebouw werkelijk gaat bouwen. Maar dan wel volgens het beeld dat de architect heeft, en dat de eigenaar dus kent.

Zo maakt de architect het beeld van wat gerealiseerd moet worden, een beeld dat (later) architectuur genoemd wordt. En de beschrijving daarvan vinden we dan weer terug in de boeken die daar later over geschreven kunnen zijn.

Aardig hier is het relatief jonge begrip harmonie. In feite dus hoe wat zo gepland wordt past in haar omgeving. In de bouwwereld raakt men hier aan het ruimtelijk ordenen, en aan het werk van stedenbouwkundigen. Zij stellen vast dat er een stuk land is waar een gebouw op gezet kan worden, plus de nodige randvoorwaarden waaraan dat gebouw moet voldoen omdat het in de omgeving moet passen.

2. Er wordt gesteld er vele begrippen architectuur zijn "veelal vooraf gegaan door een voorvoegsel". Daarbij wordt ook gesteld dat er verschillende betekenissen gegeven worden aan de aldus gekwalificeerde begrippen, waardoor homonieme en synonieme namen ontstaan zijn. Dat is juist, en zeer vervelend omdat niemand meer weet wat iemand bedoelt als het woord architectuur gebruikt wordt.

   Architectuur heeft altijd iets met overzicht en inzicht te maken. Een architect overziet een geheel zodat iets gerealiseerd kan worden dat bedoeld was om gerealiseerd te worden. Als je er zo naar kijkt zie je dat in de IT-wereld feitelijk maar twee vlakken zijn waar je een architect kunt verwachten:

   • Daar waar de techniek ingericht moet worden, dus het samenstel van hardware, systeemsofware, netwerk enz.
   • Daar waar IT-oplossingen moeten komen die organisaties en mensen helpen in hun werk. Dit laatste wordt ook wel IT-Business Alignment genoemd.

   Er zijn vele kreten die gebruikt worden voor architecten en architectuur in deze vlakken. Voor het eerste vlak wordt vaak de term IT-architectuur gebruikt, want hier gaat het immers om de technologie zelf. In het tweede vlak hebben we het over oplossingen voor "gebruikers". Hier worden vaak termen als Solution Architecture en Enterprise Architecture gebruikt.

   Deze beide vlakken zijn waar IT-oplossingen binnen een informatievoorziening zich bevinden: het aanbod. Een totale informatie infrastructuur bevat tegenwoordig een vaak steeds groter wordend aantal IT-oplossingen, samen de IT-infrastructuur, naast een aantal anders gerealiseerde oplossingen.

   Dan is het nog het stedenbouwkundige, het ruimtelijk ordenen. Vaak wordt dit als de taak van de Enterprise Architect gezien, al is het overzicht en inzicht van die Enterprise Architect gewoonlijk totaal anders dan je hier moet hebben. Hoe je een stad opbouwt is nu eenmaal iets anders dan als je een gebouw binnen dat geheel moet ontwerpen en laten neerzetten. In de Informatie-wereld zien we steeds meer dat informatiekundigen zich ontwikkelen. De term informatiearchitect zou hier goed passen ware het niet dat deze gebruikt wordt door de IT-wereld. Maar daarmee verdwijnt de soort werk niet, integendeel. En voor die soort werk is maar mondjesmaat kennis nodig van IT.

Blz 8:

3. De definitie van de Amerikaanse vereniging van ingenieurs IEEE geeft een sterk technische, maakbare invalshoek aan het begrip Architectuur vanuit de systeemtheorie. Dit past bij eerder gemaakte opmerkingen rond zoals in dit rapport de term Enterprise-Architectuur beschreven wordt en het feit dat het in werkelijkheid gaat om een IT-Enterprise-Architectuur (zie mijn opmerkingen rond hoofdstuk 1). Die maakbaarheid via deze definitie past goed bij het inrichten van een IT-infrastructuur, maar niet zo goed bij het inrichten van een organisatie zelf. Een organisatie is dan misschien ook een systeem, maar wel een systeem van een ander kaliber. Vaststellen dat iets (omdat dat iets ook als een systeem te beschouwen is) op dezelfde manier en met dezelfde methoden aan te pakken is is erg kortzichtig. Zo ook met de term Enterprise-Architectuur; IT-methoden kunnen goed passen om iets met IT-systemen te doen, maar daarom zijn ze nog niet geschikt om in een sociaal systeem te gebruiken. Machine componenten reageren bijvoorbeeld heel anders dan mensen doen op vraagstukken, om een typisch probleem te noemen. En dat is precies wat je in de praktijk ziet als enterprise architecten IT-methoden proberen te gebruiken om "iets" met de werking van een organisatie te "doen". Zo werkt het gewoon niet, al wordt het zo wel geprobeerd.

4. De van Capgemini overgenomen IAF-definitie en de uit zusterorganisatie Sogeti overgenomen DYA-definitie van Enterprise-Architectuur trekken de definitie van IEEE iets breder. Ook hier blijft het echter om "maakbare" systemen gaan. Daarmee lijkt de scope van hoe de auteurs van dit rapport naar de in dit rapport te vergelijken methoden kijken vastgesteld, en dus ook hun scope van kijken naar de wereld: een sterke nadruk op het investeren in IT-oplossingen via IT-projecten. De paragraaf onder de IAF en DYA definitie vertelt dat de schrijvers uitgaan van deze Capgemini + Sogeti definities.

   Curieus is de opmerking dat de opgenomen definities van IEEE enCapgemini/Sogeti een vaste kern hebben waar, volgens de auteurs, iedereen het over eens zou zijn. En dus zou iedereen het er over eens zijn dat het om afspraken, principes en modellen (steeds weer die lijstjes, lijstjes...) gaat. Dit is niet eens een bewijs uit het ongerijmde, het is gewoon onzin. Zodra hier één van zeer vele andere definities van buiten de IEEE/Capgemini/Sogeti-invloedsfeer naast gezet zou worden geldt deze "vaststelling van de waarheid" door de auteurs in het geheel niet meer. Je zou dit wensend denken kunnen noemen, of nog iets dat echt nog onaardiger is; duidelijk is dat dit een fout syllogisme en een echt onjuiste conclusie is. Deze conclusie maakt voor de lezer wel de sfeer alsof het waar zou zijn, en daarmee kan je dus sterk twijfelen aan het gebruik van dit rapport.

5. Dan stellen de auteurs dat de IEEE/Capgemini/Sogeti definities het samen mogelijk maken om een bruikbare definitie van Enterprise-Architectuur te geven: "het deelgebied van de architectuurdiscipline dat zich richt op de organisatie en omgeving". Dit is een erg vreemde "nieuwe" definitie van het begrip Enterprise-Architectuur:

• Wat is dan de architectuurdiscipline? Het vak rond architectuur? Of, beter, het vak van architect? Onduidelijk.
• ...deelgebied van de architectuurdiscipline...: het is dus kennelijk een discipline, een vak met zelfs vakgebieden. En wat zijn die delen, die vakgebieden dan? Programmeren? Bankieren? Ondernemen? Toch IT? Je kunt het ook nog lezen alsof Enterprise-Architectuur zo'n vakgebied is. Maar wat is dan het vak waar Enterprise-Architectuur een deel, een vakgebied is? Onduidelijk.
• ...dat zich richt op een organisatie en omgeving...: zo we al weten wat tot een organisatie hoort en we daar deze "discipline" op los kunnen laten, wat doen we dan met deze discipline in de omgeving van die organisatie? Of is het woord omgeving alleen bedoeld om vast te kunnen stellen dat een organisatie een rand heeft waar je overheen zult moeten kijken? Dat staat er niet. Onduidelijk.

Geen idee wat ik met deze definitie kan, of zou moeten kunnen. Ik krijg het gevoel als of het een soort Deus-ex-Machina is, de verteller die meestal neerdaalt en het einde van het verhaal vertelt en daarmee de oplossing geeft. Het is heel vreemd dat in een boek dat 11 methoden vergelijkt drie definities gegeven worden die daarna in een totaal andere opgaan, waarbij die definitie waarschijnlijk aan geen enkele van de vergeleken methoden ten grondslag ligt. Wat moet je met zoiets. Echt onduidelijk.

6. De Engelse term "enterprise" wordt, kennelijk voor het gemak, door de auteurs niet vertaald met de term onderneming maar als organisatie. Nou zijn er zowiezo, niet alleen in Nederland, problemen met de term enterprise omdat het een nogal verkeerd idee geeft van waar het een architectuur van zou zijn. Geeft het woord enterprise het beeld dat we hebben van op welke manier we ondernemen met onze organisatie? Dat blijkt helemaal nergens uit als je kijkt naar wat er in dit kader mee gedaan wordt. Wat in de praktijk blijkt is dat het om het beeld gaat van de manier waarop een organisatie met IT-oplossingen (IT-Business alignment) ondersteund wordt, met als doel om die organisatie door de inzet van IT beter te laten functioneren. Met links en rechts ideeën als zou ondernemen binnenkort niet meer kunnen zonder IT.

   Een totaal andere reden om Enterprise als organisatie te vertalen ligt in het feit dat je anders geen enkele reden hebt om iets te doen met Enterprise-Architectuur binnen de overheid, non-profit organisaties enz. Een puur commerciële reden, en dat zeggen de auteurs zelfs, die het bereik van de inzet van Enterprise-Architectuur beoogt te vergroten. Een feitelijk oneigenlijke reden die het oneigenlijke gebruik van de term enterprise nog meer geweld aan doet.

   Enterprise-Architectuur brengt niet de enterprise in beeld maar de IT die zo'n "enterprise" ondersteunt. Daarom is die eerder aangehaalde discussie binnen The Open Group om het voortaan maar over een IT-Enterprise Architectuur te hebben ook zo interessant. Als je dan toch ook de overheid enz. binnen je bereik wilt hebben moet je het ook over IT-Organisatie Architectuur kunnen gaan hebben, of over IT-Business Architectuur. Of misschien toch IT-Solution Architectuur. Het woord business heeft weer eigen problemen, trouwens, feitelijk om dezelfde reden als die bestaan rond het woord enterprise. Ook de business architectuur staat onder druk.

7. De gekozen systeemtheoretische invalshoek komt sterk naar voren als de auteurs Enterprise-Architectuur beschouwen via de kenmerken afbakening (de rand van het "systeem"), veranderdynamiek ("systeem"gedrag) en analyseniveau (niveaus binnen het "systeem"). Zoals gezegd is dit een indeling die wel past als het om IT-systemen gaat, maar niet (of minimaal niet goed) als het om andere systemen op andere systeemniveaus gaat.

Blz 9:

8. Afbakening. De auteurs beperken zich tot slechts twee interpretaties/stromingen/visies: ICT met en ICT zonder business en organisatie. Men doet het voorkomen alsof dit de enige keuze is, wat zeker niet het geval is. Ook dit beperkt wat in het rapport beschreven wordt weer stevig.

9. Vooral rond de tekst in de paragraaf Afbakening zelf:
   • Hier wordt ineens over ICT-architectuur (en in figuur 2.1. ook nog over IT) gesproken. Waarom is onduidelijk, het rapport gaat immers over Enterprise-Architectuur.
   • Architectuur of infrastructuur? In figuur 2.1 wordt het woord IT in een blokken gebruikt. Wat daar feitelijk staat is de IT-infrastructuur, en die wordt in drie blokken getoond. Het begrip architectuur ligt er in een ovaal overheen. Normaal zou zijn dat je architectuur als een beeld ziet van een werkelijkheid. De Enterprise-Architectuur in het linkerplaatje is dan in feite het beeld van de IT-infrastructuur en in het tweede plaatje is Enterprise-Architectuur het beeld van IT-infrastructuur en Business-Infrastructuur samen. In beide gevallen mogelijk inclusief afdeling en organisatie, al is dat niet uit de figuur af te leiden. Het punt is nu alleen dat zeer slordig met dit soort begrippen omgegaan wordt, en het plaatje zeker niet eenduidig uitlegt wat bedoeld wordt. Het chinese spreekwoord zegt dat een plaatje meer waard is dan 1000 woorden. Hier geeft het plaatje een zo meervoudig uitlegbare indruk dat veel van die duizend woorden foute woorden moeten zijn. Het grote risico van plaatjes, trouwens.
   • Wordt het woord business gelijkgesteld aan bedrijfsproces en/of organisatie?
   • De auteurs gebruiken de woorden interpretatie, stroming en visie in de tekst. Het zijn woorden die elk een eigen betekenis hebben, maar die in de tekst van het rapport door elkaar gebruikt worden. Onduidelijk.

Slechte tekst, zoals op vele plaatsen in het rapport. Laat ik maar proberen het bij de inhoud te houden.

10. Enterprise-Architectuur kent dus volgens de auteurs twee interpretaties: ICT-architectuur met of zonder business en organisatie zijn. Opmerkingen:
    • Enterprise-Architectuur als een bredere ICT-architectuur, dus niet beperkt tot één organisatiedeel. Wat er echter niet staat is of deze interpretatie van Enterprise-Architectuur over de hele breedte van de "Enterprise" gaat of niet. Dus kunnen er nog steeds meer Enterprise-Architecturen in een "Enterprise" zijn.
    • Enterprise-Architectuur nu vooral in relatie met organisatie, bedrijfsprocessen, informatie, applicaties en technische infrastructuur (dit lijkt een beetje op de oude ideeën van Don Tapscott, trouwens). Hier kan de breedte van de ICT-architectuur zich ineens weer wel beperken tot één organisatiedeel. En er staat niets over wat gedaan wordt met de genoemde vijf "gebieden" en ook hier kunnen er dus vele Enterprise-Architecturen zijn in een "Enterprise" zijn.

    Deze tweedeling lijkt volledig arbitrair: de breedte is niet bepaald, over diepgang wordt niets gezegd, over een eventuele relatieve diep gang wordt niets gezegd en over allerlei soorten alignment tussen de vele gebieden wordt niets gezegd. De keuze voor de tweede interpretatie van Enterprise-Architectuur is daarmee ook volledig onhelder.

    Wat de tweede interpretatie vaak inhoudt is dat de Enterprise Architect vaak ook bezig gaat het organiseren van wat de business (ook bedrijfsproces, organisatie, afdeling, enterprise enz.) genoemd wordt. De auteurs stappen hier even snel overheen, maar daar zitten gewoonlijk wel problemen. In het voorgaande heb ik al aangegeven dat IT-professionals problemen hebben om in termen van business te denken en te werken omdat ze er als IT-professionals mee en aan willen werken. En dat gaat niet. Veel werk gaat dan ook fout als deze IT-professionals of Enterprise-Architecten zich met "de business" gaan bezig houden. IT-achtige methoden en technieken werken vrijwel altijd alleen maar onder zeer bepaalde voorwaarden, en vaak dus niet.

    In dit rapport wordt geen limiet aangelegd. Het probleem voor Enterprise-Architecten ligt vooral in, wat de auteurs noemen, organisatie, bedrijfsprocessen en informatie. En meestal wat minder in de technische infrastructuur, Enterprise-Architecten hebben daar vaak hun core-competentie en zijn "doorgegroeid". Wat het beste werkt voor Enterprise Architecten is als men het brandpunt bij de applicaties (en gegevensbestanden) legt, en ervoor zorgt dat ergens zoveel kennis van organisatie, bedrijfsprocessen en informatie is dat deze applicaties enz. goed in lijn (aligned, dus IT-Business Alignment) komen met die andere gebieden die vooral door andere specialisten goed aangepakt zijn/worden.

11. Dan is er ineens een vijfde definitie van Enterprise-Architectuur: "de discipline binnen het vakgebied van de architectuur die zich richt op de structuur en samenhang binnen een organisatie vanuit een bredere visie dan alleen de ICT-omgeving". Met de volgende opmerkingen:
    • Enterprise-architectuur is hier een discipline binnen het vakgebied architectuur. Een discipline is een "tak van wetenschap" (of "gehoorzaamheid aan voorschriften en bevelen"), een vakgebied is "onderdeel van een bepaald vak waarop men zich heeft gespecialiseerd". Dus Enterprise-Architectuur is een tak van wetenschap binnen een onderdeel van het vak architectuur waarop men zich heeft gespecialiseerd. Architectuur als vak? Enterprise-Architectuur als een deelwetenschap binnen een onderdeel van het vak architectuur? Wordt binnen "het vakgebied van de architectuur" dan ook de architectuur in de bouw, of de tuinarchitectuur of de marinearchitectuur gezien?
    • "structuur en samenhang". Vaak wordt van Vitruvius uitgegaan, die het over structuur, functie en schoonheid heeft. Ik voeg daar zelf graag harmonie van Alberti aan toe. Dan is structuur en samenhang wel heel erg kort door de bocht.
    • "structuur en samenhang binnen een organisatie". Een organisatie is veel meer dan structuur en samenhang. Is dat het enige waar Enterprise-Architectuur naar kijkt? Als dat het geval is is het logisch dat aldus gedefinieerde IT-Business Aligment zo vaak de plank mis slaat.
    • Wat is hier nu de "bredere visie dan de ICT omgeving"? Allereerst het woord visie, er lijkt een beschouwingsgebied, een werkgebied bedoeld te worden. Maar wat heeft dat te maken met het woord visie: wijze van zien of waarnemen?

Ik kan deze definitie heel moeilijk begrijpen. Enterprise-Architectuur is geen discipline, het is een bepaalde kijk op de wereld. Als ik dit als definitie van de Enterprise-Architect probeer kom ik verder. Alleen zie ik niet dat er een vakgebied architectuur zou zijn, waarbinnen het vak van de Enterprise-Architect zou passen. Kennelijk naar dat van de bouwarchitect, de tuinarchitect, de marine-architect en mogelijk nog een paar. En dan de praktijk waarin Enterprise-Architecten zich met en rond IT bezig houden in organisaties. Nu zijn dat natuurlijk ook elementen met structuur en samenhang binnen een organisatie, maar zo zal dat niet bedoeld worden. Als ik het laatste stuk dan zie als dat men breder dan alleen IT wil kijken begint er op te lijken. Maar wat er staat is meer dan een legpuzzel, maar een soort cryptische omschrijving.

Dan de relatie met de vierde definitie Enterprise-Architectuur op bladzijde 8 "het deelgebied van de architectuurdiscipline dat zich richt op organisatie en omgeving". Dit geeft mij het gevoel: wat willen deze auteurs nou? Het lijkt wel of ze willen dat de lezers van dit rapport zich verspreiden. Zou wel een goede manier zijn om mensen te "helpen" om al die verschillende meningen weer op een lijn te krijgen....

12. Dan staat er dat architectuur, aan te nemen is Enterprise-Architectuur, als managementinstrument te gebruiken om ontwikkelingen beheerst en in samenhang te sturen. Een zesde definitie: architectuur is een managementinstrument? En wat zijn ontwikkelingen? De verder ontwikkeling van een IT-infrastructuur door het uitvoeren van IT-projecten? En dan dat beheersen en sturen?

Wat een chaos, dit hoofdstuk tot nu toe.

 

 

Ps. de zinsnede "...samenhang tussen die ICT-omgeving en de rest van de organisatie" is speciaal. ICT is dus kennelijk deel van de organisatie zelf en geen hulpmiddel dat binnen een organisatie ingezet kan worden.

 

IT-centric

Afbakening. Er wordt hier over twee stromingen gesproken: Enterprise-Architectuur als geheel van IT binnen een organisatie en Enterprise-Architectuur die zich naast op IT ook de organisatie omvat. Men kiest daarbij voor de tweede stroming. Deze keuze is in de praktijk onhaalbaar en onwerkbaar omdat de meeste organisaties niet maakbaar zijn.

De logische keuze en de manier zoals het in de praktijk ook past is als Enterprise-Architectuur als de combinatie van IT-oplossingen die werken op een technische IT-infrastructuur inclusief de manier waarop deze IT-oplossingen passen bij de organisatie (wat alignment genoemd wordt).

In de praktijk blijkt dat beide beschreven stromingen niet juist zijn omdat de hardware, systeemsoftware, netwerk enz. buiten de scope van de Enterprise Architect blijft. Tevens gaat het vrijwel nooit goed als IT-ers, en dus Enterprise Architecten, organisaties gaan inrichten. Vanuit de theorie is dit ook logisch omdat de door de schrijvers gekozen stroming 3 of nog meer systeemniveaus omvat. Het blijkt dat de mensen die zo breed bezig willen gaan zichzelf tegenkomen als ze van systeemniveau zouden moeten wisselen.

De in de rapport gekozen afbakening is daarom veel te breed, en werkt in de praktijk niet. Uit de praktijk lijkt te komen dat zo'n brede afbakening ook niet kan werken.

Omdat informatie het bedrijfsmiddel (strategisch/tactisch) en IT een (tactisch/operationeel) hulpmiddel in organisatie is, is het de vraag of een Enterprise-Architectuur een algemeen managementinstrument kan zijn. Het kan Een managementinstrument voor ontwikkeling, hierboven noem ik dat investering, voor tactisch/operationeel management is wel goed mogelijk. Alleen mist dit rapport dan wel het instrument dat voor strategisch/tactisch management nodig is. Dit is ook precies wat de praktijk laat zien; de meeste methoden in dit rapport werken niet of nauwelijks op strategisch/tactisch niveau.

 

 

8. veranderdynamiek ("systeem"gedrag) en

   Veranderdynamiek. Hier wordt gesproken over het structuur aan brengen in de dynamiek van een organisatie. Het woord structuur hier is totaal anders dan de structuur die in een systeem zit. Zeker, je kunt elementen uit een Enterprise-Architectuur gebruiken om verandervraagstukken op de juiste manier aan te pakken. Als je echter de veranderkundige theorieen volgt is structuur ("blauw") maar een klein deel van wat nodig is om op de juiste manier veranderingen in te zetten en door te voeren. Het is daarom haast ondenkbaar dat Enterprise-Architectuur, op de manier zoals deze in de beschreven methoden neergezet wordt, het stuurinstrument voor veranderingen kan, en zal zijn. Sterker nog, structureren als voornaamste basis om te veranderen werkt in de praktijk vrijwel altijd averechts. Dit is precies de kloof in denken en werken van de veranderaar versus de IT-er, ook de Enterprise Architect.

9. analyseniveau (niveaus binnen het "systeem").

   Analyseniveau. Hier wordt gesteld dat het (her)structureren van een organisatie een hoger beschouwingsniveau is voor het (her)structureren van IT-systemen. Dit is een klassieke denkfout, die bijvoorbeeld erg sterk de ondergang van de methode ISAC in de jaren 80 heeft ingeluid. Einstein bedoelde dat je in concepten moet denken om de invulling van die concepten in een organisatie goed te kunnen begrijpen. Dit is een totaal andere manier van een hoger beschouwingsniveau dan de schrijvers van dit rapport omarmen. Zo is bijvoorbeeld bekend dat een informatie-analyse om een specificatie van eisen te maken feitelijk maar 10 concepten kent, die in alle organisaties op zeer vele manieren ingevuld worden.

11. a

 

 

Het is trouwens wel waar dat de manier waarop een organisatie werkt goed bekend moet zijn om goed passende IT-oplossingen te kunnen realiseren. De enige manier waarop dit werkt is als iemand de inrichting van de organisatie beheert naast degene, hier de Enterprise Architect, die de inrichten van de ondersteunende IT beheert. Juist de samenwerking tussen deze twee mensen kan snel enorme synergie opleveren, waarbij degene die de inrichting van de organisatie beheert juist geen IT-er zal zijn.

Toepassing. Hier staat dat (enterprise) architectuur de basis is om veranderingen door te voeren. Hier staat dus dat (enterprise) architectuur vooral de opstap naar investeringen is. Vergeten wordt dat het in kaart brengen van IT-oplossingen over het aanbod van oplossingen gaat en niet over de vraag naar informatie van een organisatie. Wat deze vraag is en hoe deze past bij de veranderende organisatie wordt nergens in dit rapport beschreven.

Gesteld wordt dat een enterprise architect bedrijfsdoelstellingen en strategische visie vertaalt naar de gewenste doelsituatie (= de gewenste IT-infrastructuur). Dit zijn veel te veel stappen om zomaar in één keer te zetten. De Enterprise-Architectuur, zoals deze hier gedefinieerd wordt, is daarbij alleen maar zeer zijdelings te gebruiken. Juist de inrichting van de huidige IT beperkt een optimaal effectieve inrichting van toekomstige IT-ondersteuning sterk. Logisch, want je kunt het aanpassen van huidige IT-aanbod met zoiets algemeens als een strategie in gedachten niet laten leiden tot een echt goede nieuwe inrichting. Dat kan alleen maar als de vraag goed bekend is, en dat is geen onderdeel van wat hier Enterprise-Architectuur genoemd wordt.

In organisaties ontstaat slechts beperkt de vraag naar iets dat zowel descriptief als prescriptief is. Er is behoefte aan de juiste kennis op basis waarvan men het beste kan doen. Er zijn diverse soorten kennis die goed naast elkaar beheerd en ontwikkeld zal moeten worden. Enterprise-Architectuur zou de kennis van IT-oplossingen en de aansluiting daarvan op de organisatie moeten omvatten. Dat wordt in dit rapport nogal uit zijn verband gerukt doordat er een aantal elementen uit andere vakgebieden onder de term Enterprise-Architectuur wordt gebracht. Het gaat niet alleen om structuur en om het ordenen daarvan. Het gaat ook om de toegevoegde waarde van de functie, het mooie en het gemak en de aansluiting met de rest. Van deze 4 elementen wordt in dit rapport maar 1 element meegenomen, en dat beperkt het geheel erg sterk. Verder gaat het, zoals ik al eerder gezegd heb, niet vooral om het realiseren van veranderingen. Dat is waar de IT-leverancier zich op richt omdat dat voor hen omzet is. Het gaat om veel en veel meer.

Methoden en raamwerken. "Een Enterprise-Architectuurmethode is een systematische manier om te komen tot een Enterprise-Architectuur". Met de volgende opmerkingen:

Hoe deze definitie zich laat rijmen met de titel van het rapport "Wegwijs voor methoden bij Enterprise-Architectuur" is onduidelijk. Hier staat dat de methode de manier is om een Enterprise-Architectuur te maken.

Als Enterprise-Architectuur de kennis is die er is over de IT-oplossingen die een organisatie samen ondersteunen, dan is dit een sterk beperkte definitie. Immers, Enterprise-Architectuur is dan niet iets dat je een keer opzet, maar iets dat je beheert en ontwikkelt. Het is dus geen project, maar een continue aktiviteit die voortaan uitgevoerd zou moeten blijven worden. Want het op een rij zetten wat je weet van de IT-oplossingen van een organisatie is feitelijk verouderd zodra die opgezet is. Dus moet deze bijgehouden worden. Met deze definitie lijkt het op de situatie die in het 90-er jaren ontstond rond informatieplanning, waarbij eenmaal een plan opgesteld werd dat vaak 5 of 10 jaar later weggegooid is. Is dat ook het voorland van Enterprise-Architectuur zoals die hier gepresenteerd wordt? In de praktijk lijkt het daar erg sterk op.

Opmerkingen ten aanzien van de kenmerken van een goede Enterprise-Architectuurmethode:

Het doel van de methode. Ook hier lijkt het alsof je diverse doelen kunt hebben om een methode om tot een Enterprise-Architectuur te komen zou hebben. Deze verschillen zullen wel uit de beschreven methoden naar voren gekomen zijn. Dit is erg vreemd XXXXXXXXXXXXXx blz 13