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

45 > Services registreres og er synlige For at gøre det nemmere at finde og anvende de rette services, skal serviceleverandøren registrere og publicere disse i et servicekatalog. Her kan serviceanvendere finde de enkelte services, de skal bruge, og hente den information, der er nødvendig for at kunne anvende disse. Figur 7: Serviceleverandør, serviceanvender og servicekatalog. For at synliggøre services på en standardiseret måde, er det nødvendigt at stille krav til den information, der skal publiceres og til de mekanismer, der anvendes til publicering. SOA er baseret på standarder Services baseres på anvendelse af fælles begrebsdannelse og standarder fastlagt af den offentlige sektor 6. Standarder omfatter både tekniske standarder, der gør det muligt at fremstille, publicere, finde og anvende services på tværs af programmeringssprog og driftsplatforme, men også 6 Se OIO-kataloget på for en oversigt over anbefalede standarder. 46

46 < forretningsmæssige standarder som eksempelvis standardiserede domænemodeller og referencemodeller. Anvendelse af standarder, både tekniske og forretningsmæssige, er afgørende for interoperabilitet og integration. Standarder kan være gældende lokalt for den enkelte offentlige myndighed, for en sektor eller på nationalt eller internationalt plan og det er vigtigt, at anvendelse og udarbejdelse af standarder foregår på det relevante niveau. Selvom et fælles begrebsapparat er afgørende for interoperabilitet og integration, er det svært at forestille sig, at der kan etableres en fælles begrebsmodel for alle offentlige myndigheder. Det må forventes, at der vil blive etableret en række begrebsmodeller med hver sine variationer i definitioner af begreber. SOA infrastrukturen skal derfor indeholde faciliteter til transformering og mapning af begreber imellem de forskellige variationer af samme begreber for at kunne opnå den ønskede interoperabilitet. 3.2 SOA set i forskellige perspektiver Ligesom i traditionel bygningsarkitektur kan det være formålstjenstligt, at se på SOA fra forskellige synsvinkler, som hver især stiller skarpt på forskellige aspekter af arkitekturen. Anvendelse af arkitekturperspektiver er et effektivt middel til at fremme kommunikation og forståelse af forskellige aspekter i arkitekturen. Det enkelte perspektiv reducerer kompleksiteten ved at nedtone og fravælge emner, der ikke er væsentlige og fremhæve og fokusere på aspekter, der er væsentlige for det valgte perspektiv. 47

47 > Dette svarer til, at man ved bygning af et hus ikke kun udarbejder en enkelt tegning, men et helt sæt af tegninger, der hver især fremhæver forskellige aspekter i bygningskonstruktionen. Der udarbejdes en tegning, der viser hvordan fundamentet skal støbes, og hvordan el, vand og varme skal tilsluttes. Elektrikeren har en tegning, som viser nøjagtigt, hvor de enkelte elektriske installationer skal være - helt ned til placeringen af den enkelte stikkontakt. Der udarbejdes en tegning, der viser ruminddeling og andre anvendelsesmæssige aspekter, som er interessante for brugeren af bygningen osv. Hvis alle disse oplysninger skal placeres på en og samme tegning, er det indlysende, at kompleksiteten vil blive meget stor og dermed gøre det særdeles vanskeligt for de forskellige aktører at gennemskue arkitekturen. I SOA er der følgende væsentlige perspektiver, der sætter fokus på bestemte aspekter i arkitekturen: > Forretning > Services > Applikationer > Teknologi Andre aspekter kan også være væsentlige og kan derfor være repræsenteret i et selvstændigt perspektiv. Sikkerhed er eksempelvis mere eller mindre en del af alle perspektiverne i ovennævnte liste, men kunne meget vel være defineret som et selvstændigt perspektiv. Forretningsperspektivet Når SOA ses ud fra dette perspektiv, er det forretningens målsætninger med SOA, forretningsprocesser og den 48

