Serviceorienteret arkitektur - Hvad og hvorfor

Transkript

1

2 > Serviceorienteret arkitektur - Hvad og hvorfor IT- & Telestyrelsen November 2006

3 Indhold > Forord 6 1. Indledning Formål og baggrund Målgruppe Pjecens struktur 8 Del 1 - SOA i den offentlige sektor De grundlæggende elementer i SOA 9 Hvad er SOA? 9 Den ideelle SOA 12 Den realistiske SOA 12 Hyppige misforståelser omkring SOA SOA, Enterprise Arkitektur og digital forvaltning Målsætninger med SOA i den offentlige sektor 18 Udfordringer i den offentlige sektor 18 SOA ikke et mål, men et middel Hvor går grænserne for SOA i den offentlige sektor? Indførelse af SOA i den offentlige sektor 25 Ikke kun en teknisk disciplin 25 Udgangspunktet er forretningens processer og begreber 26 Behov for en sammenhængende arkitektur 27 Services skal være synlige og veldokumenteret 28 Behov for styring og koordinering 29 De eksisterende løsninger 31 Den offentlige sektor skal selv gå forrest IT- og Telestyrelsens anbefalinger Afrunding 35 Del 2 - SOA en mere detaljeret gennemgang Generelle SOA principper 37 Forretningsrelaterede services 39 Genbrugelige services 39 Kontraktbaserede services 40 Løst koblede services 41 Platformsuafhængig anvendelse af services 41 Lokationsuafhængig anvendelse af services 42 Sammensætning af services 43

4 < Services er en abstraktion over forretningsfunktionalitet og information 44 Services versioneres 45 Services registreres og er synlige 46 SOA er baseret på standarder SOA set i forskellige perspektiver SOA som en lagdelt arkitektur 50 Præsentationslaget 51 Serviceorkestrerings- og workflowlaget 51 Servicelaget 53 Serviceimplementeringslaget Teknisk fundament SOA, komponenter og objektorientering Udviklingsproces og metode 63 5

5 Forord > Digital forvaltning handler i høj grad om at skabe en sammenhængende og effektiv offentlig sektor, hvor nytten af relevante borger- og virksomhedsrettede services er høj. Et væsentligt middel i arbejdet med at skabe sammenhæng og effektivitet, er konceptet serviceorienteret arkitektur, som i de senere år har vundet mere og mere indpas som et strategisk værktøj i digital forvaltning. Hovedprincippet i den serviceorienterede arkitektur (SOA) er, at opbygge fleksible og genbrugelige løsninger, der understøtter forretningens behov optimalt. Denne SOA pjece er skrevet som et led i opfølgningen på Hvidbogen- og Håndbogen om it arkitektur, der tilsammen er med til at sætte de overordnede rammer for arkitekturarbejdet i den offentlige sektor. SOA pjecen beskriver i et enkelt sprog, hvad SOA er; hvad værdien af SOA er; hvilke problemstillinger SOA er med til at løse, samt IT- og Telestyrelsens anbefalinger til arbejdet med SOA. Du kan læse mere om det fællesoffentlige arkitekturarbejde på Marie Munk Vicedirektør IT- og Telestyrelsen 6

6 1. Indledning < 1.1 Formål og baggrund Serviceorienteret Arkitektur (SOA) er et begreb, der igennem de senere år er blevet anvendt om en bestemt tilgang til udvikling af it-løsninger. Afhængig af baggrund og motivation anvendes SOA i mange sammenhænge og med fokus på forskellige aspekter af it. Der findes ikke en almindelig anerkendt definition af SOA, hvorfor det er nødvendigt at gøre sig klart, hvad den offentlige sektor forstår ved SOA, og hvilke resultater offentlige myndigheder ønsker at skabe gennem anvendelse af SOA. Pjecens formål er at give en grundlæggende forståelse for SOA i den offentlige sektor, herunder: > Hvad er SOA og hvad består det af? > Hvad er værdien af SOA i den offentlige sektor? > Hvilke problemstillinger er SOA med til at løse? > Hvad er IT- og Telestyrelsens anbefalinger til arbejdet med SOA? Den offentlige sektor står over for en rivende udvikling i de kommende år. Strukturreform, krav om en effektiv opgaveløsning med borgeren i centrum, krav om mere service for færre penge og færre hænder til at løfte opgaverne slår for alvor igennem i de kommende år. Itløsninger er et centralt element i fht. at kunne imødekomme udfordringerne. Digitale løsninger skal i endnu højere grad skabe nytteværdi for medarbejdere, borgere og virksomheder. Anvendelsen af SOA i den offentlige sektor er ikke kun en teknisk disciplin. Det er et forandringsprojekt, som kræver ledelsesmæssig fokus, en organisatorisk modenhed og opbygning af en række nye kompetencer. 7

7 > 1.2 Målgruppe Denne pjece henvender sig både til beslutningstagere i den offentlige sektor statsligt, regionalt og kommunalt og til deltagere i arkitekturarbejdet projektledere, brugerrepræsentanter, it-arkitekter, leverandører, konsulenter, rådgivere m.fl. med interesse i offentlige itprojekter. Del 1 er primært målrettet beslutningstagere. Del 2 er skrevet ud fra en mere teknisk synsvinkel, og forudsætter derfor en vis indsigt i SOA. 1.3 Pjecens struktur Pjecen er opdelt i to dele, hvor første del SOA i den offentlige sektor indeholder en kortfattet ikke-teknisk gennemgang af de grundlæggende elementer i SOA, målsætningerne med at indføre SOA i den offentlige sektor samt overvejelser og anbefalinger til, hvordan denne forandringsproces kan gribes an. Første del er målrettet læsere, der ud fra et ikke teknisk perspektiv ønsker at skabe sig et overblik over, hvad SOA er, og hvilke målsætninger den offentlige sektor typisk har med SOA. Anden del af pjecen SOA en mere detaljeret gennemgang gennemgår bl.a. principperne, arkitekturlagene, udviklingsprocessen og det tekniske fundament for SOA med flere tekniske detaljer. Anden del er målrettet læsere, som ønsker en mere detaljeret indsigt og indføring i SOA. 8

