IT Management Planering av tjänsteorienterad arkitektur

INSTITUTIONEN FÖR TILLÄMPAD IT
IT Management
Arkitekturdesign
TIA005 – VT 2012
Planering av
tjänsteorienterad arkitektur
En studie som behandlar vad företag skall tänkta på gällande den egna
förmågan att åstadkomma en tjänsteorienterad arkitektur innan en implementation av molntjänster
Gruppmedlemmar:
Aurora Karlsson
Henrik Libell
Thomas Zetterlund
Handledare:
Thanos Magoulas
Sammanfattning
Molntjänster har de senaste åren varit en prioriterad investering för organisationer mot bakgrunden av löften om en flexibel kostym för dess informationssystem som snabbt och enkelt
kan anpassas för en föränderlig affärsmiljö. Stora investeringar har genomförts men många
organisationer kämpar fortfarande med att se en nyttorealisering av investeringarna. Det saknas ofta en förståelse för den egna förmågan att hantera potentialen hos en tjänsteorienterad
ansats så det går att utvinna reella konkurrensfördelar. Detta kan ha lett till att organisationer
har fattat förhastade och/eller missriktade beslut. Denna studie undersöker vad organisationer
bör ha i åtanke om de överväger att migrera sina informationssystem till molntjänster.
Studien genomfördes i en orienterande granskning av litteraturen inom forskningsområdet
kombinerat med en ingående granskning av iSOAMM, en etablerad oberoende modell för
analys av organisationers mognadsnivåer för en tjänstebaserad arkitektur. Det terroristiska
perspektivet sammanställdes i en egen modell i syfte att jämföras med empirin. En leverantör
av affärssystem intervjuades för att kunna konkretisera eller falsifiera syntesen av den inhämtade kunskapen.
Resultatet av studien visar på betydelsen av att redan vid planering av en migration av system
till molntjänster, identifiera vilka nyttoeffekter som efterstavas, vilken mognadsnivå organisationen behöver uppnå för att realisera de önskade nyttoeffekterna. Studien belyser vidare
vikten av att kunskapsmässigt konstruera en övergripande förståelse av orsakssambandet mellan den stödjande arkitekturen och den relevanta miljön som den påverkar.
2
Innehållsförteckning
SAMMANFATTNING ........................................................................................................... 2 1. INTRODUKTION ............................................................................................................... 4 1.1 BAKGRUND OCH PROBLEMOMRÅDE ............................................................................................................... 4 1.2 SYFTE OCH FRÅGESTÄLLNING ........................................................................................................................ 5 1.3 BEGRÄNSNINGAR ............................................................................................................................................ 5 1.4 METOD ............................................................................................................................................................ 5 1.5 DEFINITION AV BEGREPP ................................................................................................................................. 6 2. TEORETISKT RAMVERK............................................................................................... 8 2.1 ENTERPRISE ARKITEKTUR ............................................................................................................................... 8 2.1.1 Service-Oriented Architecture ............................................................................................................... 9 2.2 MOLNTJÄNSTER ............................................................................................................................................ 10 2.2.1 För- och nackdelar med molntjänster .................................................................................................. 13 2.3 MIGRATION ................................................................................................................................................... 14 2.3.1 Beslut om att migrera till moln ............................................................................................................ 14 2.3.2 Aktiviteter under migrationen till moln ................................................................................................ 15 2.3.3 Kostnader och risker med molnmigration............................................................................................ 17 2.4 ISOAMM ...................................................................................................................................................... 19 2.4.1 iSOAMM-Modellens Perspektiv ........................................................................................................... 19 2.5 EGEN MODELL ............................................................................................................................................... 27 3. EMPIRI .............................................................................................................................. 28 3.1 DEMOGRAFI .................................................................................................................................................. 28 3.1.1 Bo Orskarsson ...................................................................................................................................... 28 3.1.2 Evry ...................................................................................................................................................... 28 3.2 INTERVJU RESULTAT ..................................................................................................................................... 28 4. ANALYS OCH DISKUSSION ......................................................................................... 32 4.1 EFFEKTORIENTERAD ARKITEKTUR, MOLN OCH MIGRATION .......................................................................... 32 4.2 ARKITEKTURELL MOGNAD ............................................................................................................................ 32 4.3 HOLISTISK SYNTES AV MIGRATIONSKUNSKAPEN .......................................................................................... 35 5. SLUTSATS ........................................................................................................................ 36 REFERENSER ...................................................................................................................... 37 3
1. Introduktion
2011 publicerade Gartner en undersökning där CIOs beskrev att molnet var deras toppprioritet under året. I dagsläget har stora investeringar gjorts i plattformar som fört organisationer långt, men många organisationer kämpar fortfarande efter år av investeringar i olika
molnlösningar, för att visa att IT ger värde, inte bara i kostnad utan även inom organisationen
(Hunter, 2011). Utvecklingen bland molntjänster går snabbt och den snabbaste utvecklingen
är ibland lagring, databaser och infrastruktur. Det är inte bara så att det är IT-avdelningen som
köper in molntjänster utan andra delar av organisationer som kan köpa in dem. Fördelar med
molntjänster kan till exempel vara flexibilitet, enkelhet och kostnadseffektivitet. Även om
molntjänster har varit den största prioriteringen de senaste åren har det börjat höjas kritiska
röster om att det existerar en övertro på molnet och att denna “hajp” har gjort att företag har
fattat förhastade beslut. Problematiken blir inte mindre av att leverantörer av systemlösningar
har gjort ”moln” till sin favoritmarknadsföringsterm vilket ytterligare försvårar upphandlingen av tjänster.
1.1 Bakgrund och Problemområde
Molntjänster har en betydande inverkan på alla aspekter av IT och användarnas tillgång till
applikationer, information och företagstjänster. Även om potentialen är betydande är bredden
och djupet av konsekvenserna på förhastade inköp stor (Cearley & Smith, 2012). En möjlig
anledning till att organisationer som optimistiskt inhandlar nya systemlösningar i molnet inte
anser att investeringen lever upp till förväntningarna kan vara en brist i den egna planering av
hur sådana tjänster skall hanteras och kopplas samman med de informationssystem som redan
existerar. Det går att göra en jämförelse med att spontant inhandla en soffgrupp utan att fundera på om den får plats i hemmet eller hur den fungerar ihop med det övriga möblemanget.
Det finns anledning att fråga sig redan på ett tidigt planeringsstadium: Vilken nytta vill vi
uppnå med att migrera våra system till molnet? Vilka förändringar måste vi göra i vår egen
arkitektur för att kunna hantera molntjänster?
Skapandet av en Services Oriented Architecture (SOA) lovar organisationer en flexibel anpassning av deras informationssystem till snabbt förändrade företagsbehov. En framgångsrik
implementation av SOA är inte begränsad till förändringen av IT-systemen utan en förändring
som ger genomslag i hela organisationen. För att kunna hantera komplexiteten är det lämpligt
att implementera en bred SOA för hela organisationen genom en steg för steg ansatts. Kunskap från experter från olika områden är nödvändiga för att kunna göra rätt förändringsbeslut.
En planeringsfas ger organisationer en överblick av nuvarande system samt en första inblick i
en möjlig framtida arkitektur (Shulster et al, 2010).
4
1.2 Syfte och Frågeställning
Syftet med denna rapport är att exemplifiera vad verksamheter bör ha i åtanke vad gäller deras
egen förmåga inför en implementation av en tjänsteorienterad arkitektur (SOA). Innehållet i
studien vill öka verksamheters medvetenhet i mognadsnivåer och vilka utmaningar som kan
uppkomma vid implementationer av en SOA samt visa på en möjlig ansats till förändring av
befintlig arkitektur innan en verksamhet kan implementera molntjänster. Den frågeställning
som studien ämnar besvara blir således:
Vad skall företag tänkta på gällande den egna förmågan att åstadkomma en
tjänsteorienterad arkitektur innan en implementation av molntjänster?
1.3 Begränsningar
Det finns en mängd olika aspekter att ta hänsyn till i definitionen av molntjänster. Det kan
vara aspekter så som säkerhet i användningen av information, ekonomiska aspekter samt vilken leverantör som kan ge ett bra koncept eller ett bra pris. Uppsatsen ämnar inte ta upp
ovannämnda aspekter. Uppsatsen kommer att fokusera på migrationen och förberedelser för
migrationen till molntjänster.
Vi är medvetna om att det finns en mängd olika områden som kan behandlas inom forskningsfrågan. Dessa områden kan till exempel vara:
•
•
•
•
•
•
•
•
Molntjänster och vilka slags tjänster som passar in kontexten
Beslutsfattande
Vilka nyckelintressenter som finns i beslutsfattande
Kunskap och lärande, och samarbete. Hur dessa påverkar organisationen
IaaS, PaaS samt SaaS, och inköp av dessa i organisationer
Processen för utveckling och val av IT-tjänster
Förändringstakten i företag
Kommunikation med tjänsteleverantörer
Det finns många olika ansatser och ramverk som skulle kunna ligga till grund för dessa perspektiv. Studien inriktar sig dock på planering av arkitektur, migrationsöverväganden och
mognadsmodeller.
1.4 Metod
Denna studie inleddes med att en litteraturstudie genomfördes, där syftet var att läsa in oss på
relevant litteratur inom området, som efter hand växte fram till att utgöra vårt teoretiska ramverk. Litteraturstudien bestod huvudsakligen av vetenskaplig forskning publicerat i bok- och
artikelformat. Sökningar efter litteratur skedde till största del via ändamålsenliga artikeldatabaser och sökmotorer som Göteborgs Universitetsbibliotek, Summon, Samsök, Chalmers
bibliotek, och Google Scholar.
En kvalitativ forskningsansats valdes, med studiens forskningsfråga och tidsram, samt möjliga
respondenter i åtanke, eftersom att en sådan är speciellt lämplig vid insamlandet av djupdykande empiri ur ett mindre antal respondenter (Jacobsen, 2002; Denscombe, 2009). Empiriinsamlingen skedde genom en semi-strukturerad intervju, som genomfördes ansikte mot ansikte. Såväl Denscombe (2009) som Jacobsen (2002) skriver att semi-strukturerade intervjuer
tillåter ett lämpligt djup i respondenternas svar genom att återspegla de tolkningar och upp5
fattningar som respondenterna har av undersökningsfenomenet. Detta ansågs passande för
studien, och valdes därför som primär datainsamlingsmetod.
Vidare gavs vi möjligheten att återkomma per e-post till respondenten i det fall att missförstånd uppstått vid analysen av dennes svar, eller om ett förtydligande behövdes. I kombination med möjligheten att spela in intervjuerna i digital form för senare och mer rigorös analys,
har studiens validitet samt datasäkerhet höjts.
För att besvara studiens forskningsfråga, eftersöktes personer med kännedom kring de faktorer som påverkar ett företags förmåga att åstadkomma en tjänsteorienterad arkitektur inför
en implementation av molntjänster.
Intervjun som genomfördes ansikte mot ansikte och tog plats på en av respondenten utvald
plats, för att som Denscombe (2009) och Backman (2008) påpekar; främja respondentens
vilja att prata öppet och ohämmat, vilket möjliggörs genom att denne känner sig bekväm på
den plats som intervjun genomförs. Vid intervjuns början efterfrågades respondentens samtycke till att intervjun spelades in, och vidare togs kontinuerliga anteckningar för att underlätta tolkningen av svaren vid senare analyser. Analysen utfördes genom att materialet lästes
och lyssnades igenom ett par gånger i syfte att göra oss förtrogna med innehållet, och därmed
på ett bättre sätt kunna upptäcka relevanta kopplingar mellan respondentens svar och forskningsfrågan.
1.5 Definition av begrepp
Enterprise Application Architecture (EAA)
EAA är ett perspektiv inom EA som verifierar och definierar interaktionerna ibland processer
och standards som används av organisationen. Se avsnitt 2.1 Enterprise arkitektur.
Enterprise Application Integration (EAI)
EAI definieras som användningen av mjukvara, datorsystem och arkitektoniska principer för
att integrera en kvantitet av företags datorapplikationer. EAI är en ”bakom kulisserna”-teknik
som ofta uppfattas som ett produktivt verktyg för IS-utövare. EAI är ett brett begrepp som
omfattar ett spektrum av EAI-programvara, -produkter, -metoder och -processer.
Enterprise Resource Planning (ERP)
ERP är en typ av affärssystem som innehåller många integrerade funktioner för alla större
affärsfunktioner som spänner över en hel organisation, till exempel: produktion, distribution,
försäljning, ekonomi, och personalhantering. ERP inhandlas ofta som en ett färdigt paket vilket sedan kan anpassas för att passa organisationen optimalt. Ett ERP-paket ersätter vanligen
många olika tidigare separata programpaket.
Front End, Middleware & Back End
Dessa tre termer används för att karakterisera programgränssnitt och tjänster i förhållande till
slutanvändaren av gränssnitten och tjänsterna. Ett front end-program används av slutanvändaren, och det interagerar med back end som exempelvis kan vara databasen bakom gränssnittet
som användaren ser och som front end-programmet kommunicerar med. Back end-program
tjänar som indirekt stöd för front end-program. Det förekommer även ibland ett mellanliggande lager; ett så kallat middleware, som knyter samman programkomponenter som inte kan
kommunicera direkt med varandra på grund av exempelvis kompatibilitetsproblem.
6
On Demand
Är en företagsmodell där datorresurser görs lättillgängliga för användaren efter dennes behov.
Resurserna kan hållas inom ett företag eller göras tillgängliga av en leverantör. Denna modell
eller tjänst har framställts för att övervinna den gemensamma utmaningen för företag att
kunna bemöta en fluktuerande efterfrågan på effektivitet. Då en företagsförfrågan på datorresurser kan variera drastiskt över en period, kan resurser upprätthållas för att möta toppar och
krav. Genom ett ”on demand” avtal kan företag skräddarsy sina datorresurser och skära ner
kostnader.
Service Bus
En service-buss ansvarar för förbindelserna mellan utövarens/användarens? applikation och
resurserna som applikationen nyttjar i molnet, detta oavsett vilken plattform som brukas. Användning av denna kommunikationsinfrastruktur kan medföra att utvecklaren inte behöver
skapa komplexa koder som kan behövas för en korrelation och logik i kopplingen mellan
olika nätverk. En service-buss ger användaren tillåtelse att exponera tjänster på internet även
om användaren sitter bakom en brandvägg.
Service-Level Agreement (SLA)
SLA är ett kontrakt eller ett avtal mellan en tjänsteleverantör och en kund. Avtalet beskriver
vilka tjänster som skall finnas tillgängliga, och detta ofta med ett återbäringsavtal vid drift
störningar. Leverantören garanterar att viss kapacitet skall levereras. Organisationer kan mäta
och jämföra mellan olika leverantörer för att få ett så bra avtal som möjligt. Avtal av denna
formen kan till exempel innehålla parametrar som: hur många procent av tiden som tjänsten
kommer att vara tillgänglig, antalet användare som kan använda tjänsten samtidigt, statistik av
användning med mera.
7
2. Teoretiskt ramverk
2.1 Enterprise arkitektur
För att beskriva Enterprise Arkitektur (refereras vanligen EA härefter) är det logiskt att börja
med en definition av begreppet. Ordet ”arkitektur” kommer från grekiskans ”arki” som betyder principer och ”tektur” som betyder lämpligt mönster, vilket ordagrant ger begreppet innebörden, principer för att skapa lämpliga mönster (Magoulas & Pessi, 1998). Detta innebär
emellertid att begreppet ”arkitektur” blir synnerligen applicerbart på en mängd olika fenomen
och entiteter i vår omvärld, varav ”Enterprise” eller företag är ett, som dock i kombination
med ”arkitektur” skiljer sig avsevärt från exempelvis ”mjukvara”. Domänen för arkitektur hos
ett företag är betydligt mer omfattande än hos en programvara, liksom entiteter i respektive
domän, dess mönster och de principer som formar mönster är helt annorlunda.
Söker man i litteraturen efter en definition av begreppet ”Enterprise Arkitektur”, finner man
med tanke på den stora domänen inte oväntat en mängd vitt skilda begreppsdefinitioner för
EA. Lewis (2009) närmar sig problemet på ett pragmatiskt vis när som söker i dessa olika
definitioner efter gemensamma termer som en indikation på vad som är mest beskrivande för
vad EA ”är”, nämligen komponenter, relationer och principer. Det kan också vara handlingar,
en planerad förändring vilket visar på att EA är levande och inte endast en dokumentation av
ett statiskt tillstånd. Lewis (2009) definition av EA kan beskrivas som: ”EA är den planering
som harmoniserar och integrerar ALLA resurser som en organisation använder för att bli så
verkningsfull, effektiv och accepterad som möjligt. Det handlar verkligen om komponenter
(resurser) och deras relationer (kopplingar), utformade efter principer.” Lewis (2009) menar
att EA består av en samling av artefakter i form av planer eller ritningar som grupperats så de
kan utnyttjas som beslutsunderlag för ledningen eller vägledning för utveckling och implementation, men också att EA är en designprocess med syfte att skapa vidareutveckla EA i
linje med organisationens behov. Land et al (2009) nämner sju olika definitioner för hur en
EA kan definieras. Deras olika definitioner visar att det finns stora skillnader, dock att alla
definitioner har en gemensam grund som författarna pekar ut. Denna grund är enligt författarna strukturen och relationerna kombinerade med principer som i sin tur kan ge guidning och
support för direktioner och beslut. EA fokuserar på att forma och leda en design av en framtida EA genom att använda principer för att framställa framtidens inriktning och vilka modeller som finns för att stödja och visualisera framtiden. Det finns tre viktiga perspektiv inom
EA och vilken roll den skall spela. Dessa perspektiv är; 1) ett författningsorienterat perspektiv
som reglerar utformningen av ett företag, 2) ett designorienterat perspektiv som innefattar
designbeslut om faktiska system och artefakter, 3) ett strukturorienterat perspektiv som fokuserar på användandet av designmönster. Detta perspektiv utgör sig för att vara en bro mellan
de två första perspektiven. Efter detta resonemang kommer författarna fram till sin egen definition av EA: en sammanhängande uppsättning av beskrivningar, som omfattar ett författningsorienterat, designorienterat och strukturorienterat perspektiv på ett företag, som tillhandahåller indikationer och kontroller som utgör en informativ styrning av företagets framgång
och utveckling (Land et al, 2009).
Domänen för EA är i sig ett heterogent nätverk av andra domäner. Aerts et al (2004) har identifierat tre domäner vars arkitektur är av betydelse för EA; 1) ”Business Architecture” definierar affärssystemet och dess miljö, 2) ”Application Architecture” innehåller systemapplikat8
ioner och dess interaktion, 3) ”ICT platform architecture” är arkitekturen för de gemensamma
teknikresurser som används för att bygga system i EA. Många andra författare inom ITmanagementlitteraturen använder en liknande skiktad modell för att beskriva domänstrukturen för EA (figur 1).
Figur 1, Enterprise Arkitekturens delkomponenter (Pessi, 2012)
Magoulas & Pessi (1998) påpekar att det är viktigt att förstå hur den historiska utvecklingen
av informationssystem har påverkat utvecklingen av EA och förändrat behoven av strategisk
planering för organisationer. De delar upp den allmänna IS-utvecklingen i tre ”eran” från 70talet till idag. Databehandlingseran (DP) på 70-talet dominerades av ett behov att rationalisera
bort rutinmässiga arbetsuppgifter genom datasystem för att göra kostnadsbesparingar. Informationseran (MIS) under 80-talet kännetecknas av ett ökande behov av att använda informationen i systemen för att förbättra beslutsprocesser i företagen. Men fick upp ögonen för att
informationen i sig var värdefull, likt mer traditionellt påtagliga resurser och ansträngde sig
för att göra den tillgänglig. Under den strategiska informationssystemeran (Network) på 90talet och framåt breddas synen på informationssystem till att även omfatta omvärlden (med
kunder, partners, leverantörer och konkurrenter) så behoven utökades ytterligare från intern
rationalitet och effektivitet till extern konkurrenskraft vilket medförde ökat fokus på en övergripande strategisk planering och positionering av organisationens informationssystem. Aerts
et al (2004) visar på hur utvecklingen av modellerna i de tre signifikativa arkitekturdomänerna utvecklas under denna tidsperiod (från 50-talet i sex steg) så att den sammantaget driver
fram en utveckling för EA mot just rationalisering, effektivisering och konkurrenskraft.
Roeleven och Broers (2008) studie visar på att den stora majoriteten av EA projekt misslyckas. Detta trots att de organisationer och företag som startar dessa EA projekt från början är
medvetna att de vill åstadkomma verklig verksamhetsomfattande förändring i linje med uttalade visioner, strategier och målsättningar. Den vanligaste orsaken till att EA projekt misslyckas är svårigheten med att koppla EA till affärsrelaterade element som affärsstrategier och
verksamhetsprocesser.
2.1.1 Service-Oriented Architecture
Service-Oriented Architecture (SOA) är, i motsats till vad många tror, inte ett verktyg eller
ramverk, utan ett arkitektuellt tillvägagångssätt, eller ett funktionellt perspektiv, med syftet att
bryta ner affärsprocesser i mindre och logiska tjänster (Arsanjani, 2004; Feuerlicht & Govardhan, 2009; Josuttis, 2007; Sharma, Sood & Sharma, 2011). SOA har under sin livstid
9
utvecklats från att till en början handla om att leverera befintliga tjänster från en provider (leverantör) till en consumer (konsument) genom så kallade web-tjänster (web service), till att
användas för att ta fram hållbara och serviceinriktade systemlösningar. SOA är vanligt förekommande vid exempelvis utveckling av affärssystem åt organisationer, där distribuerade
system ofta används. Arsanjani (2004) beskriver SOA som ett hjälpmedel för att överbrygga
klyftan mellan affärs- och IT-sidan, genom att använda ett antal designprinciper och tekniker
för att ta fram affärsanpassade IT-tjänster. Dessa tjänster är ofta helt oberoende av varandra,
och ibland utspridda såväl geografiskt som användarmässigt. Tjänsterna kommunicerar sedan
via så kallade interface, som enkelt beskrivet fungerar som en tolk så att tjänster skrivna på
olika programmeringsspråk eller för olika system kan kommunicera med varandra. Detta gör
att flera organisationer utan modifikationer av befintliga system eller specialutvecklade översättningssystem kan dela data eller funktioner samtidigt som de slipper använda sig utav exakt
samma system inom organisationen och över organisationsgränser. SOA erbjuder alltså ett
slags standardiserat och kompatibilitets-orienterat arbetssätt, och anses av en del teoretiker
vara en föregångare till dagens molntjänster. Vidare menar även en del författare, som exempelvis Linthicum (2012), att molntjänster förutsätter SOA; det vill säga att för en majoritet av
organisationer krävs SOA för att molntjänster skall implementeras och fungera tillfredsställande. Anledningen föreslås av Linthicum (2012) vara att SOA tillhandahåller en passande
infrastruktur inom organisationen för att nyttja tjänster och komponenter som levereras från
exempelvis molnet utanför organisationsgränserna.
Figur 2, Standardiserat förlopp av informationsutbyte i SOA (McGovern et al. 2006)
Det finns en uppsjö definitioner av SOA, där ingen är den andra helt och hållet lik. Det finns
emellertid en utmärkande gemensam faktor, och det är det serviceinriktade tänket. Mellan en
serviceprovider och en serviceconsumer sker ett standardiserat förlopp av informationsutbyte,
vilket resulterar i att consumern får en önskad och förväntad tjänst levererad till sig av providern (Figur 2). Det finns idag inget behov av att consumern och providern är två helt separerade organisationer, utan SOA kan enligt (Session, 2006) vara ett hjälpmedel för att hantera
en komplex situation där en organisation står inför ett omfattande systemarbete, och där en
struktur över dess processer och tjänster är önskvärda.
2.2 Molntjänster
Termen “moln” eller engelskans “cloud” kan tyckas vara ett lustigt namnval på det hetaste
fenomenet inom IT under det senaste decenniet, men begreppet har en historisk förankring
från IT-erans gryning. När forskare under 1960-talet började modellera datanätverk i form av
diagram och ville beskriva hur data flyttades från en känd startpunkt genom ett nätverk till en
känd destination och vägen genom nätverket var okänd eller ointressant, så användes en
10
molnfigur för att symbolisera nätverket. Komplexa stora nätverk, som Internet har därför med
tiden blivit modellbegreppsligt synonymt med ”Moln” (Rittinghouse & Ransome, 2010).
I den allra bredaste definitionen blir det därför enkelt att beskriva molntjänster som ”tjänster
som erbjuds och konsumeras genom datatrafik över stora komplexa nätverk”. För att skapa en
mer användbar beskrivning av det moderna fenomenet som associeras med molntjänster eller
”Cloud Computing” kärvs en definition som bättre belyser dess egenskaper. NIST (National
Institute of Standards and Technology) har enligt Mell & Grance (2010) identifierat fem centrala egenskaper hos molntjänster:
•
•
•
•
•
Självbetjäning på begäran innebär att konsumenten av tjänsten ensidigt och utan förhandling eller inblandning av mänskliga aktörer kan reglera omfattningen av resurser som utnyttjas via tjänsten som exempelvis servertid och lagringskapacitet i nätverket efter behov.
Bred nätverksåtkomst är tillgång av tjänsten över nätverket genom standardmekanismer
(protokoll etc.) som kan användas av ett blandat utbud av klientenheter (exempelvis datorer, mobiltelefoner och pekplattor).
Sammanslagning av resurser är en egenskap som syftar på att tjänsteleverantören har
grupperat sin samlade datorkapacitet i centraliserade enheter som kan betjäna flera konsumenter samtidigt och dynamiskt kan distribuera och omfördela resurser som exempelvis
lagringsutrymme, processorkraft, minne, bandbredd och virtuella servrar utifrån kundens
efterfrågan.
Snabb elasticitet är förmågan att snabbt, och i vissa fall automatiskt, expandera eller frigöra allokerade resurser. Konsumenten upplever därigenom att tjänsten har en obegränsad
kapacitet som kan anskaffas i valfri mängd och närsomhelst.
Mätbarhet vilket innebär att tjänsten är kvantifierbar i leverans så att användningen kan
övervakas, kontrolleras och rapporteras. Det möjliggör analys och optimering av nyttjandet av molntjänsten för både konsument och leverantör (Mell & Grance, 2010 ).
11
Figur 3, Modell av molntyper som används för leverens av molntjänster
(Conway, 2011 )
Vidare så kan leveransen av molntjänster distribueras över olika typer av nätverk och det kan
därför sägas att spridningen sker genom olika molntyper (Fihur 3). Varje molntyp tillför fördelar och nackdelar som inverkar på tjänstens kostnadsaspekter, dess säkerhet och tillgänglighet samt hur den kan styras och anpassas (Conway, 2011). De vanligaste typerna av moln är
publika moln, vilka karaktäriseras av fri tillgänglighet och exemplifieras typiskt av Internet
och privata moln vilka är exklusiva för en enda organisation som nyttjar tjänsterna som erbjuds i denna typ av moln. Communitymoln är en typ av moln som skapats för en grupp av
organisationer som har gemensamma krav på molnets säkerhet och integritet och/eller har
gemsamma infrastrukturella element. Nationella myndigheter och institutioner är vanliga exempel på ägare av gemensamma moln. Hybridmoln består av två eller flera molntyper (publika, privata, gemensamma) som kopplats samman genom standardiserade eller proprietära
mekanismer som möjliggör ett utbyte av data och tjänster (Mell & Grance, 2010; Conway,
2011).
Figur 4, Tjänstemodeller för molntjänster (Conway, 2011)
12
Den kanske viktigaste aspekten för kategorisering av molntjänster är de olika tjänstemodeller
som används. Conway (2011) visar på tre breda modeller som kan användas för att särskilja
de vanligaste molntjänsterna idag. Infrastucture-as-a-Service (IaaS) innebär att konsumenten
på begäran får tillgång till IT-infrastuktur i form av virtuella element som exempelvis servar,
datalagring och nätverksenheter. Dessa kan användas som stöd för traditionell systemkonstruktion och administration med lämplig mjukvara eller som underliggande byggstenar för
andra molntjänster. Platform-as-a-Service (PaaS) ger konsumenten tillgång till en komplett
utvecklingsmiljö på vilken det går att köra befintliga applikationer eller utveckla egna funktioner med hjälp av programmeringsspråk och verktyg som tillhandahålls av leverantören (Figur 4). GoogleApps och Microsoft Azure är exempel på PaaS. Software-as-a-Service (SaaS)
är den klart dominerande tjänstemodellen och innebär att kunden kan använda och anpassa en
eller flera applikationer som tillhandahålls vanligtvis via en portal där användaren kan interagera med applikationen genom en webbläsare, plugin eller ett mindre klientprogram.
2.2.1 För- och nackdelar med molntjänster
Molntjänster låter användaren få tillgång till applikationer och dokument från var som helst i
världen, dock finns det både för- och nackdelar med moln, (Miller, 2009).
Fördelar med moln
• Lägre driftkostnader. Datorer och servrar behöver inte lika stor prestanda eller processorkraft när molntjänster används. Detta leder till att datorer inte behöver vara lika dyra då det
inte krävs lika mycket minne, processorkraft med mera.
• Förbättrad prestanda. När datorer och databaser inte längre behöver krävande program.
• Minskade kostnader för programvara. Leverantören kan stå för den programvara som behövs för molntjänsterna.
• Omedelbara programuppdateringar. Organisationen eller programleverantörer står inte
längre för uppdateringen av programvaror. Detta gör att beslut om att uppdateringar av
programvaror inte längre behövs.
• Förbättrad dokumentformatskompatibilitet. Oron över inkompatibla dokument försvinner
då alla inom organisationen använder samma molntjänst.
• Lagringskapacitet. Molntjänster erbjuder praktiskt taget obegränsad lagring.
• Ökad tillförlitlighet. Då servrar och datorer kan krascha försvinner ofta information om det
inte finns ett backupsystem. Moln har stora backupsystem, och skulle en krasch inträffa
finns informationen kvar.
• Universell tillgång till dokument och information. Finns en internetuppkoppling, så finns
tillgången till molnet där. Detta medför att användare kan komma åt viktig information var
som helst i världen.
• Tillgänglighet till senaste versionen. Information som redigeras på ett ställe är alltid uppdaterad på ett annat ställe. I molnet finns alltid den senaste versionen av handlingar och
dokument.
• Enklare gruppsamarbeten. Genom att kunna dela dokument över stora områden, kan flera
personer i till exempel en projektgrupp arbeta med samma dokument samtidigt.
• Enhetsoberoende. Användare är inte beroende av en speciell dator eller ett nätverk för att
kunna utföra arbetsuppgifter.
13
Nackdelar med moln
• Kräver konstant internetanslutning. Att arbeta med moln är inte möjligt om inte en internetuppkoppling finns att tillgå. Internetanslutningar kan vara otillförlitliga och detta kan
då bli en nackdel.
• Molntjänster fungerar inte bra med låghastighetsanslutningar. Webbaserade lösningar
kräver stor bandbredd för att kunna ladda ner och ladda upp stora dokument. Stora molntjänster och funktionsrika molntjänster kräver en stor bandbredd.
• Molntjänster kan vara långsamma. Molntjänster kan bli långsamma då backuper körs.
Molntjänster kan alltså bli långsamma i perioder.
• Funktioner kan vara begränsade. Då molntjänster ofta inte är lika utvecklade som desktop
program kan vissa begränsningar finnas. Det är upp till säljarna att visa upp en så komplett
lösning som möjligt för det specifika användandet.
• Säkerhetsaspekter. Det finns många frågor kring säkerhet i molnet. Enligt säljare så är
moln säkra, dock är det för tidigt i utvecklingen att urskilja säkerheten.
• Lagrad data kan gå förlorad. Tekniskt sett är lagrad data i molnet ovanligt säker då den är
replikerad i flera instanser. Skulle molnet mot all förmodan totalhaverera, försvinner dock
all data. Men genom att göra egna regelbundna backuper kan organisationer säkerställa att
data finns kvar.
2.3 Migration
Migration betyder förflyttning. Migration har varit ett skäl till människans utveckling och
överlevnad. Intern migration behandlar förflyttningar inom en organisation och extern migration behandlar migration utanför en organisation. Migration kan innebära att förflytta IT resurser från en avdelning till en annan och sådan migration blir då intern. Migreras exempelvis
system eller tjänster till en annan destination kallas förflyttningen extern migration, (NE.se,
2012). Migration till moln är en extern migration då organisationer förflyttar sin arkitektur till
en webbaserad arkitektur. Anledningen till migration kan vara många och variera beroende på
vilken organisation som tillfrågas (se, fördelar med molntjänster ovan).
Skalbarhet och elasticitet är två begrepp som ofta förekommer i samband med molnet, och är
två viktiga faktorer till varför organisationer väljer att migrera till molnet. Genom en hög grad
av skalbarhet kan, som ovan nämnt, exempelvis processorkraft och bandbredd omedelbart
ökas eller minskas i takt med ett fluktuerande behov. Detta kan komma väl till pass i en organisation med ett över tiden varierande behov av datorkraft. En sådan organisation skulle traditionellt sett ha varit tvingad att förse sig med tillräckligt med datorkraft för att hantera de
enstaka topparna ett par gånger om året eller i månaden, och som resten av tiden skulle ha
stått helt outnyttjad. Vidare kan skalbarhet och elasticitet gynna organisationer med en utmanande framtid, exempelvis om ett antal fusioner eller förvärv är planerade utan att en klar bild
av framtida behov IT-resurser finns.
2.3.1 Beslut om att migrera till moln
Enligt Baldwin et al (2012) börjar molntjänster växa fram i företagen och beslutet att använda molntjänster kan frambringa frågor som: skall IT-systemen vara kvar eller skall de ut i
molnet samt vilka molntjänster som är aktuella. Beslutet kan vara att migrera all IT till molnet
men det är mer troligt att beslutet kommer innebära att den interna applikationen behålls och
istället ersätts delar av den med molntjänster. Detta beslut triggas ofta av företags behov av att
14
uppgradera applikationer. Beslutet av att använda sig av molntjänster påverkar inte bara applikationen utan även andra delar bör tas i beaktning så som: säkerhet, sekretess, intressenter,
kostnader.
Beslut om säkerhetsregler tenderar även att tillämpas över hierarkin och kan komma att påverka många delar i verksamheten. En ram för att tänka igenom beslutet kan vara att föredra.
Om beslut om moln gäller enskilda tjänster kommer säkerhetsbeslut att kunna bli enklare. När
det gäller säkerhetsbeslut som påverkar hela organisationen kan det vara svåra att estimera
kostnad och produktivitetseffekter. Isolation av dessa effekter i en ensam applikation kan underlätta beslutet. Att flytta en applikation till moln kan fortfarande ha stor inverkan på hela
Enterprise IT (Baldwin et al, 2012).
Att flytta flera applikationer ut från organisationens datacenter kan reducera kostnader däremot kan detta bidra med en ökad kostnad för de applikationer som är kvar. Molnbeslut är mer
komplexa då beslutet omfattar att flytta faktorer som representerar affärsbeslut som förvaltning av kostnad och informations faktorer. Genom att formalisera nyttofunktioner i ett ramverk för att kunna jämföra olika värden som organisationen skalle kunna få mellan olika
molntjänster är ett alternativ för ett företag som vill uttrycka hur man vill värdera en vinstfaktor, så som affärsnytta mot en förlust. Denna nyttoanalys kan sedan användas för att se olika
tjänsternas regler och villkor. Även om molntjänster ger en omedelbar nytta, kan det vara
klokt att vänta tills molntjänsten även ger nytta på långsikt. Beroende på om ett företag är väl
etablerat med god ekonomi eller om ett företag är nystartat med instabil ekonomi kan valet av
molntjänster se annorlunda ut. Ett företag med god ekonomi har råd att vänta ut nyttan med
molntjänster medan ett företag med instabil ekonomi inte har tiden att vänta ut nyttan av
molntjänster. Valet att migrera till molntjänster kan då ligga på ekonomin och inte på nyttan
som kan uppnås. Osäkerheten med molntjänster är förvaltningen av information, äganderätt
till information. Även om det finns ett förtroende till leverantörer bör dessa aspekter värderas
innan en migration sker (Baldwin et al, 2012).
Det finns värde i att vänta med beslutet av molntjänster. Genom att vänta kan organisationer
se hur andra organisationer drar nytta av molntjänster och vilken framgång de bringar. Genom
att vänta och se hur utvecklingen går kan väntan motivera en snabb adoption av molntjänster.
Modeller och ramverk ger inte noggranna förutsägelser om resultat utan snarare ramar in antaganden och alternativ, detta för att kunna hålla en diskussion om ämnet. Beslutsfattare är
inte medvetna om alla aspekter och en diskussion har betydande värde. Diskussioner med
företag har gett författarna en insikt att inlåsningseffekter är en aspekt som organisationer
oroar sig över. Organisationer vill även kunna byta tillbaka till sina gamla system om nyttan
som önskades inte uppnåddes. Osäkerheten om molntjänster kan komma utifrån känslan av
”förlusten av kontroll” och behovet av att förlita sig på andra (Baldwin et al, 201).
2.3.2 Aktiviteter under migrationen till moln
Symonds (2010) beskriver att migrationen till moln är beroende på hur organisationer använder sig av IT och att det inte finns ett spår som kan följas för att göra en migration till en
molnbaserad miljö. Författarna anser snarare att ett antal aktiviteter skall ske parallellt eller
var och en för sig i ett iterativt arbetssätt. Organisationer bör testa och försöka för att kunna
bygga upp erfarenheter som kan vara praktiska men bör samtidigt lägga grunden för en gradvis migration av alla system i riktning mot molntjänster. Symonds (2010) anser att migration
till ett moln börjar med matchning. Vilket menas med att organisationen skall avgöra om det
existerar en passande molnmiljö och att molnmiljön motsvarar organisationen och EAs krav.
15
Då marknaden expanderar mycket i dagsläget anses denna matchning bli mer och mer trolig
då standardkomponenter och miljöer utvecklas i snabb takt vilket leder till att den nya miljön
kan levereras snabbare. Dock kan detta kräva en kulturell och organisatorisk förändring då det
inte behöver byggas en special anpassad miljö.
De första aspekterna som bör tas i akt är att avgöra vilka system som är lämpliga för överföring till moln. Ett bra sätt är enligt Symonds (2010) att köra ett pilotprojekt inom organisationen. Det finns många olika sätt att välja ut ett system som skall testas, till exempel så kan
organisationen välja det första påtänkta systemet. Den data som ligger inne i kärnprocesser är
sådan data som ej primärt bör migreras. Det pragmatiska valet ligger alltså inte i att välja system som är internlänkade med andra system utan att välja sådana system som ligger utanför
kärnsystemeten. Figur nummer 5 visar de komponenter som är mer flexibla i en EA och de är
mer mottagliga för en molnstrategi enligt Symonds (2010) Följande system är de bästa systemen att börja med: ljud- och videokonferenser, test och utbildningsmiljöer, virtuella skrivbord, datalagring samt arkivering. Data kan även behöva ”rensas upp” för att kunna migrera
till moln. Författarna anser att en sammanhängande datamodell är väsentlig för att kunna migrera till moln. Detta menas med att samma fält skall betyda samma sak i alla sammanhang
och organisationen skall veta vilken som är den ursprungliga versionen.
Figur 5, Systemkomponenters migrations lämplighet (Symonds, 2010)
16
En god inkörningsport är att testa av molnet och genom tester utveckla en ”buttom up” strategi. Detta test har en låg risk samt att testet erbjuder ett sätt för utvecklare att bekanta sig
med molnmiljön därefter kan detta driftsättas och andra applikationer kan testas. En av de
första grupperna kan vara den interna tjänsteleverantören, tillexempel de som använder PaaS
för att utveckla SaaS tjänster, samt externa användare som behöver en modern, flexibel utveckling och en testmiljö. De som kan tester är även sådana som förvaltar testningen för nya
versioner av existerade applikationer. Teknologin för sådana här miljöer är inte svår att tillhandahålla men arbete krävs för ”as a service” aspekter till exempel, efterfrågan och utbudmodellen (vilka är kunderna och vilka är leverantörerna), vilken är servicebeskrivningen och
vilka servicenivåer kan nås, service management aspekter så som kostnadsberäkningar, prissättning, kapacitetsplanering med mera Symonds (2010).
Symonds (2010) anser att organisationer skall fastställa och sprida pilot tillämpningar för att
migrera till moln. Processen för att migrera till moln bör innehålla:
•
•
•
•
•
•
•
•
•
Identifiering av målgrupper, program eller tjänster som är aktuella samt gränssnittet
som behövs.
Identifiera och hantera styrning och riskfrågor.
Bygga upp ett organisatoriskt mål.
Bygga en serviceledning som har förmågan att hantera leveranser av moln.
Sammanställa förändringen i organisationens applikationsmiljö,
Utveckla nya former av tillgänglighet/kontinuitet/oförutsedda hanteringsprocesser för
att hantera den nya leveransmodellen,
Implementera en accepterad miljö i molnkontexten för att testa användbarheten.
Migrera den levande miljön, eventuellt i grupper av användare.
Försäkra att den kunskap som tillförs fångas så den kan användas i andra projekt.
2.3.3 Kostnader och risker med molnmigration
Migrera till en ”infrastruktur som en tjänst” (IaaS) är en attraktiv möjlighet för ett företag som
vill skifta från en kapitalkostnad till en ”pay as you go” modell. Oavsett drivkraften bakom
molntjänster, som kan vara många, som att minska kostnader och lägga till smidighet i EA, så
står stora företag inför en förnyad bedömning av sin kärnverksamhet till IT-tillgångar med ett
öga mot ”enterprise to cloud” migration för att förbättra affärseffektiviteten. IT-chefer saknar
förmågan att kvantitativt bedöma risk och belöning hos vilken applikation som skall migreras
från EA till ett moln. Utan att ha en mätbar konsekvensanalys av migrationsresurser till ett
moln inför företagen ad-hoc beslut under molnmigrations processer. För CIO (Chief Information Officer) och CTO (Chief Technology Officer) och företagsarkitekturen har molntjänster
kommit att bli en ofrånkomlig aspekt av den övergripande IT-strategin. När ett företag utser
ansatser till migrationsdelar av deras infrastruktur till molnet brottas IT med grundläggande
frågor som (Yunus, 2010):
•
•
•
•
Vilken applikation eller komponent skall migreras?
I vilken ordning skall migrationen ske?
Vilka IaaS leverantörer bör väljas baserat på prestanda och tillförlitlighet?
Hur kan migrationsrisken mildras?
I en migration till moln kommer företag att identifiera kandidatkomponenter baserade för
drivkrafter som kontinuitet i verksamheten, skalbarhet och lägre totala kostnader för ägande.
Valet av molnleverantör kräver rörliga tjänster och komponenter såsom databas, applikations17
servrar, ESBs (en mjukvaruarkitektursmodell som används för att utforma och genomföra
interaktion och kommunikation mellan mjukvaruapplikationer i SOA) och identitetsaffärer till
molnmiljöer. När ett fullständigt referenssystem är installerat i molnet skall beteenden av EAapplikationen och interaktion med molntjänster testas av. Genom ett test kan företaget utvärdera klassen av servrar, minne, CPU och lagringsbeteenden i flera miljöer. IaaS-leverantörer
bör också vara referensanvändare vid olika tidpunkter för att kunna säkerhetsställa ett konsekvent beteende (Yunus, 2010).
För att förstå riskerna av att flytta applikationskomponenter till ett moln behövs kvantifierbara
effekter av att lägga till ytterligare hopp från företagens datacenter till molnleverantörer. Företag bör testa scenarion som kan komma att uppstå innan en integration sker. Detta för att upptäcka buggar med systemet och för att vara säkra på att molnet har önskad effekt. Molnsimulering och migrationsmodellering ger mer effektiva och smidiga alternativ till att bygga en hel
molnbaserad referensinfrastruktur för att kunna utvärdera företagets migrationsrisker. Genom
migrationssimulering kan organisationer simulera tjänster i molnet innan migrationen har genomförts. Simuleringen gör att företag kan dra nytta av att inte behöva röra produktionen
samtidigt som det sker en eliminering av tid, kapital och IT-personalkostnader relaterade till
skapandet av distinkt miljö för molntestning. Kostnader som kan elimineras genom simulering är (Yunus, 2010); 1) En fullskalig, redundant arkitekter som involverar både hårdvaruoch mjukvarulicenskostnader, 2) Hyra engagerade utvecklingsteam för testning och jämförelser och 3) Specialanpassade ”tänk om”-scenarier för att fastställa felförhållanden relaterade
till svarstid, prestanda, säkerhet och skalbarhet.
Genom att simulera programkomponenter i molnet innan migrationen kan organisationer se
verklig information om molnleverantörer, exempelvis; 1) resultatstatistik, 2) geografisk latens
och integrerad initiering, 3) fel, avbrott och applikationer fel status och 4) säkerhet, kompatibilitet och kapacitet. Med data från tester i olika scenarion kan företag fatta beslut om migrationsstrategin till molnet utan att behöva flytta allt eller delar av en applikation till molnet,
modifieringing av företagets produktionskoder för ”ifall att” utvärderingar, kommer att ha en
betydande utveckling för infrastrukturkostnader under utvärderingsprocessen (Yunus, 2010).
Informationen som förts samman genom simulering av molnet gör att företag kan fatta viktiga
beslut om övergångsstrategi. Simuleringen kan avslöja betydande kompromisser mellan kostnad och risker. Sådana avvägningar kan hjälpa företag att välja om de ska behålla ”status qou”
(oförändrat tillstånd) eller migrera applikationer till molnet. Kostnadsfaktorer bestäms bäst
genom att simulera en applikation inom ett moln och detta kan avslöja den serverklassen som
krävs för molnleverantören för att upprätthålla de önskade applikationernas prestanda. IaaSleverantörer förser en variation av alternativ baserade på olika processorer och minnesstorlekar. Genom en detaljerad simulering baserad på analys kan rätt serverklass identifieras och
kostnaderna kan modelleras. Företag kan använda flera molnleverantörer för att skapa redundans. Kostnadsanalyser gör det möjligt för företag att bestämma över migrationen till flera
molnleverantörer. Förutom ”pay-as-you-go”-kostnader finns det en rad andra kostnadsfaktorer som bör beaktas så som: säkerhetskostnader, hanteringskostnader och den faktiska kostnaden för migrationen (Yunus, 2010).
18
2.4 iSOAMM
Genom att anamma en tjänsteorienterad arkitektur (SOA) får en organisation möjlighet att
snabbare kunna anpassa de applikationer de använder till förändringar av verksamhetens behov. För att lyckas implementera SOA i en organisation krävs omställningar i hela organisationen och inte endast förändringar i IT-systemen. Oavsett om det handlar om en introduktion
av SOA eller en uppgradering av en befintlig tjänsteorienterad arkitektur, är förändringar som
omfattar hela organisationen följaktligen så komplexa att en stegvis utvecklande ansats är att
föredra. Mognadsmodeller möjliggör planering och kontroll av migrationen från en traditionell till en tjänsteorienterad arkitektur såväl som migrationen mellan olika nivåer av utvecklingsmognad. Det är viktigt att kunna värdera graden av mognad hos organisationen för att
dels kunna bestämma en lämplig nivå där nyttan motiverar kostnaderna för att uppnå och upprätthålla en sådan mognadsnivå men också för att finna en lämplig väg för att nå dit. En SOA
mognadsmodell bör därför innehålla nivåer som visar på hur SOA stödjer verksamhetsprocesserna, nyttan och kostnaden för varje mognadsnivå samt risker som är förknippade med varje
steg så att den enskilda organisationen kan välja en passande nivå för sin unika verksamhet.
Tidigare modeller för värdering av SOA-mognad är i de flesta fall utvecklade leverantörer av
SOA teknologi (IBM, HP, Oracle etc.) och nivåerna i dessa modeller är därför kopplade till
graden av integration med leverantörens teknologier medan framgångsrika SOA – implementationer ofta innehåller en blandning av olika teknologier. Dessutom förutsätter modeller
skapade av leverantörer att den högsta mognadsnivån i modellen är den mest eftertraktade och
hjälper därför inte organisationen att välja en mognadsnivå för SOA som är ändamålsenlig
och passande snarare än primärt avancerad (Rathfelder & Gorenda, 2008).
2.4.1 iSOAMM-Modellens Perspektiv
iSOAMM använder fem perspektiv som belyser SOA-mognaden med hänsyn till både teknologiska och organisatoriska aspekter (Rathfelder & Gorenda, 2008).
1. Tjänstearkitektur (Service Architecture) : Betraktar de arkitekturella lagren hos en SOA
och de tjänster de innehåller, tjänsternas roll de i verksamhetsprocesserna och interaktionen mellan dem. Arkitekturen kan här variera från att endast vara ett lager för integration av tjänster till att aktivt stödja verksamhetsprocesser genom samordnade tjänster, användarinteraktion och samverkan med externa företag (B2B).
2. Infrastruktur (Infrastructure) : Granskar den underliggande infrasturkturen serparat från
tjänsterna och deras interaktion, eftersom en stabil infrastruktur är en förutsättning för att
tjänsterna snabbt skall kunna förändas så att de flexibelt kan anpassas till nya behov och
förutsättningar för verksamheten. Den huvudsakliga uppgiften för infrastrukturen hos en
tjänsteorienterad arkitektur är att försörja tjänsterna med ett gemensamt lager för kommunikation, vilket men ökande grad av mognad kan kompletteras med nya komponenter
och utökas till flera lager för övervakning och säkerhetsfunktioner.
3. Organisationsstruktur (Enterprise Structure): SOA påverkar både IT-system och verksamhetsprocesser. Anpassningar i organisationens strukturella uppbyggnad och förändringar av de olika verksamhetsenheternas ansvar och åtaganden är därför nödvändiga.
Perspektivet belyser de enheter i organisationen som påverkas av SOA och deras ansvar
och åtaganden.
4. Tjänsteutveckling (Service Development): Hur tjänster utvecklas och implementeras är
en avgörande del i utformningen av en SOA. Hur processen för tjänsteutveckling anpas19
sas med ökande nivåer av mognad är i fokus för perspektivet där den generella regeln är
att ökad grad av automatisering av tjänsteutvecklingen blir följden av ökad SOA-mognad.
5. Styrning (Governance): En förutsättning för en lyckad implementation av en SOA är en
genomgripande organisationsförändring. Förändringar, regelverk och riktlinjer som är relevanta för organisationen ur ett holistiskt perspektiv, som följd av SOA är här i fokus.
Styrning av SOA är emellertid ett ämne som är så omfattande att modellen endast kan
visa på den huvudsakliga nyckelindikatorn för varje mognadsnivå i detta perspektiv.
Genom att undersöka de fem perspektiven i en SOA och identifiera vilken nyckelindikator för
var perspektiv som bäst beskriver egenskaperna i den undersökta arkitekturen kan organisationer härleda vilken mognadsnivå som organisationen befinner sig på. iSOAMM använder
fem progressiva mognadsnivåer; Trial SOA, Integrative SOA, Administered SOA, Cooperative
SOA och On Demand SOA (Figur 6). En mognadsnivå är resultatet av en evolutionär mognadsprocess för en SOA, vilket innebär att man ofta finner nyckelindikatorer från de passerade lägre mognadsgraderna även i den nuvarande mognadsnivån för en SOA, men det är
också möjligt att en nyckelindikator kan ersätta en annan när organisationen omformas i utvecklingsprocessen.
Figur 6, Mognadsnivåer med nyckelindikatorer (Rathfelder & Gorenda, 2008)
Nivå 1, Trial SOA
Detta är instegsnivån där organisationer bekantar sig med en tjänsteorienterad arkitektur, vilket ofta sker i isolerade projekt där organisationer gärna experimenterar med standarder och
olika typer av SOA teknologi.
Tjänstearkitekturen: Kopplingarna mellan befintliga applikationer ersätts med tjänster, men
eftersom de inte behöver följa en standard så kan tjänsterna vara inkompatibla med varandra.
Infrastrukturen: Den blandade infrastrukturella miljön av med olika standarder kan orsaka öar
av tjänster som inte kan kommunicera med varandra.
Organisationsstrukturen: Verksamhetsavdelningarna är separerade från varandra och samarbetar sällan. De har egna applikationsportföljer som sköts av interna IT resurser.
20
Tjänsteutvecklingen: Oberoende SOA projekt utan någon samordnad utvecklingsprocess.
Styrning: SOA projekt ses som en intern IT angelägenhet utan större betydelse för verksamheten och saknar oftast stöd från ledningen.
Utmaningar , fördelar och risker med nivå 1:
Introduktionen av en tjänstebaserad arkitektur i en traditionell arkitektur innebär förändrade
synsätt och anammande av ny och ofta främmande teknologi. Det är därför ofta något dyrare,
speciellt på instegsnivån att implementera en tjänst jämfört med punkt-till-punkt förbindelser.
De erfarenheter av standarder och ny teknologi som de tidiga SOA projekten ger är dock en
förutsättning om organisationen vill utveckla sin SOA-mognad och är relativt riskfria eftersom de är så pass avskilda från den övriga verksamheten.
Nivå 2, Integrative SOA
På den här nivån är målsättningen att förverkliga en integration av IT systemen som används
inom hela organisationen, vilket brukar benämnas Enterprise Application Integration (EAI).
Erfarenheter från den lägre mognadsnivån med separata SOA projekt såväl som dokumenterad vägledning från externa projekt bidrar med kunskap från vilken en lämplig infrastruktur
för integration kan utformas.
Tjänstearkitekturen: Blandningen av standarder och teknologier ersätts med en gemensam
Service Bus (SB), vilken ger ett enhetligt tjänstegränssnitt genom som kan användas för att
koppla samman användarnas applikationer (Frontend Applications) med de underliggande ITsystem som förser dessa med data (Backend Systems).
Infrastrukturen: Kraven på skalbarhet, stabilitet, tillgänglighet och prestanda hos den gemensamma infrastrukturen är höga då den utgör ryggraden i en SOA implementation. Servicebussen är en sammansättning av olika standarder och teknologier som väljs utifrån behov och
kapacitet hos de applikationer och system som den knyter samman. Servicebussen håller
också logiskt reda på var en tjänst fysiskt körs vilket gör det smidigt att flytta tjänster.
Organisationsstrukturen: Samarbetet mellan verksamhetsavdelningar ökar på den här mognadsnivån främst på teknisk nivå till att omfatta ett gemensamt SOA-team bestående av olika
IT-experter som har ansvar för att utforma integrationen av systemen och föra en dialog med
alla affärsenheter i SOA-relaterade ärenden.
Tjänsteutvecklingen: Utvecklingsenheter för tjänster har nu en gemensam bas av dokumenterad kunskap med samlade erfarenheter, best practice och riktlinjer för tjänsteutveckling liksom bättre utvecklingsverktyg och en mer kontrollerad testmiljö.
Styrning: En tjänst kan på den här mognadsnivån användas av flera applikationer och system
samtidigt vilket medför krav på riktlinjer för styrd versionshantering och förändringsledning
så att modifiering och induktion av tjänster kan ske under standardiserade former.
Utmaningar , fördelar och risker med nivå 2:
Service Bus-komponenten är en stor utmaning att implementera då den bygger på ny standard
och teknik som utvecklarna måste kompetensutbildas för. Det är dessutom väldigt viktigt att
tillgänglighet och prestanda beaktas men framförallt att den är möjlig att skala upp så det växande utbudet av tjänster kan hanteras. Den huvudsakliga nyttan med att uppnå nivå kommer
från det enhetliga gränssnittet (API) som erbjuder ett standardiserat sätt att bruka tjänsterna.
21
Riskerna på den här nivån är kopplade till acceptansen från främst utvecklarna av den nya
standarden och teknologin samt flexibilitet och driftsäkerhet hos SB-komponenten som blir en
central byggsten för vidare utveckling av SOA.
Nivå 3, Administered SOA
Den tredje nivån av SOA-mognad kännetecknas av arrangerade tjänster, vilket innebär att de
systemorienterade tjänster som integrerades på nivå 2 nu arrangeras i konfigurationer så
funktionaliteten de bidrar med fokuseras i linje med verksamhetens processer (alignment)
(Figur 7).
Figur 7: iSOAMM nivå 3 (Rathfelder & Groenda, 2008)
Tjänstearkitekturen: Det lager inom vilket tjänsterna arrangeras i mönster som stödjer verksamhetens processer är det arkitekturella tillskottet i mognadsnivån. Arrangemangen av tjänster i mönster som följer logiken i verksamhetens processmönster måste tidigare programmeras
direkt i verksamheternas olika användarapplikationer. Som ett komplement till de mönstrade
tjänstearrangemangen görs en standardisering av relevanta affärsdatatyper. Detta innebär att
informationsdata hos exempelvis ”kund” blir enhetligt och får en gemensam struktur så det
inte behöver konverteras i transaktioner mellan olika system och tjänster.
Infrastukturen: Instruktionerna som styr hur tjänsterna arrangeras i mönster är processbeskrivningar och inte körbar kod. Sådana processinstruktioner behöver därmed en exekverande
miljö, en slags mönstermotor som därför måste adderas till infrastrukturen. Servicebussen
måste också utökas med ny funktionalitet vilket i sin tur kräver omgärdande infrastruktur för
övervakning, säkerhet och kommunikation. Övervakande infrastruktur hanterar tjänsternas
prestanda och stabilitet medan säkerhetsinfrastuktur styr tillgänglighet baserad på åtkomsträttigheter.
Organisationsstrukturen: Funktionalitet och data som förmedlas av en tjänst kan delas in i
tjänstedomäner som exempelvis ”kundhantering” och ”orderhantering”. Ansvaret för tjänstedomänernas funktionalitet hanteras ofta av respektive verksamhetsavdelning som kan hantera
den genom en IT-enhet inom avdelningen eller delegera till en gemensam IT-funktion. SOAteamet som på nivå 2 bestod av IT-experter inkluderar nu verksamhetskunniga från de olika
avdelningarna vilket ger en organisatorisk konstellation som reflekterar den högre graden av
alignment. SOA-teamet styr centralt hur tjänsterna indelas i domäner och standardiseringen av
affärsdatatyper.
22
Tjänsteutvecklingen: Den gemensamma kunskapsbasen och utvecklingsverktygen som används av tjänsteutvecklarna är avancerad och utvecklingen automatiseras i ökande grad. Detta
åstadkoms exempelvis genom användande av modell-drivna programmeringsspråk speciellt
framtagna för utveckling av mönsterarrangerade tjänster. Standardiserade tjänster är enklare
att hantera i modeller på en högre abstraktionsnivå och driftsätta med automatik än integrerade tjänster.
Styrning: Organisationsövergripande regler som dikterar att hur den tjänsteorienterade ansatsen skall användas i hela IT-miljön etableras. SOA-teamet kan tillåta undantag från regelverket när de bedömer att det kan motiveras. Eftersom tjänster nu kan stödja flera processer samtidigt och även utanför de domäner som tillhandhåller dem så måste kostnadsdebiteringen
styras så att den del av verksamheten som producerar tjänster inte straffas ekonomiskt genom
ökande driftskostnader. Även regler för tillgång till tjänster med hänsyn till säkerheten adresseras på den här nivån inom ramen för styrning.
Utmaningar , fördelar och risker med nivå 3:
Utökningen av infrastrukturen för att kunna hantera de nya kraven på säkerhet och övervakning är förvisso en betydande engångsinvestering men den kompliceras ytterligare av att
framtida behov måste förutses. En annan utmaning blir att skapa en utvecklingsmetod för orkestreringen av tjänster.
Möjligheten att arrangera tjänster i mönster som stödjer verksamhetsaktiviteter och dessutom
snabbt kan arrangeras om i nya konstellationer när verksamhetsbehoven förändras är just den
klart största fördelen med att uppnå nivå 3 i SOA-mognad. Den högre och nu hållbara alignment mellan IT och verksamhet som nu är möjlig ger inte bara snabbare driftsättning av nya
”front end” applikationer utan minskar också redundanta insatser tack vara det disciplinöverskridande samarbetet. Tjänster kan dessutom nu återanvändas i flera processer tack vare standardiseringen av affärsdatatyper. Modulariseringen separerar affärslogiken från datalager och
användargränssnitt vilket ytterligare ökar organisationens agila förmåga. Riskerna ligger dels
i nödvändigheten med att lyckas strukturera om organisationen och dels i att samma tjänster
nu används i många och ofta vitt skilda verksamhetsprocesser så om en frekvent använd tjänst
fallerar så påverkas många olika delar av verksamheten samtidigt.
Nivå 4, Cooperative SOA
Det som främst utmärker den här mognadsnivån är introduceringen av Service Level Agreements (SLA), som är ett avtal mellan brukare och leverantör av tjänster vilket reglerar och
säkerställer en garanterad servicenivå på tjänsten vad gäller omfattning och kvalitet så länge
brukaren använder tjänsten inom ramen för en specifik användarprofil. Ytterligare ett arkitekturlager har introduceras för att integrera tjänster och processer. Värt att notera är att man särskiljer också mellan externa B2B-processer, vilka i regel är automatiserade och interna processer som innefattar moment utförda av människor.
23
Figur 8: iSOAMM nivå 4 (Rathfelder & Groenda, 2008)
Tjänstearkitekturen: B2B och användarinteraktioner är de två utmärkande processmönster
som karaktäriserar tjänstearkitekturen, var för sig eller i kombination. För att kunna hantera
B2B behöver lagret kunna koreografera processer (samordna i sekvenser), vilket kan jämföras
med orkestrering av tjänster vilket är arrangemang av enbart tjänster i mönster (Figur 8). Eftersom användarmoment är en del i verksamhetsprocesser, går det inte att implementera processer genom orkestrering. Vanligen sker presentationen av användarmomenten i en process
genom en portal där de mänskliga aktörerna kan interagera i processen. Andra utmärkande
verktyg som blir tillgängliga genom processhanteringslagret är affärsregler vilka ger möjlighet till flygande ändringar av processer och händelsehantering eftersom verksamhetsprocesser ofta är starkt påverkade av omvärldshändelser.
Infrastukturen: Introduktionen av ett processlager ställer nya krav på infrastrukturen, dels
behövs ett regelverk som kan hantera processernas affärsregler och dels krävs nya infrastrukturella komponenter. Liksom orkestreringen av tjänster så kräver även processerna en exekverbar miljö som kan tillhandahålla ny funktionalitet i form av sekvensstöd för processhantering (koreografering) och stöd för användarinteraktion. Generellt utformas processer av affärskunniga snarare än av IT-experter vilket ställer krav på integration av de semantiska beskrivningarna av processer och tjänster. De SLA:er som används på den här mognadsnivån
introduceras i regel vid implementationen av en tjänst och ändras därefter sällen men det
krävs ändå noggrann övervakning av tjänsterna och processernas tillstånd och prestanda för
att säkerställa att de fungerar inom ramen för deras avtal. Även infrastrukturen för säkerhetsövervakningen måste utökas till att omfatta den data som används vid tjänsteanropen.
Organisationsstrukturen: Indelningen av organisationen med ansvar som motsvarar tjänstedomäner förfinas ytterligare genom att indelas i mindre specialiserade enheter. Det är möjligt
att bryta ned organisationsstrukturen till en så extrem nivå att en grupp kan ha ansvar och vara
specialiserad för att sköta en enda enskild tjänst. Ny affärsmässig funktionalitet handlar därmed inte enbart om att komponera ihop nya konstellationer av tjänster utan också att matcha
dessa med interdisciplinära grupperingar av verksamhetskompetenser. Det krävs dock fortfarande en separat IT-avdelning som kan hantera infrastrukturen.
24
Tjänsteutvecklingen: Utvecklingsprocessen måste beakta affärsregler och händelser, vilka
ramar och möjligheter detta medför. Utvecklingsteamen använder grafiska modeller för att
utforma processer och arrangera tjänster i mönster (koreografering och orkestrering), modeller
som sedan direkt kan omvandlas till körbar kod. Användandet av grafiska modeller i tjänsteutvecklingen underlättar för affärsexperter att implementera verksamhetslösningar i tekniska
system. Den utökade säkerhetsinfrastrukturen och introduktionen av SLA:er påverkar även
utvecklingen av tjänster. SLA:er innehåller kvalitativa parametrar vilka måste hanteras av
tjänsteutvecklarna så att QoS (Quality of Service) kan mätas och matchas mot den QoS som
garanteras av tjänsteleverantören. SLA:erna innehåller även kostnaden för att använda tjänste
vilket medför att det går att kostnadsoptimera tjänster efter kvalitetskrav.
Styrning: Från den här mognadsnivån måste alla nya IT system implementeras med en tjänsteorienterad ansats och alla gamla ”legacy”-system måste förses med tjänstebaserade gränssnitt och införlivas i SOA. Hanteringen av kostnader för tjänsterna som tidigare gjordes med
kompensationer regleras nu genom SLA:erna. Varje enhet kan därmed själva balansera kostnaden för nyttjandet av tjänster internt. Det finns nu istället behov av ett organisationsomfattande regelverk och en reglerande central instans som säkerställer att ingen enskild enhet
missbrukar och berikar sig genom maken över kritiska tjänster. Mätvärden och nyckeltal för
processer introduceras så att processer och SOA-implementationer kan övervakas och utvärderas löpande, vilket kan ske genom utnyttjande av den redan befintliga infrastrukturen för
övervakning.
Utmaningar , fördelar och risker med nivå 4:
SLA:er är ett nytt element på den här nivån som ställer nya krav på anställda som behöver
utbildas för att hantera de tekniska och affärsmässiga aspekterna av servicekontrakten. Eftersom användarinteraktion nu hanteras inom arkitekturen behöver infrastrukturen anpassas
för detta vilket kan vara en stor utmaning, liksom introduktionen av affärsregler är en utmaning för tjänsteutvecklarna. När avdelningarna dessutom bryts ner i mindre och specialiserade
team ökar behovet av stödfunktioner runt om i organisationen som kan bidra med service och
kompetens som inte finns i dessa små grupper. Fördelarna med ett processlager är möjligheterna det skapar för att samordna externa processer med den egna verksamheten i koreograferade flöden (B2B) och att direkt involvera manuella användarmoment i verksamhetsprocesser.
Affärsreglerna skapar möjlighet till att snabbare reagera till förändringar i verksamhetsprocesser medan SLA:er bidrar till att sådana transformeringar sker med bibehållen kvalitet. Den
mer detaljerade säkerhetsövervakningen säkerställer att förändringar kan göras i de mest kritiska verksamhetsprocesser, tjänster är lättare att hitta för verksamhetskunniga tack vare möjligheten till semantiska sökningar och händelser i verksamhetsprocesser kan kopplas direkt
till berörda IT-processer. Riskerna med att introducera ett processlager och affärsregler är
relativt små ut ett IT-perspektiv medan följderna detta innebär för struktureringen och arbetsflöden i organisationen är omfattande, vilket kräver stort och helhjärtat stöd av de anställda
eftersom SOA på nivå 4 är helt avgörande för om organisationen skall kunna nå sina affärs
mål.
Nivå 5 On Demand SOA
Genom den föregående mognadsnivån introducerades SLA:er vilket skapar möjlighet att utannonsera tjänster med krav på service nivåer (QoS). Detta föranleder tjänsteleverantörer att
undersöka om de kan möta kraven och kanske i sin tur efterfråga nya tjänstenivåer i avtalen
(SLA) med sina underliggande tjänsteleverantörer. Detta skapar en förhandlingskedja som om
den kan automatiseras möjliggör korta servicekontrakt utöver de långa kontrakt som etablera25
des i nivå 4. Det blir därmed också möjligt att upphandla enstaka tjänster på en gemensam
marknad för leverantörer och brukare genom automatisk förhandling.
Tjänstearkitekturen: Det krävs en motsägelsefri och uttömmande gemensam beskrivning av
tjänster och databegrepp, en enhetlig semantik mellan leverantörer och brukare, eftersom den
statiska bindningen av tjänster ersätts av en dynamisk bindning. Det behövs också styrande
regler som säkerställer valet av den mest passande tjänsten bland de tjänster som tillgodoser
de kvalificerande kraven.
Infrastrukturen: En plattform, en s.k. marknadsplats behöver etableras inom infrastrukturen
som stödjer processen för automatiserad sökning och försörjning av tjänster. Det är möjligt
för en sådan marknadsplats att använda flera olika anskaffningsmodeller som exempelvis öppen auktionering av tjänster eller val bland alternativa erbjudanden. Introduktionen av automatisk upphandling av tjänster medför också att flera infrastrukturella komponenter måste
implementeras som stödjer automatisk SLA förhandling och urval av tjänster. För att bästa
möjliga effektivitet vid brukandet av tjänsterna skall kunna vara möjlig måste de arrangerade
tjänsterna och koreograferade processerna övervakas i minsta detalj.
Organisationsstrukturen: Det är endast mindre ändringar i strukturen för organisationen
gentemot den förgående nivån men den automatiska försörjningen av tjänster gör att ledningen måste säkerställa en flexibilitet i organisationen att anpassa sig till snabbt förändrade krav
från kunderna.
Tjänsteutvecklingen: I kontrast mot tidigare mognadsnivåer sker inte valet av tjänster i designfasen utan i princip vid exekveringen. Detta innebär att tjänsteutvecklarna måste se till att
regler för hur tjänster väljs ut måste definieras och formuleras redan i designarbetet. Tjänsteutvecklingen har nu utvecklats i sig från fokus på att sätta samman paket av tjänster till att
bygga färdig funktionalitet där de ingående paketen av orkestrerade tjänster och koreograferade processer automatiskt kan kontakta en marknadsplats och anskaffa de underliggande
tjänster som krävs i leveransen av varje funktion.
Styrning: Övervakningen av verksamhetsprocesserna ha nu utvecklats till Business Process
Management (BPM) vilket syftar till att kontrollera och optimera verksamhetsprocesserna.
Den dynamiska automatiserade upphandlingen av tjänster gör att övervakningen av att de
regler, som etablerades i den föregående mognadsnivån, efterlevs nu också måste ske automatiskt.
Utmaningar, fördelar och risker med nivå 5:
Utmaningarna på nivå 5 är mycket stora och kräver ett helt nytt tankesätt. Erbjudande av
tjänster ersätts nu av fördefinierade kvalitetskrav som styr förhandlingen, detta innebär att
brukaren nu kan ställa direkta krav som leverantören strävar efter att möta. Det en förutsättning att alla aktiviteter i samband med själva driften av SOA måste automatiseras för att tilllåta den dynamiska kopplingen och urvalet av tjänster. Detta är inte bara en teknisk utmaning
utan innebär stora förändringar för de anställda som tidigare arbetat med dessa uppgifter. Nyttan med att uppnå nivå 5 är att en övergång till en automatisk, ”on demand” tjänsteförsörjning
medför en än mer flexibel och snabb anpassning av organisationen för att möta kundens behov. Dessutom medför den avancerade underliggande infrastrukturen att resursanvändningen
kan optimeras. Misslyckas organisationen däremot att förverkliga det nya ”on demand” synsättet uteblir också alla fördelar. Slutligen finns också risken att chefer och ledare i organisat26
ionen misstolkar ansatsen och anser att full automatisering innebär förlorad kontroll och därför avfärdar SOA.
2.5 Egen modell
Denna sektion av vår uppdragsrapport syftar till att ge en samlad bild () av det perspektiv vi
valt för att undersöka den arkitekturella problematiken organisationer konfronteras med vid
planeringen av implementationen av molntjänster. Perspektivet är baserat på den inhämtade
kunskapen från den teoretiska litteraturen med tyngdpunkten på den potential och begränsning som en serviceorienterad arkitektur skapar i relation till hur avancerad och framträdande
den är.
Figur 9 Egen modell av vårt valda teoretiska perspektiv
Vi tänker oss att en given organisation utgår från en traditionell EA med målsättningen att
implementera molntjänster i hela eller delar av sin verksamhet. För att lyckas med detta utgår
vi från att organisationen måste transformera sin innevarande arkitektur (migrera) stegvis till
en SOA. Varje steg öppnar nya implementationsmöjligheter men medför också nya utmaningar och risker eftersom arkitekturen omformas och ökar i komplexitet. För att undersöka
hur dessa möjligheter, utmaningar och risker kan se ut i den tjänsteorienterade arkitekturens
planerade transformeringsprocess, granskar vi den genom teoretiska linsen från iSOAMM.
Detta innebär att vi tematiserar vår undersökning och analyserar tjänstearkitekturen, infrastrukturen, organisationsstrukturen, tjänsteutvecklingen och styrningen i samband med den
stegvisa utvecklingen av en SOA.
Den stegvisa utvecklingen av SOA blir således vår teoretiska fokuspunkt med traditionell EA,
implementation av molntjänster och molnfenomenet som omgärdande teoretisk referens vilket
förhoppningsvis skapar en bättre kontextuell belysning av problemområdet (Figur 9).
27
3. Empiri
3.1 Demografi
3.1.1 Bo Orskarsson
Oskarsson har arbetat med affärssystem sedan 1972 på de flesta tekniska plattformar och affärssystem i huvudsak inom industrin. Oskarsson har mer en praktisk erfarenhet än en teoretisk. Idag
har Oskarsson en titel på företaget EVRY som Produkt och marknadschef för ERP Jeeves.
Oskarsson jobbar ideellt för handelshögskolan inom Göteborgs Universitet. HAN sitter med i
styrelsen för ”centrum för affärssystem” på handelshögskolan inom Göteborgs universitet. Där
han är den enda som är ”assosiated fakulty”. Han är även en av huvudsponsorerna till handelshögskolan. Orskarsson är näringslivsrepresentant och sponsor för Scandinavian Academic Network
for Teaching Enterprise Systems (SANTE). SANTE är ett samarbete för användning av affärssystem i akademisk undervisning samt forskning. SANTE ser affärssystem som en pedagogisk möjlighet att visualisera samt simulera verksamheter. Genom SANTE kan utbildningen av ekonomer,
ingenjörer och systemvetare förses med verksamheter som i sin tur har möjlighet att anställa studenter (santeacademy.se, 2012). Oskarsson har även undervisat i flera av Sveriges högskolor.
Dessa undervisningar kan tillexempel behandla process baserad utveckling och integration.
3.1.2 Evry
Evry är ett norskt bolag som anses vara nummer ett inom norden när det gäller IT och nummer två
inom Sverige. Evry har i dagsläget 10 000 anställda och omsätter 13 miljarder per år. Företaget
inriktar sig i huvudsak på drift och på outsourcing. Inom Sverige kallas företaget Evry One (evry.com/one). Enligt deras webbplats så inriktas sig Evry One på branch miljöer inom området ITinfrastruktur. Evry levererar traditionell IT-drift, applikationsdrift samt leverans av infrastruktur
som en kapacitetstjänst (cloud computing). Oskarsson anser att inom industrin arbetas det mycket
idag med grön IT och återanvändning av kod, lösningar, Macro, SOA, SaaS och inbäddade objekt.
Oskarsson förklarar att trenden som finns idag är att företag vill implementera applikationer till
sina system. Utan det är, hur vi bygger nya lösningar till kunder till det som redan existerar utan
att börja om från början varje gång.
3.2 Intervju resultat
Tjänstearkitektur
Bo Oskarsson anser att tjänstearkitekturen hos företag behöver ha en stomme som de kan
bygga sin arkitektur mot. Han menar att vissa avdelningar inte accepterar lösa kopplingar och
snabbt utbytbara objekt utan kräver enhetlighet och väl inarbetade system. Han exemplifierar
detta genom att prata om ekonomerna och deras krav på att företaget köper något av de affärssystem som är kända från en utvald leverantör (exempelvis Jeeves, SAP eller IFS) och implementerar det i sin helhet, sedan kan ekonomerna tillåta att man adderar ytterligare tjänster
som inte är kritiska utan ger någon form av mervärde genom visualisering i analysverktyg etc.
Oskarsson menar att ekonomer vill extrahera ekonomiska data från alla verksamhetsgrenar
och centralisera denna i system byggda efter rigorösa redovisningsprinciper och har absolut
ingen tolerans för lösa kopplingar som utmärker molnbaserade lösningar. Ekonomernas synsätt är det mest extrema men även företaget i stort vill ha en baslösning och sedan optioner för
att expandera och integrera denna bas med företagets unika lösningar, de system som stödjer
företagets unika erbjudande. Oskarsson menar att SOA huvudsakligen bidrar som komplement till den befintliga arkitekturen när det gäller just att integrera det standardiserade affärssystemet som utgör kärnan i systemmiljön med de specialiserade system som skapar mervärdet.
28
“Hela informationssystemet bygger på kopplade objekt eller mindre löst kopplade objekt, men
relationer till ekonomerna vill extrahera allt utifrån verksamheten som skall organiseras i
kostnader, konto med mera i deras egna system, vilket resulterar i dubbel-lagring av data.“
Bo Oskarsson
Oskarsson illustrerar sin ståndpunkt genom en serie metaforer. I den första metaforen liknar
han grundsystemet vid ett modul byggt standardiserat hus. Kunden väljer ett hus med en
planlösning som täcker grundbehovet, det skall finns kök, gemensamma rum , ett antal sovrum som alla hänger samman på ett funktionellt standardiserat vis. Varje rum vill däremot
kunden själv kunna inreda och välja mellan olika alternativ som vilken typ av spis, paneler,
tapeter och träslag osv. Det är också viktigt att huset placeras mitt på tomten så det finns utrymme att bygga till huset vid behov.
I den andra metaforen beskriver Oskarsson affärssystemet som en oklädd julgran. Där själva
stommen i julgranen är affärssystemet och där julgransfoten är ekonomiavdelningen. I denna
stomme skall all information flöda. Detta medför att leverantörer mer eller mindre tvingas att
utgå från de befintliga kärnsystemen vilket i praktiken innebär affärssystemet. De olika grenarna som julgranen har är de olika avdelningar som verksamheten innehåller. När företag
skall köpa in sina SOA objekt handlar det om att klä julgranen med olika dekorationer. Dekorationerna som inhandlats bör då falla in i den kontext som en julgran har. Kärnan som system
integreras mot anses vara ett måste och även om olika objekt kan prata med varandra måste
dessa objekt förankras mot någonting samt att de lösningar som läggs till skall anpassas till
verksamheten i sig. Det grundläggande i en tjänstearkitektur bör anpassas till syftet och verksamhets mål, det vill säga klä julgranen med objekt som passar in i kontexten.
Infrastruktur
Oskarssons grundläggande åsikt angående den infrastrukturella aspekten är att den idag spelar
en mycket liten roll, vilket han menar beror på att i princip allt går att lösa rent infrastrukturellt sett. Oskarsson uttrycker detta genom bland annat följande citat:
“Rent tekniskt skulle man kunna åstadkomma vilken mognadsnivå
som helst. I slutändan handlar det endast om pengar.”
Bo Oskarsson
Vidare påpekar Oskarsson också att det till viss del handlar om kompetens, och vikten av att
ha rätt personal (kompetent) på rätt plats. På frågan om huruvida säkerheten påverkar den
infrastrukturella aspekten svarar Oskarsson att det delvis handlar om pengar även här, men att
det i övrigt är vad han kallar för ett “icke-problem”. Han menar att i det fall ett företag kräver
högsta möjliga säkerhet, så är det enbart en kostnadsfråga, som ofta löses genom olika former
av krypterade tunnlar och länkar mellan moduler och verksamhetsenheter. Oskarsson fortsätter;
“Det är [säkerhetsmässigt] ingen skillnad mellan att koppla upp
mot en server inom verksamheten jämfört mot en någon annan
stans i världen.”
Bo Oskarsson
29
En grundsten hos infrastrukturen är dess kapacitet att understödja framtida behov, eventualiteter och adderandet av nya moduler, vilket till stor del har med gemensamma standarder att
göra.
Oskarsson anser att de största problemen med infrastrukturen är standardiseringen av processer, komponenter med mera, och att standarder i de olika komponenterna är ett måste. Genom
att standardisera kärnprocesser kan verksamheter och användare skapa samstämmighet, flexibilitet och konsistens. Genom att ha en gemensam standard så kan olika objekt kopplas till
varandra.
“Det är samma slags problem som när det finns 4 olika fält för datum.
Vilket fält använder jag?”
Bo Oskarsson
Enligt Oskarsson så är standardmeddelandet det universella inom en verksamhet. Genom att
ha en gemensam standard kan system prata med varandra. Det handlar om att försöka skapa
synergi. Finns det standarder inom ett företag kan olika processer utformas med objekt som
stödjer de kärnprocesser som är definierade. Detta medför att infrastrukturen kan bistå processerna som önskat och att objekt kan kopplas på och av efter behov. Oskarsson nämner problemet med att det finns många olika standarder i branschen och att dessa kan skilja sig mellan olika kontinenter samt leverantörer. Han nämner även att standarder kan skapa inlåsningseffekter för brukaren och svårigheten med att enas om gemensamma standarder kommer sig
av att utvecklare vill tjäna pengar i slutändan.
Organisationsstruktur
När det gäller organisationsstrukturen menar Oskarsson att problematiken är tvådelad; dels
handlar det om ansvarsfrågan och dels om samverkan mellan olika grupper av objektägare. I
ansvarsfrågan ser han problem när företaget har flera leverantörer av tjänster. Företag efterstavar att hitta en partner som tar ett helhetsansvar och därmed bara har en kontaktpunkt
om systemlösningen skulle fallera. Är det flera aktörer inblandade måste man dels själva hitta
vilket del av systemet som inte fungerar och sedan identifiera vilken leverantör som ansvarar
för den delen. Har verksamheten dessutom endast en leverantör får de inga problem med flera
standarder som inte fungerar ihop, leverantören ansvarar för att alla delarna i systemet fungerar ihop inom ramen för den standard som leverantören använder.
Vad gäller företagets interna samverkan menar Oskarsson att det finns täta skott mellan verksamhetsavdelningarna och i än högre grad mellan stödjande funktioner som IT och ekonomi
vilka är ännu mer särpräglade i sina arbetsprocesser. För SOA innebär detta att det endast blir
en vacker tanke med gemensamt ägda tjänster med ett interdisciplinärt ansvarstagande. Verkligheten är att budgeten, kulturen och traditionen för varje avdelning styr och gränsöverskridande samarbete är alldeles för komplicerat och tidskrävande.
Tjänsteutveckling
Oskarsson anser att när lösningar och tjänster skall utvecklas och implementeras är det viktigt
att standarden är den samma. Detta för att de skall kunna kopplas till kärnan i verksamheten
men även kunna kopplas ur lika lätt. Det är även bra att hålla sig till en leverantör då denna
ofta har en enda standard som den använder. Företag bör inte ägna sig att utveckla sina egna
tjänster utan köpa dessa färdigutvecklade av en leverantör. Enligt Oskarsson kan företag möjligen ägna sig åt att kvalitetssäkra i gränssnitten mellan olika system. Oskarsson pekar på
orimligheten i att företag ägnar sig åt tjänsteutveckling genom att hänvisa till ett projekt där
30
IBS 1995 försökte utveckla ett stort klassbibliotek som man sedan kunde plocka ihop skräddarsydda funktioner av. Efter att ha investerat över 100 miljoner så lade man ner projektet
eftersom det kostade för mycket och tog alldeles för lång tid att genomföra. Oskarsson menar
att möjligen kan man tänka sig att man utvecklar applikationer för mobila lösningar eftersom
dessa inte skriver data utan endast läser i de befintliga systemen.
Styrning
De visioner som verksamheter har är att vara unika i sin egen kategori. Detta kan vara svårt
att bli enligt Oskarsson då verksamheter oftast vill handa med beprövad teknik. Genom att
köpa beprövad teknik utsätter sig inte verksamheten för långa “pay off” tider. Enligt Oskarssons anses den optimala ”pay off” tiden vara inom 18 månader för en verksamhet. Det kan
vara svårt för ett företag att besluta sig om vilka SOA lösningar som är lämpliga för verksamheten, och frågor om vilka typer av standarder som finns, och vad SOA är, uppkommer ofta.
Organisationer vill helst ha mätbara mål att förhålla sig till i en implementation. Företag vill
särskilja sig från sina konkurrenter och ha en rörlighet i sitt erbjudande. Oskarsson menar att
SOA visserligen erbjuder viss flexibilitet och unika lösningar men att utvecklingstakten är
alldeles för långsam.
”Användares behov är ett hållbarhetsperspektiv som jag har som leverantör. Men då måste
jag gjuta grunden bra för att kunna sedan byta ut komponenter och vara väldigt förutseende
på vad jag tror kommer att komma i framtiden. Leverantören måste ha ett framtidsperspektiv.
Vem ska ta detta beslutet? Det är SOA-teamet och master planen. Vem är det som bygger
master planen? Master planen är inte svår att förstå, så länge den är inom organisationen
men så fort verksamheten tar in externa tjänster som leverantören inte känner till. Hur gör
jag då?”
Bo Oskarsson
Enligt Oskarsson skall masterplanen vara så flexibel att den tillåter vissa objekt i periferin
enkelt kan bytas ut. Den centrala styrningen skall förse verksamheten med en gemensam semantik, ett samförstånd kring centrala objekt som “kund” och “artikel” samt formulera en
övergripande målbild så att alla är eniga kring företagets riktning och utvecklingsnivå.
31
4. Analys och diskussion
4.1 Effektorienterad arkitektur, moln och migration
Det finns en fundamental skillnad i motiv mellan en organisations vilja att bygga en EA och
dess vilja att förändra sin EA till en tjänsteorienterad EA, det vill säga SOA. Motivet bakom
att skaffa en EA är att få ordning och reda i en informationsmiljö som ofta är präglad av en
dysfunktionell arkitektur i form av spagettistrukurer, informationsöar och informationsbyråkratier (Magoulas & Pessi, 1998). Motivet bakom att skaffa sig SOA är däremot att utifrån en
befintlig EA vidareutveckla arkitekturen för att bättre överbrygga klyftan mellan verksamheten och IT med hjälp av en tjänstebaserad ansats (Arsanjani, 2004). En annan anledning till att
förändra sin befintliga arkitektur kommer från företagets önskan att skaffa sig de nyttoeffekter
som förknippas med molntjänster, exempelvis lägre driftkostnader, snabba programuppdateringar, lagringskapacitet, universell tillgång och tillförlitlighet (Miller, 2009). Bo Oskarsson
hävdar likaledes att organisationer som överväger att skaffa sig molntjänster gör så med utgångspunkten att dessa skall integreras med en befintlig traditionell systemarkitektur. Han
menar att den befintliga arkitekturen representeras i hög grad av en fast grundstruktur som
utgörs av affärssystemet. Detta kan tyckas vara en förenklad syn på arkitekturbegreppet men
belyser ändå i någon mån kopplingen mellan EA och SOA, där SOA måste ses som en specialiserad enterprise arkitektur som är ett komplement till traditionell EA eller i avancerad form
en komplett transformation av EA.
4.2 Arkitekturell mognad
Rathfelder & Groenda (2008) beskriver att om en verksamhet skulle vilja migrera till SOA
behövs en viss mognad; en förmåga att dra nytta av arkitekturens egenskaper på ett sådant sätt
att nyttoeffekterna av tjänsterna kan realiseras. SOA-mognaden hos den egna organisationen
är progressiv så att ökad mognadsnivå medför nya egenskaper och därmed blir fler nyttoeffekter möjliga att uppnå. Genom att använda en mognadsmodell kan verksamheter diagnostisera sin nuvarande EA-mognad och planera en kontrollerad migration till den mognadsnivå
som skapar förutsättningar för de önskade nyttoeffekterna (Rathfelder & Groenda, 2008).
iSOAMM är en sådan mognadsmodell som belyser SOA-mognad i fem nivåer genom att undersöka arkitekturen från fem olika SOA-perspektiv; tjänstearkitektur, infrastruktur, organisationsstruktur, tjänsteutveckling och styrning.
Tjänstearkitektur
Tjänstearkitekturens uppgift är att knyta samman de olika arkitekturella lagren (jämför Pessi,
2012: Figur 1). Många av de önskvärda nyttoeffekterna manifesteras tydligast genom detta
perspektiv och det är också här man ser effekten av vad skillnader i mognadsnivå innebär i
förlängningen. Bortsett från nivå 1 som är en enkel instegsnivå utan genomslag i organisationen så innebär varje steg stora förändringar i organisationens kapacitet att agera samordnat
och dra nytta av tekniken i verksamheten. Speciellt mellan nivå 2 och 3 sker en förändring
från en nivå där applikationer och system endast länkas samman och integreras med hänsyn
till tekniken till att sådan integration sker som en reflektion av hur verksamheten faktiskt fungerar. Effekten blir att verksamhet och informationslager knyts närmare samman och faktisk
hållbar alignment blir möjlig. Rathfelder och Groenda (2008) hävdar att det är här vi finner de
flesta av verkliga organisationer som på allvar arbetar med att försöka implementera SOA och
att majoriteten av dessa i sin tur lyckas åstadkomma integration av systemen men att det är
32
svårare att lyckas orkestrera tjänster efter verksamhetens mönster och därmed misslyckas
med hållbar harmonisering alternativt uppnår endast skenbar eller tillfällig alignment.
Bo Oskarsson beskriver emellertid en helt annan bild av problematiken och hävdar att kritiska
system måste vara enhetligt integrerade för att utgöra ryggraden i arkitekturen som alla andra
system måste förhålla sig till. Han tänker sig att en sådan ryggrad, stomme i arkitekturen på
sin höjd endast kan delas upp i moduler men att alla dessa moduler då måste utvecklas av en
och samma leverantör. På så vis får man en kärnarkitektur som har en given sammansättningsplan. Han jämför detta med att köpa en byggsats med en fixerad design, som ett legobygge med ett tema som exempelvis “Star Wars” där delarna endast kan kopplas samman i ett
logiskt mönster för att resultatet skall bli meningsfullt.
Infrastruktur
Infrastrukturens uppgift är enligt Rathfelder och Groenda (2008) att i en tjänsteorienterad arkitektur, genom ett gemensamt kommunikationslager, försörja tjänsterna med nödvändig information. Detta ställer således en del krav på en befintlig eller planerad infrastruktur, eftersom att en stabil infrastruktur är en förutsättning för flexibilitet bland tjänsterna (Rathfelder
& Groenda, 2008). Oskarsson hävdar emellertid att en infrastruktur som fullt ut stödjer en
tjänsteorienterad arkitektur i dagens läge, rent tekniskt, inte är något problem. Han menar att
det endast rör sig om en kostnadsfråga, vilket borde innebära att man med dagens teknik kan
åstadkomma alla nivåer av infrastrukturell mognad, om så önskas. Säkerhetsaspekten av en
expanderande infrastruktur är något som ökar i takt med mognadsgraden, och ju högre mognad desto högre krav på säkerhet uppstår enligt iSOAMM-modellen. Angående säkerhetsaspekten gör Oskarsson gällande att det endast rör sig om mycket små skillnader mellan de
olika nivåerna i dagens läge, och menar på att man idag nyttjar samma typ av tekniska lösningar, och därmed nivå av säkerhet, vid exempelvis intern som extern serverdrift, vilket
torde innebära att säkerhetsaspekten idag blivit mindre kritisk.
Oskarssons åsikt gällande problematiken kring standardisering av komponenter och processer
i infrastrukturen, återfinns även inom den infrastrukturella aspekten av iSOAMM. Rathfelder
och Groenda (2008) menar att det krävs standardiserade processer och arbetssätt för att nå de
högre mognadsnivåerna, och detta kan bekräftas till viss del av Oskarssons resonemang kring
att standarder möjliggör en tjänsteorienterad infrastruktur. Standarder är också den bit av infrastrukturen som Oskarsson anser vara mest problematisk, och därmed troligen ett kritiskt
område för en organisation som tänkt utveckla sin infrastruktur mot en tjänsteorienterad sådan. Oskarsson menar alltså inte att infrastrukturen i sig är oviktig, utan snarare tvärt om; den
är av stor vikt, men med de tekniska möjligheterna idag utgör infrastrukturen oöverkomlig
problematik.
Organisationsstruktur
iSOAMMs perspektiv på organisationens struktur handlar om hur organisationens uppbyggnad behöver förändras med hänsyn till verksamhetsdelarnas ägande, ansvar och åtaganden för
de olika tjänsterna. En följd av en tjänstebaserad ansats innebär att ökande grad av gränsöverskridande samarbete mellan olika avdelningar hos verksamheten och dess stödjande funktioner som IT och ekonomi. På lägre nivåer i mognadsnivå är SOA-projekt en ren IT fråga medan
nivåer som ger alignment mellan IT och verksamhet kräver representation av flera discipliner
i de team som ansvarar för och styr utvecklingen av tjänster (Rahtfelder & Groenda, 2008).
Oskarsson menar att detta i realiteten bildar en barriär som motverkar att tjänstebaserad arkitektur förverkligas eftersom det finns en protektionistisk kultur inbyggd i hur företag tradit33
ionellt organiserar sig. Subjektiva värderingar baserad på avdelningens balans av resurser och
hierarkiska plats i den interna hackordningen cementerar den rigida
Tjänsteutveckling
Rathfelder och Groenda (2008) anser att utvecklingen av tjänster är en avgörande del i utformningen av SOA. Hur processen för tjänsteutveckling anpassas med ökande nivåer av
mognad är i fokus för perspektivet där den generella regeln är att ökad grad av automatisering
av tjänsteutvecklingen blir följden av ökad SOA-mognad. Den första nivån kan utveckling
ske relativt ostrukturerat, dock struktureras detta upp i nivå två gemom att verksamhetsdelar
har skaffat sig en gemensam kunskapsbas och en mer kontrollerad testmiljö. Symonds (2010)
konkretiserar detta genom vikten av att även att företag bör använda sig av en testmiljö som
kan lägga grunden till en gradvis migration. Bo Oskarsson menar att det inte finns några
större problem med utvecklingen av tjänster så länge en verksamhet håller sig till en standard
och en leverantör som hanterar utvecklingen av SOA objekt.
Styrning
Genom att verksamheter använder sig av förändringar, regelverk och riktlinjer kan ett holistiskt perspektiv eftersträvas. Beroende på vilken mognadsnivå som organisationen befinner sig
på krävs olika kontroll och styrning av verksamheten. I den första nivån finns det ingen styrning och i den andra nivån kan vissa riktlinjer efterföljas så som krav på riktlinjer. I den tredje
nivån finns det regler och förhållanden mellan olika verksamhetsdelar gällande kostnad och
tillgång till tjänster (Rathfelder & Groenda, 2008). Bo Oskarsson anser att det finns en viss
problematik i vem som har ansvaret för de olika delarna i EA. Genom att specificera en masterplan anser Oskarsson att detta kan lösas, men så fort externa leverantörer kommer in i vilken då kan denna plan ändra riktning. Genom att skapa en så flexibel plan som möjligt kan
detta hinder förbises. Här finns en skillnad jämfört med teorin. I den fjärde kontrolleras kostnader med SLA:er. Detta medför att varje verksamhetsdel kan kontrollera och säkerhetsställa
kostnader. Den femte och sista nivån innebär att alla SLA:er, regler och styrningar från de
tidigare nivåerna sker per automatik (Rathfelder & Groenda, 2008).
Enligt Bo Oskarsson så är SOA inte ett högt prioriterat alternativ för beslutsfattare då implementationen av en sådant här detaljrikt och komplext system innebär ofta en lång implementations tid. Ofta uppkommer frågor som: vad är SOA och vilka typer av standarder som finns
tillgängliga samt vilka lösningar som kan vara lämpliga för den unika situationen och verksamheten? Oskarsson själv upplever den optimala “pay off” tiden som, inom 18 månader och
detta skall då försöka eftersträvas när implementationen sker. Verksamheter vill få möjligheten att mäta mål och detta kan vara svårt när ”pay off” tiden upplevs som lång. Fördelen som
Oskarsson ser med SOA är att denna sorts arkitektur har en viss flexibilitet och unika lösningar men att den största orsaken till att implementeringen av SOA inte genomförs är den långa
utvecklingstakten.
Det är värt att notera att Bo Oskarsson ser problem med den ekonomiska avdelningen då
denna helst vill vara fristående från övriga EA. Teorin inte har tagit upp den ekonomiska
aspekten. Här finns en differens som kan komplicera SOA-implementationen, dock säger migrationsteorin Symonds (2010) att det är lättare att börja med att flytta ut SaaS-delar än att
börja med starkt etablerade verksamhetsdelar.
34
4.3 Holistisk syntes av migrationskunskapen
Genom att väga samman teori och empiri får vi en holistisk förståelse av hur SOA verkar som
grundförutsättning för en migration till en systemansats där tjänster länkar samman systemen.
Figur 10, Holistisk perspektiv över migrations ansats till moln (Egen modell)
Figur 10 (ovan), som är en reviderad version av vår tidigare egna modell, visar på sambandet
mellan SOA-mogand och molntjänster men också på kunskapen från teori och empiri ger insikt om vad som är realistiskt idag och vad som kan vara möjligt imorgon.
1. Nivå 1-2: Realistiskt integrationsalternativ
Bo Oskarsson förespråkar en modulbaserad ansats som fungerar väl i organisationer med en
mognadsnivå av 1 och 2. Han anser däremot att idag är detta gränsen för vad man kan uppnå i
SOA mognad och därmed begränsas också implemantionsalternativen och i förlängningen
även de nyttoeffekter som går att uppnå genom en tjänsteanstas.
2. Nivå 3: Alignment & effektrealisering
Rathfelder och Groenda (2008) visar emellertid på att det finns företag som lyckas att åstadkomma SOA med mognadsnivå 3, och att detta har inneburit att alignmenteffekter mellan
informationssystemen och affärsverksamheten faktiskt realiseras i praktiken. Detta sker genom att systemanrop orkestreras samman i mönster som imiterar den verkliga arbetsprocessen
i verksamheten. Därmed samlas en logik som följer mönster från verksamheten i en tjänst
som sedan kan användas om och om igen i många verksamhetsdelar och som dessutom blir
enkelt utbytbar och därigenom skapar flexibilitet, anpassningsbarhet och återanvändning i
arkitekturen.
3. Nivå 4-5: Forskningsnivå & science fiction
Både teoretiker (Rathfelder & Goenda, 2008) och praktiska utövare (Bo Oskasson) är däremot
helt överens om att de mest avancerade nivåerna 4 och 5, inte går att återfinna hos någon känd
organisation i nuläget, men att dessa nivåer diskuteras livligt bland forskare då de innehåller
löften om nya värdefulla effekter som kan uppnås genom den tjänstebaserade arkitekturella
ansatsen.
35
5. Slutsats
Syftet med denna studie var att exemplifiera vad företag bör ha i åtanke vad gäller den egna
förmågan att implementera en tjänsteorienterad arkitektur. Innehållet i studien ämnar öka
verksamheters medvetenhet i planeringsfasen och vilka utmaningar som kan komma vid implementationer av en SOA samt hur EA skall hanteras innan en verksamhet kan implementera
molntjänster. Frågeställningen till uppsatsen var:
Vad skall företag tänka på vad gäller den egna förmågan att åstadkomma en tjänsteorienterad arkitektur innan en implementation av molntjänster?
Genom att analysera och diskutera det insamlade empiriska materialet med utgångspunkt i
studiens teoriavsnitt, kan följande slutsatser dras:
•
Företag bör ha en god kunskap kring vilka effekter som eftersträvas med implementationen, samt genom att testa och analysera olika utgångspunkter kan de önskade effekterna åstadkommas. Nyttoeffekterna är differentierade vilket innebär att vissa system,
som till exempel kärnsystem, kräver högre investeringar för att migreras till moln och
har begränsade vinster om man lyckas, medan löst kopplade och specialiserade system
kan vara lättare att flytta och enklare att ta hem effekter ifrån.
•
Genom att se till vilken mognad företag eller verksamheter har i sin EA kan lämplig
nivå erhållas för verksamheten. Verksamheter Mognad hos organisationen för att
kunna implementera SOA. Företag måste vara realistiska i sin strävan och bör inte
sikta för högt utan anpassa sig till den mognads nivå som de själva är på. SOAmognad är dessutom progressiv i sin natur, vilket gör att arkitekturen måste utvecklas
evolutionärt i steg. Det är därför viktigt att alltid vara medveten var man befinner sig
och hur långt man behöver driva utvecklingen för att nå sina mål.
•
Verksamheter som fungerar på att implementera SOA bör ha en holistisk förståelse för
en migration. Kunskap, förståelse av sambandet mellan SOA och moln, där förmågan
hos den egna arkitekturen (SOA) är en minst lika viktig faktor att beakta som innehållet i själva molntjänsten oavsett om det handlar om privata eller publika moln. Löften
om vad SOA och moln kan tillföra i värde särskiljer dessutom sällan mellan vad som
är möjligt idag och vad som endast är potentiella nyttoeffekter.
Våra insikter till trots, har fokus för vår studie centrerats kring beaktandet av arkitekturens
förmåga att hantera molntjänster i planeringsfasen medan molntjänsterna själva, implantationen och påverkan av mänskliga arbetsmönster har varit en kontextuell inramning för studien
och bildar därmed några intressanta framtida forskningsämnen i ett väldigt brett forskningsfält.
36
Referenser
Aerts, A., Goossenarts, J., Hammer, D., Wortmann, J., (2004) Architectures in context: On
the evolution of business application software and ICT architectures. Information &
Management 41, pp: 781-794.
Armbrust, M., Fox, A., Griffith R, Joseph A.D., Katz, R., Konwinski, A., Lee, G., Patterson
D., Rankin, A., Stoica, I., & Zaharia, M. (2010) A View of Cloud Computin,
Communications of the ACM vol:53, no.4, pp: 50 – 58
Arsanjani, A. (2004) Service-Oriented Modeling and Architecture - How to identify, specify,
and realize services for your SOA. IBM developWorks, november 2004.
Artus, D.J.N. (2006) SOA Realization: Service Design Principles. IBM developWorks,
februari 2006.
Backman, J. (2008) Rapporter och uppsatser. Studentlitteratur: Lun
Baldwin A, Pym D, Shiu S (2012) “Enterprise information risk management: Dealing with
cloud computing”, http://www.abdn.ac.uk/~csc335/CloudRisk.pdf, Hämtad: 2012-05-01
Cearley, D., & Smith. D., (2012) “Five Cloud Computing Trenss That Will Affect Your Cloud
Strategy Through 2015”, Gartner inc, G00230221
Conway, G (2011) “Introduction to Cloud Computing” , Innovation Value Institute, National
University of Ireland Maynooth and Intel Corporation.
Denscombe, M. (2009) Forskningshandboken: för småskaliga forskningsprojekt inom
samhällsvetenskaperna. Studentlitteratur: Lund
EVRY, http://evry.se/ Hämtad: 2012-05-07
Feuerlicht, J.G. & Govardhan, S. (2009) SOA: Trends and Directions. 17th International
Conference on Systems Integration 2009, Prague, Czech Republic, June 2009 in
Proceedings of the 17th International Conference on Systems Integration 2009, Prague,
Czech Republic, pp. 149-154.
Hunter, R., (2011) “The Way of Cloud”, Gartner inc, G00226469
Ibrahim, M. & Long, G. (2007) Service-Oriented Architecture and Enterprise Architecture,
Part 1 & Part 2. IBM developWorks, april 2007.
Jacobsen, D.I. (2002) Vad, hur och varför? Studentlitteratur: Lund
Josuttis, N. M. (2007) SOA in Practice. Cambridge, Paris: O'Reilly and Sons.
Land, M., Proper, E., Waage. M., Cloo, J., Steghuis, C., (2009) Enterprise Architecture
Creating Value by Informed Govermance Springer pp: 32 – 39
Lewis E. (2009) The foundation of Enterprise Architecture. Utdrag från webben
Linthicum, D. (2012) Cloud Computing? Thank SOA. http://thecloudtutorial.com/cloudcomputing-soa.html. Hämtad 2012-04-10
37
Magoulas, T., Pessi, K., (1998) Strategic IT-management. Part 1 “Introduction” and Part 2
“IT management in nine Swedish organizations”. Doctoral Thesis (in Swedish).
Department of Informatics, Gothenburg University pp: 1-109.
McGovern, J., Sims, O., Jain, A., & Little, M. (2006). Enterprise Service Oriented
Architectures: Concepts, Challenges, Recommendations. Netherlands: Springer.
Mell, P. & Grance, T. (2010) “The NIST Defenition of Cloud Computing”, Communications
of the ACM, 53:6 pp:50
Migration. http://www.ne.se.proxy.lnu.se/lang/migration/255707, Nationalencyklopedin,
hämtad 2012-04-23.
Miller, M., (2009) Cloud Computing Pros and Cons for End Users,
http://www.informit.com/articles/article.aspx?p=1324280&seqNum=2, Hämtad: 201204-24
Molnet. http://www.ne.se.proxy.lnu.se/molnet, Nationalencyklopedin, hämtad 2012-03-03
Pessi, K. (2012) Introduktion till Enterprise Architecture. Föreläsning på kursen
Arkitekturdesign vid Institutionen för Tillämpad IT. Göteborgs Universitet, 2012-01-2
Rathfelder, C. & Groenda, H. (2008). “iSOAMM: An Independent SOA Maturity Model”, 8th
IFIP WG 6.1 international conference on distributed applications and interoperable
systems, DIAS.
Rittinghouse, J. W. & Ransome, J. F. (2010). Cloud Computing: Implementation,
Management, and Security. Boca Raton, Florida: Taylor and Francis Group, LLC.
Roeleven, S. & Broer, J. (2008) Why two thirds of Enterprise Architecture projects fail. ARIS
Expert paper, IDS Scheer.
Santeacademy, (http://www.santeacademy.se/index_se.html Hämtad:2012-05-07
Session, R. (2006) “A better path to enterprise architectures” ObjectWatch, Inc.
http://www.objectwatch.com/whitepapers/ABetterPath-Final.pdf Hämtad: 2012-04-13
Sharma, R., Sood, M. & Sharma, D. (2011) Modeling Cloud SaaS with SOA and MDA.
Communications in Computer and Information Science, 2011 In Proceedings of the
International Conference on Advances in Computing and Communications 2011, vol.
190, iss 5, pp. 511-518.
Shulster, T., Rathfelder, C., Shulster, N., Nimis, J. (2010). “Comprehensive tool support for
iterative SOA evolution”, International Workshop on SOA Migration and Evolution
2010 (SOAME 2010), pp: 1-9
Symonds, M (2010) “Cloud: Its Potoetial For Businesses”, Whitepaper, Atos Origin
Yunus, M., (2010) Understanding Enterprise-to-Cloud Migration Costs and Risks,
http://www.ebizq.net/topics/cloud_computing/features/12741.html?page=1, Implact
2012, Hämtad:2012-04-24
38