Softwaremigrering. Indledning

Transkript

1 Softwaremigrering Forord Nedenstående tekst er baseret på Migration guide version 3.0 Bundesministerium des Innern, april 2008 samt erfaringer mv. opbygget i ITST s OSS-projekt. Teksten er udarbejdet af Open Source Software (OSS) gruppen i Videnscenter for open source og åbne standarder juni Indhold: software migrering...1 Indledning...1 Behov og forudsætning for migrering...2 Integrationer...3 Konfigurationsintegration...3 Funktionel integration...3 Data integration...3 Juridiske aspekter i forbindelse med softwarelicenser...4 Projektmæssige aspekter ved migrering...5 Beslutning om migrering...5 To migrationsmodeller...6 Beslutningsstøtte...7 Succesfaktorer...8 Tekniske succes-faktorer...8 Økonomiske succes-faktorer...9 Organisatoriske success-faktorer...9 Software alternativer...9 Mere læsning...10 Indledning Migrering kan ganske kort beskrives på følgende måde: en virksomhed (ejer af systemer) flytter eller flyttes fra én eksisterende systemportefølje til en ny systemportefølje, der kan løse de samme eller tilsvarende opgaver som den oprindelige. Migrering gør sig gældende for alt lige fra opdateringer af den eksisterende systemportefølje til programpakker (software), der ændres til helt andre produkter og måske fra andre leverandører. Det følgende indeholder råd og vejledning vedrørende i princippet alle former for migrering; migrering der indebærer opdateringer, skift af enkelte programmer, skift mellem closed sourcemiljøer og overgang fra closed source-miljø til open source-miljø. 1

2 Denne tekst beskæftiger sig ikke med den situation, hvor systemejeren selv skal have opbygget (special-) komponenter til eksisterende software det, der benævnes som build -situation for ejeren af systemporteføljen. I stedet tages der udgangspunkt i eksisterende software/programmer (standard software), og dets muligheder for at udgøre et samlet eller delvist systemkompleks, der opfylder forretningens behov for it-understøttelse. Denne tekst har således anskaffelsessituationen som forudsætning. Behov og forudsætning for migrering En organisation kan være i en situation, hvor migrering skønnes nødvendig til trods for, at den kan være omkostningskrævende. Dette ses eksempelvis i forbindelse med: at vedligehold af det/de programmer, man anvender, af den ene eller anden grund ikke længere understøttes at omverdenen stiller nye krav til interoperabilitet, som man ikke kan opfylde med det eksisterende software at funktionaliteten ikke længere er tidssvarende at der skal ske softwaremæssig konsolidering at omkostninger ved eksisterende programportefølje er for høj Der kan være mange forskellige årsager til, at migrering skønnes nødvendig. Men før beslutningen om migrering tages, skal man gøre sig klart, at der ofte er tale om en langtidsinvestering et strategisk valg hvorfor beslutningen normalt kræver nøjere overvejelser. Et sådant valg kræver mange forskellige overvejelser. Men det skal fremhæves, at man i hvert fald på den tekniske side er nødt til at overveje om: eksisterende data, dokumenter etc. kan overføres til de nye systemer man opnår et interoperabelt og integrerbart miljø man vil komme til at operere i et miljø med åbne standarder og åbne standardiserede interfaces Når man vælger at migrere, er et typisk strategisk mål at opnå åbenhed. I denne kontekst forstås åbenhed som brug af åbne standarder og interfaces. Som følge af åbenhed opstår en vis grad af leverandøruafhængighed, og man undgår lock-in vedrørende sin systemportefølje. Åbenhed 2