48 < information processerne anvender og manipulerer, som er i fokus. Der stilles i dette perspektiv skarpt på, hvordan processer gennemføres effektivt, hvordan eksisterende processer kan optimeres, hvordan nye processer kan udvikles og eventuelt sammensættes ud fra eksisterende osv. Forretningens processer beskrives af proces- og informationsmodeller. Disse danner grundlaget for at identificere de rigtige services og dermed automatiseringen af forretningens processer. Serviceperspektivet Serviceperspektivet stiller skarpt på, hvordan services på bedst mulig vis kan repræsentere forretningens processer uafhængig af den underliggende teknologi, og på hvordan disse services kan udstilles, findes og anvendes. Applikationsperspektivet Applikationsperspektivet har fokus på, hvordan services kombineres, sammensættes og forbindes med forskellige former for system- og brugergrænseflader til færdige løsninger. Der vil i dette perspektiv være mulighed for at få besvaret spørgsmål om, hvordan det eksempelvis er muligt at kombinere funktionalitet fra standard softwarepakker med egenudviklede services, og hvordan disse sammensatte services kan præsenteres med et ensartet ydre for brugeren. Teknologiperspektivet Teknologiperspektivet har fokus på den teknologi SOA bygger på. Der stilles her skarpt på hvilke driftsplatforme, kommunikationsprotokoller, sprog osv. løsningerne bygges på. 49

49 > 3.3 SOA som en lagdelt arkitektur SOA perspektiverne er, som beskrevet, en mekanisme til at fremhæve forskellige aspekter af arkitekturen for at fremme forståelse og kommunikation. Lagdeling er en anden teknik, der ofte anvendes i beskrivelse af arkitekturen i it-løsninger. Lagdelingen af arkitekturen giver en organisering af arkitekturen, som gør det overskueligt at forstå, kommunikere og placere ansvar for forskellige aspekter i arkitekturen. Lagdeling har med andre ord fokus på organisering og placering af ansvar for forskellige aspekter i arkitekturen. Ligesom der findes mange definitioner af SOA, er der forskellige måder at anskue lagdelingen af SOA på. De væsentligste lag i SOA er illustreret i figur 8. Figur 8: SOA lagdeling. 50

50 < Præsentationslaget Præsentationslaget har ansvar for håndtering af alle aspekter omkring præsentation af en given it-løsning over for brugeren og har således ansvaret for, at præsentation og registrering af informationer sker på den mest hensigtsmæssige måde. Præsentationslaget er bindeleddet mellem it-løsningerne, brugere og de underliggende forretningsregler og forretningsprocesser. Præsentationslaget udstiller således forretningslogik og forretningsprocesser ved at anvende services fra serviceorkestrerings- og workflowlaget eller services direkte fra servicelaget. Præsentationslaget fastlægger, hvordan brugergrænseflader skal udvikles, anvendes og fremstå visuelt. Præsentationslaget fastlægger også, hvordan brugergrænseflader eventuelt kan udvikles som selvstændige portalelementer, og hvordan disse portalelementer kan sammensættes, udveksle information og konfigureres til større sammenhængende portalbrugergrænseflader. Serviceorkestrerings- og workflowlaget Orkestrering og workflow er to begreber, der i forbindelse med SOA ofte anvendes i flæng. De dækker bredt over det koncept, at services kan sammensættes, så de understøtter arbejdsgange og forretningsprocesser, der enten gennemføres her og nu eller strækker sig over en længere tidsmæssig periode, involverer forskellige aktører og forskellige it-systemer. En orkestrering er en beskrivelse af, hvorledes enkeltstående services sammensættes til en større helhed 51

51 > og automatiserer enten helt eller delvist gennemførslen af en forretningsproces. En orkestrering beskriver 7, hvilken sekvens de involverede services kaldes i, og hvilke informationer der udveksles mellem de involverede services. Et workflow defineres i denne sammenhæng som en orkestrering, der udover beskrivelsen af hvilke services der indgår i workflowet også omhandler de aspekter, der er forbundet med den menneskelige interaktion med systemet, tilknytning af de rigtige aktører til en given aktivitet, sikring af at aktiviteter gennemføres inden for de givne tidsrammer og ikke mindst aspekter forbundet med at aktivere og forbinde forskelligartede it-løsningers brugergrænseflader, således at brugerens arbejdsgang fremstår sammenhængende og integreret. Ved at isolere aspekter angående orkestrering og workflow i et selvstændigt lag, bliver det muligt at genbruge orkestreringer og workflow på tværs af løsninger, ligesom vedligeholdelse af regler og opsætning af flow og udveksling af information mellem services kan foretages centralt. 7 En orkestrering beskrives ofte i BPEL (Business Process Execution Language). Se evt. 52