8 Del 1 - SOA i den offentlige sektor < 2.1 De grundlæggende elementer i SOA Hvad er SOA? I denne pjece defineres SOA som en arkitekturmæssig stilart, der ligesom arkitekturmæssige stilarter kendt fra bygningsarkitektur har sine egne unikke karakteristika og principper, f.eks. gennem fokus på genbrug, optimal forretningsunderstøttelse, stærkt aftalegrundlag m.v. Det betyder ikke, at SOA er nyt og unikt på alle områder. SOA er en evolutionær arkitekturmæssig stilart, der bygger på fortidens innovationer og erfaringer, som blandes med nye måder at anskue udvikling af it-løsninger på, og som derfor bliver til en unik stilart. SOA er et begreb, der anvendes hyppigt i forskellige sammenhænge og med forskellig betydning. Der bliver ofte sat lighedstegn mellem SOA og anvendelsen af webservices 1. Mens anvendelse af webservices hovedsagelig er en teknisk disciplin, rækker SOA langt videre og tager udgangspunkt i en grundlæggende forståelse af myndighedens forretningsprocesser og information. SOA en tilgang til udviklingsprocessen SOA kan samlet set beskrives som en tilgang til udviklingsprocessen, der med udgangspunkt i forretningen fører frem til udvikling, anskaffelse og anvendelse 1 En webservice er en service, der med anvendelse af en række standarder og teknologier muliggør platformsuafhængig kommunikation via Internettet. Webservice er beskrevet nærmere i kapitel 3.4 Teknisk fundament. 9

9 > af it-løsninger som et sæt af forretningsunderstøttende, genbrugelige og fleksible services. Servicekonceptet SOA bygger på et servicekoncept, der understøtter, at funktionalitet kan betragtes og behandles som selvstændige, uafhængige enheder uden dog at være isoleret helt fra hinanden. Disse selvstændige enheder af funktionalitet kaldes i SOA for services, f.eks. servicen hent personoplysninger. Fælles principper og standarder sikrer, at de på den ene side kan udvikle sig individuelt over tid, mens de på den anden side også kan fungere samlet og sammensættes således, at de understøtter forretningsprocesserne ud fra en helhedsbetragtning. Det kunne eksempelvis være processen boligstøtteansøgning, hvori servicen hent personoplysninger kunne indgå. SOA bygger på det ganske enkle forhold, at der findes to parter, en serviceleverandør og en serviceanvender. Serviceleverandøren tilbyder og udstiller udførelsen af en veldefineret og afgrænset aktivitet en service mens serviceanvenderen på den anden side efterspørger og anvender denne service. Services kan rumme meget eller lidt funktionalitet og dermed være både små og store. Der kan ikke gives et entydigt svar på, hvor stor en service bør være, men blot at en service skal være meningsfuld for den tiltænkte anvender af servicen. Services kan sammensættes af andre services, hvilket giver mulighed for at tilbyde nye services, der på baggrund af eksisterende services, understøtter nye forretningsbehov. 10

10 < Elementerne i SOA Figur 1 illustrerer elementerne i SOA i hovedtræk. Figur 1: Elementerne i SOA. Det er først og fremmest myndighedens strategi, mål, forretningsprocesser og information, der udgør de grundlæggende elementer, som SOA bygges på og skal understøtte. SOA processen er de processer, metoder, principper og styring, der sikrer at forretningens målsætninger understøttes med SOA. Endelig er der selve SOA produktet, som er resultatet af SOA processen. SOA produktet består af løsningerne, som automatiserer og understøtter forretningsprocesserne, services som løsningerne opbygges af og endelig den tekniske infrastruktur, der gør det muligt at afvikle de serviceorienterede løsninger. 11

11 > Den ideelle SOA SOA repræsenterer en vision om en ideal verden, hvor alle informationer og al funktionalitet er klart og entydigt opdelt i uafhængige og forretningsunderstøttende services, der kan sammensættes på tværs af organisatoriske skel. Den serviceorienterede arkitektur er således et idealbillede et målbillede for en fremtidig fleksibilitet og interoperabilitet i den offentlige sektors it-understøttelse. Vejen til den ideelle SOA er en lang og kompliceret rejse, der kun kan nås ved bevidst at arbejde hen imod idealbilledet både tværgående og lokalt i den enkelte myndighed. Den realistiske SOA Vejen frem mod det ideelle målbillede for SOA forvirres ofte af en række misforståelser omkring SOA, hvor SOA blot betragtes ud fra en teknologisk synsvinkel. Dertil kommer, at mange eksisterende løsninger bygger på en arkitektur, der ikke nødvendigvis er i overensstemmelse med SOA målsætningen. En realistisk vej frem mod SOA i den offentlige sektor bør tage udgangspunkt i forretningens processer og begreber, et antal klart definerede principper og en fastlagt udviklingsproces. De vigtigste fokusområder er: > Sikring af at de enkelte services designes som forretningsservices - afgrænset ud fra de relevante forretningsprocesser og forretningsbegreber. > Sikring af at løsningen (herunder også standardsystemer) både kan anvende eksterne services og udstille egne services, som andre it-systemer kan benytte. 12

12 < Hyppige misforståelser omkring SOA SOA er de senere år blevet et modeord, som de fleste leverandører anvender i deres markedsføring. Det er vigtigt ikke at sætte en ny mærkat på gammel teknologi og markedsføre den som SOA uden at tage hensyn til, at SOA repræsenterer sin egen arkitekturmæssige stilart, der bygger på en række definerede og beskrevne principper. Eksempler på SOA principper er beskrevet i pjecens del 2. En af de hyppigst forekommende misforståelser er en tendens til at sætte lighedstegn mellem SOA og webservices, således at anvendelse af webservices automatisk fører til SOA. Det er vigtigt at gøre sig klart, at webservices kun er ét aspekt ved SOA. SOA er ikke kun et spørgsmål om den tekniske arkitektur og anvendelse af en række tekniske standarder. Selvom tekniske standarder er et væsentligt element i SOA, skal der langt mere til end webservices for at høste fordelene ved SOA. Risikoen ved alene at fokusere på de tekniske standarder og anvendelse af webservices kan være en række uhensigtsmæssigheder i arkitekturen, eksempelvis: > Manglende helhed og interoperabilitet i den samlede portefølje af services > Services der ikke understøtter forretningsprocesserne > En struktur hvor services ikke kan sammensættes og genbruges af andre services. Ensidig fokus på webservices vil med andre ord ikke nødvendigvis indfri forventningerne til SOA. 13

