EA-spanarnas Togaf-rapport – Del 3: Togafs framtid
En kritisk granskning av det mest populära ramverket för enterprise-arkitektur
2011-01-17: Peter Tallungs och Robert Elm
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.
Vi är glada för att läsarna vill diskutera med oss, både i kommentarsfältet och via mejl. Vi ser fram emot en fortsatt dialog.
Vi arbetar med utveckling av affär, verksamhet och IT. Det handlar om att coacha IT- och verksamhetsutvecklare att arbeta tillsammans och leverera värde dag för dag. Vi tror att vi lever i en tid av uppvaknande. Det som nu händer i relationen mellan IT och verksamhet är större än allt som hänt tidigare. Detta vill vi skriva om.
Vi är anställda på konsultföretaget IRM som startades med modelldriven verksamhets- och systemutveckling som bärande idé år 1982. IRM driver utbildningarna Certifierad verksamhetsarkitekt sedan 1994 samt Certifierad process- och verksamhetsutvecklare.
Du når oss på peter.tallungs@irm.se och robert.elm@irm.se.
Peter Tallungs och Robert Elm
#1 Robert Åkeby |
tisdagen den 18 januari 2011 kl. 09:41 |
Kul att läsa krönikan.
Håller med om det mesta, nästan allt faktiskt.
Jag vill gärna fortsätta parallellen med RUP. Om man inte anpassar RUP till organisationen utan försöker köra RUP i sin helhelt så skulle ALLA projekt som jag deltagit i kört i diket. Eftersom jag tidigt valde att anpassa RUP i det företag jag jobbade på så slapp vi det problemet.
Häri ligger just storheten hos agila metoder. Man har populariserat (jag menar på ett icke-snobbigt och positivt sätt) systemutvecklingsmetoder. På så sätt har man undvikit "anpassningsrisken". Det är bra.
Håller med om att risken finns för att samma sak kan inträffa mede TOGAF. Det är stort och teoretiskt. Men, om man väljer att anpassa och inte okritiskt ta allting utan att i stället se TOGAF som en checklista kan vi arkitekter undvika detta.
Här är egentligen skillnaden mellan mitt angreppssätt och författarnas. Jag börjar hellre med en checklista och sorterar sedan bort i stället för att utgå från ett vitt papper. Därför har jag inte lika stora invändningar mot att TOGAF är teoretiskt. Genom att anpassa det blir det praktiskt.
Man kan komma fram till ett bra resultat i bägge fallen, skillnaden är hur man startar. Och självklart är det viktigt att man följer goda och i Sverige etablerade ledarprinciper så att man inte detaljstyr, utan i stället stöder och styr. Ingen metod (eller process med Roger Sessions ordval) kan ersätta erfarenhet och sunt förnuft.
#2 Mats Gejnevall |
onsdagen den 19 januari 2011 kl. 23:24 |
Vad jag tycker har glömts i denna artikeln är en annan viktig aspekt av ett arkitekturramverk är att det ger alla inblandade ett gemensamt språk. Det kommer inte lösa alla missförstånd men ger arkitekter ett kontext att förhålla sig till när de kommunicaerar med andra arkitekter. Detta språk använd naturligtvis inte med alla intressenter utan måste sedan anpassas till olika typer av intressenter.
TOGAF och dess metamodel innehåller ett såndan språk och möjliggör skapandet av grunddata som då blir mer lättförstådda. Detta grunddata kan sedan användas för att på ett enkelt sätt skapa vyer som förklarar arkitekturlösningen för alla intressenter. En av arkitektens viktigaste uppgifter är att kommunicera sin arkitektur på ett lättförståligt sätt. En modell utan en förklaring är inte värt mycket.
#3 Mats Gejnevall |
onsdagen den 19 januari 2011 kl. 23:32 |
I en av de tidigare delarna nämndes att TOGAF inte hanterar moderna arktekturansatser som SOA och Cloud. Inom Open Group har det under de senaste 5 åren pågått ett antal projekt runt SOA som har producerat ett antal standarer som är tillgängliga för arkitekter (SOA Maturity, SOA Governance, SOA Ontology) och fler är på väg. Inom Cloud området har Open Group producerat en mängd "white papers" om affärsfördelarna med Cloud Computing och fler är på gång. Alla dessa standarder och "white papers" är kopplade till TOGAF och försöker föra TOGAF vidare in i nya moderna tankesätt.
#4 Peter Tallungs |
torsdagen den 20 januari 2011 kl. 09:47 |
Svar till Mats Gejnevall.
Vi berörde i del två att Togaf är mer av ett språk än en metod. Vi kallade det för ontologi. Det vill säga att Togaf mer definierar vad man kan prata om än redogör för hur man kan arbeta. Vi tycker att det till och med gäller för ADM, metoddelen i Togaf. Det är en beskrivning av vilka faser det kan finnas och vilka leverabler som kan finnas i ett storskaligt arkitekturarbete. Det beskrivs inte hur man kan arbeta som arkitekt, hur man tar fram en leverabel. Det beskrivs inte ens hur en viss leverabel ser ut. Därför kan man knappast kalla ADM för ett metodramverk tycker vi utan snarare ett ontologi. Så vi är helt överens där.
Jag tycker att en ontologi är minst lika viktig som en metod. Vi behöver skapa gemensamma begrepp och ett gemensamt språk för vårt yrke. Men då tycker jag också att vi ska berätta FÖR VAD inom arkitekturområdet som Togaf försöker sätta ett språk. Jag tycker inte Togaf över huvud taget berör sådant som vi som arkitekter arbetar med dagligen, annat än ytterst ytligt och rudimentärt.
Togaf är enligt vårt förmenande en begreppsapparat och ett synsätt för styrning av arkitektarbete inte arkitektarbetet i sig. Dessutom en storskalig styrning i en mycket stor organisation.
Du säger att ni inom Open Group arbetar med att försöka modernisera Togaf. Det är bra, det behövs verkligen om Togaf ska kunna spela en roll.
Men jag tror att den typen av världsomspännande kommittéarbete inte kan driva utvecklingen framåt, utan i bästa fall följa efter och fånga upp det som händer med många års eftersläpning. Precis som sker idag.
Om jag har rätt ska vi inte titta på Togaf om vi vill se framtiden.
Togaf avspeglar hur stora byråkratiska organisationer försöker hantera sin komplexitet. Och det är som vi vet de inte deras bästa gren.
#5 Lennart Hedenström |
fredagen den 21 januari 2011 kl. 00:30 |
Tallungs: "Togaf avspeglar hur stora byråkratiska organisationer försöker hantera sin komplexitet. Och det är som vi vet de inte deras bästa gren."
Fråga: Vem menar du har bästa gren att hantera den komplexitet som finns i stora organisationer?
Apropå ordet byråkrati så definierar wikipedia det som "den struktur och uppsättning regler som skapats för att styra en vanligen större organisation". Så delar man den definitionen så är det en tautologi att kalla stora organisationer byråkratiska. Därtill är ej heller denna definition av ordet en värdering.
#6 Johan Schubert |
fredagen den 21 januari 2011 kl. 13:31 |
Hej Peter och Robert,
Tack för en bra debattartikeln. Den inbjuder till många kommentarer. Nöjer mig med en kommentar denna gång.
Jag har en bakgrund som industriell systemguru och även som systemprofessor och var den första som fick KTHs guldmedalj att inom systemtänkande överbrygga vad som pågår uti verkligheten med vad som görs på högskolor. Jag vågar mig därför ha lite personliga synpunkter hur ni använder orden tänkare och teori i er artikel.
I min värld är alla tänkare mer eller mindre, både teoretiker och praktiker! Det finns inga djupare teorier inom IT eller om mjukvarusystem (enligt mig) och låt mig utveckla detta lite provocerande påstående lite.
Redan Fred Brooks (han med manmånaden och silverkulan) noterade för mer än 35 år sedan att det finns principiellt olika typer av komplexitet och dessa kräver helt olika angrepp. Denna nyansering och förståelse (återigen enligt mig) saknas nästan alltid inom IT-världen. I denna värld blandar man friskt i sina metodansatser när det gäller förändringar i ett It-landskap konsolidering, modernisering med en äkta funktionell och/eller egenskapsutveckling. Att förenkla och modernisera många av dagens äldre mycket ad-hoc IT-landskap är nödvändig och kostnadsbesparande och kräver främst god ordning och reda och här kan dagens EA-verktyg definitivt ha sitt värde av de skäl som Mats Gejnevall tar upp i sina kommentarer.
Reell utveckling (vad Brooks skulle kalla ”intrinsic”) är svårt för att det är gå ut på okända fält. Inom industriella system sker sällan reell utveckling när det sker så ofta genom att man stödjer sig på TEORIER som i sin tur har en naturvetenskaplig karaktär. Någon motsvarighet finns hittills inte inom IT. Det är visserligen bra om man är lättrörligt och ambitiös men även då är det lätt att det blir hellre än väl. Exemplen är legio.
Arkitektur är inte bara en fråga om att VILJA utan också att VETA. Hur ska det gå till?
#7 Peter Tallungs |
fredagen den 21 januari 2011 kl. 15:48 |
Svar till Lennart Hedenström:
Vi vet alla att termerna ”byråkrati” och särskilt ”byråkratisk” vanligen används i nedsättande bemärkelse. Huvuddelen av den Wikipedia-artikel du citerar ägnas åt den betydelsen. Vi är överens om att byråkrati i en den mera ovanliga men neutrala betydelsen är något bra och nödvändigt.
Du frågar efter var vi hittar kunskap och erfarenheter om hur vi bäst kan hantera den komplexitet som finns i stora organisationer. Det är en mycket viktig fråga, men också en djup, bred och mångfacetterad fråga. Det är något av en ödesfråga för EA. Det var EA-områdets mission när det startades, och under sina första 25 år har EA-communityn inte lyckats så bra med det.
Vi tror att det är för att man har drivit området från fel premisser och på fel sätt. Men nya mer användbara synsätt kommer nu. De kommer från olika håll, ofta från andra discipliner. Vi tror inte att när något har visat sig inte fungera, bara fortsätta vräka på med mer av samma, som till exempel Togaf gör.
Det är de nya synsätten inom EA våra EA-spaningar handlar om. Vi vill visa på de alternativa synsätt som nu kommer.
Så det bästa svaret är, tyvärr inget rakt och direkt svar. Men läs de spaningar som vi har skrivit så får du en bild av vad vi tror på. Och fortsätt och läs och var med i en dialog med oss.
Jag tror att vi har mycket att lära av andra discipliner som har lyckats mycket bättre med att hantera komplexitet. Som tillverkningsindustri, programvaruutveckling, det moderna tänkandet runt organisation, ledarskap och innovation.
En grundläggande strategi för att hantera komplexitet på – som jag tror - alla områden har varit att bryta ner ett större system i autonoma komponenter som också betraktas som system i sig.
Nu som först har detta synsätt vunnit insteg inom EA med ”Business Capabilities”.
Nästa vecka drar det igång en serie workshops på Sigtunastiftelsen om Business Capabilities, där deltagare från näringsliv och forskning tillsammans diskuterar erfarenheterna av att använda Business Capability-perspektivet inom EA. Det är ett samarbete mellan IASA Sweden, DAMA Scandinavia, IRM och KTH. Du är välkommen.
#8 Peter Tallungs |
fredagen den 21 januari 2011 kl. 16:11 |
Svar till Johan Schubert:
Jag tycker att det är en viktig nyansering den du berör, mellan det som ibland kallas mellan ”inbyggd” komplexitet och ”skapad” komplexitet. Den inbyggda komplexiteten består i att den verklighet som ska hanteras verkligen är komplex och inte kan förenklas. Den skapade komplexiteten består i att vi i onödan har komplicerat saker. Den inbyggda måste vi hantera. Den skapade måste vi reducera eller helt få bort, eller också i praktiken hantera fast sträva efter att förenkla.
Man ska göra saker så enkelt som det går men inte enklare. Så jag tror att vi är överens om att när vi pratar om att hantera komplexitet betyder det att sålla de olika kategorierna från varandra.
Jag arbetar mycket med verksamhetsmodellering. Då handlar det alltid om att hitta fram till en modell (ett språk) som bäst gestaltar verkligheten med dess inbyggda komplexitet, gör den så tydlig som möjligt för det aktuella syftet. Och att samtidig ta hand om den onödiga komplexiteten. Ofta löses den upp av sig självt när man hittar en bra modell, då hade den uppstått för att man tidigare till exempel hade försökt förenkla för långt. Man hade alltså försökt reducera inbyggd komplexitet, vilket alltid straffar sig.
Jag hoppas att du inte tror att vi med lättrörlighet menar att man ska göra saker så enkelt det bara går utan att inse att man inte kan skyla över inbyggd komplexitet. Det är annars en vanlig missuppfattning.
Det finns mycket bra saker skrivna om detta, av Eric Evans i boken Domain Driven Design. Boken handlar visserligen om programmering, men det är bara på ytan. Allt i boken är i högsta grad tillämpligt på EA-området, och är något av det bästa som skrivits om detta.
#9 Herbjörn Wilhelmsen |
onsdagen den 2 februari 2011 kl. 09:58 |
@Robert Åkeby
Jag lämnade en kommentar på den förra krönikan (http://www.dfkompetens.se/trendspaning/veckans-ea-spaning/2010-12-16_togaf2/index.xml) där jag tog upp det du pratar om. Denna anpassning som du pratar om är uppenbart nödvändig för att ha nytta av Togaf, men det är svårt att göra en sådan anpassning. Särskilt för personer med liten erfarenhet. Så vari ligger den stora nyttan av Togaf?
Har man erfarenhet så kan man säkert välja delar ur Togaf som man vill fokusera på, men det kan man med sin erfarenhet säkerligen göra utan Togaf. Har man inte erfarenhet är risken att man gör så mycket som möjligt, "för säkerhets skull". Detta leder till mycket onödigt arbete och att det som är allra viktigast i arkitekturarbetet på ditt företag försvinner i en stor mängd icke ändamålsenliga leverabler.
#10 Per Björkegren |
onsdagen den 2 februari 2011 kl. 14:56 |
Den första frågan är; vad menar vi med ett ramverk? TOGAF är egentligen ett ramverk för en arkitekturverksamhet, medan de flesta andra ramverk handlar om hur vi strukturerar arkitektur och i vissa fall även hur arkitektur utvecklas. Jag använder alla för mig kända metoder och ramverk för att ANPASSA till den verklighet som råder. TOGAF har som alla metoder och ramverk sin styrkor och svagheter. Idéen om en central process tycker jag är en viktig styrka. En gemensam nomenklatur är en annan. En framgångsfaktor när det gäller arkitekturarbete är erfarenhet, utan den kvittar det vilken metodisk pelare man väljer att luta sig mot. Jag tycker TOGAF är en bra utgångspunkt i sitt perspektiv för den som har erfarenhet och idéer. Man kan plocka godbitarna helt enkelt. Jag har själv aldrig upplevt något som kan kallas hype när det gäller arkitekturramverk, så i min värld har det inte varit nån peak ej heller någon indikation att det skulle dö ut.
Det sista ni skriver är mycket viktigt, att inte leta efter ett heltäckande ramverk, men TOGAF kommer nog att förbli en viktig maträtt på smörgåsbordet även framåt.
LEAN är givet. Tycker man kan börja och läsa om originalet Toyota till att börja med och anpassa detta till sin situation..
Så, det är alltså inte TOGAF som kommer att dö ut, utan den naivitet som bygger på att man kan skaffa sig ett heltäckande ramverk och därmed få alla problem lösta.
Ser du någon kommentar som du tycker är kränkande eller olaglig? Då kan du anmäla den här >>
Skriv en kommentar...