TOGAF: het universele wondermiddel?

Daan Rijsenbrij, maandag 30 maart 2009

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’s2en 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 architecten10en 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).


Opmerking

Je moet lid zijn van Via Nova Architectura om reacties te kunnen toevoegen!

Wordt lid van Via Nova Architectura

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 14.41

Geschreven door Danny Greefhorst op 30-03-2009 20:54

Hoi Daan,

Bij deze even een korte reaktie op jouw column (ik zal TOGAF inhoudelijk niet verdedigen; dat laat ik graag over aan de auteurs van TOGAF). Ik ben met je eens dat TOGAF de scherpte mist die wenselijk is en dat de oorzaak ongetwijfeld ligt in het standaardisatieproces. Zoals ik in een eerder artikel aan gaf zitten er wel veel interessante zaken in TOGAF, maar wordt je niet echt aan de hand genomen om te bepalen wat nuttig is in een specifieke situatie. Het is lastig om te bepalen wat de essentie is tussen al die interessante zaken. TOGAF is dan ook niet iets voor de beginnende architect, maar is vooral iets dat je als ervaren architect erbij stopt in je gereedschapskist.

Uiteindelijk is het de kennis en ervaring van de architect die het verschil maakt tussen een succesvol of een gefaalde architectuur. Zoals ik op de Open Group conferentie in Londen ook zal toelichten is een pragmatische en doelgerichte aanpak voor architectuur noodzakelijk. Als je TOGAF goed leest dan leent het zich goed voor een dergelijke pragmatische aanpak (je moet inderdaad wel wat pagina's lezen om dat te zien ;-)). Daarnaast denk ik dat het voortbouwen op standaarden en initiatieven zoals TOGAF uiteindelijk wel leidt tot een verdere volwassenheid van ons vakgebied.

Mvgr,

Danny

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 14.41

Geschreven door Ron Tolido op 09-04-2009 07:06

Daan Rijsenbrij bewijst met zijn column dat er nog steeds genoeg architecten zijn die liever over architectuur kissebissen dan dat ze er feitelijk een maken.

Ron Tolido, Erik Proper

-- 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. --

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 14.41

Geschreven door Daan Rijsenbrij op 30-03-2009 22:52

Danny,

Dank voor jouw volwassen reactie. Zoals ik ook al aangaf zitten er een aantal goede ideeën in TOGAF, maar die zijn een beetje ondergesneeuwd.

De verdediging van TOGAF door de auteurs zoals jij schrijft, komt niet echt op gang zoals je in de reactie van de heren van Capgemini kunt lezen. Jammer, maar zij dulden geen tegenspraak.

Vriendelijke groet,
Daan.

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 14.41

Geschreven door Daan Rijsenbrij op 30-03-2009 22:55

Ron,

Ik vind het jammer dat jij niet wat inhoudelijker reageert op mijn column. Het lijkt nu net alsof ik een open zenuw heb geraakt bij Capgemini. Trouwens, waarom zou een bouwclub zich moeten bekommeren om architectuur. Het is voor hen veel belangrijker dat ze het functioneel ontwerp kunnen lezen en daaruit professioneel kunnen bouwen.

Groetjes,
Daan.

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 14.41

Geschreven door Marc Lankhorst op 31-03-2009 09:40

Daan,

Ik sluit me bij Danny aan. Ongetwijfeld is er van alles op TOGAF af te dingen, maar er is door een zeer grote groep architecten consensus over bereikt en het vormt een nuttig stuk gereedschap. Elke \'methode\' die alleen door een eenzame goeroe wordt gepraktiseerd, maar die niet overdraagbaar is, biedt geen oplossing voor het opleiden van architecten (en we zijn het er vast over eens dat daaraan grote behoefte is). Karel Appels \"ik rotzooi maar wat aan\" maakt de tekenles op school niet overbodig.

Verder vindt ik je opiniestuk erg tendentieus geschreven, met termen als \"triviaal\", \"rigide\" en \"sekte\". Dat draagt niet bij aan een volwassen discussie en je oproep aan Ron voor een inhoudelijke reactie vind ik dan ook een gotspe. Blijkbaar wil je je afzetten tegen wat je denigrerend de \"bouwers\" noemt. Dat lijkt me bepaald niet de manier om het vakgebied vooruit te helpen.

Groet,
Marc

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 14.41

Geschreven door Daan Rijsenbrij op 31-03-2009 10:17

Marc,

Dank voor jouw openhartige reactie.

Ik ben beslist geen voorstander van een methode van een ‘eenzame’ goeroe. Ik ben überhaupt geen voorstander van een (activiteitgeoriënteerde) methode op architectuurgebied, wellicht wel voor engineering.

Consensus impliceert niet dat er een waardevol product ligt.

Natuurlijk ben ik voorstander van architectenopleidingen. Ik ben niet voor niets twee keer hoogleraar geweest, en heb jaren geleden de masteropleiding van Capgemini op de rails gezet. Juist omdat het belangrijk is dat er meer architecten komen.

Ik zet mij niet af tegen de bouwers. Aan professioneel bouwen is grote behoefte gezien de stand van zaken van de IT en de IT-projecten bij veel ondernemingen. En ik denk dat er naast te weinig architecten, zeer zeker te weinig vakbekwame engineers zijn. Op goede engineers moet je als onderneming zeer zuinig zijn en goed opleiden.

Vriendelijke groet,
Daan.

PS Ik vind het trouwens jammer dat jij en Ron jullie publicaties in AG niet inbrengen op VNA zodat de architectuurgemeenschap beide kanten van de medaille kan zien.

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 14.40

Geschreven door Mark Paauwe op 31-03-2009 10:20

Daan,

Wellicht dat je tot op heden geen enkele inhoudelijke reactie hebt gekregen omdat de opmaak van je artikel niet duidelijk maakt dat je vanuit een lijst van zeven punten kijkt naar de wereld. Zeg maar de Schaal van Rijsenbrij.

Er is niets mis lijkt mij in het hanteren van een normenkader. Het werkt objectiviteit in de hand.

Voor andere lezers van deze thread zet ik de zeven punten even duidelijker onder elkaar:

1. Het informatieverkeer in de onderneming

2. Digitale werkruimten van de gebruiker

3. Architectuurprincipes

4. Architectuurvisualisaties

5. Multidisciplinaire aanpak van de architect

6. Architectuurfasen en stappenplan

7. Rollen en taken van een architect

Dit zijn stuk voor stuk belangrijke onderwerpen voor architecten. Ik geef Daan groot gelijk als hij het belang van deze onderwerpen onder de aandacht brengt. Omdat ik niet objectief overkom als ik iets over TOGAF zeg, nodig ik graag studenten van universiteiten uit om aan de hand van deze zeven punten van Daan een paper te schrijven over TOGAF. Ze dienen dan in iedergeval Danny, Marc, Ron, Erik, Daan en anderen te interviewen.

Het lijkt mij dat de TOGAF community hier geweldig veel aan heeft. Het paper bevat dan precies een paar genuanceerde aanbevelingen voor enkele zwakke plekken in de Requirements Engineering-aanpak genaamd TOGAF.

Stel nu dat dit paper er nooit komt (dat is namelijk wel hoogst waarschijnlijk), dan komen er allemaal Rijsenbrij-architecten die los van TOGAF zeer goed bezig zijn inde boardroom. Dat is toch niet wat TOGAF wil?

Wie is er overigens ooit mee gekomen dat een compleet vakgebied een standaardmethode nodig zou hebben? Dat lijkt mij erosie van de bovenste plank.

Wie weet heeft men dit boek gelezen:
http://nl.wikipedia.org/wiki/1984_(boek)

Volgens mij heb je meer aan veel verschillende maar goede methoden.

Met vriendelijke groet,
Mark Paauwe

( mark@paauwe.info)

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 14.40

Geschreven door Paul L. Jansen op 31-03-2009 16:14

Beste Daan,
Allereerst: als lid van de BAWG (Business Architecture Work Group) van TOG (The Open Group) was ik in 2007/8 persoonlijk betrokken bij de 'upgrading' van TOGAF. Het was, en is, een feit dat TOG als organisatie zijn oorsprong en genen stevig in de ICT heeft. In '07 is TOG voorzichtig begonnen om professionals vanuit andere disciplines naar binnen te halen en te betrekken in de verdere ontwikkeling van TOG en TOGAF. Niet alleen informatiekundigen, maar juist/ook sociologen, communicatiespecialisten, businessmanagers, gedragswetenschappers etc., omdat 'architectuur' de complexiteit van de organisatie in al zijn facetten betreft. Het mag duidelijk zijn dat het veranderen van een aanbiedingsgericht IT-bouwers bolwerk naar een multidisciplinair en vraaggerichte organisatie, met overeenkomstige producten, niet zo eenvoudig is en niet snel gebeurt.
TOGAF 9 is een bouwers-product met hier en daar de eerste tekenen van holistische, creatiever en context-gedreven elementen. Helaas staan die nog allemaal 'klein' en naast de linkerbrein-benadering van stapjes en checklists, maar ik wil nog steeds een 'half vol glas' zien en bezie TOGAF 9 hoopvol als 'tussenpaus' naar een volgende versie waarin de stelregel van G. Boomans (Schrijven is Schrappen) zal zijn toegepast en er veel meer vanuit de context en de 'bloedsomloop' (informatiehuishouding) zal worden uitgegaan. Gezien de dominante rol die de 'bouwers' binnen TOG (blijven) spelen is mijn hoop wellicht niet zo realistisch, maar dat zal dan nog wel blijken. Ondertussen viel me op dat Gartner op 14 december '08 met researchpaper G00162771 o.a. de volgende Key Findings stelde:
• Through year-end 2009, 55% of EA programs will be stopped due to economic pressures and the lack of perceived value.
• By 2012, 80% of organizations will have abandoned the use of standard EA frameworks. • By 2011, 80% of large-enterprise EA guidelines and solution portfolios will include cloudcomputing services.
• By 2011, 30% of Global 2000 organizations will adopt application-neutral information architectures.
In dat opzicht krijg je dus feitelijk ook steun van Gartner war het 'standard (EA) frameworks' betreft.
Kortom: ik ben het vooral met je eens, zie die vaststelling vooral als een aanmoediging aan TOG om de compromissen te mijden en de echte 'leap' te maken, en stel vast dat de hoop dat dit gaat lukken en tot een bruikbare versie 10 zal leiden in ieder geval niet op de geschiedenis tot nu toe gebaseerd is. En ja: de benadering vanuit de business en vanuit de informatiecomponent heeft in ieder geval de toekomst.

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 14.40

Geschreven door Hans Bot op 31-03-2009 19:51

Hallo Daan,
Om te beginnen: ik zie mijzelf niet als TOGAF expert. TOGAF 8 vond ik een sympathieke poging om 'iets' op het gebied van Enterprise Architectuur te formaliseren. Ik ben een beetje afgehaakt toen in - als ik mij goed herinner - in versie 8.1.1 in het ADM model het bedrijfsobject «Requirements» plotseling vervangen werd door het bedrijfsproces «Requirements Management» - overigens zonder dat ik daar enige verklaring of rechtvaardiging voor heb kunnen terugvinden. Het leek en lijkt me niet zo praktisch om een proces te ontwerpen waar alle andere processen vervolgens afhankelijk van zijn. Dat lijkt in engineering termen angstvallig veel op een "single point of failure". Hoe je dit fatsoenlijk kunt ontkoppelen van de andere processen is voor mij in elk geval onduidelijk gebleven.
Niettemin gebruik ik TOGAF van tijd tot tijd nog steeds als informatiebron: er vallen soms best wat praktische hulpmiddelen in te vinden.
Als ik nu sentimenten en argumenten in de discussie probeer te scheiden, dan lees ik een flinke dosis kritiek op de scope van TOGAF. Veel van die kritiek ben ik geneigd te delen: enige bescheidenheid zou de architectencommunity geen kwaad doen - zeker gelet op de resultaten die tot dusverre zijn geboekt. De verwarring over het verschil tussen de taken en verantwoordelijkheden van een «engineer» en die van een «architect» zijn wijdverbreid. We bewijzen het architectuurvak m.i. een slechte dienst als we ons als engineers gedragen. Voor zover TOGAF9 daarover verwarring zaait, dan ligt er een schone taak voor de auteurs van TOGAF10.
Ik ben zoals bekend een verklaard tegenstander van «vendor driven architecture», en zie ik ook wel de nadelen van «vendor driven methodology». Hier wreekt zich naar mijn idee het ontbreken van een professionele, internationale, leveranciersonafhankelijke architectuurcommunity, waarin professionele architecten uit alle NAF-pijlers vertegenwoordigd zijn, die met voldoende autoriteit een standaard methodiek voor het vakgebied zou kunnen ontwikkelen. Tegelijkertijd kan ik er niet omheen een standaard methodiek een vooruitgang is ten opzichte van een grote verzameling leveranciersspecifieke methodieken.
Mijn vraag is daarom simpel: Zijn de leveranciers die zijn aangesloten bij de OpenGroup nu ook zo overtuigd van de praktische bruikbaarheid van TOGAF dat ze per direct stoppen met DYA, IAF, MArch en wat dies meer zij, of komt er alleen maar een extra "standaard" bij? In dat laatste geval, dan moeten we ons naar mijn bescheiden mening serieus afvragen welk probleem we daarmee dan denken op te lossen...

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 14.40

Geschreven door op 31-03-2009 20:00

Beste Daan,

Als je gevraagd wordt om een reactie te geven is dat kennelijk nodig. Daarom het navolgende, met genoegen.

TOGAF is voor mij geen onbekende. In juni 2006 heb ik tijdens de IT Architecture Practitioners Conference in Miami gesproken en dat heb ik in januari 2008 nogmaals in San Francisco gedaan. Na de eerste echte kennismaking in Miami heb ik een reactie op TOGAF geschreven. Die was lang en scherp, en staat al jaren openbaar op het net. Toen leek The Open Group nog een organisatie die open stond voor discussie en communicatie. Dat bleek niet zo te zijn, want niemand heeft ooit gereageerd. Dat heb ik nog een keer geverifieerd in 2008, en toen bleek dat de gelederen echt gesloten waren. Jammer, maar helaas.

De laatste jaren zijn Capgemini en later Getronics zich bezig gaan houden met TOGAF. Past ook wel, want die “methode” past in het verleden van Capgemini (de PANdata-tijd). Als ik de externe versies van SDM goed geteld heb zou TOGAF gezien kunnen worden als SDM versie 6 of misschien 7. Het is een reeks zich herhalende stappen die tracht steeds meer informatie te verzamelen over een IT-omgeving, om die als kennis vast te leggen. Normaal is dat in, niet al te kleine, organisaties minimaal in 5 jaar de stappen in de cirkel 5 keer uitgevoerd worden voordat een voldoende substantiële kennisbasis zou ontstaan (uitspraak binnen The Open Group). Tientallen mensjaren werk, dus, en het is sterk de vraag of die effectief zullen (of zelfs kunnen) zijn. En dan begint het dus pas, want je zult diverse fte’s in moeten zetten om het allemaal bij te houden.

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 14.40

Daan zegt, in lijn met Jaap van Rees, dat de methode het niet doet. Zeker, het is de mens die het doet, en ook zal moeten doen. Als de methode het zou doen zouden we allemaal naar de Bahama’s kunnen zodra die methode geprogrammeerd zou zijn. En dat is praktisch gewoon echt onzin.

Daar zit ook een hele zware claim van TOGAF achter: mensen die geleerd hebben volgens de methode TOGAF te werken mogen zich volgens The Open Group gecertificeerd noemen. In plat Nederlands heeft men dan het TOGAF-kunstje tijdens een cursus geleerd en dat feit staat op een The Open Group papiertje wat certificate genoemd wordt.
Ron Tolido (Capgemini) stelt, samen met Ernst Fuld (directeur NGN), in de Computable van 5 februari 2009 (http://www.computable.nl/artikel/ict_topics/beleid/2858528/2379250/...) dat beroep en certificering iets met elkaar te maken hebben en dat The Open Group de organisatie is om dat te regelen. Dus iedereen TOGAF gecertificeerd, en dan is iedereen in de informatie & IT-sector een vakmens. Onzin. Mensen die een Java-diploma hebben, of een SDM cursus hebben gelopen, of Archimate kunnen bedienen zijn daarmee toch ook geen vakmensen? Ja, ze kennen een aangegeven manier van werken, maar daar blijft het dan ook bij. Om vakmens te zijn komt er nog wel wat meer kijken dan een methode kennen die het verzamelen van IT-kennis door mensen met een IT-achtergrond van een IT-infrastructuur beoogt. Waarbij nog niemand me ooit antwoord heeft willen (of kunnen) geven hoe TOGAF zich in investeringen in (“IT-projecten”) en exploitatie van IT (“IT-beheer”) kan vertalen. Maar ja, ik ken versie 9.0 nog niet, natuurlijk.

Daan heeft deels gelijk als hij zegt dat de methode, de manier van werken, feitelijk irrelevant is voor de organisatie voor welke gewerkt wordt. Deels omdat werk aan IT zich herhaalt. Daarom is het wel handig als je eenzelfde soort werk op eenzelfde manier doet, met op zich vergelijkbare resultaten/producten. Maar, zoals gezegd, een echt vakmens kan meestal op meer manieren werken omdat hij/zij haar/zijn vak kent, voldoende ervaring heeft en als persoon kan optreden zoals nodig is. En daarbij is TOGAF maar een zeer klein deel van wat een vakmens moet kennen en kunnen. Certificering zou dan ook moeten zijn dat je kunt vaststellen wie vakmens is, welk vak die mens beheerst en, desnoods, op welk niveau deze vakmens in zijn vak kan functioneren. Een TOGAF certificering kan daar “een kunstje” aan toevoegen, tenminste als iemand als vakmens in de informatie & IT-sector werkt aan wat TOGAF beoogt te regelen. Want al het andere, en dat is nogal wat, valt daar immers buiten.

Op TOGAF 9.0 kan ik niet reageren. Gewoon omdat ik dat document van 728 bladzijden niet tot mijn beschikking heb. En ik betwijfel of ik het wel wil kopen, want ik heb er als vakmens niet of nauwelijks iets aan als ik mijn kennis van de ontwikkeling van TOGAF tot en met versie 8.x doortrek. De IT-wereld speelt zich immers tussen tactisch en operationeel niveau in een organisatie af en ik hou me vooral bezig met de strategisch/tactische vraagstukken, zoals regie over bijvoorbeeld IT. En daar heb ik tot nu toe niets van kunnen ontdekken, ook niet in de business-hoek van The Open Group (sorry Dave).

Daan zegt dat er een TOGAF-sekte ontstaan is. Die zie ik ook. Dat roept bij mij beelden op die ook tussen 1975 en 1985 rond SDM versies 1 en 2 ontstonden. Klopt ook wel, want, zoals gezegd, is TOGAF voor mij zoiets als versie 6 (of toch 7?) van SDM.

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 14.40

Ook TOGAF richt zich voornamelijk op IT ontwikkeling en dat is gemiddeld toch maar 20% van alle geld dat aan IT uitgegeven wordt. En het beeld dat Daan in zijn laatste alinea oproept “Rond TOGAF … architecten’.” kan ik ook alleen maar onderschrijven. En wat me daarbij benauwd is dat organisaties er gewoon weer opnieuw intrappen. Ongelofelijk, eigenlijk, na 70 jaar IT nog steeds. En ze blijven miljarden euro’s/dollars/… weggooien.

Zoals ik gezegd heb ben ik 2 keer naar een TOGAF congres in de VS geweest. Niet helemaal voor niets, al heeft het in relatie tot The Open Group weinig opgeleverd. Het is IT-ers gewoon niet aan het verstand 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.
Dat 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. In mijn ervaring met heel veel organisaties en mensen blijkt het veruit de meeste IT-ers niet gegeven te zijn om daar zo over na te denken, en ik zal dan ook wel weer afgeblaft worden in dit forum als het nog eens zeg. Maar het is wel de praktijk. En TOGAF heeft daar echt niets voor. Sterker nog, het werkt het ontwikkelen van de kennis van informatie zelf zelfs stevig tegen. De gezamenlijke reactie van Ron Tolido en Erik Proper op de column van Daan laat dat bijvoorbeeld ook zien. Ik heb het al eerder gezegd: weinig is meer gesloten dan The Open Group, en dus ook TOGAF.

En dan nog de tiende opmerking in Daan zijn column: “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).” Dit is wat kort door de bocht. TOGAF noemt zichzelf neutraal. Dat wil zeggen dat men elkaars belangen (die van de deelnemende IT-leveranciers) niet zal schaden. En eigenlijk is dat ongelofelijk gevaarlijk voor de klanten van die IT-leveranciers, want men zorgt, naar eigen zeggen, dus eerst voor elkaar en dan pas voor de klant.
Onafhankelijk betekent feitelijk ongebonden, zelfstandig, aan niemand onderworpen, niet door iets bepaald of geregeld. Heeft dus niet zoveel met een arbeidsverband te maken, maar meer met de manier van denken en werken. Dat wil zeker niet zeggen dat je niet gebonden bent aan beroepsregels; juist wel.
In de praktijk van de informatie & IT-sector betekent het in feite dat je niet gebonden bent aan een IT-leverancier. Oftewel je staat voor de organisatie, niet voor de belangen van leveranciers van oplossingen zoals IT. Daarom zal ik ook niets in TOGAF vinden waar ik, als onafhankelijke, iets mee kan omdat ik daarmee al een oplossingsrichting in zou slaan. Wat ik wel zal moeten weten is hoe de leverancierswereld met TOGAF denkt en werkt, zodat ik wat een organisatie wil naar hen kan vertalen (dus misschien zal ik dat boek toch nog moeten lezen….). Sterke vragers kunnen zo gemakkelijk gekoppeld worden aan sterke aanbieders, waardoor een optimale relatie in vraag/aanbod ontstaat. Zoals SAP me ooit eens vroeg: wanneer gaan organisaties nou eens echt weten wat ze willen? Als ze me dat nou eens zouden kunnen vertellen kunnen wij het optimale product leveren. Of dat helemaal waar is, is voor mij een stevige commerciële overdrijving. Maar het principe is natuurlijk waar. We zijn alleen nog lang niet zover en dus modderen we voort. Met Steve Covey: wanneer worden organisatie nou eindelijk eens zelf iemand rond hun informatievoorziening? Het antwoord laat op zich wachten.

Steven van ‘t Veld
Steven.van.t.Veld@AIM.nl

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 14.38

Geschreven door Daan Rijsenbrij 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?

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 14.38

Geschreven door Daan Rijsenbrij 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’.

Vriendelijke groet,
Daan.

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 14.38

Geschreven door Paul L. Jansen 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...

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 14.38

Geschreven door Daan Rijsenbrij 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?

Vriendelijke groet,
Daan.

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 14.38

Geschreven door H.J. van Til 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?

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 14.38

Geschreven door 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
Steven.van.t.Veld@AIM.nl

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 14.37

Geschreven door Daan Rijsenbrij 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.

Vriendelijke groet,
Daan.

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 14.37

Geschreven door 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
Steven.van.t.Veld@AIM.nl

Sponsoren

Sessies

17-04: GIA sessie over data-driven multi-channel marketing meer...

26-04: KNVI sessie over Architecture Mining meer...

Advertenties

Je kunt hier adverteren

© 2018   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden