Min EA är inte din EA!
Varför vi så lätt pratar förbi varandra
2012-06-13: Håkan Edvinsson och Peter Tallungs
OLIKA ENTERPRISE-ARKITEKTUR Du har inte samma mission som arkitekten som sitter bredvid dig. Fyra arketypiska EA-roller särskiljer olika slags EA-arbete, med olika förväntade resultat. Vilken roll har du?
Att få en EA-funktion att mogna brukar ses som att definiera mer struktur och fler roller, implementera mer process i arkitektarbetet, skapa fler artefakter, samla in mer data. Men allt detta är medel och inte mål. Och utan ett mål för arkitektarbetet som du är överens med dina intressenter om blir medlen gärna missriktade.
Det menade Tim DeGennaro från Forrester Research i sitt föredrag på it-arkitektkonferensen ITARC 2012 den 17 april på Moderna Museet i Stockholm. Men hur ska vi då resonera i stället?
EA har en otydlig uppgift
Bakgrunden är att EA har en mycket brett och löst definierad uppgift. Det blir tydligt om vi jämför med andra discipliner i vår omgivning. Systemutvecklingens mål är att leverera applikationer i tid och på budget och som möter kraven. Säkerhetsarbetet ska motverka incidenter. Driftens mål är pålitlighet och låg kostnad.
Men vad är EA-arbetets mål? Det går inte lika lätt att peka ut tydliga mål för EA-arbetet. Skälet är inte att mål saknas utan att området är så brett så att vi bör särskilja olika slags EA-arbete, med olika intressenter och olika mål. Om vi inte gör det pratar vi förbi varandra och får svårt att analysera och diskutera vår egen verksamhet, arkitekturfunktionen, dess intressenter, mål och strategi.
Vad förväntar sig dina intressenter?
En EA-funktion har naturligt många intressenter med skilda förväntningar på vad funktionen ska leverera. Intressenterna kan spänna över allt från affärsledningen, CIO, linjecheferna, projektkontoret till utvecklingschefen eller it-strategifunktionen.
Du bör fråga dig vem som är din mest inflytelserika intressent - vilket inte alltid är den som är högst i rang. Du bör sedan fråga dig vad du tror att den intressenten förväntar sig att du bidrar med. Välj ett eller flera av följande alternativ. Men var ärlig. Du ska inte ägna dig åt önsketänkande, det handlar just nu inte om vad du helst vill göra eller tror du är bäst på.
Förväntar sig dina mest inflytelserika intressenter att det primära värdet av EA-funktionen ska vara att:
- reducera kostnad och komplexitet i it,
- säkra att de enskilda verksamhetsprojekten lyckas,
- ge strategi och vision till hur vi hanterar it-frågor, eller
- stödja strategisk planering och affärstransformation?
Välj ett av ovanstående alternativ innan du läser vidare.
Fyra arketypiska EA-roller
Vi kan orientera oss i hela EA-området efter två axlar. Dels en vertikal axel som går från arbete med orientering mot organisationens strategi till arbete med orientering mot enskilda lösningsprojekt. Dels en horisontell axel som går från arbete med fokus på informationsteknik till arbete med fokus på själva verksamheten och affären.
Vi får på så sätt fyra kvadranter som var och en beskriver en arketypisk roll som en EA-funktion kan ha och ett eget värdeerbjudande. Se bilden nedan.
Tim DeGennaro menar att när ett EA-team etableras i en organisation är intressenternas avsikt vanligen att den ska ha en kärna i ett av dessa fyra specifika värdeerbjudanden. Då framträder fyra arketypiska EA-roller vilka vi kan använda för att förankra resonemang om EA-arbete.
Arketyp 1: EA som teknisk infrastruktur
Det finns EA-team som tillsätts för att få kontroll på tekniken och dess kostnader (sydost-kvadranten). Du känner igen det teamet på nyckelord som ”standardisering”, ”arkitekturmönster”, ”återanvändning” och ”teknisk granskning”.
Arketyp 2: EA som stöd till verksamhetsprojekt
Andra EA-team bildas för att säkra kvaliteten på lösningarna (sydväst-kvadranten). Då handlar det ofta om ”krav”, ”granskning av design” och ”process- och informationsmodeller”.
Det är här du oftast hittar verksamhetsarkitekter i Sverige, och Business Architects i andra länder.
Arketyp 3: EA som it-strategi
Sedan finns det EA-team som man tänker ska se till att organisationen får bästa möjliga informationsteknik (nordost-kvadranten). Då hör man ord som ”roadmap”, ”teknisk innovation”, ”it-strategi”, ”it-kompetens”.
Arketyp 4: EA som affärs-/verksamhetsstrategi
Till sist har vi de team som etableras för att bidra till strategisk affärstransformation (nordväst-kvadranten). Då talas det om ”affärsmodeller”, ”capability mapping” och ”portföljplanering”.
I Sverige har vi utbildning till affärsarkitekt som syftar till denna roll.
Av någon anledning finns det hos en del arkitekter en uppfattning om att just affärs- och verksamhetsstrategi är det finaste och mest angelägna arbetet man kan ägna sig åt, och att allt det andra inte är riktig EA, utan något slags arbete med it-lösning. Det är ett elitistiskt, omoget och exkluderande synsätt.
Vi tycker att allt EA-arbete är viktigt och att vi behöver ge alla uppgifterna ett utrymme och stöd på olika sätt. Men för detta behöver vi i resonemanget kunna skilja på de olika typerna av EA-arbete.
Förväntan på EA-teamet
Förväntan på EA-teamet skiljer sig ofta från vad det kan och vill leverera, Intressenterna till ett EA-team har ofta andra förväntningar på teamet än vad medlemmarna i teamet själva upplever är det område där de kan ge mest värde. Det blir då en spänning i relationen mellan intressenter och team som man behöver kunna hantera.
Vi ska nu titta på ett antal typfall som Tim DeGennaro har namngivit.
Typfall 1: EA-teamets traditionella identitetskonflikt
Ett EA-team har ofta haft en stark ambition att arbeta med strategi, nära affärs- och it-ledning, det vill säga i de båda övre kvadranterna. Men nästan lika ofta har teamet inte fått den rollen i verkligheten utan har mest setts som tillhöriga it-sidan och fast i nedre högra hörnet. Det här har varit så vanligt och kan nästan ses som ett kroniskt och strukturellt identitetstrauma i en hel generation av arkitekter. Man kan undra vad en sociolog eller kulturantropolog skulle säga om en sådan dissonans mellan självbild och verklighet hos en yrkesgrupp.
Typfall 2: Fast i vardagen
I en del organisationer är både intressenterna till EA-teamet och EA-teamets medlemmar överens om att teamet ska ägna sig åt strategiarbete, det vill säga de båda övre kvadranterna. Men detta hindras effektivt av de mer omedelbara och brännande uppgifter i de två nedre kvadranterna, som fyller arbetsdagarna.
Typfall 3: Gömd och glömd
Det händer ofta i större organisationer att intressenterna inte vet om eller bryr sig om vad EA-teamet hittar på. Om teamet inte själva lyckas etablera sig, blir det lätt så att man inte får någon tydlig roll alls, utan för en tynande tillvaro. Kanske gör man lite av varje, men utan att väsentligen bidra till något. Den viktiga utvecklingen sker någon annanstans i organisationen. Otaliga är de arkitektposter i företagen som är reträttplatser för trotjänare, en landshövdingutnämning i väntan på pensionen.
Typfall 4: Överbelastning
På senare tid vet ofta företag vad de ska ha EA-team till men problemet blir då ofta att de vill ha dem till allt. Det är då många olika intressenter som engagerar EA-teamet i än det ena än det andra över hela kartan. Arbetsdagarna fylls av stort och smått, från de stora frågorna till de viktiga detaljerna. Ett sådant team blir lätt ofokuserat och vinglar mellan uppgifterna utan att få ett fast grepp någonstans.
När vi har presenterat de här typfallen för kollegor har de både skrattat och suckat. Man känner igen sig själv och kollegor. Många har sett och upplevt alla typfallen under sin karriär.
Hur de fyra arketyperna hjälper dig
Om vi ska kunna resonera om hur vi ska utveckla en EA-funktion, vad vi ska fokusera på och vilka begränsningar vi har – är det viktigt att vi är överens om vilken slags EA vi avser.
Det gäller även om vi ska resonera om arbetssätt, standarder, ramverk. Är det här ramverket bra? Bra för vad? Är den här artefakten bra? För vad? Hur bidrar det här arbetssättet? Till vad? Inget är bra i största allmänhet; bara bra för ett visst syfte.
Det här är ett vida mer intelligent sätt att resonera om EA-arbetet än att bara sätta som mål att man ska implementera ett visst ramverk, en viss process etcetera.
Låt oss resonera vidare. Hur kan vi täcka hela kartan utan att förlora fokus? Kanske är EA en alldeles för stor rock att fylla ut för ett enda team utan att alldeles tappa fokus. I stället för att träta om vad som är ”riktig” EA bör vi erkänna och stödja alla specialiseringar inom området. Hur gör vi det?
Känner du igen dig i något av typfallen ovan? Och hur hanterar du det?
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.
Peter Tallungs finns 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.
Håkan Edvinsson finns på företaget Informed Decisions som är konsulter kring förbättrade beslut inom affär, verksamhet och IT. Han är författare till facklitteratur inom Enterprise Architecture.
Du når oss på peter.tallungs@irm.se och hakan.edvinsson@informeddecisions.se.
Peter Tallungs och Håkan Edvinsson
#1 Jens |
fredagen den 15 juni 2012 kl. 09:13 |
Välskrivet, tack!
#2 Robert Elm |
tisdagen den 19 juni 2012 kl. 16:56 |
Gillar verkligen sättet att beskriva olika typer av arkitekturroller med dessa arketypiska roller. Ger en bättre strategisk förståelse än när vi försöker boxa in alla tiotals olika arkitektroller som hittats på under åren.
#3 Anders |
söndagen den 1 juli 2012 kl. 20:45 |
Finns det någon anledning till att ni vänt på axlarna gentemot orginalversionen? Märk väl att det också står "Business and IT-strategy planning and alignment" i kvadranten "Business Strategy" i orginalet. Därmed blir väl inte helller översättningen / tolkningen av "Technology Strategy" till IT-strategi helt korrekt?
#4 Lars Stålheim |
måndagen den 2 juli 2012 kl. 09:29 |
Kul och intressant att ni tar upp arkitekturbredden! Jag har under mina år på Ericsson flyttat runt mellan dessa olika värdar och även om många har problem att förstå kollegorna som jobbar i en annan arkitektur kan jag konstatera att vi inom Ericsson även har ett formaliserat språk inom alla områden. Det som är mindre formaliserat är hur dessa områden ska samverka, men samtidigt är jag personligen starkt övertygad om att det är denna "brist" som driver inovationer och rationaliseringar. Redan under 80-talet tog jag med mig mina kunskap till Chalmers och några föreläsningar, vilka var mycket uppskattade. Tyvärr är detta aspekter som få institutionsanknutna lärare tar upp än idag (lätt att vara skråtrogen). (Naturligtvis använder jag nästan helt andra begrepp än DeGennaro, men det är inte det viktiga så länge de förklaras!) Lycka till med jobbet att förklara nyttan och nödvändigheten av alla modeller, det har vi alla nytta av!
#5 Peter Tallungs |
måndagen den 2 juli 2012 kl. 11:39 |
Svar till Anders: Vi tog oss friheten att vrida på Tim De Gennaros graf så att strategi-projekt-axeln blir vertikal i stället för horisontell som han hade avbildat den.
Det ändrar inget av innebörden men underlättar jämförelser med andra liknande grafer som finns. Det är ju något av en konvention när man försöker avbilda ting som dessa att avbilda övergripande företeelser (som mål och strategi) högre upp och mer konkreta företeelser (som genomförande) längre ner.
Nu ser jag dock att vi har råkat sätta etiketten ”Orientering” på strategi-projektaxeln och etiketten ”Fokus” på verksamhet-it-axeln. Det är ett misstag. Det bör vara tvärtom.
Vi hade problem med att få till en bra och lättflytande översättning av ”Business and IT-strategy planning and alignment”. Det är just ”alignment” som spökar. Det betyder ju att något linjeras, inriktas, justeras, rättas in i förhållande till något annat och avser vanligen i dessa fall att man ser till att it-strategin tjänar verksamhetens strategi.
Så det som avses med kvadranten ”Business Strategy” är enligt min tolkning den typen av EA-arbete som handlar om att affärs- och verksamhetsstrategi vilket också innefattar en it-strategi som stödjer denna.
Du har rätt i att den strategi som i så fall blir kvar på it-sidan blir det som handlar om rena teknik-/plattformsval. Som jag ser det avspeglar det hur mycket mer teknikfokuserade man är inom EA-området (liksom it-området) i USA.
Det här är svårt men också intressant. Men det som både De Gennaro och vi verkligen ville förmedla är att EA-området är mycket omfattande och att vi gör fel i att hantera det som en avgränsad uppgift. Då är det inte viktigt hur vi drar gränserna exakt, utan se det mer som tyngdpunkter som vi kan diskutera runt.
#6 Anders |
måndagen den 2 juli 2012 kl. 21:04 |
Tack, Peter! Bra resonemang. "Alignment" är ju ett så där litet fiffigt ord på engelska som inte är direkt enkelt att översätta med bara ett ord.
Min poäng är att även andra strategier (t ex HR eller miljö) påverkar verksamhetstrategi som helhet. Men det som avses i den kvadranten är att det är IT-strategin som behöver "alignas" med övrig verksamhet.
#7 Peter Tallungs |
tisdagen den 3 juli 2012 kl. 11:16 |
Om krav på ”alignment” mellan it och verksamhet: Om man säger att A ska ”alignas”, dvs rättas in i ledet i förhållande till B så har man också sagt att man betraktar A som något som kan röra sig fritt i förhållande till B, och också har en ovana att göra det, att fladdra fritt, gå egna vägar och inte går att lita på.
Och kanske är det så att it-funktionen i många verksamheter inte riktigt tjänar verksamhetens mål på bästa sätt.
Men grundproblemet är väl då att vi ännu inte betraktar it-funktionen som en fullständigt integrerad del av verksamheten utan som en servicefunktion.
Så ”alignment” är i så fall en fix av symptomen och inte en bot av sjukdomen. Och dessutom en farlig fix, eftersom det nästan alltid tolkas som att verksamhetsutveckling ska ske först, sedan ska detta resultera i krav på it-stöd. Och vi vet ju att det inte kan fungera, utan vi behöver jobba iterativt och tätt integrerat i hela kedjan.
Varför hör vi sällan att finansfunktionen bör ”alignas” med verksamheten? Eller att HR-funktionen? Eller försäljningsfunktionen? Eller ledningen? Varför är det just it som vi är så rädda för ska gå egna vägar och tjäna andra intressen än organisationens?
Det är som jag ser det ett grundläggande problem, att vi över huvud taget har tudelningen verksamhet-it. Inte att vi pratar i de termerna, för de måste vi göra så länge vi har den mentala bilden i våra organisationer.
Men vi borde ha en målbild där denna tudelning löses upp.
Vi borde göra allt vi kan för att integrera it-jobbet med det andra som händer. Det vill säga tex att it-uveckling bara ses som en aspekt bland flera av verksamhetsutveckling och inte som något avskilt, eget.
#8 Håkan Edvinsson |
tisdagen den 3 juli 2012 kl. 12:27 |
Peter har helt rätt i att IT inte ska ha en särställning. Om man skulle dra tudelningen och ett ensidigt ”alignment” till sin spets så får vi oönskade verksamheter. Om man betraktar organisationer som vägrat ta till sig ny teknik och nya arbetssätt så finner vi också att de antingen är sakteligen utdöende och minskar i betydelse, eller, så är de besvärliga att ha att göra med.
Robertson m fl anser i boken ”EA as strategy” att det successiva och planerade EA-arbetet måste samverka med motsvarande arbete inom affärsutvecklingen. De är inte enskilda företeelser. Affärsvärldens spelplan utvecklas hela tiden, liksom de tekniska förutsättningarna ständigt utvecklas. Det är när utvecklingen av teknik och nytta kan gå i takt som det blir riktigt intressant.
Tyvärr har historien försett oss med flera exempel på systemlösningar som sålts in med affärsnytta och resulterat i leveranser som inte passar in. Likaså har IT-proffs ur egen nyttoaspekt initierat ändlösa infrastrukturprojekt och gått över till kortlivade utvecklingsmiljöer med spräckta ramar vilket sänkt förtroendet. Därför kan man förstå att det lett till hårdare styrning av vad IT tar sig an och ”alignment” blivit ett ledord.
När det gäller "alignment"-åsikter av Finans och HR så är det ganska ofta man hör hur de, liksom åsikter om IT-enheten, sägs leva sitt eget liv.
#9 Anders |
onsdagen den 4 juli 2012 kl. 00:36 |
Är det så man ska tolka "alignment"? Att IT ska "rätta in sig i ledet" gentemot övrig verksamhet? I sådana fall håller jag helt och hållet med i resonemanget.
Modellen säger väl heller i sig inget om hur vi ska organisera oss. Den förhärskande organisationsformen, att klumpa ihop människor med samma kompetens på samma avdelning, tror jag sakta men säkert får ge vika för en mer dynamisk form, med multidisciplinära team som så att säga levererar längs med värdekedjan. När detta sker i större utsträckning kommer det att påverka både IT-relaterad och annan verksamhet.
Frågan är om man inte ska betrakta EA som "löst kopplat" till organisationsform? Det gör nog "min" EA iaf...
Ser du någon kommentar som du tycker är kränkande eller olaglig? Då kan du anmäla den här >>
Skriv en kommentar...