FREDERICIA KOMMUNE. Indholdsfortegnelse

Transkript

1 Indholdsfortegnelse Fredericia Kommunes arkitekturmodel... 2 Den digitale Kommunes krav til fremtidige IT-anskaffelser... 2 Forretningsmæssige krav... 2 Krav til IT-arkitektur... 3 a) at det pågældende IT-system konsekvent understøtter en lagdelt, distribueret og komponentbaseret arkitektur b) at komponenter i IT-systemet er løst koblede, ved hjælp af veldefinerede (og ideelt) smalle funktions (kald) API er, baseret på åbne standarder c) at IT-systemets data-udvekslingsformater er baseret på åbne standarder d) at IT-systemet kan tilgå eksterne datakilder i realtid og via dataservice komponenter e) at IT-systemer så vidt muligt afvikles data-/parameter styret f) at systemet benytter tynde klienter for afvikling af brugergrænseflade logik g) at IT-systemet indgår i en portalbaseret og personaliseret brugergrænseflade h) at IT-systemet integrerer sømløst med Fredericia Kommunes centrale bruger- og gruppekatalog i) at IT-systemet opfylder en række driftsmæssige krav Fredericia Kommunes nuværende arkitektur miljø... 9 Intranet Portal... 9 Hjemmeside, herunder selvbetjening... 9 Elektronisk Dokument Håndtering IDM system AD og stamregistre Forventning til arkitektur udviklingen Side 1 af 14

2 Fredericia Kommunes arkitekturmodel Fredericia Kommunes kommunalbestyrelse vedtog i 2010 en ny digtal strategi der er en videreudvikling af det tidligere IT-strategier. Af strategien fremgår det det bl.a., at kommunen vil være en digital kommune. En væsentlig forudsætning for realisering af de visioner, der udstikkes af Digitaliserings-strategien er fortsat implementering af en IT-arkitektur, som er i stand til at understøtte visionerne bag den digitale kommune. Udarbejdelse af modellen for en IT-arkitektur er gennemført som et selvstændigt projekt i Arkitekturmodellen er siden da blevet revideret flere gange i takt med den teknologiske og organisatoriske udvikling. Nærværende dokument sammenfatter de resultater, der er udviklet under ITarkitektur projektet inkl. efterfølgende justeringer. Dokumentet bruges til orientering i forbindelse med IT-anskaffelser. Leverandører er velkomne til at kommentere på indholdet. Bemærk: Når der i nærværende dokument skrives f.eks. "... det er et krav at ITsystemet...", skal det ikke opfattes som et krav i udbudsteknisk forstand, med mindre det er eksplicit angivet i selve kravspecifikationen. Den digitale Kommunes krav til fremtidige IT-anskaffelser I det følgende beskrives de krav som Fredericia Kommune generelt stiller til nye IT-systemer. Beskrivelsen skelner mellem forretningsmæssige krav og krav til IT-arkitektur. Forretningsmæssige krav Opfyldelsen af forretningsmæssige krav kan opfattes som den "synlige" oplevede effekt af en konkret IT-anskaffelse for brugere af det pågældende ITsystem. Forretningsmæssige succeskriterier og afledte krav for den nye IT-arkitektur er således: at der skabes 'On-line' adgang for kommunens borgere og erhvervsliv til kommunale selvbetjeningsydelser i alle døgnets 24 timer, 365 dage om året og uafhængigt af geografisk lokation. Side 2 af 14

