• No results found

Migreringavtransaktionstungalegacy-system UppsalaUniversitet

N/A
N/A
Protected

Academic year: 2021

Share "Migreringavtransaktionstungalegacy-system UppsalaUniversitet"

Copied!
39
0
0

Loading.... (view fulltext now)

Full text

(1)

Uppsala Universitet

Inst. för Informatik & media

Migrering av transaktionstunga

legacy-system

En fallstudie hos Handelsbanken

(2)

Sammanfattning

(3)

Begreppslista

Transaktionstungt system

Transaktionsbaserat system med krav på höga volymer av transaktioner. Dessa förekommer frekvent hos finansiella institutioner som banker, men också hos fösäkringsbolag. I vissa fall finns de även inom den industriella sektorn. Systemen har ofta byggts upp under en längre tid och är centrala för verksamheten och är därför ofta mycket komplexa.

Transaktion

Utförandet av en ekonomisk överföring. I denna uppsats avser begreppet ex-empelvis när pengar flyttas från ett konto till ett annat.

Teknisk transaktion

En programmatisk implementation av en transaktion (se definitionen av transaktion ovan) där en transaktionshanterare håller samman den tekniska transaktionen vid uppdatering av resurshanterare som till exempel data-bashanterare eller köhanterare. Detta så att endera alla uppdateringar i den tekniska transaktionen utförs i alla resurshanterare eller så att alla uppda-teringar i den tekniska transaktionen görs ogjorda.

Legacy-system

Ett system i drift som täcker en avsevärd del av organisationens affärsmässiga behov och funktionella aspekter men inte följer utvecklade arkitekturmässiga standarder.

Adapter

(4)

Innehåll

1 Inledning 3 1.1 Bakgrund . . . 3 1.2 Problemområde . . . 4 1.2.1 Dålig flexibilitet . . . 4 1.2.2 Höga driftskostnader . . . 5 1.2.3 Kompetensbrist . . . 5

1.2.4 Problem rörande specifikt transaktionstunga system . 5 1.3 Syfte . . . 5 1.4 Avgränsningar . . . 6 2 Metod 7 2.1 Formulering av forskningsstrategi . . . 7 2.1.1 Datainsamlingsmetodik . . . 8 2.2 Metodik för dataanalys . . . 9 3 Teoretisk bakgrund 11 3.1 Problemområden . . . 11 3.2 Strategier . . . 12 3.2.1 Strategier för ersättningstillfället . . . 12

3.2.2 Genomgående strategier för migreringprocessen . . . . 13

4 Handelsbankens migreringsprocess 15 4.1 Introduktion till Handelsbankens systeminfrastruktur . . . 15

4.2 Migreringens mål . . . 16

4.3 Påverkande faktorer till migrering . . . 16

4.3.1 Omgivning . . . 17 4.3.2 Användningsområde . . . 17 4.3.3 Driftskostnader . . . 17 4.3.4 Vidareutvecklingskostnader . . . 18 4.3.5 Kompetensbrist . . . 18 4.4 Teknisk arkitektur . . . 19

4.5 Svårigheter vid migrering . . . 20

(5)

4.7 Utveckling av strategier för migreringsprocessen . . . 21

4.7.1 Övervägning av generisk lösning . . . 22

4.7.2 Skiktad arkitektur . . . 23

5 Analys 25 5.1 Strategier för migrering . . . 25

5.1.1 Strategier för ersättningstillfället . . . 25

5.1.2 Strategier för migreringsprocessen . . . 27

5.2 Svårigheter vid migrering . . . 28

5.2.1 Skillnader i programmeringsspråk . . . 28

5.2.2 Verksamhetskrav . . . 28

5.2.3 Faktorer kopplade till transaktionstunga system . . . . 29

5.3 Faktorer som påverkar migrering . . . 30

5.3.1 Kompetensbrist . . . 30

5.3.2 Dålig flexibilitet . . . 30

5.3.3 Höga driftskostnader . . . 31

6 Slutsats 32 6.1 Stegvis migreringsprocess . . . 32

6.2 System väljs efter verksamhetskrav . . . 32

6.3 System väljs efter prestandakrav . . . 33

6.4 Tydliga riktlinjer för arkitektur . . . 33

6.5 Ta hänsyn till den kontextuella förändring som skett . . . 33

(6)

Kapitel 1

Inledning

1.1

Bakgrund

Under 1960-talet blev IT-användningen i organisationer allt mer utbredd. Systemen var anpassade efter dåtidens teknik och verksamhetskrav. I likhet med teknikens utveckling har också kraven från verksamheten förändrats. Detta leder till att de IT-system som organisationer har i användning måste vidareutvecklas. I nuläget finns system i drift som utvecklades för flertalet tiotal år sedan, vilka levt vidare genom underhåll. Ofta brukar dessa system benämnas som legacy-system, även om explicita definitioner av begreppet varierar. Basem Alkazemi hänvisar till uttrycket som: “Ett system i drift som täcker en avsevärd del av organisationens affärsmässiga behov och funk-tionella aspekter men inte följer utvecklade arkitekturmässiga standarder.” vilket är en definition som kommer gälla i denna uppsats [1, Alkazemi BY., 2014].

Legacy-system har genom sin ålder och användning fördelen att de är välbe-prövade och därigenom välfungerande. Detta är en möjlig förklaring till var-för de än idag fortfarande är så vanligt var-förekommande. En undersökning visar år 2005 att 75% av all affärsdata någon gång bearbetas av system skrivna i COBOL, det mest förekommande programmeringsspråket för legacy-system. Beaktas endast den finansiella sektorn visar samma undersökning att 90% av alla finansiella transaktioner bearbetas av COBOL-system. [4, Datamonitor, 2008]

(7)

COBOL skapades 1959 och tillhör den procedurella programmeringsparadig-men, och har genom åren vidareutvecklats. Fler programmeringsparadigmer existerar, exempelvis den objektorienterade paradigmen vilken bland annat inkluderar programmeringsspråket Java. Den objektorienterade paradigmen växte fram under 1980-talet, och ledde till ett skifte mellan den procedurel-la paradigmen till den objektorienterade paradigmen. I modern tid utveck-las de flesta nya systemen i objektorienterade programmeringsspråk. Sedan paradigmskiftet har en mängd företag migrerat, eller valt att påbörja en migreringsprocess från legacy-system, ofta skrivna i COBOL, till objektori-enterade system. [2, Ashok RB Samuel, 2005, s.2]

Objektorienterad programmering införde tekniker som abstraktioner, inkaps-ling, arv och polymorfi. Bland annat förenklar detta återanvändandet av pro-gramkod. Detta leder också till att vidareutveckling och underhåll blir mer hanterbart och effektivt. Eftersom strukturen mellan den procedurella pro-grammeringsparadigmen och den objektorienterade programmeringsparadig-men skiljer sig, kan system från de båda olika paradigmerna ej enkelt sam-verka med varandra. Programmeringsparadigdmerna skiljer sig även ur ett utvecklarperspektiv. Detta medör att utvecklare som arbetat med program-meringsspråk från den ena paradigdmen, inte nödvändigtvis kan arbeta med och utveckla system byggda med ett språk från den andra paradigmen.[9, Vranes, Stanojevic,1995, s.247]