52 < Servicelaget Servicelaget er det lag, der har ansvar for, at services kan udstilles, fremfindes og anvendes. Servicelaget indeholder derfor den nødvendige infrastruktur, der gør det muligt at: > Beskrive, organisere og publicere services i et servicekatalog > Forbinde en serviceanvender med en given service via tilgængelige kommunikationsmekanismer > Foretage eventuelle transformeringer af dataformater og datastrukturer > Dirigere serviceforespørgsler til forskellige fysiske servicelokationer. Servicelaget kan illustreres som vist i figur 9. Figur 9: Servicelaget har ansvaret for at services kan udstilles, fremfindes og anvendes. 53

53 > Servicelaget kan med fordel inddele og gruppere services i forretningsmæssige funktionelle domæner, som giver en mekanisme til at katalogisere services i servicekataloget og dermed gøre det nemmere at fremfinde services inden for et givent forretningsområde. Endvidere kan opdelingen i funktionelle domæner anvendes til at samle aspekter, der er fælles for alle services, typisk politikker, procedurer og regler, i et givent domæne frem for at specificere disse på den individuelle service. Services i servicelaget kan endvidere kategoriseres i forskellige servicetyper, eksempelvis applikationsservices, tekniske services og forretningsservices. Den samlede infrastruktur i servicelaget bliver ofte benævnt som en Enterprise Service Bus (ESB) og indeholder hele den tekniske infrastruktur, som services i servicelaget anvender. Eksempler på infrastrukturservicekategorier er: > Routning services der eksempelvis finder den fysiske placering af en given service og giver mulighed for omdirigering af serviceforespørgsler. > Transformation services der foretager transformation af data og meddelelsesformater. > Sikkerhed services der stiller sikkerhedsfunktionalitet som eksempelvis autentificering og autorisation til rådighed. > Orkestrering og workflow services der stiller den grundlæggende orkestrerings- og workflowfunktionalitet til rådighed, eksempelvis i form af en BPEL- eller workflowmotor. 54

54 < > Systemmanagement services der stiller funktionalitet til eksempelvis overvågning, fejlhåndtering og logning til rådighed. > Messaging services der stiller funktionalitet til eksempelvis kø-håndtering til rådighed. Serviceimplementeringslaget Indførelse af nye arkitekturparadigmer er som oftest kendetegnet ved, at det medfører en total udskiftning af system og programporteføljen, hvilket i større virksomheder i bedste fald kun kan ske over en lang tidsmæssig udstrækning og i værste fald er helt urealistisk. SOA udmærker sig ved at være en arkitektur, hvor funktionalitet fra eksisterende systemer kan indpakkes og udstilles som services og kombineres med eksterne services. Dermed vil - og kan - overgangen til SOA ofte være gradvis. Serviceimplementeringslaget realiserer services udstillet i servicelaget som vist i figur 10. Figur 10: Serviceimplementeringslag med serviceimplementering ved hjælp af komponenter, ved udstilling af services fra eksisterende systemer eller ved eksternt realiserede services. 55

55 > Eksternt realiserede services Services kan realiseres ved at indgå en kontrakt, der giver adgang til eksisterende standard services fra eksterne serviceleverandører eller ved at få serviceleverandører til at udvikle specielt tilpassede services, som man efterfølgende kan købe sig adgang til. Anvendelse af services fra eksterne leverandører stiller krav til udarbejdelse af detaljerede Service Level Aggreements (SLA), der specificerer krav og forventninger til driftsmæssige aspekter ved anvendelse af de pågældende services. Udstilling af services fra eksisterende systemer Anvendelse og genbrug af eksisterende ressourcer er et stort ønske, eller ligefrem krav, fra langt de fleste større virksomheder og offentlige myndigheder, grundet de store omkostninger og risici forbundet med genudvikling. Eksisterende systemer vil derfor, ved starten af en SOA implementering, være en af de største kilder til potentielle services. Eksisterende systemer kan i den forbindelse være både egenudviklede systemer, eksternt udviklede systemer eller eksternt anskaffede standard softwarepakker. For at kunne udnytte funktionalitet i eksisterende systemer som services, er der to grundlæggende aktiviteter, der skal udføres. Først og fremmest er det nødvendigt at kunne identificere og afgrænse de ønskede services i det eksisterende programkompleks. For det andet skal de identificerede services beskrives og udstilles således, at de kan anvendes som services. Flere og flere standard softwarepakker leveres allerede i dag med forretningsfunktionaliteten udstillet som services på lige fod med de traditionelle brugergrænseflader. Der 56