3 at stadig flere ydelser implementeres som "ægte" selvbetjeningsydelser, dvs. at der skabes integration til bagvedliggende fagsystemer, således at borgeren kan gennemføre visse kommunale sagsforløb, uden mellemkomst af kommunens medarbejdere. at medarbejdere oplever en intuitiv, personaliseret og opgaveorienteret PC-arbejdsplads, hvorfra relevante funktioner og informationer kan tilgås enkelt og entydigt, herunder at data vedligeholdes ét sted i realtid. at integrationen mellem forskellige systemer opleves transparent og præsenteres/aktiveres ensartet (efter fælles retningslinier) på kommunens Intranet, herunder at der ikke er behov for særskilt login mellem systemer (Single Sign On). at udbygningen af kommunens IT-systemer kan ske løbende og hurtigt, så der kan reageres effektivt på nye og ændrede arbejdsgangsbehov, som f.eks. lovgivningsmæssige tiltag. at eksisterende og nye anskaffelser, kan genbruges i sammenhænge, de ikke oprindeligt var tænkt ind i. Succeskriteriet her, er ikke mindst, at udbygningen af kommunens IT-systemer løbende medvirker til reduktion af "Informationsøer", der traditionelt er vanskelige at integrere med andre systemer. at IT-systemerne kan skaleres i forhold til en varierende (stigende) forespørgselsmængde. Krav til IT-arkitektur Kravene til IT-arkitektur kan opfattes som de "usynlige" tekniske krav som en konkret IT-anskaffelse er underlagt. IT-arkitekturen skal sikre sammenhæng mellem den nye anskaffelse og kommunens nuværende og fremtidige ITsystemer og IT-infrastruktur. De følgende krav opfattes som en stående målsætning og ambition for udviklingen af kommunens IT-arkitektur og kun i et vist omfang som en beskrivelse af den nuværende situation. Fredericia Kommunens IT-arkitektur krav og ønsker til en konkret anskaffelse er følgende (punkterne a til i): a) at det pågældende IT-system konsekvent understøtter en lagdelt, distribueret og komponentbaseret arkitektur. Et væsentligt kendetegn ved IT-arkitekturen er etablering/vedligeholdelse af en stringent horisontal lagdeling af IT-services og IT-funktioner med veldefinerede snitflader mellem disse servicelag. Ved én IT-service forstås den funktionalitet og de tilhørende data, som et velafgrænset IT-modul tilvejebringer til f.eks. en bruger eller til et andet IT-modul. Side 3 af 14

4 Der skelnes imellem 4 typer af services: Brugergrænseflade lag, som understøtter forskellige arbejdsplads-typer. Brugerservices er de faciliteter, der stilles til rådighed for forskellige brugergrupper. Der er her især fokus på dialog og præsentationsformer rettet mod brugerkategoriernes forskellige opgavetyper. Forretningsservices er moduler (en velafgrænset mængde IT-funktionalitet) der realiserer virksomhedens forretningsprocesser. Begrebet forretningsservices anvendes, fordi modulerne kan indgå i flere forskellige sammenhænge enten i brugerservices eller i andre forretningsservices. Dataservices er delsystemer, der tilvejebringer og vedligeholder virksomhedens elektroniske information med tilhørende metadata beskrivelser. Den elektroniske information omfatter både information i databaser og dokumentarkiver. Det er ikke et krav, at alle lag nødvendigvis anvendes i alle løsninger. Men for at sikre maksimal fleksibilitet og genbrug, skal eksisterende fælles services anvendes og spillereglerne for kommunikation mellem lag overholdes. I nedenstående figur er lagdelingsprincippet for IT-arkitekturen illustreret: Borgere Politiker Samarbejdspartner Medarbejdere Brugergrænseflade Win-program PDA Mobiltelefon Browser SmartBook Smartphone Brugerservice Veldefineret grænseflade til fælles IT-funktioner Forretningsservice Veldefineret grænseflade til fælles e og data - informationer Dataservice Metadata beskrivelse Systemer, data og dokumenter Side 4 af 14