Migreringsprocessen för legacy-system blir med rådande faktorer en kritisk affärsprocess vilken är vital för hela verksamheten. Anledningen till detta är att legacy-systemen ofta utvecklats under en längre tid och blivit centrala för verksamheten. Storleken på dessa system är ofta mycket omfattande[5, MO-LU, 2013]. Till följd av övergångens komplexitet har många verksamheter valt att skjuta upp transformeringen tills förändringen blir en absolut nöd-vändighet. Processen är bred och involverar både organisationens IT-enhet tillsammans med andra beslutsfattande organ som rör företagets affärspro-cesser, något som är tidskrävande. [6, Neeti Aggarwal, 2006]

1.2

Problemområde

Det finns olika motiv till varför organisationer väljer att påbörja en migrering av legacy-system. Nedan beskrivs orsaker som presenterats inom tidigare forskning.

1.2.1 Dålig flexibilitet

(8)

med system. En förklaring till detta är att arkitekturen för legacy-systemen ofta kan hämma möjligheten att anpassa legacy-systemen efter nya verk-samhetskrav samt kan vara svåra att vidareutveckla.[6, Neeti Aggarwal, 2006]

1.2.2 Höga driftskostnader

Enligt en undersökning ansåg de flesta bankerna att en av de främsta anled-ningarna som motiverade en migrering var minskade driftskostnader. Detta i form av vidareutvecklingskostnader samt operationella kostnader. [6, Neeti Aggarwal, 2006]

1.2.3 Kompetensbrist

En faktor som beskrivs leda till att företag väljer att inleda en migreringspro-cess är kompetensbrist som råder inom COBOL-programmering. Program-merare med kompetens inom COBOL finns i mycket liten utsträckning kvar på marknaden. Kompetensbristen har lett till att konsulter med rätt kun-skap därför blivit eftertraktade. Därmed har också konsultarvoden blivit en högre kostnad än tidigare vilket bidrar till de höga underhållskostnader. [8, Harry M. Sneed Katalin.Erdoes, 2013]

1.2.4 Problem rörande specifikt transaktionstunga system

Litteratur som beskriver olika strategier för migrering från legacy-system ex-isterar, men dessa fokuserar inte direkt på system som är transaktionstunga. Därav är det inte självklart att de strategier som beskrivs för rent generella legacy-system kan appliceras på de transaktionstunga system som ofta byg-ger upp verksamheter inom banksektorn eller hos försäkringsbolag. Det går heller inte att validera att bakgrunden till varför en migrering påbörjas är den samma som den mer generella beskrivningen som ges ovan.

1.3

Syfte

Uppsatsen syftar till att redogöra för hur transaktionstunga legacy-system kan migreras och motiv till varför en migrering påbörjas. Resultatet kommer presenteras som en modell vilken beskriver tillämpningsbara koncept vid mi-grering av transaktiontunga legacy-system. Organisationen Handelsbanken genomför en migrering av den typ av system uppsatsen syftar till att grans-ka. Uppsatsen syftar till att presentera och analysera Handelsbankens motiv till migrering. Den modell som presenteras kommer baseras på en analys av Handelsbankens migreringsprocess ur ett IT-arkitekturmässigt perspektiv. Arbetet med uppsatsen har utgått från följande frågeställning:

(9)

1.4

Avgränsningar

(10)

Kapitel 2

Metod

2.1

Formulering av forskningsstrategi

En migrering av en organisations legacy-system är inte unikt och är framför allt en aktuell fråga inom de sektorer där finansiella system existerar, detta eftersom många finansiella system faller inom definitionen för legacy-system. Under den tidsram som funnits för uppsatsen har det dock inte varit möjligt att granska flertalet organisationer. Eftersom den sektor uppsatsen syftar till att granska är relativt oexploraterad, finns svårigtheter att tydligt klargöra exakt hur forskningsproblemet ser ut rent generellt.

Oates beskriver att en explorativ fallstudie ofta används för att definiera hypoteser och hjälpa forskare att bättre förstå problem när mängden litte-ratur är begränsad. Genom att observera hur ett specifikt fall har hanterats kan de frågor som är intressanta att granska genom vidare forskning identi-fieras. [7, Oates, 2006, s. 141-143] Således föll valet på att göra enfallstudien explorativ då forskningsområdets nuvarande stadie faller inom ramen för vad som beskrivs ovan. Att genomföra en enfallsstudie kunde förutom det-ta motiveras med den tidsram som existerade. Den explorativa fallstudien genomfördes vid företaget Handelsbanken. Handelsbanken genomför för till-fället en migrering från COBOL-system till Java-system för vissa delar av sin verksamhet. Baserat på uppsatsens syfte, är Handelsbankens migrerings-process relevant att granska.

(11)

detalj, samt att fallstudien resulterar i en modell som beskriver fenomenet.[7, Oates s.146] Fallstudien vid Handelsbanken behandlades därför med utgång från att den skulle resultera i en rik insikt. Uppsatsen syftade även till att resultera i en modell som beskriver de koncept Handelsbanken tillämpat vid deras migreringsprocess.

Oates beskriver olika typer av tidsaspekter som en studie kan ha. Den longi-tudinella typen av tidsaspekt genomförs där ett fall granskas under en längre tidsperiod.[7, Oates, 2006, s. 144] Fallstudien som har genomförts har endast kunnat granska den migreringsprocess från det att den påbörjades fram till det stadie som den befinner sig i nu. Planer och strategier som kommer an-vändas i framtiden är däremot något som granskats vilket leder till att en longitudinell tidsaspekt bäst definierar studien.

Nedanstående figur illustrerar den forskningsprocess som genomförts:

Figur 2.1: Forskningsprocessen

2.1.1 Datainsamlingsmetodik

(12)

under ett tidigt skede en ostrukturerad karaktär, för att vid senare tillfällen övergå mot mer semi-strukturerad karaktär. [7, Oates, 2006, 266-267]. Intevjuer har skett vid olika tillfällen, och den information som framkom-mit vid en intervju har bearbetats och kodats innan nästa intervju skett. Tre personer vid Handelsbanken har intervjuats. Alla tre av dessa personer har ansvar inom den migreringsprocess som genomförs hos Handelsbanken. De områden dessa personer har ansvar inom är: teknisk arkitektur, enterpri-se arkitektur samt ur ett systemägare- och beställare perspektiv.

Intevjuer har skett vid olika tillfällen, och den information som framkom-mit vid en intervju har bearbetats och kodats innan nästa intervju skett. Tre personer vid Handelsbanken har intervjuats. De tre intervjupersonerna är: Gunnar Johansson Hård med ansvar som systemägare- och beställare, Johnny Modig som har ansvar inom enterprise arkitektur samt Lennart He-näng som har ansvar inom teknisk arkitektur. Alla tre av dessa personer har är delaktiga inom den migreringsprocess som genomförs hos Handelsbanken. Intervjupersonerna på Handelsbanken har valts genom ett strategiskt ur-val. Anledningen till att specifikt dessa personer valts är att de är delaktiga i ansvaret för migreringsprocessen på Handelsbanken, då med funktionen som arkitekter. De har därför väldigt god insyn, samt en gedigen bakgrund inom ämnet och var därför högst lämpliga att intervjua med uppsatsens perspek-tiv i åtanke. Vidare har personerna som intervjuats korrekturläst uppsatsen för att mininmera felaktigheter. Även Håkan Sandström som också arbetar vid Handelsbanken har varit delaktig i detta.

