En kritisk granskning av det mest populära ramverket för enterprise-arkitektur
DEN TREDJE OCH AVSLUTANDE DELEN Är Togaf framtiden?
Vi ska i denna del av EA-spanarnas Togaf-rapport ge vår bild av Togafs framtid. Det handlar om vår syn på hur EA-området utvecklas och hur väl Togaf ligger i linje med det spåret. Djupast handlar det om vår syn på vad arkitektarbete är och hur det kan drivas.
Togafs framtid
Vi kan redan nu avslöja vad vi tror om Togafs framtid. Det bör inte komma som en överraskning för den som följt denna serie. Togaf passerar nu - på ett ungefär - toppen på hajpkurvan. Det är nu de uppblåsta förväntningarna är som störst och härifrån går färden brant ner i det som Gartner kallar för de brustna illusionernas tråg. Frågan är vad som händer sen.
För många hajpade företeelser återfår ju efter det sin respektabilitet och stiger sakta upp längs det som i Gartners hajpkurva kallas för upplysningens jämna slänt. Det är då företeelsen börjar mogna. Till slut når företeelsen den produktiva platån där saker och ting används och ger nytta på riktigt.
Men det finns hajpade företeelser som aldrig kommer igen efter backlashen utan försvinner. Det finns då aldrig någon livskraft bakom. Antingen var det ett feltänk rakt igenom eller så blev företeelsen föråldrad innan den blommade.
Vilken väg tar då Togaf efter hajpen och det efterföljande fallet? Vi tror att Togaf aldrig stiger igen utan tynar bort och lever undanskymt i bakvattnet om några år. Vi ska motivera det i denna artikel. Vi ska också peka på alternativ till Togaf.
Vi kan lära av historien
För att spana om framtiden kan vi lära av historien. Har det funnits ett liknande läge tidigare inom samma eller närliggande område? Hur gick det där? Vilka faktorer är samma och vilka är annorlunda denna gång? Vad talar för en annan utveckling denna gång?
Vi tror att det kan vara intressant att jämföra med systemutvecklingsområdet. Dels liknar utveckling av it-system på många sätt utveckling av företagsarkitektur, även om det också finns vissa skillnader. Dels är områdena besläktade, närliggande och ofta överlappande.
Vi ber läsaren om tålamodet att följa med oss på en tillbakablick i den riktningen innan vi går tillbaka till Togaf och idag. Vi tror att det kan vara belysande hur metodtänkandet inom ett område plötsligt kan ta ett nytt spår. Utvecklingen är ofta inte linjär utan dialektisk, det vill säga från tes till antites som sedan genom syntes blir till ny tes.
Drömmen om Det Stora Ramverket
Systemutvecklingsmetod-området har haft en omtumlande resa de senaste tjugo åren. Efter en experimentell period konsoliderades metodtänkandet under andra hälften av 90-talet i ett ramverk som kom att heta Rational Unified Process, RUP.
Detta metodramverk fick ett mycket stort genomslag och blev helt dominerande i världen och i Sverige. RUP var omfattande och mycket dokumenttungt. Det rymde många moderna drag, som en fullt genomförd iterativ process, och en syn på verksamhetsanalys och kravarbete som en kontinuerlig process.
Problemet var omfattningen av ramverket. Den viktiga kärnan var svår att få syn på och drunknade bland alla artefakter som utvecklingsteamet skulle producera. Kombinationen av RUPs volym, tunga dokumentdrivna process, omognaden bland dem som skulle implementera metoden och brist på dialog runt detta i branschen blev ett problem. De flesta utvecklingsorganisationer använde sin energi till att exekvera RUP i stället för att leverera förändrad verksamhet och stödsystem.
RUP krävde djup kunskap om systemutveckling och lång erfarenhet och mognad för att verkligen fungera. Det var kunskap och mognad som saknades i branschen, inte minst hos dem som kallade sig experter på RUP och tog betalt för sin kunskap. Och RUP hade en position som den högsta sanning som gjorde att det inte kunde diskuteras öppet i branschen.
Vi tycker att metodområdet inom EA idag starkt påminner om situationen inom systemutveckling 1999. Ett dominerande och voluminöst ramverk. Liten erfarenhet av arkitekturarbete hos dem som kallar sig experter. De är måhända experter på ramverket men inte på praktiskt arkitekturarbete.
Jämförelsen mellan RUP och Togaf haltar dock. Trots att vi genom åren skällt på RUP måste vi tillstå att RUP jämfört med Togaf var ett under av modernt tänkande och praktisk användbarhet.
Upproret och det stora ramverkets död
Trendbrottet kom 1999. Många utvecklare och organisationer var trötta på metoder över huvud taget. Metod för dem var RUP. Det vill säga som de kände RUP, något som var onödig byråkrati, verklighetsfrämmande och hindrade dem i deras arbete att leverera nytta.
I stället kom ett helt nytt metodtänkande från ett annat håll, från utvecklare själva i stället för från dem som mer styrde systemutveckling på avstånd. Det är det som är känt som Agile Software Development (lättrörlig eller agil programvaruutveckling) med metoder som Scrum, Extremprogrammering med flera.
Sedan har också Lean Software Development och Kanban anslutit sig. Det är metoder som är samma andas barn men som har sitt ursprung i tillverkningsindustrin
Ett nytt synsätt
Det som är gemensamt för det nya metodtänkandet är saker som fokusering på individen och teamet, iterativ utveckling (dvs. hur man levererar tidigt och sedan stegvis förfinar), samarbete över gränser, ständig anpassning, tät och nära kommunikation och ständig utveckling av teamet och arbetssättet. Det är grundat i en hantverksnära och praktisk tradition, och från detta har en rörelse växt fram hos utvecklarna själva, som därmed har tagit ödet i sina egna händer.
Idag är lättrörlig utveckling dominerande. Det finns fortfarande organisationer som använder anpassningar av RUP, men ger då ofta RUP en lättrörlig tolkning. Det passar mycket bra ihop med RUP, eftersom RUP i grunden har samma iterativa synsätt även om det har drunknat i dokumentträsket.
Det finns en liknande rörelse hos Enterprise-arkitekter. Vi möter det tydligt varje dag, både i vårt arbete och i diskussioner med Sveriges arkitekter. Men det har inte blivit tydligt profilerat, det är inte paketerat på samma sätt.
Vi ser också motsvarande utveckling inom andra områden, som tillverkningsindustrin (Lean Production, Kanban), produktutveckling (Lean Product Development), kunskapsarbete (Lärande organisation, System Thinking, det nya tänkandet inom innovation etc). Ja även inom ledning och styrning finns det en stark ny tradition som delar grundvärderingar med nytänkandet inom andra områden.
Gemensamt för alla dessa rörelser är att de står i opposition mot ett äldre mekanistiskt och toppstyrt synsätt.
I teorin är det inte skillnad på teori och praktik
Det finns alltid en skillnad - och ska finnas en skillnad - mellan tänkarna på ett område och praktikerna. Inom systemutveckling blev avståndet för stort mellan tänkarna och praktikerna. Tänkarna var delvis inne på fel spår, tänkandet misstämde med de praktiska erfarenheterna. Därmed sprack hela området. De som då var tänkare förlorade sina positioner och nya tänkare uppstod från praktikernas läger.
Vi tror att samma sak händer inom EA-området just nu, fast kanske inte lika dramatiskt. Vi som jobbar som arkitekter känner inte igen oss ett dugg i Togaf. Det är som om Togaf adresserar ett annat område i ett annat universum.
Vi har kommit till uppfattningen att det beror på att Togaf är en helt och hållet teoretisk skapelse, och dessutom enbart handlar om styrning på övergripande nivå och inte landar i praktiskt arbete någonstans. Men det beror också på att Togaf representerar ett äldre tänkande inom EA-området som utvecklingen sprungit ifrån. Togaf kommer från den amerikanska militära och federala byråkratin, som väl är något av det mest trögrörliga vi känner till.
Vi får ofta höra att: Jo visst har Togaf brister, men det utvecklas åt rätt håll, och när nästa version kommer, då… Men Togaf har funnits i många år och visar endast svaga tecken på att hänga med i utvecklingen. Arbetet går mycket trögt. Det skulle förvåna oss mycket om det är från det hållet förnyelsen kommer inom området.
Paketlösning saknas
Men vad är då alternativet? Vi tror att Togafs framgång just nu beror på att företag och individer ser det som en paketlösning. Man tror att man då vilar på etablerade erfarenheter. Man känner egentligen inte till innehållet.
För den som söker ett paket, en färdig lösning, ett alternativt Togaf, har vi inget alternativ. Men det finns gott om erfarenheter och kunskap från olika håll, bara vi lyfter blicken. Man kan på det viset sätta samman det man behöver för sin organisation och för sin situation.
Just nu upplever vi en tid av intensiv utveckling, och det är en fröjd för den som är intresserad av områdets utveckling. Mycket inspiration kommer från andra områden. Vi har skrivit om detta i tidigare spaningar och vi kommer att skriva om allt detta framöver. Men några punkter vill vi lyfta fram här.
Och nu kommer EA-spanarnas ramverk…
Leta inte efter moderna heltäckande metoder eller ramverk. Det finns inget sådant, och det är ingen bra idé över huvud taget. Ta i stället reda på så mycket som möjligt och plocka in delar som det finns verkliga erfarenheter av från organisationer som liknar din. Ta in lite i taget och prova er fram.
- Då det gäller arbetssätt: Låt dig inspireras av de nya erfarenheterna av utvecklingsarbete från andra områden. Lean-tänkandet från tillverkningsindustrin, Agile Software Development från systemutveckling, det nya tänkandet om innovation och lärande organisationer. Allt det som tar avstamp i verkliga praktiska erfarenheter och ser utveckling som en evolutionär process.
- Då det gäller arkitekturens struktur och leverabler: Där finns lång erfarenhet av saker som processer, informationsarkitektur, it-arkitektur med mera inom EA-området. Det mesta av det gäller fortfarande, men även här sker en utveckling.
- Ta del av de nya synsätt som har kommit och som kommer, inte minst det som de äldre synsätten saknar. Hur man kan hantera komplexitet genom att dela ner verksamheten i komponenter, det som kallas Business Capabilities. Hur it är en del av verksamheten och inte en servicefunktion. Och hur arkitekturarbetet kan stödja affärsutvecklingen genom att vi hanterar relationen mellan affärslogiken och arkitekturen.
Låt detta vara vårt ramverk - om vi nu nödvändigtvis måste ha ett sådant.
Robert Elm och Peter Tallungs, IRM
2011-01-18