5 I praksis er brugergrænseflade lag og brugerservices ofte implementeret som ét lag i forhold til specifikke systemer og brugergrænseflader (eksempelvis web). I figuren er der identificeret middleware på to niveauer: Mellem forretningsservices og dataservice. Mellem brugerservices og forretningsservices/ressourceservices. I en ideel verden, ville kommunen kun benytte én middelware teknologi, over hvilken alle forespørgsler og opdateringer på tværs af fagsystemer kunne foregå sikkert og effektivt. I praksis må kommunen, som en konsekvens af det brede leverandørgrundlag og forskelligartede teknologier for kommunens IT-systemer, dog leve med forskellige snit mellem arkitektur lag. I det omfang det er muligt foretrækker kommunen, at basere sig på MS middleware komponenter, som fx BizTalk, MS MQ, MS IIS hostede SOAP webservices mv. Det er dog helt klart at kommunen i overensstemmelser med de initiativer der foregår i regi Den Digitale Taskforce, ønsker at basere sin fremtidige eksponering af (især) forretningsservices på web services teknologi. b) at komponenter i IT-systemet er løst koblede, ved hjælp af veldefinerede (og ideelt) smalle funktions (kald) API er, baseret på åbne standarder. Med henblik på at tilgodese forretningsmæssige krav om hurtig tilpasning af funktionalitet, herunder genbrug af eksisterende systemer, er det vigtigt, at programmoduler kan udskiftes og/eller tilpasses individuelt, uden konsekvenser for andre komponenter. Dette hensyn sikres ved anvendelse af kontrakter, der stilles til rådighed af service-komponenter. Klient-komponenter benytter services i service-komponenterne og så længe kontrakten ikke brydes mellem de involverede komponenter, kan de hver især tilpasses uden indvirkning på hverandre. Forudsætningen er, at kontrakter er skrevet i en form, som er standardiseret. Konkret forventes, at komponenter eksponerer funktions-api er over protokoller som COM/DCOM, HTTP og/eller SOAP/XML. Det er Fredericia Kommune forventning, at især SOAP/XML protokollen har et langsigtet potentiale. Samtidig forventes det, at der indeholdt i IT-systemer, som opfylder ITarkitekturen, er en standardiseret adgang til beskrivelsen af disse kontrakter dét der i figuren ovenfor er angivet som Metadatabeskrivelser. Med andre ord ønskes, at det pågældende IT-system, on-line i en passende form, kan Side 5 af 14

6 beskrive, hvilke komponenter og tilhørende API er, systemet stiller til rådighed for omverdenen. Et eksempel på ønsket beskrivelses-syntax er XML schema standarden, WSDL eller tilsvarende. En konsekvens ved opfyldelse af dette krav er, at Fredericia Kommune får en større grad af leverandør uafhængighed en faktor som kommunen lægger vægt på, i et turbulent IT-marked. c) at IT-systemets data-udvekslingsformater er baseret på åbne standarder. Dette krav kan opfattes som en præcisering af kravene under punkt b). Inden for de sidste år har udviklingen inden for IT-teknologien været meget fokuseret på XML som generisk standard for udveksling af data mellem IT-systemer. Det er Fredericia Kommunes forventning, at brugen af XML vil blive udviklet videre, således at udveksling af f.eks. data til/fra databaser, overførsel af parameterdata i forbindelse med servicekald på komponentniveau m.m., med tiden konsekvent indlejres i XML og kaldes over SOAP - og dermed at proprietære formater med tiden helt kan undgås (f.eks. ODBC, NET8 m.v.). d) at IT-systemet kan tilgå eksterne datakilder i realtid og via dataservice komponenter. Som nævnt tidligere er det en stående ambition for kommunen at reducere antallet af uafhængige datakilder / informationsøer. Konkret betyder det i forbindelse med anskaffelse af et IT-system, at det skal analyseres, om kommunen allerede råder over data, som systemet kan tilgå. Typiske eksempler kan være personoplysninger (medarbejder, borger) eller adresseoplysninger m.m. I givet fald skal IT-systemet integrere med disse datakilder i realtid, hvorved ajourføringer i datakilden fra anden part, har øjeblikkelig effekt i det nye IT-system. Ajourføringer til en ekstern datakilde fra det nye IT-system skal desuden udføres på en sådan måde, at datakildens struktur og indhold bevares konsistent til enhver tid. Adgang til eksterne datakilder skal så vidt muligt foregå via nye eller eksisterende dataservice-komponenter. Hvis det ved en konkret anskaffelse afklares, at kommunen ikke allerede råder over en relevant dataservice-komponent, bør leverandøren tilbyde udvikling af en sådan. I visse tilfælde kan det accepteres, at der skabes adgang til eksisterende datakilder via direkte opslag i/ajourføring af datakilden. I visse andre tilfælde kan det accepteres, at integration foretages ved replikering af data mellem ekstern datakilde og det nye IT-system. Side 6 af 14