2.2

Metodik för dataanalys

Då primärt kvalitativa datainsamlingsmetoder använts, var det också na-turligt att välja en kvalitativ dataanalys. Något som skulle kunna vara ett hinder för en kvalitativ datainsamlingsmetod, och där igenom en kvalitativ dataanalys, är om informationen inte är tillgänlig t.ex. via sekretesskydd eller oåtkomliga personer. Detta utgjorde ej något problem i den fallstudie som genomfördes.

(13)
(14)

Kapitel 3

Teoretisk bakgrund

I detta kapitel kommer relevant teori för området presenteras. Teorin är något begränsad och därför består den teori som presenteras av mer generell forskning rörande migrering av legacy-system.

3.1

Problemområden

Legacy-system är i nuläget vanligt förekommande och specifikt i finansiella system är COBOL-system utbredda. Av flertalet anledningar, inkluderande dålig flexibilitet, kompetensbrist och höga driftskostnader, kan en migrering vara av hög prioritet. Migreringen har visat sig vara en affärskritisk process vilken konsumerar mycket resurser och kompetens från ett brett spektrum av kompetenser inom företaget.

Sneed Erdoes (2013) beskriver ett problem vid migrering från COBOL till Java-system. Problemet beror på att kodstrukturen mellan system skriva i COBOL och Java skiljer sig åt. Anledningen till detta är att program-meringsspråken tillhör två olika programmeringsparadigmer, där COBOL tillhör den procedurella paradigmen och Java tillhör den objektorienterade paradigmen. En direkt översättning från COBOL-system till Java resulterar därför i att koden får en procedurell karaktär. Detta leder till att de förde-lar objektorienterade programmeringsspråk ger i förhållande till procedurella programmeringsspråk blir mindre förmånliga. Genom detta uppstår därför problematik vid direkt översättning från COBOL kod till Java kod. [8, Harry M. Sneed Katalin.Erdoes, 2013, s.3-4].

Två problemområden som diskuteras av Bisbal J, Lawless D, Wu B, Grimson J. är följande:

(15)

migreringen ofta är komplex och berör flertalet områden, kan det vara svårt att uppnå detta krav. Detta kan leda till problem eftersom syste-men ofta är centrala inom verksamheten.[3, Brisbal J, Lawless D, Wu B, Grimson J., 1999].

• Eftersom ett legacy-system ofta utvecklats och underhållits under en längre tidsperiod, möter ofta systemet delar av de verksamhetskrav som ställs på systemet. Det är därför kritiskt att det nya systemet som skapas vid migreringen uppfyller de krav som legacy-systemet uppfyl-ler. Vid dålig förståelse för vilka verksamhetskrav som ställs på det nya systemet, finns en möjlighet till att det nya systemets funktionalitet ej uppfyller användarnas behov. Detta kan i värsta fall leda till att migreringsarbetet misslyckas och fallerar.[3, Brisbal J, Lawless D, Wu B, Grimson J., 1999].

3.2

Strategier

Olika strategier kan tillämpas vid migrering. Denna sektion beskriver strate-gier som behandlats i tidigare forskning. Stratestrate-gierna som beskrivs, tillämpas vid olika delar i migreringen. De två delar som behandlas är ersättningstillfäl-let samt strategier som är tillämpningsbara genom hela migreringsprocessen. Ersättningstillfället är den tidpunkt då ett äldre system ersätts med ett nytt system, medan de strategier som beskrivs som är tillämpningsbara genom hela migreringsprocessen inte endast är bundna till denna tidpunkt.

3.2.1 Strategier för ersättningstillfället

Vid ersättningtillfället av ett legacy-system kan olika strategier tillämpas. Bisbal J, Lawless D, Wu B, Grimson J.diskuterar tre strategier:

Cut-and-run strategy

(16)

Phased interoperability strategy

Komponenter i legacy-systemet ersätts stegivs med kompontenter i det nya systemet. Komponenterna är ej verksamma samtidigt, och efter legacy-systemets komponenter ersatts, tas de ur drift. Eftersom migreringen sker genom att komponenter ersätts stegvis, ökar migreringens komplexitet. [3, Brisbal J, Lawless D, Wu B, Grimson J., 1999].

Parallel operationsstrategy

Legacy-systemet samt det nya systemet är verksamma simultant. Båda sy-stemens funktionalitet används samtidigt till verksamhetens arbetsuppgif-ter. När det nya systemet är färdigutvecklat samt fullständigt testat, ersätts legacy-systemet till fullo. [3, Brisbal J, Lawless D, Wu B, Grimson J., 1999].

3.2.2 Genomgående strategier för migreringprocessen

Vid en migreringsprocess kan ett antal olika typer av metoder tillämpas. Ett vanligt alternativ är att välja en metod som involverar att legacy-systemet samt det nya systemet samverkar genom en gateway. Dessa typer av metoder har vissa begränsningar, trots att de kan vara lyckade. En begränsing är att dessa gateways inte erbjuder transaktionshantering vilket medför svårigheter att säkerställa konsistent data mellan legacy-systemet samt det nya systemet. En annan svårighet med metoden är att det ofta blir svårt att underhålla samt konstruera en gateway. [3, Brisbal J, Lawless D, Wu B, Grimson J., 1999].

The Chicken Little Strategy

En metod som använder gateways är The Chicken Little Strategy. Samverkan mellan legacy-systemet samt det nya systemet tillåts med hjälp av gateway-en. Under migreringen byggs stegvis mindre delar av legacy-systemet på den nya platformen, vilket innebär att det nya systemet till en början är litet, för att sedan växa under migreringsprocessen. Eftersom de båda systemen inte kan utföra direkt informationsbyte då programmeringsspråket mellan systemen ej samstämmer, måste informationen översättas för att samverkan skall kunna ske. För att översätta informationen används mappning, vilket kan vara komplext samt långsamt. Om de nya applikationerna kräver infor-mationsutbyte mellan de båda systemen, påverkas därför applikationernas effektivitet. [3, Brisbal J, Lawless D, Wu B, Grimson J., 1999].

The Butterfly methodology

(17)
(18)

Kapitel 4

Handelsbankens

migreringsprocess

Den information som presenteras i detta kapitel baseras på de intervjuer som genomförts under en fallstudie vid Handelsbanken. Intervjuerna har genom-förts med personer med ansvar inom teknisk arkitektur, enterprise arkitektur, systembeställning samt systemägande. De personer som intervjuats har alla haft insyn och ansvar för den migrering som genomförs inom Handelsban-kens IT-system, och information anses därför vara högst relevant samt giltig. De citat som presenteras i kapitlet har framkommit under de intervjuer som genomförts.

4.1

Introduktion till Handelsbankens

systeminfra-struktur

Handelsbankens system utvecklades, liksom de flesta andra finansiella sy-stem, från slutet av 60-talet och framåt. Under åren har sedan Handelsban-ken successivt byggt på system utefter det att kontexten till hur systemet används har förändrats. Även om det har skett förändringar under hela sy-stemets livslängd är det i slutet av 1990-talet som en av de största föränd-ringarna som har inverkan på Handelsbankens system inträffar. Internet blir mer användbart för gemene man och Handelsbanken lanserar sin webbap-plikation, alltså sin internetbank, där vanliga privatpersoner själva kan göra sina bankärenden.