13 > En anden hyppig misforståelse er, at distribuerede softwareløsninger er det samme som SOA. Visse former for distribueret softwareløsninger anvender ganske vist også servicebaserede principper i en vis udstrækning, men mange af disse er ofte baseret på proprietære standarder, der vanskeliggør integration til løsninger baseret på andre teknologier. En tredje misforståelse udspringer af brugen af udviklingsværktøjer med automatiserede faciliteter til definition af services ved hjælp af indkapsling af programkode. Da disse services således ofte vil blive designet ud fra et teknisk perspektiv med udgangspunkt i it, og ikke i forretningsprocesser, vil de isoleret set sjældent bidrage til, at man opnår de ønskede målsætninger med SOA. 14

14 < 2.2 SOA, Enterprise Arkitektur og digital forvaltning Hvordan er det nu lige med SOA? Er det ikke bare et nyt navn for Digital forvaltning og Enterprise Arkitektur? Det er det ikke! Der er sammenhæng, men de har hver deres fokusområde. Digital forvaltning: Projekt Digital forvaltning har i strategien for defineret fem pejlemærker: 1. Den offentlige sektor skal levere sammenhængende ydelser med borgere og virksomheder i centrum. 2. Digital forvaltning skal skabe øget servicekvalitet og frigøre ressourcer. 3. Den offentlige sektor skal arbejde og kommunikere digitalt. 4. Digital forvaltning skal baseres på en sammenhængende og fleksibel it-infrastruktur. 5. Offentlige ledere skal gå forrest og sikre, at deres organisation kan realisere visionen. Formålet er således at udbrede digital kommunikation til at dække størstedelen af de informationer, der udveksles mellem offentlige myndigheder, samt at den digitale kommunikation også udbredes mellem de offentlige myndigheder, borgere og virksomheder. 15

15 > Dette omfatter eksempelvis løsninger som: > tilbyder elektronisk adgang til en række offentlige servicetilbud, eksempelvis biblioteker og folkeregister. > elektroniske løsninger der erstatter en arbejdsgang som eksempelvis indgivelse af selvangivelse. > etablering af portaler med tværgående services i stedet for forvaltningsspecifikke websider. Digital forvaltning og SOA: Løsningerne omkring digital forvaltning kan etableres på mange forskellige måder. SOA er blot en af flere løsningsmodeller hertil. Grunden til at SOA er den foretrukne model er, at SOA udover en effektiv understøttelse af digital forvaltning er med til at give en række andre fordele som beskrevet i forbindelse med SOA principperne i pjecens del 2. Enterprise Arkitektur (EA): EA er en sammenhængende arkitektur over hele forretningen og er ikke kun afgrænset til it-løsninger. I denne disciplin skabes der et overblik over den samlede offentlige sektor på forskellige niveauer og i forskellige perspektiver. Etableringen af en EA betyder, at løsninger beskrives ud fra en fælles begrebsramme, og at den enkelte it-løsning organiseres således, at den kan indgå i et funktionelt samspil med de øvrige it-løsninger. EA giver således et overblik over sammenhængen mellem forretning og it. Der arbejdes i EA med et helhedsbillede af, hvordan alle aspekter af it-løsningerne understøtter de 16

16 < forretningsmæssige mål. Herved opnås mulighed for at vurdere it-løsningernes forretningsmæssige betydning. EA bruges således til at sikre, at politiske og administrative visioner omsættes i de ønskede løsninger. Enterprise Arkitektur og SOA: EA er et arkitekturbillede, som dels hjælper den offentlige sektor til at skabe et overblik over strategi, forretningsprocesser, informationsstrømme, teknologiressourcer m.m. og dels hjælper med at planlægge udviklingen heraf. SOA er en retning, man kan vælge for denne udvikling ved at anvende SOA principper, eksempelvis løs kobling, genbrug m.m. SOA er dermed et middel til at operationalisere udvalgte dele af den samlede EA, hvorfor SOA er en del af en myndigheds samlede EA. Enterprise Arkitektur og digital forvaltning: Et projekt som digital forvaltning er ikke muligt at gennemføre, med mindre der er en sammenhængende styring og planlægning af arkitekturen. Denne del håndteres via en Enterprise Arkitektur, som i denne sammenhæng også kaldes for Arkitektur for digital forvaltning. I forhold til projekt digital forvaltning er en sammenhængende offentlig Enterprise Arkitektur en afgørende forudsætning for at kunne realisere visionerne om en offentlig digital forvaltning. 17

17 > 2.3 Målsætninger med SOA i den offentlige sektor Udfordringer i den offentlige sektor Den offentlige sektor står over for en rivende udvikling i de kommende år. It-løsningerne skal dække en større del af opgaverne. De skal skabe nytteværdi for medarbejdere, borgere og virksomheder, på flere fysiske lokationer, og i en større del af døgnet. Den offentlige sektor skal kunne levere mere service med færre ressourcer, og it skal være et af midlerne til at opnå denne effektivisering. Det kræver bl.a. forøget genbrug og standardisering af it-løsninger både på tværs af og i de enkelte myndigheder. En anden udfordring er, at samspillet med de offentlige myndigheder, borgere og virksomheder skal forbedres. Borgere og virksomheder skal ved hjælp af it-løsninger, på mange områder, kunne udføre de samme opgaver, som de ansatte hos de offentlige myndigheder. Borgerne skal kunne vælge mellem forskellige medier og kontaktpunkter. Uanset om borgerne vælger at bruge Internettet eller møder personligt op i et borgerservicecenter, skal de opleve samme behandling og have de samme muligheder. En tredje udfordring er, at der lokalt i de enkelte myndigheder skal være frihedsgrader til understøttelse af lokale forskelligheder. De lokale myndigheder skal på en række områder selv kunne vælge egne arbejdsgange og sammensætte egne it-løsninger, der hvor det er nødvendigt for myndighedsspecifikke målsætninger. For at kunne gøre dette på en økonomisk effektiv måde, skal de enkelte it-løsninger hvad enten disse er centrale eller lokale 18

18 < kunne samles af service-byggeklodser, hvor hver service svarer til en velafgrænset del af den samlede arbejdsgang. SOA ikke et mål, men et middel SOA er ikke et mål i sig selv, men derimod et middel til at indfri målsætningen om at skabe en mere sammenhængende offentlig sektor med nemmere adgang til data på tværs af it-systemer og organisatoriske skel. I betjeningen af den enkelte borger eller virksomhed vil SOA være et af midlerne til at sikre et sammenhængende udbud af serviceydelser, hvor løsningerne tager udgangspunkt i borgerens og virksomhedens behov. SOA vil sammen med det øvrige fællesoffentlige arkitekturarbejde med fælles metoder, referencemodeller, datastandardisering, etc. gøre det nemmere for borgerne og virksomheder at kommunikere med det offentlige via en bred vifte af tilgængelige digitale tjenester. Borgere og virksomheder slipper for at skulle afgive de samme oplysninger igen og igen til forskellige myndigheder og it-systemer. I SOA er målsætningen, at man kun afgiver de samme oplysninger én gang og får en hurtigere og mere sammenhængende sagsbehandling også i de tilfælde hvor mere end én myndighed er involveret. 19

