In 1982 schreef Jaap van Rees het roemruchte artikel ‘de methode doet het niet’. Sinds die tijd is er een ware vloedgolf aan methodenboeken op de markt verschenen. Veel methoden zijn trouwens activiteitgeoriënteerd, dus uitermate geschikt om op basis van uurtje-factuurtje op mechanische wijze body shopping uit te voeren. Het is dan ook niet voor niets dat veel methodes door softwarehuizen zijn bedacht dan wel worden gepropageerd.
‘De methode doet het niet’ geldt des te sterker voor projecten die een hoge mate van creativiteit en situatieafhankelijkheid vergen. Trouwens wie haalt het in zijn hoofd als hij een fysieke architect uitnodigt een ontwerp te maken voor zijn droomhuis hem de vraag te stellen: welke methode gebruik je? Behalve een doorgeschoten theoreet of een nieuwsgierige concurrent is daar toch geen enkele zakelijke opdrachtgever of nuchtere businessmanager in geïnteresseerd. De dikte van een methodenboek is meestal recht evenredig met de mate van betutteling van de toepasser. Het boekwerk TOGAF 9.0 telt ruim 700 pagina’s2 en is zo zwaar dat je het fysiek kunt gebruiken om er tegenstanders mee knock out te slaan. Handig bij de eeuwigdurende methodenstrijd.
Op 2 februari 2009 werd versie 9.0 van TOGAF ten doop gehouden in San Diego als opvolger van versie 8.1.1, resulterend in een grote hoeveelheid extra details. Het formuleren zal een forse inspanning hebben gevergd. Probeer maar eens wereldwijd consensus te krijgen over zoiets principieels als een methodologie, zeker als er honderden partijen bij betrokken zijn. Uit de wandelgangen heb ik vernomen dat door de forse bijdragen van Capgemini en SAP het proces toch redelijk snel verlopen is.
Ik geloof heilig in ‘open source’, maar bij ‘open methodologie’ zet ik toch grote vraagtekens: democratie3 leidt meestal tot niets. Trouwens, bij de analyse van ADM kwam bij mij spontaan de afgezaagde grap naar boven: een kameel is een paard ontworpen door een democratische groep.
Bij het doorworstelen van die 728 pagina’s TOGAF wordt de lezer getrakteerd op een tamelijk onevenwichtige, weinig samenhangende en nogal gedateerde verzameling teksten met te weinig diepgang. Het informatieverkeer - de bloedsomloop van elke onderneming – ontbreekt geheel. Digitale werkruimten - de persoonlijke digitale werkruimte in het bijzonder - worden niet eens genoemd omdat de gebruiker volledig buiten beeld blijft. Architectuurprincipes lijken gezien het aantal pagina’s dat daar werkelijk aan is gewijd een ondergeschoven kindje, terwijl serieuze architectuurvisualisaties en waardevolle architectuurconcepten niet eens aan bod komen. ADM, het hart van TOGAF, is een onduidelijk mengseltje van architectuur, engineering, IT-governance en projectmanagement. Ik ben trouwens nog geen weldenkende architect tegengekomen die mij de logica achter dit schema heeft kunnen uitleggen noch de plausibiliteit van de verschillende pijltjes. Trouwens, het hele TOGAF-document overziend valt mij op dat 38,9% handelt over IT-Governance en projectmanagement, 39,4% over engineering en slechts 21,7% over architectuur.
Gelukkig biedt TOGAF een redelijk triviaal, rigide stappenplan voor alle architectuurfasen, zalig voor het uurtje-factuurtje in elkaar zetten van een architectuur.
Als je de rol en taken van een architect in TOGAF beschouwt, dan krijgt de architect naast zijn eigen werkzaamheden ook een groot deel van de werkzaamheden van de CIO, de businessconsultant, -strateeg, de programmamanager, de engineer en zelfs de innovator op zijn bord. Kortom, hij wordt de belangrijkste man na de CEO. Dat lijkt mij toch wel een beetje opgeklopt?
Toegegeven, er zitten ook nuttige ideeën in TOGAF 9.0, maar ja die kans loop je snel bij 728 pagina’s met een dergelijke heterogene groep.
Rond TOGAF ontstaat een ware IT-sekte: je bent in TOGAF of je begrijpt niets van het vakgebied. Sommige TOGAF-bekeerden stellen zelfs dat iedere professionele architect eigenlijk in TOGAF zou moeten zijn gecertificeerd4. Ik heb op dit moment überhaupt nog moeite met het certificeren van architecten, laat staan het certificeren op basis van een boek.
Ik hoopte dat na het uiteenspatten van de internetbubbel we weer met de benen op de grond waren gekomen. Helaas, al heel snel kregen we het luchtkasteel ‘second life’, gevolgd door een SOA-besmetting en nu dan een kind met een waterhoofd ‘TOGAF’. Waar heeft de business - die IT toch broodnodig heeft - dit aan te danken? Ik neem aan dat de opdrachtgever van architectuur nuchterder zal reageren op deze TOGAF-gekte met een houding ‘architecten, dat jullie onderling met TOGAF bezig zijn boeit mij weinig, maar val mij er niet mee lastig!’5. Ik voorzie trouwens een goudmijn voor opleidingsinstituten6 en consultants, want iedere onderneming die haar IT een beetje op orde wil hebben, kan volgens de TOGAF-indoctrinatiemachine niet zonder TOGAF7. Wellicht zullen sluwe consultants instrumenten propageren waarmee TOGAF-compliancy of zelfs de TOGAF-maturity kan worden gemeten?8
Een roemruchte vakbroeder bij Capgemini schreef mij dat er nu een echte wereldstandaard is op het gebied van architectuur. Hij bedoelde natuurlijk een wereldstandaard opgesteld/opgelegd door de bouwers9 van deze wereld. En dat terwijl architectuur toch eigenlijk thuishoort aan de vraagkant. NORA 2.0 had als waarschuwende ondertitel: ‘vóór en dóór architecten’. Ik vind dat in de bijsluiter van TOGAF 9.0 dient te worden opgenomen: ‘vóór en dóór bouwers, uitermate schadelijk voor de creativiteit van architecten’.
Concluderend: TOGAF is een architectuurframework dat zijn wortels heeft in een technisch architectuurframework ontwikkeld door DoD, dat eigenlijk slechts bedoeld was als hulpmiddel voor het informatiemanagement. Het lijkt mij twijfelachtig dat TOGAF ooit deze valse start zal kunnen overstijgen. Als ik de losse eindjes in dit document overzie, vrees ik voorts dat TOGAF 10.0 minstens 1000 pagina’s gaat tellen.
Mijn advies is te stoppen met dit initiatief en een (wereld)standaard te ontwikkelen vanuit de vraagkant, dus een standaard ontwikkeld door onafhankelijke architecten10 en gedragen door de businessmanagers van grote ondernemingen/instellingen.
1 Gepubliceerd in verkorte vorm in de Automatisering Gids, 27 maart 2009, nummer 13, pagina 16. 2 Naast die 700 pagina’s is er trouwens nog ruimte voor duizenden pagina’s nadere uitleg. 3 Plato constateerde al 2500 jaar geleden dat democratie de één na slechtste regeringsvorm is en dat geldt zeker voor IT-projecten/IT-beslissingen. 4 Jammer genoeg moeten alle TOGAF 8.1.1 gecertificeerden opnieuw examen doen in TOGAF 9.0. En dat terwijl ‘TOGAF 8.1.1 gecertificeerd’ veel gründlicher klinkt dan ‘TOGAF 9.0 gecertificeerd’. 5 Er zijn drie categorieën architectuurdocumenten: voor de opdrachtgever/businessmanagers, voor de architecten onderling, voor de bouwer. TOGAF is alleen voor de architecten onderling! 6 Ik vrees opleidingen door docenten die nauwelijks voldoende praktijkervaring hebben met architectuur. Je weet wel, van die beroepspraters: ‘geef mij de transparanten en ik doe wel even de cursus, maakt niet uit waarover’. 7 En, er wordt nog steeds makkelijker verdiend met praten dan met werken. 8 Was dat ook al niet met SOX? 9 Die bouwinvloed zit trouwens ook overduidelijk in DYA, de architectuurmethode met de grootste mindshare in Nederland. Onderwerpen als ‘strategische dialoog’, ‘ontwikkelen zonder architectuur’, ‘projectstartarchitectuur’ en de te grote nadruk op het applicatielandschap tonen dat wij hier te maken hebben met een architectuuraanpak opgesteld door een bouwer uitsluitend ten behoeve van het bouwen. 10 Onafhankelijke architecten zijn architecten die volledig zelfstandig opereren of die op de loonlijst staan van een onafhankelijk, onpartijdig architectenbureau dan wel architecten die in dienst zijn van een consultancybureau dat geen bouwactiviteiten uitvoert (direct noch indirect).
Reacties (99)
Geschreven door
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
op 29-04-2009 16:19
Beste Jan (28/4 12:18)
In een andere bijdragen heb ik het over het te vaak misverstane begrip Universe of Discourse (UoD) gehad uit ISO TR-9007 (the orange book). Dat gaat niet over het opdelen van de wereld in delen, maar over het kiezen van wat wel en wat niet tot je aandacht hoort. Dat kan een totale organisatie zijn, of een deel daarvan. Het kan ook een samenstellen van delen van 5 organisaties zijn, het kan Nederland zijn, of de wereld als geheel. De keuze die zo maakt is erg belangrijk omdat je daarmee ook de grens trekt tot hoe ver je moet en kan gaan. Het geeft dus ook direct, onder andere, de grens om wat nog wel je informatievoorziening is, en wat niet meer. Als je, bijvoorbeeld, internet als vele extranetten ziet, dan zal het extranet van de organisatie(s) binnen je UoD wel meegenomen moeten worden, en alle andere niet. Over die grens stroomt natuurlijk informatie (hopelijk zo weinig mogelijk gegevens), in en uit.
Het is dus geen kwestie van het “hiërarchisch” opdelen van de wereld, het zijn geen schalen naast elkaar. Sterker nog, vaak zullen de mensen die de ene UoD beschouwen ook een deel van een andere meenemen. Juiste het onderkennen dat je overlap hebt is ontzettend belangrijk, omdat je daar iets mee zult moeten. Al is het alleen maar dat je het overlappende deel aan één van beiden toewijst. Neem bijvoorbeeld NICTIZ in Nederland. Is de uitwisseling van informatie die zij voorstaan tussen gezondheidszorg organisaties iets van NICTIZ, van het Ministerie VWS of van die gezondheidszorg organisaties? En waar die grens of overlap ligt, welke afspraken zal je daar moeten maken om goed samen te kunnen werken?
Als jij onder wat je schalen noemt ook de ondersteunende informatievoorziening van een UoD verstaat bedoelen we hetzelfde. Omdat je expliciet op harmonie tussen schalen in gaat heb ik het vermoeden dat jij die schalen meer disjunct ziet dan ik dat doe. In oudere termen: feitelijk als hiërarchie, terwijl ik meer in termen van een netwerk denk.
Je zult nooit een verstandig en robuust geheel kunnen kiezen voor alle tijden. Je zult dan ook nooit geheel veilig aan de slag kunnen met een voor zo’n geheel integrale informatievoorziening, want dat kan morgen anders zijn. Dat wordt bijvoorbeeld anders als Fortis en ABNAMRO fuseren en een samensmeltende informatievoorziening gaan nastreven. Of als een wet van kracht wordt die afdwingt dat organisaties voortaan informatie met elkaar moeten gaan uitwisselen, zoals in de gezondheidszorg. Die haverklap kan dus elke dag gehoord worden, en organisaties zijn dan ook bereid, als zoiets gebeurt, om te investeren in het veranderen van de informatievoorziening.
Echt het enige dat we hier aan kunnen doen is de juiste standaards maken, en volgen. Feitelijk moeten we ooit stoppen met het maken van software zelf, zodat we alleen nog software genereren op basis van wat een organisatie wil. Maar dat pad hebben we in de 90-er jaren verlaten en we proberen dat tegenwoordig via (out)sourcing te doen…
De ruimst denkbare schaal kan alleen wereldwijd zijn, dus alle 6,5 miljard mensen en alle 6,5 miljard organisaties omvatten. Probeer daar maar eens een ontwerp voor te maken. Je ziet hoe slecht dat gaat met iets als internet.
In deze thread hebben we het al eerder over veranderingen gehad. Dat is echt de verkeerde focus. Je kunt alleen uitgaan van wat is, en nadenken over wat zou kunnen zijn. En als je dan zover bent komen die veranderingen aan de orde. Verandering als doel stellen is echt de dood in de pot. Harmonie heeft vooral te maken met balans tussen de delen. Lees de aloude economische wet van het marginale nut er maar eens op na: stop je energie in de elementen waar het beter moet worden om naar een goede, betere balans te kunnen komen. Bestek is niet een doel, maar meer een combinatie van elementen die je al hebt, en die je samenneemt om duidelijk te maken wat je wil bereiken. Daarom is zoiets als business analyse en informatie analyse ook een tijdelijk iets, want waarop zou je zwaar willen analyseren als je al weet wat je hebt, en wil?
UoD heeft ook maar gedeeltelijk iets met organisatie te maken. Organisatie is daar slecht een van de onderdelen van, er zijn er veel meer. Het ontwerp van de bedrijfsprocessen is dan ook maar een element, een keuze die best wel eens een keer kan moeten veranderen op de termijn. En dus nog steeds geen stabiele, veilige basis geeft. Sterker nog, in mijn discussie met Peter heb ik het over synergie. Dit is nu precies één van de zaken waar veel synergie te halen valt als goed samengewerkt wordt, met de opmerking dat het doel en de strategie van de organisatie leidend moet zijn. En ook die kan snel veranderen.
Ik heb niet zoveel te kiezen als ik een werkelijkheid in ga. Wat ik wel moet doen is goed proberen vast te stellen wat mijn werkelijkheid op een moment is. Vooral om te weten waar ik in gesprek moet met anderen omdat zaken aan dienen te sluiten, of dienen te overlappen.
Je zegt dat ik dan een informatiearchitectuur zou gaan maken. Grappig is dat dit feitelijk zelden nodig is omdat iedere organisatie haar architecturen heeft. Die architecturen kunnen slecht uitgewerkt zijn, en slecht gedeeld zijn. Dan is het maar de vraag waar ik moet gaan beginnen om e.e.a. beter uit te werken, zodat die balans goed gaat ontstaan. Je doet het voorkomen alsof je een soort proces kan neerzetten dat begint bij het kiezen van wat jij een schaal noemt, dat je dan die informatiearchitectuur gaat maken en dat je dan enz. Buiten het feit dat dit enorm kostbaar kan gaan worden zonder dat veel resultaten ontstaan is het ook nooit nodig. Als je een supermarktketen binnengaat die al meer dan 100 jaar bestaat kan het gewoon niet zijn dat ze niet weten wat ze doen. En dus hebben ze architectuur. En dus is er geen vast proces, a-la TOGAF bijvoorbeeld, om daar wat mee te gaan doen.
Ja, het HUIDIGE probleem zit vooral in wat ik planologie heb genoemd, zoiets als wat Pieter stedebouwkundige architectuur noemt. Daar zit in de huidige praktijk meestal het gat dat nodig uitgewerkt en ingevuld moet worden.
Neen, een organisatie is niet de ruimste schaal, zoals ik hierboven aangegeven heb. De neiging in mijn praktijk is dat wat jij schaal noemt steeds breder wordt: de overheid, de ministeries, de gezondheidszorg en ga zo maar door. Voor het bouwen en onderhouden is de schaal trouwens meestal kleiner.
Ik weet niet of wij als informatiekundigen en IT-ers zoveel met de schaalgrootte moeten. Feitelijk is het voor ons vaak een gegeven, al kan je in de loop van de tijd wel een trend naar verbreding zien. Het enige dat we er echt mee kunnen is de juiste standaarden ontwikkelen en handhaven. Niet via oplossingen, want dat is altijd alleen zo lang als het breed is. Maar juist via kennis, en de aansluiting daarvan op de rest van de wereld. Dat is ook de reden dat ik jaren tijd heb besteed binnen ODP en Conceptual Schemas om daar iets werkbaars van te maken. Met tot nu toe slechte resultaten, gewoon omdat de verkeerde disciplines ermee bezig zijn. IT-ers zijn oplossers, en geen planologen of kennisontwikkelaars. Maar ik zie ook geen opleidingen in WO en HBO die wel mensen opleiden om dit gat te vullen. Daarom moeten we het doen met praktijkmensen die zich natuurlijk zo ontwikkeld hebben, met het risico dat iedereen er op zijn of haar eigen manier tegen aan kijkt. En zo methoden en technieken wil voorschrijven die passen bij haar of zijn “toevallige” ervaringen. Wat leidt tot stammenstrijden enz. zoals rond TOGAF. Tja, als je geboren wordt ben je ook niet gelijk volwassen…
Steven van ’t Veld
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
Stel nu eens, voor de duur van deze bijdrage, dat je leeft in een tweedimensionale wereld. In die wereld ben je geboren, getogen en als er verder niets verandert, zul je er ook in overlijden. Je weet eenvoudigweg niet beter. De grenzen van zo’n wereld werken natuurlijk (beperkend) door in alle viewpoints die je maar kunt bedenken/hanteren. En als je niet in de gaten hebt – of krijgt – dat er méér is dan die twee dimensies (waar je je waarschijnlijk niet of nauwelijks van bewust bent), dan is het erg moeilijk te bedenken dat een viewpoint dat jijzelf hanteert door die twee dimensies wordt beperkt.
Mogelijk vermoed je ‘ergens’ wel dat er iets niet klopt, maar zoek je de ‘oplossing’ daarvoor binnen de oplossingsruimte van die twee bekende dimensies. Wat nu als die oplossingsruimte is uitgeput? Dan is al je inspanning tevergeefs.
Het kan natuurlijk ook zijn dat je je wel degelijk bewust bent van de twee dimensies en een derde dimensie hebt aangeboord. Met zo’n extra dimensie verandert je wereld kwalitatief. Er passen oneindig veel tweedimensionale vlakken in driedimensionale ruimte. Je eigen vertrouwde tweedimensionale vlak interacteert nu volop met die nieuwe ruimte. Veel (zoniet alles) van de je zo vertrouwde tweedimensionale wereld hervindt zich nu in ruimte. Het is niet meer dan logisch dan dat voor al die nieuwe en bestaande relaties nieuwe betekenis, nieuwe woorden in de taal ontstaan. Nieuwe terminologie – zeg oog maar. En dat is altijd reuze lastig – voor iedereen.
Als ik er nu eens van uit ga dat jij een derde dimensie hebt aangeboord met wat jij noemt de “10 of 11 echte basisconcepten” en “conceptual schemas”. Dan zijn dat woorden die ik in mijn 2D wereld ken, maar daar waarschijnlijk een veel armere betekenis dragen dan in jouw ruimere 3D wereld. Als dat zo is, vergt dat extra uitleg als je een 2D-er wijs wilt maken wat jij bedoelt. Dan komen er waarschijnlijk ook nieuwe termen om al te veel verwarring met 2D te voorkomen en om daarmee tegelijk ook aan te geven dat je bezig bent met een werkelijk vernieuwende sprong vooruit. Klopt, dat is allemaal reuze lastig – voor iedereen. Die extra uitleg over die nieuwe, rijkere concepten ga je naar alle waarschijnlijkheid ook documenteren zodat ook anderen met jou mee kunnen groeien qua begrijpen.
Dat met dat “axiomatisch stelsel voor radicale interdependentie” (Wisse, 23-04-2009 10:32) is ook gedocumenteerd en duidt zeker ook op een extra dimensie. Het zou dan ook bijzonder interessant zijn om die twee met elkaar in verband te brengen om te zien waar de overeenkomsten en verschillen zitten en wat die twee in elkaars nabijheid zouden kunnen betekenen. Denk je niet?
Geschreven door Daan Rijsenbrij op 01-05-2009 13:14
Hierbij een verlate reactie wegens storingen op de website
Peter,
Hierbij reageer ik op jouw persoonlijke noot van 24 april om 13.20 over de engineer. Ik wil graag nog een paar extra woorden wijden aan mijn oproep (van 23 april om 21:23): ‘Heren en dames engineers wees er trots op engineer te zijn en noem jezelf geen architect. Architecten, zorg dat je informatie inwint bij vakbekwame engineers om te borgen dat je bouwopdracht bouwbaar is. En, engineers probeer de taal van de architecten te verstaan’.
Engineers functioneren totaal anders dan architecten, maar zijn net zo belangrijk. Wat heb je aan een mooi ontworpen auto als de engineering onder de motorkap niet werkt. Je ziet weliswaar die engineering niet, maar het maakt wel dat de auto lekker rijdt. Je ziet ook dat engineering zorgt dat er architectureel meer kan en andere zaken mogelijk zijn. Pas toen de personenlift werd geperfectioneerd konden we wolkenkrabbers ontwerpen, honderd verdiepingen zijn immers niet te belopen.
Ik hoorde laatst bij een klant dat een van hun topengineers was gepromoveerd tot architect alleen omdat de salarisschalen van architecten verder doorliepen dan die van engineers. Erg jammer! Ga je als onderneming om te zorgen dat je een uiterst waardevolle medewerker niet verliest er maar een ander label opplakken? Ander voorbeeld. Bij de Belastingdienst is de softwareontwikkeling en de exploitatie ondergebracht bij B/CICT en het omzetten van wet en regelgeving naar producten en processen in B/CPP. Toch lopen er bij B/CICT veel mensen rond die architect op hun businesskaartje hebben staan. Waarom eigenlijk? De architecten horen bij B/CPPte zitten en de engineers bij B/CICT. Die engineers moeten wel het werk van de architect kunnen doorgronden. Ik heb dit advies al een paar keer uitgebracht, maar de architectentitel lijkt bij B/CICT meer aanzien te geven dan de engineerstitel. Dit bevordert niet echt de duidelijk naar de businessklant.
Wanneer is deze onterechte onderwaardering van engineers begonnen? Volgens mij is in het 4GL-tijdperk de noodzaak van een goed technisch ontwerp verloochend. Zie voor een nadere uitleg mijn artikel in het Maandblad Informatie (2008) jaargang 50, nummer 10, pp 10 – 13: ‘Toen was vakbekwaamheid nog heel gewoon’. In de 32 jaar dat ik bij Capgemini heb gewerkt heb ik heel wat vakinhoudelijke opgangen en neergangen meegemaakt. Maar het meest triest vond ik het massale vertrek van de engineers (toen nog technisch ontwerpers genoemd) in de tweede helft van de negentiger jaren omdat zij nul-komma-nul meer werden gewaardeerd. Erg jammer! Deze exodus heeft zich waarschijnlijk ook afgespeeld bij andere softwarehuizen gezien de resultaten die ik op dit moment zie bij enkele grote projecten in het bijzonder in de publieke sector.
Engineers zijn in twee rollen nodig. Ten eerste als partner voor de architect om te berekenen en adviseren wat technisch mogelijk is. Van de architect wordt immers verwacht dat hij een bouwbaar ontwerp aflevert, dus dient hij specialisten te raadplegen om de bouwbaarheid te kunnen beoordelen. Naast engineers horen hier ook security experts, privacy deskundigen en vele anderen bij. De tweede rol ligt bij de bouwer die het functioneel ontwerp moet laten omzetten naar een technisch ontwerp. Op het ogenblik zijn er ruim 10 specifieke architectenbureau boven de horizon verschenen voor de digitale wereld. Ik zou van die bureaus wel eens willen weten wie bij hun de echte engineers zijn of welke externe engineers zij inhuren als adviseur bij hun architectuurwerk. Als hun antwoord luidt dat hun medewerkers zowel architect als engineer zijn, dan vind ik hun bureau ongeloofwaardig. In het verlengde van bovenstaande heb ik al vaker opgeroepen tot specifieke onafhankelijke engineeringsbureaus. Een voorbeeld hiervan was het Telematicabureau, jammer dat zij zich nu ook met architectuur bezig houden. Dat verzwakt hun imago.
Als oprichter van de Landelijke ArchitectuurCongressen (vanaf 1999) en als initiator van dit E-Magazine ’Via Nova Architectura’ heeft mij altijd voor ogen gestaan platformen in het leven te roepen waar niet alleen architecten met elkaar kunnen communiceren, maar ook architecten met engineers en engineers onderling, allen op voet van gelijkwaardigheid. Immers de discussie tussen architecten en engineers is de strijd tussen esthetische vormgeving (liefst met de mens centraal) en technische haalbaarheid: zie mijn presentatieset op het tiende Landelijk ArchitectuurCongres. Dus Peter, ik zie graag een publicatie van jouw hand over de engineer in dit E-Magazine.
Hoort deze discussie nu onder mijn artikel over TOGAF? Ja! Het probleem met TOGAF ligt in het niet erkennen van de scheiding tussen architecten en engineers. Dat komt al langer voor, want waarom moest – alweer lang geleden - IEEE een architectuurdefinitie lanceren?
Architect of engineer? Beiden zijn even waardevol, en horen op hetzelfde niveau te worden gehonoreerd. Mijn advies is altijd: doe waar je grootste affiniteit ligt of wat populairder verwoord:’volg je hart’. De vakgebieden architectuur en engineering zijn zo groot dat je nauwelijks kunt excelleren in beiden.
Vriendelijke groet, Daan.
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
Geschreven door
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
op 02-05-2009 01:55
Beste Peter (28/4 7:19)
Tja, je mengt wel eens in een discussie. Het zeggen van A én B.
Het is en blijft lastig om de titel architect te duiden in de informatie & IT-sector. Dat komt deels doordat de uitleg van wat architect-zijn is is en betekent. Je kunt immers de hardware van een informatievoorziening inrichten, maar ook van alle applicaties, of van één applicatie. Je kunt voor beide een lans breken, met dien verstande dat je belangrijkste stakeholder iemand (of iets als je in termen van organisaties denkt) anders is: de niet-IT-er die zich laat ondersteunen door IT en de IT-ers die een platform nodig hebben om die ondersteuning te kunnen realiseren. Het is net als met systemen, iets vergelijkbaars doen voor een ander publiek hoewel je kunt uitleggen dat je hier nog steeds over vergelijkbare systeemniveaus spreekt. En dan wat de IT-sector ontzettend hard nodig heeft: overzicht, inzicht en onder regie komen. Je kunt dan zowel een lans breken voor het gebruik van de titel architect, alsook tegen het gebruik van die titel. Jan en Pieter hebben het over de stedebouwkundige architect, je kunt het ook over een planoloog of een informatie strateeg hebben. Of dat architecten zijn, het heeft er veel kenmerken van, maar veel ook niet. En dan heb ik het nog niet over wat in de organisatie buiten haar informatievoorziening gebeurt. IT-ers claimen het vormen van bedrijfsprocessen, maar dat is feitelijk een zwaktebod van de rest van de organisatie. Feitelijk zou een organisatie die iets voorstaat, en dat zal moeten want waarom is de organisatie er anders, ook moeten bepalen hoe ze hun doel(en) cq. strategie willen bereiken. Informatie is daar maar een onderdeel van, en IT is maar één van de vele hulpmiddelen die daarvan aangeschaft en ingezet kunnen worden.
Wat ik veel erger vind is dat de titel gebruikt wordt om een paar euro per uur meer te verdienen. Als je niet zegt dat je tot het Nederlandse leger van zo’n 30.000 architecten behoort ben je minder. Wat natuurlijk volle onzin is, want feitelijk zijn er maar een paar 100 echte architecten, en de rest doet waar zij goed in is en gebruikt de titel architect.
Architectuur in de IT-sector (applicaties, bestanden, systeemsoftware, hardware en netwerk) is iets blauws, iets dat ingericht kan worden en hoort dus hoogstens op tactisch niveau in een organisatie. Omdat het inrichting is kan je veel structureren, en dat is precies wat TOGAF, DYA en wat al niet bedacht is doet en wil doen. Het gaat allemaal over inrichten en verrichten, en niet over het richten. Meer dan 99% van de IT-wereld is hier mee bezig: er hebben (of maken) een probleem, en zorgen voor de IT-oplossing. Ontwerp tot realisatie en testen. Te beginnen met iets dat business analyse of informatie analyse heet en wat niet meer is dan het begrijpen van het probleem door analyse, waarna je gaat ontwerpen, inrichten, en dus realiseren en testen. Er is een stuk land en daar moet een huis op komen. Waar zit nu de architect in de informatie & IT-sector? Informatie zelf? Applicatie/IT-business/IT-Enterprise/Alignment/ontwerp? Infrastructuur? De vergelijking met de bouwwereld gaat steeds vaker mank als je verder buiten de technologie en de toepassing daarvan zelf komt.
Klopt, iemand die een concertgebouw gaat ontwerpen voert die opdracht uit. Dat is ook wat de IT-sector doet: opdrachten uitvoeren, te beginnen met weten wat de vraag eigenlijk is, gevolgd door een passend ontwerp enz. Maar dat hele proces, en dat zijn ervaringscijfers, is ongeveer 20% of minder van het budget van een organisatie. Zo’n 80% of minder is exploitatie. En dan hebben we het nog steeds over oplossingen in een geheel. Naast dit alles zal er ook nog iets moeten zijn die dat soort oplossingen richt, de noodzaak ervan vaststelt. En het budget. En dat heeft weinig met IT te maken, en dat soort zie je dan ook zelden in de IT-wereld. Logisch, want organisaties moeten zelf bepalen waar ze hun geld het beste aan kunnen besteden, dat kunnen IT-aannemers niet doen. Die krijgen een opdracht, en je mag hopen dat die goed en helder neergezet is. Business analyse is alleen nodig als die opdracht niet goed genoeg uitgewerkt is. Hopelijk dus een uitstervend beroep, want organisaties zullen zelf goed moeten weten wat ze doen met hun informatie. Daar is het werkterrein van de informatiekundige, in de vraag naar informatie in de organisatie tegenover, hopelijk in optimale samenwerking, met oplossers als IT-ers.
Met je verhaal over Sydney vertel je m.i. hetzelfde als ik hier nu vertel. Je hebt het over IT-leveranciers, onze aannemers en waar ze mee bezig zijn. Je kunt daar strijden of de architect bij deze aannemers zit, of dat het om een onafhankelijk architect dient te gaan. Als het puur om het (functionele) ontwerp gaat dat voldoet aan de gestelde vraag kan ik me de combinatie ontwerper/aannemer voorstellen. Maar dan moet al wel voor houtbouw gekozen zijn, want een houtbouw aannemer zal alleen houtbouw ontwerpers willen. Dus zal de keuze voor .Net en IBM feitelijk al gemaakt moeten zijn voordat een organisatie de opdracht geeft dat concertgebouw te ontwerpen, en mogelijk bouwen. De vraag van de klant is eerst, hoe zeer je ook een betere oplossing voor die vraag wilt bieden.
Wat ik wel vaak tegenkomt is dat het meer willen bieden ook letterlijk genomen wordt. Het leveren van meer en andere functionaliteit dan gevraagd wordt. Soms zelfs veel en veel meer. Vaak functionaliteit die er al is, maar dan net even anders. Met alle aansluitingsproblemen. Daarom zullen opdrachtgevers zeer precieze vragen moeten leren stellen, en zullen aannemers, IT-leveranciers, moeten leren niet meer of minder op te lossen dan gevraagd wordt. En dat zijn we absoluut niet gewend. Kijk maar eens naar de outsourcing naar landen als India. Waar gaat het fout? In de vraagstelling. India weet vaak te doen wat hen gevraagd wordt, maar als wij de juiste vragen niet (kunnen) stellen, dan zal outsourcing zeker mislukken. Voorbeelden te over, zie vooral ook de bankwereld. TOGAF probeert zoveel mogelijk werk binnen de organisatie zelf in IT te trekken: “omdat ze het in de organisatie niet doen”. Je kunt echter je hersenen, met je kennis van je informatie, als organisatie niet door derden laten doen, en dat is TOGAF wel probeert. En wat in de huidige bewegingen van organisaties niet past. Men gaat het “voortraject” echt structureel zelf doen, los van IT juist om IT onder regie te krijgen.
Structuur en functie zijn 2 van de 3 kenmerken van Vitruvius. De derde, schoonheid, wordt nog nauwelijks begrepen in de IT-sector. Laat staan harmonie, een niet-Vitruviaans kenmerk. Dan gaat het niet meer om binnen de getrokken grens, maar juist ook om buiten de grens. En juist in de bouwwereld zie ik vaak objecten die niet of nauwelijks passen in hun omgeving.
Jij hebt dus een keuze gemaakt voor wat architectuur voor jouw is. Misschien dat je het woord eens beter kunt vervangen door een ander woord, zoals bijvoorbeeld ontwerp, want we hebben een veelvoudig homoniem gecreëerd en we weten vakmatig dat zoiets dat ons ontzettend veel parten gaat spelen.
Ik wens je veel succes met je keuze, en feliciteer je dus, zoals ik al eerder gezegd heb, met het feit dat je een keuze gemaakt hebt.
Steven van ’t Veld
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
Geschreven door
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
op 02-05-2009 02:40
Beste Jan (30/4 21:06)
Ja, je punt is helder. Als ik je idee doortrek dan zie ik 2 verschillende dingen. De ene is waar de informatie & IT-sector de niet informatie & IT-sector raakt. IT-ers zien echt wel dat een personeelsbeheerder en een jurist iets anders doen dan hij/zij zelf doet. Maar als het om verschillende viewpoints binnen de informatie & IT-sector gaat, dan ontkent men vaak het bestaan ervan. Misschien onvolwassenheid. Ik denk meer het ontbreken van een collectief geheugen in de 70 jaar dat IT bestaat. IT is immers nog nooit een vakgebied geweest, dus wat te doen. Rusland is haar collectieve geheugen in ruim 70 jaar ook kwijtgeraakt, maar daar is wel het nodige om te herinneren.
In de gaten krijgen dat het niet allemaal over IT gaat kom je vooral achter als je naar andere vakgebieden kijkt. Dan zie je dat het niet alleen om technologie kan gaan, en je krijgt meer dan een vermoeden. En dat er zoveel beroepen in de informatie & IT-sector zijn, verwacht wordt tussen de 40 en 60 (“soorten”) beroepen, dat het niet allemaal over één kam geschoren kan worden. En dat doen we wel.
Rond 1990 heb ik voor de viewpoints van ODP ooit eens een plaatje gemaakt met 7 of 8 dimensies. In de blauwe wereld van IT moest dat naar de huidige 2 dimensies platgeslagen worden, en dan nog vooral met maar 2 van de 5 viewpoints. Alles zou hetzelfde zijn, alleen kijk je er anders naar als je een andere achtergrond hebt. En dat is gewoon onjuist, en één van de redenen waarom de bewijzen van Sowa te kort schieten. Viewpoints zijn dan ook geen oplossingsruimte, het zijn manieren van kijken naar de wereld. En dan zie je zaken in je eigen vakgebied, en zaken die tot andermans vakgebied horen. Waar de IT-wereld vol mee zit is dat men zaken uit andermans vakgebied claimt als zaken in het eigen vakgebied. Daar is de ODP standaard hard de mist in gegaan, en daar gaat TOGAF de mist in. Zorg nou maar dat je goed bent in je eigen vak/viewpoint, en verklaar de rest niet voor gek omdat ze een ander vak hebben. Hoe vaak heb ik niet gehoord dat een IT-er uitroept dat die stomme organisatie haar bedrijfsprocessen niet kent, of dat een gebruiker niet weet wat goed voor hem/haar is. Respectloos, en de absolute van synergie.
Je dimensievoorbeeld lees ik als het relaas van een ontwerper. Met de beperkingen van de gestelde grens en van wat je opdrachtgever feitelijk wil. Misschien is het mooi als het ook in meer dan 2 dimensies kan, zo lang het maar voldoet aan de vraag die aan de ontwerper gesteld wordt: maak me een oplossing die….
Het was Erik Proper die gevraagd heeft om een vergelijking van methoden te doen. Het probleem is dan wel dat je methoden dient te vergelijken die zich met iets vergelijkbaars bezig houden. Nou is dat het geval met veruit de meeste architectuurmethoden zodat je dan zoiets kan doen als het boekje dat ik in 1990 voor de NGGO heb samengesteld met een werkgroep rond het vergelijken van 16 methoden voor systeemontwikkeling. Het schema en de concepten dat we toen gebruikten past nog steeds voor dit soort werk. Dat past ook voor het werk dat jij, Pieter en Jaap doen rond het ontwerpen en de ideeën van bijvoorbeeld Alexander die daar richting aan geven (of geldt dat alleen voor Jaap?). Als ik het over informatiekunde heb dan spreek ik over de kennis van en ervaring met de informatie van een organisatie. Dat heeft nog erg weinig met ontwerp te maken; het gaat vooral om het onderbouwen van het geheel en het inpassen vragen die uiteindelijk in het ontwerp cq. de ontwerpen een plaats moeten hebben. Ik weet dat jullie IT onafhankelijk proberen te ontwerpen, uitgaande van ruimte en niet van beperking. Maar toch is er een groot verschil tussen het richten van de informatievoorziening en het inrichten daarvan. Met de voorlopige conclusie dat het woord informatiekunde nu een echt homoniem is geworden, en zoals gewoonlijk levert dit ook weer de nodige problemen op.
Steven van ’t Veld
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
Geschreven door
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
op 02-05-2009 08:49
Beste Steven (2/5 00:55) en Daan (1/5 12:14),
Ik wil best een andere titel verzinnen voor mijn architectuur-zijn en als alternatief voor de architecten titel binnen het bouwdeel van de ICT. Designer/ontwerper is te algemeen, dat is de superset waar architecten en engineers maar ook bijvoorbeeld meubel of mode-ontwerpers onder vallen. Lawson heeft hele mooie boeken* geschreven over de generieke kenmerken van allerlei soorten designers (ontwerpers) en wat design eigenlijk is (bestaat ook geen eenduidig antwoord op).
De meest passende oplossing voor een alternatieve titel blijf ik systems engineer** vinden. En ik wil me best sterk maken voor het gebruik van die titel via een stuk op Via Nova (in plaats van het visiestuk wat ik in gedachten had) en binnen onze organisatie.
* How Designers Think en What Designers Know ** onderdeel van systems engineering is ook de (systeem) architectuur, oftewel: systems architecture engineering dat is ook een mooi alternatief voor het hele "bouwen (of nu zelfs beheren) onder achitectuur)
Dank je wel voor de duidelijkheid die je me verschaft.
Als ik in je bijdrage lees dat je mijn "dimensievoorbeeld lees[t] als het relaas van een ontwerper", moet ik je toch uit - ik noem het maar even - je droom helpen. Dat dimensievoorbeeld moet je juist lezen als het relaas van een... (in jouw eigen bewoording) planoloog! Over perspectiefwissel gesproken!
Je begint je bijdrage met "Ja, je punt is helder." Nu zal er best wel een punt zijn dat helder is, maar ik heb geenszins de indruk dat dat 'mijn' punt is (vanuit 'mijn' perspectief).
Wellicht kun je 'één en ander' aan bijdragen nog eens vanuit dat 'planologische' perspectief aan je geestesoog voorbij laten trekken? Hoeveel verschillen vallen dan weg? Hoeveel meer overeenkomsten vallen er dan te noteren?
Geschreven door
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
op 02-05-2009 19:25
De slogan ‘Even Apeldoorn bellen’ ... heeft sinds Koninginnedag 2009 voor sommigen een ‘andere lading’ gekregen. De discussie hier over TOGAF illustreert volgens mij in ieder geval het belang van ‘lading’. Ik leg kort uit: Ik schets u de werkelijkheid als een groot wit doek. Ieder van ons projecteert daar zijn eigen percepties op, en noemt het ‘de werkelijkheid’. Als we merken dat iemand anders iets anders ziet (wij noemen het projecteren meestal ‘waarnemen’) op dat doek dan wij, hebben we een verschil gevonden. Interessanter nog wordt dat verschil wanneer we hetzelfde omschrijven te ‘zien’ (feiten) maar er een geheel andere betekenis aan geven. Ik projecteer een doodenge spin, jij ziet een klein en waardevol insect... Verwarring ontstaat wanneer ik verwacht dat ‘iedereen’ die doodenge spin waarneemt, en natuurlijk snappen degenen die slechts ‘een klein waardevol insect’ zien daar helemaal niets van. Als ik deze analogie nog wat verder mag oprekken, namelijk m.b.t. ICT: Bakker ziet een waardevol insect, en van ’t Veld een doodenge spin. Het verschil in waarneming zegt weinig over ICT, maar (bijna) alles over de persoon die zijn waarneming (= projectie) verwoord; we nemen niet waar maar duiden onze persoonlijke projectie. Daarmee is de betekenis van ICT (dus) relatief; afhankelijk van de context, hier: de waarnemer en zijn persoonlijke ervaringen met ... spinnen. Zo ook begrijp ik Rijsenbrij’s pleidooi voor een ‘opdrachtgever gedreven’ traject met betrekking tot architectuur: het is immers in die context juist de (verwachtingen, projecties van de) opdrachtgever die maatgevend moet zijn voor wat er mee wordt bedoeld en wat er uit voortvloeit. En dan is exact hetzelfde relativeringsproces nodig om de waarde van TOGAF te bepalen: context. Of simpel: ‘wat is de waarde van TOGAF?’ is pas te beantwoorden als we minimaal aanvullend vragen ‘voor wie?’ Interessant is ook te benoemen dat eigen aannames over, en projecties van, de betekenis van woorden die anderen gebruiken (Bakker zegt: ‘waardevol insect’, van ’t Veld hoort: ‘doodenge spin’) op een bijzonder taaie manier en steeds opnieuw worden opgevat zodat ze (weer) passen in de eigen projectie (waarneming) van degene die leest. Als Wisse schrijft is dat vooral te waarderen als het product van een ‘spiderlover’, en als Rijsenbrij bijdraagt volgt natuurlijk onderbouwing van de engheid van spinnen... Hopelijk is deze karikatuur ergerniswekkend genoeg om juist aan te geven hoe bevooroordeeld en tot mislukking gedoemd discussies soms kunnen zijn, juist als de deelnemers woorden en betekenissen steeds opnieuw hervormen tot ze weer in hun persoonlijke en bestaande ‘plaatje’ passen. Het zal pas lukken daarmee rationeel af te rekenen wanneer de onbewuste manier waarop dat gaat ... bewust wordt gemaakt. Dit is mijn poging daartoe. Voorbeeld? Wat bedoelen ‘we’ toch met ‘de ICT’? Ik beweer graag dat, als er al een goede ontwikkeling van het vak architectuur m.b.t. informatie en communicatie mogelijk is, deze uit de ICT moet voortkomen, overigens net zoals dat in de bouwwereld gebeurde! Ik refereer daarbij ook aan de etymologische betekenis van de feitelijke woorden waarvoor ICT staat (zie: http://is.gd/w81p). Tegelijkertijd heeft van ’t Veld vast goede redenen om, vanuit zijn eigen ervaringen daarmee bijvoorbeeld, te stellen: “Architectuur in de IT-sector (applicaties, bestanden, systeemsoftware, hardware en netwerk) is iets blauws, iets dat ingericht kan worden en hoort dus hoogstens op tactisch niveau in een organisatie.” Zegt hij daarmee dat, volgens hem, door de eigenheid van ICT de mogelijkheden van ICT-driven architectuur beperkt wordt? En is dat dan een gegeven, of een persoonlijke mening? Mijn betoog is dat het vooreerst een projectie is. TOGAF is niet goed of fout. Het is hooguit goed of fout in een bepaalde context. De betrekkelijkheid wordt vervolgens niet alleen bepaald door de context, maar meer nog door de beoordeling daarvan door de waarnemer. Alleen zo kan TOGAF zowel een waardevol insect als een doodenge spin betekenen, geheel afhankelijk van de context dus. En, even terug naar de Apeldoorn-slogan: ook nog afhankelijk van tijd. Er is dus een grote variëteit aan contexten die de betekenis van informatie beïnvloedt. Ofwel: homoniemen alom. Het ontwerpen van een alomvattend stelsel dat rekening houdt met deze grote afhankelijkheid van context en tijdsfactor in de betekenisduiding van informatie vraagt een fundamenteel andere aanpak dan we tot nu toe, vanwege onze zeer beperkte focus, konden benutten: we hebben inmiddels te maken met een netwerkmaatschappij. Nou denk ik warempel en-passant ook nog een klein lichtje te hebben geworpen op dat lastige begrip “axiomatisch stelsel voor radicale interdependentie”. Maar dat is ook slechts mijn projectie van mijn beperkte begrip daarvan. Net als iedereen projecteer ik maar wat, zoals mijn feitelijk en onbetwistbaar enige juiste definitie van architectuur: http://is.gd/w9t0.
Geschreven door
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
op 03-05-2009 00:05
Beste Peter (2/5 7:49)
Ik denk niet dat het erom gaat dat we een andere titel verzinnen. We zullen samen een beroepenlandschap moeten neerzetten, met daarbij de best passende titels. Architect, Daan heeft het over engineers en er zullen nog 40 of meer andere titels nodig zijn. System engineer klinkt mij niet slecht in mijn oren. Als eenling kan je er niet veel aan doen. Je kunt beter meegaan met wat past in de huidige situatie. Als community zullen we, internationaal, toch echt een keer moeten gaan kiezen, we proberen het immers al meer dan 20 jaar. Maar het zal wel door eenlingen geïnitieerd moeten worden, want anders gaat het niet gebeuren. Misschien kan je je visiestuk combineren met je naam die je eraan hangt.
Steven van ’t Veld
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
The core of any EA development is the framework, i.e. its meta-architecture. The framework is the glue between components and artifacts. Without a good framework, there is no navigation between artifacts and their components.
Bij veel organisaties bestaat het beeld dat de Project Start Architectuur (PSA) bedoeld is om de Solution Architecture van het project weer te geven en daarmee de scope te bepalen. Als gevolg daarvan is het een dik document en duurt het enkele maanden om het op te stellen. Dit artikel laat zien dat deze invulling van de PSA fundamenteel onwenselijk is. De PSA bevat geen Solution Architecture!
Without a framework, we can deliver predictable and repeatable outcomes. An EA framework represents the architecture of the EA, that is the meta-architecture of the Enterprise, i.e. an EA structure with hooks where components fit back in, like the chassis where the car parts mount on.
In this paper, we investigate the mapping between ArchiMate’s concepts and TOGAF’s implicit and explicit meta models along the following lines. First, we ask whether TOGAF’s meta model aligns with ArchiMate’s. We investigate the generic, meta meta level of both and go deeper into the business architecture, data architecture, applications architecture and technology architecture as prescribed by TOGAF, to see whether we can express the required TOGAF notions in ArchiMate. We conclude with recommendations to the designers of both ArchiMate and TOGAF.
Bedrijfsprocessen in kaart brengen blijft een vak apart. Er zijn inmiddels schitterende modelleertools waarmee procesmodellen met één druk op de knop kunnen worden omgezet in werkende applicaties die die processen kunnen ondersteunen of op basis van bedrijfsregels zelfs volledig kunnen uitvoeren, maar in het woud van mogelijke tools en methodieken is het vaak moeilijk kiezen. Bovendien zijn beschikbare proces referentiemodellen die er voor verschillende branches en toepassingsgebieden zijn vaak lastig vertaalbaar naar de eigen praktijk.
This paper is the second in a series in which we intend to shed light on the possibilities of using the ArchiMate language with an architecture method and inform you on the pitfalls you may face. This paper follows up “Using ArchiMate with an Architecture Method”, which outlined some of the fundamental ideas behind ArchiMate and set out nine questions to ask of a method to be used in conjunction with it.
This second paper returns to answer the nine questions we defined in the first paper (to help you integrate the use of ArchiMate with your chosen architecture method) using TOGAF as an example architecture method.
The ArchiMate language for enterprise architecture has recently been adopted by The Open Group as a technical standard. This may result in a steep rise in its popularity. However, ArchiMate is only a language and does not prescribe a way of working. Hence, it will be used in combination with some other method to guide the process of architecting. Some assume it will be easy to use ArchiMate when following the process of their preferred architecture method. Indeed, it will be easy to use the ArchiMate box symbols in drawing artifacts/diagrams. Perhaps many will do this, thinking they have thus used the ArchiMate language with their method.
Danny Greefhorst, Sander Rodenhuis, Toine Schijvenaars, Erwin Oord, Jan Willem van Veen
maandag, 11 mei 2009
Een enterprise-architectuur in twee weken
Architectuur is een belangrijk instrument bij het veranderen van organisaties. Organisaties zijn in veel gevallen nog wel op zoek naar hoe ze dit instrument precies moeten hanteren. Deze zoektocht leidt er veelal toe dat architectuur overmatig wordt toegepast en onvoldoende aansluit op de doelstellingen. Dit artikel beschrijft een pragmatische visie en een bijbehorende aanpak voor enterprise-architectuur. Deze aanpak levert in twee weken al veel toegevoegde waarde.
Since architecture is a relative new field, much debate goes on about the methods and techniques to be used within the field. Since one of the key competencies of an architects is to be able think conceptually, it is only natural for architects to engage in lengthy discussions about their tools, techniques, approaches and methods. A recent example of such a discussion can be found on the Via Nova Architectura website, where a rather opinionative posting on TOGAF 9 resulted in an involved discussion with 38 elaborate responses.
De komst van de alweer negende versie van het architectuurraamwerk van de Open Group – TOGAF – heeft een verhit debat in de architectencommunity veroorzaakt. Daan Rijsenbrij stelde in zijn column in de Automatiseringgids dat TOGAF een regelrechte bedreiging voor de creativiteit van architecten vormt en pleitte voor een bijsluiter met die strekking. Op Via Nova Architectura leverde dit niet minder dan 38 reacties op – de één nog gepeperder dan de andere. Is de Open Group doorgeschoten in haar ambitie om een wereldstandaard voor architectuur neer te zetten, of hebben ze alleen misgeschoten?
In het boek "bedrijfsarchitectuur" geven de auteurs een goed overzicht van het architectuur vakgebied in de volle breedte. Het is bewonderenswaardig hoeveel informatie de auteurs in dit boek bijeen hebben kunnen brengen. Het is wel wat jammer dat het boek voor een deel weer eigen terminologie introduceert.
Henk Jonkers, Marc M. Lankhorst, Maria-Eugenia Iacob, Erik Proper
dinsdag, 17 maart 2009
De internationale standaard voor het modelleren van enterprise-architecturen
De Open Group werkt al jaren aan standaarden. Eerst waren dat standaarden op het gebied van protocollen en operating systems. Sinds het einde van de jaren negentig richt men zich ook op standaarden voor het werk van architecten. The Open Group Architecture Framework (TOGAF), waarvan onlangs versie 9 is verschenen, is uitgegroeid tot een van de meest toonaangevende methoden voor enterprise-architectuur. In dit artikel kijken we naar ArchiMate, de nieuwe Open Group-standaard voor architectuurmodellering.
Dragon1 is een beweging die enterprise architectuur uitdraagt als ontwerp- en realisatiediscipline voor duurzame, toekomstvaste en integrale bedrijfs/IT-oplossingen. In deze blog zet ik kort uiteen wat de essentie is van Dragon1. Dit zodat iedereen zelf een beeld kan vormen over wat Dragon1 is in het licht van andere bewegingen, methoden en aanpakken. En ook de mogelijkheid heeft om er kennis van te nemen.
Bij de opzet van Dragon1 we gekozen voor het bewegingsmodel. Naast een methode in boeken, cursussen, sjablonen, voorbeelden en checklisten, is er bij Dragon1 ook een Dragon1 Usergroup, een Dragon1 Architecture Foundation en een XR. e-magazine.
Met al deze zaken wordt ervoor gezorgd dat steeds meer mensen kennis kunnen nemen op een laagdrempelige en zeer toegankelijke wijze van het gedachtengoed dat Dragon1 heet. Iedereen die wil bijdragen aan Dragon1 kan dat via de Usergroup. Dat gebeurt nu nog kleinschalig elke maand in Wageningen.
Architectuur leer je niet uit een boekje, maar van een meester en na jarenlange uitoefening. Daarom: Niet TOGAF is verplichte kost voor de architect, maar de oratie van Daan Rijsenbrij. TOGAF is een goed (reactief) analyse/managementinstrument, voor IT-architectuur, of beter gezegd: IT-structuur en IT-constructie. Dragon1 is volgens de Dragon1-gebruikers meer een (proactief) ontwerp/strategisch instrument voor bedrijfstransformaties en IT-innovatie onder enterprise architectuur. Maar methoden blijven methoden. Je hebt goeroes nodig die aan de hand van een methodische aanpak laten zien hoe je mooie dingen maakt.
Er zijn de afgelopen tien jaar veel architectuurmethoden, technieken en raamwerken verschenen. Veel van deze methoden en technieken zijn afkomstig van adviesorganisaties en niet publiek beschikbaar. Er is echter een duidelijke trend naar open standaarden en TOGAF en ArchiMate zijn daarvan goede voorbeelden. In dit artikel wordt een overzicht gegeven van TOGAF, waarbij met name wordt ingegaan op TOGAF 9. Aanleiding is de publicatie ervan op 2 februari 2009 op de Open Group conferentie in San Diego.
In the introduction of the book the author promises “to answer some of the common sense business questions related to Enterprise Architecture”. Reading the book, I got very soon the impression that he in fact, wanted to answer every potential question. Some aspects are discussed on the level to guide the Architect, others to teach the Business Manager.
The EA framework is the meta-architecture of the Enterprise or the Architecture of the Enterprise Architecture. This item explores what an EA framwork is and what is should consist of.
In dit artikel pogen de auteurs de balans op te maken van een aantal ontwikkelingen op het terrein van bedrijfsmodellering. Met het positioneren van een aantal veelbesproken technieken voor visuele modellering wordt gepoogd meer helderheid te scheppen in het enorme aanbod op dit gebied. Tot slot wordt er gekeken naar voor de nabije toekomst te verwachten of gewenste uitbreidingen op bestaande praktijken.
In this research project, ing. J.M. Cloo developed a framework for evaluating architecture modeling methods for their suitability for modeling services and applied it to three of the most frequently used methods within Capgemini by Business architects: DEMO (Dietz, 1999) and Business modeling Method for Information planning (BMI). The framework consists of criteria for modeling methods and a classification of these criteria.
Systems development methods are used to express and communicate knowledge about systems and software development processes; i.e. methods encapsulate knowledge. Since methods encapsulate knowledge, they also encapsulate rationale. Rationale can in this context be understood as the reasons and arguments for particular method prescriptions. In this paper we show how the combination of two different aspects of method rationale can be used to shed some light on the communication and apprehension of methods in systems development. This is done by way of clarifying how method rationale is present at three different levels of method existence. By mapping existing research on methods onto this model, we conclude the paper by pointing at some research areas that deserve attention and where method rationale could be used as an important analytic tool.
Massimo Cossentino, Salvatore Gaglio, Brian Henderson-Sellers, Valeria Seidita
maandag, 05 juni 2006
Several different approaches to Situational Method Engineering exist. They differ in terms of the primary element of the paradigm: the method fragment definition. Here, we introduce four method fragment definitions from the literature and compare their metamodels according to structural and functional criteria. The structural comparison showed a general alignment of some concepts that are sometimes referred with different names while the study of the compositional aspects results in evidence of substantial differences.
Het doel van dit onderzoek was om een methode te ontwikkelen voor de evaluatie van digitale architectuur. Er zijn verschillende gebieden onderkend die allemaal te evalueren zijn. Twee belangrijke stromingen zijn de productgeoriënteerde aanpak en de procesgeoriënteerde aanpak. De keuze is gemaakt om het product van architectuurontwikkeling te evalueren, de architectuurdocumentatie. De Architectuur Documentatie EvaluatieMethode is een raamwerk die verschillende scans bevat die uitgevoerd kunnen worden.
Tijdens de evaluatie van de gemeente Amsterdam door middel van de voorbereidende scan werd vrijsnel duidelijk dat er verschillende belangrijk geachte elementen niet aanwezig zijn. Zo is de rationaliseringsketen niet expliciet gemaakt waardoor er geen fundering is voor alle gekozen oplossingen in de architectuurdocumentatie. Tevens zijn er geen stakeholders en concerns opgenomen waardoor de validiteit van de architectuurprincipes niet gegarandeerd is. De gemeente Amsterdam dient de rationaliseringsketen dan ook expliciet op te nemen in de volgende versie. Aangezien de architectuurdocumentatie belangrijke elementen mist zou de holistische scan niet mogen worden uitgevoerd.Dit is omwille van het onderzoek toch gedaan. ...
David Campbell, Guido Chorus, Yves Janse, Chris Nellen, Paul van Vlaanderen, Robin van ’t Wout
vrijdag, 15 juni 2007
Dit document is het resultaat van een onderzoek binnen het vakgebied van de Digitale Architectuur, zoals dit gedoceerd wordt aan de Radboud Universiteit te Nijmegen. Het onderzoek is door zes studenten uitgevoerd onder begeleiding van prof. dr. Daan Rijsenbrij en prof. dr. Erik Proper. Dit document beschrijft de eerste fase van het onderzoek; de ontwikkeling van een architectuurevaluatiemethode. In de tweede fase wordt dit onderzoek voortgezet op individuele basis. Een aantal onderdelen van de methode worden dan verder uitgediept. Ook wordt de in dit document voorgestelde methode getest door een bestaande architectuur te evalueren. Deze fase is niet beschreven in dit document.
This report is a result of research conducted for the Radboud University of Nijmegen and Sogeti Nederland B.V. Our main research question was to determine how an architect can create a usable description of an enterprise. This research question was defined because architects require insight into the enterprise which enables them to develop a usable architecture. At the time this research initiated it was yet unknown how usable descriptions could be created.
Henk Jonkers, Marc Lankhorst, René van Buuren, Stijn Hoppenbrouwers, Marcello Bonsangue, ...
woensdag, 26 november 2003
A coherent description of an enterprise architecture provides insight, enables communication among stakeholders and guides complicated change processes. Unfortunately, so far no enterprise architecture description language exists that fully enables integrated enterprise modelling, because for each architectural domain, architects use their own modelling techniques and concepts, tool support, visualisation techniques, etc. In this paper we outline such an integrated language and we identify and study concepts that relate architectural domains. ...
Vítor Estêvão Silva Souza, Ricardo de Almeida Falbo, Giancarlo Guizzardi
vrijdag, 22 juni 2007
The rapid evolution of the area of Web Engineering has motivated the proposal of several methods and frameworks for the development of Web Information Systems (WISs). In particular, it is becoming more and more common to use containerbased architectures and frameworks when it comes to their development. Following this idea, we have proposed a method for designing frameworkbased WISs, called FrameWeb. and, in this paper, we present FrameWeb's UML profile for modeling framework components in design models.
This paper presents experiences and reflections from using the EKD Enterprise Modeling method since the beginning of the 1990’ies. A large number of application cases have been carried out. The paper focuses on the EKD modeling language, the EKD modeling process and supporting tools.
A large number of strategies, approaches, meta models, techniques and procedures have been suggested to support method engineering (ME). Most of these artifacts, here called the ME artifacts, have been constructed, in an inductive manner, synthesizing ME practice and existing ISD methods without any theory-driven conceptual foundation. Also those ME artifacts which have some conceptual groundwork have been anchored on foundations that only partly cover ME. This paper presents an ontological framework, called OntoFrame, which can be used as a coherent conceptual foundation for the construction, analysis and comparison of ME artifacts. Due to its largeness, we describe here its modular structure composed of multiple ontologies. For each ontology, we highlight its purpose, sub-domains and theoretical foundations. We also mention the approaches and process by which OntoFrame has been constructed.
The discipline of situational method engineering (SME) promotes the idea of retrieving, adapting, and tailoring fragments, rather than complete methodologies, to specific situations. In order to succeed in creating good methodologies that best suit given situations, fragment representation and cataloguing are very important activities. We introduce a visual SME approach,whose roots are in domain engineering. This approach relies on the Application-based DOmain Modeling (ADOM) approach, which provides a framework for representing both applications and domains and validating them each against the other. Furthermore, the proposed ADOM-based approach aims at supporting all the SME-related activities, while in this paper we focus only on its fragment representation and cataloguing parts. The main advantages of the approach are its expressiveness, its support for specifying, constraining, and...
We propose a three stage method development life cycle. The requirements engineering phase consists of elicitation and representation of method intentions, the design phase produces the architechture of the method and the construction phase consists of organizing method features in a coherent whole. We concentrate in this paper on the Design and Construction phases of the life cycle. We explaion our notion of method architecture and organization and illustrate them. Finally we show the relevance of method architecture and organization in SME. The design and consturction engineering phases of our life cycle are illustrated for a small SME example.
Little scientific research has as yet been done on projects conforming to Enterprise Architecture. To lay foundations for such research, this paper presents a theoretical framework for defining the Project Architecture (PA) in the context of working with Enterprise Architecture. One part of the PA is the Project Start Architecture (PSA), which bounds the project to the Enterprise Architecture (EA) and/or Domain Architecture (DA). We start with explicating the context of a PSA in terms of its relation to the EA and DA. Subsequently, we define the PA in terms of three dimensions. The first dimension con-tains four aspect areas. The second dimension features four abstraction levels. The third dimension contains two project content categories: the PSA (containing prescriptions inherited from the EA and/or DA) and the PED (the Project Exclusive Design, containing the fundamental analysis and design artifacts that have been created specifically for the project). A real-life case is used to help illu-strate and validate the theoretical framework. Additionally, a mapping with RUP artifacts is made to further clarify the framework of the PA with examples of well-known analysis and design artifact types.
The aim of this research is to develop an information agent framework for knowledge discovery in enterprise architecture (EA). This framework is based on specific purpose ontology and knowledge discovery techniques. Such framework would facilitate strategic decision making for EA stakeholders by enabling them to analyze and monitor the portfolio of processes, data, applications, and organizational units in terms of their correlation and impact in the overall organization. This framework is very useful for affording key stakeholders with the appropriate view that is reliant on an accurate and concise picture of systems, applications, technologies and other infrastructure elements in the business and how these integrate to serve the enterprise. The paper discusses the concepts and components of this framework. Potential benefits of this framework over existing approaches are also discussed.
In this article, we explore the possibilities of combining ArchiMate, a modelling language for enterprise architecture (EA), with TOGAF, The Open Group Architecture Framework, a design method for EA.
In een serie van artikelen wordt een generiek uitbreidbaar (IT-) Architectuurraamwerk beschreven. In dit eerste artikel wordt gedetailleerd ingegaan op de essentie van het ontwerpproces.
In een serie van artikelen wordt een generiek uitbreidbaar (IT-)Architectuurraamwerk beschreven. In dit tweede artikel wordt het Metamodel xAF beschreven en zal nader worden ingegaan op de Architectuur-principes.
