Teknik och Samhälle Datavetenskap
Examensarbete
15 högskolepoäng, grundnivå
Att implementera Service Oriented
Architecture kostnadseffektivt
Utvärdering av systemarkitektur vid systemskifte
To implement Service Oriented
Architecture cost-effective
Evaluation of system architecture associated with system transition
Filip Larsson
Kandidatexamen 180 hp Handledare: Kristian Ekberg Datavetenskap Examinator: Annabella Loconsole Affärssystem
Resumé
I enighet med teknikutvecklingen förändras även förutsättningarna för kostnadseffektiva IT-miljöer. Systemarkitekturen för mjukvarusystem förändras i samband med detta och verksamhetens systemdesign måste följa denna utveckling för att vara konkurrenskraftig på IT-marknaden.
Implementeringar av Service Oriented Architecture, förkortat SOA, har i många fall visat sig vara lönsamma investeringar till en modernare arkitektur. Denna rapport förklarar på vilka sätt SOA kan vara kostnadseffektivt för verksamheter, samt identifierar kritiska framgångsfaktorer som är avgörande vid systemskiften till SOA.
I kombination av en teoretisk litteraturstudie, analys av publicerade företagsfall och empirisk undersökning visar sig SOA-baserade lösningar vara kostnadseffektiva genom sänkta kostnader, tidsbesparingar och snabbare produktutveckling. Studien identifierar huvudsakligen fem kritiska framgångsfaktorer som är direkt kopplade till hur pass kostnadseffektiv en implementering av SOA kan komma att bli.
Nyckelord: Service Oriented Architecture, SOA, Implementering,
Kostnadseffektivitet, Kritiska framgångsfaktorer, Systemarkitektur, Enterprise Architecture
Abstract
In unity with the technological evolution the conditions for cost-effective IT environments also changes. In this context, the architecture of software systems is changing and the business system design has to follow this development in order to be competitive on the IT market.
Implementations of Service Oriented Architecture, abbreviated as SOA, have in many cases proven to be profitable investments to a modern architecture. This thesis explains in which ways SOA may turn out to be cost-effective for companies, and identifies critical success factors that are crucial within a system transition to SOA.
The combination of a theoretical literature study, analysis of published business cases and empirical studies provided a result in which SOA-based solutions was cost-effective by reduced costs, time savings and faster product development. The study identifies five main critical success factors which are directly related to how cost-effective an implementation of SOA may be.
Keywords: Service Oriented Architecture, SOA, Implementation, Cost-effectiveness, Critical success factors, System architecture, Enterprise Architecture
Innehållsförteckning
1 Inledning ... 1 1.1 Bakgrund... 1 1.2 Problemformulering ... 2 1.2.1 Frågeställning ... 3 1.2.2 Syfte ... 3 1.3 Målgrupp ... 3 1.4 Avgränsning ... 3 2 Teoretisk ram ... 5 2.1 Systemarkitektur ... 5 2.1.1 Bakgrund ... 5 2.1.2 Definition ... 6 2.1.3 Arkitektoniska nivåer ... 72.2 Service Oriented Architecture (SOA) ... 8
2.2.1 Bakgrund ... 8
2.2.2 Definition ... 9
2.2.3 Tekniker inom SOA ... 10
2.3 Implementering ... 11 2.4 Ekonomiska begrepp ... 11 2.4.1 Kostnadseffektivitet ... 12 2.4.2 Avkastning på investering ... 12 2.4.3 Nettonuvärde ... 12 2.5 Kritiska framgångsfaktorer ... 13 3 Metod ... 14 3.1 Ansats ... 14 3.2 Kvalitativ metod ... 15 3.3 Tillvägagångssätt ... 15
3.3.1 Analys av publicerade företagsfall ... 16
3.3.2 Empirisk undersökning ... 16
4 Resultat ... 19 4.1 Företagsfall ... 19 4.1.1 British Telecom ... 19 4.1.2 Cerdo Bankpartner ... 20 4.1.3 Fritidsresor ... 20 4.1.4 Nordea ... 21 4.1.5 SBAB ... 21 4.1.6 Starwood Hotels ... 22 4.1.7 Sammanfattning ... 22 4.2 Empirisk undersökning ... 23 4.2.1 Cerdo Bankpartner ... 24 4.2.2 Nordea ... 25 4.2.3 Sammanfattning ... 26 5 Analys ... 27
5.1 Hur SOA kan vara kostnadseffektivt ... 28
5.2 Fem kritiska framgångsfaktorer ... 30
6 Diskussion ... 34
6.1 Att tänka på före implementering av SOA ... 35
6.2 Förslag till vidare forskning ... 35
Referenser ... 37
Tryckta referenser ... 37
Elektroniska referenser ... 38
Bilaga 1 – Formulär till empirisk undersökning ... 40
Bilaga 2 – Enkätsvar från Per Skenhall, Cerdo Bankpartner ... 41
1 Inledning
Inledningen går igenom bakgrunden till ämnet, beskriver ett problem och utformar en frågeställning för studien. Kapitlet redogör även för syftet med studien, rapportens målgrupp samt vilka avgränsningar som gjorts i detta arbete.
Infrastruktur för IT-system förändras hela tiden i och med att teknikutvecklingen går framåt. Tekniska lösningar präglas idag av optimerade verksamhetsprocesser och effektivisering genom exempelvis återanvändning av funktioner, standardiserade webbapplikationer och molnbaserade tjänster (Olson & Kesharwani, 2010; Rainer & Turban, 2009). Gärna ska system även vara kompatibla och användbara för flera plattformar, inte minst mobila enheter.
Oavsett om det är ett projekt eller en process, ett litet informationssystem eller ett stort affärssystem, följer utvecklingen denna trend. Samtidigt blir distribuerade informationssystem allt mer komplexa. Systemkomponenter har flyttats ut, från att vara inbyggda i systemets kärna, till externa, ofta Internetbaserade, tjänster (Josuttis, 2007).
Bass, Clements och Kazman (2003) förklarar att förutsättningarna för en lönsam systemarkitektur förändras i samband med IT-marknadens utveckling. Ny teknik möjliggör att aktörer på marknaden går över till nyare lösningar som ger avgörande konkurrensfördelar. Inom en del marknadssegment handlar systemskiften om verksamhetens existentiella överlevnad och konkurrenskraftighet.
1.1 Bakgrund
För att följa med i teknikutvecklingen krävs flexibilitet och anpassning till IT-marknadens förändrade förutsättningar (Josuttis, 2007). Systemarkitekturen måste ständigt underhållas och ibland krävs förändringar inom verksamhetens infrastruktur. Förändringar kan vara av så pass stor vikt att ett helt systemskifte kan vara relevant för att hålla verksamheten och dess IT-system konkurrenskraftiga (Bass, Clements & Kazman, 2003).
Service Oriented Architecture, härefter förkortat SOA, är en systemarkitektur som blivit populär de senaste åren. SOA är ibland översatt till svenskans tjänsteorienterad arkitektur, men begreppet SOA används i denna rapport då det är vanligast förekommande. Även om SOA inte är något helt nytt fenomen, ökar stadigt antalet företag som gör systemskiften till SOA. Företag som genomför implementeringar av SOA är både stora och små, samt inom olika branscher. Bland de främsta finns bolag inom telekom, finans och försäkring (Wallström, 2011; Heffner, 2011).
Kavis (2009) menar att implementering av SOA inte bara handlar om teknisk evolution. Kavis är även av uppfattningen att SOA bör ses som ett nytt sätt att tänka kring verksamhetens informationsteknik.
Att implementera en ny systemarkitektur är ett stort steg och därför är det viktigt att ta reda på vilka fördelar man kan utvinna med arkitekturen (Olson & Kesharwani, 2010).
Begreppen systemarkitektur, SOA och implementering redogörs för i den teoretiska ramen i nästkommande kapitel.
1.2 Problemformulering
Som tidigare diskuterats är det viktigt att verksamhetens infrastruktur är konkurrenskraftig i jämförelse med andra aktörer på IT-marknaden. Med tiden förändras förutsättningarna för kostnadseffektiva IT-miljöer och då kan en implementering av en modernare arkitektur vara aktuell.
Fler och fler har under de senaste åren genomfört systemskiften till SOA och många har upplevt stora fördelar med en tjänsteorienterad arkitektur (Wallström, 2011; Heffner, 2011). Att många företag dragit fördel av SOA leder in på frågan på vilket sätt man upplevt SOA fördelaktigt. Eskil Swende, SOA-specialist, menar att en SOA-baserad arkitektur sänker företags IT-kostnader (Berg, 2008). Det som återstår att utreda är på vilka sätt SOA kan vara kostnadseffektivt för verksamheter. Vad är det som gör att SOA är ett alternativ värt att satsa på i ett ständigt föränderligt IT-samhälle?
En annan fråga i samband med detta är vad man bör tänka på inför ett eventuellt systemskifte. Är det lämpligt för alla verksamheter, eller skiljer det sig exempelvis mellan organisationens verksamhetsområde eller investeringsmöjligheter? För att belysa dessa frågor kan det vara intressant att utreda de viktigaste faktorerna i samband med en implementering, för lyckat resultat. Olson och Kesharwani (2010) menar att implementering av informationssystem är förknippat med stora risker. Därför kan det vara relevant att söka kritiska framgångsfaktorer för implementering av SOA.
1.2.1 Frågeställning
Utifrån given problemformulering ämnar denna studie att besvara följande frågor:
På vilka sätt kan SOA vara kostnadseffektivt för verksamheter? Vilka kritiska framgångsfaktorer kan identifieras i samband med en
implementering av SOA?
1.2.2 Syfte
Syftet med undersökningen är att göra en utvärdering av på vilka sätt en implementering av SOA kan vara kostnadseffektivt. Studien ämnar undersöka vilka kritiska framgångsfaktorer som finns vid en implementering av SOA.
1.3 Målgrupp
Denna studie vänder sig till personer som intresserar sig för systemarkitektur och i synnerhet SOA. Studien är särskilt intressant för de som överväger ett systemskifte till en SOA-baserad lösning.
Rapportens målgrupp är sedermera personer med beslutsfattande i olika sorts verksamheters mjukvarusystem. Rapporten har en stark förankring i ett branschmässigt perspektiv, vilken gör att den kan användas som underlag inför en implementering.
1.4 Avgränsning
Denna studie fokuserar på implementeringsfasen av SOA, vilket medför att rapporten ej innefattar uppföljning av systemdesignen. Undersökningen utreder hur SOA kan vara kostnadseffektivt.
Denna synvinkel utelämnar andra viktiga aspekter som bör beaktas vid val av systemdesign så som användbarhet, prestanda, krav och säkerhet. Dessa
aspekter är dock inkluderade i de fall faktorerna påverkar produktivitet, effektivitet eller andra nyckelfaktorer som påverkar kostnadseffektiviteten. En annan avgränsning i undersökningen är att endast titta på systemskiften till systemarkitekturen SOA, då denna de senaste åren haft en stark tillväxt bland företag på IT-marknaden (Wallström, 2011; Heffner, 2011). Denna avgränsning gör att studien kan gå djupare och hitta de faktorer som är kopplade till problemområdet.
Många andra intressanta undersökningar kan göras med andra avgränsningar. Under avsnitt 6.2 finns förslag till vidare forskning.
2 Teoretisk ram
Den teoretiska ramen går igenom de teorier som används för att göra undersökningen. Studiens forskningsområde gör att dessa teorier huvudsakligen har sin grund inom det datavetenskapliga ämnet.
För att få en inblick i både begrepp och situation följer här en redogörelse av de teorier som är genomgående i hela rapporten. De datavetenskapliga begrepp som redogörs för är systemarkitektur, Service Oriented Architecture (SOA) och implementering.
Sedan följer redogörelser av de ekonomiska begrepp som används i undersökningen och kritiska framgångsfaktorer. Detta görs för att vara tydlig med vad begreppen innebär.
Detta kapitel kan ses som kunskapsbildande läsning inför kommande kapitel, samt ligger till grund för undersökningen.
2.1 Systemarkitektur
För att kunna göra en bra systemdesign är det viktigt att vara medveten om vilka olika komponenter som ingår i systemet och hur relationen mellan dem fungerar (Bass, Clements & Kazman, 2003).
En systemarkitektur är nödvändig då den förklarar dessa saker. Är systemarkitekturen välgjord kan processer effektiviseras och standarder underlätta för utveckling (Bass, Clements & Kazman, 2003).
2.1.1 Bakgrund
Systemarkitektur har sin bakgrund ur olika affärsmässiga och tekniska beslut. Många olika faktorer spelar in hur arkitekturen kan komma att se ut, men det är tydligt att arkitekturer skiljer sig från hur de skulle ha designats för bara några år sedan (Bass, Clements & Kazman, 2003).
Redan på 1960-talet var utvecklare överens om att en välgjord systemarkitektur förenklade utvecklingen av informationssystem (Garlan &
Shaw, 1994). De senaste decennierna har utvecklingen av både befintliga och nya system utvärderats noggrannare än vad det tidigare gjorts. Från att utvecklare enbart jobbat med en detaljerad kravspecifikation, blev det även intressant att se hur helheten ser ut (Bass, Clements & Kazman, 2003).
1995 kom exempelvis första versionen av TOGAF, som är ett ramverk och en standard för att tillämpa systemarkitektur (The Open Group, 2011). De senaste åren har SOA varit en stor trend inom systemarkitekturen (Wallström, 2011; Heffner, 2011).
Idag ses systemarkitektur som en av de avgörande beståndsdelarna inom datavetenskapen (Bass, Clements & Kazman, 2003).
2.1.2 Definition
Det finns, precis som med andra datavetenskapliga begrepp, många olika definitioner på vad systemarkitektur innebär. Detta avsnitt presenterar de vanligaste definitionerna på vad systemarkitektur innebär.
Bass, Clements och Kazman (2003) menar att systemarkitektur är en beskrivning av hur infrastrukturen ser ut för verksamhetens IT-system. Författarna menar vidare att arkitekturen är en del av designprocessen, ofta före implementering av ett nytt system eller vid systemskifte. Systemarkitekturen definierar strukturen av stora mjukvarusystem (Bass, Clements & Kazman, 2003).
IT-konsortiumet The Open Group definierar systemarkitektur i TOGAF, The Open Group Architecture Framework, såhär:
”The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.” (The Open Group, 2011)
En arkitektonisk design beskriver vilka systemkomponenter som ska användas i systemarkitekturen. Systemdesignen redogör även för hur systemkomponenterna ska samspela och användas på ett effektivt sätt (The Open Group, 2011). Systemarkitektur benämns alltså som ett begrepp som definierar ett systems övergripande struktur.
I samband med systemarkitektur skapas ofta ett dokument som kallas Software Architecture Document, SAD, där olika systemkomponenter beskrivs och relationerna mellan dem (Maréchaux, 2005). SAD ses som en artefakt, något som ger värde, inför en implementering eller systemskifte. SAD har sitt urprung ur systemutvecklingsmodellen RUP, Rational Unified Process (Kruchten, 2002).
Det finns olika sorter av systemarkitekturer. Bland de vanligaste hör client/server-arkitektur, lagerarkitektur och SOA. En client/server-arkitektur är uppsatt på så sätt att samverkan sker mellan den förfrågande klienten och den svarande servern. Dessa systemkomponenter kommunicerar genom olika protokoll. Client/server-arkitektur är användbart då systemet kräver modularitet och fysisk distribution (Bass, Clements & Kazman, 2003).
Lagerarkitektur (eng. tier architecture) är en systemarkitektur där systemkomponenterna separeras i olika skikt. Bland de vanligaste varianterna av modellen hör trelagersarkitekturen, där användargränssnitt, applikation och data skiljs (James, 2009).
2.1.3 Arkitektoniska nivåer
Ibland nämns systemarkitektur på olika nivåer. FEA Practice Guidance (2007) identifierar tre olika skikt av systemarkitektur (eng. architectural levels) som skiljer sig i abstraktionsnivå och ses ur olika affärsmässiga perpektiv. Dessa är Enterprise Architecture, Segment Architecture och Solution Architecture. En översikt över de tre skikten presenteras nedan i Figur 1.
Figur 1 – Arkitektoniska nivåer (Översatt figur av FEA Practice Guidance 2007, s. 5)
Enterprise Architecture är det skikt med lägst teknisk detaljrikedom, som fokuserar på verksamhetens strategier gällande IT-system. Detta perspektiv tar distans ifrån tekniska detaljer, utan målet med Enterprise Architecture är att verksamhetens IT uppfyller verksamhetens funktion och fungerar effektivt. Att företaget drivs mot de övergripande målen är en central del av Enterprise Architecture (FEA Practice Guidance, 2007).
Solution Architecture är beskrivningen av den systemdesign som sker i samråd med utvecklare och gäller mer operationella beslut. I detta skikt handlar det om att utvecklare ska tillgodose användarnas behov av det aktuella systemet. I Solution Architecture ser man snarare systemarkitekturen som komponenter och applikationer (FEA Practice Guidance, 2007).
Segment Architecture kan ses som ett mellanskikt som är en viktig länk mellan teknik, ledningsbeslut, utvecklare och intressenter. I Segment Architecture handlar det om att omvandla övergripande mål och strategier till en systemdesign med ursprung ur affärsmässiga beslut. I detta skikt tas även beslut om hur affärsprocesser ska gå till (FEA Practice Guidance, 2007).
Denna rapport kommer att fokusera på den översta nivån av systemarkitektur, Enterprise Architecture. På denna nivå tas de affärsmässiga beslut som är kopplade till investering, implementering och strategi, vilket är inom problemområdet för denna studie.
2.2 Service Oriented Architecture (SOA)
Service Oriented Architecture, härefter förkortat SOA, har under de senaste åren varit en genomgående trend i IT-branschen, där många företag sett fördelar med en SOA-baserad lösning (Wallström, 2011; Heffner, 2011).
Detta avsnitt kommer att presentera bakgrunden till SOA, en redogörelse för vad SOA egentligen betyder och innefattar, samt en beskrivning av vilka tekniker som är vanliga i en SOA-baserad lösning.
2.2.1 Bakgrund
Begreppet SOA sägs ha myntats av analytikern Alexander Pasik redan 1994, då han menade att begreppet client/server hade felanvänts som distribuerade system istället för den tjänst det är. Istället för att ha två definitioner för client/server uppmanade Pasik folk att använda begreppet SOA Business Applications, innan det enbart blev SOA (Josuttis, 2007).
Josuttis (2007) förklarar vidare att begreppet SOA ökat i samband med att användandet av webbtjänster ökat. Många gör misstaget att blanda ihop webbtjänster och SOA, vilket är felaktigt. I början på 2000-talet identifierades SOA som ett nyckelkoncept för framtidens systemutveckling (Josuttis, 2007). Olika standarder av SOA har förekommit i samband med ökad användning. Dessa standarder och specifikationer syftar till att underlätta för utvecklingen
av baserade lösningar. TOGAF presenterar exempelvis tre olika SOA-standarder; SOA Source Book, OSIMM och SGVM (The Open Group, 2011). Kreger och Brunssen (2012) menar att användningen av SOA-standarder effektiviserar systemarkitekturen och underlättar för integration. Dessa standarder bör ses som riktlinjer i samband med att man implementerar SOA. Företag som implementerat SOA har tidigare haft olika sorts system som behövt ersättas, på grund av olika anledningar. Med tanke på olikheterna för varje specifikt företagsfall skiljer sig även de SOA-baserade lösningarna. Det är ofta inte heller den tidigare systemarkitekturen som är drivkraften till att verksamheter funderar på systemskiften, utan snarare förändringar inom marknadssegmentet (Van Den Berg, Bieberstein & Van Ommeren, 2007; Wallström, 2011). Att nya digitala marknader uppstår är ett exempel på detta, vilket beskrivs närmre i företagsfallen, kapitel 4 av rapporten.
2.2.2 Definition
Även SOA har många olika definitioner och tolkningar.
Som tidigare nämnts hänger begreppet SOA samman med att nya tekniker utvecklats från det klassiska client/server. Josuttis (2007) menar att SOA i sig inte är en konkret arkitektur, utan snarare en tjänstebaserad arkitekturstil. The Open Group (2011) delar denna uppfattning och förklarar vidare att systemdesignen utgörs av tjänster som samverkar till en enhetlig lösning. Josuttis (2007) menar dock att SOA leder till en konkret arkitektur. Josuttis förklarar vidare att SOA inte är något fysiskt verktyg eller ramverk man kan köpa, utan snarare ett förhållningssätt och ett sätt att tänka.
Olson och Kesharwani (2010) förklarar SOA som en systemdesign där applikationer samverkar med en eller flera tjänster som tillhandahåller funktionalitet. Författarna upplever SOA som en flexibel arkitektur i och med återanvändandet av tjänster.
En SOA-präglad systemarkitektur är ofta designad på så sätt att samma funktioner återanvänds om och om igen. Denna sorts lösning gör SOA modulär som arkitektur. Att endast ett fåtal tjänster eller program används till att utföra samma jobb främjar även en modulär utveckling ifall ytterligare applikationer tillkommer i framtiden. (Van Den Berg, Bieberstein & Van Ommeren, 2007).
Andersson (2010) menar vidare att SOA-baserade lösningar förenklar ärendehantering och förbättrar affärsprocesser:
”SOA är klistret mellan verksamheten och IT-systemen, som gör det möjligt att optimera affärsprocesserna.” (Andersson, 2010)
Trots att det finns många olika definitioner av begreppet SOA, så är de allra flesta överrens om att SOA, precis som namnet förkunnar, är en systemarkitektur där tjänsteorienteringen ligger i fokus. Så är även uppfattningen i denna rapport. SOA är tillika starkt förknippat med webbtjänster och teknik som främjar integration och återanvändning.
2.2.3 Tekniker inom SOA
Det som karaktäriserar SOA är som tidigare nämnts den tjänstebaserade systemdesignen. SOA fokuserar på användning av externa tjänster med gränssnitt som tillåter tillgänglighet på ett flertal plattformar. Ofta är dessa tjänster Internetbaserade, det vill säga webbtjänster (Van Den Berg, Bieberstein & Van Ommeren, 2007).
Webbtjänster tillhandahåller funktionalitet över Internet genom ett gränssnitt baserat på HTTP-protokoll och XML-format (Josuttis, 2007). SOAP och WSDL är vanliga tekniker som är SOA-kompatibla, vilket innebär att de möjliggör en tjänstebaserad lösning (Li, 2010). Dessa tekniker möjliggör att data från webbtjänsten lätt kan göras åtkomlig (Josuttis, 2007). Detta är bara de vanligaste exemplen på olika protokoll och standarder som används inom webbtjänster och SOA.
Det är dock inte bara användandet av webbtjänster och dess tillhörande teknik som ligger inom ramen för SOA. SOA-baserade lösningar kan se väldigt olika ut beroende på vad de ska användas till.
Om det finns ett stort behov av integration mellan olika system kan en integrationsplattform vara att föredra, som sköter kontakten mellan system genom olika gränssnitt. En integrationsplattform fungerar som ett mellanlager (eng. middleware), som hanterar olika gränssnitt och protokoll (Li, 2010). Ett annat vanligt begrepp inom SOA-arkitekturen är Enterprise Service Bus, ESB. En ESB fungerar som en medlare mellan den anropande klienten och den svarande tjänsteservern. Denna lösning sköter de olikheter som identifieras mellan de olika protokollen och formaten, för att tjänsten som helhet ska fungera flexibelt och effektivt (Li, 2010).
Van Den Berg, Bieberstein och Van Ommeren (2007) anser att användning av en ESB kan vara fördelaktig då man har olikheter i de komponenter som ingår i systemarkitekturen. Två vanliga produktexempel på integrationsplattform och ESB är TIBCO och BizTalk (Emmerich, Aoyama & Sventek, 2007).
2.3 Implementering
För att tjänsteorientera systemarkitekturen behöver en implementering av den nya arkitekturen göras. Med begreppet implementering menas den process där ett införande av ett nytt system sker från ett gammalt (Rainer & Turban, 2009). Ett sådant systemskifte är en komplex operation och tar ofta lång tid, till höga kostnader (Olson & Kesharwani, 2010).
En implementering av ett nytt system eller en ny arkitektur är även förknippad med stora risker. Viktigt att tänka på vid en implementering är bland annat att förstå behovet av en implementering, förändra organisationens kultur kring sin IT, samt välja en passande implementeringsmetod (Olson & Kesharwani, 2010).
Magnusson och Olsson (2008) presenterar fyra olika införandestrategier vid systemskiften. Big bang är den vanligaste använda implementeringsmetoden och går ut på att ett helt nytt system införs på en och samma gång. Mini big bang är, precis som det låter, en mildare version av Big bang. Fasad per modul innebär att endast en modul av den nya lösningen införs i taget. Fasad per site är den sista införandestrategin där implementeringen sker i flera faser utifrån geografiska positioner i verksamheter.
2.4 Ekonomiska begrepp
Detta avsnitt presenterar de ekonomiska begrepp som används i studien. Alla dessa begrepp är relaterade till investeringar.
I samband med utformningen av undersökningen har olika ekonomiska faktorer värderats, och valts ut. Dessa faktorer förklaras i Tabell 1 nedan.
Ekonomisk faktor Beskrivning
Avkastning på
investering Kvot utifrån framtida inkomster i relation med investeringskostnad
Effektivitet Resultat av produktivitet – hur väl och precist resurser förbrukas
Kostnadseffektivitet Resultat i form av kostnadsbesparingar
Lönsamhet Samlingsbegrepp som innefattar hela verksamheten resultat utifrån resultatinsatsen
Nettonuvärde Begrepp där framtida inkomster beräknas till ett nuvärde
Payback/
återbetalningsperiod
Tid det tar att tjäna igen investeringskostnaden
Tabell 1 – Ekonomiska faktorer vid urval (Begrepp från Oxford University Press 2012)
Av dessa faktorer används kostnadseffektivitet, avkastning på investering och nettonuvärde i undersökningen. Tidigt i studieprocessen togs beslutet att utreda vilka kostnadseffektiva faktorer SOA kan resultera i. Det var också dem företagsfallen påvisade. Avkastning på investering och nettonuvärde används i den empiriska undersökningen, för att se hur resultatet sett ut för företagen. Anledningen till varför studien väljer bort exempelvis lönsamhet som ekonomisk faktor, beror på att lönsamhet innefattar otillgänglig ekonomisk data. Begreppet lönsamhet tar även hänsyn till bland annat prestanda och yttre krav. Effektivitet fokuserar mer på hur produktiv en lösning är, vilket inte riktigt svarar mot studiens problemställning. Återbetalningsperioden valdes bort då avkastning på investering är en närliggande faktor.
2.4.1 Kostnadseffektivitet
Kostnadseffektivitet är ett begrepp som definierar resultatet av investerade ekonomiska resurser (NE, 2012). Det som investeringen har resulterat i är alltså det som ställs mot implementeringskostnaden (Phillips & Thompson, 2009).
Kostnadseffektivitet kan mätas genom att titta på hur pass stora kostnadsbesparingar en förändring genererat. I denna studie är förändringen ett systemskifte, där resultatet sätts i relation till investeringskostnaden. Kostnadseffektivitet mäts inte bara genom kostnadsbesparingar, utan kan även mätas i form av effektivisering av processer eller tidsbesparingar etc (Phillips & Thompson, 2009).
2.4.2 Avkastning på investering
Avkastningen för en investering (eng. return on investment eller ROI) är ett ekonomiskt mätinstrument som sätter investeringskostnaden i relation till framtida inkomster. Resultatet blir en kvot som alltså mäter förhållandet mellan satsat kapital och den tid det tar för investeringen att tjäna igen sig (Bergstrand, 2003).
2.4.3 Nettonuvärde
Nettonuvärdet (eng. net present value eller NPV) är ett annat mätinstrument där framtida inkomster som är direkt kopplade till investeringen värderas.
Detta värde flyttas sedan tillbaka i tiden till ett nuvärde som diskonteras av den aktuella kostnaden för investeringen. Resultatet av nettonuvärdet värderas tillsammans med andra investeringskalkyler för att se ifall en investering är lönsam (Rainer & Turban, 2009).
2.5 Kritiska framgångsfaktorer
Kritiska framgångsfaktorer är faktorer som anses vara kritiska för att ett projekt eller en investering ska vara genomförbar och lyckad. Uppfylls inte sådana faktorer, exempelvis vid en implementering, kan antingen förändringen misslyckas helt eller inte generera det önskade resultatet (Zabjek, Kovacic & Stemberger Indihar, 2009).
Denna rapport ämnar söka kritiska framgångsfaktorer för en implementering av SOA. Med andra ord betyder det att sådana faktorer är de viktigaste och mest elementära sakerna som bör beaktas inför ett eventuellt systemskifte.
3 Metod
Metodkapitlet går först igenom vilken synvinkel undersökningen genomförs utifrån och vilken forskningsmetod som används. Efter det följer det praktiska tillvägagångssätt som faktiskt använts för att göra undersökningen. Kapitlet innehåller även en metodkritik för undersökningen, med motiveringar om varför och hur saker har gjorts.
Undersökningen till denna rapport har en relativt stor branschstämpel. Empiriska resultat, från företag i näringslivet som gjort implementeringar av SOA, ligger till grund för analysen, vilket gör undersökningen mer praktisk. Problemområdet för studien undersöker på vilka sätt SOA kan vara kostnadseffektivt, vilket medför att detta branschperspektiv innehåller releventa data.
En sammanställning av flertalet publicerade företagsfall utgör en del av undersökningen. Studien innefattar även en empirisk enkätundersökning, där frågor av mer utredande karaktär läggs fram.
Den empiriska datan vägs samman med teori från artiklar och tidskrifter, och utifrån detta hittas samband som resulterar i på vilka sätt SOA kan vara kostnadseffektivt, samt vilka framgångsfaktorer som finns vid en implementering.
3.1 Ansats
Denna rapport har sin grund i en induktiv ansats. I den induktiva ansatsen är det empirin som är utgångspunkten till undersökningen (Eriksson & Wiedersheim-Paul, 2006). Karaktären av problemområdet gör att en induktiv ansats lämpar sig då en implementering av SOA har ett praktiskt utförande. Det görs även en teoretisk litteraturstudie av forskning inom ämnet, men det är empirin som genererar mest information i denna undersökning.
3.2 Kvalitativ metod
Denna rapport bygger till största del på en kvalitativ metod, där resultat från sex olika företagsfall tillsammans med mer djupgående enkätsvar ligger till grund för analysen. En kvalitativ metod utgår ifrån primärdata som exempelvis observationer, fallbeskrivningar och intervjuer (Eriksson & Wiedersheim-Paul, 2006).
3.3 Tillvägagångssätt
För att kunna besvara frågeställningen gjordes först en inledande litteraturstudie av material rörande SOA. Vid detta skede påträffades publicerat material inom ämnet, varefter urval av relevant litteratur gjordes. Därefter skedde en insamling av publicerade företagsfall med verksamheter i näringslivet som gjort implementeringar av SOA. Slutligen gjordes även en empirisk undersökning i form av en enkätundersökning.
Litteraturstudien gav en inblick i hur SOA uppfattas idag och hur företag jobbar med SOA. Undersökningen gav även en översikt hur marknaden ser ut i nuläget, samt vilka tekniker som används och trender som följs.
Forskningsmetoden för att besvara båda två frågorna i frågeställningen är en kombinationen av litteraturstudie, företagsfall och empirisk undersökning. Dock har dessa metoder haft olika tyngd i de olika frågorna. Figur 2 nedan illustrerar vilka metoder som haft störst inverkan på varje forskningsfråga.
Figur 2 – Forskningsmetoder
Material från företagsfallen utgör en stor del i resultatet för på vilka sätt SOA kan vara kostnadseffektivt. För forskningsfrågan om kritiska framgångsfaktorer har en mer djupgående analys krävts. Den empiriska undersökningen belyste mer utredande hur och för vem SOA kan vara en lönsam investering, samt vad man bör beakta inför ett systemskifte.
3.3.1 Analys av publicerade företagsfall
Efter en inledande litteraturstudie över SOA-relaterat material, letades olika företagsfall upp. Fallen hade alla likheterna att företag haft ett behov av ändringar i sina IT-system.
Kriterier för att räknas med i undersökningen var att verksamheten genomfört en implementering av SOA, samt att ett år gått sedan systemskiftet. Anledningen till detta kriterium var att företagen skulle hunnit skaffa sig uppfattningar om hur pass kostnadseffektiva eller inte implementeringarna faktiskt varit.
Data från de publicerade företagsfallen insamlades och en sammanställning gjordes över på vilket sätt SOA varit till fördel för företagen. Anledningen till att endast se till fördelarna med SOA beror på studiens problemformulering, där studien ämnar ta reda på vilket sätt SOA kan vara kostnadseffektivt. I undersökningen fanns ett fåtal fler företagsfall, men de föll bort från urvalet då de inte uppfyllde tidigare nämnda kriterier. Trots att alla företagsfall i denna studie har lyckade utfall, är det viktigt att tänka på att implementeringar av SOA-lösningar inte alltid är rätt. Studier påvisar att ca hälften av alla systemskiften till SOA är misslyckade (Kavis, 2009). Då SOA behöver angripas på rätt sätt för att lyckas, söker denna studie även kritiska framgångsfaktorer vid en implementering.
De olika företagsfallen hittades på olika platser. En del hittades i branschtidningar som Computer Sweden och CIO Sweden, medan andra fanns på tekniksajter på Internet.
Resultatet från företagsfallen presenteras i avsnitt 4.1 av denna rapport.
3.3.2 Empirisk undersökning
Utifrån de företagsfall som analyserats, gjordes även en empirisk undersökning i form av en enkätundersökning med två företag som genomfört implementeringar av SOA.
Enkätundersökningar lämpar sig då man riktar sig till utvalda personer, vilket en utredning av denna karaktär gör (Andersen & Schwencke, 1998).
Frågorna till formuläret togs fram utifrån problemområdet för studien tillsammans med de företagsfall som tidigare analyserats. Frågorna gjordes så pass öppna som möjligt för att låta respondenterna föra fram sina åsikter om SOA, dess fördelar och nackdelar, samt egna upplevelser av företagets
systemskifte. Det föreligger inte klara svarsalternativ på de öppna frågorna, vilket var en anledning till att genomföra enkätundersökningen (Andersen & Schwencke, 1998).
Formuläret med frågorna till enkäten återfinns i sin helhet i Bilaga 1.
Enkätundersökningen genomfördes i form av e-postkorrespondens där frågor ställdes i syfte att besvara aktuellt problemområde för denna studie. Anledningen till att enkätundersökningen skedde via e-post berodde på att respondenterna var placerade i andra städer, men det lämpade sig ändå bra då frågorna var relativt omfattande. Det var även enklare av dokumentationsskäl.
Alla företag vars fall denna studie inkluderar kontaktades, varav två ställde upp på att svara på enkäten. Enkätundersökningen gjordes med Cerdo Bankpartners IT-arkitekt Per Skenhall och Hans-Henrik Eigtved, Head of IT Retail Banking på Nordea.
Det kändes naturligt att genomföra den empiriska undersökningen med dessa personer, då befattningen på deras tjänster vittnar om att de har god insikt i helhetsbilden för systemskiftet. Båda respondenter har även funnits inom verksamheten under en längre tid och har därmed möjlighet att faktiskt förstå konsekvenserna av implementeringen i jämförelse mot den tidigare systemarkitekturen.
Enkätundersökningen gav studien ett större djup, då mer detaljerad information presenterades i respondenternas svar. Enkätsvaren klargör vilka åtgärder företagen faktiskt gjorde i ändringen av systemarkitekturen.
Resultatet från den empiriska undersökningen presenteras i avsnitt 4.2 av denna rapport.
3.4 Metodkritik
Anledningen till att metoden för studien ser ut som den gör är huvudsakligen på grund av ämnet för problemområdet, systemarkitektur och SOA. Rapportens problemformulering har en branschrelaterad utgångspunkt, vilket gör att en enskild teoretisk litteraturstudie inte representerar ett tillförlitligt resultat. Av just denna anledning har rapporten ett induktivt angreppssätt och utgår ifrån empirisk data i form av praktiska företagsfall tillsammans med den tidigare nämnda enkätundersökningen.
Att tillvägagångssättet skett i den ordningen har gett en fördel på så sätt att den kvalitativa enkätundersökningen belyser oklarheter från företagsfallen. Andersen och Schwencke (1998) menar att öppna frågor i
enkätundersökningar gör det möjligt för respondenterna att motivera sina svar, vilket i denna studie är upplevelser och intryck av en implementering. Alternativet till detta tillvägagångssätt skulle kunna vara att arbeta deduktivt, det vill säga att utgå ifrån teorin. Detta perspektiv försvårar dock undersökningen på grund av att studien genomförts i relation till implementering, vilket har ett praktiskt utförande.
4 Resultat
Detta kapitel presenterar de empiriska resultat som tagits fram i undersökningen. Kapitlet inleds med resultatet som företagsfallen uppvisar. Efter det följer resultatet för den empiriska undersökningen.
Implementeringar av SOA-baserade lösningar ökar ständigt och det är företag med verksamhetsområden inom telekom, energi, finans och försäkring som ligger i framkant (Wallström, 2011). Det är ingen tillfällighet att de företagsfall som denna studie iakttar finns inom dessa marknadssegment.
Drivkraften till systemskiften i dessa branscher är ofta förändrade förutsättningar. Exempelvis har banker på senare år förflyttat tjänster från klassiska bankkontor till Internetbanker där kunderna själva utför sina ärenden (Olsson, 2006).
4.1 Företagsfall
Resultatet svarar på insamlingen av de publicerade företagsfall som används i studien. Resultatet för företagsfallen är uppdelat i sex underrubriker, en för varje företagsfall. Avslutningsvis görs även en sammanfattning med jämförelser för företagsfallen.
Det som studien analyserar i företagsfallen är främst på vilka sätt SOA har visat sig vara kostnadseffektivt för varje enskilt fall. Studien analyserar även följande parametrar:
Marknadssegment
Behov av förändring
Teknisk lösning
4.1.1 British Telecom
British Telecom, BT, är en av de största operatörerna i världen inom telekomtjänster. BT är verksamt i över 170 länder och erbjuder som många
andra telekombolag fast och mobil telefoni, TV, olika bredbandstjänster etc (BT Group, 2012).
År 2005 stod BT inför ett generationsskifte, från att enbart tillhandahålla telefontjänster till att erbjuda IT-lösningar, inom både fler verksamhetsområden och fler regioner. Problemet vid denna tid var att företaget inte hade en gemensam avdelning för infrastrukturen, utan varje del av företaget och varje projekt hade sitt eget informationssystem. Detta gjorde att företaget vid denna tid hade 4300 olika projekt, varav endast 20% hade direkt affärssyfte (Rainer & Turban, 2009).
Vid denna tidpunkt beslutade man att neka alla IT-relaterade projekt som inte kunde uppvisa en återbetalningsperiod på ett år. BT gick över till en SOA-baserad arkitektur, som inte bara reducerade antalet system, utan framför allt sänkte de IT-relaterade kostnaderna med ca 20% och ökade kundtillfredsställelsen med uppskattningsvis 15% (Rainer & Turban, 2009).
4.1.2 Cerdo Bankpartner
Cerdo Bankpartner är ett outsourcingföretag inom BPO, Business Process Outsourcing, som jobbar med att sy ihop bankers backofficetjänster, tjänster som inte har en direkt relation med slutkonsumenten. På marknaden ställdes krav på snabbare processer, oberoende av ifall bankkunder uträttade sina bankärenden via bankkontor eller internetbank (CIO Sweden, 2009).
Många av de applikationer som bankernas system använde samverkade inte. För att lösa dessa problem satsade Cerdo år 2007 på en SOA-baserad lösning, där en integrationsplattform implementerades för att knyta samman systemen. SOA blev en förutsättning för Cerdo när fokusen låg på att korta ner tider för bankärenden. Totalt effektiviserades ca 200 affärsprocesser (CIO Sweden, 2009).
4.1.3 Fritidsresor
Fritidsresor, som ingår i den nordiska koncernen Fritidsresegruppen, är ett av de största resebolagen i Norden. Fritidsresegruppen ingår i världens största resekoncern TUI Travel (Fritidsresor, 2012).
Under de senaste åren har resebranschen förändrats, från fysiska kundmöten i samband med köp av resor, till bokningar via Internet. Dessa förändringar låg till grund för det systemskifte Fritidsresor påbörjade till SOA (Larsson, 2009).
Fritidsresor uppskattar att återanvändning av IT-funktioner i olika delar av verksamheten sparat mycket tid. Dessutom har man upplevt fördelar med exempelvis kortbetalningar och en integrerad tjänst med förmedlingen av hyrbilar. Fokusen har legat i att användaren av hemsidan ska få intrycket av att allt sker genom Fritidsresor (Larsson, 2009).
4.1.4 Nordea
Nordea är en av norra Europas största banker. Koncernen Nordea startade genom att fyra storbanken sammanslogs från Sverige, Norge, Danmark och Finland. Denna sammanslagning genererade en komplex situation för koncernens IT-system. Varje år utför koncernens tio miljoner privatkunder flera miljarder transaktioner, vilka alla tidigare har hanterats olika beroende på vilket land och system det gäller (Goldberg, 2009).
År 2003 påbörjades en gigantisk undersökning av infrastrukturen inom IT-systemen, och hur de skulle kunna effektiviseras. Nordea valde att använda SOA för att slå samman sina IT-system. Resultatet är stora tidsbesparingar. Ärendetider för exempelvis ett banklån har förkortats från tio dagar till tio minuter. Detta är ett resultat av den standardisering som skett (Goldberg, 2009).
4.1.5 SBAB
SOA har även visat sig vara kostnadseffektivt för svenska SBAB. SBAB är en statligt ägd bank och bolåneinstitut som behövde genomföra flera större förändringar i sina IT-system. Anledningen till förändringarna var tre nya internationella lagar på finansmarknaden (Lewan, 2007).
Då regleringarna var avgörande för verksamheten, var man tvungen att genomföra förändringarna parallellt. SBAB passade då på att gå över till en SOA-baserad lösning (Lewan, 2007).
Antalet förändringsprojekt minskades och så även kostnaderna, i och med att en del systemkomponenter kunde återanvändas. Samma komponenter låg även till grund när SBAB startade upp sin bankverksamhet tätt därpå. SBAB:s IT-ansvarige Ulf Tingström menar att förvaltningen för verksamheten gjort kostnadsbesparingar med SOA på 30 till 50% (Lewan, 2007).
4.1.6 Starwood Hotels
Starwood Hotels är en av världens största internationella hotellkedjor. På 2000-talets början hade Starwood Hotels ett stort ökande antal besökare på sina hemsidor och CRM-systemet var uråldrat och komplext (CIOInsight, 2006).
Starwood Hotels började då flytta över sina system till ett öppet SOA-baserat ramverk. Det öppna ramverket tillåter en enklare utveckling av nya verktyg. Då företaget hade en god tillväxt passade detta bra. SOA tillät dotterbolag att använda samma ramverk istället för att låta dem bygga sina egna applikationer. Kostnadsbesparingarna med SOA är enorma. Israel Del Rio, Senior vice president of technology solutions på Starwood Hotels, menar att företaget sparar ca 20 miljoner dollar per år i underhållskostnader med SOA (CIOInsight, 2006).
4.1.7 Sammanfattning
De olika företagsfallen har haft olika förutsättningar och behov inför var och ens implementering av SOA. Samtidigt har företagsfallen gjort systemskiften till SOA från olika sorts system som använts tidigare. Därav är det svårt att hitta samband av hur implementeringar av SOA utfaller ifrån en viss typ av systemarkitektur.
Däremot kan man dra vissa slutsatser utifrån de parametrar som diskuteras i inledningen av kapitlet. I Tabell 2 på nästa sida beskrivs de likheter och skillnader de analyserade parametrarna uppvisar.
Likheter Skillnader
Kostnadseffektiva faktorer: De
olika företagsfallen uppvisar ett mönster där SOA-baserade lösningar varit kostnadseffektiva på liknande sätt.
Marknadssegment: Då företagsfallens
branscher skiljer sig, går det inte att dra några slutsatser om olikheter per
segment.
Förändrade förutsättningar:
Företagens drivkraft till systemskiftet har berott på nya förhållningssätt i organisationen eller på marknaden.
Behov av förändring: Företagsfallen
har alla haft olika sorts behov och anledningar till sitt systemskifte.
Teknisk lösning: Företagsfallens
tekniska lösningar har varit liknande, där en central SOA-enhet i form av mellanlager eller ramverk dominerat.
Förändringsarbete: En omfattande
omstrukturering har skett för hela verksamhetens systemarkitektur och företagskultur.
Tabell 2 – Företagsfallens likheter och skillnader
4.2 Empirisk undersökning
Resultatet för den empiriska undersökningen är uppdelat i två underrubriker, en per respondent. Avslutningsvis görs även en sammanfattning med jämförelser mellan enkätsvaren.
Den empiriska undersökningen är gjord utifrån den enkätundersökning som presenteras tidigare i rapporten. Enkäten innehåller bland annat frågor om anledning till implementeringen av SOA, vad företagen förändrat, samt vilka fördelar man upplevt med SOA. Formuläret med frågorna till enkäten återfinns i sin helhet i Bilaga 1.
Den empiriska undersökningen syftar till att utreda mer djupgående frågor för vem SOA är lämpligt, samt hur systemarkitekturen bör angripas. Den empiriska undersökningen analyserar följaktligen parametrar som:
Fördelar med SOA
Teknisk lösning
4.2.1 Cerdo Bankpartner
Per Skenhall har jobbat i fem år som IT-arkitekt på Cerdo Bankpartner. Outsourcingföretaget implementerade en SOA-baserad lösning i samband med att man knutit samman applikationer som inte samverkade genom en integrationsplattform (CIO Sweden, 2009).
Tabell 3 nedan visar ett urklipp bland de frågor och svar som Skenhall besvarar i undersökningen. Urklippet belyser på vilka sätt SOA varit kostnadseffektivt för Cerdo Bankpartner, samt aspekter att tänka på i samband med en implementering av SOA.
Fråga Svar
Vad var
huvudanledningen till att ni gick över till en SOA-baserad arkitektur? Var det ett affärsstrategiskt beslut?
”kunna driva en mer kostnadseffektiv
livscykelhantering av systemportföljen utifrån större volymer”
”SOA-baserad arkitektur blev därför en av hörnpelarna i transformeringsprojektet för att kunna separera olika system”
Vilka är de största
fördelarna ni upplevt med SOA?
”en mycket mer flexibel systemportfölj där nya funktioner snabbt och effektivt kan uppnås” ”bättre möjligheter att övervaka den dagliga driften av integrationen mellan system och externa parter” För vem tycker du SOA är
lönsamt? ”när flexibilitet och kort time-to-market är viktigt” Tabell 3 – Urklipp av enkätsvar från Per Skenhall, Cerdo Bankpartner Enkätsvaren från Per Skenhall, härefter representerad som Företag 1, visas i sin helhet i Bilaga 2.
Företag 1 förklarar att SOA hade en stor del i det transformeringsprojekt som syftade till att lösa dessa problem. Företag 1 menar att SOA var en kostnadseffektiv lösning vid integrationen av applikationerna.
Det Cerdo Bankpartner gjorde var att implementera en integrationsplattform som var tänkt att ersätta det dåvarande kärnbanksystemet. Företag 1 förklarar vidare att den nya integrationsplattformen samlade rutiner för olika applikationer, vilket gjorde att alla nya eller ändrade integrationer gick genom denna plattform. Det sparade verksamheten mycket tid och resurser i utvecklingen av nya funktioner.
Förutom denna effektivisering hade SOA en fördel i och med den standardisering som gjordes kring integrationerna. Företag 1 menar att standardiseringen har gett Cerdo bättre möjligheter att hantera integrationer mellan egna system och externa parter.
Företag 1 hävdar fortsättningsvis att SOA kan vara lönsamt för företag som har krav på att få ut nya applikationer på kort tid. Företag 1 menar att ett SOA-baserat verktyg, som exempelvis Cerdos integrationsplattform, förenklar utvecklingen av nya applikationer på ett snabbt och flexibelt sätt.
4.2.2 Nordea
Hans-Henrik Eigtved har jobbat på Nordea sen 1999, varav de senaste fyra åren som Head of IT Retail Banking. Bankkoncernen Nordea använde SOA vid sammanslagningen av sina IT-system. Den standardisering som gjordes i samband med implementeringen resulterade i förkortade ärendetider och effektivisering av infrastrukturen (Goldberg, 2009).
Tabell 4 nedan visar ett urklipp bland de frågor och svar som Eigtved besvarar i undersökningen. Urklippet belyser på vilka sätt SOA varit kostnadseffektivt för Nordea, samt aspekter att tänka på i samband med en implementering av SOA.
Fråga Svar
Vad var
huvudanledningen till att ni gick över till en SOA-baserad arkitektur? Var det ett affärsstrategiskt beslut?
”business transformation”
”harmonise processes and consolidate our front-end banking applications across countries without needing to consolidate our national back-end systems at the same time”
”SOA was introduced as a tool to separate the two parts through SOA-service interfaces”
Vilka är de största
fördelarna ni upplevt med SOA?
”easy to re-use to serve different front-end applications”
”interfaces easier to manage” För vem tycker du SOA är
lönsamt? ”you need to have a demand for it”
Tabell 4 – Urklipp av enkätsvar från Hans-Henrik Eigtved, Nordea
Enkätsvaren från Hans-Henrik Eigtved, härefter representerad som Företag 2, visas i sin helhet i Bilaga 3.
Huvudanledningen till att Nordea valde en arkitektur baserad på SOA var att bankens ”front applikationer skulle samverka samtidigt som ”back end”-funktionaliteterna från varje land skulle lämnas orörda. Företag 2 förklarar att det inte finns några siffor som direkt härrör till implementeringen av just SOA, men den investering som gjordes i samband med systemskiftet hade en återbetalningstid på mellan två och tre år.
Företag 2 menar vidare att SOA används som ett verktyg som separerar båda delar. Verktyget fungerar som ett brygga mellan nyare ”front end”-applikationer och de äldre, nationella ”back end”-end”-applikationerna.
Mellanlagret har gjort att olika funktioner blivit enkla att återanvända, vilket har snabbat upp utvecklingstiden av nya applikationer. Dessutom har det varit lättare att hantera olika sorters gränssnitt med SOA-lösningen, påstår Företag 2.
Företag 2 anser att det måste finnas en efterfrågan av SOA för att en implementering ska vara lönsam. Företag 2 menar vidare att SOA bör ses som ett förändringsarbete för att uppnå kostnadseffektivitet.
4.2.3 Sammanfattning
Respondenterna från den empiriska undersökningen har båda varit med hela vägen i det systemskifte verksamheten genomgått. Detta har gett dem möjlighet att analysera för vem och hur SOA bör angripas i samband med en eventuell implementering. I Tabell 5 nedan beskrivs de likheter och skillnader respondenterna upplevt med sina systemskiften.
Likheter Skillnader
Fördelar med SOA: Båda
respondenter upplever att den SOA-baserade lösningen genererat snabbare produktutveckling.
Teknisk förutsättning: Inför
systemskiftet skiljer sig
verksamheternas system mycket, då de kommer från skilda branscher.
Teknisk lösning: Respondenternas
företag har båda lagt stor fokus vid att sköta integrationer från en central källa, samt ha tydligt definierade gränssnitt.
Efterfrågan: Då båda företagen gått
igenom verksamhetsövergripande förändringar har en efterfrågan funnits. Respondenterna är också båda av uppfattningen att det krävs ett behov av SOA för att en
implementering ska vara aktuell.
5 Analys
Analysen görs utifrån det resultat som presenteras i föregående kapitel. Analysen binder samman detta resultat med den teoretiska litteraturstudien för undersökningen, vilket gör att frågeställningen kan besvaras i kapitelet.
Innan verksamheten bestämmer sig för att genomföra förändringar i sin systemarkitektur bör det utredas varför. Det är viktigt att belysa de saker som behöver förbättras. Van Den Berg, Bieberstein och Van Ommeren (2007) presenterar de vanligaste incitamenten till implementering av SOA som förändring inom IT, sammanslagning av system, legalisering, nya marknader och krav från leverantörer eller distributörer. Resultatet av företagsfallen från föregående kapitel påvisar liknande anledningar.
Det kan vara bra att göra investeringskalkyler på vad en implementering både skulle kosta och generera. Investeringskalkylen är ett beslutsunderlag, medan exempelvis en marknadsanalys är ett annat. Kanske är det så att ett systemskifte kan vara nödvändigt för att ens kunna konkurrera inom marknadssegmentet inom en snar framtid, trots att det medför stora implementeringskostnader. Vad som kan vara värt att tänka på i samband med kostnadsberäkningar är hur länge en systemarkitektur är aktuell.
Underhåll av systemarkitekturen bör ses som ett kontinuerligt arbete, vilket ju medför kostnader även efter en implementering (Bilaga 2). Denna kontinuerliga process fortlöper hela tiden och arkitekturen bör förändras vid varje utvecklingsprojekts start och slut (Bilaga 3).
Kavis (2009) menar att det i mångt och mycket handlar om en kolloborativ verksamhetsförändring för att lyckas med implementeringen av SOA. Det är inte bara verksamhetens IT som behöver anpassas till SOA, utan även affärsprocesser och inte minst företagskulturen. Att se SOA som en förändring är viktigt för att lyckas (Kavis, 2009).
Att förändringsarbetet och kulturskiftet sker på alla nivåer i organisationen är även det viktigt. SOA har inverkan genom systemarkitekturens alla skikt, och då gäller det att inte bara verksamhetens Enterprise Architecture är redo för ett systemskifte, utan även mer operationella divisioner.
SOA-specialisten Eskil Swende menar att implementering av SOA tar mycket tid inledningsvis, men att kostnaderna ändå är relativt låga (Berg, 2008). SOA kan vara ett bra angreppssätt, när det väl är implementerat, för företag på marknader med kort tid gällande ”time-to-market” (Bilaga 2). När
SOA-lösningen väl är på plats går utvecklingen av nya applikationer snabbare vilket gör att man tjänar igen den tid man lagt på implementeringen.
5.1 Hur SOA kan vara kostnadseffektivt
Om en verksamhet överväger att gå över till en SOA-baserad lösning är det viktigt att ha insikt om vad det innebär. Även om SOA påvisade kostnadseffektiva resultat bland företagsfallen, som är inom olika branscher, betyder det inte att SOA behöver vara en framgångssaga för alla.
Kavis (2009) presenterar i sin artikel att hela 50% implementeringar till SOA är misslyckade. I artikeln refererar Kavis till Anne Thomas Manes, analyschef för Burton Group som genomfört undersökningen, som poängterar att de misslyckade implementeringarna inte beror på tekniska aspekter, utan snarare att medarbetare och processer inte anpassats till det kulturskifte SOA faktiskt innebär.
En SOA-baserad arkitektur passar inte heller alla verksamheter. Resulatet av den empiriska undersökningen indikerar på att ett behov av SOA måste finnas för att en implementering ska vara befogad. Finns inget behov av en implementering betalar sig inte investeringskostnaden, då fördelarna man drar av SOA är för få (Bilaga 2; Bilaga 3).
SOA har dock visat sig vara kostnadseffektivt för många. Tabell 6 på nästa sida sammanställer resultatet från företagsfallen undersökningen presenterade i föregående kapitel. Resultatkolumnen visar på vilket sätt implementeringen av SOA varit kostnadseffektiv för respektive företag.
Företagsfall Behov/anledning Lösning Resultat
British Telecom Sammanslagning Sammanslagning Sänkta kostnader Färre IT-projekt
Cerdo Bankpartner Snabbare processer och integration Integrations-plattform Effektiviserade affärsprocesser Kortade ärendetider Snabbare produktutveckling Fritidsresor Bokningar via
Internet
Återanvändning
av funktioner Tidsbesparingar
Nordea Sammanslagning Enterprise Service Bus Tidsbesparingar Kortade ärendetider Snabbare produktutveckling SBAB Internationell lagstiftning SOA-ramverk Sänkta kostnader Färre IT-projekt Snabbare produktutveckling Starwood Hotels Ökad kundmängd SOA-ramverk
Sänkta kostnader Tidsbesparingar Snabbare
produktutveckling Tabell 6 – Sammanställning av företagsfall
Företagsfallen har de likheter att drivkraften till systemskiftet varit förändrade förutsättningar inom organisationen eller markanden. De tekniska anledningarna och förutsättningarna skiljer sig dock från verksamhet till verksamhet. Det är även svårt att urskilja några särskilda likheter utifrån de olika marknadssegmenten företagsfallen kommer ifrån.
Däremot kan man se i alla företagsfall att implementeringar av SOA gett ett positivt resultat genom ett omfattande förändringsarbete. Det är tydligt att hela verksamhetens systemarkitektur har omstrukturerats. För flertalet av företagen i fallen har lösningen varit ett centraliserat och tjänsteorienterat ramverk.
Trots att företagen i fallen haft olika behov av förändring och lösningar har sett olika ut, så har den viktigaste parametern för frågeställningen, det kostnadseffektiva resultatet, visat liknande mönster. SOA-implementeringarna från företagsfallen har sitt främsta resultat i sänkta kostnader, tidsbesparingar och snabbare produktutveckling. Dessa faktorer är enligt företagsfallen de vanligaste förekommande sätten SOA varit kostnadseffektivt på. Förutom resultatet av de kostnadseffektiva faktorerna har
implementeringar av SOA bland annat ökat kundtillfredsställelsen och integrerat externa tjänster.
Sammanfattningsvis kan studien presentera att SOA kan vara kostnadseffektivt för verksamheter främst på följande sätt:
Sänkta kostnader
Om investeringen är gjord på rätt sätt bör SOA-verktyg och
återanvändning av funktionalitet resultera i sänkta kostnader. Syftet med SOA är att minska komplexiteten och öka flexibiliteten. Givetvis är sänkta kostnader ingen garanti bara för att man skaffar en
SOA-baserad lösning. Tidsbesparingar
Återanvändning av funktioner, användning av webbtjänster och väl fungerande SOA-ramverk sänker inte bara kostnader, utan fokuserar även på att minimera arbetet med teknikerna. Förbättrad tillgänglighet och effektiviserade processer gör att tidsbesparingar kan bli stora av en tjänstebaserad systemdesign.
Snabbare produktuteckling
En bra SOA-lösning främjar modulär utveckling. De tjänster och den funktionalitet som återanvänds skall vara av den kvalitet att de
underlättar för snabbare utveckling av nya applikationer och produkter. En snabbare produktutveckling är kostnadseffektiv då mindre resurser förbrukas, samtidigt som den kan ge konkurrensfördelar genom snabb leveranstid.
5.2 Fem kritiska framgångsfaktorer
När verksamheten väl bestämt sig för att förändringar ska genomföras i sin systemarkitektur är det viktigt att utvärdera vad som behöver förändras, samt hur implementeringen ska gå tillväga. Denna analys handlar inte bara om vad som behöver förbättras, utan även vilka tekniska möjligheter som finns.
Tekniska lösningar inom SOA är ofta baserade på webbtjänster eller andra tjänstebaserade applikationer. Stora system med hög grad av komplexitet är i behov av många integrationer mellan olika tjänster. Dessa tjänster bör ha tydliga gränssnitt för att integrationer ska fungera flexibelt. Med väl definierade gränssnitt är applikationerna inte bara kompatibla till det egna SOA-ramverket, utan även till externa system (Bilaga 2). Väldefinierade gränssnitt är dessutom lättare att hantera vid utveckling (Bilaga 3).
Även om gränssnitt görs väldefinierade blir antalet applikationer och tjänster många för stora IT-system, vilket bör innebära stora behov av integration. Då kan det möjligen vara fördelaktigt att ta hjälp av ett verktyg som sköter dessa integrationer. En del företagsfall i studien har löst detta genom SOA-ramverk som sköter integrationer på olika sätt.
Den empiriska undersökningen beskriver en del exempel på SOA-baserade lösningar. I samband med Nordeas systemskifte infördes ett mellanskikt i form av en Enterprise Service Bus, som sköter alla integrationer (Bilaga 3). Deras system var allt komplexare och gränssnitt fungerar inte längre ”point-to-point”. Dock är det viktigt att mellanlagret har hög kapacitet och prestanda för att kunna hantera alla olikheter som uppstår i integrationerna. Trots allt är det ändå applikationernas gränssnitts tydlighet som är viktigast (Bilaga 3). Cerdo Bankpartner använde sig av en integrationsplattform vid implementering av sin SOA-lösning, vilket även det förenklade arbetet med gränssnitt och integration. Dessutom har det varit till stor fördel för verksamheten att alla applikationer utvecklats på ett standardiserat sätt, då det har avlastat arbetet för integrationsplattformen (Bilaga 2).
Förutom de tekniska aspekterna gällande SOA, är det viktigt att komma ihåg den verksamhetsförändring SOA innebär. SOA bör implementeras i samband med ett kulturskifte inom organisationen för att den ska ge effekt (Kavis, 2009). SOA genomsyrar affärsprocesser i verksamheten på alla nivåer, vilket har en betydelse för såväl Enterprise Architecture som Solution Architecture. För att SOA ska få den önskade genomslagskraften inom verksamhetens förändring är det viktigt att det finns ett behov av SOA inom marknadssegmentet. Om förutsättningarna på marknaden är relativt statiska och har låga krav på flexibilitet blir troligtvis inte effekten av SOA särskilt stor (Bilaga 2).
För att en implementering av SOA ska vara framgånsrik bör man också se systemskiftet ur en mer långsiktig synvinkel. Att implementera framtidens lösning i ett ständigt föränderligt IT-samhälle är inte lätt. Kompetens om tekniska nyheter, förändrade förutsättningar inom marknadssegmentet och kanske legala krav ses som en färskvara.
Kompetens och förutsägbarhet om hur framtiden ser ut bör också beaktas vid en implementering av anledningen att systemskiften ofta tar lång tid, ibland flera år (Olson & Kesharwani, 2010). En annan sak man bör tänka på är att utveckla lösningar kompatibla för flera plattformar. De senaste åren har användandet av mobila enheter blivit en vardaglighet, även när det gäller arbetsuppgifter inom verksamhetens IT-system.
Slutligen är det även viktigt att ha en tydlig strategi om hur implementeringen ska gå till innan man påbörjar införandet. Erl (2005) menar att en Big
bang-implementering inte är att föredra, då stora risker föreligger vid systemskiften till SOA. För att undvika ett misslyckande kan det istället vara lämpligt att låta implementeringen ske i steg. Fasad per modul är då en aktuell införandestrategi, där SOA iterativt tar en allt större del av verksamhetens infrastruktur (Magnusson & Olsson, 2008).
Ovanstående redogörelse är baserad på data från företagsfallen tillsammans med den empiriska undersökningen. Utifrån denna analys kan fem kritiska framgångsfaktorer för en implementering av SOA identifieras:
Använd centralt SOA-ramverk
Systemarkitekturer är idag allt mer komplexa med användning av många olika tjänster. Detta medför ett stort behov av integration då tjänster och applikationer ofta är utvecklade med olika protokoll och gränssnitt. Med grund i detta är ett centralt SOA-ramverk att föredra för att hantera alla dessa integrationer. Ett centralt SOA-ramverk kan exempelvis bestå av en integrationsplattform eller en Enterprise Service Bus, som sköter integrationer.
Ha tydligt definierade gränssnitt
För att SOA-verktyget ska fungera väl krävs väl definierade gränssnitt. Att tjänster och applikationer har tydliga gränssnitt underlättar för integration och utveckling mot dem. Gränssnitt bör vara utvecklade på ett standardiserat sätt.
Bli redo för kulturskifte
SOA bör ses som ett kulturskifte för hela verksamhetens strategi gällande sin IT. Att tjänsteorientera verksamhetens Enterprise Architecture medför förändrade förutsättningar vad gäller både
affärsprocesser och arbete mot olika system. En implementering av SOA har inflytande i alla delar av organisationen och därför bör SOA inte ses som ett projekt.
Välj implementeringsmetod
Hur implementeringen av SOA går till rent praktiskt har stor inverkan på utgången av systemskiftet. Att implementera SOA genom Big bang medför stora risker när kanske varken företagskultur eller infrastruktur är redo för detta. Därför kan en fasad införandestrategi vara lämplig, då man bör beakta att det tar lång tid att genomföra ett systemskifte till SOA.
Tänk långsiktigt
Att implementera en ny systemarkitektur är en stor investering. För att verkligen lyckas med systemskiftet bör man även se saker ur ett längre
perspektiv. Att förutse framtidens situation inom marknadssegmentet och IT-marknaden kan vara svårt, men att utveckla sin SOA-lösning med kompabilitet mot flertalet nya plattformar, just nu mobila, är definitivt en framtidsinvestering.