19 > For mange virksomheder handler det først og fremmest om at bruge mindst mulig tid på administrative byrder. Virksomhederne ønsker typisk: > at få svar på henvendelser så hurtigt som muligt, > at det offentlige giver ens og forudsigelig behandling hver gang, og > at opgaver afsluttes i én arbejdsproces, hvor kun én myndighed skal kontaktes. SOA er et af midlerne til at indfri virksomhedernes ønske om at minimere de administrative byrder i forhold til det offentlige. For det offentlige er SOA interessant, fordi det giver mulighed for at kunne yde en bedre service over for virksomheder og borgere, men herudover vil SOA på en række områder også kunne effektivisere arbejdsgangene i den offentlige sektor. Målet er derfor en øget kvalitet i de offentlige service i form af bedre produkter, hurtigere sagsbehandlingstid, færre fejl m.v. I samarbejdet mellem den offentlige og private sektor vil SOA bidrage til at understøtte en mere fleksibel placering af de enkelte opgaver. SOA gør det muligt at placere opgaverne der, hvor de udføres bedst og billigst offentligt eller privat. Services fra eksterne partnere kan anvendes i stedet for egne services, ligesom eksterne partnere kan anvende services stillet til rådighed af det offentlige. 20

20 < Målsætningerne med SOA inden for den offentlige sektor er mangfoldige. Således er SOA, sammen med bl.a. datastandardiseringstiltag omkring OIOXML 2, et vigtigt middel til at opnå en sammenhængende digital forvaltning inden for den offentlige sektor. Udover at SOA kan anvendes som middel til at adressere en række specifikke målsætninger i den offentlige sektor, understøtter SOA ligeledes følgende generelle målsætninger: It der afspejler forretningsprocesser Den offentlige sektor har et ønske om at udvikle løsninger, der understøtter hele forretningsprocesser frem for isolerede it-systemer, der kun understøtter en del af forretningsprocessen og ofte er opbygget ud fra en bestemt organisatorisk synsvinkel. Disse isolerede it-systemer betegnes ofte som silosystemer. Figur 2:Eksisterende it-løsninger som silosystemer. 2 OIOXML fastlægger standarder for dataudvekslingen mellem offentlige myndigheder og mellem det offentlige og private virksomheder. 21

21 > En vigtig målsætning med SOA er derfor, at it-løsninger bygger på forretningens processer og begreber uden at lade sig begrænse af den aktuelle organisatoriske eller systemmæssige strukturer. Identifikation, anskaffelse og anvendelse af services sker med udgangspunkt i veldokumenterede procesmodeller og informationsmodeller. På denne måde sikres en konsistent forståelse af forretningsprocesser og forretningsbegreber, som medvirker til en forretningsdrevet anskaffelse og anvendelse af it-løsninger baseret på services. Omstillingsparathed Den offentlige sektor stiller stadig større krav til hurtigt at kunne implementere forandringer som følge af ny lovgivning, EU direktiver, organisatoriske forandringer, effektivisering af eksisterende arbejdsgange m.m. Det er derfor vigtigt, at it-løsninger understøtter disse forandringer på en effektiv og fleksibel måde. Det skal være den offentlige sektors forretningskrav, der bestemmer it-udviklingen. It-løsninger må ikke være den begrænsende faktor for, hvordan den offentlige sektor skal udvikle sig. Rationalet ved en it-portefølje baseret på SOA viser sig tydeligt med behovet for at kunne reagere hurtigt og fleksibelt i forhold til forandringer. En af målsætningerne med SOA er netop, at it-løsninger designes til forandring og videreudvikling, så ændringer i omverdenen får mindst mulige konsekvenser for it-løsningernes grundlæggende strukturer og sammenhænge. 22

22 < Sammenhæng og genbrug Det er en målsætning, at it-løsninger indrettes, således de kan arbejde sammen på tværs af myndigheder, systemskel og teknologiske platforme under anvendelse af konsistente informationer og funktionalitet. Den samme forespørgsel skal anvende samme forretningsregler og give samme resultat, uanset hvor og hvordan forespørgslen er foretaget. Dermed minimeres de forretningsmæssige risici, der kan være forbundet med uens behandling af den samme forespørgsel i forskellige it-løsninger. For at imødekomme denne målsætning er det nødvendigt, at de enkelte myndigheder i det offentlige betragter data som fællesoffentlige frem for den enkelte myndigheds ejendom. Et af målene med SOA er derfor, at forretningslogik kun udvikles én gang, og at data kun afgives og registreres én gang og ét sted. Bedre udnyttelse af eksisterende systemportefølje Inden for det offentlige er der mange ældre it-systemer, som ikke uden videre kan udskiftes, men som nye løsninger i en lang periode fremover skal kunne arbejde sammen med. En målsætning for SOA i det offentlige er derfor, at få disse forskelligartede løsninger til at kunne samarbejde ved eksempelvis at stille funktionalitet i eksisterende itløsninger til rådighed som services. SOA skal gøre det muligt, at få de eksisterende itsystemer, som ofte befinder sig i isolerede miljøer, til at samarbejde og kommunikere på tværs baseret på generelt anvendelige og standardiserede integrationsmekanismer 23

