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 22-04-2009 07:38
Voor mij gaat het bij architectuur in het algemeen erom dat je een stukje van de wereld wilt veranderen. Die verandering breng je samen tot stand met allerlei partijen, in mijn wereld (infrastructuur) vooral samen met engineers en de bouwers.
Als je zeker wilt weten dat die verandering goed verloopt (d.w.z. oplevert wat je voor ogen hebt) moet je zorgen dat alle betrokkenen hetzelfde beeld voor ogen houden. In mijn optiek kan dat alleen als je allemaal werkt vanuit één en hetzelfde (logische) model waar iedereen zijn informatie aan moet toevoegen. Methodes worden dan ondergeschikt aan dit centrale model. Deze werkwijze heeft zich al jaren bewezen bij bijv. de ontwikkeling en realisatie van auto's, defensie systemen, vliegtuigen en complexe gebouwen.
Probleem met de meeste architectuurmethodes die ik ken is dat die werken met allerlei verschillende architectuurprodukten (tekeningen, documenten) die vervolgens over de muur worden gegooid richting engineers en bouwers. Die vervolgens die produkten weer gaan vertalen in eigen beschrijvende producten (bijna altijd ook weer losse documenten). Hierdoor ontsaat er veel ruis (consistentie problemen) en informatielekken wat het eindresultaat niet ten goede komt...
Mijn kritiek op alle architectuurmethodieken in de virtuele wereld is dat ze door het benoemen van allerlei losse architectuurprodukten onbewust mee helpen aan het ineffectief maken van het toch al moeilijke proces van verandering.
Geschreven door
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
op 22-04-2009 08:15
Aangezien mijn blog posting "off topic" is mbt de door Daan Rijsenbrij gestarte discussie, zal ik hier niet reageren op comments op mijn blog entry. De blog staat inmiddels zowel op mijn VNA blog als mijn eigen blog. Op commentaren op die plekken zal ik reageren.
Geschreven door
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
op 22-04-2009 10:20
Wat vreselijk, eigenlijk! Aangespoord door vooral de laatste reactie door Peter Bakker (22 april 2009) herlas ik mijn eigen opstel Kritiek op de Pure Methode (www.wisse.cc/htm/kritiek_op_de_pure_methode.htm) uit 1995. Tjonge, is dat alweer zó lang geleden? Nee, helaas zie ik geen aanleiding er ook maar iets aan te veranderen. Zelfs het begin van onderhavige discussie met een m.i. onbegrepen beroep op Jaap van Rees’ stelling De Methode Doet Het Niet blijkt slechts een zoveelste herhaling. ;-)
Ik stond voorts even te kijken van de manier waarop Erik Proper verkeer naar zijn blog probeert te genereren. Succes ermee. Maar gelukkig reageerde Steven van ’t Veld hier wèl (22 april 2009). Uiteraard, als ièts past in een discussie over Togaf, zijn dat nota bene “de concepten achter dit soort methoden.” Steven, zou je daarop ajb nader willen ingaan? Ja, ik besef dat het een korte vraag betreft waarop stellig slechts een uitvoerig antwoord recht doet aan de reële variëteit. Daarom, is er relevante documentatie beschikbaar waarnaar je inmiddels simpel kunt verwijzen? Je persoonlijke toelichting is natuurlijk extra welkom.
En Daan Rijsenbrij werkt blijkbaar nog aan “een samenvatting.” Op 3 april jl. deelde hij hier mee dat hij die “over een week [zou] trachten […] te geven.” Hopelijk lukt het hem alsnog spoedig.
Geschreven door
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
op 22-04-2009 21:21
Nadat de posting-teller al 18 dagen lang op 38 was blijven steken - iedereen was immers in gespannen afwachting van de samenvatting die Daan zou gaan geven (zie Daan's posting van 03-04-2009 11:06) - verbreekt Erik Proper op 21 april de stilte.
Proper is op dat moment helemaal 'mede' geinspireerd door de discussie die tot aan 3 april heeft plaatsgevonden. Dat gepraat ook allemaal... We moeten gewoon aan het werk. Dat is het! Dat we dat niet zelf konden bedenken. Zoveel wijze mannen! Ik kan me wel voor het hoofd slaan!
Steven van 't Veld ontleent op zijn beurt - en tot mijn verbazing - constructieve (zie de posting van Pieter Wisse) inspiratie aan de posting van Proper. Van't Veld sluit zijn reactie naar mijn idee - heel passend - af met: "Maar [Proper's] streven is zeer lovenswaardig."
Maar wat nu? Er is nog steeds geen samenvattende opening tot vruchtbaar vervolg! Daan waar blijf je?! Ook Wisse verkeert nog steeds - naar mijn idee terecht - in de veronderstelling dat zo'n samenvatting er daadwerkelijk komt.
Ik denk dat het fair is de lezers van deze blog wat dat betreft 'uit de brand' te helpen. Van Daan zelf hoorde ik vanochtend dat hij in deze blog niet meer zal reageren. Toch wil ik Daan bij deze alsnog met klem oproepen om aan te geven waar hij dan wel (verder) zal reageren met een samenvattende opening tot vruchtbaar vervolg - bijvoorbeeld. Dat lijkt mij fair. Mee eens Daan?
Geschreven door
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
op 23-04-2009 01:34
Beste Peter,
Ja, en hier zit juist het punt waar ik het niet mee eens kan zijn: het direct in verband brengen van architectuur met veranderen. Dat is ook precies de zware beperking die een methoden DYA, TOGAF en vrijwel elke andere “architectuur”methode als uitgangspunt neemt.
Laat ik het anders zeggen. Stel je eens de vraag wat de architectuur is van iets dat bestaat: een kerk, software, een IT-infrastructuur of nog iets anders. Mensen gaan dan kenmerken opnoemen. In lijn met reeds lang bestaande ideeën gaan die kenmerken vooral over wat functioneel geboden wordt, wat de structuur is, hoe mooi het is (en waarom) en hoe het geheel past in zijn omgeving. Stel nu dat je kenmerken wilt beschrijven van iets dat er nog niet is, iets dat er misschien moet komen. Wat je dan moet beschrijven zou eigenlijk hetzelfde moeten zijn als wat je op zou schrijven als het wel bestaat. Dus wederom met kenmerken als functie, structuur, schoonheid en harmonie.
Als dit zo kan, dan is architectuur en verandering dus vooral iets anders. Zeker in onze informatie & IT-sector, want daar zou eigenlijk de architectuur van het geheel er moeten zijn. Niet alleen van de delen, maar juist en vooral van het geheel. En daarbinnen kunnen zaken aangepast (moeten) worden. Die veranderingen binnen het geheel vaststellen is in feite het bestek, de specificatie van eisen voor de door te voeren verandering.
Naar onze informatie & IT-sector heeft de architectuur van een gehele informatievoorziening feitelijk weinig of niets te maken met informatie techniek. Pas als e.e.a. verder uitgewerkt wordt om een bestek van eisen te kunnen krijgen zullen een minimale set eisen toegevoegd kunnen of misschien moeten worden om de juiste verandering te bewerkstelligen. Minimaal, want waarom zou een organisatie zich druk moeten maken over welke processor, welk operating system, welk netwerk, welke dbms, welke programmeertaal enz., tenminste zo lang het maar in het geheel past (de harmonie). Regie is dan dat je binnen het geheel passende bestekken hebt die verwezenlijkt kunnen worden zodat ontstaat wat je als organisatie wenst, en waar je geld voor uitgeeft.
De verandering is gemiddeld ongeveer 20% van alle geld dat uitgegeven wordt. Verwacht mag worden dat dit “bedrag” uiteindelijk kan dalen, maar omdat de hoop er nog steeds is dat dan ook de exploitatiebedragen zullen dalen zal de totale hoeveelheid geld misschien minder worden, terwijl het percentage aan verandering misschien wel gelijk blijft. Nu wil het geval dat DYA zich kompleet en volledig beperkt tot het veranderen, en dus niet met de 80% andere kosten doet. TOGAF lijkt me wat breder, maar dat zou best eens een foute inschatting kunnen zijn. En ik ken maar weinig andere “methoden”, “architecturen” die meer afdekken naast dat veranderen. En daarmee is architectuur op dit moment maar een fractie van wat het zou moeten zijn: het totale beeld van een informatievoorziening. En daarmee zeg ik ook dat TOGAF geen universeel wondermiddel KAN zijn, want het dekt maar een heel klein deel van alles in de informatie & IT-sector af.
Daarmee deel ik dus je kritiek op de huidige architectuur methoden, maar om een echt kompleet andere reden en rationale. Dit soort methoden vergelijken is daarom op zich interessant, maar duidelijk ook zeer beperkt in scope als je echt naar wat ik de informatie & IT-sector noem en voor de informatievoorzieningen van en binnen organisaties daarbinnen. Het kan weinig meer zijn dan een vervolg van het boek Vergelijking van Systeemontwikkelingsmethoden dat door NGGO in 1989 onder mijn redactie geschreven is. Op zich wel relevant voor, m.i., vooral de IT-sector, maar het heeft nog zeer weinig met architectuur te maken. Net als DYA, TOGAF, GEM en hoe de 100-en architectuurmethoden tegenwoordig ook genoemd worden.
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 23-04-2009 01:58
Beste Pieter,
Ja, je hebt gelijk dat een antwoord rond concepten erg lang kan worden. In het kort het er op neer dat ISO in lijn met het technical report TR9007 in de 90-er jaren een standaardisatie aktiviteit heeft gehad onder de noemer Conceptual Schema Management Facilities. Of wel over de concepten die onder het information viewpoint, de informatiekunde liggen. In een paar zijn daar ruim 250 geinventariseerde begrippen teruggebracht naar 10 of 11 echte basisconcepten. Het was Prof John Sowa, met John Zachman ex-IBM, die het wiskundige bewijs geleverd heeft dat deze set compleet was. Daar is toen nog discussie over ontstaan omdat dit bewijs gebaseerd was op het terugbrengen van alles in 1 object definitie, wat theoretisch juist was maar te weinig praktisch om er iets mee te kunnen doen. Daarom is de groep in 1999 ontbonden, en is het werk blijven liggen als committee draft versie 2.
Onderliggende reden voor dit alles is dat de deelnemende leveranciers community zich ging realiseren dat zo ontzettend moest gaan veranderen aan de installed base en hun producten en diensten dat zij dat niet zagen zitten. Nu, 10 jaar later, beginnen veel vragen zich in dit totale kader te vormen, en zijn de “architectuurmethoden” feitelijk weinig anders dan wat we in de 70-er jaren ook al hadden. Daarmee zeg ik dat de essentie allang bekend is, maar dat in de praktijk te weinig geld verdiend kan worden als we die basisconcepten echt ook zouden hanteren. Met een “bewijs” uit het ongerijmde: als je ooit een echt goed ontworpen informatiesysteem hebt gezien dan weet je dat haast altijd per definitie “agile” is en dat het altijd maar een fractie van de kosten voor onderhoud nodig heeft. Alleen al de praktische constatering dat een conceptueel echt goed ontworpen gegevensstructuur maar, als vuistregel, eentwintigste van het aantal regel programmacode nodig heeft spreekt hier boekdelen. Maar zolang wij SDM-achtige molochen als TOGAF, DYA en andere architectuurmethoden willen blijven pushen komen we geen stap verder. Simpelweg omdat als je echt kijkt naar wat het kan en doet de complexiteit ineens extreem groter maakt. Zie bijvoorbeeld ook mijn vorige reactie naar Peter. En dat alles schrijf ik als praktijkmens die letterlijk in honderden organisaties heeft kunnen kijken en werken. En ook als iemand die zeer aarzelt, net als Jaap van Rees al jaren doet, om het woord architectuur te gebruiken omdat het zo vaak, in mijn ogen, misbruikt is en wordt in de informatie & IT-sector.
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 23-04-2009 07:24
Beste Steven,
Ik heb voor mezelf* een duidelijk antwoord op de vraag wat de architectuur is van iets dat bestaat: een kerk, software, een IT-infrastructuur of nog iets anders. Voor mij is dat het beeld dat de architect communiceert richting vooral (maar niet beperkt tot**) de engineers en bouwers. Om gebouwen als voorbeeld te nemen. De schetsen, de architectuurtekeningen, de schaalmodellen, de door de architect genomen beslissingen is voor mij de architectuur van het gebouw. Het gebouw zelf is voor mij het resultaat (niet alleen van de architect en de architectuur, maar van het samenwerken tussen allerlei partijen). Sterker nog, voor mij kan een architectuur ook bestaan zonder dat er werkelijk iets is veranderd, daarom spreek ik van "wil veranderen". In mijn optiek heeft een architect de wil om iets te veranderen, of dat gerealiseerd wordt is lang niet altijd zeker. Vaak stranden dingen in bijv. een bid proces, toch is er dan al sprake van een architectuur.
IT-Infrastructuur is in deze context wat lastiger. Een IT-infrastructuur is in mijn geval meestal een ooit valide oplossing dat nu het begin of context is van "mijn" probleem wat ik ga proberen op te lossen. Ik kijk dan vooral naar wat ik wil/moet veranderen omdat de dynamiek/wereld rond de bestaande infrastructuur is veranderd waardoor die niet meer afdoende aan de belangen van de stakeholders voldoet. Ik kijk dan naar veel meer dingen dan alleen maar de architectuur.
Ik vind het wel opmerkelijk dat als jij zegt dat je deze kijk een zware beperking vind en dat je zegt dat TOGAF, DYA, etc. ook deze zware beperking hebben (omdat ze ook van veranderen uitgaan) en dat we dan toch beide tot dezelfde conclusie/kritiek komen. Zegt misschien ook wel iets over de huidige methodieken, of over ons :-)
* Zonder mensen te willen overtuigen dat mijn beeld op architectuur het enige juiste beeld is. Ik kan me best voorstellen dat anderen wel (delen van) het resultaat als architectuur zien. **Natuurlijk ook richting allerlei andere partijen maar mijn ervaring en interesse komt vooral voort uit de samenwerking tussen architect(en), engineers en bouwers)
Geschreven door
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
op 23-04-2009 11:32
Wat die aangekondigde samenvatting betreft, daarin gaat voor Rijsenbrij dus steeds meer werk zitten. ;-) Gelukkig maar! Hoezo, “niet meer reageren”? Dat lijkt me geen reële optie, nadat zoveel mensen zoveel energie staken om gehoor te geven aan, nota bene, zijn verzoek om reacties.
Dank je wel, Steven (van ’t Veld), voor je nadere reacties. Vooral stem ik graag in met wat Van ‘t Veld schreef nav wat Peter Bakker eerder opwierp als associatie van architectuur met verandering. Tegelijk meen ik ook wel het accent van Bakker te volgen. Het blijft m.i. ondermeer misgaan door vanuit (het woord) architectuur te redeneren. Pap, wat is een containerbegrip, vroeg gisteren mijn oudste dochter mij toevallig. Dat staat inderdaad, meen ik, op gespannen voet met alle aspecten, verschijnselen, noem maar op die Van ‘t Veld aan de orde stelt. Dat neemt echter niet weg, en volgens mij stelt Van ’t Veld dat ook duidelijk, dat er natuurlijk van alles en nog wat verandert. Maar dat is niet, herhaal, niet àlles. Het was niet om er iets absoluuts tegenover te stellen (want daardoor verschuift het zwaartepunt van verwarring slechts), maar in een poging tot wat scherper zich op schakering dat ik hetzelfde accent koos als Bakker naar mijn idee nu presenteert. Dan helpt het om een àndere term te gebruiken. Dus niet architectuur. Mijn keuze, zeker niet origineel, viel op ontwerp. Toegespitst, informatiekundige ontwerpleer. Onmiddellijk is de nauwere associatie met verandering wèl redelijk, zelfs ronduit opportuun.
Van ’t Veld, als ik hem goed begrijp, wijst er terecht op dat veranderingen niet lòs staan. Sterker nog, als ik me een woordspeling mag veroorloven, het vèld waarin ze passend moeten opgaan is veel ruimer. De kans om die ruimte te waarderen lijkt Bakker echter op eigen initiatief te beperken want “[z]ijn ervaring en interesse komt vooral voort uit de samenwerking tussen architect(en), engineers en bouwers.” Prima, dat is ook maar weer duidelijk. Maar zelfs, of juist, onder de noemer van ontwerp-annex-verandering is die beperking op z’n gunstigst kortzichtig, maar waarschijnlijker vòl risico’s. Voor wie? Dat geeft Van ’t Veld volgens mij mooi aan. Want vooral de, zeg maar, duurzame bewoners van het veld verdienen erkenning voor “iets dat er nog niet is, iets dat er misschien moet komen.” Die hulpverleners die Bakker opsomt, zijn allang weer weg wanneer de èchte effecten optreden. In zijn rijtje noemt hij overigens tevens de architect, maar Van ’t Veld bedoelt daarmee iemand ànders, te weten iemand die verder kijkt (lees ook; zich verantwoordelijk weet) dan de apart beschouwde transactie … omdat in de werkelijkheid nu eenmaal niets strikt apart bestaat.
Met wat Van ‘t Veld mij (meer) direct adresseerde, verraste hij mij. Ja, ik wist dat hij indertijd meewerkte aan dergelijke conceptuele grondslagen. Ik ben deels aangenaam verrast dat hij dat ophaalt. Want ik ben het volkomen met Van ‘t Veld eens dat slechts zùlke grondslagen, conceptuele dus, samenhang helpen) borgen. Ik meende echter, omgekeerd, dat Van ‘t Veld van mij allang wist dat ik resultaten van die ISO-ontwikkeling principieel tekort vind schieten. De wiskundige bewijsvoering is immers ook maar bepaald door de gehanteerde axioma’s. Op mijn beurt ontwierp (!) ik een axiomatisch stelsel voor zgn radicale interdependentie. Klopt, dat strookt tevens met zijn standpunt over variëteit onder de noemer van architectuur. Dat verklaart mijn deels onaangename verrassing. ;-) Wanneer we Togaf als het ware ontologisch wilt positioneren in het gehele werkelijkheidsveld, is naar mijn overtuiging een rijkere conceptuele basis nodig dan wat de activiteiten die Van 't Veld noemt opleverden. Tijdens een eerdere discussie hier op Via Nova Architectura, om een eerdere verrassing te schetsen, verklaarde Van ’t Veld overigens dat hij geen tijd heeft om uitvoerige literatuur na te slaan. Daarom laat ik hier verwijzing ernaar maar achterwege.
Eigenlijk heeft Paul Jansen (veel) eerder in deze discussie al pogingen gewaagd om Togaf realistisch te positioneren. Het is, dat ben ik hartgrondig met hèm eens, nooit een kwestie van welles, nietes. Nooit òf zwart, òf wit. Jansen probeert met de nodige precisie te duiden wat in positieve zin de plááts van Togaf is. Daaruit volgt dat (ook) Togaf opgevat moet zijn in een bepaalde context. Het enige wezenlijke geschilpunt vind ik daarom of Togaf al dan niet op die manier ‘relatief’ is. Jansens antwoord luidt: ja. Mocht ik zijn bijdragen foutief interpreteren, zie ik natuurlijk graag zijn verbetering. In een eerdere reactie probeerde ik aan te geven dat wie op de relativiteitsvraag naar haar/zijn aard liefst met ‘nee’ wil antwoorden, die vraag niet of nauwelijks kàn begrijpen. Dat maakt deze discussie extra lastig. Wat ontbreekt is een spoor voor metacommunicatie. Dat leidt tot herhalingen, touché, waaraan ik inderdaad meedoe zoals blijkt uit deze hernieuwde vraag om aandacht voor ‘onze’ metacommunicatie.
Van ’t Veld, althans zo komen zijn bijdragen hier op mij over, wijst Togaf categorisch àf. Waarom? Dat wordt duidelijk door te willen begrijpen waar hij vóór is. Als ik het gemakshalve in één woord probeer te vangen, Van ’t Veld is vóór variëteit. Hé, dat ben ik ook! En Jansen enzovoort! Van Til, ook zo’n typisch variëteitsmens. Over variëteit gesproken, Jansen en ik zijn echter helemaal niet tégen Togaf, omdat sommige mensen er absolute claims op baseren. Dat ligt immers niet aan Togaf, maar aan die mensen. Daarom mikken we ànders. Dus, Togaf, prima, maar ‘slechts’ voor zus-en-zo. Nogmaals, daaraan hebben verstokte vóórstanders geen boodschap. Zo sektarisch is veel gedrag blijkbaar. Oeps, dat is niet anders als het gaat om conceptuele grondslagen, waarover Van ’t Veld en ik (nog) sterk van mening verschillen … Als dat toch even mag, in formele zin reikt de variëteit van mijn axiomatisch ontwerp (waarin relativisme principieel besloten ligt!) principieel verder dan dat van bijvoorbeeld John Sowa. Als het dus op rationele afweging aankomt, zoals Van ’t Veld voorstelt, zou ons meningsverschil dus allang eenvoudig opgelost moeten zijn. Maar dat zou van zijn kant enige literatuurstudie vergen; zolang dat niet gebeurt, heeft discussie over dat thema dus geen zin. Goed, verstokte vóórstanders, hoe valt te discussiëren met iemand die absolute geldigheid blijft opeisen? Feitelijk was er dan nooit een discussie en is wat er gebeurt puur een kwestie van heersende macht. Die toestand valt lastig opbouwend te veranderen, maar volgens mij moet een verantwoorde ontwerper het blijven proberen.
Geschreven door
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
op 23-04-2009 12:47
Beste Peter,
Met je laatste reactie laat je precies zien wat ik bedoel. Het verschil dat we hebben is de gerichtheid van de architect op verandering. Waarom zou iets in de IT-infrastructuur, of het nu software, hardware, bestand, netwerk of nog iets anders is, een probleem zijn? Ja, voor mensen die binnengeroepen worden om problemen op te lossen lijkt dat zo. Verkeerslichten worden ook stoplichten genoemd omdat je lang naar rood moet kijken en groen direct voorbij kunt rijden. Een IT-infrastructuur biedt ondersteuning, vigerende oplossingen. Als daar een op te lossen probleem mee is kan je die oplossing misschien inderdaad een ooit valide oplossing noemen, maar men is er wel nog steeds mee geholpen. Nog steeds, want probeer zoiets maar eens uit te zetten….
Als je de focus van verandering afhaalt en legt op stabiliteit, groei en verbetering wordt het beeld ineens totaal anders. Je hebt dan een beeld, een architectuur en dat ga je hoogstens bijstellen. Dat bijstellen kan tot het realiseren van veranderingen van de IT-infrastructuur leiden, of iets anders. Een verandering kan ook door opleiding geregeld worden, of door verhuizen of het kopen van aanvullende magazijninrichting.
Architectuur is een beeld van een (gekozen) werkelijkheid. Ongeacht hoe goed of slecht die werkelijkheid ook is. Dus iedere organisatie heeft haar architectuur van haar informatievoorziening. Je kunt architectuur expliciet(er) maken zodat deze bijvoorbeeld beter gedeeld kan worden. En als je dan een beter beeld hebt wordt het simpeler om binnen dat beeld aan te geven wat moet veranderen. Het expliciet vaststellen van zo’n verandering kan tot een bestek, een specificatie van eisen, een requirement document leiden; een analyse, dus, op basis waarvan die verandering aangepakt kan worden. Met als resultaat een aangepaste situatie zoals die van tevoren vastgesteld is binnen en waarvan van tevoren een bijgesteld beeld is gemaakt.
Architectuur is daarmee iets dat er is, en dat goed bijgehouden zal moeten worden. Het doel is niet verandering, het doel is dat je weet hoe het in elkaar zit en dat je er zo controle (noem het regie) over krijgt. En natuurlijk gaat dat over dezelfde concepten. Die worden echter nogal anders gebruikt en ingezet. Zoiets als wat we vroeger in projecten informatie analyse noemden en wat nu organisatiebreed wordt ingezet. Dat ik ook waarom ik TOGAF, DYA en de meeste andere methoden zwaar beperkend vind. Het zijn methoden die als doel hebben veranderingen te realiseren. Ze gaan uit van een probleem en werken naar een oplossing. En dat is precies waar organisaties NIET op zitten te wachten. Het is het doel van IT en van IT-leveranciers om projecten te doen, het doel binnen een organisatie is om de juiste informatie op het juiste moment op de juiste plaats te hebben. Oplossingen die dat doen zijn daarbij belangrijk, maar goed genoeg is goed genoeg. Ook ooit valide oplossingen kunnen nog steeds goed ondersteunen, al is misschien niet de nieuwste technologie gebruikt, of past de oplossing niet optimaal: je hebt er als organisatie wel iets aan. Gewoon praktisch.
De hang naar veranderen is feitelijk zwaar beperkend voor organisaties. In mijn ervaring hebben organisaties in hun primaire informatievoorziening nooit meer dan 10 of 12 soorten informatie, vaak zelfs maar 3 of 4. Door de hang naar het creëren van oplossingen hebben organisaties 100-en, 1.000-en, soms zelfs 10.000-en oplossingen opgebouwd waarin steeds weer dezelfde informatie zit. Wat is dan het nu om er nog een bij te zetten? Of een bestaande oplossing te vervangen zonder naar andere, vergelijkbare oplossingen te kijken? IT-infrastructuren zijn al zo complex, en ze worden door op veranderingen gerichte methoden vooral complexer. Tot we echte IT-infarcten krijgen, en daar zitten een aantal organisaties ontzettend dicht tegenaan. Methoden die gericht zijn op verandering hebben het niet in zich om echt naar simpeler en beter te kijken, terwijl veel toch vaak relatief gemakkelijk te realiseren is. En daarom beperken ze wat mogelijk is, en noem is ze zwaar beperkend. Hopelijk krijgen we na de kredietcrisis niet ook nog een informatiecrisis, om bovenstaande redenen.
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 23-04-2009 15:56
Met groot genoegen heb ik de laatste bijdragen gelezen. Ik raakte oprecht onder de indruk van de manier waarop van ’t Veld de essentie van architectuur middels een haast prozaïsche opsomming juist de poëtische lading wist te geven die ‘het’ (architectuur) ultiem verdient. Inderdaad: ‘het’ gaat niet alleen om veranderen... Maar toch, Mondriaan zei ooit "Ondanks alles strijdt het ideële tegen het materiële." en dat zien we in deze discussie dan ook precies gebeuren. 'Ook', want als het doel/deelgebied tot ‘een verandering’ beperkt is (context) zijn meer het met elkaar eens dan hier lijkt. Het is zoals een koe een rund is, en een rund niet noodzakelijk een koe is. Trek ik de holistischer typering door van ’t Veld nog wat verder door, dan stel ik dat het hier toch vooral om een beschouwingshouding gaat, en niet eens zozeer om de ‘scope’. Aan de timmerman is niet te zien of er uiting wordt gegeven aan een intens verlangen naar de zee, het avontuur en het onbekende of dat hier gewoon een timmerman een bootje bouwt. En in beide gevallen is er een bouwtekening, maar ik waag om het te beweren dat de ontwerper van de boot die uiting aan het genoemde verlangen geeft een (totaal) andere bouwtekening aflevert dan de bouwtekenaar die ... een bouwtekening voor een bootje leverde. En tegelijk is het zelfs mogelijk dat ze toch hetzelfde zijn. Dat laatste is minder waarschijnlijk omdat, zo interpreteer ik ook van ’t Veld, ‘bootje ontwerpen’ geen rekening houdt met de (on)kenmerken van de horizon... Overigens hebben beide eindprodukten (bootjes) hun eigen waarde, is de ene niet beter of slechter dan de ander, zolang we elk maar beoordelen vanuit de context waarin ze hoorden en waarvoor ze bedoeld zijn. Het is daarom niet zozeer de vraag naar of/of, maar, als ik mag opperen, de vaststelling van de en/en. Al weer ben ik het met van ’t Veld eens dat (juist) de bepertkte context van waaruit en waar naartoe oplossingen worden bedacht in de praktijk tot veel te veel ‘oplossingen’ leiden, die door hun aantal en soort weer voor nieuwe (interoperabiliteits) problemen zorgen, die dan weer ‘te beperkt’ tot nieuwe oplossingen aanleiding geven... Dat zegt over TOGAF dat de gebruiker ervan zich terdege van d(i)e beperking ervan bewust moet zijn! En ook: dat de persoon die zich dat voldoende bewust is, en bezig moet op een terrein dat binnen diezelfde begrenzing valt, aan TOGAF een waardevol ‘framework’-instrument kan beleven. Zijn we het vervolgens niet juist allen volledig met elkaar eens dat TOGAF niet gelijk is aan architectuur ..?! En dat iedereen die beweert dat je voldoende hebt aan een inbussleutel (TOGAF) of alleen een schroevendraaier (DYA) om ‘meubels te maken’ blijkt geeft de weidse wereld van meubels buiten IKEA niet te (willen) kennen...
Over de, inderdaad beperkte, veranderingsinvalshoek zie ik TOGAF c.s. absoluut profetisch bijdragen aan gelijksoortige en beperkte oplossingen in de lijn van de bestaande ‘oplossing’. Verbouwingen dus, met een mooi hek er omheen, en ingegeven door een geconstateerd intern probleem en gericht op de oplossing daarvan. Maar, zo hoor ik iemand zeggen, ‘met behoud van de bestaande architectuur’, hetgeen in de praktijk meestal neerkomt op het minimaal beschadigen en verliezen van die bestaande architectuur. Nogmaals: het probleem is hier niet TOGAF, maar de beschouwingshouding van de gebruiker ervan. Verandering is hooguit, soms, een tweede stap vanuit de bredere, realistischer erkenning van de ‘netwerkmaatschappij’ die we inmiddels al lang kennen, maar (als ik even bot mag chargeren) op vele plaatsen tegen beter weten in(?) nog effectief wordt tegengehouden door mensen die denken dat de A0 waarop ‘de architectuur’ staat weergegeven, inclusief de eindigheid van het papier, de werkelijkheid IS... En TOGAF kan daar dan iets te goed bij helpen :-). De enige beschouwingshouding die zowel de betrekkelijkheid van TOGAF, DYA kan zeker stellen als de veel te bonte, beperkte en veelvuldige oplossingen tot simpeler en beweeglijker architectuur kan helpen brengen, is de beschouwing vanuit context en interafhankelijkheid: het totaal inclusief emerging factors van de netwerksamenleving. Functie, structuur, schoonheid, harmonie: dat alles krijgt pas in de context (buiten de bouwput) de inhoud die het verdient en echte betekenis, zoals ik meen te begrijpen dat van ’t Veld die ook bedoelt. Precies dus ook waar Wisse op doelt als hij schrijft over ‘radicale interpendentie’ en impliciet op Metapattern wijst als stelselmatige erkenning en toepassing daarvan. En ja: daar is TOGAF totaal ongeschikt voor. En voor wie het grijze zoekt: juist uit de discussie in deze threat zie ik de bevestiging dat er in de benadering van(uit) het vak geen grijs is: je komt vanuit de brede, contextgedreven kant òf je staat met je ‘rug naar de context’ naar een ogenschijnlijk geïsoleerde verander-uitdaging te kijken. Beiden hebben hun waarde en beiden ‘moeten’ elkaar ‘van nature’ bestrijden, althans in het huidige tijdsgewricht. En nee, zomin als een beetje zwanger zijn niet kan, zo kan een beetje contextoriëntatie ook niet ... Dat vul ik dan aan met mijn eigen persoonlijke mening dat de ontwikkeling en de maatschappelijke behoefte in toenemende mate vraagt om de benadering vanuit het netwerkdenken, context en interpendentie, en dat 'die andere benadering' zijn houdbaarheiddatum al is gepasseerd, en daarbij weet ik dat er elke dag opnieuw in de praktijk wordt bewezen dat ‘die andere benadering’ nog volop en welig tiert. Van ’t Veld eindigde met ‘Hopelijk krijgen we na de kredietcrisis niet ook nog een informatiecrisis’ en helaas(?) moet ik zeggen dat het nog veel ‘erger’ is: die crisis is er al. Daarom is er een toenemende behoefte aan die ‘andere’ architecten, voor wie dus TOGAF geen (goede) oplossing biedt ...
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.