(19)

system även skulle användas externt. När Handelsbanken sedan utvecklade en internetbank under slutet av 1990-talet, medförde även detta att externa användare kunde använda systemen.

Denna typ av externa användare ökade markant i samband med teknikens utbredning hos Handelsbankens kunder. Att Handelsbanken erbjuder system för externa användare motiveras primärt av att kunna tillgodose kundbehov och önskemål och samtidigt möjliggöra sänkta kostnader. Detta har därför öppnat upp för ytterligare system. Därför har system för telefonbankärenden och mobilanvändning även blivit konstruerade.

Handelsbankens system kan alltså sägas evolverat genom att successivt på-byggas utefter att nya krav på funktionalitet som ställts från verksamhets-sidan. Eftersom ett system ofta kräver information från och levererar infor-mation till en mängd andra systemen, genereras en stor mängd kopplingar till andra system. Detta gör systemarkitekturen komplex, vilket gör att att integrering av nya system därför blivit en utmaning.

4.2

Migreringens mål

Handelsbanken har ingen plan som direkt definerar att företaget skall byta ut alla COBOL-system till Java. Istället har företaget bestämt att möjlighet till utveckling av affärssystem skrivna i både Java och COBOL skall erbjudas. Detta innebär att nya system kan programmeras i COBOL när detta är lämpligt. Övergripande kan Handelsbankens mål med att migrera system sägas vara att inneha system med mer förändringsbar arkitektur samt ny, lönsam funktionalitet som visat sig för dyr att bygga in i legacy-systemet.

4.3

Påverkande faktorer till migrering

(20)

migrering genomförs om inte Handelsbanken anser att den blir ekonomiskt lönsam. Ekonomisk lönsamhet kan primärt uppnås via två förbättringsområ-den. Antingen genom att migreringen tillför ny funktionalitet som Handels-banken anser efterfrågas till en sådan grad att det blir ekonomiskt lönsamt att utveckla funktionaliteten, eller genom att migreringen bidrar till effek-tivisering till en sådan grad de ekonomiska vinster effekeffek-tivisering medför överstiger migreringskostnaderna.

“Det nya systemets ekonomi och om man får mer funktionalitet på köpet, avgör om det blir en migrering. Det finns ingen skönhet i att systemen är skrivna i Java för att det är finare än COBOL, utan det här företaget och de flesta andra drivs stenhårt av eko-nomiska realiteter. Finns det ingen lönsamhet i kronor och ören, då blir det ingen konvertering. Det finns ingen stress över att konvertera system från exempelvis 1968 om de fungerar, då får de vara. Ekonomin och funktionaliteten avgör migreringstakten."

När ett nytt system skall byggas väljs programmeringsspråk baserat på ett flertal faktorer.

4.3.1 Omgivning

En mycket viktig aspekt som övervägs är systemets omgivning, dvs. vilka nuvarande system det nya systemet skall samverka med. Om det nya systemet skall samverka med många system skrivna i COBOL, är det ofta fördelaktigt att programmera även detta system i COBOL. Viktigt att beakta är att ett system ofta kan samverka ett stort antal andra system. Det är därför essentiellt ha en plan för hur nya system samverkar med resterande system när de byggs i Java.

4.3.2 Användningsområde

En annan faktor som övervägs är systemets användingsområde. Java är exem-pelvis mer lämpligt att använda för system kopplade till användargränssnitt, medan Handelsbanken anser att COBOL ofta är lämpligt att använda för system som hanterar transaktioner och arbetar mot databassystemen.

4.3.3 Driftskostnader

(21)

företaget optimerat systemen vilket minskar systemens driftskostnad. Han-delsbanken anser utöver detta att de nya systemen som skall ersätta legacy-systemen, i vissa fall ej kommer vara möjliga att optimera till samma grad som legacy-systemen, vilket får till följd att dessa system får en högre drifts-kostnad än legacy-systemen.

4.3.4 Vidareutvecklingskostnader

I vissa situationer, där system levt vidare genom att dess funktionalitet ut-vidgats, har en situation där systemets arkitektur blivit svårtydd och kom-plex uppstått. Genom detta blir vidareutvecklingskostnaderna höga. Även om systemen är mycket lönsamma och driftskostnaderna är låga kan vidare-utvecklingskostnaderna ändå vara en faktor till migrering om systemen skulle vara så pass sönderförvaltade att de är svåra att förändra.

4.3.5 Kompetensbrist

Handelsbanken har diskuterat frågan huruvida kompetensbrist av COBOL-utvecklare kan påverka organisationen och hurvida detta kan ses som en anledning till migreringen. Då flera av Handelsbankens COBOL-utvecklare närmar sig pensionsåldern anses faktorn som relevant. Därigenom finns en risk för att en framtida kompetensbrist kan uppstå. Handelsbanken påpekar dock att det finns ett samarbete med en utbildningsinstitution som lyfter fram kompetens i yngre åldrar. Enligt Handelsbanken finns det för yngre människor inte några motsättningar till att lära sig COBOL under förut-sättning att arbeten med rätt lön finns. Handelsbanken har också sett att erfarna utvecklare i andra programmeringsspråk kan övergå till COBOL med endast en kortare inlärningsperiod. Utvecklare brukar normalt sett bli pro-duktiva under loppet av två månader. När ett nytt system utvecklas ser Handelsbanken därför inte en eventuell kompetensbrist inom COBOL som ett tungt argument för att föredra ett system byggt i ett annat programme-ringsspråk före ett system byggt i COBOL.

(22)

4.4

Teknisk arkitektur

När en teknisk arkitektur definieras är det viktigt att besluta hur pass de-taljrika riktlinjerna för arkitekturen ska vara. Handelsbanken definierar två typer av riktlinjer för arkitektur, styrande eller stödjande riktlinjer.

Styrande riktlinjer kännetecknas av att dessa mer eller mindre i detalj define-rar hur nya system skall byggas upp. Fördelen med detta är att riktlinjerna är vägledande och därför tydligt instruerar hur systemen skall konstrueras, vilket ger klarhet i systemutvecklingen. En annan fördel är att system som utvecklas med styrande riktlinjer får stora likheter, vilket medför att det blir lättare att koppla in nya utvecklare på ett redan existerande projekt. En nackdel är dock att styrande riktlinjer inte alltid kan vara förutseende för förändrade krav på system. Dessutom kan utvecklarnas möjlighet till att finna kreativa lösningar till problem hämmas.

En stödjande arkitektur definerar mer generella riktlinjer än en styrande arkitektur. Detta innebär att större frihet ges till utvecklarna att skapa eg-na tillämpningar, under förutsättning att tillämpningareg-na följer de generella riktlinjerna. I jämföresle med en styrande arkitektur för och nackdelarna det motsatta. Utvecklarna ges större möjlighet att påverka systemets uppbygg-nad samt finna kreativa lösningar till problem, vilket kan anses som fördelak-tigt ur ett innovationsperspektiv. Eftersom stödjande riktlinjer ej definerar hur system skall byggas med samma detaljrikedom styrande riktlinjer ges ej samma möjlighet till tydlighet inom systemutvecklingen. Detta leder ibland till att oklarheter i utvecklingen uppstår vilket kan få negativa konsekvenser. Till följd av detta kan systemen få stora skillnader.