7 Uanset metode skal integration til eksterne datakilder foretages under behørig hensyntagen til de sikkerheds- og myndigheds-krav, der omgiver den pågældende datakilde (f.eks. persondatalov osv.). e) at IT-systemer så vidt muligt afvikles data-/parameter styret. Rettelser til forretningsregler i ældre IT-systemer kan ofte kun gennemføres ved en programmerings-indsats, en både besværlig og dyr proces. Det er som konsekvens heraf ønskeligt, at nye systemer, i muligt omfang, kan tilrettes ved justeringer til data-/parametre, der bør være indlejret i en database. Målet er således, at det pågældende IT-system indeholder værktøjer, så nødvendig tilpasning kan foretages af kommunens medarbejdere selv. Der kan f.eks. være tale om definitioner af nye arbejdsgange i et ESDH/workflow system, om ændringer af en satsberegning i et dagpengeprogram osv. f) at systemet benytter tynde klienter for afvikling af brugergrænseflade logik. Ved tynde klienter forstås 1) program moduler, der optager et minimalt ressource forbrug på den hardware enhed, modulet afvikles på og 2) program moduler, der kan distribueres til brugere i organisationen med en minimal indsats (ideelt set som en Intranet adresse/url). Typisk er kravet til tynde klienter opfyldt med web-baserede IT-systemer, der kan afvikles i Internet browsere. Generelt er det Fredericia Kommunes ambition, at standardisere på web-baserede systemer. Det vil på sigt sige, at hovedparten af medarbejderens daglige arbejde foran PC en udføres i et browser orienteret miljø. Samtidig forventer kommunen, at vi i de kommende år også vil tage andre tynde klienter i anvendelse, som f.eks.. mobilt Internet, specialiserede håndholdte terminaler m.m. g) at IT-systemet indgår i en portalbaseret og personaliseret brugergrænseflade. Fredericia Kommune benytter i sin IT-infrastruktur web-server teknologi fra Microsoft. Det er dog kommunens forventning, at blandede web-server miljøer, kan være aktuelle i kommunen fremover. Side 7 af 14

8 Det er et krav til nye IT-systemer, at de kan indgå transparent i kommunens Intranet miljø uanset hvilken platform produktet i øvrigt er udviklet til. Integrationen skal gennemføres, således at brugere ikke skal logge ind på det nye ITsystem, når brugeren allerede er kendt på Intranettet /LAN (Single Sign On). h) at IT-systemet integrerer sømløst med Fredericia Kommunes centrale bruger- og gruppekatalog. Fredericia Kommune baserer sin bruger-, gruppe og organisatorisk-enheds (OU) vedligeholdelse på Microsoft Active Directory (AD). Desuden og af hensyn til muligheden for at supplere AD oplysninger med andre data, der ikke egner sig til opbevaring i AD vedligeholdes visse oplysninger om brugere, grupper, roller og OU endvidere i en MS SQL baseret database. Det er et krav til nye IT-systemer, at der er direkte eller indirekte brugervalidering mod AD, evt. via den LDAP implementering, som eksponeres alternativt af AD. Målet er at opnå central bruger- og rettighedsadministration, således at denne kan varetages i ét sammenhængende system, med direkte (realtids) effekt i nye IT-systemer såvel som i kommunens eksisterende IT-systemer. Det forventes, at det nye IT-system - ved læsning/skrivning af data fra/til eksterne kilder og/eller ved anvendelse af 3. parts API'er - er i stand til at videregive brugerens adgangstegn (eng.: logintoken), på en sådan måde, at der gives mulighed for transparent adgang til eksterne systemer, samt mulighed for sporbarhed m.v. IT-systemet forventes endvidere sikkerhedsmæssigt, at kunne konfigureres og afvikles niveauopdelt. Konkret spædende fra ingen sikkerhed til maksimal sikkerhed inkl. krypteret digital signatur fx OCES borger/medarbejder certifikat. Samtidig skal IT-systemets arkitektur understøtte løbende tilpasning af det gældende sikkerhedskoncept, således at nye teknologiske landvindinger og/eller udviklingen inden for brugen af digitale signaturer i Danmark kan imødekommes. Desuden er der er meget klar forventning til, at oplysninger vedrørende kommunens IT-brugere, medarbejdere og organisatoriske enheder, m.v. ikke skal (gen)etableres i forhold til anskaffelsen af et nyt IT-system, men derimod kan læses fra kommunens eksisterende kilder. Herunder at den løbende vedligeholdelse af disse oplysninger, afspejles i realtid eller nær realtid i IT-systemet. Side 8 af 14

