Samenvatting tot nu toe 
 
Het is voor mij bijzonder moeilijk om een uitgebalanceerde samenvatting te geven van de uiterst interessante discussie over de pro’s en contra’s van TOGAF 9.0. Daarnaast ontvouwde zich een discussie over wat er zou moeten zijn in plaats van TOGAF. Deze discussie is zeer inspirerend, maar nog te divers om in enkele woorden samen te vatten. 
Kortom, moeilijk om iets compacts te formuleren. Vandaar een subjectieve sfeertekening, gevolgd door enkele conclusies en enige aanbevelingen. 
 
 
Sfeertekening: 
 
Het is duidelijk dat er veel goed onderbouwde kritiek is op TOGAF 9.0, maar uit het kamp van de voorstanders is het ijzingwekkend stil. Mogen zij niets zeggen, willen zij niets zeggen of zijn zij het diep in hun hart roerend eens met de kritieken die in deze discussie zijn geuit over TOGAF 9.0? 
 
Op 30 maart merkte Danny Greefhorst terecht op: ‘Ik ben het met Daan eens dat TOGAF de scherpte mist die wenselijk is en dat de oorzaak ongetwijfeld ligt in het standaardisatieproces’ en ‘Het is lastig om te bepalen wat de essentie is tussen al die interessante zaken’. 
 
Op 31 maart constateerde Paul Jansen dat TOGAF 9.0 een bouwers product is met hier en daar de eerste tekenen van holistische, creatieve en contextgedreven elementen. 
 
Hans Bot mijmerde op 31 maart: ‘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’. Voorts stelde hij dat: ‘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’. 
 
Bijzonder treffend vind ik de opmerking van Steven van ’t Veld op 31 maart: ‘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’.  
Voorts ziet hij net als ik een TOGAF-sekte ontstaan. Hij vervolgde met: ‘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. Ook TOGAF richt zich voornamelijk op IT ontwikkeling en dat is gemiddeld toch maar 20% van alle geld dat aan IT uitgegeven wordt’. Interessant is zijn constatering: ‘weinig is meer gesloten dan The Open Group, en dus ook TOGAF’. 
 
Pieter Wisse stelde op 2 april: ‘Ik ben inderdaad eerder geneigd TOGAF met ITIL te vergelijken’ en ‘Psychoanalytisch bekeken zou TOGAF wel eens een uitdrukking van angst voor het onbekende kunnen zijn’. 
 
Ten slotte concludeerde Paul Jansen op 23 april: ‘Zijn we het vervolgens niet juist allen volledig met elkaar eens dat TOGAF niet gelijk is aan architectuur?! En, dat iedereen die beweert dat je voldoende hebt aan een inbussleutel (TOGAF) of alleen een schroevendraaier (DYA) om ‘meubels te maken’ blijk geeft de weidse wereld van meubels buiten IKEA niet te (willen) kennen’. En ‘Daarom is er een toenemende behoefte aan die ‘andere’ architecten, voor wie dus TOGAF geen (goede) oplossing biedt’. 
 
 
Conclusies: 
 
Terecht merkten velen op dat het de hoogste tijd wordt dat de ideeën over informatiekunde van Jaap van Rees worden afgestoft en worden geactualiseerd met de vele waardevolle zaken die ik heb zien langskomen in deze discussie. In de huidige praktijk lijkt de informatisering van ondernemingen niet te worden begeleid door informatiekundigen (of echte architecten), maar te worden geforceerd door technisch georiënteerde informatici. Jammer, daar lijden we al ruim 40 jaar onder. Wat hebben al die leergangen BIK aan universiteiten ons eigenlijk opgeleverd? 
 
In mijn reactie op Paul Jansen stelde ik op 1 april: ‘Je hebt gelijk, we hebben nog een hele weg te gaan voordat tussen de (business-)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’. 
 
De ontnuchterende constatering van Steven in ’t Veld op 1 april zou meer ter harte dienen te worden genomen: ‘Veranderen is het doel van IT-leveranciers. Daar verdienen zij immers geld aan. Voor organisaties gaat het echter alleen om een voldoende effectieve informatievoorziening. 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’. 
Deze conclusie zou het startpunt kunnen zijn voor een meer volwassen wijze om met IT om te gaan. Het is immers zo simpel: we hebben business en IT. In de eerste plaats willen we een effectieve business. Op de tweede plaats willen we dat die business efficiënt is, hiervoor is meestal ondersteuning van IT nodig is. Dus op de derde plaats willen we een effectieve IT-ondersteuning. En ten slotte willen we op de vierde plaats dat die IT efficiënt is. Dat dient de juiste volgorde te zijn die moet worden nagestreefd. Doch het heeft er nu alle schijn van dat veel softwarehuizen en pakketleveranciers bezig zijn een efficiënte IT te propageren, totaal voorbijgaand aan het feit dat IT bedoeld was voor een effectieve bedrijfsvoering. Kortom, in veel gevallen hebben we te maken met een verheerlijking van een suboptimalisatie op IT niveau. 
 
