English version
		Nederlandse versie
Steven's Weblog (Nederlands) Iedereen kan informatie van deze weblog overnemen onder de voorwaarde dat hij/zij blijft verwijzen naar deze weblog.
18 oktober 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 Dit rapport in boekvorm is geschreven door een groep IT-ers die elkaar gevonden hebben binnen NGI, een Nederlands platform voor ICT-professionals. Het vergelijkt de methoden, technieken en hulpmiddelen die deze IT-ers gebruiken in hun werk in de IT. Het rapport heeft een curieuze titel meegekregen: “Wegwijzer voor methoden bij Enterprise-Architectuur”. Bij? Net of methoden iets bij een kopje thee zijn. Je zou verwachten dat methoden, voorgeschreven manieren van werken gevolgd dienen te worden bij het ontwikkelen van Enterprise-Architectuur. Geef een reactie -- Terug naar het begin Algemeen beeld Dit NGI-rapport is een vlees noch vis, en dan zeg ik het echt heel erg netjes. Dit rapport kan hoogstens als een verkoopverhaal voor de "enterprise-architectuurmethoden" TOGAF en DYA gezien worden. De schrijvers diskwalificeren de andere opgenomen methoden door aan te geven dat het geen methoden zijn. 9 , waarbij de andere "methoden" alleen als aanvulling als dat nodig is. In dit rapport wordt rijp en groen behandeld. Van vergelijken is geen sprake omdat de schrijvers veruit de meeste opgenomen methoden als geen methode beschrijven. Buiten commercie dient dit boek geen doel gehanteerde begrippen methode, enterprise-architectuur zeer onduidelijk en dubbel beschreven. de keuze voor de methode is een zeer beperkte verzameling vergelijking in hoofdstuk 6 is pure onzin omdat de positionering via spindiagrammen in hoofdstuk 5 11 kompleet andere interpretaties van de in die diagrammen gehanteerde begrippen laat zien. Zo worden koeien met paarden, vissen en vogels vergeleken, wat een totaal onzinnige uitkomst geeft. Het is een raadsel hoe de methoden die in dit rapport beschreven worden passen in de werkelijkheid van een organisatie. Een methode is XX waarmee iets bereikt moet worden. Dat is kennelijk de enterprise-architectuur van een organisatie. Alleen hoe die enterprise architectuur dan gebruikt gaat worden om organisatie verder te helpen in hun wens om vooruit te komen is volledig onduidelijk. Dit is onbegrijpelijk, want de relatie is op zich simpel en gemakkelijk weer te geven. Maar rond de hier beschreven methoden, behalve RUP, is onduidelijk wat de schrijvers zien als toegevoegde waarde naar een organisatie. Dit is trouwens voor dit soort methoden meestal nauwelijks vastgesteld. Mijn advies is om dit rapport snel te vergeten. Daarnaast adviseer ik de schrijvers om vakgebieden in de informatie- en IT-sector serieus te gaan beschouwen en niet op de ijselijke manier die in het rapport naar voren komt. Geef een reactie -- Terug naar het begin Persoonlijke noot Het blijft een raadsel waarom over methoden voor Enteprise Architectuur (veel beter: IT-Enterprise Architectuur) wordt gesproken. De in dit NGI-rapport gepropageerde methoden TOGAF en DYA leveren voor organisaties ontzettend veel werk op terwijl TOGAF-fers en DYA-ers niet kunnen of willen vertellen waar hun "methode" nu eigenlijk toe leidt. In The Open Group zelf spreekt men over jaren werk voor een grote groep mensen voordat de, in dit geval TOGAF, IT-Enterprise Architectuur er is, waarna de procesgang continu herhaald moet blijven worden. En wat heb je dan? Kennis en ervaringen van de hoe de IT van een organisatie in elkaar zit, en hoe deze past bij de organisatie vanuit IT-perspectief. In feite alles wat je NIET nodig hebt om echt verder te kunnen komen. En dat blijkt in de praktijk ook wel, want we blijven al tientallen jaren cirkelen rond wat we al jaren verfoeien: wat IT-er de IT-legacy van een organisatie noemt. Een enterprise-architectuurmethode zou een aanpak zijn om de enterprise-architectuur op te zetten. En, hopelijk, te onderhouden. De beste benadering van wat een IT-Enterprise Architectuur is, is waarschijnlijk kennis van de IT van een organisatie, gecombineerd met ervaringen die men met en rond die IT heeft. Iets beters is niet te vinden. Hoe deze "kennis" zich nu verhoudt tot het realiseren van IT-oplossingen wordt door velen grijs gehouden. Is ook lastig, want hoeveel kan je met kennis van bestaande IT als je een nieuwe IT-oplossing moet creeeren. In dit rapport wordt hier (vrijwel) niets over gezegd. In de praktijk is niet een IT-Enterprise Architectuur van groot belang, maar juist de vraag naar informatie van de organisatie. Uitwerken wat de informatie van een organisatie is en waar men in de organisatie eigendom of behoefte heeft aan bepaalde informatie is cruciaal om te weten wat voor oplossing, al of niet met IT, gerealiseerd moet worden. Een organisatie zal immers alleen in administratieve IT moeten en willen investeren als men daarmee een goede oplossing voor problemen in de informatievoorziening kan realiseren. Dit alles vormt dus geen onderdeel van de IT-Enterprise Architectuur. En als informatie en bedrijfsprocessen daar al deel van uitmaken, dan worden die meestal vanuit een IT-achtergrond bekeken. De opgenomen methode DEMO is hard op weg om daar een uitzondering op te zijn. Organisaties hebben hoogst zelden goede kennis van hun informatie, en zij ontwikkelen en beheren die kennis dus ook niet of nauwelijks. Wie zich realiseert dat die kennis van informatie feitelijk de inhoud van een specificatie van eisen voor de realisatie van IT-oplossingen (in de praktijk heet dat ook vaak een specificatie, een definitie studie, een business case, een informatie analyse en diverse andere namen) feitelijk de eisen die een organisatie stelt aan wat men gerealiseerd wil hebben, waar men in investeert. Een goede informatiepositie van een organisatie betekent dat men precies kan vragen wat men wil hebben, en dus ook precies kan bepalen of wat gerealiseerd is aan hun eisen voldoet. Een echte basis voor strakke regie, dus. En geen onderdeel van een IT-Enterprise Architectuur. outsourcing. Geef een reactie -- Terug naar het begin Puntsgewijze samenvatting Dit NGI rapport laat de volgende dingen duidelijk zien: Enterprise-Architectuur gaat over het aansluiten van IT in een organisatie. Dit wordt ook wel (business) alignment genoemd. Daarom zijn er stemmen die de zeer pretentieuze term Enterprise-Architectuur willen aanpassen naar IT-Enterprise Architectuur. Dit zou een logische en verstandige aanpassing zijn, want Enterprise-Architectuur gaat niet over beeldvorming van een organisatie, maar, zoals gezegd, alleen over het inzetten van IT-oplossingen in een organisatie. Rond de informatievoorziening van een is het werk in te delen in vier soorten: Weten. Met informatie als vierde bedrijfsmiddel is kennis van de informatie van de organisatie de absolute noodzaak om een sterke positie op te bouwen om de juiste informatie op het juiste moment op de juiste plaats in de organisatie te krijgen. Deze kennis is de basis die nodig is om strakke regie over het andere werk aan de informatievoorziening te kunnen voeren. Investeren. Het werk dat nodig is om nieuwe informatie oplossingen te realiseren en om bestaande informatie oplossingen aan te passen. Dit werk wordt vooral in de vorm van projecten uitgevoerd. Exploiteren. Het beheren, in de lucht houden en onderhouden van bestaande informatie oplossingen, en Afstoten: het laten uitfaseren van informatie oplossingen. De in dit rapport beschreven methoden draaien allemaal vooral om het investeren in nieuwe of bestaande IT-oplossingen, waarbij niet of nauwelijks gekeken naar niet-IT-oplossingen wordt en waarbij alleen kleine delen van de andere soorten werk meegenomen worden. Daarmee toont dit rapport goed aan R r r r r r Geef een reactie -- Terug naar het begin Inhoudelijk Hoofdstuk 1: Inleiding Opmerkingen rond dit hoofdstuk: Het vakgebied van architecten wordt in dit rapport Enterprise-Architectuur genoemd. Met het feit dat Enterprise-Architectuur het inzetten van IT in een organisatie omvat is dit een grove en onjuiste verbreding van het vakgebied van de Enterprise Architect. Een Enterprise Architect is een IT-er die nieuwe of aangepaste IT-oplossingen in een organisatie introduceert. Deze mensen: kijken slechts zeer zijdelings naar de opzet en inrichting van IT zelf, de IT-infrastructuur. kijken alleen naar de vraag naar informatie van een organisatie voorzover het om de IT-oplossing gaat waar zij mee bezig zijn zijn alleen zijdelings betrokken bij het organiseren en/of reorganiseren van het werk in een organisatie, vaak het uitwerken van bedrijfsprocessen genoemd, en kijken zelden naar andere oplossingen dan IT-oplossingen. IT-ers hebben wel vaak het idee dat zij dit soort werk doen, maar de praktijk wijst meestal uit dat men dat werk met een IT-bril op doet, en dat men zo niet of nauwelijks in staat blijkt om de werkelijk gewenste resultaten op de resp. gebieden te bereiken. Met de aanvullende opmerking dat een beperkte groep IT-ers via opleiding en ervaring de overstap naar deze andere vakgebieden maken of hebben gemaakt. Die stap blijkt steeds weer lastig voor IT-ers omdat de maakbaarheid van oplossingen waar IT-ers aan gewend zijn veel minder mogelijk is in die andere vakgebieden. De referentie naar Zachman 1987 als een soort vader van het idee om informatiesystemen in hun samenhang te beschouwen is feitelijk onjuist. Al in de jaren 60 en 70 waren er vele ideeen en methoden die IT-infrastructuren in de breedte benaderde. Een methode als het informatiekruis van IBM, het bedrijf waar Zachman in die tijd voor werkte, en methoden als Prodosta, ARDI, SDM, NIAM, ISAC, Yourdon en vele andere zijn echt 10 of 20 jaar ouder dan de publicatie van John Zachman in 1987. De stelling dat je met methoden, technieken (incl. talen) en hulpmiddelen methoden voor Enterprise-Architectuur zou professionaliseren is een mythe. De referentie naar het artikel van Jaap van Rees "De methode doet het niet" wordt hier ook gemaakt, maar kennelijk niet goed begrepen. Als je naar de methoden en technieken uit de laatste 70 jaar, IT is rond 1939 ontstaan, kijkt is dit een zoveelste herhaling van het introduceren van methoden, technieken en hulpmiddelen voor werken aan IT. Zo wordt de beschreven methode TOGAF wel gezien als de 6e of de 7e versie van de methode SDM die in het begin van de jaren 70 is ontstaan uit een samenwerking van 3 grote Nederlandse ondernemingen: PTT, AKZO en Nationale Nederlanden. Het verhaal over de moeite om voor een methode te kiezen is een zeer oud verhaal, dat bijvoorbeeld juist zijn basis vindt in het genoemde artikel van Jaap van Rees. IT heeft gewoon geen geschiedenis om in een organisatie allemaal op een vergelijkbare manier vergelijkbaar werk (de essentie van methoden, technieken en hulpmiddelen) te doen, en er zal veel water door de Rijn moeten stromen wil dat ooit gaan lukken. Het is veel te simpel om dat alles puur en alleen onder de noemer cultuur samen te vatten, het gaat om veel en veel meer. De voordelen van methodisch werken zijn daarom niet minder, zeker als het om iets gestructureerds (Prof. dr. Léon de Caluwé noemt het "blauw") gaat als IT in essentie is. Het gaat echter om weten waar je mee bezig bent, en waar je werk past in het geheel. Zo lang IT-ers zich ook met andere zaken bezig houden en het van de interesse van de IT-er afhangt waar vooral aan gewerkt en naar gekeken wordt zal de introductie van methoden feitelijk blijven mislukken. En dan spreken we nog niet over het feit dat het kennen van een methode iemand niet tot een vakmens maakt. Daarom is het sterk de vraag of je als organisatie voor een methode moet kiezen. Het, binnen een totaalkader, kiezen voor passende methoden, technieken en hulpmiddelen voor de uit te voeren werkzaamheden kan een beter alternatief zijn. Met de hoop dat niet teveel methoden, technieken en hulpmiddelen gekozen worden het hetzelfde of ongeveer hetzelfde doen. De IT-praktijk laat dan ook al 70 jaar zien dat te ver, en te ver is snel bereikt, voorgeschreven methoden omarmen als organisatie nauwelijks effectief is, nauwelijks werkt. De uitleg van een methode als ingedikte ervaring wordt gelogenstraft met de methoden die in de rest van het rapport beschreven worden. Een echt vakmens heeft de kennis, kunde en de persoonlijkheid om met veruit de meeste methoden voor zijn of haar vakgebied te kunnen werken. De redenering dat kennis van methoden standaardbagage is voor enterprise architecten, en dat het voor hen van groot belang is om methoden te kennen is daarom een zeer zwakke redenatie. Dat dit moeilijk is, is bekend omdat de IT-wereld er niet van overtuigd is dat er enkele tientallen verschillende vakgebieden rond die technologie bestaan waarin mensen zich kunnen specialiseren. Maar de die vakken zelf hangen niet af van het feit of je gewend bent geraakt om lijnen in plaats van blokjes te tekenen. Dit boek bevat slechts 11 van de zeer vele Enterprise-Architectuur methoden, technieken en hulpmiddelen die bestaan. Dit is een zeer beperkte verzameling van alle methoden, technieken en hulpmiddelen die bestaan. Daarbij komt nog dat de meeste van de meegenomen methoden enz. op de markt gebracht worden door één of zeer weinig IT-leveranciers. Dit rapport ademt ook sterk de mening van deze IT-leveranciers(s) uit omdat anderen niet aan het woord komen. Dit is een slechte zaak voor een organisatie als NGI, die toch een zekere onafhankelijkheid zou moeten uitstralen. Geef een reactie -- Terug naar het begin Hoofdstuk 2: Het nut van een enterprise-architectuurmethode Opmerkingen rond dit hoofdstuk: De keuze voor de definitie van de Amerikaanse vereniging van ingenieurs IEEE geeft een sterk technische, een maakbare invalshoek aan het geheel. Dit is in lijn met mijn eerdere opmerking rond de term Enterprise-Architectuur en het feit dat het in werkelijkheid gaat om een IT-Enterprise-Architectuur. Die maakbaarheid via deze op systeemtheorie gebaseerde definitie past goed bij het inrichten van een IT-infrastructuur, maar bijvoorbeeld niet bij het inrichten van een organisatie zelf. Daarmee wordt in feite bewezen dat de pretentie die de term Enterprise-Architectuur neerlegt, namelijk dat het om alles in een organisatie als enterprise gaat, onjuist is. De van Capgemini + Sogeti overgenomen definities IAF en DYA trekken dit iets breder, maar het blijft ook daar om maakbare IT-systemen gaan. Daarmee is de scope van hoe de schrijvers van dit rapport naar methoden vastgesteld, en dus ook hun scope van kijken naar de IT-wereld: het investeren in IT-oplossingen. De paragraaf onder de IAF en DYA definitie laat zien dat de schrijvers uitgaan van deze Capgemini + Sogeti definities. Er vele andere definities van Architectuur waar hier niet over gerept wordt. Dat is jammer, want dat zou totaal andere invalshoeken zichtbaar maken. De uitleg van het begrip enterprise als organisatie zodat ook non-profit organisatie erdoor aangesproken worden is een verbreding, zoals eerder aangegeven, die niet past bij de methoden waar in dit boek over geschreven wordt. De systeemtheoretische, het "blauwe" dus, invalshoek komt sterk naar voren als Enterprise-Architectuur beschouwd wordt 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 als het om andere systemen op andere systeemniveaus gaat. 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. 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. 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. 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 a a aaaaa Geef een reactie -- Terug naar het begin Hoofdstuk 3: Ontstaan en ontwikkeling van enterprise-architectuurmethoden De in dit rapport beschreven manier van ontwikkelen van het begrip (enterprise) architectuur vanuit de oudheid tot nu is een zeer beperkte en gerichte versie. Ter adstructie: De historische verhandeling begint bij de piramides en eindigt bij Capgemini/Sogeti en situaties die passen bij de aanpak van deze IT-leveranciers. Er bestaan gelukkig veel meer op deze wereld dan de vooral op “maakbare architectuur” gerichte manieren van aanpak voor het realiseren van IT-oplossingen volgende de uiteindelijk in dit rapport genoemde “enterprise-architectuurmethoden” (“waar we nu staan”) Archimate, DYA, IAF en TOGAF. Vitruvius heeft het in zijn werk over functie (utilitas), structuur/degelijkheid (firmitas) en schoonheid (venustas). Dus wat de functie(s) van een geheel zijn, hoe het geheel gestructureerd is en hoe mooi het is (veel later heeft Alberti daar overigens nog het begrip harmonie aan toegevoegd, dus hoe een deel in een geheel past). Dit rapport stelt dat “Architectuur volgens Vitruvius aan minimaal drie kwaliteitsaspecten moet voldoen; functioneel, duurzaam en mooi”. Dit is wel een zeer beperkte uitleg van Vitruvius. Die past op zich wel bij de maakbaarheid van architectuur die deze werkgroep kennelijk wenst te neer te zetten. Zoals eerder gezegd is dit weer het zo blauwe van de IT-wereld zoals Leon de Caluwé dat bedoeld. Het is precies de reden waarom binnen de Bond van Nederlandse Architecten zo lang gewerkt is om aannemers buiten hun gelederen te houden. Iets wat hen uiteindelijk gelukt is, maar waar de IT-wereld nog aan moet beginnen. Bedenken is toch echt iets anders dan maken, waarbij de bedenker de taak heeft om de makers goed genoeg te vertellen wat gemaakt moet worden. Als je echter een maker laat bedenken, dan zal het vooral gemaakt kunnen worden volgens de techniek van die maker. Een houtbouwer zal immers niet echt nadenken over betonbouw, net zoals dat een SAP-specialist vooral en vaak alleen over ERP na zal denken. Zoals de werkgroep zlrf schrijft wordt in dit hoofdstuk de essentie weergegeven van de belangrijkste ontwikkelingen op het gebied van enterprise-architectuur algemeen en enterprise-architectuurmethoden in het bijzonder. Die wereld blijkt zich echter te beperken tot de wereld van en rond IT-leverancier Capgemini/Sogeti. Daarom is het logisch dat men geen andere methoden wil evalueren. Die passen immers vaak niet of nauwelijks in die wereld, of ze worden op de markt gebracht door directe concurrenten van deze IT-leveranciers. Geef een reactie -- Terug naar het begin Hoofdstuk 4: Het model voor het vergelijken van methoden Opmerkingen rond dit hoofdstuk: De gekozen manier om methoden te vergelijken werkt niet, en kan niet werken. De reden is simpel. Als je een methode voor het aanleggen van een snelweg naast een methode voor het beoordelen van personeel legt, dan kan het resulterende spindiagram er in beide gevallen precies hetzelfde uitzien terwijl het leggen van een asfaltlaag toch echt iets anders is dan het invullen van een beoordelingsformulier. Het zijn natuurlijk allebei manieren van werken, maar het vergelijken van beide methoden gaat nergens over, en gaat nergens naartoe. De spindiagrammen laten hier niets van zien, en dat is de reden dat ze onbruikbaar zijn om methoden te vergelijken tenzij er een zeer strakke context omheen gedefinieerd wordt. Dat is niet gebeurd. In latere hoofdstukken worden bijna alle vergeleken architectuurmethoden als niet architectuurmethoden beschreven, terwijl ze via de spindiagrammen toch vergeleken worden. Het Nederlandse spreekwoord "Appels met Peren Vergelijken" is hier zeer van toepassing. ............................. De keuze voor wat de assen van het spindiagram zijn is arbitrair. soorten stappen, fasering, product/dienst, methode/werkwijze, technieken, hulpmiddelen, methodieken/methodologie, achterliggende concepten., Alleen voorschrift voor stappen in werkwijze en hoever uitgewerkt is geen Architectuur gaat over functie, structuur, schoonheid en harmonie. De blauwe geachte om structuur in de aanpak om architectuur te realiseren te krijgen beperkt de creativiteit en zet vast op structuur en functie. Dat is ook de realiteit. .......................... Geef een reactie -- Terug naar het begin 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. Geef een reactie -- Terug naar het begin Hoofdstuk 6: Methoden met elkaar vergeleken Opmerkingen rond dit hoofdstuk: a Geef een reactie -- Terug naar het begin Hoofdstuk 7: Tien tips voor het kiezen en gebruiken van een methode Opmerkingen rond dit hoofdstuk: Geef een reactie -- Terug naar het begin Bijlagen: Te Opmerkingen rond dit hoofdstuk: Geef een reactie -- Terug naar het begin Interviews: Te Opmerkingen rond dit hoofdstuk: alfabetisch: Amsterdams raamwerk voor informatiemanagement. Classificatie raamwerk. Vooral gebruikt bij het evalueren van bestaande situaties, maar ook omgezet in methoden 9-vlak een ANSI/IEEE 1471-2000. Standaard Archimate. Hulpmiddel gekoppeld aan TOGAF, zie hierna. BIP. Business Informatie Planning van Novius Adviesgroep. DEMO. Een methode voor het in kaart krijgen van de verschillende bedrijfsprocessen van een (deel van een ) organisatie. Dragon1. Hulpmiddel. Uitwerking van de denk- en werkwijze van een persoon. DYA. Zeer algemeen raamwerk waarbinnen IT-elementen ingepast kunnen worden. IAF. Een door Capgemini op de markt gebracht classificatieschema. Een afgeleide van het Zachman framework RUP: taal TOGAF: Een door The Open Group, een commercieel samenwerkingsverband van de IT-leveranciers Capgemini, HP, IBM, NEC, SAP, Sun en HSBC-bank. Zie een twee Zachman. Door Zachman zelf een classificatieschema van XXXX genoemd. Opmerkingen: Wat opvalt is dat de meeste beschreven enterprise-architectuurmethoden elk iets nogal anders willen doen in de informatie- en IT-sector. Het is daarom sterk de vraag waarom voor deze methoden gekozen is, want omdat ze iets anders beogen zijn ze per definitie onvergelijkbaar. En dat is, zie de hoofdstukken 4 en 6, de bedoeling van dit rapport. We spreken bij de 11 beschreven enterprise-architectuurmethoden feitelijk niet of nauwelijks over methoden of technieken: Een methode wordt algemeen gedefinieerd als een verzameling van voorschriften en regels, die werkelijk worden gehanteerd of die gehanteerd zouden moeten worden bij het uitvoeren van wetenschappelijk onderzoek of bij het oplossen van praktijkproblemen. Een methode kan een reeks voorschriften bevatten voor de manier waarop een analyse wordt uitgevoerd, maar ook voor de aanpak van projecten, de manier van plannen, enz. Een techniek is het "gereedschap" dat wordt gebruikt ter ondersteuning van het werken volgens een methode (of een onderdeel daarvan). Voorbeeld zijn diagrammen, tabellen, talen, enz., waarbij de specifieke syntactische regels (bijvoorbeeld "input boven de streep en output onder de streep") onderdeel van de techniek zijn. Een hulpmiddel (of "tool") wordt gebruikt te ondersteuning van het werken met de methode en.of de techniek. Het kan om een potlood gaan, of om een template, software voor documentatie, ontwerp, realisatie enz. Aardig is trouwens dat de termen methodiek en methodologie niet aan de orde komen. Een methodologie wordt ook als "de leer der methoden" uitgelegd, waarbij methoden voor theorievormend onderzoek worden bedoeld. De term methodiek wordt ook uitgelegd als "de leer der methoden". Een methodiek wordt gezien als een geheel van samenhangende methoden gericht op de oplossing van een bepaalde categorie van praktijkproblemen. Waar de term methodiek in het kader van praktijkproblemen gebruikt worden, worden methodologieen gebruikt voor theorieproblemen. Het woord enterprise-architectuurmethoden en de context van deze wegwijzer voor de praktijk suggereert dat de beschreven methoden feitelijk methodieken zouden zijn. Gezien wat de beschreven enterprise-architectuurmethoden voorstellen en laten zien is geen van hen een echte methodiek. Sterker nog, sommige zijn puur een methode om een bepaald probleem op te lossen (zoals DEMO), andere zijn feitelijk technieken (zoals RUP) of gebaseerd op hulpmiddelen (Archimate en Dragon1). De meeste van de 11 beschreven enterprise-architectuurmethoden is een andere mix van bovenstaande termen uitgelegd worden. Geen van hen, hoewel enkele dat zullen beogen, is kompleet. Daarmee is feitelijk gezegd dat ze niet met elkaar te vergelijken zijn. De schrijvers geven in hun tekst ook aan dat RUP, XXXXXXXXXXXXXX geen enterprise-architectuurmethode is. Waarom deze manieren van aanpak meegenomen zijn in dit rapport is daarmee een raadsel. De spindiagrammen die gebruikt worden voor de "positionering" van de beschreven "methode". Ze geven echter nauwelijks informatie omdat de 11 vergeleken "methoden" niet of nauwelijks over hetzelfde gaan. Deze diagrammen kunnen daarom alleen waarde hebben als het doel van de enterprise-architectuurmethoden goed in acht gehouden worden. Het naast elkaar leggen van de spindiagrammen is verder volledig zinloos. Het feit dat DEMO een werkwijze kent en daar dus sterk scoort is bijvoorbeeld onvergelijkbaar met dat RUP ook een werkwijze kent. De manier waarop bedrijfsprocessen aangepakt kunnen worden heeft immers niets te maken met de manier waarop RUP de werking van een te ontwikkelen IT-applicatie beschrijft. Vergelijk dit maar met boeken: het feit dat er een boek over de architectuur van Gaudi en een boek over bouwkundig ontwerpen bestaat zegt niets over waar die boeken voor bedoeld zijn en wat hun effect is. En datzelfde geldt voor denkwijze, representatie- en modelleerwijze, ondersteuningswijze, gebruikswijze, neheer- en exploitatiewijze gebruiker en beheer- en exploitatiewijze eigenaar. Steeds weer worden koeien en paarden vergeleken op een manier die vergelijkbaarheid minimaal suggereert. A Geef een reactie -- Terug naar het begin

Uw naam:

Uw E-mail:

Uw reactie:

Terug naar het begin