9 i) at IT-systemet opfylder en række driftsmæssige krav. Som nævnt tidligere er der forventning til en effektiv afvikling af kommunens IT-systemer i døgnets 24 timer, hele året rundt - en forventning der er stigende i takt med udvikling af kommunens borger-rettede selvbetjeningsydelser. Det er derfor et krav, at det nye IT-system kan konfigureres til at indgå i et driftsmiljø, hvor "Single Point of Failure"' kan elimineres ved hjælp af fejltolerant hardware som f.eks. virtualisering, SANs, klynger af applikationsservere, message queing integrationer mv. Samtidig, og muliggjort ved anvendelse af denne teknologi, forventes det, at nye IT-systemer kan imødekomme et stigende behov ved simpel hardware skalering. Samtidig forventes det, at IT-systemerne kan skaleres ved distribution, dvs. ombrydning af konfigurationer, således at særligt CPU-tunge servicekomponenter kan (om)placeres på dedikerede servere/serverfarme osv. Endvidere er der en række krav vedrørende det nye IT-systems muligheder for at kunne overvåges via TNG UNIcenter, således at en række applikationsovervågningsparametre beskrives i forhold til monitorering på TNGplatformen. Fredericia Kommunes nuværende arkitektur miljø Det er primært i forbindelse med kommunens etablering af hjemmeside, Intranet, ESDH, Økonomisystem og AD/Stamregistre, at der er taget hul på realisering af kommunens IT-arkitektur strategi. Et stigende antal fagsystemer understøtter også kravene til IT-arkitektur i større eller mindre grad. I det følgende beskrives miljøerne i yderligere detalje. Intranet Portal Fredericia Kommunes Intranet er baseret på Microsoft Sharepoint Portal x.x. Som database benyttes SQL200x Systemet er taget i drift i medio 200x. Yderligere information omkring MS Sharepoint, kan findes på Microsofts hjemmeside. Hjemmeside, herunder selvbetjening Fredericia Kommunes hjemmeside afvikles på Microsoft Sharepoint Portal x.x der hostes eksternt. Ved levering af et nyt IT-system bedes leverandøren - med henblik på levering af selvbetjenings-services til kommunens borgere - vurdere, hvorledes der op- Side 9 af 14

10 nås hel eller delvis (realtids) integration fra hjemmesiden til det pågældende IT-system. Integrationen skal foregå med konsekvent hensyntagen til sikkerhed og adgangsrettigheder, herunder til hacker forebyggelse (f.eks. SQL injection attacks, m.v.). Forholdet til signon metode der anvender Nem-login og Nem ID skal medtages. Det er væsentligt, at det pågældende IT-system samtidigt giver mulighed for integration med interne, dvs. Intranet baserede services (ligeledes i realtid). I forbindelse med anskaffelse af nye IT-systemer forventes det således, at leverandøren forholder sig til den beskrevne hjemmeside arkitektur og vurderer, hvilke konkrete tiltag der skal gennemføres mhp. integration som beskrevet i det foregående. Elektronisk Dokument Håndtering I løbet af 2009 har Fredericia Kommunes implementeret ESDH systemet Acadre i samtlige forvaltningsområder samt KMD Sag EDN til behandling af personsager. Der er omkring brugere på løsningen. Acadre er implementeret som en windows klient. Dokumenter og sager opbevares i SAN baseret SQL200x database. Det er kommunens forventning, at ESDH systemet skal udvikle sig til krumtap for al sagsbehandling, som foregår uden for dedikerede fagsystemer. I forbindelse med anskaffelse af nye IT-systemer forventes det, at leverandøren forholder sig til de naturlige integrationer, der måtte være mellem det pågældende IT-system og kommunens ESDH system. Som eksempel kan nævnes muligheden for at vise/afspejle eksterne sager/sagshændelser i ESDH og/eller initiere/integrere med sagsforløb i ESDH systemets workflow. Den overordnede målsætning er uafhængigt af de konkrete IT-systemer, at tilvejebringe en helhedsorienteret dokument- og sagsbehandlings arbejdsplads. IDM system I løbet af 2010 har Fredericia Kommunes implementeret et IDM system baseret på Novell IDM platform. Integrationer er i dag til Opus, AD, Telefonisystem, KSP/CICS. Side 10 af 14