Ik onderschrijf volledig de conclusie van Steven in ’t Veld op 23 april: ‘Maar zolang wij SDM-achtige molochen als TOGAF, DYA en andere architectuurmethoden willen blijven pushen, komen we geen stap verder. Simpelweg omdat als je echt kijkt naar wat het kan en doet, de complexiteit ineens extreem groter maakt.’ 
 
De conclusie van Peter Bakker op 2 april lijkt mij zeer plausibel: ‘Volgens mij maak je het architectuurvak niet volwassener met zoiets als TOGAF of welk architectuurraamwerk dan ook. Volgens mij zou het vakgebied pas volwassen zijn als architecten ook aansprakelijk gesteld kunnen worden voor gebreken in hun gerealiseerde ontwerpen’. 
 
Pieter Wisse concludeerde op 23 april net als ik dat er best waardevolle zaken in TOGAF zitten: ‘Togaf, prima, maar ‘slechts’ voor zus-en-zo’. 
 
 
Aanbeveling: 
 
1. Resultaatgerichte informatisering van de onderneming. 
Jaap van Rees zei in een bijna vergeten verleden: ‘de methode doet het niet’. Zeker, het zijn de vakmensen die het moeten doen. Ik zou vier essentiële rollen willen onderscheiden: de opdrachtgever (natuurlijk uit de business), de architect (geruggensteund door engineers), de bouwer (inclusief zijn eigen engineers) en de eventuele toeleveranciers (zoals Oracle, SAP, Microsoft, Google, servicesproviders). 
Ik ben persoonlijk niet zo geïnteresseerd in de wijze waarop deze essentiële rollen hun werkzaamheden verrichten. Ik wil wel van te voren weten welke resultaten zij opleveren. Daarom pleit ik er al jaren voor dat er duidelijke resultaten (documenten) worden gedefinieerd voor de communicatie tussen die rollen en wellicht ook binnen die rollen. 
De architect maakt documenten die hij gebruikt in de communicatie met de opdrachtgever. Hij maakt andersoortige documenten voor de communicatie met andere architecten en met de te raadplegen engineers. Ten slotte maakt hij documenten die nodig zijn om de bouwer te tonen wat er moet worden gebouwd. Dit zijn drie essentieel verschillende soorten documenten. 
 
2. Een nieuw alomvattend denkkader voor architectuur, engineer en bouw. 
Op grond van de vele waardevolle bijdragen, in het bijzonder van Hans Bot, Jan van Til, Paul Jansen, Peter Bakker, Pieter Wisse en Steven van ’t Veld, zou ik wil pleiten voor een fundamentele herbezinning op het SDM-denken, of dat nu lineair is, iteratief, incrementeel of welke andere ontwikkelstrategie dan ook. 
Reeds in mijn posting op 3 april bepleitte ik dat er behoefte is aan een breder denkkader voor ‘architectuur + engineering’ waarin TOGAF eventueel kan worden gepositioneerd. Persoonlijk onderscheid ik een vraagkant die in de business ligt en een aanbodkant die in de technologie kan liggen. Ik zou architectuur willen reserveren voor de vraagkant en aan de aanbodkant de term engineering of desnoods IT-architectuur willen gebruiken.  
De knip tussen (business-)opdrachtgever en bouwer hoort pas te liggen na de functionele specificaties. De architect zorgt voor of begeleidt de architectuurfase, het functioneel ontwerp en de functionele specificaties. Dat laatste document hoort te kunnen leiden tot een bouwbare opdracht. 
 
3. Een strikte functiescheiding tussen architecten en engineers. 
Laten we voor de eenvoud architecten weer architecten noemen, en engineers weer engineers. Nu gooien we appels en peren door elkaar. En natuurlijk, het is allemaal fruit maar voor de klant is het wel zo plezierig dat als hij een appel wil ook een appel krijgt en niet een peer. Goede, creatieve architecten zijn zeldzaam. Maar een vakbekwame engineer is wellicht nog zeldzamer. Dus, heren en dames engineers wees er trots op engineer te zijn en noem jezelf geen architect. Architecten, zorg dat je informatie inwint bij vakbekwame engineers om te borgen dat je bouwopdracht bouwbaar is. En, engineers probeer de taal van de architecten te verstaan.