23 > frem for enkeltstående punkt-til-punkt integrationsløsninger. Omkostningerne til at integrere de eksisterende it-systemer med nye løsninger bliver dermed mindre, og behovet for at skulle udskifte de eksisterende it-løsninger her og nu mindskes. 2.4 Hvor går grænserne for SOA i den offentlige sektor? SOA er en arkitekturmæssig stilart, der kan anvendes til at understøtte mange forskellige forretningsprocesser i mange forskelligartede it-løsninger, men der findes også scenarier hvor SOA er knap så velegnet. Arkitekturmæssige barrierer i eksisterende systemer En del eksisterende it-løsninger er bygget med arkitekturmæssige strukturer og bindinger, der er vanskelige at tilpasse til SOA uden at skulle udvikle systemerne om fra grunden. Som udgangspunkt vil disse systemer derfor ikke være i målgruppen for SOA. Kun hvis der er behov for interoperabilitet hos tredjepart, bør implementering af en serviceorienteret arkitektur overvejes. Løsninger med kort levetid og begrænset udbredelse It-løsninger med begrænset udbredelse og/eller kort levetid vil ofte være urentable at tilpasse til SOA. Årsagen er dels, at behovet for at skulle genbruge disse itløsningers funktionalitet sandsynligvis ikke er særlig stor, dels at sandsynligheden for at der skal gennemføres store ændringer er lille. Leverandørvalg På visse områder kan der være et ønske om eller behov for at anvende en bestemt leverandør. Hvis den pågældende 24

24 < leverandør ikke kan efterleve principperne for SOA, må man i det konkrete tilfælde vægte leverandørvalget op mod den overordnede strategi for implementering af SOA. 2.5 Indførelse af SOA i den offentlige sektor Ikke kun en teknisk disciplin Indførelse af SOA i den offentlige sektor er ikke kun en teknisk disciplin. Det er et skift til en arkitekturmæssig stilart, der har indflydelse på styring, organisering, leverandørsamarbejde, kultur m.m. Det er et forandringsprojekt, som kræver mange kræfter, tid og ressourcer at gennemføre. For at det bliver en succes, er det vigtigt, at den enkelte myndighed sikres de rette incitamenter til at fortsætte arbejdet med udbredelsen af digital forvaltning understøttet af SOA. Det der driver denne udvikling, er ikke kun centrale diktater og lovgivning. Den altovervejende del af borgerservicen foregår lokalt lokalt på rådhuset, i institutionen m.m. Det er ofte her borgeren møder det offentlige. Det er derfor med dette udgangspunkt, at mange af de nye, gode løsninger baseret på SOA skabes. Det er i høj grad her, man har behovet for, at systemer kan tale sammen, og data kan udveksles på tværs af sektorer. Det er her, man skaber grundlaget for at kunne udvikle løsninger med udgangspunkt i borgernes og virksomhedernes behov. 25

25 > En af forudsætningerne herfor er, at der fastlægges fællesoffentlige standarder omkring SOA. Det omfatter: > Processtandarder standarder der beskriver de overordnede processer og aktiviteter, der skal være i henhold til lovgivning og minimal praksis i en sagsbehandling og arbejdsgang. > Datastandarder standarder for hvilke informationer (begreber) der udveksles i de forskellige sagsgange og mellem services. > Tekniske standarder standarder for hvorledes itsystemerne bygges, således at de er nemme at samle og adskille. Standardiseringen skal sikres gennem et samarbejde, hvor interessenterne i den offentlige sektor i fællesskab bliver enige om mål og rammer. Mål som det efterfølgende er vigtigt, at ledelsen i den offentlige sektor engagerer sig i at få gennemført. Udgangspunktet er forretningens processer og begreber Viden om relationerne mellem forretning og it er en forudsætning for en effektfuld SOA. Uden en veldokumenteret viden om forretningsprocesser er det umuligt at implementere optimalt understøttende it. Fokus skal rettes mod at kortlægge og forstå forretningens processer frem for først at fokusere på it-systemer. En fælles opfattelse af processer og begreber giver bedre mulighed for at udvikle en sammenhængende it- 26

26 < understøttelse, hvor information kun registreres én gang og genanvendes i mange forskellige sammenhænge. Dette betyder, at den enkelte myndighed skal fokusere på at udarbejde modeller over processer og begreber som en del af systemudviklingsprocessen. Således kan modellerne blive et aktivt redskab, når nye services realiseres, nye itløsninger udvikles eller eksisterende ændres. Processer og begreber skal beskrives på et så detaljeret niveau, at de kan bruges til at fastlægge krav til de enkelte services. Dette skal ske på en måde, så de myndigheder der er involveret i forretningsprocessen, eller anvender de pågældende begreber, opnår en fælles forståelse og enighed om disse. Det kræver selvsagt stor indsigt i arbejdsgange og af og til vil det også kræve både vilje og beslutningskompetence at justere de eksisterende forretningsprocesser, da disse ofte udfordres eller påvirkes i processen. Arbejdet ligger derfor naturligt hos de myndigheder, der ejer forretningsprocessen og de tilhørende begreber. Behov for en sammenhængende arkitektur Det er vigtigt, at de overordnede principper og retningslinier for SOA i den offentlige sektor følges også lokalt. Afvigelser herfra bør være synlige og veldokumenterede. En sammenhængende arkitektur og fælles løsninger på tværs af den offentlige sektor er ikke i konflikt med behovet for lokale løsninger og fleksibilitet. Når blot de centrale løsninger koordineres via en sammenhængende arkitekturstyring og udvikles som services under hensyntagen til SOA principperne og øvrige retningslinier, 27

27 > kan man på enkel vis sammensætte individuelle løsninger lokalt. Et vigtigt element ved indførelse af SOA i den offentlige sektor er, at den enkelte myndighed ser løsningerne i et koncernperspektiv frem for at suboptimere løsningerne til den enkelte myndigheds specifikke behov. Ved en SOA løsning er business casen for den enkelte myndighed ikke altid specielt god, men det kan den være for den offentlige sektor som helhed. Den enkelte myndighed skal derfor se på den samlede business case. I modsat fald kan det resultere i lokale, kortsigtede løsninger, der ikke understøtter visionen om en sammenhængende itunderstøttelse i den offentlige sektor. Derfor bør myndigheden sikre sig bedst muligt både i forhold til fremtidige behov for samspil med andre og i muligheden for at kunne skifte system med færrest mulige omkostninger. Services skal være synlige og veldokumenteret Når det offentlige opbygger sin it-arkitektur som en SOA, vil det forbedre mulighederne for interoperabilitet betydeligt. Men for at kunne fungere effektivt i praksis, er det vigtigt, at de forskellige services, som den enkelte myndighed udstiller, er både synlige og veldokumenterede. Andre myndigheder skal have mulighed for dels at finde disse services, dels at vurdere om den udstillede funktionalitet svarer til det aktuelle behov. Spørgsmålet er derfor, hvordan man effektivt udstiller de services, man selv udbyder, og hvordan man finder de relevante services, andre tilbyder? 28