3 som strategi sikrer investeringen i migrering bedst på længere sigt, fordi man derved står stærkere i forhold til på et senere tidspunkt at komme ud af bestemte produkt- og leverandørforhold. Integrationer En væsentlig problemstilling i forbindelse med softwaremiljøer er muligheden for integrationer mellem programmer. Når der skal migreres, er det derfor meget relevant at vurdere integrationsmuligheder i det fremtidige softwaremiljø. Der findes forskellige måder at betragte integration på. Migration guide version 3.0 opgør bl.a. konfigurationsintegration, funktionel integration og dataintegration. Konfigurationsintegration Konfigurationsintegration er den situation, hvor der anskaffes/købes programmer, som på forhånd er udviklet til at kunne integrere. Integration af sådanne programmer sker via konfiguration ved installationen, og sker relativt automatisk. Denne type integration sparer både tid og penge uden at sætte begrænsninger for hverken de enkelte komponenter eller programporteføljen i sin helhed. Funktionel integration Funktionel integration er karakteriseret ved, at funktionalitet knyttet til ét program også kan udnyttes i et andet program. Et eksempel er, at et tekstbehandlingsprogram kan tilknytte regnearksfunktionalitet, eller at et program tillader brug af hyperlinks til internetadgang. Data integration Dataintegration handler om genbrug af data og kommunikationsprotokoller, forstået på den måde, at flere programmer kan udveksle og tilgå de samme data via standardiserede grænseflader. Dataintegration forudsætter normalt, at der eksisterer en fælles anvendt datamodel. Generelle betragtninger i forhold til integration I forbindelse med integrationer bør det tages i betragtning, at en meget høj grad af integration, eksemplificeret ved konfigurationsintegration og funktionel integration, indebærer en risiko for overdreven interlinkning. Det betyder, at programmer eller komponenter bliver for afhængige af hinanden og dermed ikke kan skiftes individuelt. Leverandørafhængigheden bliver således relativt høj. Omvendt er løs kobling mellem programmer/komponenter ved hjælp af standardiserede grænseflader mere fleksibel både med hensyn udskiftning af programmer og med hensyn til leverandøruafhængighed. 3

4 Der gælder endvidere for integration mellem programmer, at jo mere udbredt et program er på markedet, desto mere sandsynligt er det, at der allerede findes mulige integrationer til andre programmer. Der er udført færre integrationer til mindre udbredte programmer, hvorfor man typisk er henvist til selv for at få udviklet eventuelt nødvendige integrationer. Juridiske aspekter i forbindelse med softwarelicenser Overvejelser i forbindelse med anskaffelse og implementeringer af software indebærer overvejelser både om mulig anvendelse af closed source software og open source software. Beslutninger om at migrere til closed source software og/eller open source software bør hovedsageligt være baseret på tekniske og økonomiske kriterier og vurderinger. Derudover spiller juridiske overvejelser ofte også ind. Et eksempel herpå ses i usikkerhed om, hvorvidt man er juridisk dårligere stillet ved anvendelse af open source software i forhold til closed source software. Der er normalt forskel på fremstillingsbetingelser og licensbetingelser for closed source software og open source software, selvom anskaffelse og benyttelse af de to i bund og grund er sammenlignelige. Brugeren må, som altid ved softwareanskaffelser, sikre sig, at den valgte software giver ham/hende de fornødne frihedsgrader. Dertil skal tilføjes, at de licensspørgsmål, der angår videredistribution af både open source software og closed source software, ikke opstår ved brugerens egen anvendelse af softwaren. En anden vigtig forskel på closed source software og open source software vedrører fremstillingsbetingelserne. Traditionelt fremstillet software har ofte én fremstiller eller et softwarehus hvorimod open source software ofte har mange fremstillere (måske enkeltpersoner). I hvert fald er det typisk for open source software-licenser, at licensgiveren fraskriver sig ethvert ansvar for programmets funktionalitet. Med en kommerciel leverandør af open source software er der dog mulighed for hos leverandøren at tilkøbe forskellige garantier, som denne følgende er forpligtet til at overholde. Disse forhold har betydning i forbindelse med fejlrettelser, opdateringer og lignende. Men risikoen ved open source software anses normalt ikke for at være markant anderledes end for closed source software. I forbindelse med closed source software er det op til softwarehuset og dets forretningsmæssige overvejelser, om man vil holde et program ved lige med nye opdateringer mv. Vælger 4

5 softwarehuset ikke at gøre dette, har brugeren ikke mulighed for at vedligeholde programmet det har brugeren derimod ved anvendelsen af open source software. Der findes eksempler på, at open source software-programmer har eksisteret, og er blevet vedligeholdt godt i mere end 10 år en tidshorisont, der er sammenlignelig med de længstlevende closed source software-programmer. Som udgangspunkt er det således ikke juridiske grunde, eksempelvis licensforhold, der hindrer anskaffelsen og brug af open source software. Derimod skal man, som ved alle andre køb der fordrer vedligehold, vurdere modenhed og stabilitet af producenten/ophavet. Dette gælder både closed source software og open source software. Projektmæssige aspekter ved migrering Beslutning om migrering Beslutningen om at foretage en hel eller delvis migrering kan baseres på mange forskellige kriterier som for eksempel et ønske om leverandøruafhængighed eller for et opnå et mere uniformt driftsmiljø, hvor supportomkostninger minimeres. Andre typiske årsager til migrering er, at enkelte programmer hele eller dele af programporteføljen ikke længere vedligeholdes, eller forskellige inkompatible driftsmiljøer skal sammenlægges til én driftsorganisation. Uanset hvilke kriterier, der spiller ind forudsat at tekniske og funktionelle behov/krav er opfyldt vil økonomiske kriterier altid være tungtvejende. Økonomiske sammenligninger vil for softwares vedkommende så vidt muligt tage udgangspunkt i TCO (Total Cost of Ownership), dvs. opgørelser, der ikke alene vedrører investeringer, men også medtager fremtidige driftsomkostninger, vedligeholdelsesomkostninger, supportomkostninger mv. I forbindelse med beslutninger om migrering bør det som minimum også overvejes grundigt, om organisationen har: udviklet en generel IT-strategi, der indeholder finansielle, organisatoriske, medarbejdermæssige samt udviklingsmæssige aspekter. fastlagt en softwareplatformstrategi, der indeholder langsigtede økonomiske aspekter samt tager forskellige former for softwaremuligheder i betragtning, herunder open source software 5

