Ik geef al jaren les in TOGAF en dat kent een interessant aanvangspatroon. Op de eerste dag kom ik binnen met een hele grote doos met die vuistdikke TOGAF boeken. Bij uitdelen zie je dat gewicht als het ware al neerdalen op de cursisten. "Moeten we dat allemaal leren?" En dan komt een tweede doos nog met Study Guides. "Wat! Tientallen meerkeuzen vragen over een plancyclus met 8 fasen? Dat is toch waterval? Big Up Front Design? We gaan bij onze organisatie voor agile tegenwoordig!" De motivatie daalt bij sommigen tot een dieptepunt. En dan zijn we nog niet eens echt begonnen. Gelukkig komt dat altijd weer goed.
"De moeder aller architectuurmethodes"
TOGAF is ooit met bombarie neergezet als "de moeder aller architectuurmethodes" en gezien het nog steeds stijgend aantal gecertificeerden "straalt" dit "radioactief" materiaal blijkbaar nog steeds. Of in ieder geval blijkt het hoogst besmettelijk. Maar past dit wapen echt nog wel in deze tijd? Het kost mij altijd weer enige tijd om de groep TOGAF ook in een moderne agile setting op waarde te leren schatten en de motivatie weer terug te brengen in de groep. Dit is mijn verhaal dat ik zal besluiten met vier concrete tips die je helpen het TOGAF materiaal "verrijkt" toe passen in jouw organisatie.
Agile werken is wat gevraagd wordt in de huidige organisaties, samenleving en economie. Eerst al je architectuurgedachten in een Roadmap, Referentie Architectuur of PSA vastleggen en die "over de muur" gooien naar management of ontwikkelaars, die tijd is dus echt voorbij. De tijd van hele dikke rapporten ook. Het TOGAF boek beschrijft tot in groot detail processtappen met in logische volgorde uit te voeren stappen, "elegant" genummerd A tot en met H, die je precies vertellen wat op welk moment te doen als architect, wie te betrekken, welk architectuurproduct te maken, welk assessment te doen etc. etc. Is dat strijdig met agile?
'Foute' interpretaties van TOGAF
Het is erg gemakkelijk om TOGAF 'fout' te interpreteren. Dan zou je bijvoorbeeld:
- Elk genoemd stapje dus ook precies zo en 100% compleet moeten gaan doen.
- Focussen op (lijvige?) documenten die moeten worden opgeleverd.
- Na elke stap een handtekening vragen en niet meer terugkomen op besluiten, ze in beton gieten.
- Er allemaal een gigantische exercitie van maken.
- Alles eerst helemaal tot in detail uitkauwen en dan pas gaan implementeren.
Toegegeven, zo geïnterpreteerd ziet het er allemaal best wel triest uit voor TOGAF. Dan zou het inderdaad een nogal "non-agile" methode zijn die flink tegen het manifesto (http://agilemanifesto.org/) in gaat. Maar al bovenstaande interpretaties staan nergens in TOGAF.
TOGAF en Agile gaan hand in hand
Zo dient TOGAF in de praktijk niet te worden toegepast. Naar mijn ervaring, juist ook door heel bewust het TOGAF stappenplan als architect toe te passen bij flink wat organisaties, is het juist een fantastisch hulpmiddel om "de dingen juist te doen", ook in het gedachtengoed omtrent het manifesto. TOGAF hamert er allereerst steeds op te vertrekken vanuit de business en in veel dialoog met de business: sterker nog, zonder een expliciete opdracht en betrokkenheid "mag" een architect van TOGAF feitelijk niet eens starten. Luisteren en communiceren dus. En daartoe dus al vroegtijdig die stakeholders inventariseren en hun concerns en scenario's echt leren begrijpen, dat is wat TOGAF voorschrijft. Niet holder-de-bolder dus maar meteen over technologie gaan beslissen en daarbij wellicht ook nog eens onbezonnen keuzes maken. Dingen doen in lijn met de strategie van je organisatie. En heel veel en subtiel itereren, want TOGAF beschrijft vele manieren om "van grof naar fijn" te gaan, stapjes terug te doen of zaken aan te passen. TOGAF promoot te denken in niveaus van fijnheid (wellicht vergelijkbaar met de epics en user stories uit SAFe?). Eerst maak je een beknopte strategische architectuur. Van daaruit kun je al meteen met bepaalde zaken aan de slag, maar andere delen moet je wellicht nog weer verder opdelen en een extra loop gunnen. Dat geeft je heel veel flexibiliteit om snel te gaan implementeren waar het kan. En TOGAF is daarnaast een prima hulpmiddel dat je helpt na te denken wie te betrekken in welke fase. Communiceren wederom! En ook expliciet stil staan bij het feit dat je de juiste verandervoorwaarden moet creëren of die in ieder geval moet toetsen.
Met TOGAF implementeer je daarnaast bewust processen en governance mechanismes in je organisatie die over projecten heen kijken om beslissingen te nemen die de flexibiliteit van je organisatie en landschap waarborgen. Elke grotere organisatie en IT-afdeling weet dat het zonder regie bijklussen uiteindelijk leidt tot een hopeloos verknoopt landschap dat al inflexibeler en duurder wordt. De gewenste agility van de organisatie gaat daar zeker aan onderdoor. Ook zo bezien is TOGAF er dus juist voor om agile te worden en te blijven. Dus geen lokale sub-optimalisaties in de waan van de dag of loslopende teams, maar in sync blijven met die stip op de horizon, die overigens best mag bewegen en enigszins vaag kan blijven.
4 tips voor TOGAF in een Agile omgeving
Radioactief materiaal is heel gevaarlijk. In de foute handen wordt het materiaal een vreselijk terreurwapen. Alles moet dan volgens procedures, rangordes en met militaire precisie worden uitgevoerd omdat 'het van TOGAF zogenaamd zo moet'. De processen worden al zwaarder en gefragmenteerder en je moet wel mee in die template wapenwedloop, want iedereen doet TOGAF, of eist van elkaar zogenaamde TOGAF documenten en werknemers met TOGAF diploma's. Maar toegepast in een agile setting bevat het dus juist zeer waardevolle middelen om je te helpen in je werk als architect en verraderlijke plekken in je organisatie te bestralen. Verruil TOGAF dus niet zomaar voor "een andere methode" die het volgens zeggen "wel gaat doen". Gebruik of combineer TOGAF met verstand. Hierbij mijn verrijkende tips:
- Laat een TOGAF plancyclus nooit langer dan 1 tot maximaal 2 maanden duren (doorlooptijd!). Zo voorkom je te gedetailleerde plannen (BUFD), uit de pas gaan lopen met de werkelijkheid en gold-plating. Natuurlijk mogen je gemaakte plannen best verder vooruit kijken, dus een strategisch roadmap opleveren voor de komende 3 jaar is wat mij betreft heel erg prima, maar stel die dus wel snel op. Misschien klinkt 2 maanden hiervoor veel te lang voor iemand die Scrum gewend is, maar voor een dergelijk strategische document moet je met veel mensen uit de top praten en die agenda's zitten gewoonweg propvol. Het is niet anders.
- Betrek in alle fasen intensief je stakeholders en verdeel architecten daarbij niet teveel in hokjes per fase. Zorg ook voor een architect die in alle fasen meeloopt als 'rode communicatie draad'. Besteed als architect minimaal 50% van je tijd aan interviewen, overleggen en reviewen met stakeholders. En daarmee bedoel ik niet enkel met collega architecten, maar juist met de management, afdelingshoofden, operatie, portfoliomanagement, dozen schuivers etc.
- Schrijf geen (dikke) documenten, maar streef naar plaatjes met beknopte toelichtingen. Voor technische zaken naar je ontwerpers kun je heel efficiënt werken met visualisaties in bv UML of ArchiMate. Voor andere stakeholders gebruik je schetsen en informele, informatieve en aantrekkelijke landschapsfoto's gemaakt in bijvoorbeeld Visio, vaak vergezeld van wat beknopte tabellen in Excel. Als het maar begrijpelijk is voor je stakeholders en ze betrokken zijn! De rest licht je mondeling toe, veel effectiever dan via papier en ze zijn je dankbaar.
- Gooi nooit maar dan ook nooit iets over de muur: in geen enkele fase en al helemaal niet in de implementatiefase. Regel dus intensieve betrokkenheid bij de uitvoering en zorg dat je de mensen kent. Zo hoor je ook weer wat er van al je plannen is geworden in de weerbarstige praktijk.
Dus hoeveel 'straalt' dat TOGAF materiaal nog anno 2014? Ik schat de halfwaardetijd van niet-verrijkt TOGAF op best nog wel enkele jaren, al was het maar door de certificeringsmotor, maar verrijkt met agile inzichten gaat de kern echt nog vele tientallen jaren mee!
Training TOGAF 9.1 examen
Bekijk hier de Training Togaf 9.1