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 5: Elf enterprise-architectuurmethoden

In het algemeen

 

Opmerkingen

1. aaa
2. aaa
3. aaa

Hoofdstuk 5: Elf enterprise-architectuurmethoden

In dit hoofdstuk worden 11 enterprise-architectuurmethoden beschreven, te weten (alfabetisch) Amsterdams raamwerk voor informatiemanagement (ook wel het 9-vlak genoemd), ANSI/IEEE 1471-2000, Archimate, BIP, DEMO, Dragon1, DYA. IAF, RUP, TOGAF en Zachman. Opmerkingen rond dit hoofdstuk:

Een enterprise-architectuurmethode zou een verzameling van voorschriften en regels moeten zijn, die werkelijk worden gehanteerd of die gehanteerd zouden moeten worden bij het uitvoeren van wetenschappelijk onderzoek of, zoals bedoeld in dit rapport, bij het oplossen van praktijkproblemen. In dit geval het opzetten, ontwikkelen en/of beheren van de (IT-)Enterprise Architectuur van een organisatie. In dit rapport worden 11 zogenoemde enterprise-architectuurmethoden met elkaar vergeleken. Het gaat om:

Amsterdams raamwerk voor informatiemanagement, ook wel het 9-vlak genoemd. Volgens de schrijvers is dit raamwerk feitelijk geen enterprise-architectuurmethode, het zou dienst kunnen doen naast andere enterprise-architectuurmethoden. Gezien het beschrevene wordt uitgegaan van een nogal gekunstelde uitwerking van dit raamwerk binnen de Nederlandse overheid. Een totaal andere uitleg en uitwerking geven Abcouwer en Truyens, mede-ontwikkelaars van dit raamwerk. De kracht van het raamwerk wordt door hen als basis voor audits en evaluaties gebruikt, en daar komt het raamwerk ook krachtig uit de verf.
Daarmee wordt ook gelijk het gebrek aan kracht van het spindiagram in de positionering helder. Dit raamwerk is een classificatieschema en past niet in de definitie van architectuur en methode die de schrijvers aanhangen; architectuur als het nieuwe woord voor specificatie-van-eisen in methoden om nieuwe IT-oplossingen te realiseren. De conclusie van de schrijvers doet dit raamwerk dan ook zwaar te kort. 9-vlak een

ANSI/IEEE 1471-2000. Dit is een standaard die door het Institute of Electrical and Electronics Engineers (IEEE, de Amerikaanse vereniging van ingenieurs) in samenspraak met de Amerikaanse standaardisatie organisatie American National Standards Institute (ANSI) is geschreven. Het hoofddoel was (architectuur)beschrijvingen van software intensieve systemen vast te leggen i.c.m. best-practices uit het vakgebied IT. Het is dan ook geen methode maar, zoals een standaard hoort te zijn, een verzameling van begrippen en beschrijvingen die de basis voor methoden zouden moeten vormen.
Het punt is dat deze standaard begrippen vaststelt die gericht zijn op het ontwikkelen van software. Buiten het feit dat het geen methode is omvat deze standaard bijvoorbeeld maar een klein deel van de begrippen waar bijvoorbeeld in het Amsterdamse raamwerk over gesproken wordt (onderste rij, rechterkant). Hoe hier een spindiagram uit kan komen dat meer zou weergeven dan dat van het Amsterdamse model is dan ook een raadsel: het gaat immers vooral ergens anders over.

Archimate. Archimate is een diverse Nederlandse organisaties, in het begin vooral door Ordina, binnen de Universiteit Twente opgezet hulpmiddel dat bij het documenteren van IT-oplossingen gebruikt kan worden. Via Capgemini is Archimate gelieerd aan de enterprise-architectuurmethode TOGAF van The Open Group.
De schrijvers zien Archimate vooral als een modelleertaal die helpt bij het ontwikkelen van architectuurproducten. Archimate is dus ook geen enterprise-architectuurmethode, het is een taal die zich kan vormen naar een bestaande enterprise-architectuurmethode waarbij software bestaat waarmee je kunt documenteren. Het kan dan zo zijn dat Archimate diverse enterprise-architectuurmethoden kan documenteren, dat rechtvaardigt nog niet dat het zo hoog scoort in het spindiagram. De methode dient immers te bepalen, en dit is een hulpmiddel gebaseerd op taal, hoe waardevol zoiets ook kan zijn.