11 Muligheden for integration mod IDM systemet skal være beskrevet i forbindelse med implementering af nye it-systemer. AD og stamregistre En række grundoplysninger omkring kommunens virksomhed opbevares mest hensigtmæssigt uden for de (mange) IT-fagsystemer, som kommunen anvender. Derfor vedligeholder kommunen foruden AD, en række lokale databaser der indeholder væsentlige grunddata (entiteter). Nedenfor listes de entiteter der er tale om: Medarbejdere og (IT-brugere). Medarbejderoplysninger omfatter kompetencer/cv, deltagelse på kurser, deltagelse i projekter m.v. Organisatoriske enheder, herunder institutioner. Udvalg. Politiske udvalg, samt råd og nævn. Foreninger. Borgere/P-Data. Dagligt udtræk fra KMD. Løsningen overvejes udbygget med mulighed for on-line opslag på udenbys borgere. Ejendoms- og miljø data (E&M). Dagligt udtræk fra KMD. Virksomhedsdata. Kombineret løsning med lokal database og on-line opslag mod centralt vedligeholdt kilde. Metadata. Ved metadata forstås strukturede nøgleord, som kommunen selv har etableret og vedligeholder. Metadata danner udgangspunkt for opmærkning af f.eks. dokumenter og andet materiale, som kommunens medarbejdere producerer mhp. understøtte ønsket om effektiv viden deling. Konkret ved at give mulighed for søgning på de samme nøgleord på tværs af IT-systemer (f.eks. ESDH og Intranet). KL Journalplan. Også metadata periodisk leveret af KL. Anvendes til opmærkning af sager i ESDH, herunder som udgangspunkt for dannelse af statistikker. I forbindelse med anskaffelse af nye IT-systemer forventes det, at leverandøren forholder sig til de data/entiter der er nævnt, i det omfang at det pågældende system anvender en eller flere af datakilderne. Specielt skal alle nye ITsystemer redegøre for IT-bruger/medarbejder/OU integration. På nær nogle enkelte af de systemer der er beskrevet ovenfor, har kommunen ejerskab for vedligeholdelse af datamodeller og data indhold. Side 11 af 14

12 Forventning til arkitektur udviklingen Fredericia Kommune har beskæftiget sig med IT-arkitektur som selvstændigt IT fagområde siden medio IT-arkitektur indgår som emne i alle større IT-projekter der igangsættes. ITarkitekturen har i den forbindelse til formål, at vurdere de nye IT-systemers opfyldelse af krav til IT-arkitektur. Desuden er det IT-arkitektur funktionens opgave, løbende at foretage justeringer til de principper som er styrende for arkitekturen og som nye systemer vurderes i mod, i takt med den teknologiske og forretningsmæssige virkelighed. Umiddelbart forventer kommunen, at udviklingen på arkitektur området vil gå i retning af besked baserede (XML) integrationer, konkret implementeret i objekt-brokere (ORBs), som fx MS BizTalk. Brokeren stiller services til rådighed, via web-services (f.eks. SOAP baserede). Der vil ske en gradvis til lempelse/accept af de initiativer, der udspringer centrale omkring Den Digitale Taskforce, men kommunen agter på den anden side ikke at afvente vedtagelser af standarder på centralt hold, hvis en taktisk løsning, kan skabe en nytteværdi ift en given behov/arbejdsgang. I nedenstående figur er XML-brokeren indpasset i et forventet fremtidigt miljø, der omfatter både Inter-, og Intranet, ESDH og KMD-systemer, samt lokale fagsystemer. Side 12 af 14

13 KMD Andre Borger - browser Inter - nettet Intranet Portal FireWall XML Broker EJB - Miljø (Oracle 9iAS) XXX yyy DNA miljø (Microsoft) Lokale fagsystemer EDH platform XML snitflader Native (plsql/asp m.fl) URL links Eksempel på indpasning af XML broker i Gentofte Kommunes IT-arkitekur Nye IT-systemer bør så vidt muligt kunne integrere med den skitserede XMLbroker model eller bringes til det, ved en begrænset og kendt integrationsindsats. IT-systemer, som ikke integrerer på dette niveau endnu, skal leveres med udviklingsplaner for, hvornår en sådan integration kan forventes, og hvilke forudsætninger der i øvrigt skal være opfyldt. Fredericia Kommune anvender pt. MS XML broker (BizTalk version 2004) som prototypisk element i kommunens IT-miljø, men kører pt. ikke i drift på miljøet. Installationen eksponerer adgang til en række stamdata over web-services, samtidig med at disse er dokumenteret i et service katalog. Side 13 af 14

14 Side 14 af 14