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 14:49
TOGAF opleiding
Naast mijn column over TOGAF in de Automatisering Gids stonden nog drie bijdragen over TOGAF. In één daarvan prijzen twee docenten, Mieke Mahakena en Dave van Gelder, TOGAF 9.0 aan met de reclameleus ‘TOGAF 9 veel consistenter’.
Zij vertellen dat zij als docenten regelmatig worden geconfronteerd met opmerkingen over inconsistenties in TOGAF 8. En stellen dat The Open Group zich deze kritiek heeft aangetrokken met als resultaat dat de consistentie in TOGAF 9 is verbeterd. Ik begrijp dat niet, waarom is deze nieuwste versie niet eindelijk volledig consistent gemaakt, in plaats van veel consistenter? Zij sluiten hun bijdrage af met de conclusie dat ‘hoewel TOGAF 9 niet perfect is, het rijp is om op grote schaal toegepast te worden’. Keer op keer stel ik dat het grote drama van de IT is dat producten nog voordat ze zijn uitgekristalliseerd in het ‘laboratorium’ al wereldwijd worden uitgerold. Alleen maar om snel geld te verdienen. Geen wonder dat op veel plaatsen de IT nog een zootje is. Laten we daarmee stoppen!
Voorts stellen deze docenten dat ook de certificering enorm is verbeterd, omdat er onderscheid is gemaakt tussen een foundation- en certified-certificering. De term ‘certified certificering’ klinkt bij mij een beetje pleonastisch, maar zal wel een diepere, wellicht esoterische, betekenis hebben. Als ik dat zo lees denk ik dat TOGAF te moeilijk is om voor te worden gecertificeerd, dus als tegemoetkoming hebben we een aantal gradaties: diplome ‘watertrappen’, diploma ‘schoolslag’ en uiteindelijk diploma ‘zwemmen met de kleren aan’.
Zij vinden dat architecten net als projectmanagers en systeemontwikkelaars ook behoefte hebben aan een standaardwerkwijze met goed gedefinieerde processen en producten ter ondersteuning van hun werkzaamheden. Ik vraag mij af waar de opdrachtgever van architectuur behoefte aan heeft. Ik denk aan creatieve architecten en niet aan architecten die een methode doorlopen als een soort looprekje, toch?
Tenslotte hun advies: maak van de inrichting van de architectuurfunctie een architectuurproject. Lijkt mij een beetje te heftig. Het opstellen van een architectuurfunctie kan in een week, en om daar een project voor op te tuigen is een beetje te veel van het goede.
PS: Zou het moederbedrijf waar deze docenten voor werken een architectuur hebben? En, is die volgens TOGAF opgesteld? Of is TOGAF alleen bedoeld voor de verkoop en niet voor eigen consumptie?
Geschreven door
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
op 01-04-2009 15:06
Steven,
Dank voor jouw wijze woorden. De lezers van deze blog zouden jouw opmerkingen zorgvuldig moeten bestuderen.
Met name jouw vergelijking met SDM vind ik bijzonder verhelderend. SDM1 en SDM 2 waren activiteitgeoriënteerd en opgesteld door Pandata, de tent waar Ron Tolido – de grote promotor van TOGAF in Nederland – vandaan kwam. Ron is ook de geestelijke vader van SDW, een tool waar een intelligente repository centraal stond. Vandaar dat ‘Requirementsmanagement’ zo’n centrale rol heeft in het voor mij nog steeds onbegrijpelijke ADM van TOGAF.
In de overgang van SDM1 naar SDM2 ligt in feite de kiem van een verantwoorde architectuur: de strikte scheiding tussen architectuur en engineering. Dit is wel begrepen door de opvolgers van Pandata die IAF in eerste instantie verder gestalte hebben gegeven, maar is daarna verwijderd. Doodzonde. Persoonlijk heb ik toen Pandata werd overgenomen door Capgemini Nederland de opvolger van SDM laten formuleren: SDM-toekomst. Deze methode was resultaatgericht in plaats van activiteitgericht. Slimme klanten zijn immers geïnteresseerd in de resultaten die zij mogen verwachten en niet in de processen die tot die resultaten leiden. Zoals prof. Veldhuizen van de Erasmus Universiteit eind tachtiger jaren reeds zij: ‘Het gaat uiteindelijk om productkwaliteit, proceskwaliteit is in feite een zwakte bod. Vaak zien wij dat als men de productkwaliteit niet kan borgen, men maar zijn toevlucht neemt tot proceskwaliteit’. Dit geldt voor systeemontwikkeling, maar het geldt nog veel sterker voor architectuur.
Ik vind het trouwens vreemd dat Capgemini haar CTO haar architectuurideeën laat verkopen, zeker tegen de achtergrond van stelling 7 van mijn tweede inaugurele rede (2004): ‘Technologie is zeer belangrijk voor architectuur. Maar zet niet de CTO (corporate technology officer) op de plaats van de CAO (corporate architectural officer). Nieuwe technologieën bieden mogelijkheden tot geavanceerdere architecturen. Maar de inzet van technologie dient dienend te blijven. De CTO hoort daarom een inspiratiebron te zijn voor de CAO. Het is uiteindelijk de verantwoordelijkheid van de CAO om nieuwe technologieën zodanig aan te wenden dat ze de effectiviteit, de efficiency en het innovatieve vermogen van de onderneming bevorderen. Architectuur is een teken van beschaving en geen vrijbrief voor een technologie-uitstalling’.
Geschreven door
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
op 01-04-2009 15:19
Beste Daan, Nav je laatste toevoeging 'TOGAF opleiding' noem ik graag nog even een facet dat onuitgesproken is gebleven, maar wezenlijk van invloed is op de architectuurdiscussie in het algemeen, en het werken met een 'framework' en certificeringen in het bijzonder. Ik heb het over de ongezonde behoefte van (business) managers om het 'hoe' van het architctenwerk te willen begrijpen en zelfs te willen 'managen'. Een standaard ingebouwd impliciete wantrouw-component die opdrachtgevers inbrengen, en waar veel te veel architecten in mee lijken te gaan, waarmee zij wantrouwen versterken en weer impliciet communiceren het 'wat' onvoldoende duidelijk te kunnen maken. Anders gezegd: er is nog steeds een stille afspraak tussen opdrachtgevers en architecten dat we het over een inspannings-relatie hebben. Dan is het bieden van vermeende zekerheden (frameworks, certificeringen) begrijpelijk. Waar het uiteindelijk natuurlijk (alleen maar) over gaat is het resultaat; de resultaat-verplichting. We hebben nog een lange weg te gaan...
Geschreven door
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
op 01-04-2009 16:43
Paul,
Je hebt gelijk, we hebben nog een hele weg te gaan voordat tussen de opdrachtgever van een IT-project of een groot verandertraject met een zware IT-component enerzijds en de bouwer anderzijds een onafhankelijke architect wordt geplaatst die aan de kant van die opdrachtgever staat en de werkelijke vraag/behoefte van die opdrachtgever accentueert. Het wordt hoog tijd dat er een emancipatie komt van de architect.
Ik heb enkele instemmende reacties ontvangen op mijn column van architecten die niet openlijk hun mening willen publiceren omdat ze bang zijn voor de softwarehuizen of voor die klanten die zich volledig door hun softwarehuis laten indoctrineren. In deze tijd van kredietcrisis kan dat grote gevolgen hebben voor hun broodwinning. Daarom lijkt het sommige onafhankelijke architecten verstandiger om maar te zwijgen. Jammer, dit weerhoudt een open discussie over de waarde van TOGAF. Ik heb daarom wel eens voorgesteld een vereniging van onafhankelijke architecten op te richten zodat businessmanagers weten waar zij moeten zijn. In mijn key note op het laatste LAC heb ik duidelijk geponeerd dat er een functiescheiding zou moeten komen tussen architecten, bouwers en toeleveranciers. Met die laatste categorie bedoel ik pakketleveranciers (zoals Oracle, SAP) en servicesproviders.
Het is ook niet zo verwonderlijk dat menige businessmanager op zekerheid wil spelen gezien het trackrecord van softwarehuizen. Dat zag je ook al bij offshoring. Managers willen met eigen ogen zien hoe hun spullen in Verweggistan worden behandeld in plaatst van dat zij de front office van hun provider vertrouwen. Die businessmanagers beseffen nog niet dat een methode geen enkele zekerheid geeft. Businessmanagers moeten daarin worden geholpen, en dat gebeurt zeker niet met een voor hen onbegrijpelijk framework als TOGAF.
Zoals ik al eerder expliciet heb toegegeven zitten er ook waarvolle componenten in TOGAF. De Open Group zou zichzelf een dienst bewijzen als ze een TOGAF versie zouden laten schrijven voor dummy’s. Een versie die direct begrijpbaar is voor businessmanagers zonder cursus en zonder uitleg. Veel eenvoudige plaatjes, grote letters en niet meer dan 50 pagina’s. Maar ja, wie gaat dat schrijven? Toch niet de auteurs van TOGAF, hoop ik. Heb jij nog tijd of zin?
Geschreven door
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
op 01-04-2009 16:47
Beste Steven,
Complimenten! Ik sluit niet uit dat ik jouw bijdrage met deze reactie toch wat uit zijn verband trek, maar dat risico neem ik dan maar. Ook realiseer ik me dat ik deze thread mogelijk enigszins misbruik, maar alweer: dat risico neem ik dan maar; je boodschap – zoals ik die begrijp – is er nu eenmaal te belangrijk voor.
Je geeft aan dat het “IT-ers gewoon niet aan het verstand [is] te brengen dat je als organisatie andere kennis nodig hebt dan IT-kennis om als organisatie IT (als in te zetten technologie) echt onder controle te kunnen krijgen, zodat de juiste IT gekocht en ingezet kan worden.” Treffend en kernachtig neergezet! Dat is me uit het hart gegrepen.
Nee, inderdaad: “[d]at betekent nooit dat IT onbelangrijk is, integendeel. Alleen je hoeft weinig of niets van motoren van auto’s zelf te weten om dagelijks van Rotterdam naar Amsterdam vv. te kunnen rijden. Je hebt dan ook kennis van informatie nodig om echte regie over IT te kunnen krijgen.” De spijker op zijn kop. Ik lees die zinnen nog een paar keer en snuif ze diep in mijn brein in. Heerlijk!
Nog een keer, die laatste zin: “Je hebt […] kennis van informatie nodig om echte regie over IT te kunnen krijgen.” Prachtig! Ja, sluit die motorkap nu maar gewoon. Verleg je focus van IT naar informatie – laat met andere woorden datgene wat zo krampachtig wordt vastgehouden los … – en de regie over IT wordt je erbij in de schoot geworpen. Scherp gezien! En alweer: “[dat] is IT-ers gewoon niet aan het verstand te brengen.” Dat is hun vak ook niet. Daar zijn informatiekundigen voor nodig, of civiel informatiekundigen als het vraagstukken op maatschappelijke schaal betreft. Maar waar zijn ze? En wie realiseert zich dat er schreeuwend behoefte is aan deze nieuwe vaklui?
Ronduit “[benauwend] is dat organisaties er gewoon weer opnieuw intrappen. Ongelofelijk, eigenlijk, na 70 jaar IT nog steeds. En ze blijven miljarden euro’s/dollars/… weggooien.” Ja, triest. Zolang organisaties het onderscheid niet willen/durven maken tussen informatici en informatiekundigen… zolang blijven ze er intrappen. Voor organisaties vormen informatiekundigen het aangrijpingspunt waarmee de impasse tussen IT en organisatie kan worden ingevuld. Nee, “[dat] is IT-ers gewoon niet aan het verstand te brengen.”
Maar hoe zit het met organisaties? Inderdaad, zoals je zelf al aangeeft: “[…] wanneer worden organisatie nou eindelijk eens zelf iemand rond hun informatievoorziening?” Pas als leidende personen hun focus structureel verleggen van IT hulpmiddelen naar informatie van betekenis. Dan pas – niet eerder – zien ze ruimte voor (civiele) informatiekunde. Daar is visie en lef voor nodig. Toch maar liever lijden aan oude en bekende problemen dan de groeipijn doorstaan die inherent is aan het verkennen van nieuwe, maar minder bekende horizonten?
Geschreven door
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
op 01-04-2009 17:31
Beste Daan, Paul (en anderen).
Omdat ik hier een punt zie in de uitwisseling tussen Daan en Paul realiseer ik me dat ik moet aanvullen wat waarschijnlijk niet duidelijk genoeg is. Die aanvulling zit in het feit dat de informatie & IT-sector zich nog steeds sterk concentreert op en rond ontwikkeling en verandering. Dit is precies de reden waarom zoiets als TOGAF niet goed meer in deze tijd past. Veranderen is het doel van IT-leveranciers. Daar verdienen zij immers geld aan. Voor organisaties gaat het echter alleen om een voldoende effectieve informatievoorziening. Niet meer, en niet minder. En die moet liefst zo min mogelijk veranderen als die voldoet, want alleen zo kan die organisatie zich zo goed mogelijk op haar werkelijke taken concentreren: bankieren, rail exploiteren, handel drijven en wat verder nog.
Het maken van deze stap opent een volledig nieuwe wereld. Business managers bestaan dan niet meer, want iedere manager is een business manager. Er is geen IT-gebruikerswereld, want iedereen gebruikt informatie, en dus vaak IT. IT dient voldoende effectief te functioneren zodat men de informatie kan krijgen die men nodig heeft. Is dat niet goed, of niet voldoende dan dient er iets te gebeuren. En dat kan bijvoorbeeld nieuwe IT aanschaffen zijn. Of de oude aanpassen. Of een paar papieren bloknotes kopen.
TOGAF gaat ervan uit dat IT moet veranderen. Er komt iets mooiers, en dat moeten we hebben. Die tijd is gewoon lang voorbij. Zo lang het goed genoeg werkt hoeven we office, onze SAP-versie, ons hypotheekpakket toch niet te vervangen: het bestaande geeft dan immers nog voldoende ondersteuning. Of als we het minimaal aanpassen werkt het weer prima. Het is vaak de IT in andere omgevingen die ons noopt om ook te veranderen: de support stopt, de gegevensformaten passen niet meer, gegevens moeten voortaan in een ander formaat elektronisch uitgewisseld worden of het is nog niet in HTML, PHP of Java (en dan sla je natuurlijk een modderfiguur) en ga zo maar door.
Wat mij betreft is TOGAF dus iets dat past bij waar IT-leveranciers mee bezig zijn. Het kan ook SDM, Prince2, DSDM, DoD-standaard of nog een andere methode zijn. Voor een organisatie is primair dat het werk dat IT-leveranciers doen goed zichtbaar en controleerbaar is. En dat is een grote opdracht aan de IT-wereld. Want waarom zou ik als organisatie moeten gaan leren (laat staan dat ik me zou moeten laten certificeren) in de manier waarop IT-leveranciers op een moment vinden dat zij moeten werken? Ik kijk wel uit. Als ik dat wel doe komt mijn organisatie in dezelfde val te zitten als waar men destijds met SDM in zat, waarbij de leveranciers bepaalden wat wel en wat niet waar is in de manier van werken.
Ik zie TOGAF, zover ik het gezien heb dan, dit niet doen. Daarom is het ook niet of nauwelijks interessant buiten de IT-wereld (en het is dan trouwens de vraag of het dan interessant is binnen de IT-wereld). Net zo interessant als de nieuwe manier waarop een monteur een nieuwe uitlaat onder een auto krijgt. Dus alleen interessant als dat een snellere en goedkopere oplossing voor mijn probleem, die kapotte uitlaat, oplevert. En dan moet men het ook nog niet wagen om een nog-niet-kapotte uitlaat te gaan vervangen. En daarbij ga ik ervan uit dat die monteur een vakmens is, al of niet vastgesteld met een certificaat. Maar zover is de IT-wereld nog lang niet. Daarom haakte ik ook in op onafhankelijkheid, in dit geval onafhankelijkheid van informatiekundigen tov IT-leveranciers. Er moet nog ontzettend veel gebeuren voordat is wat moet zijn.
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 01-04-2009 17:42
Marc Lankhorst,
Ik heb jouw publicatie van afgelopen vrijdag in de Automatisering Gids gelezen waarin jij stelt dat ArchiMate een standaardtaal is voor architectuurbeschrijvingen. ArchiMate is een product dat er mag zijn, daarmee feliciteer ik jou van harte. Maar of het dat is waar de architect op zit te wachten, betwijfel ik. Heb jij het wel eens gevraagd aan echte architecten? Als ik een traject beschouw van ‘architectuur – engineering – bouw’, vind ik dat Archimate wellicht een derde van de architectuurfase zou kunnen afdekken en de hele fase van engineering. Er blijft dus een groot stuk van de architectuurfase over waarvoor Archimate minder geschikt is. De tools voor die werkzaamheden zijn toch gewoon potlood en papier of wat geavanceerder powerpoint dan wel een wat rijker tekentool waartegen jij ten onrecht ageert.
Wat voor Archimate geldt, geldt ook voor het tool ‘Architect’ van BizzDesign. Toch zitten wij te wachten op een tool waarmee de architect uit de vrije hand kan schetsen, overgaand naar formelere vastlegging met Archimate, waarna de engineer het overneemt in Archimate en de bouwer het afmaakt met een specificatietool voor de programmatuur. Dit alles in een doorlopende stroom, met één enkele repository daaronder om de consistentie te borgen zowel bij de ontwikkeling als bij het onderhoud. Bij grote organisaties dan wel grote programma’s ligt het iets complexer maar in essentie loopt het netzo
Jij stelt dat Archimate slechts drie lagen onderkent: bedrijfs-, applicatie- en technologieconcepten. Hiermee ontken jij, net als TOGAF, het belang van het informatieverkeer. Dat is een groot gemis. Zowel TOGAF als Archimate stellen bouwen centraal in plaats van het oplossen van een probleem/uitdaging in de digitale wereld.
Trouwens liever een PowerPoint-architect dan een hightech jongen waarmee je achter zijn scherm allerlei moeilijke diagrammen moet doorworstelen. En waarom zou je trouwens die PowerPoint-architect er steeds bij moeten halen om zijn architectuurplaten uit te leggen? Deze kunnen toch ook zelfverklarend zijn, eventueel met een eenvoudige legenda in de rand.
Geschreven door
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
op 01-04-2009 17:46
Beste Jan,
Volgens mij volg je mijn betoog en mijn ideeën achter mijn reactie heel precies.
Mijn enige punt in je reactie is je toevoeging civiel (zoals in techniek: tegenover militair waarschijnlijk). Ik zie de noodzaak voor deze extra kwalificatie van het woord informatiekunde niet. Maar misschien komt dat omdat ik het nodige voor Defensie gedaan heb.
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 09-04-2009 07:07
Ron Tolido,
Ik heb in de Automatisering Gids van afgelopen vrijdag jouw bijdrage bestudeerd in het drieluik van advertorials over TOGAF, getiteld ‘Architecten eindelijk aan standaarden’. Jij stelt dat mede door de standaardisatieactiviteiten van The Open Group het werkveld van de architect langzamerhand volwassen wordt. Architecten zijn vrije denkers die echt kunnen luisteren, begrijpbaar kunnen formuleren, overlopen van haalbare creatieve suggesties en kunnen overtuigen. En dat allemaal wil jij kunnen vangen in standaarden? Waarschijnlijk heb jij mijn key note op het laatste LAC over een nieuwe generatie architecten niet echt begrepen. Jammer!
Jij stelt dat de stelling van Jaap van Rees: ‘De methode doet het niet’, wordt ondervangen door de zogenaamde ‘situatiesensitiviteit’ die jij TOGAF toeschrijft. Onzin! Een gevangenis is een gevangenis of die nu rigide of flexibel is. Ik heb echter de stellige overtuiging dat jij niet echt begrijpt wat Jaap van Rees werkelijk heeft bedoeld.
Jij stelt dat TOGAF 9.0 een verdere stap is in de goede richting.Welke richting bedoel jij eigenlijk? Wat bedoel je met de tijd van huisvlijt, heldendom en goeroes is voorbij. Slaat dit op architectuur of eigenlijk op een groot deel van de westerse sofware industrie?
Het verwondert mij trouwens dat Capgemini een meer volwassen architectuurbenadering als IAF inruilt tegen zoiets als TOGAF. Maar waarschijnlijk gaat het niet meer om architectuur, maar om extra omzet draaien of was dat jouw prijs voor het board membership van The Open Group?
Het zelfvertrouwen van een architect hangt niet af van zijn zogenaamde gereedschapskist zoals jij stelt, maar van het respect dat bouwers hebben voor de architect.
De disclaimer: ‘TOGAF 9.0 is zeker nog niet af, voor zover je ooit van ‘af’ kunt spreken. Kritiek leveren op TOGAF is ook makkelijk. Zoals elke architect weet, is afbreken nu eenmaal makkelijker dan opbouwen’, is wat al te goedkoop. Hiermee kan je op voorhand alle kritiek op een prematuur product proberen af te vangen. Maar met zoveel mankracht had er toch ook een intern consistent en uitgebalanceerd product kunnen worden neergelegd?
Vriendelijke groet, Daan.
-- De redactie moedigt de professionele discussie aan maar keurt persoonlijke aanvallen af. Niet alleen kan dit betrokkenen onterecht schade toebrengen ook kan het een eveneens ongewenste op de persoon gerichte tegenaanval uitlokken. --
Geschreven door
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
op 01-04-2009 22:36
Daan,
Ik wil me verder niet in deze discussie mengen, alleen even een inhoudelijk misverstand wegnemen: ArchiMate ziet informatie wel degelijk als zeer belangrijk. Het is alleen geen laag maar een kolom in het raamwerk. Overigens zou ook wat mij betreft een schetstool met een conversie naar formele modellen zeer welkom zijn; iets dergelijks is er zelfs al (geweest) in de UML-wereld (zelfs geschikt voor smartboards): Ideogramic (nog steeds te downloaden, maar al jaren geen ontwikkeling meer).
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.