56 < eksisterer endvidere mange værktøjer og mekanismer, som kan facilitere og automatisere processen med at indpakke og udstille funktionalitet i eksisterende systemer som services. Implementering af services vha. funktionalitet i eksisterende systemer kan dog være forbundet med visse udfordringer. Dels vil indsatsen med at indpakke funktionalitet i eksisterende systemer afhænge af det eksisterende systems beskaffenhed og vil ofte kræve en afkobling af forretningslogik fra præsentationslogikken. Dels vil den eksisterende funktionalitet i nogle tilfælde ikke afspejle den ønskede forretningsproces. Udbyttet ved indpakningen kan i sådanne tilfælde være begrænset til isolerede forretningsregler. Serviceimplementering ved hjælp af komponenter Når services skal udvikles fra grunden af, er komponentbaseret udvikling (Component Based Development CBD) en velegnet metode, der går fint i tråd med de serviceorienterede principper. Komponentbaseret udvikling hylder, ligesom serviceorientering, principperne om bl.a. kontraktbaserede interfaces, løs kobling, genbrug og adskillelse af specifikation fra implementering. Da services og komponenter har mange fælles træk, kan det ofte være vanskeligt at afgøre, hvor grænsen mellem services og komponenter går. En ofte anvendt skelnen er, at services fokuserer på understøttelse og udstilling af forretningsprocesser som services, mens komponenter er en implementeringsmekanisme, der har fokus på den bedst mulige softwaremæssige realisering af it-løsninger. Yderligere er anvendelsen af komponenter som oftest baseret på proprietære standarder. 57

57 > 3.4 Teknisk fundament Det tekniske fundament under SOA er i vid udstrækning baseret på åbne standarder. En webservice er en service, der anvender en række åbne standarder, protokoller og teknologier, og som bruger Internettet som netværksfundament. Webservice konceptet bygger på modulær opbygning, hvilket betyder, at man kan nøjes med at anvende den del, som er nødvendig i den aktuelle kontekst. Eksempelvis kan man starte med at bruge de grundlæggende elementer som UDDI 8, WSDL, SOAP og HTTP og efterhånden udbygge fundamentet med mere avancerede WS-* standarder, ligesom man kan udskifte elementer og eksempelvis erstatte anvendelsen af UDDI med et alternativt register til udstilling af services. Figur 11: Webservice standarder og teknologier. Figur 11 viser de grundlæggende standarder, protokoller og teknologier, der anvendes i forbindelse med 8 Webservices offentliggøres via UDDI (Universal Description Discovery and Integration), som er et XML-baseret register til offentliggørelse og fremfinding af webservices. 58

58 < webservices, ligesom figuren viser, hvorledes mere avancerede udvidelser gradvist kan tages i brug. En webservice konstrueres ved, at man indpakker et stykke softwarefunktionalitet og udstiller dets funktionalitet for andre it-løsninger. Webservicen gøres tilgængelig for andre ved at offentliggøre beskrivelsen i et XML-baseret WSDL-dokument. For at gøre det nemt for en mulig anvender at finde en webservice, placeres links til WSDL-beskrivelser i et UDDI register. Transport af data fra et stykke software til et andet sker via kommunikationsprotokollen SOAP som typisk bygger oven på transportprotokollen HTTP. I SOAP transporteres data som et XML-dokument. Offentliggørelse: Offentliggørelse af en webservice gøres via Universal Description Discovery and Integration (UDDI), som er et standardiseret og platformuafhængigt XML-baseret register til offentliggørelse og fremfinding af webservices. Beskrivelse: Beskrivelsen af en webservice foretages via Web Service Description Language (WSDL), som er et XML-baseret sprog beregnet til at beskrive de forskellige karakteristika, en webservice besidder. WSDL beskriver de funktioner, som en webservice understøtter, hvilke ind- og uddataparametre de forskellige funktioner anvender, hvor den kan findes (eksempelvis via en URL), og hvilke transportmekanismer man kan benytte (eksempelvis SOAP via HTTP). WSDL beskriver således en stor del af servicekontrakten. 59