Arbetet med att utveckla struktur för arkitekturen, dvs. arkitekturmässig standard pågår fortlöpande för Handelsbanken. En del i detta arbete är be-sluta hur pass styrande och stödjande de riktlinjer som definierar arkitek-turens struktur skall vara. Handelsbanken anser att legacy-systemens arki-tektur följer en struktur som till viss del ej är gynnsam för vidareutveckling för en del av de verksamhetskrav som ställs på systemen i dagsläget. Därför är det essentiellt att definiera en tydlig struktur för de nya systemen. Under uppbyggnaden av Handelsbankens internetbank använde Handelsbanken en mycket styrande arkitektur och ett tydligt definierat ramverk. Genom detta finns goda erfarenheter av att använda denna typen av riktlinjer. Det går att se att de system som bygger upp internetbanken har stora likheter, något som kan förklaras av beslutet att använda ett styrande ramverk.

(23)

av internetbanken talar för att använda sådana även i framtiden. Företagets önskan att ge utvecklarna frihet talar däremot för en mer stödjande arki-tektur. Eftersom arbetet med att definera riktlinjer pågår fortlöpande, är typen ännu ej faställt samt slutgiltigt. Nya krav för systemen uppstår och förändras även systemens verksamhetstid, vilket även kräver att riktlinjerna utvecklas.

4.5

Svårigheter vid migrering

Det har identifierats flertalet problem i den migreringsprocess som påbörjats. Exempelvis är kommunikation och intergration problematiskt. För Handels-banken, men även genomgående för transaktionstunga system, är det viktigt att alla förändringar som sker vid en transaktion, sker inom en teknisk trans-aktion. Vid exempelvis en överföring mellan två bankkonton, är det viktigt att saldot för båda dessa konton förändras under en teknisk transaktion. Anledningen till detta är att det möjliggör att processen blir reverserbar om fel inträffar under processen. Om detta ej är möjligt, riskeras att felaktiga saldon för konton uppstår. Genom att använda COBOL är det för Handels-banken enklare att upprätthålla att alla transaktioner sker inom en teknisk transaktion. När tjänster skapas som exempelvis behöver hantera kommuni-kation för både Java-system och COBOL-system sker inte detta naturligt, och det uppstår ofta problematik med att få dessa tjänster att hantera flera förändringar under en teknisk transaktion.

Ses migreringen ur ett arkitektur-perspektiv identifieras andra problem. För tillfället är strukturen för arkitekturen av de nya Java-systemen inte helt fär-digställd. Under defineringen av denna struktur är det en balansgång hurvida det ska väljas riktlinjer som är stödjande eller styrande. Den struktur som bygger upp COBOL-systemen har genomarbetats under 50år, och är därför tydligt definierad. I dagsläget är Handelsbanken därför i behov av att under en kort tidsperiod bygga upp en struktur för Java-systemen som motsvarar strukturen för COBOL-systemen. En investering endast för att bygga upp en struktur är oftast svår att få godkänd. Istället får denna struktur byggas upp under finansierade projekt. Då strukturen för Java-systemen i dialogskiktet definerades skedde dock ett beslut där finansiering gavs för att bygga upp grunden för en Java-platform. Detta beslut fattades när Handelsbanken ut-vecklade företagets internetbank.

4.6

Anledningen till varför Java väljs

(24)

att samverkan med nuvarande COBOL-system blir effektivare då de verkar på samma platform. Den nuvarande databasen som används verkar även på z/OS. Handelsbanken ser ingen anledning till att byta ut detta system. Däri-genom blir databaskopplingen också enklare att hantera för de nya systemen när de verkar på samma plattform. Med tanke på dessa fördelar blir det därför en tung faktor att att Java kan köra på z/OS vid valet av program-merinsspråk för framtida system. Eftersom Handelsbanken vill garantera att de system som byggs skall kunna användas och underhållas ett flertal tiotal år framöver, kan endast de största programmeringsspråken övervägas. Funk-tionella programmeringsspråk övervägs inte med tanke på att osäkerhet om språkens framtida utbreddning existerar. Således har Java blivit det språk som Handelsbanken valt att gå vidare med. Anledningen till att flertalet språk inte testas grundar sig i att systemen måste vara förvaltningsbara. Byggs system i flertalet olika programmeringsspråk försämras förvaltnings-barheten eftersom det skapar ett behov av kompetens inom flertalet områden.

4.7

Utveckling av strategier för

migreringsproces-sen

Stora delar av de migrerings-strategier som Handelsbanken implementerar i nuläget är baserat på tidigare erfarenheter. Det är till stor del den komplexa arkitektur som ligger till grund för Handelsbankens IT-infrastruktur som be-höver beaktas.

Handelsbankens arkitektur är som tidigare beskrivet uppbyggd av flertalet olika system. En regel för hur arkitektur skall byggas inom Handelsbanken är att inget system får modifiera ett annat systems databas. Organisationen applicerar därför ett slags tjänstekoncept där varje system måste interagera via det interface som finns tillgängligt då det behöver data från ett annat systems databas. På så sätt kan det garanteras att inga operationer, som inte är definierade hos det system som tillhandahåller tjänsten, utförs. Istället för att tillämpa en strategi där systemet migreras simultant blev lösningen att välja ut system som stegvis migreras. Valet av denna strategi medför att kopplingar som behöver förändras till följd av nya system blir enklare att överblicka och arbetet lättare att genomföra.

(25)

databas där information om de olika systemens prestanda och antal buggar finns. På så sätt görs även en avvägning baserat på förvaltningsläget för sy-stem om vilket sysy-stem som skall migreras för att förbättra driftssäkerhet och prestanda som är ett essentiellt verksamhetskrav. I figur 4.1 nedan illustreras Handelsbankens migreringsstrategi.

När ett system är färdigutvecklat körs systemet ofta parallellt med det legacy-system som det skall ersätta under en kortare tidsperiod, detta för att verifiera den nyskrivna systemets driftsäkerhet. Handelsbanken strävar däremot efter att minimera tidsramen för denna parallella drift för att hålla nere kostnaderna för legacy-systemet.

Figur 4.1: Handelsbankens migreringsstrategi

4.7.1 Övervägning av generisk lösning

(26)

för-utsättning att systemen kommunicerar med ett generellt protokoll via den generiska bussen. Anledningen till att Handelsbanken ej valt att styra arki-tekturen i denna riktning är att systemens körtid skulle försämras avsevärt. Resonemanget går i riktningen att det är snabbare att låta information utby-tas mellan systemen om de körs på samma plattform än om informationen först måste transformeras till ett generellt format, skickas via ett nätverk genom bussen för att sedan transformeras till ett nytt format och läsas av systemet som har efterfrågat informationen.

4.7.2 Skiktad arkitektur

