Examensarbete i Informatik
SOA – Tänk efter före
Ett organisationsförberedande ramverk inför
implementeringen av en tjänsteorienterad arkitektur Daniel Friberg, Kristina Gyllander, Mondésir Mondélus
Göteborg, Sweden 2007
Institutionen för tillämpad informationsteknologi
REPORT NO. 2007:61
SOA – Tänk efter före
Ett organisationsförberedande ramverk inför implementeringen av en tjänsteorienterad arkitektur
DANIEL FRIBERG KRISTINA GYLLANDER MONDÉSIR MONDÉLUS
Department of Applied Information Technology
IT UNIVERSITY OF GÖTEBORG
GÖTEBORG UNIVERSITY AND CHALMERS UNIVERSITY OF TECHNOLOGY Göteborg, Sweden 2007
Abstrakt
SOA (Service Oriented Architecture) är ett koncept för hur affärsverksamheten och informationsteknologin i en organisation ska organiseras med återanvändbara tjänster som skapas utifrån verksamhetens processer. Att införa en SOA ställer höga krav på hela verksamheten då det innebär både ett teknik- och kulturskifte.
Därför krävs det att organisationen är väl insatt i det åtagande de har och att förändringsviljan är väl förankrad i alla nivåer och enheter. Genom litteratur- granskning och med stöd av sex kvalitativa intervjuer har i denna uppsats ett organisationsförberedande ramverk arbetats fram med en rad riskfaktorer att beakta inför en SOA-implementering. Ramverket formades slutligen till att innehålla tretton faktorer där samtliga måste fungera i en organisation som ska införa en SOA. Av dessa faktorer kunde fem lyftas fram ytterligare, då de utgör en extra stor risk att bli förbisedda.
Nyckelord: SOA, organisationsförberedelse, inför implementering SOA – Tänk efter före
Ett organisationsförberedande ramverk inför implementeringen av en tjänsteorienterad arkitektur
DANIEL FRIBERG, KRISTINA GYLLANDER, MONDÉSIR MONDÉLUS Handledare: Faramarz Agahi
Examinator: Alan B Carlson
Institutionen för tillämpad informationsteknologi IT-universitetet i Göteborg
Göteborgs Universitet och Chalmers Tekniska Högskola
SUMMARY
Service Oriented Architecture (SOA) represents a concept on how to organize the business activity and information technology of an organization where reusable services are created from the business processes and information systems.
Introducing a SOA calls for major demands on the entire organization due to the fact that it involves both a change of technology and culture. Therefore it requires the organization to be well-informed about the commitment it takes, and in addition that the will towards change is firmly established on all levels and in all units. The object of this thesis has been to produce a framework consisting of a series of risk factors to take into consideration before implementing a SOA. This has been accomplished through a literary review supported by qualitative interviews. Ultimately the framework has been modified to contain thirteen factors which all need to function in an organization aiming to implement a SOA.
Five of those factors could be identified as high risk factors in regard to being neglected by the business organization.
The report is written in Swedish.
Keywords: SOA, organizational preparation, pre-implementation SOA – Look before you leap
A framework for organizational preparation during pre-implementation of a SOA
DANIEL FRIBERG, KRISTINA GYLLANDER, MONDÉSIR MONDÉLUS Department of Applied Information Technology
IT University of Göteborg
Göteborg University and Chalmers University of Technology
SOA – Tänk efter före
Ett organisationsförberedande ramverk inför implementeringen av en tjänsteorienterad arkitektur.
DANIEL FRIBERG, KRISTINA GYLLANDER, MONDÉSIR MONDÉLUS
© DANIEL FRIBERG, KRISTINA GYLLANDER, MONDÉSIR MONDÉLUS, 2007.
Report no 2007:61 ISSN: 1651-4769
Department of Applied Information Technology IT University of Göteborg
Göteborg University and Chalmers University of Technology P O Box 8718
SE – 402 75 Göteborg Sweden
Telephone + 46 (0)31-772 4895
[Institutionen för tillämpad informationsteknologi]
Göteborg, Sweden 2007
Innehåll
1 Introduktion... 1
1.1 Bakgrund ... 1
1.2 Tidigare forskning ... 2
1.3 Implementering av affärssystem ... 2
1.4 SOA kontra affärssystem ... 3
1.5 Syfte och frågeställning... 3
1.6 Avgränsning ... 4
1.7 Disposition ... 4
2 Metod... 5
2.1 Vetenskapligt angreppssätt... 6
2.2 Tillförlitlighet ... 7
2.2.1 Källkritik ... 8
3 Teoretisk ram... 10
3.1 Tjänsteorienterad arkitektur ... 10
3.1.1 Definition av SOA... 11
3.1.2 Tjänster... 12
3.1.3 Web Services... 14
3.1.4 Register och repository... 16
3.1.5 Planera för SOA ... 17
3.1.6 Identifiering av tjänster ... 19
3.1.7 Governance... 20
3.1.8 Teknisk grund... 21
3.2 Affärssystem... 24
3.2.1 Införande av affärssystem ... 25
4.1 Anpassning av modell ... 29
4.2 Ledning... 30
4.2.1 Strategi ... 30
4.2.2 Ledarskap ... 31
4.2.3 Stöd... 32
4.2.4 Kompetens... 32
4.3 Projekt ... 32
4.3.1 Projektgrupp ... 32
4.3.2 Projektledning (Management)... 33
4.3.3 Projektplan ... 34
4.3.4 Hantering av externa konsulter ... 34
4.4 Organisation ... 35
4.4.1 Företagskultur... 35
4.4.2 Förändring ... 36
4.4.3 Processhantering... 37
4.4.4 Kommunikation... 38
4.5 Teknisk plattform ... 38
5 Resultat och diskussion ... 41
5.1 Respondentpresentation ... 41
5.2 Ledning... 42
5.2.1 Strategi ... 42
5.2.2 Diskussion Strategi... 43
5.2.3 Ledarskap ... 44
5.2.4 Diskussion Ledarskap ... 45
5.2.5 Stöd... 46
5.2.6 Diskussion Stöd... 48
5.2.7 Kompetens... 49
5.2.8 Diskussion Kompetens ... 50
5.3 Projekt ... 50
5.3.1 Projektgrupp ... 50
5.3.2 Diskussion Grupp ... 51
5.3.3 Projektledning (Management)... 52
5.3.4 Diskussion Management ... 52
5.3.5 Projektplan ... 53
5.3.6 Diskussion Plan ... 53
5.3.7 Hantering av externa konsulter ... 54
5.3.8 Diskussion Externt ... 55
5.4 Organisation ... 56
5.4.1 Företagskultur... 56
5.4.2 Diskussion Kultur... 57
5.4.3 Förändring ... 58
5.4.4 Diskussion Förändring ... 60
5.4.5 Processhantering... 61
5.4.6 Diskussion Process ... 62
5.4.7 Kommunikation... 63
5.4.8 Diskussion Kommunikation ... 64
5.5 Teknisk plattform ... 65
5.5.1 Diskussion Teknisk plattform ... 67
5.6 Ramverket i sin helhet... 68
6 Generell diskussion och slutsats... 71
6.1 Slutgiltigt ramverk... 71
6.2 Slutsats ... 73
6.3 Förslag till vidare forskning ... 73
7 Referenser ... 75
Bilaga 1 – Intervjuunderlag ... 79
1 Introduktion
På en affärsmarknad med allt högre konkurrens och snabbare förändringstakt, ställs det ständigt ökande krav på flexibla organisationer som snabbt kan ändra kurs och följa den utveckling som sker. Att införa tjänsteorienterad arkitektur i företag är ett sätt att skapa mer flexibla organisationer, som lättare får möjlighet att följa marknadens svängningar. I korthet kan tjänsteorienterad arkitektur beskrivas som ett objektorienterat tankesätt som involverar hela organisationens sätt att arbeta. Åter- användbara tjänster skapas utifrån företagets processer och informationssystem.
Tjänsterna kan sedan användas som byggstenar i olika sammanhang och kombina- tioner efter behov.
1.1 Bakgrund
Enligt analysföretaget Gartner ligger tjänsteorienterade arkitekturer idag på en sjunde plats bland företagens teknikprioriteringar. De listar även en rad affärsprioriteringar såsom, ”förbättrade affärsprocesser”, ”kontroll över operativa kostnader”, ”snabbare innovationer” och ”införande av nya funktioner för att möta strategiska mål”
(Wallström, 2007). Anders Torelm, Chef över IBM-programvara, påstår också att cirka 80 procent av alla nya projekt som startas under 2008, enligt Gartners analyser, kommer att handla om tjänsteorienterade arkitekturer. Det grundar sig i behovet av att kunna möta önskemålen om att IT på ett bättre sätt skall kunna stödja affärs- verksamhetens prioriteringar och för att möjliggöra snabb anpassning till framtida förändringar (Torelm, 2007).
SOA är en av den senaste tidens trebokstavsförkortningar som det talats mycket om.
Det står för Service Oriented Architecture och är den engelska benämningen av tjänsteorienterad arkitektur. Det verkar dock finnas få som verkligen vet vad SOA är.
David Linthicum, som är ett framstående namn inom SOA, verkar precis som Torelm övertygad om att SOA just nu är på stark frammarsch. Han hävdar att ju fler lyckade exempel det dyker upp bland de företag som tidigt hoppade på trenden, desto fler väljer att följa efter. Han tror att det kommer att bli en stor ökning i antalet SOA- relaterade projekt under 2007 och varnar samtidigt för risken att en ”hype” kring ämnet ska uppstå. Han anser att alltför många organisationer är övertygade om att de vill ha SOA trots de inte ens har kunskap nog till att kunna definiera vad det är, eller vet hur den ska användas. Linthicum (2007) väljer att uttrycka det som: ”they’ll buy the house before they know where they are going to put it” (s. 20). Till det läggs problemet med teknikleverantörer som erbjuder olika SOA-lösningar för att lösa samma problem och som hävdar att deras lösningar är heltäckande, oavsett om deras teknologi faktiskt stödjer SOA eller inte. Det leder oss dessutom in på nästa problemområde, att SOA ses som en IT-lösning fast det i själva verket utgör ett koncept för hur hela verksamheten ska bedrivas. Linthicum nämner även problematiken i det korta tidsperspektiv för SOA-implementering som oftast råder.
Leverantörerna måste förstå att SOA är ett långtidsprojekt. Kunskapen om de förändringar och förberedelser som krävs inför ett SOA-projekt måste öka bland företagsledare och IT-chefer. Arbetet börjar med förståelsen för företagets behov på en språklig-, process- och servicenivå eftersom SOA lika mycket innebär ett kultur- som ett teknikskifte och måste vara förankrad i dem båda för att bli framgångsrik. Att inte redan från början ha rätt personer ombord på båten kan bli kostsamt . Linthicum höjer ett varningens finger med påståendet att om inte dessa kunskaper ökar, kommer
framtiden att ge många rubriker om misslyckade SOA-projekt (Linthicum, 2005, 2007).
1.2 Tidigare forskning
Det vore att sticka ut hakan lite väl långt, att påstå att det inte gjorts någon akademisk forskning om vilka faktorer som påverkar huruvida införandet av en tjänsteorienterad arkitektur, eller SOA, kommer att bli lyckad eller ej. Vi vågar dock påstå att det är ett ämne som det inte har skrivits några större mängder litteratur om. Det finns ett antal så kallade mognadsmodeller på marknaden bland leverantörer av SOA-lösningar.
Modellerna ska fungera som en slags fingervisning för företagen hur pass väl förberedda de är att ge sig på en SOA-satsning och kan i första läget verka likt den ansats vi haft med denna studie, men dessa modeller är för det första inte heltäckande, för det andra fokuserar de mycket på den tekniska grunden för en SOA och för det tredje har de ingen vetenskaplig grund. Däremot har det har gjorts akademiska studier tidigare i kritiska framgångsfaktorer för att andra typer av projekt ska bli lyckade.
White och Fortune (2002) har gjort en studie där de tagit reda på vad personer ute i arbetslivet ansåg vara de viktigaste faktorerna för att skapa framgångsrika IT-projekt.
Studiens deltagare var verksamma inom skilda branscher med mycket varierande storlek. Deltagarna fick svara på enkätfrågor i två omgångar där de i första läget själva fick ange kritiska framgångsfaktorer för projekt, och i andra läget prioritera de faktorer som framkommit i första omgången. Studien resulterade i en tabell med 22 faktorer som anses vara mer eller mindre kritiska för framgång. Tabellen toppas av faktorerna ”tydliga mål”, ”stöd hos högsta ledningen”, ”lämpliga/tillräckliga resurser”
och ”realistisk tidsplan” och fortsätter med andra liknade faktorer i fallande prioritetsordning.
Whites och Fortunes forskningsrapport har i sin tur till viss del legat till grund för en studie gjord av Magnusson, Nilsson och Carlsson (2004). De har utifrån litteratur- studier och företagsintervjuer tagit fram sexton faktorer som de anser behöver vara väl fungerande för att ett affärssystemsimplementeringsprojekt ska lyckas. Faktorerna berör frågor om allt ifrån affärsstrategier och företagskultur till teknologi och har sorterats i ett ramverk med fyra olika skikt eller nivåer med fyra faktorer i varje.
Nivåerna utgörs av: 1) Ledning, det vill säga beställarna eller ägarna av projektet, 2) Projekt, som hanterar faktorer angående själva arbetet med projektet, 3) Organisation, vilket utgör den organisation som projektet utförs i, samt slutligen 4) System, vilket tar upp faktorer som har direkt anknytning till det system som ska införas.
1.3 Implementering av affärssystem
Affärssystem utgörs av stora och kostsamma verksamhetsövergripande projekt som kan ha en påverkan på hela företagskulturen (Davenport, 1998). Davenport väljer, för att förtydliga sin ståndpunkt, att citera en företagsledare angående affärssystemet SAP: ”SAP isn’t a software package; it’s a way of doing business” (s. 125).
För att ett affärssystemsprojekt ska bli lyckat krävs det att ledningen är helt medveten om, och involverad i, projektet och att det finns tydliga affärs- respektive IT-strategier som stämmer överens med varandra. Affärssystem bygger dessutom precis som SOA på standardiserade företagsprocesser med målet att skapa visibilitet och flexibilitet i företagen. Davenport (1998) påstår även att när problem uppstår vid införandet av ett affärssystem så beror det oftast på problem med affärssidan oavsett hur komplicerad
den tekniska implementeringen är. Företagsledare ser vanligen affärssystems- implementeringar som ett IT- och inte som ett verksamhetsprojekt. De misslyckas därför med att få affärsbehoven och informationsteknologin att stämma överens då de ger sig in i affärssystemsprojekt utan att först ha skapat sig en fullständig förståelse för affärskraven. Han skriver att ledningen måste se upp så att den inte glömmer att se problemen bakom alla fördelar och löften. För problem har det varit mycket av när det gäller affärssystemsimplementeringar. Undersökningar visar på att bara cirka 10-20 procent av alla affärssystemsprojekt varit lyckade med avseende på budget, tidsram och uppfyllda förväntningar (Parr & Shanks, 2000).
1.4 SOA kontra affärssystem
Även om SOA och affärssystem skiljer sig fundamentalt åt, såväl teoretiskt som i den tekniska lösningen, så finns det många intressanta paralleller dem emellan. Den huvudsakliga likheten som gör en jämförelse intressant är att de båda utgör stora verk- samhetsövergripande projekt då de införs. Införandena innebär en påverkan på hela organisationen och ska därför hellre ses som ett organisationsprojekt än ett IT-projekt.
De baseras på standardiserade företagsprocesser och båda införs vanligtvis för att tillmötesgå organisationens krav på att kunna möta konkurrensen från omgivningen.
Viktiga skillnader att ta hänsyn till, mellan de båda, är först och främst att affärssystem är ett system, precis som namnet beskriver, medan SOA är ett koncept för hur hela verksamheten ska bedrivas. Affärssystem har, i och med det faktum att det är ett system som införs, slutanvändare som påverkas av implementeringen. Även en SOA kräver naturligtvis teknologi i botten för att stödja de behov som en tjänsteorienterad arkitektur har, men där är inte slutanvändarna en faktor som behöver beaktas eftersom några sådana inte existerar i egentlig mening.
Med likheterna i att båda utgör verksamhetsövergripande projekt i fokus och med de nämnda skillnaderna i beaktande har vi för denna studie valt att ta avstamp i ramverket utarbetat av Magnusson et al. (2004), för att se om, och i så fall hur, detta skulle kunna anpassas för att passa för SOA-sammanhang. Förhoppningen är att ett sådant ramverk ska kunna användas för att få företag som vill införa en tjänste- orienterad arkitektur att inse vad arbetet som ligger framför dem kommer att innebära.
1.5 Syfte och frågeställning
Syftet med uppsatsen är att undersöka vad företag behöver tänka på innan de ger sig in på att införa en tjänsteorienterad arkitektur, så att en upprepning av det stora antalet misslyckanden som skett i samband med affärssystemsimplementeringar kan und- vikas. Med studien vill vi öka medvetenheten hos företag som vill införa en SOA om vilken utmaning det innebär för organisationen, genom att visa på riskområden som kan påverka utgången för projektet. Det görs genom att ta fram ett ramverk som ska fungera som ett stöd för att få verksamheter att förstå vad som krävs av hela organisationen inför en SOA-implementering.
Frågeställningen för uppsatsen blir därmed:
Vilka förberedande faktorer ska en organisation beakta inför ett verksamhetsövergripande SOA-införande?
Den följs av frågan:
Utgör några av dessa faktorer en högre risk än de andra att förbises?
1.6 Avgränsning
Undersökningen är avgränsad till att studera faktorer som bör beaktas redan innan ett SOA-projekt påbörjas. Vilka organisationer som bäst lämpar sig för att skaffa en tjänsteorienterad arkitektur berörs inte, ej heller hur de organisationer som vill förbereda sig inför en SOA-implementering ska gå till väga, eller hur eventuella problem som kan upptäckas med hjälp av ramverket ska lösas. Affärsnyttan med ett införande av en tjänsteorienterad arkitektur berörs inte heller.
1.7 Disposition
I nästföljande kapitel redogörs för hur den vetenskapliga metoden för uppsatsen valts och hur arbetsgången i projektet varit. Därefter följer, i kapitel 3 och 4, den teoretiska ram som ligger till grund för uppsatsen. I teorikapitel 3 redovisas de teorier som behövs för den allmänna förståelsen. Det följs av teorikapitel 4 som redogör för hur valet av modell gjorts. Där redovisas även nödvändiga teoriavsnitt för att förklara innebörden av modellens ingående delar. I kapitel 5 redovisas resultatet av de genomförda intervjuerna varvat med diskussioner för respektive faktor i ramverket.
Med tanke på det relativt stora antalet faktorer varvas på detta sätt resultat och diskussion för att skapa en mer samlad bild. Som avslutning ges i kapitel 6 en generell diskussion och slutsats där det slutgiltiga ramverket arbetas fram och presenteras.
2 Metod
Studien för denna uppsats har i princip genomgått fem faser: i) val av ämne, ii) litteraturgranskningsfasen, som löpt parallellt genom i stort sett hela arbetet, iii) genomarbetning av ramverket, iv) intervjuer för att verifiera, vikta och delvis komplettera innehållet i ramverket och slutligen v) en sammanställande analys och diskussion utifrån det insamlade materialet.
Att hitta akademiskt utförda undersökningar i ämnet kritiska framgångsfaktorer inför ett SOA-projekt har varit svårt. Vårt intresse riktades därför mot den större mängd litteratur som behandlar implementeringar av affärssystem. Vi valde, som nämnts i introduktionskapitlet, att använda ramverket framtaget av Magnusson et al. (2004), innehållande faktorer som bör vara väl genomtänkta för att ett affärssystems- implementeringsprojekt ska bli lyckat. Ramverket har sedan, om än i något omarbetad form, varit den huvudsakliga utgångspunkten för de intervjuer som ingått i studien.
För att få en uppfattning om ifall ramverket verkligen kunde vara intressant för vår studie utförde vi en öppen intervju med vår handledare på Zystems by Semcon.
Intervjun bör ses som en informantintervju, då syftet med den var att ge oss en bättre förståelse för arbetet med SOA-implementeringar och för hur det valda ramverket skulle kunna passa in, så att vi skulle vara bättre förberedda inför kommande respondentintervjuer. Informantintervjuers syfte är just att fungera som ett verktyg för forskaren så att denne, eller som i vårt fall dessa, kan skapa sig en stabil empirisk grund. Informanten måste inte nödvändigtvis själv ingå i sådan verksamhet som ska studeras men ska vara väl insatt i ämnet (Holme & Solvang, 1997).
Informantintervjun utfördes under informella former i Zystems by Semcons lokaler i Göteborg. Ingen inspelningsutrustning användes, utan anteckningar fördes under tiden. Alla de tre författarna deltog i intervjuandet, som utfördes som ett samtal runt var och en av faktorerna i det aktuella ramverket. Anledningen till att vi valde bort inspelning av intervjun berodde till stor del på att vi ansåg det vara enkelt att i efterhand ta upp det som vi inte fått med från själva intervjun, då personen i fråga fanns tillgänglig i vår omedelbara närhet. Valet av informant gjordes utifrån hans kunskaper i och erfarenheter av SOA samt hans kontakter med företag som påbörjat ett SOA-arbete i någon form. Intervjun pågick under cirka en timmas tid. Analysen av intervjun resulterade i att ramverket omarbetades i viss mån. Det omarbetade ramverket har sedan utgjort grunden för respondentintervjuerna.
Efter utförd litteraturgranskning och informantintervju skapades ett intervjuunderlag.
Intervjun berörde grovt sett ämnena företags- och projektledning, projekthantering, organisationsfrågor samt för SOA nödvändigt tekniskt stöd, eftersom ramverket låg som grund till strukturen. Intervjuunderlaget finns presenterat i bilaga 1. Som komplement till detta intervjuunderlag skapades ett stödjande frågeformulär som respondenterna fyllde i under intervjuns gång.
Totalt utfördes sex stycken respondentintervjuer, som vardera pågick i cirka en och en halv timma. Cirka 70 procent av tiden användes till att diskutera faktorerna i ramverket. Resterande tid gick i huvudsak till frågor runt deras spontana angivelser av framgångsfaktorer för SOA-projekt, samt till presentation av respondenterna. Två av de tre första intervjuerna var gruppintervjuer, båda gångerna med två respondenter närvarande. Vid de tre första intervjuerna deltog alla tre författarna till denna rapport,
vid de tre senare deltog bara två. Alla tre ledde någon intervju, med andra ord har inte samma person ställt frågorna vid varje intervjutillfälle. Intervjuerna har i relativt hög grad följt ordningen i intervjuunderlaget. De genomfördes i respektive respondents företags lokaler och utfördes alla under loppet av två veckor i slutet av april 2007.
Samtliga intervjuer spelades in och lagrades digitalt för att sedan transkriberas.
Materialet har sedan sammanfattats och sammanställts i tabellform tillsammans med intressanta citat för att lättare kunna bearbetas och slutligen presenteras i resultatkapitlet.
Respondentintervjuernas syfte är att få tillgång till åsikter hos personer som ingår i det studerade fenomenet (Holme & Solvang, 1997). I vårt fall handlade det därmed om personer som deltar i projekt som i någon form har anknytning till SOA. För ändamålet att samla information om hur personer som arbetar i SOA-projekt ser på de olika faktorerna i vårt omarbetade ramverk valde vi att genomföra respondent- intervjuerna i form av semistrukturerade djupintervjuer. En semistrukturerad intervju lämnar utrymme för intervjuaren att styra intervjun åt ett visst håll efter respondentens svar, samtidigt som förutbestämda frågor kan följas i en viss ordning (Björklund &
Paulsson, 2003). Valet av semistrukturerad intervju baserades på kombinationen av att vi ville höra respondenternas åsikter om de olika faktorerna och därför var tvungna att tydligt styra intervjun dit, samtidigt som vi önskade att få så fria synpunkter som möjligt om respektive faktor. Respondenterna fick inför diskussionen angående respektive faktor en av oss mycket kortfattad, skriftlig beskrivning för att definiera dess innebörd. Dessa definitioner är i grunden inte våra egna utan tagna från det ramverk av Magnusson et al. (2004) som varit vår utgångspunkt. Endast nödvändiga ändringar för att passa för diskussioner om SOA har gjorts i utgångsläget. Vi vill här vara tydliga med att definitionerna har sitt ursprung hos Magnusson et al. då vi inte kommer att skriva ut källan i samband med att definitionerna används genom rapporten. Parallellt med den muntliga intervjun fick respondenterna fylla i ett mindre frågeformulär för att det skulle hjälpa oss i jämförelsen av intervjuerna under analysfasen. På så sätt tvingades respondenterna att sammanfatta vissa av sina tankar i mer konkreta ordalag.
Respondenterna fick vi kontakt med via personal på Zystems by Semcon. Alla utom en hade för närvarande ett nära samarbete med Zystems by Semcon eller var själva anställda där. Den förstnämnde hade tidigare ingått i ett samarbete med företaget.
Företagen som de olika respondenterna representerar är alla svenska, börsnoterade bolag, men skiljer sig för övrigt åt. De varierar såväl storleks- som spridningsmässigt.
Något existerar endast inom landet medan andra finns utspridda över världen. Vissa tillhör tillverkningsindustrin medan andra tillhör tjänstesektorn. Den enda gemensamma nämnaren i valet av företag är att de i någon grad kommit igång med arbetet med tjänsteorienterad arkitektur. Alla respondenter representerade IT- organisationen i respektive företag, men hade olika professioner. Spridningen i företagstyper och intervjupersonernas respektive professioner beror på problemen med att hitta företag som på allvar påbörjat någon form av tjänsteorienterade projekt.
2.1 Vetenskapligt angreppssätt
Valet av kvalitativ insamlingsmetod för denna studie passar in på det konstruk- tivistiska synsättet, som enligt Sohlberg och Sohlberg (2002) innebär en strävan att skapa förståelse för en fråga eller ett ämne. En exakt upprepning av studien är knappast möjligt att genomföra, vilket även det passar in i det konstruktivistiska
synsättet. Den positivistiska synen med krav på absolut objektivitet ansåg vi inte vara möjlig att följa, med tanke på det kvalitativa metodvalet. Det relativistiska synsättet, att det över huvud taget inte går att skapa en objektiv bild och som strävar efter att framställa resultatet utifrån så många vinklar som det anses möjligt, kändes inte heller rimlig (Sohlberg & Sohlberg, 2002).
Utifrån valet av kvalitativ insamlingsmetod och med tanke på den relativt starka tidsbegränsning som gällde för studien valde vi dessutom att huvudsakligen arbeta utifrån ett kvalitativt perspektiv. Förhoppningen var att vi genom ett fåtal semi- strukturerade djupintervjuer skulle kunna skapa en intressantare bild än vad någon kvantitativ forskningsmetod skulle kunna ge. Dessutom skulle det vara svårt att få ihop ett tillräckligt stort antal undersökningsobjekt för en kvantitativ studie, då SOA ännu är sällsynt i svenska företag. Backman (1998) beskriver det kvalitativa perspektivet som att ”Intresset förskjuts mot att studera hur människan uppfattar och tolkar den omgivande verkligheten…” (s. 47) istället för att försöka separera människan från omvärlden och försöka ge en objektiv beskrivning av den. Detta perspektiv passar väl överens med den ansats vi haft med vårt kvalitativa metodval. I de genomförda intervjuerna är det respondenternas personliga upplevelser och åsikter som har efterfrågats. Den kvalitativa datainsamlingen kombinerades med en mindre del kvantitativ datainsamling, med förhoppningen att det skulle kunna hjälpa till att förtydliga eventuella mönster i intervjumaterialet. Genom att kombinera de båda forskningsmetoderna finns det en möjlighet att erhålla ett tydligare resultat (Holme &
Solvang, 1997).
Studien har utförts med ett induktivt arbetssätt. Det innebär att forskaren samlar in en större mängd vanligen kvalitativ data inom ramen för intresseområdet. Utifrån dessa data försöker forskaren sedan skapa sig en bild av problemområdet som i sin tur ska ligga till grund för eventuella slutsatser. Alternativet hade varit det deduktiva angreppssättet där forskaren till en början utgår från en teori för att kunna ställa en hypotes. Hypotesen testas sedan utifrån logiska mönster eller sammanhang för att se huruvida den gäller eller ej. Vid induktion står individens sätt att tolka sin omgivning i fokus, vilket stämmer överens med vårt kvalitativa metodval, medan vetenskapen är utgångspunkten i det andra (Backman, 1998).
2.2 Tillförlitlighet
En studies tillförlitlighet brukar anges i termerna validitet och reliabilitet. Björklund och Paulsson (2003) skriver att validitet handlar om att rätt saker mäts. Med reliabilitet menas hur korrekt själva mätningen kan anses vara. De väljer att illustrera begreppen med att kasta pil, vilket illustreras i figur 1, och skriver att:
”Hög reliabilitet fås om pilarna kommer samlat och hög validitet fås om man träffar mitten av tavlan. Hög validitet och reliabilitet samtidigt innebär att man både träffar mitt i tavlan och att alla pilarna kommer samlat.” (Björklund & Paulsson, 2003, s.60)
Låg validitet, Låg validitet, Hög validitet, låg reliabilitet. hög reliabilitet. hög reliabilitet.
Figur 1: Illustration av validitets- och reliabilitetsbegreppen med hjälp av en piltavla.
(Källa: Björklund & Paulsson, 2003, s.60)
Med tanke på att datainsamlingen utfördes med en rad intervjuer som följde samma intervjuunderlag med ramverket som utgångspunkt, så kan reliabiliteten i det avseendet anses vara tillfredsställande. Dock finns det en risk med den valda intervju- formen att vi varit lite mer ledande i frågorna ju senare i turordningen en intervju har legat. Vi fick inte alltid heller i varje intervju utvecklande svar på alla delar i ramverket. Största bristen i reliabiliteten anser vi själva vara att de olika intervjupersonerna arbetade i sinsemellan olika professioner. De var dock alla väl insatta i SOA:s problemområden. En av dem hade arbetat med tjänsteorienterat arkitekturtänkande i mer än tio år, vilket i dessa sammanhang ska ses som mycket lång tid. Ett annat problem var att respondenterna representerade skilda typer av organisationer med olika förutsättningar. Det påverkar möjligheterna för hur en SOA- implementering kan genomföras i organisationen. Vi anser ändå inte att det har en avgörande negativ inverkan på resultatet, då de faktorer som ingår i ramverket är avsedda att gälla oavsett hur organisationen är beskaffad.
Gällande validiteten anser vi att det kan ses som ett problem att alla intervju- personerna hörde hemma i IT-organisationerna, trots att studien riktar in sig på de faktorer som i huvudsak berör affärssidan och organisationen som helhet. Troligen speglar dock detta verkligheten ganska väl, i det avseendet att SOA-projekt, trots sin verksamhetsövergripande karaktär, oftast verkar påbörjas på IT-organisationens initiativ, precis som Linthicum (2007) varnar för.
Figur 2: Studiens tillförlitlighet.
För att knyta an till figur 1 ovan skulle tillförlitligheten i denna studie, enligt vår mening kunna illustreras som figur 2 här bredvid. Varken validiteten eller reliabiliteten är helt tillfredsställande, men kan ändå anses ligga på en acceptabel nivå.
2.2.1 Källkritik
Det första större problem vi stötte på under arbetets gång var att få grepp om vad SOA egentligen innebär. Litteraturen på området är inte alldeles entydig och dessutom inte särskilt väl akademiskt förankrad. Den teoretiska ram för SOA som presenteras i arbetet ska därför ses som en beskrivning av vår tolkning av SOA utifrån den granskade litteraturen. Ett visst kommersiellt intresse kan ligga bakom delar av den litteratur som använts, men i de fall som inte utgör akademiskt granskad och godkänd
litteratur, har vi försökt hålla oss till författare som vi uppfattat vara etablerade namn inom ämnesområdet.
Det stora antalet faktorer i ramverket, det vill säga tretton stycken, har dessutom medfört att litteraturgranskningen av ämnesområdena för respektive faktor blivit relativt ytlig. Vi har bara kunnat skrapa lite på ytan för att kunna presentera en bild av vad de olika faktorerna innebär. Det finns därmed en risk att en ibland ensidig bild presenteras av ett ämne, trots att det måhända finns olika synsätt därom. När det gäller ramverkets faktorer har vi dock uteslutande försökt att hålla oss till litteratur som blivit akademiskt godkänd eller av i systemvetarutbildningen ingående kurslitteratur.
3 Teoretisk ram
Följande kapitel redovisar den teoretiska ram som, efter litteraturgranskningen, ligger till grund för uppsatsen. Inledningsvis ges en redovisning om vad SOA är. Det ska, då bilden i litteraturen inte är helt entydig, ses som en beskrivning av den syn på SOA som arbetet stödjer sig på. Efterföljande avsnitt om affärssystem ska inte ses som en fullständig redovisning av ämnet. Där tas bara de delar upp som visar varför det är relevant att utgå från en modell för affärssystem när ämnet som ska undersökas handlar om SOA. Valet av modell blir beskrivet i efterföljande kapitel 4. Där redovisas hur modellen för studien valts och arbetats om för att kunna användas i själva undersökningen, samt vad de olika delarna i modellen handlar om.
3.1 Tjänsteorienterad arkitektur
Visionen av vad IT kan göra för organisationer och företag har på senare år blivit mer och mer sofistikerad och ambitiös. Organisationers högsta ledning har högre förväntningar på IT och gör numer mycket större investeringar än tidigare, trots IT kraschen runt år 2000. Att IT-chefen på större företag idag ofta är innehavare av en av de mer inflytelserika posterna är ännu ett uttryck för det. Bland resultaten av denna utveckling av IT inom affärsvärlden har disciplinen Enterprise Achitecture Planning (EAP) varit. Det är en process som fokuserar på design och implementering av IT på ett sätt som ska möta målen och förväntningarna från ledningen samtidigt som det ska säkra effektivitet och kontinuitet av själva IT-systemen. För att kunna tillmötesgå kraven från EAP så har Web Services kommit att spela en stor roll. Det är en teknik som möjliggjort interoperabilitet och förbättrad samverkan mellan teknologin och affärsprocesserna. Web Services har i sin tur haft en stor påverkan på utvecklingen av tjänsteorienterade arkitekturer (SOA), som är den senaste fasen av EAP. SOA har potential att leverera förbättringar inom kostnadskontroll, affärsrörlighet och affärsprocesseffektivitet, vilket varit det stora målet för EAP (Pulier & Taylor, 2006).
Magoulas och Pessi (1998) talar om att många organisationer står inför en situation där utformningen av verksamhetens framtida strategi gällande informationssystems- arkitekturen måste skapas. Anledningen till detta är de problem och den kravbild som förekommer i fler och fler organisationer. Organisationer förändras kontinuerligt när verksamheter decentraliseras, förnyas och omprövas och det ställs allt högre krav på effektiva och snabba anpassningar till den dynamiska affärsvärlden. För att klara dessa behov ställs det allt högre krav på informationssystemarkitekturen. I många större organisationer lyfts det fram problem med informationssystemen, som karaktäriseras som exempelvis ”systemöar”, ”rigida strukturer” eller ”spagetti- strukturer”. Problem förknippade med sådana strukturer kan innefatta oöverblick- barhet, förändringströghet, inflexibilitet, ineffektiv samverkan, otillgänglig information och höga förvaltningskostnader. Det är tydligt att organisationer lägger en stor vikt vid strategiska arkitekturella och infrastrukturella frågeställningar.
Anledningen till att den typen av frågeställningar prioriteras så högt är den växande önskan att få ett ökat värde för de pengar som investerats i IS/IT samt att kunna öka konkurrenskraften genom en effektivare användning av IS/IT. Trots att Magoulas och Pessis utlåtande har ganska många år på nacken vid det här laget, så är ämnet fortfarande lika aktuellt. Med de möjligheter som SOA kan erbjuda finns det numer, om det görs på rätt sätt, en öppning mot en fungerande lösning.
Sättet som organisationer vill arbeta, göra affärer, marknadsföra sig och utvecklas är, som redan nämnts, dynamiskt och under konstant förändring. Utifrån de modifieringarna kommer efterfrågan på att IS/IT ska stödja de nya eller förändrade processerna. Det kräver en mer eller mindre konstant förändring av applikationsfloran och informationssystemarkitekturen. Tanken med SOA är att organisationer inte ska behöva uppfinna hjulet på nytt varje gång en förändring sker utan istället kunna organisera sina applikationer och system för att de lättare ska kunna återanvändas, underhållas och stödja delning av data och resurser (Erl, 2005). En traditionell informationssystemarkitektur är ofta mindre förändringsflexibel och instängd av sina nätverksprotokoll, hårdvaruplattformar och programmeringsspråk, på samma sätt som ombyggnationen av en byggnad ofta begränsas av dess ursprungliga struktur (Pulier &
Taylor, 2006). Den hårda kopplingen av system i en traditionell informationssystem- arkitektur har gjort dem dyra och tidsödande att förändra. Det har resulterat i svårigheter att följa den höga förändringstakt som affärsprocesser tenderar att ha. En tjänsteorienterad arkitektur (SOA) är ett sätt att angripa informationssystem- arkitekturen genom att exponera de ingående beståndsdelarna som tjänster. Resultatet är en distribuerad IS/IT-miljö med en hög grad av interoperabilitet mellan systemen.
En väl utförd SOA-implementering skapar möjlighet till att på kortare tid och till en lägre kostnad kombinera, omorganisera och återanvända de ingående mjukvaru- delarna. Tack vare SOA:s flexibla och förändringsbara struktur så blir det möjligt för företagsledare att modifiera sina affärsprocesser utan att vara lika begränsade och tidsberoende av IT som traditionella arkitekturer kan vara. Genom att göra det relativt enkelt att förändra hårdvara, mjukvara, och den fysiska placeringen av systemen så kan företagsledare arbeta mot sina mål med färre restriktioner än tidigare. På så sätt möjliggör det för företag att genom SOA skaffa sig konkurrensfördelar (Pulier &
Taylor, 2006).
3.1.1 Definition av SOA
Tjänsteorienterade arkitekturer (SOA) ska ses som ett affärsmässigt synsätt samtidigt som det också är ett tekniskt förhållningssätt med metodologier för dem båda. SOA har växt fram för att kunna möjliggöra för affärsverksamheter att ägna sig åt beslut och förändringar rörande affärsfrågor med en IT-organisation som på ett bättre sätt kan stödja, istället för att begränsa eller styra besluten (Erl, 2005). The Organization for the Advancement of Structured Information Standards (OASIS, 2006) beskriver SOA som ett paradigm för att organisera och dra nytta av distribuerade resurser som kan vara kontrollerade av olika ägare. Hurwitz, Bloor, Baroudi och Kaufman (2007) definierar SOA som en arkitektur för att bygga affärsapplikationer genom att använda en uppsättning löst kopplade och inkapslade komponenter som är ordnade för att leverera en väldefinierad servicenivå genom sammanlänkning av affärsprocesser. Erl (2005) skriver att informationssystemet i en tjänsteorienterad arkitektur, fungerar genom en samling av tjänster, där varje tjänst kan interagera med en eller flera andra tjänster för att kunna utföra en viss uppgift. Funktionaliteten hos en viss enskild tjänst kan bestå av en kombination av ett flertal lågnivåfunktioner, vilka i en tjänste- orienterad arkitektur inte betraktas som tjänster i sig själva.
I en tjänsteorienterad arkitektur så är de affärsstödjande applikationerna sammansatta av en uppsättning av byggstenar som benämns som komponenter. En del komponenter kan vara köpta standardprodukter, andra kan vara egenutvecklade eller anpassade. Det är informationssystemarkitekturen och affärsprocesserna som definierar vilka mjukvarukomponenter som ska användas samt hur de komponenterna
ska interagera med varandra. En eller flera komponenter som verkar tillsammans för att lösa en specifik eller generell uppgift benämns som en tjänst. Det går att se på tjänster med två olika synsätt, dels ur ett affärsperspektiv som med affärslogik beskriver vad tjänsten ska göra samt hur den ska interagera med andra tjänster, dels ur ett implementeringsperspektiv som tekniskt beskriver vilka de ingående komponenterna är samt hur de ska utföra tjänsten (Hurwitz et al., 2007).
Erl (2005) beskriver SOA som en realisering av intressedelningsprincipen (separation of concerns, SOC). En traditionell affärsarkitektur kan betraktas som två lager, ett affärsprocesslager (Business Process Layer) och ett applikationslager (Application Layer). Applikationslagret ska stödja affärsprocesserna och måste följas åt och anpassas till förändringar i affärsprocesserna. Affärsprocesslagret och applikations- lagret har således i den traditionella affärsarkitekturen beroenden till varandra. Utifrån intressedelningsprincipen introducerar Erl ett tjänstegränssnittslager (Service Interface Layer) mellan affärslagret och applikationslagret. De kopplingar och beroenden som tidigare fanns, ersätts av det gemensamma tjänstegränssnittslagret. Han väljer att dela upp tjänstegränssnittslagret i tre underlager. Ett lager som bildar kopplingen mot affärsprocesslagret (Business Service Layer), ett lager som bildar en koppling mot applikationslagret (Application Layer) och slutligen ett styrlager (Orchestration Layer) som styr och hanterar tjänsterna inuti tjänstelagret. En variant av Erls modell presenteras i figur 3.
Figur 3: Företagsarkitektur baserad på SOA. (Inspirerad av: Erl, 2005 )
3.1.2 Tjänster
En tjänsts omfattning bör vara relativt liten och inte erbjuda en alltför omfattande funktionalitet för att den lättare ska kunna användas och återanvändas som byggsten i olika sammanhang. SOA:s användning och återanvändning av tjänster har potential att underlätta utvecklandet av nya applikationer och förenkla förändringar av befintliga system (Hurwitz et al., 2007). Booth et al. (2004) på World Wide Web Consortium (W3C) definierar en tjänst som:
... an abstract resource that represents a capability of performing tasks that represents a coherent functionality from the point of view of provider entities and requester entities. To be used, a service must be realised by a concrete provider agent. (Avsnitt 2.3.2.10.1)
För att realisera det tjänsteorienterade konceptet måste tjänsterna följa ett antal principer. Enligt Erl (2005) krävs det att tjänsterna ska kunna dela ett formellt kontrakt och ha en abstrakt underliggande logik. De ska vara återanvändbara, löst kopplade, komponerbara, autonoma, tillståndslösa och upptäckbara. Formella kontrakt mellan en tjänstekonsument och en tjänsteleverantör används exempelvis för att specificera en tjänsts funktionalitet, tillgänglighet, prestanda, behörigheter och ekonomiska debitering (Pulier & Taylor, 2006). En tjänsts underliggande logik ska vara dold och abstrakt för att lättare kunna vara utbytbar. Abstraktionslagret döljer de ingående detaljerna om hur tjänsten rent tekniskt fungerar samt vilken hårdvara och vilket programspråk som använts (Booth et al., 2004).
För att en tjänst ska vara praktiskt återanvändbar krävs det att den både är flexibel och har en väl avgränsad funktionalitet som ändå är av en såpass allmän karaktär att den kan komma till användning i andra, nutida eller framtida sammanhang. Med flexibilitet menas att tjänsten bör kunna hantera scenarier som ligger nära dess grundläggande funktionalitet. Exempelvis bör en tjänst som utför kreditkortskontroller kunna hantera alla de vanligaste kreditkorten istället för att det skapas en tjänst för varje typ av kort (Pulier & Taylor, 2006).
Lösa kopplingar är ett angreppssätt för att minska beroenden mellan mjukvaru- komponenter. Traditionella mjukvarumiljöer med hårda kopplingar innebär att komponenterna kommunicerar och utbyter information genom proprietära interface och nätverksprotokoll. Det gör det svårare, dyrare och mer tidskrävande att byta ut någon av de ingående komponenterna (Pulier & Taylor, 2006). Lösa kopplingar innebär också att tjänsterna och den underliggande tekniska lösningen är medvetet frånskilda varandra så att själva tjänsten inte har någon programkod som direkt är relaterad till hanterandet av IT-miljön. På grund av delningen så kan komponenter bindas ihop dynamiskt i realtid och bete sig som de vore en enda hårt kopplad applikation. Lösa kopplingar har möjliggjorts av diverse olika tekniker och komponenter så som exempelvis Enterprise Service Bus (ESB), SOA repository, SOA registry och Web Services (Hurwitz et al., 2007).
Att tjänster ska vara komponerbara innebär att de ska kunna representera logik från alla typer av källor, inklusive andra tjänster. Den huvudsakliga orsaken till att implementera denna princip är för att tillse att tjänster skapas så att de, vid behov, kan deltaga som medlemmar i andra tjänstekompositioner (Erl, 2005).
För att en tjänst ska vara autonom krävs det att logiken som tjänsten exponerar endast existerar inom ett explicit område. Det tillåter att tjänsten kan utföra självreglering över allt som den processar. Det eliminerar också beroenden till andra tjänster som annars kan hindra dess införande och vidare utveckling. Det är väsentligt att ta hänsyn till tjänsteautonomi när beslut kring hur applikationslogik ska delas upp i tjänster och vilka operationer som ska grupperas tillsammans inom en tjänst (Erl, 2005).
Tillståndslöshet innebär att varje meddelande som konsumenten av tjänsten skickar måste innehålla all information som behövs för att tjänsteleverantören ska kunna processa den. En sådan restriktion gör tjänsten mer skalbar då tjänsteleverantören inte behöver spara information om olika tillstånd och varje förfrågan kan ses som generisk. Då det inte finns några mellantillstånd att hålla reda på, så ökar även tillförlitligheten och återhämtningen från mindre fel blir då lättare att hantera (He, 2003).
Att en tjänst är upptäckbar innebär att konsumenten av tjänsten någonstans måste kunna få information om exempelvis vad tjänsten kan utföra, vilka data som behövs, hur anslutningen går till samt var tjänsten finns. Det finns olika tekniker och standarder för att möjliggöra en tjänsts upptäckbarhet. Ett exempel är Web Services Description Language (WSDL) som beskriver exakt vad en Web Service gör och hur den används. Universal Discovery, Description, and Integration (UDDI) är en standardiserad katalog som beskriver vilka Web Services som finns tillgängliga för användning (Pulier & Taylor, 2006).
Utvecklingsprojekt för tjänsteorienterade arkitekturer är på ytan lika andra projekt för distribuerade applikationer. Web Services designas, utvecklas och driftsätts parallellt med standardkomponenter på ett liknande sätt. Under ytan finns dock skillnader som gör att traditionella projekt och utvecklingscykler kräver vissa modifieringar. Erl (2005) förespråkar användandet av olika abstraktionslager vid identifiering, modellering och strukturering av tjänster. De abstrakta tjänstelagren är applikationstjänstelagret, affärstjänstelagret och styrningslagret. En organisations logik kan då delas upp i två huvudsakliga områden, affärslogik och applikationslogik.
Tjänster kan därefter modelleras för att representera den ena eller båda typerna av logik. Erl (2005) samt Leymann, Roller och Schmidt (2001) menar vidare att separata tjänstelager är en nödvändighet för att uppnå organisationsövergripande lösa kopplingar hos tjänsterna. När individuella samlingar av tjänster representerar bolagsspecifik affärslogik och teknologispecifik applikationslogik så blir de befriade från de direkta beroenden som annars uppstår. Det tillåter representationen av affärsprocesslogiken att utvecklas oberoende av den tekniska applikationslogiken som är ansvarig för dess exekvering, vilket medför ett löst kopplat förhållande mellan affärs- och applikationslogik.
Hur tjänster som ska representera applikationslogiken ska modelleras är beroende av huruvida det är arvssystem (legacy systems) eller om det är ny logik som utvecklas för att stödja tjänster. Existerande ärvda system kan eventuellt påtvinga ett antal restriktioner, begränsningar och förändringar i SOA-miljön som behöver beaktas vid skapandet av tjänsterna (Erl, 2005).
3.1.3 Web Services
Enligt Erl (2005) så stödjer Web Services på ett naturligt sätt kontrakt, lösa kopplingar, abstraktion och kombinerbarhet. De egenskaperna gör Web Services till ett bra val för att realisera SOA-konceptet. Hurwitz et al. (2007) påpekar att Web Services absolut inte är ett krav för en tjänsteorienterad arkitektur då det även finns andra tekniker för genomförandet, exempelvis DCOM (Distributed Component Object Model) eller ORB (Object Request Broker) baserat på CORBA (Common Object Request Broker Architecture). Web Services ökande popularitet som standard har dock fungerat som en motor och möjliggjort för ett ökat antal SOA-
implementeringar och kan på sikt bidra till att öka dess popularitet samt göra arkitekturen tillgänglig för ett större antal organisationsformer. Hurwitz et al.
poängterar samtidigt att användandet av Web Services i sig inte automatiskt gör arkitekturen tjänsteorienterad.
Web Services består av ett utbyte av så kallade SOAP-meddelanden över ett antal olika protokoll, ofta HTTP-protokollet. SOAP är en specifik typ av XML-meddelande i ett standardiserat format som är fastställt av W3C standardiseringsorgan. Web Services baseras på en mjukvaruarkitektur bestående av fråga och svar (request and respons). Konsumenten av en Web Service anropar leverantören av tjänsten genom att skicka ett SOAP-anrop. Web Servicen utför den tjänst som efterfrågades och svarar med att skicka ett SOAP-meddelande i retur. Varje Web Service består av en konsument och en leverantör. Det är möjligt för ett stort antal olika Web Service konsumenter att ansluta sig till och nyttja samma tjänst, oavsett vilket operativsystem eller programmeringsspråk som används. Så länge konsumenten anropar tjänsten genom att använda SOAP i standardiserat format så gör det ingen skillnad vilken hårdvara, operativsystem eller programspråk som konsumenten använder (Booth et al., 2004).
För att kunna beskrivas utåt så har varje Web Service ett Web Service Description Language (WSDL) dokument som förser den potentiella konsumenten med förklaringar om hur tjänsten fungerar samt hur den kan få åtkomst till tjänsten. WSDL beskriver hur konsumenten ska skapa en SOAP-fråga som anropar en specifik Web Service. Om en utvecklare vill skapa en mjukvara som nyttjar en Web Service så behövs endast WSDL-dokumentet som underlag, vilket betyder att tjänster både kan skapas och nyttjas utan att de olika utvecklarna behöver kommunicera med varandra (Booth et al., 2004). Universal Dicovery, Description and Integration (UDDI) används för att presentera vilka Web Services som finns tillgängliga inom ett visst nätverk.
UDDI är ett plattformsoberoende XML-baserat register som fungerar ungefär som en telefonkatalog för Web Services (OASIS, 2006).
I motsats till datorsystem vars samverkan är hårt kopplad genom proprietära gränssnitt, så är Web Services löst kopplade. Det möjliggör för systemadministratörer att med relativt enkla medel byta ut eller fysiskt flytta datorsystem som kör Web Services. Lösa kopplingar innebär också att förändringar som görs i tjänsten hos tjänsteleverantören inte nödvändigtvis leder till förändringar hos tjänstekonsumenten.
Lösa kopplingar hos Web Services har därför potential att spara tid och pengar genom att skapa interoperabilitet mellan datorsystem samt att öka en organisations produktivitet genom att möjliggöra för snabbare förändringar i affärsprocesserna (Booth et al., 2004). Web Services kan skapas på två grundläggande sätt. Mjukvaru- utvecklare kan exponera redan existerande legacy-system eller alternativt skapa helt nya applikationer som från början avses att bli Web Services, enligt Pulier och Taylor (2006). De anger också ett antal begränsningar hos Web Services:
• Web Services är ett hjälpmedel som underlättar exponeringen av ärvda system men kan inte ersätta dem. Det ärvda systemets ursprungliga funktionalitet förändras inte men kan genom Web Services nyttjas på andra sätt.
• Web Services kan inte fungera tillförlitligt och säkert på egen hand, då de endast är en uppsättning av standarder, inte ett komplett mjukvarupaket.
• Web Services har fått kritik för att prestanda kan bli lidande i tidskritiska miljöer.
På grund av att stora mängder av den mjukvara som används idag är utvecklad på tiden före Web Services ankomst, så är ofta de tjänster som används baserade på legacy-system som exponerats med hjälp av Web Services. Att exponera som en Web Service innefattar att göra det möjligt för den äldre mjukvaran att ta emot och svara på SOAP-anrop. De flesta större leverantörer av äldre system och mjukvara tillhanda- håller idag verktyg som möjliggör för utvecklare att enklare komma åt legacy- systemens inbyggda funktionalitet och exponera dessa som Web Services (Pulier &
Taylor, 2006). Pulier och Taylor illustrerar hur en tjänst kan se ut och hur den kan användas genom följande förenklade exempel, se figur 4. Ett försäkringsbolag har en stordator som hanterar en databas innehållande sina kunders individuella kreditinformation. Antag att försäkringsbolagets CRM-system (customar relationship management) behöver tillgång till kreditinformationen för att underlätta telefonförfrågningar. CRM-systemet skickar då ett SOAP-meddelande till den Web Service som är exponerad på stordatorn och begär Sven Svenssons kredit. Web Servicen tar emot meddelandet, hämtar informationen i stordatorn och svarar genom att översätta informationen till ett SOAP-meddelande som sedan returneras till CRM- applikationen.
Figur 4: Exempel på hur en Web Service kan se ut och användas.
(Inspirerad av Pulier & Taylor, 2006)
3.1.4 Register och repository
Möjligheten att registrera, upptäcka och styra tjänster är ett väsentligt krav för implementeringen av en tjänsteorienterad arkitektur. Det kan finnas svårigheter att finna stöd i organisationen för detta i tidiga stadier av en SOA-implementering där antalet skapade tjänster fortfarande är lågt. Antalet tjänster brukar emellertid växa med tiden och när antalet går upp så är användandet av centrala resurser kritiskt för att kunna hantera åtkomst, kontroll av tjänsters metadata och tillhörande artefakter. Ett tjänsteregister tillhandahåller de möjligheterna och är en infrastrukturell nyckel- komponent som fungerar som en hörnsten i utrullningen av en tjänsteorienterad arkitektur (Erl, 2005; Sun Microsystems, 2005). Enligt Windley (2006) så är registret
det primära verktyget för organisationer när det gäller hantering och kommunicering av governance-artefakter samt automatisering av vissa governance-aktiviteter. Ett register tillhandahåller en central referens och förteckning av tjänster. Den kan betraktas som en plats där tjänsterna i en organisation kan annonseras av leverantören och upptäckas av konsumenten. Registret fungerar likaså som en kontrollpunkt för styrning av tjänstetillgänglighet, versionshantering och kravhantering.
Det är lämpligt att vid nyttjande av ett register utreda och dokumentera ansvarsfrågor som exempelvis, vem som har kontroll över SOA–metadata, vem ansvarar för de olika tjänsterna, vilka är utvecklare, vem ansvarar för affärsprocesserna, och så vidare.
En organisation måste klargöra vem som är ansvarig för vad med hänsyn till de principer som råder. Om inte ansvarsfrågorna utreds och dokumenteras finns det risk att utlovade fördelar med exempelvis återanvändning, tjänstekatalog och affärsrörlighet uteblir (Sun Microsystems, 2005; Erl, 2005).
Universal Description, Discovery and Integration (UDDI) är ett standardiserat register (registry) från Organization for the Advancement of Structured Information Standards (OASIS) som stöds av ett flertal stora mjukvaruleverantörer. Syftet med UDDI är att centralt kunna registrera Web Services och skapa en allmän beskrivning (Universal Description) som möjliggör upptäckbarhet, sökning och integration av tjänster (OASIS, 2006).
Ett repository är en lagringsplats för mjukvara. För att framgångsrikt kunna styra och hantera mjukvaruutvecklingsprocessen används ett repository som förråd för all mjukvara med tillhörande komponenter. Ett repository stöder ofta versionshantering, specifikationer, historisk information och olika typer av metadata som tillhör mjukvaruutvecklingsprocessen (Jardim-Goncalves, Grilo & Steiger-Garcao, 2006;
Hurwitz et al., 2007).
En del mjukvaruleverantörer paketerar sina registry och repositoryprodukter som en enda produkt vilket kan bidra till en viss begreppsförvirring (OASIS, 2006). När en utvecklare skapar en tjänst så placeras tjänsten i ett repository så att andra kan använda den. Där sparas versioner, historisk information och annan viktig information som rör varje tjänst. Ett repository är statiskt i den meningen att den inte förändras från ett tillfälle till ett annat. Den förändras endast då något nytt läggs till, dock inte i realtid. Ett repository kan ses som att den ligger något utanför den tjänsteorienterade arkitekturen som den stödjer. Tjänsterna introduceras genom ett repository men den är inte aktivt involverad i den dynamiska SOA-verksamheten. Registret hämtar tjänsterna från ett repository och sätter dem i drift. När tjänsternas fysiska placering förändras så är det registrets uppgift att hålla reda på dem. Registret kan även svara och anpassa sig dynamiskt till vissa av kraven från den tjänsteorienterade arkitekturen. Så, trots att de är tätt sammanlänkade så fyller ett register och ett repository olika funktioner (Hurwitz et al., 2007).
3.1.5 Planera för SOA
En tjänsteorienterad arkitektur har till skillnad från traditionella IS-arkitekturer en större fokus på affärsnytta. Affärsmodeller kan beskrivas som modulära processer och kan då tillsammans med IT-systemen brytas ned till komponenter som tillhandahåller återanvändbarhet och modularitet. Att i det här sammanhanget skapa komponenter, är därmed inte bara applicerbart på mjukvarusystem, utan även på affärsenheter tvärs
över företaget och organisationen. Införandet av ett SOA-projekt berör då inte bara implementeringen av IT-infrastrukturen utan resulterar också i en affärsmässig förändringsprocess genom hela verksamheten. Att planera ett införande av en tjänsteorienterad arkitektur kräver att det tas hänsyn till de specifika organisatoriska strukturer och processer som existerar i varje företag och organisation. Det finns ingen optimal plan eller lösning som passar alla scenarier utan att individuella anpassningar behöver göras. Det finns dock en samlad erfarenhet som är snabbt växande och kan hjälpa till med riktlinjer, idéer och best-practices för en projektplans uppläggning och struktur (Bieberstein, Bose, Fiammante, Jones & Shah, 2005).
För att minska riskerna med nya SOA-projekt så bör de startas i liten skala och påbörjas i projekt som inte har någon stor organisatorisk påverkan. En SOA-strategi bör alltså inte innefatta en ”big-bang”-ersättning av den existerande IT-miljön, utan istället vara utformad enligt en progressiv, iterativ och evolutionär införandeplan (Erl, 2005; Bieberstein et al., 2005). Beroende på IT-organisationens mognadsnivå så kan ofta befintliga och existerande organisationsstrukturer omdefinieras och förändras för att stödja ett initialt SOA-projekt (Bieberstein et al., 2005). Projektet ska ledas av en projektgrupp som är tvärfunktionell i sin struktur. Baserat på erfarenheter från stora och medelstora företag så bör projektorganisationen enligt Bieberstein et al. (2005) innehålla följande delar:
• SOA business transformation architecture council: Den här gruppen leder ihopsamlandet av affärskrav, utför analys av affärsdomänen,
affärsprocessanalys samt identifierar de nödvändiga affärskomponenterna, tjänsterna och processmodulerna. Istället för att följa ett strikt top-down angreppssätt så bör gruppen använda ett blandat tillvägagångssätt genom att blanda top-down, bottom-up och meet-in-the-middle metoder för identifiering av lämpliga tjänster. Gruppen säkrar att de definierade tjänsterna motsvarar affärskraven och dess specifikationer. De olika angreppssätten förklaras mer i nästa avsnitt om identifiering av tjänster.
• SOA technical architecture board: Den här gruppen tillser att affärssidan och IT ligger i fas med varandra samt följer industriella och företagsspecifika standarder. De ser även till att exponerade tjänster tekniskt motsvarar kraven för evolution och återanvändbarhet. Medlemmarna bör ha hög teknisk kompetens och vara väl insatta i berörda spjutspetsteknologier och
standardiseringar. De är ansvariga för utformandet av den tekniska planen för hur företagsarkitekturen ska se ut.
• Component design and development centers: Genomför design och utveckling av komponenter och processer samt utför business process modelling (BPM).
Gruppen svarar för leverans av tjänsteorienterad analys och design samt olika testfaser som enhets, integration, system och acceptanstest.
• Operations center: Den här gruppen ansvarar för driften av
tjänstekomponenterna. Här ingår hantering av quality of services (QOS), upprätthålla service level agreements (SLA), säkerhetsaspekter och kostnadsdebitering. Gruppen står även för driftsättning av tjänster samt övergripande systemunderhåll och drift.
En organisation har ofta flera ingångsalternativ vid ett SOA-införande. Valen är kopplade till hur mycket och på vilken nivå som den tjänsteorienterade arkitekturen
tränger in i affärsverksamheten och går att definiera i olika införandenivåer.
Bieberstein et al. (2005) listar följande val:
• Initialt införande: Företag som vill reducera sina risker går till en början igenom en teknisk utvärdering och en beredskapsevaluering som analyserar tekniska och affärsmässiga implikationer. Så småningom så kan de resultaten användas för att bedöma de faktiska organisatoriska konsekvenserna som då kan resultera i ett djupare åtagande att gå mot SOA. Det involverar tidiga pilottester bestående av skapande och exponering av tjänster från
affärsverksamheter som inryms i nya eller existerande applikationer. Dessa tester används för en tidig evaluering av ett flertal beslutspunkter, som exempelvis följande:
o Förmågan att transformera existerande legacysystem kan innefatta tekniska lösningar så som meddelandehantering, adaptrar och kopplingar eller samarbete med leverantörer som kan tillhandahålla produkter för en tjänsteorienterad integration.
o Förmågan att hantera ickefunktionella krav, vilket inkluderar delar som prestanda, säkerhet och ledningsförmåga.
o Den organisatoriska strukturen som krävs för att stödja företagets utveckling, speciellt de som riktar sig mot kompetenshantering och stödjer governance-strukturer.
• Affärsområdesinförande: På denna nivå identifierar företaget ett affärsområde och prioriterar de processer där SOA kan hjälpa till med att öka affärsvärdet.
• Företagsövergripande införande: Denna införandenivå involverar skapandet av en verksamhetssyn baserad på en tjänsteorienterad affärsverksamhet, med prioritering av projekt grundade på affärsvärde, följt av arkitektur och implementeringsfaser. Företagsaktiviteter behöver kategoriseras i separata affärsdomäner och komponenter som utgör affärsverksamheten. En grupp för SOA-governance, med de nödvändiga befogenheterna för att kontrollera, definiera och auktorisera förändringar i företagets tjänster, bör etableras.
• Företags- och partnerövergripande införande: På den här nivån sker det en bred omvandling av existerande affärsmodeller eller driftsättande av nya affärsmodeller som inte bara involverar företaget som helhet, utan även dess samarbetspartners, leverantörer och/eller kunder.
Erl (2005) och Hurwitz et al. (2007) hävdar att några utav de mest kritiska fram- gångsfaktorerna för ett lyckat tjänsteorienterat införande handlar om hur väl projektet följer rådande standarder när det väl ska fasas in i affärs och applikationsdomänerna.
Trots det, så är det vanligaste sättet att mäta ett projekts framgång baserat på hur väl den specifika lösningen uppfyller de förväntade kraven inom en given budget och tidsram. Att kortsiktigt mäta ett SOA-införandes framgång på det traditionella sättet och då eventuellt skapa incitament som äventyrar användandet av förespråkade standarder kan då äventyra den långsiktiga tjänsteorienterade införandeprocessen.
3.1.6 Identifiering av tjänster
Processen att identifiera tjänster inom ett företag, affärsenhet eller organisation består av strategiska metoder som top-down, bottom-upp och meet-in-the-middle, eller en kombination av dessa (Erl, 2005; Bieberstein et al., 2005).