Business Informatie Planning (BIP). BIP is een door Novius Adviesgroep. Zoals de schrijvers vertellen is BIP een informatieplanningsmethode met verbindingen naar architectuur. Dus ook hier weer geen enterprise-architectuurmethode, maar een aanpak die zo’n methode zou kunnen aanvullen. Ook hier weer een redelijk gevuld spindiagram, terwijl de schrijvers duidelijk aangeven dat het niet om een enterprise-architectuurmethode gaat.

DEMO. DEMO is een binnen de Technische Universiteit Delft door emeritus prof Jan Dietz ontwikkelde methode voor het in kaart krijgen van de verschillende bedrijfsprocessen van een (deel van een) organisatie. Daarbij wordt met DEMO de basis gelegd voor Information Systems Engineering omdat zeer scherp en expliciet aangegeven wordt welke bedrijfsprocessen een organisatie heeft. Als zodanig kan precies aangegeven worden welke behoefte aan informatie een organisatie binnen de resp. bedrijfsprocessen heeft, en dus welke oplossingen, al of niet met IT gerealiseerd, ontwikkeld moeten worden.
Ook hier geldt weer dat DEMO geen enterprise-architectuurmethode is in de definitie die de schrijvers in dit rapport geven. Het legt een stevige basis voor een enterprise-architectuurmethode. Daarom ook hier weer de opmerking dat de relatief hoge score in het spindiagram vreemd is, want ook hier spreken we, zoals de schrijvers zelf ook opmerken, dus niet over een enterprise-architectuurmethode.

Dragon1. Een manier van denken en werken rond het ontwikkelen van IT-oplossingen van de Nederlandse IT-er M. Paauwe. Daarbij is vooral en vooreerst visualiseren het doel. Dit is de kracht, en tegelijk het zwakke omdat relatief weinig van wat nodig is bij het realiseren van IT-oplossingen gevisualiseerd kan worden. Daarbij zal vooral gedacht worden aan wat tijdens systeemontwikkeling in modellen uitgeschreven kan worden.
Het is wat speciaal dat Dragon1 als enterprise-architectuurmethode in dit rapport opgenomen is omdat het geheel zo weinig verspreid is. Daarbij komt een verbazingwekkend vol spindiagram bij een methode die zo beperkt is.

Dynamische Architectuur (DYA). DYA is de methode dat door het softwarehuis Sogeti in de markt wordt gezet. Het geeft een algemeen werkmodel waarbinnen vier te besturen (ontwikkel)hoofdprocessen van IT-oplossingen ingekaderd worden, ondersteund door een drietal architecturen waarbinnen kennis over elementen als producten, processen, organisatie, gegevens, applicatie, middleware, platform en netwerk een plaats krijgen. Men probeert daarbij een inschatting te maken van hoe volwassen een organisatie al is m.b.t. de inzet van haar IT.
Doel van DYA is om de IT-infrastructuur verder te ontwikkelen en om de nodige investeringen daarvoor in kaart te krijgen. Voor een gedetailleerde evaluatie van DYA, zie deze evaluatie.
Grappig is dat de schrijvers vooral het hoofdproces “Ontwikkelen zonder Architectuur” als de kracht van DYA aanwijzen. Dit leest als een contradictio in termen, want DYA zou een enterprise-architectuurmethode moeten zijn. Men zegt zelfs letterlijk dat het zonder (enterprise) architectuur werken voor acceptatie van een enterprise-architectuurmethode door stakeholders zorgt. Verder stellen de schrijvers, waaronder de ontwikkelaar van DYA, dat er weinig aandacht is voor modellering en dat ook geen ondersteunende tooling voor DYA bestaat. Dat om die reden gebruik gemaakt wordt van Archimate, ook als enterprise-architectuurmethode beschreven in dit rapport, en van UML, als onderdeel van de enterprise-architectuurmethode RUP beschreven. Hoe het spindiagram voor deze enterprise-architectuurmethode dan zo goed gevuld kan zijn is wederom een raadsel.