28 < Et muligt svar på det spørgsmål er etablering af et centralt servicekatalog på tværs af de enkelte myndigheder, som indeholder specifikationen af de services, som de enkelte myndigheder tilbyder. Det er en opgave, som bør supporteres centralt, men som i det daglige skal forvaltes lokalt af de enkelte myndigheder. Behov for styring og koordinering SOA består som tidligere nævnt af både af SOA-processen og af SOA-produktet: Retningslinier og resultatet af de fulgte retningslinier som i praksis vil være implementeret SOA. Begge bestanddele er meget vigtige. Opbygningen af en sammenhængende SOA ud fra enkeltstående og ukoordinerede projekter har ikke store chancer for succes. Store distribuerede og integrerede it-løsninger bør bygges på en gennemarbejdet og velkoordineret arkitektur. Det drejer sig om styring og prioritering af it-indsatsen. På den ene side skal den den offentlige sektor sikre en effektiv udnyttelse af it-ressourcer på tværs af de enkelte myndigheder. Projekter med ansvar for fælles mål skal sikre udvikling af fælles services på tværs af de enkelte myndigheder. På den anden side skal styringen give plads til, at der lokalt i den enkelte myndighed kan udvikles individuelle løsninger baseret på de fælles services til opfyldelse af specifikke myndighedsmål. Styringen vil derfor skulle foregå på både statsligt, regionalt og kommunalt niveau med en koordinering på tværs af disse niveauer. Inden for hvert niveau vil der desuden være behov for koordinering på tværs af myndighederne. 29

29 > Både EA og SOA sammenlignes ofte med byplanlægning, hvor en central funktion styrer politikker i relation til fælles services (veje, kloaker, bolig- og industriområder m.m.). Herfra defineres de overordnede retningslinier. Man er herfra interesseret i, hvordan en bygning passer ind i helheden, og at denne etableres med brug af de fælles services. Derimod er man ikke interesseret i arkitekturen af den enkelte bygning. Det overlades til de lokale myndigheder og bygherren. På tilsvarende vis er der inden for SOA behov for både en central og en lokal funktion. Den centrale enhed skal udstikke de overordnede rammer og retningslinier, således at de forskellige løsninger i de enkelte myndigheder kan fungere i en sammenhængende SOA. Den daglige forvaltning bør derimod ske ved selvforvaltning i de enkelte myndigheder. Det er her anvendelsen af SOA-principper bør sikres i det daglige. Det er også her eventuelle afvigelser og undtagelser begrundes og dokumenteres. SOA skal på sigt udstrækkes til at dække størstedelen af de informationer, der udveksles mellem offentlige myndigheder, borgere og virksomheder. De fremtidige offentlige it-løsninger bør derfor udformes, så services der giver adgang til data prioriteres højt. 30

30 < For at sikre dette på en effektiv måde, bør hver enkelt offentlig myndighed udarbejde en strategi og en konkret plan for, hvorledes myndighedens it-løsninger tilrettes SOA. Dette kræver stillingtagen til en række spørgsmål, eksempelvis: > Hvilke forretningsprocesser og forretningsbegreber hører under myndighedens ansvarsområde? > Hvilke it-systemer har brug for at anvende eksterne services? > Hvilke it-systemer har brug for at stille informationer til rådighed for tredje part? > Hvilke servicekrav skal stilles til nye it-løsninger? > Hvordan og hvornår skal eksisterende it-systemer omlægges hhv. indpakkes som services? > Hvordan sikres det, at nye it-løsninger udvikles og implementeres efter SOA principperne? Den serviceorienterede arkitektur med tilhørende løsninger skal anvendes af de enkelte myndigheder, hvis den offentlige sektor som helhed skal realisere gevinsterne ved SOA. De eksisterende løsninger En af udfordringerne med it i det offentlige er, hvorledes man får alle den offentlige sektors it-systemer til at tale samme sprog, således at alle relevante data og processer er konsistente og tilgængelige for offentligt ansatte, borgere og virksomheder. Inden for det offentlige er der 31

31 > foretaget store investeringer i forskellige løsninger. Investeringer som gør, at man ikke blot kan smide de gamle løsninger ud og starte forfra. Det er derfor nødvendigt med løsninger, der bygger på de eksisterende forskelligartede løsninger og får dem til at samarbejde på en fleksibel måde. SOA er netop kendetegnet ved at kunne binde eksisterende og nye løsninger sammen sådan, at services på en enkel måde kan tilgås fra en anden service eller løsning efter behov. En af de største barrierer i relation til SOA er netop, at de forskellige it-løsninger ikke oprindelig blev designet til hverken at benytte sig af eksterne services eller at give adgang for andre til egne data. En ændring i en eksisterende it-løsning vil normalt medføre omkostninger for den pågældende myndighed. Ændringen bør derfor kun blive implementeret ved et konkret behov, eller hvis der er meget store samfundsmæssige eller offentlige gevinster herved. I den forbindelse bør den enkelte myndighed være opmærksom på mulighederne, når der er andre behov for at ændre eksisterende it-systemer eller ved et genudbud af en kontrakt om drift af et eksisterende system. Med andre ord så skal en omlægning af et eksisterende itsystem til SOA ikke gennemføres uden omtanke blot for at overholde nogle udstukne arkitekturprincipper. Der skal være en positiv business case forbundet med en given omlægning, enten lokalt eller for den offentlige sektor som helhed. 32

32 < Den offentlige sektor skal selv gå forrest Den offentlige sektor bør gå forrest ved at arbejde og kommunikere digitalt både internt og i forhold til borgere og virksomheder. Der bør arbejdes målrettet i henhold til principperne for SOA. Krav til løsninger og underleverandører skal derfor baseres på principperne for SOA. Den offentlige sektor skal gå forrest både som kravstiller og som anvender. I den forbindelse er det vigtigt, at ledelsen i den offentlige sektor engagerer sig i arbejdet med at føre principperne for SOA ud i livet. Ledelsen i den offentlige sektor har en stor opgave i at motivere og sætte mål for de ønskede resultater ved gennemførslen af SOA. 33