59 > Udveksling af beskeder: Udveksling af data sker vha. Simple Object Access Protocol (SOAP), som er en XML-protokol for udveksling af data i et distribueret miljø. SOAP er en kommunikationsprotokol til kommunikation mellem software, der afvikles på forskellige operativsystemer, forskellige teknologier og forskellige programmeringssprog. SOAP beskriver et format til at sende beskeder og er designet til at kommunikere via Internettet. En SOAP besked kan illustrativt sammenlignes med almindelige breve, der sendes via postvæsenet. SOAP beskeden er en analog til kuverten, mens brevindholdet er beskrevet som et XML-dokument. Postvæsenet er ikke interesseret i indholdet i kuverten. Deres opgave er at bringe kuverten sikkert fra afsender til modtager. SOAP har samme opgave. SOAP er blevet en accepteret standard på markedet. Den anvendes af de fleste leverandører og er W3C s 9 anbefalede protokol til software-til-software beskedudveksling. Transport: SOAP benytter forskellige transportprotokoller primært HTTP. HTTP er en simpel transportprotokol, som stort set alle virksomheder har implementeret. Med HTTP undgår man også sikkerhedsproblematikker i relation til firewalls m.m., idet HTTP-trafik almindeligvis tillades at gå 9 W3C er en non-profit organisation som leder arbejdet med udviklingen af World Wide Web gennem udviklingen af tekniske standarder, rapporter og publikationer. 60

60 < igennem firewalls. En firewall betragter SOAP-beskeden som en simpel tekst i et XML-dokument. Webservice udvidelser WS-*: Udover de ovennævnte grundlæggende standarder, protokoller og teknologier kan webservices som nævnt beriges og udvides med en række yderligere specifikationer. Disse specifikationer går under fællesbetegnelsen WS-* specifikationerne. Disse specifikationer kan tages i brug efterhånden, som det bliver nødvendigt. De omfatter bl.a.: > Sikkerhed - WS-Security og relaterede specifikationer der bl.a. omfatter autentifikation, autorisation, signering og kryptering. > Koordinering af services WS-Coordination, WS-BPEL, WS-AtomicTransaction m.fl. der omfatter sammensætning og koordinering af services, håndtering af atomare transaktioner og håndtering af længerevarende komplekse transaktioner. > Håndtering af webservice meddelelser WS-Addressing, WS-ReliableMessaging m.fl. som bl.a. håndterer problemstillinger mht. adresseinformation på meddelelser og robust afsendelse og modtagelse af meddelelser. > Webservice politikker WS-Policy og relaterede specifikationer der omhandler beskrivelser af krav, restriktioner og præferencer gældende for en given service interaktion. > Notifikation og hændelser WS-Notification og WS- Eventing og relaterede specifikationer der introducerer muligheder for mere avancerede kommunikations teknikker mellem en serviceleverandør og en serviceanvender. 61

61 > 3.5 SOA, komponenter og objektorientering Der er en del forvirring omkring begreberne services, komponenter og objekter. Situationen er ofte den, at itudviklere mener, de arbejder objektorienteret og udvikler objekter, it-arkitekter at der er tale om komponenter, mens forretningsanalytikere snakker om services. Hvem har egentlig ret? Det har de faktisk alle sammen, for der er sammenhæng mellem services, komponenter og objekter, men samtidig også en uafhængighed mellem disse, hvilket fremgår af figur 12. Figur 12: Sammenhænge mellem Services (SOA), Komponenter (CBD) og Objekter (OO). Services kan være realiseret via komponenter, som igen kan være implementeret som objekter. Men det behøver ikke at være tilfældet, og mange gode services vil uden tvivl i mange år fremover være baseret på implementering i COBOL, PL/1 eller andre programmeringssprog. 62

62 < Services er ikke en afløser for komponentbaseret udvikling, men derimod en naturlig udvidelse en måde at udstille komponenter på. 3.6 Udviklingsproces og metode Graden af opnået fleksibilitet og genbrugelighed og dermed den værditilvækst der skabes som følge af SOA, afhænger i høj grad af SOA-retningsliniernes kvalitet. SOA bliver aldrig bedre end de retningslinier, der ligger til grund for processen. Med udviklingsprocessen omkring SOA følger itindustrien i sporene på mange andre industrier eksempelvis bilindustrien. For år tilbage var hver bilmodel en verden for sig med samling af tusindvis af unikke smådele. Dette har ændret sig radikalt de sidste år. De mange smådele er udskiftet med en række komponenter, som passer sammen baseret på fælles åbne standarder. Dermed har bilproduktionen skiftet karakter. Bilproducenten koncentrerer sig nu om det overordnede design af bilen, om at specificere de funktionelle krav til de enkelte services, samt om at sammensætte disse services (komponenter) til den færdige bilmodel. Udviklingen af de enkelte komponenter kan foregå internt, eller de kan være eksternt indkøbte. Processen omkring fremstilling af en bil er ændret radikalt. Det samme er tilfældet omkring en SOA systemudviklingsproces. Hvor det tidligere var en sammenhængende proces, der designede og udviklede hele it-løsningen, bevæger vi os med SOA over i en lagdelt udviklingsproces, hvor de enkelte lag kan udføres af forskellige aktører. Der bliver et øget fokus på design og fastlæggelse af grænseflader. Processen skifter i højere 63