6 identificeret alle standarder, der er nødvendige for at sikre genbrugelighed såvel som interoperabilitet overblik over de produkter (programmer), som opfylder organisationens valgkriterier defineret et migreringsprojekt, herunder tidsplaner, aktionslister samt tilhørende budgetter Er ovenstående punkter vurderet, og måske endda dokumenteret, er en del af fundamentet for at iværksætte en migrationsproces tilstede. Det skal dog bemærkes, at ovenstående ikke er fuldt ud fyldestgørende overvejelser, samt at jo mere af programporteføljen, der ønskes migreret, jo mere kompleks vil migrationsprojektet være med tilhørende nøjere projektplanlægning. To migrationsmodeller Migrering af et eller få programmer er relativt enkel ud fra et projektplanlægningssynspunkt. Omfatter migreringen hele eller en stor del af programporteføljen, må man være mere omhyggelig. Som hovedregel og som planlægningsmæssige yderpunkter kan man vælge mellem at foretage migrationen som big-bang eller som blid overgang. Big bang -metoden er karakteriseret ved hurtighed samt på forhånd fastlagte grænser for start- og sluttidspunkter for migreringen. Big bang -modellen stiller store krav til projektplanlægning, overblik, organisationens modenhed (fra it-administratorer til brugere) og evnen til at gennemføre projekter. Fordelen ved metoden er primært, at organisationen (især it-driftsorganisationen) ikke skal håndtere to forskellige programporteføljer i længere tid. Den blide overgang, som metodemæssigt til en vis grad ligner agil udvikling, er karakteriseret ved, at der enkeltvis migreres én komponent eller samhørende komponentserie. Der er forskellige fordele knyttet til den metode: omkostninger ved migrering kan fordeles over en længere periode erfaringer fra de første migreringer kan bruges på de følgende migreringsprocesser. organisatoriske forbehold og andre barrierer kan fjernes gradvist komplekse IT-systemer kan trevles op stykke for stykke Det er dog ikke muligt at migrere komponenter helt tilfældigt. Det, der hører sammen, skal også migreres sammen. Ligeledes er det vigtigt at operere med realistiske deadlines og hele migreringen bør ikke omfatte mere end to til tre faser. 6

7 Beslutningsstøtte IT- og Telestyrelsen har udarbejdet en beslutningsstøttemodel for valg af software med henblik på at udvikle et værktøj, som tager udgangspunkt i regeringens softwarepolitik. Regeringens softwarestrategi fra 2003 fastsætter følgende principper for anvendelse af software i offentlige myndigheder: bedst og billigst uanset softwaretype konkurrence, uafhængighed og valgfrihed sammenhæng og fleksibilitet udvikling og innovation. IT- og Telestyrelsen har udarbejdet seks principper i forlængelse af softwarestrategien. Disse principper er til støtte for den offentlige sektors beslutninger i forhold til anvendelse af open source software, og fokuserer på kriterier, som bør indgå i offentlige myndigheders softwarevalg. Bedst og billigst uanset softwaretype Den enkelte myndighed skal have mulighed for at erhverve den bedste og billigste software ud fra lokale forvaltningsmæssige behov, uanset om der er tale om closed source software eller open source software. Software skal vælges på baggrund af en vurdering af en samlet business case. Konkurrence Velfungerende konkurrence er en forudsætning for et effektivt og varieret softwaremarked. Open source understøtter, at softwaren kan vedligeholdes og videreudvikles af flere leverandører. Softwareleverandører skal på lige vilkår kunne tilbyde deres it-ydelser til det offentlige. Kontrol og selvbestemmelse Anvendelse af open source software sikrer kontrollen over softwaren. Dermed kan den enkelte myndighed bestemme, hvornår og hvordan softwaren skal opdateres, udvikles og eventuelt deles med andre myndigheder. Sammenhæng og fleksibilitet Myndigheder skal satse på software, der opbygges i mindre dele, og som ved hjælp af åbne standarder er i stand til at kommunikere med andre typer software. Derved sikres det, at enkelte dele af softwaresystemet uafhængigt kan udskiftes til gavn for fleksibilitet, genbrug og konkurrence på området. 7

