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 01-04-2009 23:03
Marc,
Ik vind het jammer dat jij je niet verder in deze discussie wilt mengen. Ik stel dat Archimate verder het voortraject in zou moeten worden omwikkeld. Ik wil graag horen of dat volgens jou klopt of niet. Ik ken een aantal ondernemingen die van plan zijn om Archimate te gaan gebruiken. Die hebben toch recht om de plussen en minnen van deze taal te horen, of niet soms?
Geschreven door
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
op 02-04-2009 09:10
Een laatste reactie dan nog: mijn hoop en verwachting is dat de eerstvolgende uitbreiding van ArchiMate richting requirementsmodellering gaat. Het voortraject dus. Sterker nog, daar hebben we ook concrete ideeen over, maar het is nu aan het ArchiMate Forum van The Open Group om dit proces verder in gang te zetten.
Ik meng me verder niet in de discussie omdat vanaf het begin (soms zeker gerechtvaardigde) inhoudelijke opmerkingen vermengd zijn met rancune, moddergooien en stokpaardjesrijderij. Daar pas ik voor. Overigens heb ik verder geen bezwaar tegen herpublicatie van ons ArchiMate-stuk, maar daarover zijn geen afspraken met de AG gemaakt en ik zie niks in nogmaals zo\\\\\\\'n discussie, maar dan onder ons artikel.
Geschreven door
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
op 02-04-2009 10:43
Laat ik die laatste tekst nog iets nuanceren. Mijn bezwaar tegen de toon betreft niet Daans opmerkingen over ArchiMate, maar die van een aantal andere reacties. Deze discussie gaat wat mij betreft te vaak over persoonlijke belangen, stokpaardjes en frustraties, bijv. over de rol van de IT-dienstverleners (en Capgemini in het bijzonder) vs. de zelfstandige architect.
Geschreven door
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
op 02-04-2009 11:35
Wat is architectuur? Naar mijn indruk voeren ook de meeste deelnemers aan deze discussie weer een strijd voor eigen gelijk. Dat is natuurlijk onzin. Nou ja, dat geldt pas als onzin voor wie beseft dat één en dezelfde term diverse, soms zelfs tegenstrijdige betekenissen kan hebben. Maar hier heeft het er dus nog alles van weg, dat voorstanders van àfwijkende betekenissen elkaar naar hartenlust weigeren te begrijpen. Dat is inderdaad niet zoals ikzèlf graag opvat wat een architect doet. Want karakteristiek voor een architect is volgens mij haar/zijn open houding in wat z/hij altijd weer primair als unieke opgave ervaart. Daar horen relevante verschillen ònlosmakelijk bij. Sterker nog, zonder erkenning ervan blijft een probleem onoplosbaar. Hoe een raamwerk zoals Togaf — ik nam ooit een vorige versie eens door — die noodzakelijke divergentieslag voor ontwerp bevordert, herken ik niet. Ligt dat aan mij? Of bedoelen de opstellers gewoon (heel) iets anders met architectuur? Mijn antwoord op dergelijke vragen luidt, nee, dat ligt niet aan mij, ja, hun betekenis verschilt wezenlijk. Is dat verschil erg? Zo’n vraag moet natuurlijk preciezer luiden of ìk dat erg vind. Maar dat is praktisch dan ook weer meteen onzin, want ik kan er toch niets tegen beginnen. Daarom probeer ik praktisch de verwarring te verhelpen op een manier waarop ik (nog ;-) wèl enige invloed heb. Voor mijn werkstatus heb ik zelfs nooit de aanduiding architect gebruikt. Waarom niet? Ik besef allang maar al te sterk dat andere mensen er een ànder architectuur-, respectievelijk architectbeeld op na houden èn, zoals deze discussie voor de zoveelste keer bevestigt, als absolute standaard gevestigd willen krijgen. Ik herhaal, onzin. Maar goed, daartegen begin ik niets, zo realistisch ben ik wel zodra uit gevestigde commerciële belangen een slogan gepropageerd raakt. Eigenlijk komt mij dat prima uit, want zelfs liever benut ik de term ontwerper. Daar zet ik nog een woord vóór, zodat ik mijzelf afficheer als informatiekundig ontwerper. Informatiekundige als een enkel woord vind ik te veel weghebben van informatie-analist. Dat hoort er weliswaar nadrukkelijk bij, maar daaraan ontbreekt nota bene letterlijk het primaat van synthese, ofwel ontwerp. Over nuancering, verschillen e.d. gesproken, er is overigens zelfs nòg een woord bijgekomen. Dat geeft aan dat ik met voorrang het informatieverkeer op maatschappelijke schaal beschouw als ontwerpobject. Dat leidt inderdaad tot infrastructuur. Via de associatie met civiele techniek positioneer ik mij dus als civiel-informatiekundig ontwerper. Beweer ik hiermee dat iedereen dat dan maar moet zijn? Alsjeblieft niet! Wie haar/zijn bemoeienis elders richt, moet vooral een naam kiezen die dáárvoor past, dat spreekt. Ik weiger te strijden over reële verschillen, maar bèstrijd juist hun ontkenning. Hoe dan ook, voor beoefening van civiele informatiekunde als ontwerper heb ik uiteraard al helemaal weinig tot niets aan zoiets als Togaf. Dat raamwerk stelt slechts een aparte organisatie centraal. Dat kent, zo moeilijk is dat niet te herkennen en vervolgens toe te geven, een krachtige financiële logica. Vooralsnog zijn betalende opdrachtgevers bijna uitsluitend pèr organisatie(deel) te vinden. Het vraagstuk op maatschappelijke schaal verdwijnt door ontkenning ervan echter niet, … terwijl dat met de nieuwe kans juist wel gebeurt, wèg! Merkwaardig vind ik het natuurlijk wel, dat aan onloochenbare vernetwerking onder impuls van digitale technologie nog zo weinig consequenties verbonden zijn voor wetenschappelijke annex professionele vakontwikkeling. Infrastructuur voor informatieverkeer in de ruimste zin van het maatschappelijke woord faciliteert eveneens interacties met private deelnemers …, internationaal … Convergentieraamwerken, feitelijk gericht op onderhoud en beheer, zeg ook op méér van hetzelfde en dan ook nogeens traditioneel beperkt tot een aparte organisatie, zijn vergaand irrelevant voor mijn favoriete ontwèrpwerk inclusief nieuwe integrale dimensies. Noem het in dit stadium gerust een missie. Daarmee spreek ik echter geen absoluut waardeoordeel erover uit. Wie weet is Togaf prima geschikt voor beheer van organisatorische informatiemiddelen en dat werk verdwijnt zeker niet (maar wijzigt nota bene wel als gevolg van infrastructuralisering van informatieverkeer op maatschappelijke schaal). Ik ben inderdaad eerder geneigd Togaf met Itil te vergelijken. Nou ja, ik houd het op een suggestie, want voor wat ik versta onder architectuur is dat allemaal niet zo interessant. Zo’n specifieke vergelijking laat ik daarom graag over aan een ander. Voorts wijs ik erop dat de overheersend geraakte betekenis van architectuur in het vlak van informatievoorziening m.i. de ontwerpassociatie nagenoeg compleet verloor die de term voor zgn gebouwde omgeving van oudsher draagt. Daarom slaan vergelijkingen meestal nèrgens meer op. Dat verlies kan ik betreuren, maar we moeten dóór. Daar ligt wel een groeiend probleem. Wie domweg niet weet, en daar lijkt het met de Togaffen, Archimates enzovoort ernstig op, dat via erkenning van principiële onzekerheid ontwerp pas leidt tot structuur, neemt daardoor gauw (onbewust) vooropgezette structuur als impliciet ontwerp. Zo staat het ontwerp echter van te voren al vergaand vàst. Dat is blind behoudend. Onder veranderlijke omstandigheden vormt dat, zachtjes gezegd, een risico. Psychoanalytisch bekeken zou Togaf weleens uitdrukking van angst voor het onbekende kunnen zijn. Een ontwerper verwelkomt daarentegen het onbekende. Z/hij herkent daarin een nieuwe opgave. Paradoxaal uitgedrukt heeft de professionele ontwerper voor de divergentieslag slechts behoefte aan een leidraad die haar/hem ervan weerhoudt houvast te zoeken langs een … leidraad. Ontwerpen is primair lòslaten. Tja, tegenovergestelder kunnen bijbehorende betekenissen van architectuur niet gelden. Zij zijn allebei geldig, maar èlk beperkt tot zijn relevante context. Togaf e.d. zijn vermoedelijk opgesteld door mensen die zo’n paradox niet verdragen. Hoe krijgen ontwerpers ruimte voor noodzakelijke vernieuwing tegen die ontkennende overmacht? Dat lukt steeds minder omdat opdrachtgevers valse geruststelling ontlenen aan verwijzing naar raamwerken, certificaten enzovoort. Onderdeel van dat gedragspakket is uitsluiting van die eigenwijze, lastige ontwerpers. Dat maakt mislukking doorgaans een abc-tje. Opdrachtgevers ondervinden daarvan echter nauwelijks nadelige gevolgen. De (top)managers incasseren daar vertrekpremie en/of bonus. En de (vermeende) dienstverlener heeft zijn omzet binnen. Wie heeft er eigenlijk een probleem? Onmondige betrokkenen zoals werknemers, klanten enzovoort blijven met schade achter. Kortom, de discussie zou niet over één ènkel onderwerp moeten gaan. Dè architectuur bestaat niet en (bijvoorbeeld) Togaf biedt niet hèt raamwerk ervoor. Het is daarentegen altijd een kwestie van reële verhoudingen. Waarop mikt Togaf dan wèl en dienovereenkomstig dus ook niet? Wie er reuze blij mee is, moet dat vooral zijn … mits z/hij erkent dat informatievoorziening méér vergt dan het specifieke architectuurbegrip volgens Togaf dekt. Maar juist voor die mensen bestaat dus bijna principieel een obstakel om verscheidenheid te erkennen, … anders waren ze niet zo enthousiast over hun raamwerk. Tenslotte heb ik nog enkele opmerkingen direct aan het adres van Daan Rijsenbrij. Hij riep mij, blijkbaar tegelijk met een bericht aan talloze andere mensen, op tot een bijdrage aan deze discussie. Ik waardeer zo’n stimulans zeer. Op gerichte reacties door Rijsenbrij op mijn werk, omgekeerd dus, wacht ik echter nog steeds. Daar blijkt steeds maar weer niets van te komen. Zo lees ik in zijn teksten steeds vaker de term informatieverkeer. Eerlijk gezegd zit ik te wachten op zijn expliciete claim dat hij die als eerste poneerde. Voor de goede zaak kan mij dat niets eens zoveel schelen, mits hij zich er eerst eens grondig in verdiept. Voorlopig lijkt hij iets over te slaan, dat m.i. op z’n minst wetenschappelijk onzorgvuldig is. Of bedoelt Rijsenbrij informatieverkeer in een andere betekenis dan welke ik ervoor ontwikkelde in diverse publicaties? Zo nee, dus als hij er hetzelfde mee bedoelt als ik uitwerkte, dan stel ik zijn nadruk op samenhang op prijs voor draagvlak voor civiele informatiekunde als aanvullende discipline. Zo nee, meent hij daarom dat hij zich niets van mijn werk hoeft aan te trekken? Maar geeft hij dan voor dàt thema niet de aanzet voor een netzo vruchteloze discussie als hier tot dusver over architectuur gebeurt?
Geschreven door
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
op 02-04-2009 12:15
Pieter,
De term 'informatieverkeer' wordt door mij al heel lang gebruikt en lijkt mij ook een tamelijk vanzelfsprekende term. Een dergelijke term kan toch door niemand worden geclaimd dat doen we toch ook niet voor ‘gegevensverzameling’. Of jij en ik hetzelfde bedoelen onder informatieverkeer is een interessante vraag, maar hoort niet thuis in deze discussie. Waarom zou ik trouwens een dergelijke term willen claimen? Er bestaat niet eens een goede vertaling in het engels, dus we kunnen het ook niet ‘verkopen’ aan de togaffers. Het feit dat ik (nog) niet heb gereageerd op jouw vele publicaties impliceert niet dat ik ze niet op waarde taxeer.
Vriendelijke groet, Daan.
PS Informatieverkeer is een heel belangrijk concept en ik vind het jammer dat dit niet in TOGAF of DYA expliciet is terug te vinden.
Geschreven door
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
op 02-04-2009 13:55
Steven,
Over de toevoeging ‘civiel’ het volgende (maar zie ook Wisse’s commentaar in deze thread):
Jaap van Rees introduceerde (al) in 1980 de term informatiekunde omdat hij toen al in de gaten had dat we toe waren aan ‘iets’ heel anders naast (dus niet: tegenover) de informatica. Naast de oriëntatie op technische hulpmiddelen (informatica) ontstaat er dringend behoefte aan oriëntatie op de informatie zelf: informatiekunde dus.
In “Banaan als Boemerang” (http://www.emovere.nl/?doc=80) schreef ik daarover het volgende:
(1) Zie bijvoorbeeld: “Civiele informatiekunde: op weg naar infrastructuur voor informatieverkeer” van de hand van Pieter Wisse (http://www.informationdynamics.nl/pwisse/htm/civiele_informatiekunde.htm). Ook recentere publicaties met betrekking tot Civiele Informatiekunde zijn via Wisse’s website (www.wisse.cc) beschikbaar. (2) Zie “Modern Informatieverkeer” (http://www.emovere.nl/?doc=76) voor nadere beeldvorming. Een verkorte weergave van dat artikel is onder de titel Ontsnapping uit digitaal gekkenhuis opgenomen in de bundel Eerlijk zullen we alles delen, verkenningen naar interoperabiliteit (samenstellers S. Zwienink en P.E. Wisse, GBO.Overheid/Bureau Forum Standaardisatie, 2008). Zie ook: http://www.forumstandaardisatie.nl/fileadmin/OVOS/FS1-JanvanTil.pdf. (3) Informatiekunde en Civiele Informatiekunde zijn – dat mag duidelijk zijn – nauw aan elkaar verwant en vertonen sterke wisselwerking. Met ‘náást’ bedoel ik de twee vakgebieden dan ook vooral te onderscheiden – zeker niet te scheiden!
Over de toevoeging ‘civiel’ het volgende (maar zie ook Wisse’s commentaar in deze thread):
Jaap van Rees introduceerde (al) in 1980 de term informatiekunde omdat hij toen al in de gaten had dat we toe waren aan ‘iets’ heel anders naast (dus niet: tegenover) de informatica. Naast de oriëntatie op technische hulpmiddelen (informatica) ontstaat er dringend behoefte aan oriëntatie op de informatie zelf: informatiekunde dus.
In “Banaan als Boemerang” (http://www.emovere.nl/?doc=80) schreef ik daarover het volgende:
Van Rees en Wisse wijzen in De informatie-architect (1995, p96) op samenhang en verschillen tussen Informatica en Informatiekunde: “Natuurlijk hebben informatica en informatiekunde van alles met elkaar te maken. Het laatste, informatiekunde dus, ontstond als apart vak vooral uit het eerste. Pas toen informatietechnologie op een bepaalde schaal toegepast werd, brak de behoefte aan en besef van een ruimere zienswijze door. Vergelijk dat met verkeerskunde. Met weinig auto’s is er geen behoefte verkeer expliciet te regelen. Zodra het er meer zijn, blijkt de kunde van hun samenhangende toepassing onontbeerlijk.” Zij begrepen toen al dat de nieuwe wereld, die ontstaan was als gevolg van het enorme succes van/met IT, een geheel nieuwe kijk op ‘de dingen’ vereiste (en nog steeds vereist). Naast het vak Informatica was het – toen al – de hoogste tijd om ruimte te maken voor het vak Informatiekunde; náást het vak Informatica. Nu, in 2008, zo’n 15 jaar later, is die vergelijking met verkeerskunde nog altijd en ook opnieuw actueel, zij het dat het hoofdtoneel al wel drastisch aan het veranderen is. Naast, zeg maar even, ‘traditionele’ Informatiekunde dat primair gericht is op de enkele organisatie en haar informatievoorziening, is nu ook serieuze aandacht nodig voor informatie-infrastructuur en alles wat daarbij, zowel materieel als immaterieel, komt kijken. Dat is het nieuwe vakgebied van de Civiele Informatiekunde (1). Civiele Informatiekunde roept als aparte informatiekunde al sinds 2006 om Modern Informatieverkeer (2). En ook hier geldt: niet in plaats van, maar náást (3) de ‘traditionele’ Informatiekunde.
Civiele Informatiekunde breekt als het ware dóór de informatievoorzienings-barrière van de enkele organisatie heen. En dat is ook wel logisch. Want als gevolg van de hoge doordringingsgraad van digitale netwerktechnologie (Internet) raken veel van onze traditionele leef- en werkverbanden door en door vernetwerkt en veranderen daarmee in kwalitatieve zin. De relatief statische communicatieketens van ‘weleer’ verliezen hun primaire rol in toenemende mate aan vluchtige communicatieketens over sterk wisselende configuraties van netwerkknooppunten. Een heuse informatiemaatschappij diende en dient zich aan. Hierdoor staat de organisatie als een apart bolwerk niet langer in het brandpunt van de informatiekundige belangstelling. Dat brandpunt wordt meer en meer gevormd door de individuele deelnemer aan informatieverkeer. Dat deelname aan informatieverkeer in veel gevallen plaatsvindt in relatie tot de één of andere organisatie verbaast niet, maar dat gegeven is voor de civiel informatiekundige niet (langer) van primair, van doorslaggevend belang.
Civiele Informatiekunde erkent Informatiekunde voluit, maar verlegt haar focus resoluut van organisatie georiënteerde informatievoorziening naar infrastructureel georiënteerde informatievoorziening. Een wezenlijk, want kwalitatief, onderscheid!
(1) Zie bijvoorbeeld: “Civiele informatiekunde: op weg naar infrastructuur voor informatieverkeer” van de hand van Pieter Wisse (http://www.informationdynamics.nl/pwisse/htm/civiele_informatiekunde.htm). Ook recentere publicaties met betrekking tot Civiele Informatiekunde zijn via Wisse’s website (www.wisse.cc) beschikbaar. (2) Zie “Modern Informatieverkeer” (http://www.emovere.nl/?doc=76) voor nadere beeldvorming. Een verkorte weergave van dat artikel is onder de titel Ontsnapping uit digitaal gekkenhuis opgenomen in de bundel Eerlijk zullen we alles delen, verkenningen naar interoperabiliteit (samenstellers S. Zwienink en P.E. Wisse, GBO.Overheid/Bureau Forum Standaardisatie, 2008). Zie ook: http://www.forumstandaardisatie.nl/fileadmin/OVOS/FS1-JanvanTil.pdf. (3) Informatiekunde en Civiele Informatiekunde zijn – dat mag duidelijk zijn – nauw aan elkaar verwant en vertonen sterke wisselwerking. Met ‘náást’ bedoel ik de twee vakgebieden dan ook vooral te onderscheiden – zeker niet te scheiden!
Geschreven door
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
op 02-04-2009 14:27
De 'waardenketen van gedrag' (Principes -> Inzichten -> Regels -> Gedrag) is een handvat om ook discussies als bovenstaande te duiden en te richten. Onuitgesproken verschillende betekenissen (principes) van begrippen als architectuur, infrastructuur, informatieverkeer etc. veroorzaken 'ruis'. Simpel: TOGAF is een 'set van regels' en gaat dus over een 1-slag leertraject. Het is impliciet beperkt door een principiele invulling van het begrip 'architectuur' als 'technologie', en altijd (!) beperkt tot een deelgebied (afdeling, filiaal, bedrijf...). En met ‘infrastructuur’ wordt meestal (alleen) de ‘harde’ component (routers, kabels, servers, software) bedoeld. Zie TOGAF! In die context heeft TOGAF dus zijn volle waarde. Al jarenlang propageert Daan, naar mijn mening terecht, dat de leidende kracht in architectuur niet (impliciet) de bouwer/techniek moet zijn, maar de 'business', en dat is een zeer waardevol inzicht (2-slag leerpunt) dat echter wel weer van exact dezelfde beperking tot een deelgebied uitgaat als TOGAF. Het begrip 'informatieverkeer' heeft dan ook (voor Daan c.s.) de betekenis in die beperking, mogelijk uitgebreid met het verkeer tussen verschillende, eveneens beperkte 'architecturen' (koppelvlakken). Een architect die niet de gebruikelijke beperking tot afdeling, filiaal, bedrijf of zelfs keten als uitgangspunt(!) neemt, maar principieel (3-slag) informatieverkeer op maatschappelijke schaal als uitgangspunt(!) hanteert houdt zich, zo begrijp ik van Pieter, bezig met wat hij onderscheidend Civiele Informatiekunde noemt, waarbij hij vanuit die ‘holostische’ context zich als ontwerper op de specifieke beperkingen van de vraagstelling richt. Dan ook is het evidente misverstand tussen Daan en Pieter te duiden over het begrip ‘informatieverkeer’ aangezien Daan dat, zodra hij als architect aan het werk gaat, ‘principieel’ opvat vanuit de beperking van het gebied van de opdrachtgever, terwijl Pieter het principieel opvat op het niveau van de maatschappelijke schaal, feitelijk onbeperkt dus, als uitgangspunt voor de ‘beperkte context’ waarin (vervolgens) ontworpen wordt. Ik waardeer Daan’s voortdurende strijd tegen de dominantie van bouwers en techniek, in het werkterrein van de virtuele wereld. Ik waardeer Pieter’s voortdurende strijd tegen de dominantie van de beperking, in het werkterrein van de vernetwerkte maatschappij. In mijn uitleg over wat Architectuur is (http://www.pauljansen.eu/definingarchitect.htm) probeerde ik aan verbredingen t.o.v. de gangbare beperkte definitie uiting te geven. Wat voor mij als een paal boven water staat is dat voor informatievoorziening in heden en toekomst de maatschappij als principieel uitgangspunt moet en zal gaan gelden. Er moet en zal een einde komen aan de dominantie van techneuten en bouwers, en aan de beperking van de tunnelvisie van opdrachtgevers. Dit alles betekent m.i. dat het onderwerp hier “TOGAF: het universele wondermiddel?” alleen zinnig kan worden besproken vanuit en binnen de context van TOGAF, namelijk bedoeld als ‘framework’ voor bouwers met de beperkte definitie van architectuur en gericht op de beperkte toepassing daarvan. Ofwel: het antwoord op de onderwerp-vraag van Daan is dat TOGAF geen ‘Haarlemmer Olie’ is voor alle mogelijke definities van architectuur, infrastructuur, informatieverkeer etc., maar (slechts) voor die gebieden waar de beperkter betekenis zoals TOGAF die zelf ook aangeeft van toepassing zijn.
Geschreven door
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
op 02-04-2009 16:24
Hallo Daan,
Je vroeg me om als onafhankelijke architect (ik ben in dienst van het bedrijf waarin en waarvoor ik als informatiearchitect werk) op je artikel te reageren. Normaal zou ik niet zo gauw reageren op een artikel over een architectuurstandaard die ik nog niet eens heb gedownload. Ik zal mij dan in mijn reactie ook beperken tot die zaken waar ik wel wat over denk te mogen zeggen. Vorige week nog was ik op een presentatie van een tool voor enterprise architecten. De eerste driekwart van de presentatie ging over wat de architect eigenlijk doet, waarna er gelukkig ook nog wat tijd overbleef voor het bespreken van het tool. Dat is wat ik ook in je beschrijving van TOGAF bespeur: wat doet de architect eigenlijk en wat zou die moeten doen? Bij gebrek aan een duidelijk kader, wordt alles beschreven wat iemand met de functietitel architect zou kunnen moeten (niet moeten kunnen!) doen. Een architectuurstudent of consultant van een softwarehuis zou het idee en de ambitie kunnen krijgen dat hij al die zaken ook moet kunnen en willen doen. Met als gevolg dat hij met die instelling in de praktijk waarschijnlijk niets voor elkaar zou krijgen. Een ervaren architect pikt uit een dergelijk boekwerk hopelijk wat hij ervan denkt nodig te hebben. Ik denk er overigens zelf, op dit moment, niets uit nodig te hebben.
Ik ben het met je eens dat een dik boek en een certificaat perfect past bij consultancy. Een opdrachtgever in de ICT wereld weet namelijk, bij iemand die zich architect noemt, niet wat hij in huis haalt. Met een certificaat krijgt deze in elk geval de garantie dat grote delen van een dik boek zijn gelezen. Dat het boek met hagel schiet is voor hem ook alleen maar meegenomen, want je weet nooit voor welk probleem deze een architect in huis haalt. Ook in de fysieke wereld weet je overigens niet wat het specialisme en de deskundigheid van een bouwkundig architect is. Maar je weet dan doorgaans wèl met wat voor vragen je naar hem toe moet komen.
In dat laatste zit hem wat mij betreft de crux: rollen en rolverwachtingen. Natuurlijk zou het fijn zijn als in een boek in de informatievoorzieningswereld de 'architectuur' de analoge betekenis en de 'architect' de analoge rol, taken en middelen zou krijgen die in de fysieke bouwwereld aan architectuur en de architect worden toebedeeld. Het is maar goed dat er veel tijd nodig is om een organisatie goed te leren kennen, voordat je aan de constructies moet gaan sleutelen. Waar anders moet een architect namelijk een heel traject in om aan de opdrachtgever, de planner en de metselaar uit te gaan leggen wat hij komt doen? Welke betonvlechter of bouwkundig voorman zou een architect voor een installatiekundige houden of omgekeerd? Als dit soort vakmensen in onze informatiewereld hun sporen verdiend hebben, gaan we ze allemaal architect noemen. Dan vind ik het ook niet gek dat een boek, dat de ervaring van al die vakmensen meent te moeten bundelen, over architectuur meent te gaan.
Ik houd me liever bezig met het vervullen van de, ook door jou zo bedoelde, rol van architect en neem het op de koop toe dat ik wekelijks een paar uurtjes (ja, echt!) kwijt ben met het uitleggen wat ik doe. Het woord architectuur neem ik zelf liever niet in mijn mond, omdat ik daarna steeds een kwartier moet uitleggen wat ik wel en wat ik niet bedoel. Wat ik voor het uitvoeren van die rol nodig heb, is vooral een goede taakverdeling met de mensen om me heen, in de strategische en tactische veranderprocessen in onze organisatie. Dat kan alleen als ik zelf een heel duidelijk beeld heb van wat ik in het veranderproces wil bijdragen en waar mijn talenten liggen. Zaken waar ik me voorheen, als externe consultant, op deze manier eigenlijk niet zo mee bezighield. Voorheen had ik wel behoefte aan een boek met zaken op basis waarvan ik me een positie als architect kon verwerven (en zelfs dan nog niet zo breed of diep als TOGAF). Nu heb ik veel eerder behoefte aan een ander soort standaardwerk. En wel één, waarin ik kan vinden hoe ik mijn rol als architect in strategische en tactische veranderprocessen het meest effectief kan invullen en hoe ik mijn rol, in verhouding met andere rollen in de organisatie, kan neerzetten. Onduidelijkheden daarin blijven echt steeds weer de kop opsteken, omdat er geen consensus over de betekenis en het belang van architectuur is. Met een standaard definitie van rol en rolverwachtingen, zouden we (architect, informatiemanagement en business management, onder andere) samen (ondersteund door technieken en methoden) het veranderproces als geheel op een kwalitatief hoog niveau moeten kunnen inrichten. Dit zou ik verstaan onder een standaard vanuit de vraagkant. En ja, zo'n standaardwerk zou ik heel graag zien verschijnen.
Geschreven door
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
op 02-04-2009 18:09
Beste Jan,
Ik heb het waarschijnlijk zelf veroorzaakt met mijn opmerking rond civiel, maar dit is een discussie rond TOGAF en niet over informatiekunde. Daarnaast heb ik mezelf beloofd dat ik me niet weer zou mengen in een volgende koppensnellende discussie over informatiekunde. Dat zijn voor mij 2 redenen om die discussie ook hier niet aan te gaan. Laten we het hier bij TOGAF houden, zoals Daan hem gestart heeft.
M.vr.gr.
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.