63 > grad til et forløb med mange parallelle aktiviteter og dermed til et samlet set kortere kalenderforløb. Udviklingsprocessen i relation til SOA kan illustreres af 5 hovedprocesser, jf. figur 13. Figur 13: SOA udviklingsproces. Selv om figuren er illustreret som et vandfald, vil der som oftest være tale om en iterativ proces. Herudover forudsætter figuren en eller anden form for målinput, der berettiger forandringen. Forretningsforståelse: Fokus for systemudviklingsprocessen er i første omgang understøttelse af forretningsprocesser. Det har det nok altid været, men med SOA er der sat yderligere fokus på dette område. Der fokuseres på at understøtte forretningsprocessen snarere end på den egentlige udvikling af et it-system. 64

64 < Denne del af processen bør som hovedregel udføres af den offentlige myndighed. Identifikation af services: I relation til forretningsprocessen startes med en afklaring af, hvilke services der kræves for at kunne understøtte processen bedst muligt. Findes disse allerede på en måde, så de kan genbruges, er genbrug oftest det nemmeste og billigste. Det svarer til, at man i bilindustrien kigger efter eksisterende komponenter frem for at udvikle disse selv. Proces og tilhørende kvalifikationskrav har her fokus rettet mod at understøtte forretningsprocessen og undersøge internt og eksternt, om der findes relevante services til at understøtte denne. Denne del af processen bør udføres af den offentlige myndighed analogt med at bilfabrikanten designer bilen og afgør, hvilke funktionelle komponenter der skal anvendes. Specifikation af services: Findes en ønsket service ikke i forvejen, starter en proces med specifikation af kravene til denne. Der udarbejdes en servicekontrakt, som er uafhængig af platform og programmeringssprog og adskilt fra den tekniske implementering. Denne kan efterfølgende sendes i udbud til forskellige leverandører for derigennem at opnå den bedst mulige pris og kvalitet. Der er indholdsmæssigt tale om en lidt anderledes måde at udforme krav og kravspecifikationer på end i det traditionelle udbud. Kravet er her en bestemt funktionalitet uafhængig af implementering svarende til at bilindustrien efterspørger en ny komponent med en given funktionalitet. Proces og tilhørende kvalifikationskrav har her fokus rettet mod specifikation af krav til den enkelte service. En 65

65 > specifikation som skal være en rig og præcis beskrivelse af de krav, som leverandøren af servicen skal leve op til. Med SOA sker der således en opstramning af kravspecifikationsprocessen. Også denne del af processen udføres af den offentlige myndighed. Service implementering: Udviklingen af den enkelte service tager udgangspunkt i servicekontrakten, dvs. kontrakten for den pågældende service. Som tidligere nævnt er der i praksis flere modeller for udvikling af de enkelte services indpakning af eksisterende systemer eller standardsystemer, services baseret på komponenter m.m. Processen vil afhænge af den konkrete model, men generelt vil fokus i denne del af processen være rettet mod løs kobling til både specifikation og underliggende teknologi. Proces og tilhørende kvalifikationer skal i denne fase fokusere på bedst mulig realisering af de ønskede services. Denne del af processen udføres typisk af en underleverandør i visse tilfælde af den offentlige myndighed selv. Løsningsudvikling: Med udgangspunkt i forretningsforståelsen og de forskellige services udvikles der her sammenhængende itløsninger til understøttelse af de relevante arbejdsgange. Der kan være tale om forskellige former for sammensætning af disse løsninger lige fra fællesløsninger for hele den offentlige sektor til individuelle løsninger i den enkelte myndighed. Selve løsningsudviklingen vil typisk blive udført af en underleverandør, som har ansvaret for udviklingen af de konkrete brugergrænseflader m.m. 66

66