8 Udvikling og innovation Myndigheder skal ved udvikling af software overveje, hvilken softwareudviklingsmodel herunder open source-udviklings- og forretningsmodel som bedst understøtter innovation og hurtig udvikling af nye produkter og services. Egenudviklet software bør som udgangspunkt stilles til rådighed med en open source-licens. Det betyder ikke, at gamle metoder skal opgives, men at flere metoder kan leve side om side, og nye kan afprøves, så fordele og ulemper kan afklares i forhold til den danske forvaltnings virkelighed. Genbrug af software Anvendelse af open source software kan sikre, at skatteborgerne undgår at betale for udvikling af den samme software flere gange. Succesfaktorer For at sikre at migrationsprojekter forløber succesfuldt bør kritiske succesfaktorer identificeres og vurderes på forhånd. Her er det vigtigt at forstå, at migrering, såvel som al anden form for softwareanskaffelse, skal vurderes på dets påvirkning af eller tilknytning til i hvert fald tre forskellige aspekter, der er vitale for virksomheden. Der er tekniske aspekter, økonomiske aspekter og organisatoriske aspekter at tage hensyn til, når software implementeres i virksomheden. Fokuseres der ikke på alle tre aspekter, er der stor risiko for, at implementeringsprojektet ikke vil blive en umiddelbar succes. Glemmes eksempelvis de organisatoriske aspekter, er der risiko for, at det nye software vil virke fremmedartet og ubrugbart for brugerne, hvorfor det vil blive mødt med uvilje af brugerne. Migration guide version 3.0 deler således succesfaktorerne op i tekniske, økonomiske og organisatoriske succesfaktorer: Tekniske succesfaktorer: Fuldstændig opgørelse af behov, herunder funktionalitet Migrering skal ses i den samlede kontekst; dvs. i forhold til hele systemporteføljen Dokumentation af start og slut konditioner samt beslutninger undervejs Brug af teknologier baseret på åbne standarder Klarhed over hvilke dele af funktionaliteten, der ikke migreres 8

9 Økonomiske succesfaktorer Opgørelse af klare fordele af migreringen (eksempelvis ved anvendelse af TCO-opgørelse) Klar projektplan Projektopfølgning og overvågning Inddrage ledelsen i migrationsprojektet (budget og økonomi) Organisatoriske succesfaktorer Information om rationalet bag migreringen Inddrage ledelsen i migrationsprojektet Etablering af kvalificeret projektgruppe Uddelegering af ansvar Inddrage involverede brugere og andre interessenter Oplæring af brugere, it-personale og andre, der får at gøre med den nye software Software-alternativer Det følgende er henvisninger til netsteder, der indeholder alment udbredte open source softwarealternativer fordelt på kategorier eller til fremsøgning. Softwaren, der findes via disse netsteder, kan typisk downloades og installeres gratis. Netsted hvorfra open source-programmer kan downloades. Opdeler programmerne i antal overordnende kategorier. Dansk netsted med henvisning til et udvalg af alment brugte open source-programmer. Netsted med et meget stort antal af open source-programmer specielt for brugere på Linuxplatformen. Netsted med mulighed for at finde open source software som alternativ til closed source software 9

10 IT- og Telestyrelsens oversigt over open source-komponenter udviklet i Danmark af communities tilknyttet Softwarebørsen. Mere læsning Migration guide version 3.0 Bundesministerium des Innern, april 2008 via Foruden generelle betragtninger vedrørende migrering indeholder denne guide en omfattende gennemgang og detaljeret beskrivelse af software-alternativer, der angår meget store dele af den mest almindelige it-understøttelse, en organisation har behov for. Af områder kan nævnes databaser, directory services, netværksservices, printservices, systemovervågning, groupware, office-systemer og terminalservices. Gennemgangen indeholder beskrivelser af både closed og open source software til de forskellige formål. Open source-software i det offentlige Ministeriet for Videnskab Teknologi og Udvikling, 2008 via Retlige forhold vedrørende anskaffelse og brug af open source software IT- og Telestyrelsen, 2008 via Vejledning i anskaffelse af standardsoftware baseret på open source IT- og Telestyrelsen, 2007 via 10