Som tidigare nämnt har Handelsbanken inte någon plan på att helt ersätta COBOL med Java fullt ut. Detta grundas bland annat i att Handelsbanken menar att tisperioden för en total ersättning skulle vara för lång för att vara planerbar. Orsaken till detta är den stora mängden system skrivna i CO-BOL. En annan anledning är att vissa system, i Handelsbankens mening, lämpar sig väl skrivna i COBOL. Det har därför varit viktigt att lägga upp en strategi för hur arkitekturen ska se ut hierarkiskt för att få en god över-blick över var de system som primärt kommer vara föremål för migrering finns lokaliserade. Primärt är det tre olika skikt som man delar upp de olika systemen i, dialogskikt, tjänsteskikt och transaktionsskikt.

Det är i dialogskiktet som interaktionen med systemens användare sker. Många av dessa system är mer föränderliga än de system som finns i de andra skikten. Skiktet har behövt vidareutvecklas mycket under de senare åren med tanke på de externa användare som Handelsbanken fått via inter-netbank, telefonbank och liknande. Vidare finns tjänsteskiktet som förenklat kan sägas fungera som ett interface mot själva transaktionsskiktet. Skall exempelvis data presenteras i dialogskiktet måste program i dialogskiktet anropa en tjänst i tjänsteskiktet som sedan sköter kommunikationen med rätt system i transaktionsskiktet. Transaktionsskiktet är det som hanterar och genomför de faktiska transaktionerna. Förenklat skulle det kunna be-nämnas som Handelsbankens underliggande affärssystem. Skiktarkitekturen illustreras nedan i figur 4.2.

Modellen har varit mycket viktig för att kartlägga migreringsprocessen i yt-terligare en dimension. Genom att skiktningen finns är det en enklare process att migrera system som har en viss funktionalitet utan att behöva förändra andra system. Denna skiktningsarkitetkur är något som Handelsbanken haft i beaktning under en längre tid vid utveckling av Handelsbankens system. Skiktningen har förenklat både utveckling och migrering avsevärt.

(27)

Figur 4.2: Handelsbankens skiktarkitektur

(28)

Kapitel 5

Analys

I detta kapitel kommer analyser göras baserat på den teori som presenterats samt den information som framkommit gvid fallstudien vid Handelsbanken. Primärt kommer analysen beakta likheter och skillnader mellan den teore-tiska bakgrunden och fallstudien.

5.1

Strategier för migrering

Metoder för migrering analyseras då valet av migreringsstrategi visats vara av stor vikt för hurvida en migrering lyckas eller ej. Detta har visats både inom tidigare forskning samt inom den fallstudie som genomförts. Migre-ringsstrategier har även en central roll inom tidigare forskning, samt var ett vida diskuterat koncept under fallstudien. Detta motiverar att området analyseras.

5.1.1 Strategier för ersättningstillfället

Simultan ersättning

Vid tidigare migreringar som skett i branschen, har en simultan migrering av flera system gjorts. Strategin karaktäriserades av att alla system migrerades samtidigt (4.7). Innebörden av detta var att när det nya systemet färdig-ställts, skulle det äldre legacy-systemet tas ur bruk och ersättas av det nya systemet. Denna strategi har stora likheter med “The cut and run strategy” (3.2.1). The cut and run strategy baseras på ett tillvägagångsätt där över-gången mellan legacy-systemet och det nya systemet sker tvärt, vilket liknar den strategi som applicerats i de branscherfarenheter som Handelsbanken tagit lärdom av.

(29)

migreringen ofta är svårt att förutspå. Enligt Handelsbanken finns problem vid tillämpning av denna strategi. Handelsbanken menar att strategin är för tiskrävande och det är svårt att hålla sig inom de ekonomiska ramar som planerats för migreringen. Detta kan jämföras med de svårigheter som be-skrivs vid implementering av The cut and run strategy.

De problem som beskrivs kan uppkomma när Cut and run strategy imple-menteras blir allt för komplexa när system av en banks skala och kontext hanteras. Sannolikt är strategin mer tillämpningsbar på system av mindre storlek och med mindre komplexitet. Sådana system karaktäriseras av mind-re antal kopplingar inom systemet. Då blir det inte lika svårt att uppskatta den tid och de resurser som migreringen kommer att kräva.

Handelsbankens nuvarande strategi

Sammanfattningsvis kan Handelsbankens nuvarande migreringsstrategi de-finieras av att välja ut system som stegvis migreras. (4.7) I vilken ordning dessa system väljs ut finns det interna strategier för som tidigare beskrivits. Eftersom Handelsbanken tillämpat en stegvis migreringsprocess, är nya sy-stem aktiva samtidigt som legacy-sysy-stem som ej migrerats. Viktigt är dock att ett nytt system och ett legacy-system som uppfyller samma funktionali-tet inte är aktiva samtidigt under längre tidsperioder. Eftersom migreringen sker stegvis måste däremot legacy-system och nya system samverka med ex-empelvis samma databassystem. Delar av denna strategi kan appliceras på andra, redan definierade strategier för legacy-migrering som beskrivs i viss forskning som publicerats.

“The Phased interoperability strategy” beskriver hur komponenter i det nya systemet stegvis migreras. Sett till den strategin “Parallel operationsstrate-gy” (3.2.1), beskriver strategin att legacy-system skall vara i drift parallellt med de nya systemen där båda systems funktionalitet skall bibehållas under övergångsfasen.

Ur en synvinkel som utgår från dessa två strategier kan Handelsbankens tillämpade strategi anses som en kombination av strategin “Phased interope-rability strategy”, samt till viss del även strategin “Parallell operationsstra-tegy”. Handelsbankens val att stegvis migrera system liknas med strategin “Phased interoperability strategy”. Detta beskriver dock inte hela Handels-bankens strategi. Att systemen fortfarande är i drift parallellt under en kor-tare tidsperiod påminner till viss del med strategin “Parallell operationsstra-tegy”. En skillnad är dock att Handelsbanken försöker minimera tidsperioden legacy-systemet är aktivt samtidigt som det nya systemet.

(30)

op-timal för den typ av system som finns i drift hos Handelsbanken. Denna kan definieras som en kombination av Phased interoperability strategy och Paral-lel operationsstrategy där grundkoncepten från båda strategier inkorporeras till en ny strategi. Detta har Handelsbanken kompletterat med en ytterligare en strategi för att välja ut system för migrering i en specifik ordning baserat på hur verksamhetskrav och systemhälsa ser ut för tillfället (4.7).

5.1.2 Strategier för migreringsprocessen

Ytterligare två metoder för migrering av legacy-system är “The Chicken Litt-le Strategy” samt “The butterfly methodology” (3.2.2).

The Chicken Little Strategy, beskriver att en gateway skall användas för att möjliggöra migreringen. Migreringen sker stegvis och det nya systemets storlek expanderar under migreringsprocessen. Under migreringen samver-kar både legacy-systemet och det nya systemet med hjälp av gatewayen. Eftersom systemen ej är byggda i samma programmeringspråk måste in-formationen mellan systemen översättas för att samverkan skall kunna ske. Denna översättning sker med hjälp av mappning.

The butterfly methodology använder ingen gateway under migreringspro-cessen. Detta leder till att legacy-systemet och det nya systemet ej behöver samverka under migreringsprocessen. Trots att migreringen utförs stegvis läggs istället fokus på att migrera legacy-systemets databas. Därför sätts legacy-systemets databas till “read only” under migreringen. En fördel med denna metod, utöver att behovet för en gateway försvinner, är att migre-ringsprocessen kan avbrytas. Dessutom är processen återställningsbar tills dess att migreringsprocessen är slutförd.