Integrated Architecture Framework (IAF). Een door Capgemini op de markt gebracht classificatieschema, waarbij Capgemini zelf aangeeft dat het verouderd is en dat het geheel binnenkort door de enterprise-architectuurmethode TOGAF zal worden vervangen. Volgens de schrijvers komen veel andere van de beschreven enterprise-architectuurmethoden samen in IAF: de definities van ANSI/IEEE 1471-2000 en van TOGAF. IAF zelf is van origine een stevige abstractie van het classificatieschema Zachman’s raamwerk, waaraan later invalshoeken als governance, security, organisatieniveaus, ontwikkelpaden, best-practices, toegevoegd zijn.
IAF is dus in de basis, net als Zachman, een classificatieschema. Feitelijk dus geen enterprise-architectuurmethode, en dus weer verbazing over het gevuld zijn van het spindiagram. Waarom de schrijvers het hier nodig vinden om te vertellen dat IAF beperkt wordt door het feit dat het een beschermde aanpak van Capgemini is, is niet helder. Datzelfde geldt immers ook voor andere enterprise-architectuurmethode (bijvoorbeeld Dragon1).

Rational Unified Process (RUP), Unified Process (UP) en Unified Modelling Language (UML) en Enterprise Unified Process (EUP). RUP etc. is een onder de Object Management Group (OMG) ontwikkelde methode voor het ontwikkelen van IT-oplossingen. Zoals de schrijvers zelf zeggen is RUP etc. zeker geen enterprise-architectuurmethode. Hoe dit nu past bij de definitie van architectuur die de schrijvers zelf geven is een raadsel. Als een enterprise-architectuurmethode alleen gaat over zaken die rond het ontwikkelen van IT-oplossingen zelf gedaan moeten worden komt er kennelijk niets uit dat in de praktijk van een organisatie gebruikt kan worden, terwijl RUP etc. IT-oplossingen realiseert en implementeert. Als enterprise-architectuur zo smal gedefinieerd wordt is de toegevoegde waarde alleen kaderstellend; daarmee wordt het geld dat er aan besteed wordt dus alleen terugverdient als het realiseren van IT-oplossingen zelf tot betere resultaten leidt. Wat een ontzettend smalle basis voor een business case geeft. Dan wordt het ook erg vreemd als RUP binnenkort door OMG “omgebouwd” wordt naar een enterprise-architectuurmethode, want, gezien de commentaren van de schrijvers, zal dat dan dus iets anders moeten zijn. Onbegrijpelijk.
Omdat ook RUP etc. geen enterprise-architectuurmethode is komt de vulling van het spindiagram vreemd over.

The Open Group Architecture Framework (TOGAF). TOGAF is een door The Open Group, een commercieel samenwerkingsverband van de IT-leveranciers Capgemini, HP, IBM, NEC, SAP, Sun naast HSBC-bank, ontwikkelde enterprise-architectuurmethode.

Zie een twee

Allemaal eigen principes, geen algemene. Incoherent en inconsistent verzameling van best practices. Jan Dietz

11. The Zachman Enterprise Framework. Het gaat hier om het door John Zachman in de 80-er jaren ontwikkelde raamwerk dat door hem een classificatieschema van de elementen die komen kijken bij de inzet van IT genoemd wordt. De schrijvers stellen dat het een structuur is voor het beschrijven van onderdelen van de enterprise. Dit is verrassend, omdat ze daarmee de mening van Zachman over zijn eigen raamwerk aanpassen omdat het alleen over IT in de context van de organisatie gaat. Grappig daarbij is dat Zachman zelf, als topadviseur, zich vooral toelegt op het invullen van de motivatie-cel, rechtsboven in zijn raamwerk.
De schrijvers noemen het geheel kompleet, zonder tekortkomingen, maar stellen gelijk dat het jammer is dat er geen (enterprise-architectuur)methode bij gegeven wordt. Daarmee kennen zij de waarde van het Zachman raamwerk alleen als aanvulling van TOGAF, en ontkennen daarmee de kracht van een classificatieschema zoals ze dat ook rond het Amsterdamse raamwerk voor informatiemanagement hebben gedaan. Jammer.
Het spindiagram is minimaal en dat is logisch omdat het Zachman raamwerk geen enterprise-architectuurmethode. Maar het ontkent wel de kracht die zo’n raamwerk, al is het raamwerk van Zachman zo langzamerhand wel verouderd, aan een organisatie kan geven.

Zachman: classificatieschema, geen architectuur.

Verkooprapport van TOGAF, waarbij de andere genoemde enterprise-architectuurmethode hoogstens aanvullend kunnen zijn op deze door Capgemini cs. op de markt gebrachte aanpak.