Om Business Capabilities – det nya synsättet på verksamhet
TREDJE DELEN AV TRE. Komponentperspektivet ger en ny infallsvinkel på klassiska problem inom EA-området.
Detta är den sista delen i en miniserie om Business Capabilities. Här redovisar vi två klassiska problem inom EA-området och hur komponentperspektivet kan ge en ny infallsvinkel för att lösa dessa.
Vi har i två spaningar skrivit om ett nytt sätt att se på en verksamhet. I stället för att skiva hela verksamheten rakt över i ett antal aspekter, som processer, information med mera, kan vi se den som ett antal autonoma parter som nätverkar.
Det synsättet har många styrkor. Vi tror att det kan bidra till att lösa upp klassiska knutar inom EA-området. Vi ger här två exempel.
Problem 1: SOA har inte levererat
Det senaste decenniet har det funnits en strävan att bryta upp it-landskapet i våra företag och organisationer. Man har önskat omforma det från ett antal monolitiska it-system till fler mindre och autonoma komponenter i form av elektroniska tjänster. Det har kallats SOA, Service Oriented Architecture.
Det stora löftet med SOA var att det skulle ge en systemportfölj som bättre avspeglar och följer verksamhetens behov över tiden. Diskursen har handlat om hur en tjänst bör utformas, för största möjliga oberoende i syfte att bli tålig och flexibel. Ämnet är förstås viktigt men också grundligt genomtröskat vid det här laget. Vi har hyllmetrar hemma som handlar om design av SOA-tjänster.
Men när det kommer till vilka tjänster vi egentligen ska bygga, hur vi ska komma fram till planen för tjänsteportföljen, blir det märkligt tyst. Alla är överens om att tjänsteportföljen ska baseras på en väl utformad och korrekt verksamhetsanalys. Men ingen har kunnat visa hur en sådan ska tas fram eller vilka delar som ska ingå. Och ingenstans har vi heller sett att man tagit fram en plan för en tjänsteportfölj som har haft mening för en verksamhet.
Det har visserligen gjorts försök att få ihop tjänster med de traditionella företeelser inom verksamhetsarkitektur, som processer och informationsobjekt. Men inget har varit övertygande som gemensam plattform och språk för it- och verksamhetsfolk.
De SOA-satsningar som har gjorts har följaktligen varit interna övningar för it-arkitekter. Man har i bästa fall fått det som brukar kallas JBOWS, ”Just a Bunch of Web Services”, vilket knappast är en tjänstebaserad enterprise-arkitektur.
Vi har saknat ett gemensamt språk och en gemensam plattform mellan verksamhet och it för att bygga tjänster som verkligen kan bli verksamhetens gemensamma tillgångar. Således har EA-samhället misslyckats, och det på det som borde vara hemmaplan, att få it och verksamhet att lira ihop.
Vi tror att det komponentsynsätt på verksamhet som nu växer fram är den saknade länken som kan få SOA att leverera. Vi motiverar det i det följande.
Lösning: Förankra tjänsterna i verksamhetens förmågor
En SOA-tjänst behöver förankring i en verksamhet, den är alltid en implementation av en verksamhetstjänst eller en del av en verksamhetstjänst. Med verksamhetstjänst menar vi något som en verksamhetsfunktion erbjuder andra verksamhetsfunktioner, interna eller externa till organisationen.
En tjänst har alltid en producent och ett antal konsumenter. Kedjan producent-tjänst-konsument manifesterar sig samtidigt på flera nivåer i en stack. På låg nivå är det ett it-system som använder en tjänst hos ett annat it-system. På hög nivå är det en verksamhetsfunktion som använder en tjänst som en annan erbjuder. Om ett it-system skickar information till ett annat betyder det att något händer i verksamheten. Det kanske är Produktion som meddelar Logistik om att ett ordernummer är klart att skeppa.
Vi har sett att det är naturligt för människor att betrakta och hantera sitt område som en avgränsad funktion med ett visst ansvar och att det är naturligt att se det som att man har interna och externa kunder man erbjuder tjänster. Tjänster existerar inte i vakuum. En tjänst är något som en part erbjuder andra parter.
För att tänka och tala om tjänster behöver vi tänka och tala om subjekten, det vill säga de parter som är producenter och konsumenter av respektive tjänst. Inom verksamheten är det de naturliga funktionerna, Business Capabilities, som är producenter och konsumenter. Därmed har vi fått ett synsätt på verksamhet som i grunden är tjänstebaserad. Den består av avgränsade funktioner som samverkar genom tjänster.
Om verksamhetsarkitekter verkligen börjar anamma komponentperspektivet och börjar stötta it-sidan i arkitekturarbetet kanske SOA sent omsider kan leverera vad som så länge lovats.
Vad är då trenden? Det är vanligt att bygga tjänster, men vi har inte sett att det bli något annat än en teknisk design och således inget som får it och verksamhet att spela i samma match. Vi tror fortfarande fullt och fast på SOA, men bara om vi får till en helt annan förankring av SOA-satsningarna i verksamheten än den vi sett hittills.
Problem 2: Avstånd mellan it-sidan och verksamheten
Vi lever i en tid då många säger att it-sidan inte ska vara en leverantör till verksamheten utan en integrerad partner. Ambitionen finns säkert där men det är än så länge tomma ord. Ofta undrar vi om man verkligen har förstått vad integration innebär. Det innebär ju faktiskt att ens ursprungliga identitet och tillhörighet upplöses mer eller mindre och man får en ny hemvist. Det innebär att du faktiskt måste ta din stol och gå över till andra sidan.
Är du it-utvecklare som jobbar med kreditsystem måste du börja se dig som utvecklare av kreditverksamheten och sitta med och jobba med kreditanalytikerna och de som utvecklar kreditmodeller och kredithanteringen!
Sköter du Data Warehouse-supporten måste du börja se dig som en del av verksamheten, nämligen en expert på verksamhetens information, hur man kommer åt den, vad den betyder, vad man kan göra med den och hur man ställer de frågor mot informationen man behöver ställa och tolka de svar man får. Du är helt enkelt en verksamhetsexpert och bör sitta med dina kollegor på andra sidan, de marknads-, risk-, och finansanalytiker som du behöver samverka nära med. Det kan till och med bli så att du får lämna Foppa-tofflorna hemma och ta på en kavaj!
Vi ser dagligen hur organisationer hämmas i sin funktion och utveckling genom att vi fortfarande drar en gräns tvärs igenom funktioner som vi inte borde dra och kalla den ena delen för it och den andra för verksamhet.
För oss är drömmen och målet att lösa upp it-avdelningen och flytta över allt it-folk dit de hör hemma, ihop med dem de behöver jobba tätt ihop med. Men då måste vi ju också säga vilka som ska sitta hos vilka?
Lösning: Samgruppera it och verksamhet baserat på förmåga
De autonoma verksamhetsförmågorna vi har beskrivit är de naturliga enheterna, de som behöver dela kompetens, it-system, intern information, tjänster, kunder med mera. Där har vi förstås svaret. Det är de vi bör gruppera runt, och inte som nu separerat på ”it” och ”verksamhet”, där allt som klassas som ”it” också fösts ihop i en flock .
Men en sådan förändring kräver att vi förmår släppa det nedärvda axiomet som säger att it-arbete är att vara underleverantör till verksamheten.
Vad är då trenden? Är det här något som händer i dag eller i närtid eller är det en orealistisk dröm?
Det vi har sett är snarare en mottrend att man från 90-talet och framåt, inom managementkretsar, starkt har betonat synen att it-sidan är en leverantör. Det är svårt att överdriva hur mycket övertro på outsorcing av it har skadat våra myndigheter och företag de senaste 20 åren.
På senare år har vi börjat se en svängning. Fler och fler börjar äntligen tvivla på att it är en nyttighet man kan köpa på kran. En del it-avdelningar har organiserat om sig från resurspooler baserade på teknik till mindre team baserade på vilken del av verksamheten man stödjer.
Vi har också sett specifika områden där man vill gå mot att samgruppera it och verksamhet. Exempel är Data Warehouse-området där man de senaste åren har byggt upp Business Intelligence Competence Centers, BICC, på en del håll. Så nog finns det en trend mot att it-sidan närmar sig verksamheten baserat på vilken verksamhetsfunktion man stödjer. Det är dock en rännil. Ge oss en kraftfull ström!
Två sidor av samma mynt?
Kanske kan man se problem ett och två ovan som två sidor av samma mynt. De handlar båda om it-sidans tendens att se sig som leverantör och därmed dess oförmåga att jacka in i verksamheten på rätt plats, det vill säga i alla de enskilda funktioner verksamheten består av - vare sig det gäller systemportföljen (problem 1) eller det dagliga arbetet (problem 2).
Och lösningen är densamma: Vi behöver finna verksamhetens naturliga delar och se till att punktmarkera dem.
Och en sak till: Denna gång kommer vi inte undan med powerpoint-bilder som det står ”Business-IT Alignment” på, utan det krävs daglig och handfast gärning på plats i verksamhetens vardag.
Det här var sista delen av vår spaning om Business Capabilities. Vi är tacksamma för den dialog vi har fått med läsarna runt detta utvecklingsspår inom verksamhetsarkitekturområdet. Vi hoppas på fler kommentarer.
Håller du med om att it-sidan bör sträva mot att bli en integrerad del av verksamheten? Vad gör it-folket i din organisation för att komma dit? Tror du att det kan hjälpa att samarbeta nära runt enskilda funktioner? Bygger ni SOA idag? Hur ser ni till att SOA-tjänsterna uppfattas som en gemensam resurs och verkligen hanteras som en sådan?
Robert Elm och Peter Tallungs, IRM
2011-09-28