(31)

och Java-system. Handelsbanken har dock valt ej använda en generisk buss för att översätta information från de olika systemen till information av mer generell karaktär, vilket skiljer sig från tillämpningen i The Little Chicken Strategy.

5.2

Svårigheter vid migrering

Svårigheter och problem samt dess lösningar är av stort intresse att analysera då de lärdomar som dras från denna kunskap är av stort värde. I den fall som granskats har mycket pengar spenderats för att uppnå denna kunskap, och exempelvis för organisationer som skall eller genomför migreringar av likanande karaktär, är denna kunskap därför av stort intresse.

5.2.1 Skillnader i programmeringsspråk

Handelsbanken beskriver att det är essentiellt att definiera en tydlig struktur för de Java-system som skall utvecklas. Problematik består i att Handelsban-ken är i behov att under en kort tidsperiod definiera en tydlig struktur som skall motsvara en struktur som byggts upp i COBOL under 50 år (4.5). I avsnitt 3.1 beskrivs viss problematik som kan liknas med det som Han-delsbanken beskriver. Vid migrering från system skriva i procedurella pro-grammeringsspråk till system skrivna i objektorienterade programmerings-språk skiljer sig kodstrukturen mellan programmeringsprogrammerings-språken. Detta leder till att en direkt översättning mellan programmeringsspråken ej är fördelak-tigt, vilket medför att det krävs att kodstrukturen för legacy-systemen först förändras innan en översättning kan ske.

Vid granskning av tidigare forskning samt Handelsbankens migreringpro-cess blir det tydligt att det är av stor vikt att en tydlig struktur läggs upp för de nya system som skall skapas. Eftersom de nya systemen ofta ersätter redan existerande legacy-system är det även viktigt att den struktur som skapas kan samverka med de legacy-system som finns kvar. Detta beror på att legacy-systemen ofta har många kopplingar till andra system, och des-sa kopplingar måste kunna erhållas av de nya systemen. Om detta ej tas i beaktning, riskerar migreringsarbetet att fallera.

5.2.2 Verksamhetskrav

(32)

uppfyller de verksamhetskrav som ställdes på det gamla systemet, utöver eventuella nya verksamhetskrav.

I avsnitt 3.1 beskrivs att äldre legacy-system ofta utvecklats under en längre tid. Därför uppfyller ofta ett legacy-system många av de verksamhetskrav som ställs på systemet vid migreringstillfället. Det är därför viktigt att det nya systemet även uppfyller dessa krav, annars riskerar detta att bli oan-vänbart för verksamheten. Handelsbanken har inte benämnt detta som ett problem direkt kopplat till migreringsprocessen. Det blir dock tydligt att företaget tar problemfaktorer som beskrivs i tidigare forskning under beakt-ning.

Baserat på den information tidigare forskning presenterar, samt den informa-tion som framkommit under fallstudien, slutleds att vid en migreringsprocces från legacy-system är de krav verksamheten ställer på systemen av hög pri-oritet. Eftersom det viktigaste för användare av verksamhetens IT-system är att systemen fyller de behov användarna har av systemen, blir vilket programmeringsspråk systemen är byggda av mindre betydelse. Därför är det av största vikt att de nya IT-systemen uppfyller de verksamhetskrav legacy-systemen uppfyller, annars riskerar systemen att bli oanvändbara för verksamheten.

5.2.3 Faktorer kopplade till transaktionstunga system

Handelsbanken har beskrivit ett problem som ingen granskad relaterad forsk-ning behandlat är ett problem relaterat till banksystem. Inom banksystem är det essentiellt att alla saldoförändringar som sker mellan exempelvis två bankkonton vid en överföring från det ena kontot till det andra, sker under en databas transaktion. Detta för att det ska vara möjligt att gå tillbaka och ångra processen om något går fel under processen. (4.5) Eftersom detta problem är högst relaterat till transaktionstunga system, är det naturligt att detta problem ej behandlas i litteratur som granskar migreringsprocesser av mer generella legacy-system. Problemets är dock högst relevant inom migre-ringsprocesser av transaktionstunga legacy-system, och måste därför tas i beaktning vid en sådan migreringsprocess.

(33)

5.3

Faktorer som påverkar migrering

För en organisation är det inte enkelt att motivera en mycket kostsam mi-grering, om migreringen endast görs för att byta en teknik till en annan. Av denna anledning är det ytterst intressant att analysera de faktorer som motiverar valet att genomföra en migrering. Faktorer som motiverar migre-ringen behandlas både inom tidigare forskning, samt inom den fallstudie som genomförs. Därför är det av intresse att även analysera om faktorerna skiljer sig åt mellan forskningen och fallstudien.

5.3.1 Kompetensbrist

Avsnitt 1.2 beskriver anledningar till varför organisationer väljer att påbör-ja en migreringsprocess av sina legacy-system. En viktig anledning är den rådande kompetensbrist som har uppstått till följd av pensionsavgångar. An-ledningen till att man väljer att migrera är primärt de höga konsultarvoden som organisationer behöver betala för att underhålla och vidareutveckla sina system. Handelsbanken upplever samma typ av problematik då flera av de-ras COBOL-programmerare närmar sig pensionsålder. Handelsbanken anser däremot inte att detta är en anledning till varför organisationen ska påbörja en migrering. Detta med hänsyn till att det både går att konvertera pro-grammerare i andra språk för att arbeta i COBOL utan större ansträngning. Andra faktorer visar på att yngre arbetskraft går att rekrytera om rätt ut-bildning och rätt löner finns.(4.3)

Det finns potentiellt negativa konsekvenser med båda synsätten. Om kompe-tensbrist ej ses som en avgörande faktor för en migrering, och det i framtiden uppstår en situation där kompetens inom COBOL blir mycket sällsynt, kan en situation uppstå där underhållnings- och vidareutvecklingskostnader blir väldigt höga. Om kompetensbrist istället ses som en avgörande faktor för en migrering, kan konsekvensen bli att migreringen endast genomförs för att byta ut systemens programmeringsspråk, utan att verksamheten egent-ligen har något behov av detta. Detta kan få till följd att migreringen ej blir ekonomiskt lönsam, vilket kan leda till att migreringsarbetet fallerar.

5.3.2 Dålig flexibilitet

(34)

granskning av fallet Handelsbanken finns vissa likheter. Primärt beskriver Handelsbanken problematik som kan uppstå om ett system vidareutvecklats under en lång tidsperiod. Handelsbanken beskriver att system som vidareut-vecklats mycket kan bli sönderförvaltade. Detta får till följd att systemen blir svåra att vidareutveckla ytterligare, vilket leder till att kostnaden för vida-reutveckling blir hög (4.3.4). Därför kan en migrering av systemen påbörjas av flexibilitetsskäl om de blivit sönderförvaltade.

5.3.3 Höga driftskostnader

(35)

Kapitel 6

Slutsats