33 > 2.6 IT- og Telestyrelsens anbefalinger IT- og Telestyrelsen anbefaler: > At det offentlige som helhed og den enkelte myndighed opstiller en handlingsplan for, hvorledes indførelsen af SOA styres, hvordan fremdrift og kvalitet måles, og hvordan de enkelte services fastlægges. > At de enkelte myndigheder via sektorstandardiseringsudvalgene indgår i procesarbejdet på fagområder, således at der sikres en fælles beskrivelse af de overordnede processer og aktiviteter, der skal være i henhold til lovgivning og minimal praksis i en sagsbehandling og arbejdsgang. > At de enkelte myndigheder via sektorstandardiseringsudvalgene indgår i begrebsarbejdet på fagområder, således at der sikres et fælles forvaltningssprog. Der skal her fastlægges standarder for hvilke informationer (begreber), der udveksles i de forskellige sagsgange og mellem services. > At den enkelte myndighed anvender de standarder, der udformes i fællesoffentligt regi, herunder indarbejder krav om overholdelse af OIO-standarder i aftaler med leverandører. > At krav om en serviceorienteret arkitektur og interoperabilitet med andre systemer indføres som en del af kravspecifikationen i forbindelse med nye udbud. Der skal stilles krav til de enkelte projekter om, at de skal udvikle og styre efter SOA principperne. > At systemomlægning og standardisering til SOA fokuseres på de områder, hvor der skal gennemføres større projekter, og hvor it-løsningerne derfor i forvejen skal omlægges. 34

34 < 2.7 Afrunding Når det offentlige opbygger sin it-arkitektur som en serviceorienteret arkitektur, vil det forbedre mulighederne for et sammenhængende udbud af serviceydelser, hvor løsningerne tager udgangspunkt i borgerens og virksomhedens behov. En af forudsætningerne for en effektfuld SOA er en viden om relationerne mellem forretning og it. Uden en veldokumenteret viden om forretningsprocesser og forretningsbegreber er det vanskeligt at implementere en optimal og sammenhængende it-understøttelse. Det er derfor vigtigt, at de enkelte myndigheder fokuserer på at skabe overblik og indsigt i forretningsprocesser og begreber, således at denne viden kan blive et aktivt styringsredskab, når nye it-løsninger udvikles eller eksisterende ændres. Pjecens anden del beskriver SOA ud fra en mere teknisk synsvinkel. 35

35 Del 2 - SOA en mere detaljeret gennemgang > I denne del af pjecen gennemgås elementerne i SOA i flere detaljer og ud fra en mere teknisk synsvinkel. Herunder beskrives generelle principper for SOA, SOA som en lagdelt arkitektur og det tekniske fundament for SOA. Endelig introduceres SOA udviklingsprocessen og SOAs relationer til Objekt Orienteret (OO) og komponentbaseret udvikling (CBD) 3. 3 CBD er en forkortelse for det engelske udtryk Component Based Development. 36

36 < 3.1 Generelle SOA principper SOA er som bekendt en serviceorienteret arkitektur, men hvad betyder det så? Ud fra beskrivelsen af SOA som en arkitekturmæssig stilart hvor it-løsninger kan organiseres, udvikles, anskaffes og anvendes som forretningsunderstøttende, genbrugelige og fleksible services, fremgår det, at services er et centralt begreb. SOA bygger grundlæggende på det simple forhold, at der findes en serviceleverandør, som udstiller en formåen eller evne til at udføre en veldefineret og afgrænset aktivitet, en service, og at der på den anden side findes en serviceanvender, som efterspørger denne service. Servicen er beskrevet af en servicekontrakt, som også benævnes som en servicespecifikation eller en servicebeskrivelse. Figur 3: Serviceanvender, serviceudbyder og servicekontrakt. 37

37 > Dette enkle og klare koncept understøttes og udbygges af en række principper, som tilsammen definerer og styrer udviklingen af SOA. Principperne udtrykker så at sige ånden i SOA. De generelle principper som gennemgås efterfølgende er: > Forretningsrelaterede services > Genbrugelige services > Kontraktbaserede services > Løst koblede services > Platformsuafhængig anvendelse af services > Lokationsuafhængig anvendelse af services > Sammensætning af services > Services er en abstraktion over forretningsfunktionalitet og information > Services versioneres > Services registreres og er synlige > SOA er baseret på standarder En del af de beskrevne principper overlapper hinanden, ligesom der er sammenhæng mellem mange af principperne. Principperne skal dermed ses som sammenhængende, og kan ikke umiddelbart anvendes enkeltvis som milepæle for indførsel af SOA eller ved vurdering af SOA modenhed. 38

38 < Forretningsrelaterede services Services understøtter forretningens processer. Efterlevelse af dette princip vil bidrage til, at SOA bliver et redskab, der sikrer, at forretningen og it går i takt og arbejder efter de samme mål de forretningsmæssige mål. Forståelse og modellering af forretningsprocesser og forretningsbegreber bliver centrale aktiviteter i forbindelse med identificering, afgræsning, fremstilling og ikke mindst brug af services. En bedre forståelse af forretningens processer og den direkte afspejling af disse i services, kan være medvirkende til at give en hurtigere reaktionstid, når der sker ændringer i forretningen. Figur 4: Forretningsrelaterede services. Det skal bemærkes, at services også kan være af teknisk karakter. Tekniske services vil typisk understøtte den tekniske infrastruktur, eksempelvis print, arkivering, sikkerhed, netværk, osv. Genbrugelige services Services designes med genbrug for øje også selv om en service ikke umiddelbart skal genbruges. Dette betyder ikke, at services skal forberedes til alle tænkelige fremtidige anvendelsesmuligheder hvilket jo selvsagt er 39

39 > umuligt. Det betyder derimod, at services bør udarbejdes med anvendelse af generelt accepterede arkitekturprincipper omkring generalisering og genbrug. Ved efterlevelse af dette princip kan man med en relativ lille indsats forberede eventuel senere genbrug. Andre SOA principper - eksempelvis løst koblede services og services registreres og er synlige - er i sig selv elementer, der fremmer muligheden for genbrug. Genbrug er selvsagt en kilde til forbedring af produktivitet. Services med et højt genbrugspotentiale er som udgangspunkt mere værdifulde end services, hvor der forventes at være en lav grad af genbrug. Kontraktbaserede services Services beskrives af en kontrakt og serviceanvendelse sker på grundlag af kontrakten. Servicekontrakten er en præcis beskrivelse af servicens interface, der indeholder en beskrivelse af dels den information, servicen har ansvaret for og manipulerer med, dels den adfærd servicen har. Servicekontrakten beskriver også de servicekvaliteter, som serviceleverandøren skal leve op til, og dermed også hvilke kvaliteter en serviceanvender kan forvente. Alle aktører er dermed bekendt med deres præcise forpligtigelser, når en service leveres eller anvendes. Dette princip kan således være medvirkende til at forbedre kvaliteten i it-løsningerne, da risikoen for fejl og misforståelser bliver reduceret. Endelig indeholder servicekontrakten også en specificering af, hvordan servicen fysisk skal findes og 40

40 < anvendes, samt eventuelle andre infrastrukturmæssige krav. I praksis stiller dette relativt store krav til beskrivelse, vedligeholdelse og versionering af servicekontrakten. Løst koblede services Services i SOA er løst koblede og kan findes og anvendes under etablering af et minimum af afhængigheder mellem anvender og leverandør af en service. Servicekontrakten er den eneste fælles reference, anvender og leverandør har. Da anvenderen af en service ikke har kendskab til, hvordan servicen er implementeret, vil efterlevelse af dette princip derfor være et væsentligt middel til at sikre en høj grad af løs kobling mellem serviceanvendelsen og serviceimplementeringen. En af de væsentligste fordele ved løst koblede services er, at det giver mulighed for at ændre i serviceimplementeringen, uden at det påvirker serviceanvenderne dog under forudsætning af at servicekontrakten overholdes. Løst koblede services giver også mulighed for at udskifte en services med en anden - igen under forudsætning af at servicekontrakten overholdes. Dette giver mulighed for at ibrugtage en service, der tilbyder andre og måske bedre kvaliteter, uden at det påvirker anvendelsen af servicen. Platformsuafhængig anvendelse af services Anvendelse af en service bør foregå uafhængigt af den platform, servicen er implementeret på. En platform er i denne sammenhæng en kombination af programmeringssprog, operativsystem, kommunikationsprotokoller m.m. 41

41 > Platformsuafhængig anvendelse af services giver mulighed for at integrere forskellige systemer implementeret på forskellige platforme. For at opnå en platformsuafhængig anvendelse af en service, er det nødvendigt at beskrive servicekontrakten i et platformsuafhængigt format, eksempelvis WSDL 4, ligesom det er nødvendigt at anvende platformsuafhængige kommunikationsprotokoller, eksempelvis SOAP 5. Det er i denne sammenhæng væsentligt at understrege, at platformsuafhængig anvendelse af services ikke er ensbetydende med platformsuafhængige services. For at opnå platformsuafhængige services, stilles der yderligere krav til, at selve serviceimplementeringen er platformsuafhængig, så den frit kan flyttes fra platform til platform. Lokationsuafhængig anvendelse af services Anvendelse af en service kan foregå uafhængigt af den fysiske lokation, servicen er implementeret på. Anvenderen behøver ikke at kende den lokation hvorfra den enkelte service afvikles. Anvendelse af lokationsuafhængige services giver en række driftmæssige fordele i form af fleksibilitet og mulighed for at optimere driftsafviklingen. Det giver, sammen med efterlevelsen af en række øvrige serviceprincipper, også mulighed for at vælge den 4 WSDL (Web Service Description Language), er et XML-baseret sprog beregnet til at beskrive de forskellige karakteristika, en webservice besidder. 5 SOAP (Simple Object Access Protocol), er en XML-protokol til udveksling af data. 42

42 < konkrete forekomst af en service på afviklingstidspunktet. Lokationsuafhængig anvendelse af services kræver, at en service kaldes indirekte via sit navn eller anden form for logisk identitet, og at den fysiske lokation først bestemmes på afviklingstidspunktet. Det kræver også, at implementeringen af servicen ikke på anden vis er bundet til en bestemt fysisk lokation. Sammensætning af services Services kan sammensættes af andre services, hvilket muliggør en lagdeling af services, hvor generelle standardiserede services i de nederste lag gradvist sammensættes af services i de øvre lag. Sammensætning af services giver stor fleksibilitet og mulighed for nye måder at it-understøtte forretningen på. Sammensætning af services baserer sig på genbrug af allerede eksisterende services og kan således bidrage til højere produktivitet. Figur 5: Sammensætning af services. I eksemplet er Service A sammensat af Service B og Service C, udover at Service A har en egen serviceimplementering. 43

43 > Services er en abstraktion over forretningsfunktionalitet og information Services er en abstraktion over forretningsfunktionalitet og information, der stilles til rådighed for serviceanvendere via en offentliggjort servicekontrakt. Servicens funktionalitet er kun kendt og tilgængelig via det interface, den tilbyder. Servicen udgør dermed et abstraktionslag, der skjuler alle de komplicerede underliggende implementeringsdetaljer. Specifikationen af en service bliver hermed adskilt fra implementeringen, hvilket gør det muligt at ændre i implementeringen, uden at det påvirker anvendere af servicen - blot servicekontrakten ikke ændres. Figur 6: Specifikation af en service er adskilt fra implementeringen. Specifikationen er servicens eksterne repræsentation, der realiseres i serviceimplementationen. Da serviceimplementationen kan være realiseret med væsentlig flere detaljer og anden struktur end specifikationen, vil det ofte være nødvendigt med en transformation mellem specifikation og implementering. 44

44 < Adskillelse af specifikation og implementering giver serviceleverandøren væsentlig større frihed til at vedligeholde serviceimplementeringen uden at skulle inddrage og påvirke mulige anvendere af servicen. Det kan samtidig være medvirkende til at give højere kvalitet, idet risikoen for utilsigtede sideeffekter bliver minimeret, da alle anvendere af en service bruger den samme offentliggjorte indgang til servicen. Services versioneres Da en serviceleverandør ikke nødvendigvis har kendskab til alle serviceanvendere, er det i forbindelse med igangsætning af ændringer nødvendigt at versionere services. Services skal kunne udvikle sig over tid uden at tvinge serviceanvenderen ind i omfattende og kostbare opgraderinger. Flere versioner af den samme service kan eksistere på samme tid. Nye versioner af en service kan gradvist ibrugtages af forskellige serviceanvendere, efterhånden som der bliver brug for den ændrede funktionalitet. Der kan naturligvis være lovmæssige krav, der medfører at alle serviceanvendere skal skifte serviceversion samtidig, og før eller siden skal alle anvendere givetvis under alle omstændigheder skifte til nyeste version, men versioneringen er medvirkende til, at dette kan ske fleksibelt i forhold til den enkelte anvender. Versionering af services giver væsentlig bedre muligheder for fleksibel og effektiv videreudvikling, men stiller samtidig krav til infrastrukturen, der skal afvikle den serviceorienterede løsning, ligesom der stilles krav til implementeringen af de enkelte services. 45