Baserat på den insikt som uppnåtts vid den fallstudie som utförts, har en modell skapats innehållandes fem essentiella delprocesser som i fallstudi-en förekommit i fallstudi-en migrering från transaktionstunga legacy-system. Dessa delprocesser beskrivs utifrån de koncept och lösningar som Handelsbanken tillämpat under migreringsprocessen. Dessa anses som fördelaktiga att följa under en migreringsprocess där delar av ett transaktionstungt legacy-system skall migreras med liknande premisser som existerar för Handelsbanken. Att översätta källkoden för ett system från ett programmeringsspråk till ett an-nat är ej den mest utmanande delen av migreringsprocessen. Att omdefinera systemens arkitekturella struktur är istället mer kritiskt. De koncept som identifierats kan sammanfattas med följande punkter:

6.1

Stegvis migreringsprocess

Legacy-system i stora oraginstioner karaktäriseras av att de är komplexa. Systemen har ofta utvecklats under en längre tidsperiod och system som ur-sprungligen ej var förväntade har utvecklats och inkluderats i systemen under systemets livstid. Komplexiteten består även i att ett system ofta har en stor mängd kopplingar till andra system, vilket leder till att ett system ofta är beroende av andra systems funktionalitet för att fungera. Nya verksamhets-krav uppstår även löpande, vilket ställer verksamhets-krav på att systemen ständigt måste vidareutvecklas och underhållas. Därför måste migreringen ske stegvis, där delar av systemet migreras vid olika tidpunkter under migreringsprocess.

6.2

System väljs efter verksamhetskrav

(36)

att klara av att intreragera med det nya systemet, uppkommer den största kostnaden i början av migreringen. För att kunna motivera kostnader i denna skala är det därför viktigt att se till att det system som migreras kommer erbjuda ytterligare funktionalitet som skapar mervärde för verksamheten.

6.3

System väljs efter prestandakrav

En ytterligare anledning till att migrera och uppdatera system är att under-hålla och förbättra systemets hälsa. Detta kan vidare motiveras med verk-samheternas krav på tillgänglighet, stabilitet och säkerhet hos organisatio-nens system. Organisationen måste därför ha någon form av databas som samlar in och behandlar information om de olika systemens driftsstatus. På så sätt får beslutsfattare en enklare överblick över vilket system som är mest kritiskt att migrera för att bibehålla maximal systemhälsa.

6.4

Tydliga riktlinjer för arkitektur

Vid en migreringsprocess är det viktigt att tydligt definiera riktlinjer för de nya systemens arkitektur. Eftersom transaktionstunga legacy-system är mycket komplexa och ofta innehåller en stor mängd system, är det viktigt att de nya systemen följer en tydlig struktur. Följs ej detta och skillnaderna mel-lan systemen blir allt för stora, försvåras samverkan melmel-lan systemen samt att behov av kompetens inom fler områden skapas. När riktlinjerna för arki-tekturen defineras, finns möjlighet att välja till vilken detaljnivå riktlinjerna skall styra. Det viktiga är att riktlinjerna skapar en grund som utvecklarna kan följa när systemen skapas, för att undvika att för stora skillnader mellan systemen uppstår.

6.5

Ta hänsyn till den kontextuella förändring som

skett

(37)

Kapitel 7

Avslutande diskussion

Rörande den forskning som använts som underlag till studien kan kritik riktas mot den mängd litteratur som använts. Med tanke på att mängden publika-tioner som finns inom området är begränsad har det varit svårt att verifiera den kunskap som inhämtats via olika artiklar, detta då artiklarna i många fall är unika i sitt slag. För att säkerställa att det material som ligger till grund för både studien och dess analys är korrekt hade det varit fördelaktigt att ha multipla källor som talar om samma fenomen. Ytterligare kritik som kan riktas mot den teoretiska bakgrunden är att den primärt härstammar från relativt generell forskning. Det används alltså inget material som direkt riktar sig till miljöer där transaktionstunga system existerar. Anledningen till detta är att tillgången till sådan forskning är begränsad.

Vidare kan vissa aspekter av studiens genomförande granskas. Ämnesom-rådet är mycket komplext och omfattande. Det är därför svårt att under en kortare tidsperiod, motsvarande den som en C-uppsats innefattar, granska området med ett sådant djup som skulle behövas för att med säkerhet kunna dra exaktare slutsatser. Därav hade det varit av hög prioritet att genomfö-ra fallstudier på ytterligare organisationer för att verifiegenomfö-ra den kunskap som inhämtats hos Handelsbanken.

(38)

givande för uppsatsens validitet, eftersom uppsatsen syftar till att granska migreringsprocessen ur ett arkitekturmässigt perspektiv.

(39)

Litteraturförteckning

[1] Alkazemi BY. “A Framework to Assess Legacy Software Systems.” Jour-nal of software.

[2] Ashok RB Samuel, “Legacy-system: Migration Strategy”, 2005

[3] Bisbal J, Lawless D, Wu B, Grimson J. Legacy information systems: Issues and directions. IEEE Software 1999; 16(5): 103–111.

[4] Datamonitor, "COBOL – continuing to drive value in the 21st Cen-tury", 2008 Tillgänglig: http://www.microfocus.com/000/COBOL_ continuing_to_drive_value_in_the_21st_Century_tcm21-23652. pdf

[5] Molu, F., Software testing practices in critical financial systems trans-formation,Technological Advances in Electrical, Electronics and Com-puter Engineering (TAEECE), 2013 International Conference on , vol., no., pp.394,399, 9-11 May 2013

[6] Neeti Aggarwal, “Management Report: Roadmap to Successful Core Banking System Replacement Critical Success Factors and Best Practi-ces”, 2006

[7] Oates BJ. “Researching information systems and computing.” 2006, Lon-don: SAGE;

[8] Sneed, H.M.; Erdoes, K., Migrating AS400-COBOL to Java: A Report from the Field,Software Maintenance and Reengineering (CSMR), 2013 17th European Conference on , vol., no., pp.231,240, 5-8 March 2013 [9] Vranes, S.; Stanojevic, M., "Integrating multiple paradigms within the

References

Related documents

Fördelningar har gjorts med utgångspunkt i de olika typerna av disciplinära åtgärder, med hänsyn till stora och små byråer, mellan de större byråerna, samt

Är texten indelad i stycken så att läsaren förstår vad som hör ihop och när det händer något nytt?. Är det något som

”Sen är det så viktigt att om man nu kommer till sjukvården för någon skada eller något psykiskt att de fångar upp en för det är då man är mottaglig för att ta emot hjälp

Ett av målen som sattes upp för detta examensarbete var att undersöka vilken Linuxdistribution som kan lämpa sig bäst för LVI. Det visade sig att bygga sin egen

Med dessa tankar kring reflektionsprocessen vänder jag tillbaka till berättelsen ovan om mitt eget görande: ”Jag sågar, tolkar det jag ser, vrider klockan tillbaka och sedan

Egenskapen entusiasm hörde ihop med en av Företaget tre värderingar, nämligen den om att vara innovativ. Alla passar inte eller trivs med att ständigt byta arbetsplatser. För att

F¨ or att unders¨ oka sambandet mellan arbetsl¨ oshet och h¨ ogerpopulism anv¨ ands tv˚ a beroende variabler f¨ or st¨ od samt r¨ ostning p˚ a h¨ ogerpopulistiska partier och

Efter som subjunktion konkurrerade dock med konstruktioner där basala subjunktioner förstärkte den bisats- inledande funktionen, däribland efter som, som tidigare även