Bilag 3, Leverancebeskrivelse med Kravspecifikation og Løsningsbeskrivelse samt ændringsmuligheder (herunder Optioner)

Transkript

1 Bilag 3, Leverancebeskrivelse med Kravspecifikation og Løsningsbeskrivelse samt ændringsmuligheder (herunder Optioner) Version Ændringer Dato 2.1 Tilføjet krav Tilføjet Punkt Korrekturændringer, samt rettelser i bilagsreferencer Rettet i: - Henvisninger til underbilag korrigeret - Punkt 1. - Punkt Punkt Punkt Punkt Punkt Punkt Punkt Punkt Punkt Punkt Punkt Flyttet (5.2) - Punkt slettet - Punkt Punkt Punkt Punkt Punkt Punkt Punkt Punkt Punkt Punkt Punkt Punkt Punkt Punkt Punkt Punkt Punkt Punkt Punkt

2 - Punkt Punkt Punkt Punkt Punkt Punkt Punkt indsat - Krav Krav Krav Krav Krav Krav Krav Krav 3.23 fjernet - Krav Krav Krav Krav Krav Krav Krav Krav Krav Krav Krav Krav Krav Krav 3.54 fjernet - Krav 3.55 fjernet - Krav Krav Krav Krav 3.59 fjernet - Krav 3.60 fjernet - Krav 3.61 fjernet - Krav 3.62 fjernet - Krav 3.63 fjernet - Krav 3.64 fjernet - Krav 3.65 fjernet - Krav 3.66 fjernet - Krav 3.67 fjernet - Krav 3.68 fjernet - Krav 3.69 fjernet - Krav Krav Krav 3.72

3 - Krav Krav Krav Krav Krav Krav Krav Tabel 1 - Tabel 2 - Krav Krav Krav Krav Krav Krav Krav Krav Krav Krav Krav Krav Krav Krav Krav Krav fjernet - Krav fjernet - Krav Krav fjernet - Krav Krav Krav fjernet - Krav fjernet - Krav Krav fjernet - Krav fjernet - Krav fjernet - Krav Krav Krav Krav Krav Krav Krav Tilføjet Krav Tilføjet Krav Tilføjet Krav Tilføjet Krav 3.171

4 - Tilføjet Krav Tilføjet Krav Tilføjet Krav Tilføjet Krav Tilføjet Krav Tilføjet Krav Tilføjet Krav Vejledning til udfyldelse - Complianceliste 3.0 Ophøjet til version

5 Indholdsfortegnelse Indholdsfortegnelse... 5 Vejledning til udfyldelse Underbilag 3a: Læsevejledning Løsningsbeskrivelse Underbilag 3a.i: Kundens forretningsmæssige behov og mål Læsevejledning Baggrund Formål Sammenhængen til grunddataprogrammet Begreber Begrebsdefinition Kontekstdiagram og aktører Kontekstdiagram Systemaktører Svømmebanediagrammer Håndtering af datamodeller Datafordeleren som distributionsplatform Datafordelerens Funktionalitet Forretningsorienterede komponenter Datafordeler Basisinfrastruktur og Basisplatform komponenter Underbilag 3a.ii: Generelle krav til Systemet Læsevejledning Generelle krav til Systemet Ikke-funktionelle krav Arkitekturkrav Brugervenlighed, Look & Feel og tilgængelighed Sikkerhed Fejlhåndtering Statistik og logning Obligatoriske, åbne standarder for software i det offentlige Lovmæssige og politiske krav Underbilag 3a.iii: Krav til Fastlagte Delleverancer Læsevejledning Delleverance 0: Basisinfrastruktur Delleverance 2 og 3: Platformens Funktionalitet Delleverance 2 og 3: Generelle krav Delleverance 2 og 3: Krav til håndtering af datamodeller Delleverance 2 og 3: Skalering Delleverance 2 og 3: Metadata Delleverance 2 og 3: Fildistribution Delleverance 2 og 3: Services og transformation Delleverance 2 og 3: Brugerstyring Delleverance 2 og 3: Opdatering af Datafordeler Delleverance 2 og 3: Referenceimplementeringer Underbilag 3a.iv: Krav til Agile Delleverancer Læsevejledning Generelle krav til de Agile Delleverancer Konsolidering af Registre Generelle krav til Konsolidering Delleverance 4: Konsolidering af OIS/AWS Delleverance 5: Konsolidering af Kortforsyning Option 1: Konsolidering af Persondata Option 2: Konsolidering af CVR

6 5.4. Option 3: Udvidet Platform Option 3: Abonnement og distribution af Hændelser Option 3: Linked Data, RDF og SPARQL Option 3: Udviklingsrammeværk Videreudvikling Prædefinerede videreudviklingsydelser Yderligere krav Complianceskema

7 7 Vejledning til udfyldelse De behov, som tilbuddet skal dække, er klassificeret og beskrevet som krav. Alle krav er indsat i en kravskabelon, hvor selve kravet fremgår af feltet Kravbeskrivelse. Kravtitel og Kravområde er vejledende information til tilbudsgiver som har til formål at danne grundlag for en logisk gruppering af krav. I feltet Delleverance angives vejledende, hvilken eller hvilke bestemte Delleverancer eller Optioner, kravet vedrører. For krav som vedrører alle dele af Projektet angives ingen værdi i feltet Delleverance. Kravtypen kan antage en af følgende værdier: Kravtype Markering af kravtype Betydning Mindstekrav Værdi: MK Mindstekrav skal opfyldes uden forbehold for, at et tilbud kan være konditionsmæssigt Prioriteret krav Værdi: PK Prioriterede krav har stor betydning for opfyldelse af de forretningsmæssige mål, og tillægges derfor særlig vægt ved vurdering af de afgivne tilbud. Krav Værdi: K Almindelige krav, som bidrager til opfyldelse af de forretningsmæssige mål. Tilbudsgiver kan angive alternative forslag til disse krav i form af forbehold. For krav som stilles til Agile Delleverancer, angives i feltet, om kravet er et Absolut Krav eller et Øvrige Krav som defineret i Bilag 0. Alle krav er nummereret på 2. niveau, med foranstillet bilagsnummer, jf. nedenstående eksempel: Kravnr. 1.1 Kravtitel Eksempel på krav Kravtype K Kravområde Eksempel Øvrige Delleverance krav Kravbeskrivelse Leverandøren skal tage dette krav til efterretning Vejledende tekst i bilag I bilagene er der imellem de konkrete krav visse steder indføjet vejledende tekst. Vejledende tekst er unummereret generel tekst til tilbudsgivers orientering. Dette illustreres med følgende eksempel: Dette bilag indeholder Kundens specifikation af krav til Systemets funktion og virkemåde. Tilbudsgivers løsningsbeskrivelse Tekst omgivet af firkantede parenteser og angivet med fed og kursiv skrift er vejledende tekst til tilbudsgiver om, hvad tilbudsgiver med egne ord skal beskrive i tilbuddet. Dette illustreres med følgende eksempel:

8 8 [Tilbudsgiver beskriver opfyldelsen af kravet i underbilag X.X.] Angivelse af kravsopfyldelse Alle bilag, som indeholder krav til Leverandøren, afsluttes med et complianceskema, hvor tilbudsgiver skal angive hvilke krav, der opfyldes af det afgivne tilbud, og om der er taget forbehold i form af ændring af kravteksten. Ved udfyldelsen af complianceskemaerne placeret sidst i bilaget skal tilbudsgiver for hvert krav angive med afkrydsning, om kravet er opfyldt, om kravet er opfyldt med forbehold i form af ændret kravtekst, eller om kravet ikke er opfyldt. Eksempel på udfyldt complianceskema: Krav nr. Kravet er opfyldt Kravet er opfyldt med forbehold Kravet er ikke Delkriterie i form af ændret kravtekst opfyldt 1.1 X Tidsplan 1.2 X Tidsplan 1.3 X Tidsplan 1.4 X Såfremt et krav er opfyldt uden forbehold skal tilbudsgiver angive dette ved afkrydsning i complianceskemaet ud for det aktuelle kravnummer og Kravet er opfyldt. Mindstekrav er i complianceskemaerne markeret med grå og er på forhånd afkrydset i kolonnen "Kravet er opfyldt", idet enhver anden afkrydsning fører til, at tilbuddet er ukonditionsmæssigt. Såfremt tilbudsgiver tager forbehold til et krav, der ikke er et mindstekrav, indarbejdes forbeholdet direkte i kravteksten som en ændring af denne. Ændringen skal være markeret med ændringsmarkering. Der sættes herudover kryds i complianceskemaet ud for det aktuelle kravnummer i kolonnen Kravet er opfyldt med forbehold i form af ændret kravtekst. Der kan herudover henvises til evt. yderligere bilagsmateriale/dokumentation, der er vedlagt tilbuddet. Såfremt tilbudsgiver vil angive at et krav ikke er opfyldt, skal tilbudsgiver angive dette ved afkrydsning i complianceskemaet ud for det aktuelle kravnummer og i kolonnen Kravet er ikke opfyldt. I complianceskemaets højre kolonne fremgår det, hvilket delkriterie, jf. udbudsbetingelsernes punkt 4, det pågældende krav er relateret til.

9 9 1. Underbilag 3a: Læsevejledning Underbilag 3a er Kundens Behovsopgørelse, som er opdelt i følgende underbilag. Underbilag 3a.i beskriver Kundens forretningsmæssige Mål og Behov for Leverancen Underbilag 3a.ii beskriver generelle krav til Systemet Underbilag 3a.iii beskriver krav til de Fastlagte Delleverancer Underbilag 3a.iv beskriver krav til de Agile Delleverancer, Optioner og videreudviklingsydelser, som alle leveres efter den Agile Metode 1.1. Løsningsbeskrivelse Løsningsbeskrivelsen er Leverandørens selvstændige beskrivelse af Leverancen. Nærværende bilag indeholder desuden en række steder retningslinjer for indholdet i løsningsbeskrivelsen i form af krav til uddybende beskrivelser. Evt. underdokumenter til løsningsbeskrivelsen, er nummeret med romertal og vedlagt som appendikser ( Appendiks I, Appendiks II, Appendiks III og så fremdeles).

10 10 2. Underbilag 3a.i: Kundens forretningsmæssige behov og mål 2.1. Læsevejledning Udover denne læsevejledning indeholder underbilag 3a.i følgende kapitler: Punkt 2.2 indeholder en beskrivelse af den forretningsmæssige baggrund og formål for Systemet. I punkt 2.3 præsenteres de forretningsmæssige begreber, som er væsentlige for bilag 3. I punkt t 2.4 findes en beskrivelse af konteksten for Systemet, herunder brugeraktører og systemaktører. I punkt 2.5 findes en overordnet beskrivelse af Systemets Funktionalitet I punkt 2.6 findes en beskrivelse af de overordnede tanker, om hvordan Registrene kan implementeres på Systemet 2.2. Baggrund Etableringen af den fællesoffentlige Datafordeler skal ses i sammenhæng med digitaliseringsstrategiens 1 kapitel 10 vedr. fælles Grunddata for alle myndigheder. Grunddataprogrammet har fokuseret på at håndtere de barrierer, der eksisterer i forhold til den effektive benyttelse og genbrug af Grunddata. Som følge af disse barrierer, blev der i Grunddataprogrammet defineret følgende fem indsatsområder: Omkostninger ved Grunddata Tilgængelighed af Grunddata Kvalitet af Grunddata Sammenhæng i Grunddata Styring af Grunddata I oktober 2012 blev Grunddataprogrammet, herunder de otte delaftaler, godkendt af Regeringens Økonomiudvalg (ØU), og dermed var grundlaget til stede for at igangsætte de projekter, der er nødvendige i en fælles sammenhængende effektiv Grunddataindsats på tværs af de autoritative Grunddata. Disse Grunddata er beskrevet i nedenstående figur. 1

11 11 Figur 1 Illustration af sammenhænge i Grunddata Samlet giver Grunddata-programmet en effektivisering af den offentlige sektor på 179 mio. kr. i 2016 stigende til 231 mio. kr. i 2020 gennem bedre sagsbehandling, mindre dobbelt-vedligehold og lavere itomkostninger. Etableringen af den fællesoffentlige Datafordeler har fokus på at løfte punktet vedrørende tilgængelighed af data, ved at sikre høje oppetider, ensartede tekniske grænseflader og et sted hvor man finder, indgår aftaler om og henter de offentlige Grunddata. Myndigheder og virksomheder, der bruger Grunddata, skal kunne modtage disse hurtigt og pålideligt. Samtidig kan der spares penge i den offentlige sektor ved at distribuere Grunddata ad en fælles kanal frem for ad flere forskellige. Der eksisterer i dag separate distributionsløsninger for Grunddata om personer, virksomheder, adresser, boliger og geografi, som funktionelt minder meget om hinanden. For de myndigheder, der står for disse distributionsløsninger, er distribution forbundet med stigende omkostninger, både på grund af stigende databenyttelse på platforme, men også som følge af frikøb, samt eventuelle krav om 24/7 support. For de offentlige og private Dataanvendere er det omkostningsfuldt at skulle integrere til flere forskellige tekniske grænseflader, at skulle indgå flere aftaler, samt løbende at skulle følge de udviklinger som sker på de forskellige platforme. Dernæst er det mindre stabilt at skulle hente data fra flere forskellige distributionsløsninger, for selv om hvert Register kan levere oppetider på mellem 98 % og 99 %, så bliver den samlede oppetid på tværs af registre væsentligt mindre. Da flere eksisterende løsninger samtidig er tæt på at være teknisk forældede, betyder det, at de eksisterende systemer til distribution ikke altid kan levere de efterspurgte Grunddata lige så hurtigt, som brugerne har behov for. En fælles distributionsløsning vil imødekomme behovet for at kunne hente data

12 12 nemt, hurtigt og pålideligt og med færrest mulige omkostninger. Og det vil spare resurser hos Registermyndigheder, når det ikke længere er nødvendigt at modernisere mange forskellige distributionsløsninger af data hver for sig. Datafordeleren erstatter eksisterende distributionsløsninger, herunder Kortforsyningen (landkort og geografi), CVR og selskabsdistributionen (virksomheds- og selskabsdata), CPR distribution (persondata) og OIS/AWS (adresser og ejendomme), og leverer en fælles høj oppetid, ensartede aftaler og grænseflader og et kontaktpunkt for brugere af de fællesoffentlige Grunddata. Med idriftsættelsen af den fællesoffentlige Datafordeler er der etableret en fællesoffentlig infrastruktur til distribution af Grunddata, med følgende overordnede principper: Alle Grunddata distribueres via Datafordeleren og Datafordeleren kan også anvendes til at distribuere andre relevante data end Grunddata. Opdatering af Grunddata sker fortsat gennem Registermyndighedens grænseflader. Registermyndigheden skal til Datafordeleren levere og vedligeholde en opdateret kopi af Grunddata med en frekvens, der er tilstrækkelig i forhold til brugernes behov for aktualitet. Eksisterende dataansvar er uændret, og Registermyndighederne sikrer udviklingen af specifikationer af Tjenester til udstilling på Datafordeleren. Tværgående databeskrivelser udarbejdes i samarbejde af de relevante Registermyndigheder. Datafordeleren distribuerer data via Online-opslag, hændelser og fil-distribution til både offentlige og private brugere. Datafordeleren giver adgang til Grunddata via standardiserede aftaler. Hvis en offentlig eller privat bruger i medfør af lovgivning, frikøbsaftaler eller betalingsaftaler har ret til at anvende data i Datafordeleren, så kan denne bruger som udgangspunkt hente disse data uden yderligere omkostninger. Datafordeleren opbevarer og distribuerer Grunddata i henhold til gældende lov. Figur 2 Kontekst for Datafordeler

13 Formål Det er et mål i den fællesoffentlige digitaliseringsstrategi, at Grunddata skal være et fælles forvaltningsgrundlag for den offentlige sektor, der vedligeholdes ét sted (i de respektive Registre) og anvendes af alle de myndigheder, der har behov for de omfattede oplysninger. For at dette kan lade sig gøre skal Grunddata bl.a. have en høj teknisk tilgængelighed, dvs. at oppetiden for Grunddata er meget høj, og at Grunddata kan tilgås med et meget stort antal opslag på kort tid. Denne service skal tilbydes gennem en fællesoffentlig Datafordeler. Projektets primære formål at effektivisere datadistribution i det offentlige, både ved at konsolidere eksisterende distributionsløsninger altså samle løsninger på en platform men også ved at sikre, at der fremadrettet eksisterer en fælles platform, som andre offentlige data kan distribueres fra. Sidstnævnte vil medføre en markant reduktion i omkostninger forbundet med at skulle dele de offentlige data Sammenhængen til grunddataprogrammet Som tidligere omtalt skal Datafordeleren ses i sammenhæng med grunddataprogrammet, hvorfor de øvrige initiativer i grunddataprogrammet både er med til at definere og afgrænse scope for den fællesoffentlige Datafordeler. I indeværende punkt findes en overordnet beskrivelse af de temaer i grunddataprogrammet, som er væsentlige at være opmærksomme på i den samlede forståelse af den ramme Datafordeleren forventes at fungere indenfor. For yderligere informationer om grunddataprogrammet og de enkelte initiativer i grunddataprogrammet henvises der til og i det følgende beskrives tre væsentlige temaer, som der bør være opmærksomhed omkring i Projektet, nemlig grunddataprogrammets håndtering af governance, kvalitet og datamodellering. Governance: En tværoffentlig grunddatabestyrelse skal bidrage til at sikre en effektiv og koordineret udvikling og anvendelse af grunddata på tværs af den offentlige sektor. Grunddatabestyrelsen har bl.a. til opgave at: Sikre koordination af større udviklingstiltag og ændringer til eksisterende Grunddata Udarbejde forslag til nye udviklings- og effektiviseringsprojekter på grunddataområdet, herunder at finansiere analyser og mindre udviklingsaktiviteter Sikre at snitflader, standarder og datamodeller for Grunddata er indbyrdes koordinerede Godkende budget, udviklingsplaner, dataindhold mv. for Datafordeleren Have dialog med både den offentlige og den private sektor om potentialerne ved bedre udnyttelse af de offentlige Grunddata Sikre at alle myndigheder udnytter potentialerne ved effektiv anvendelse af Grunddata Dokumentere og følge op på myndighedernes anvendelse af Grunddata og rapportere årligt herom til regeringen og KL. Kvalitet: For at løfte kvaliteten af Grunddata forventes det, at der vil der blive ryddet op i og forbedret flere registre med centrale offentlige data og initiativer til forbedring af kvalitet omfatter: På ejendomsområdet forbedres registrene, således at oplysninger om ejendomme og bygninger samt disses ejerforhold registreres i autoritative registre på ejendomsområdet på en ensartet måde jf. På adresseområdet etableres en sammenhængende infrastruktur, og datagrundlaget forbedres, så det sikres, at data om adresser, stednavne og administrative enheder stilles til rådighed for alle på

14 14 en effektiv måde jf. På vandforvaltningsområdet etableres et landsdækkende fællesoffentligt grunddatasæt for vandløb, derudover er de geografiske Grunddata blevet frikøbt jf. Der gennemføres en analyse på Persondataområdet, hvor der udarbejdes et forslag til en mere effektiv og sammenhængende personregistrering og distribution af persondata via Den Fællesoffentlige Datafordeler jf. På virksomhedsdataområdet gennemføres der en række kvalitetsforbedringer og derudover er virksomhedsdata blevet frikøbt jf. Endelig gennemføres der løbende nye analyser, der vurderer om der bør igangsættes og gennemføres yderligere initiativer jf. Figur 2.1 Levering af nye Tjenester Kvalitetsinitiativer medfører, at de eksisterende Tjenester, der i dag benyttes til at distribuere Grunddata, indenfor visse områder vil skulle genudvikles. Tjenester til distribution af Grunddata vil selvfølgelig skulle udstilles på Datafordeleren, men specifikationen af Tjenesten vil ske i kvalitetsprojekter hos Registermyndighederne. På den baggrund beskriver figur 2.1 processen for levering af nye Tjenester. Fælles datamodel og modelregler: Den fælles datamodel skal sikre, at data kan sammenstilles på tværs af grunddataregistrene, og dermed bidrage til en mere effektiv forvaltning. Dette forudsætter en fælles måde at modellere og beskrive grunddata på samt aftaler om, hvordan relationerne mellem forskellige grunddata skal være.

15 15 Grunddataprogrammet har derfor et tværgående projekt med det formål at udvikle en fælles datamodel for grunddata. Som led i dette er der fastlagt fælles modelregler for Grunddata, der angiver, hvordan grunddataforvalterne skal opbygge deres datamodeller, og hvad datamodellerne skal indeholde. Modelreglerne og yderligere beskrivelser af den fælles datamodel kan findes via følgende link: Begreber Dette punkt indeholder definition af centrale termer og begreber der har en specifik betydning for Systemet. Der henvises til bilag 0 for begreber med specifik betydning for Projektet Begrebsdefinition Begreb Abonnement Attribut Attributværdi Bitemporale egenskaber Datasamling Forvaltningsobjekt / Objekt / Forretningsobjekt Funktionalitet Grafisk Brugergrænseflade Grunddatamodellen Hændelse Hændelsesbesked Definition Et abonnement er en registrering af at en Dataanvender ønsker at få besked når en specifik ændring indtræffer eller når en vilkårlig Hændelse vedrører en Dataentitet. Dvs. et Abonnement kan være på Hændelser eller på Dataentiteter. Et Abonnement beskriver også, hvorledes Dataanvenderen ønsker at modtage Hændelsesbeskederne. Attributterne er de enkelte, databærende elementer i Dataentiteten, konkrete forekomster kaldes Attributværdier. Se Attribut. Metadata på objektniveau, som angiver tidsperioder for en given oplysnings faktiske henholdsvis registreringsmæssige gyldighed. Datasæt indsamlet, opbevaret og vedligeholdt som en logisk Dataentitet hos en organisation. Forvaltningsobjekterne er de ting, som grunddataprogrammet skal forbedre håndteringen af, herunder også ved at distribuere disse via Datafordeleren. Forvaltningsobjekterne er altså Person, Sted, Område, Virksomhed, mv. der henvises i øvrigt til figur 1 i bilag 3. De enkelte forekomster af Forvaltningsobjekter kommunikeres som entiteter, hvor et eksempel på en person er Jan Emil Oppenheimer. Logisk, operationel egenskab ved Datafordeleren, som er beskrevet i punkt 2.5 Brugergrænseflade som repræsenteres på en skærm og består af en kombination af tekst og grafik som en Bruger direkte kan manipulere med fx tastatur og mus eller en trykfølsom skærm. Den samlede informationsmodel for de Grunddata, som udstilles via Systemet. Se i øvrigt punkt I Datafordelerens kontekst er en Hændelse udtryk for en handling på et Dataentitet, der medfører at Dataentiteten ændrer status eller indhold. Hændelsen udtrykkes gennem en hændelseskode, der angiver ændringen og årsagen til ændring, hvor årsag og detaljering afhænger af det enkelte Register og forretningsmæssige regler for dette. En Hændelsesbesked er samlingen af hændelseskode og relaterede data som Datafordeleren sender til de Dataanvendere, der abonnerer på Hændelsen eller på det Dataentitet der er berørt af Hændelsen.

16 16 Referenceimplementering Implementering af datamodel og snitflader for udvalgte Tjenester, der implementeres på Registerplatform henholdsvis Geodataplatform, og anvendes til Pilotdrift for Delleverance 2 og Delleverance 3. Registry Funktionalitet i Systemet som gør det muligt at registrere oplysninger om eksterne metadatakilder. Repository Funktionalitet i Systemet som gør det muligt at lagre metadata om de data, som udstilles via Systemet. Sikkerhedstoken Digital kode som udstedes af en autentifikationstjeneste eksempelvis NemLogin for at attestere, at en Bruger har ret til adgang til Systemet. Synkronisering Handling eller gruppe af handlinger som sikrer, at de Grunddata, der udstilles via Systemet stemmer overens med de Grunddata, der er registreret i Registrene. Transformation Funktionalitet som formidler omdannelse af data fra et format til et andet Kontekstdiagram og aktører Datafordeleren indgår i et samspil med en række forskellige systemaktører i form af Registre eller Dataanvendere. De forskellige aktører gennemgås i den følgende beskrivelse. Denne skal opfattes som en serviceinformation og forståelsesramme for Leverandøren, men indeholder ikke i sig selv krav til Leverancen Kontekstdiagram Jf. figur 2 omfatter konteksten for Datafordeleren følgende Aktører: Dataanvendere, der modtager eller henter Grunddata fra Datafordeleren Registre, der leverer Grunddata til Datafordeleren Brugere, der tilgår Datafordeleren via de implementerede brugergrænseflader, typisk til administrative formål, herunder o Selvbetjening til brugeroprettelse o Administration af abonnementer for Dataanvendere, o Fremsøgning af dokumentation i metadatakatalog for Dataanvendere o Vedligehold af dokumentation i metadatakatalog for Registermyndigheder o Konfiguration af nye distributionsgrænseflader for Registermyndigheder Systemaktører En række Eksterne Systemer forventes at interagere med Systemet i forskellige sammenhænge, som overordnet beskrives nedenfor.

17 17 Navn Rolle Opgave Antal/Kapacitet Navn Rolle Opgave Antal/Kapacitet Navn Rolle CPR CPR er Registeret, der indeholder persondata om danskere. CPR er datakilde for persondata i Datafordeleren Aktøren er master for person Grunddata og har ansvar for at levere opdaterede person Grunddata til Datafordeleren Der findes ét autoritativt CPR register, der indeholder alle danske CPR-numre med tilhørende persondata. Datamængder er beskrevet i bilag 2 Registre som MBBL har distributionsansvar for Registre som MBBL har distributionsansvar for er ansvarlige for data om fast ejendomme, adresser og bygninger i Danmark Aktøren er master for Grunddata om fast ejendom, adresser og bygninger, og har ansvaret for at levere opdaterede Grunddata om disse til Datafordeleren Registre som MBBL har distributionsansvar for består af en række særskilte Datasamlinger herunder BBR og Ejerfortegnelsen. Datamængder er beskrevet i bilag 2 under beskrivelsen af OIS/AWS Registre som GST har distributionsansvar for Registre som GST har distributionsansvar for vedligeholder og leverer geodata

18 18 Opgave Antal/Kapacitet Navn Rolle Opgave Antal/Kapacitet Aktøren er master for geografiske Grunddata og har ansvaret for at levere opdaterede geodata til Datafordeleren Registre som GST har distributionsansvar for består af en række særskilte Datasamlinger herunder DAGI og Kort10. Datamængder er beskrevet i bilag 2 under beskrivelsen af Kortforsyningen. CVR CVR er Registeret for Grunddata om virksomheder i Danmark Aktøren er master for Grunddata om virksomheder og har ansvaret for at levere opdaterede virksomhedsdata til Datafordeleren Der findes ét autoritativt virksomhedsregister der indeholder fortegnelser over danske virksomheder med tilhørende data. Datamængder er beskrevet i bilag 2 Navn OIS/AWS Rolle Eksisterende Eksternt System, der distribuerer en række offentlige Grunddata: BBR SVUR ESR Matriklen PLAN OIS/AWS skal erstattes af Datafordeleren, hvilket er angivet i diagrammet med en stiplet pil. De Tjenester, der i fremtiden udstilles via Platformen, modtager data direkte fra Registrene, og den eksisterende OIS/AWS forventes herefter nedlagt. Opgave Aktøren varetager for nuværende distribution af ovennævnte offentlige Grunddata Antal/Kapacitet OIS/AWS og datamængder er beskrevet i bilag 2 Navn Kortforsyningen Rolle Eksisterende Eksternt System, der distribuerer geodata. Kortforsyningen skal erstattes af Datafordeleren, hvilket er angivet i diagrammet med en stiplet pil. De Tjenester, der i fremtiden udstilles via Platformen, modtager data direkte fra Registrene, og den eksisterende Kortforsyning forventes herefter nedlagt. Opgave Aktøren varetager for nuværende opgaven med at distribuere geodata Antal/Kapacitet Kortforsyningen og datamængder er beskrevet i bilag 2

19 19 Navn Rolle Opgave Antal/Kapacitet Navn Rolle Opgave Antal/Kapacitet Navn Rolle Opgave Antal/Kapacitet Navn Rolle Opgave Antal/Kapacitet Navn Rolle Opgave Antal/Kapacitet NemID Fællesoffentlig Eksternt System til digital autentifikation af personer Aktøren stiller autentifikationsservices til rådighed for offentlige løsninger, således at der er en entydig identifikation af den autentificerede person Der findes en logisk NemID, men er opsat i et driftssetup med flere fysiske instanser Offentlige fagsystemer Offentlige fagsystemer er Eksterne Systemer der understøtter offentlig sagsbehandling og hvor der anvendes autoritative Grunddata i sagsbehandlingen Aktøren henter Grunddata, der understøtter sagsbehandling, via Datafordeleren eller andre distributionsløsninger, der videredistribuerer Grunddata fra Datafordeleren Der findes mange offentlige fagsystemer statsligt, kommunalt og regionalt Offentlige portaler Offentlige portaler udstiller Grunddata eller anvender disse som en del af dataudstillingen. F.eks. borger.dk hvor person relaterede Grunddata kan tilgås af borgeren At hente autoritative Grunddata fra Datafordeleren Der findes en lang række af offentlige portaler der udstiller Grunddata Andre distributionsløsninger Sektor specifik distribution af Grunddata Distribution af Grunddata til sektorspecifikke formål og på et andet aftalegrundlag end Datafordelerens Begrænset antal Private anvendersystemer Private Dataanvendere er virksomheder og private personer, der anvender Grunddata til private formål eller i forretningsmæssigt regi At hente anvendte Grunddata fra Datafordeleren Mange

20 Svømmebanediagrammer De følgende diagrammer beskriver forskellige processer for Grunddata, hvor Systemet forventes at indgå. Svømmebanediagrammerne beskriver end-to-end processer, det vil sige håndteringen af Grunddata både før Grunddata overføres til og efter Grunddata hentes fra Systemet. Opdatering af Register beskriver den proces, hvorved Grunddata opdateres hos Registermyndigheden for derefter at blive opdateret i Systemet, hvorfra de opdaterede Grunddata distribueres til Dataanvendere. Hent online data beskriver den proces, hvorved Grunddata hentes via Tjenester.

21 21 Hent Filudtræk, prædefineret beskriver den proces, hvorved Grunddata hentes via prædefinerede Filudtræk. Hent Filudtræk, dataanvenderinitieret beskriver den proces, hvorved Grunddata hentes via Filudtræk som Dataanvendere selv bestiller. Hændelser beskriver processen, hvorved Grunddata distribueres via Hændelser.

22 22 Opdatering med opslag i data fra andet Register beskriver processen, hvorved et Register forespørger på Grunddata i et andet register. Bemærk at forespørgslen ikke viderestilles til Register2, da Grunddata distribueres via Datafordeleren også når det handler om Grunddata som et Register refererer til hos et andet Register. Et eksempel på en reference kan være en persons adresse. Personer vedligeholdes i CPR med reference til adresseobjekter som vedligeholdes i MBBL Register. CPR referer til adresseobjekter via Datafordeleren. Borger fremsøger egne data beskriver processen, hvorved en borger slår egne informationer op. Bemærk at opslaget sker på borgerportalen borger.dk, da Systemet ikke stiller Grafiske Brugergrænseflader for enkeltopslag til rådighed for hverken borgere eller virksomheder. Enkeltopslag understøttes altså via de eksisterende portalløsninger eller hjemmesider. I ovenstående eksempel handler det om borgeres opslag, men det kunne også være virksomhedsopslag understøttet på virksomhedsportalen Virk.dk.

23 23 Verificer/synkroniser beskriver processen, hvorved dataindholdet på Systemet verificeres via synkroniseringsforespørgsel hos et Register. Hvis der opdages inkonsistens i data vil en synkronisering af data blive igangsat. Processen kan igangsættes af en Administrator eller være en skeduleret proces på Systemet, og har til formål at sikre at Systemet altid indeholder opdaterede Grunddata Håndtering af datamodeller Datafordeleren skal distribuere Grunddata fra en række Registre og disse Grunddata vedligeholdes af forskellige Registermyndigheder under forskellig lovgivning. Der er derfor behov for, at Datafordeleren kan rumme flere uafhængige datamodeller og give mulighed for, at disse datamodeller kan kobles sammen i Systemet. Når Grunddata samtidig ikke kan forventes at forblive uændrede i struktur, og der også forventes at være behov for med tiden at tilføje yderligere Registre og definere Tjenester på tværs af disse, opstår et behovskompleks, som stiller særdeles høje krav til fleksibilitet i håndteringen af de interne datamodeller i Systemet og datamodellernes mapning til en overordnet informationsmodel. Nedenstående use cases har til formål at eksemplificere kompleksiteten af modelhåndteringen, samt den udstilling som Systemet skal understøtte: Use case 1 Generaliserede DAGI-data DAGI-data indeholder bl.a. polygoner for sogne. Når man betragter en visualisering af sogne for hele Danmark i en GIS-klient, er det ikke muligt at se alle detaljer i sognegrænserne. Her kan man derfor benytte generaliserede geometridata og opnå en god performance. WMS-tjenesten med DAGI-data er således konfigureret til at benytte data i målestoksforholdene 1: , 1: og 1: afhængig af zoomniveau i forespørgslerne. Data er generaliserede til de forskellige målestoksforhold og ligger i separate databasetabeller/-views. Use case 2 INSPIRE-data Matrikulære data er omfattet af INSPIRE-direktivet. Derfor udstiller GST Tjenester, der følger INSPIREs dataspecifikationer, sideløbende med de eksisterende Tjenester med matrikulære data. Der er derfor behov for at remodellere og berige data i Grunddatatjenester til brug i andre Tjenester.

24 24 Remodelleringen og berigelsen af Grunddata foretages ved hjælp af databaseviews og passende konfiguration af Datafordeleren. I databaseviews bliver matrikulære Grunddata beriget med Attributter beskrevet i INSPIREs dataspecifikationer. Derudover er WFS-serveren konfigureret til at udstille Grunddata efter XML-skemaer givet ved INSPIRE. Use case 3 Tværgående tjenester Forretningsobjekter er ofte ikke afgrænset til data fra et enkelt Register, men spænder over data fra flere Registre. Tjenester der udstiller forretningsobjekter skal derfor sammensætte data fra forskellige datamodeller men stadig levere data som et konsistent hele. Et eksempel er en komplet beskrivelse af en ejendom. Dette omfatter selve ejendommen, adressen for ejendommen, ejerinformation (persondata) plus en række andre Grunddata. Afhængig af Datamodel for de enkelte Registre skal der ske en Transformation eller remodellering, så data fremstår som et konsistent forretningsobjekt. Remodellering og Transformation foretages af den Tjeneste, der leverer Grunddata. Use case 4 Ejere af virksomheder i geografisk område Ud fra Grunddata skal der sammenstilles en adresseliste over virksomhedsejere, hvis virksomheder ligger i et bestemt geografisk område. Det kan være en kommune eller en geografisk polygon (spatial søgning). Dette samles ved at sammenstille CVR s adressedata for virksomheder med geodata for det valgte område, derefter at fremsøge ejerne af de virksomheder, der opfylder det geografiske krav og endeligt at finde Folkeregisteradresserne på listen over ejere Datafordeleren som distributionsplatform Datafordeleren ses som en fælles infrastrukturkomponent, der håndterer distributionen af Grunddata, hvor selve vedligeholdelsen af Grunddata uforandret skal ske i Registrene. Datafordeleren skal indeholde en spejlet og opdateret kopi af Grunddata fra de bagvedliggende Registre til distributionsformål alene. Med afsæt i de Grunddata, der skal distribueres af Datafordeleren, den forskellige natur af disse data, og de lov og reguleringsmæssige forhold der gælder for disse (f.eks. INSPIRE-direktivet for geodata), beskrives Datafordeleren logisk opbygget som et sæt af Basisinfrastruktur- og Platformskomponenter med en række Tjenester som overbygning herpå. Definition af Datafordeler som IaaS og PaaS for Registermyndigheder IaaS (Infrastructure as a Service), PaaS (Platform as a Service) og SaaS (Software as a Service) er begreber, der i stor udstrækning forbindes med cloud-baserede ydelser, og er blevet de facto betegnelser for bestemte grupperinger af Funktionalitet og typer af tilbudte ydelser. I kommunikationen omkring Systemet er i specifikationsforløbet anvendt begreberne IaaS og PaaS, men med en bredere betydning end den generelle cloud-anvendelse af samme begreber, hvorfor en mere detaljeret teknisk beskrivelse er nødvendig for at undgå misforståelser eller fejltolkninger. Der findes ikke nogen entydig og standardiseret definition på de forskellige as a service -begreber, men de ses ofte afbilledet lagdelt, hvor der tilbydes flere services med øget Funktionalitet, jo højere man kommer

25 25 op i lagene. Nedenstående figur er et illustrativt eksempel på lagdeling og beskrivelse af de enkelte lags indhold. NIST 2 har defineret 3 lag i en cloud baseret service 3, som er præsenteret i nedenstående figur. SaaS PaaS IaaS The capability provided to the consumer is to use the provider s applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., web-based ), or a program interface. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings Eksempel: Salesforce.com The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment Eksempel: Microsoft Azure The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications Eksempel: Amazon EC2 Figur 3 XaaS lagdeling I Datafordeler-konteksten, hvor der alene fokuseres på funktionalitet til distribution af Grunddata, er Infrastrukturplatform og Platform tillagt en bredere betydning end de gængse cloud-baserede IaaS og PaaS definitioner beskrevet ovenfor. Basisinfrastrukturen i Datafordeleren forventes at indeholde den Funktionalitet, som ovenstående IaaSdefinition omfatter, men herudover også: Operativsystem Basal kommunikationsfunktionalitet (f.eks. forskellige protokolunderstøttelser, SOAP-stak) Standard-middleware (f.eks. virus-beskyttelse, DoS-forsvar) Det vil sige en række af de basale services, der i cloud-terminologien vil være placeret i PaaS, forventes indeholdt i Datafordelerens Basisinfrastruktur, som vist i nedenstående figur. 2 National Institute of Standards and Technology er USAs officielle, nationale standardiseringsorganisation, se 3 The NIST Definition of Cloud Computing

26 26 Figur 4 Basisinfrastruktur og Basisplatform i Datafordeler Datafordeler-Basisplatform forventes at omfatte højniveau-funktionalitet fra en cloud-paas, men også de generiske datadistributionsfunktionaliteter, der er nødvendige for distribution af Grunddata, uanset typen eller naturen af Grunddata. Som eksempel kan nævnes Filudtræk, der både er administration og afsendelse af datafiler. Funktionalitet i Datafordeler-Basisplatform er beskrevet i punkt 2.5. Logisk opbygning af Datafordeler Basisinfrastruktur og Basisplatform Den logiske opbygning af Datafordeleren er illustreret i nedenstående figur. Den består af følgende: Geodataplatform Registerplatform Basisplatform Basisinfrastruktur Geodata Platform Register Platform Basis Platform Basisinfrastruktur Push Pull Figur 5 Logisk komponentopdeling Grunddataregistre

27 27 Datafordelerens Basisplatform er opdelt i to domænespecifikke dele. De kaldes Geodataplatform og Registerplatform. Baggrunden for denne opdeling er det faktum, at der stilles forskellige tekniske krav til applikationslaget, der skal understøtte distribution af geodata henholdsvis registerdata. Begrebsmæssigt kan der argumenteres for, at geometri (som er en af de grundlæggende egenskaber ved geografiske data sammen med et tilhørende referencesystem) blot er en attribut på et objekt. Ligeledes kan rasterbaserede geografiske data blot repræsenteres som et bitmap. Forskellen er, at geografiske data skal kunne stedbestemmes i forhold til et givet referencesystem. Datafordeleren skal derfor opfylde en række standarder, der gælder vedrørende geografiske data og geografiske referencenet. Typisk vil et applikationslag være specifikt designet til geografiske data og overholde de givne standarder. Adskillelsen af Registerplatform og Geodataplatform skal dog ikke ses som et krav, men mere ses som en indikation af forskellige applikationsbehov som de forskellige typer af data stiller. I de efterfølgende punkter, vil det fremgå, hvilke specielle krav og standarder, der skal opfyldes afhængig af, hvilke typer af data, der skal understøttes. Datafordelerens Basisplatform dækker over et applikationslag, der leverer Funktionalitet, der er uafhængigt af hvilken type data, der skal distribueres. Det kan f.eks. være brugerstyring. Datafordelerens fælles Basisinfrastruktur dækker, som beskrevet ovenfor, over f.eks. operativsystem, databaseservere, basal kommunikationsfunktionalitet mv. Den sidste del i den logiske opbygning af Datafordeleren er komponenter til dataudveksling og synkronisering med Registrene. Her kan der eksistere specifikke behov, der gør, at synkroniseringskomponenten skal skræddersys til de enkelte Registre. Datafordelerens kontekst Grunddata, der udstilles og vedligeholdes af Registrene eller udstilles af Datafordeleren, er kun en del af de data, der indgår i den offentlige sagsbehandling, hvorfor specielt Datafordeleren skal indplaceres i forhold til udstilling og vedligeholdelse af de mere sags- og fagspecifikke data. Dette er, ud fra en mere teknisk synsvinkel, illustreret i nedenstående figur, hvor Datafordeleren er indplaceret i forhold til de fagspecifikke service- og distributions-platforme. Figur 6 Relation mellem distributionsplatforme

28 Datafordelerens Funktionalitet Den Funktionalitet, der skal tilbydes af en fællesoffentlig Datafordeler, kan beskrives som sammensætning af en række logiske komponenter, hvor komponenterne kan kategoriseres i forhold til forretningsorienterede komponenter og mere infrastrukturrelaterede komponenter. Alle komponenter er kravsat som en del af Delleverance 0, Delleverance 2, Delleverance 3 eller Option 3 i underbilag 3.a.iii eller underbilag 3.a.iv Forretningsorienterede komponenter Komponent Accounting/Statistik Abonnement Administration af Datafordeler Selvbetjening/abonnent-initieret udtræk Tjenestehåndtering Datafordeler Basisinfrastruktur og Basisplatform komponenter Komponent Brugerstyring Autentifikation Adgang/Profiler håndtering Håndtering og distribution af Hændelser Filtrering Switchboard Service/forespørgsel validering Metadata Tjenestelag til datadistribution Fildistribution Datalag Opdatering af data i Datafordeler Skalering / performance Logning og monitorering Transformation Synkronisering med Registre

29 29 3. Underbilag 3a.ii: Generelle krav til Systemet 3.1. Læsevejledning Udover denne læsevejledning indeholder underbilag 3a.ii følgende punkter: Punkt 3.2 indeholder generelle og overordnede krav til Systemet. Punkt 3.3 indeholder ikke-funktionelle krav til Systemet, herunder krav til arkitektur, sikkerhed, fejlhåndtering samt lovgivningsmæssige og politiske krav Generelle krav til Systemet Indeværende punkt beskriver de overordnede forretningsmæssige krav til etableringen af den Fællesoffentlige Datafordeler. Der henvises til underbilag 3a.i for den overordnede forretningsmæssige baggrund for etableringen af Datafordeleren, herunder generelle principper for Datafordeleren. De i krav 3.1 overordnede krav understøttes af detaljerede og specifikke krav i underbilag 3a.ii, underbilag 3a.iii og underbilag 3a.iv. Kravnr. 3.1 Kravtitel Generelle krav til Datafordeler Kravtype MK Kravområde Generelle krav Delleverance DL0, DL2, DL3, O3 Kravbeskrivelse Datafordeleren effektiviserer datadistributionen i det offentlige, både ved at konsolidere eksisterende distributionsløsninger, men også ved at sikre, at der fremadrettet eksisterer en fælles platform, som andre offentlige data kan distribueres fra. Dermed understøtter Datafordeleren den fællesoffentlige digitaliseringsstrategi og grunddataprogrammet. Datafordeleren skal tilbyde følgende overordnede funktioner og services: For private og offentlige Dataanvendere: Skal levere Filudtræk i forskellige formater fra tilgængelige Grunddata Skal levere Online-opslag i relevante formater på tilgængelige Grunddata Skal levere beskeder omkring ændringer på dataentiteter, som Dataanvender har opsat abonnement på Skal levere adgang til opsætning af abonnement Skal levere adgang til at opsætte og konfigurere dataudtræk Skal levere metadatakatalog, hvor beskrivelser og dokumentation af Tjenester kan tilgås af Dataanvendere og Registermyndigheder Skal levere adgang, hvor Brugere kan registrere sig som Dataanvendere Skal levere adgang, hvor Dataanvenderes rettigheder kan vedligeholdes. Skal levere adgang til information, om status på Systemet som helhed og dens enkelte Tjenester, fx om de er tilgængelige For Registermyndighedens Administratorer: Skal levere logudtræk, der per Tjeneste (Filudtræk, Abonnement eller Onlineopslag), giver information om enkeltbrugers forbrug Skal levere logudtræk, der over en periode viser tilgængelighed af Systemets enkelte Tjenester

30 30 Skal levere adgang til konfiguration af og ændringer til Registermyndighedens Tjenester For opdateringer fra Registre Skal modtage eller hente opdateringer til enkelte Dataentiteter fra Registre, der leverer opdatering på entitetsniveau. Skal modtage eller hente fuldt udtræk fra Register med faste aftalte intervaller fra Registre, der leverer opdateringsudtræk Skal modtage eller hente ændringsfiler (deltafiler) med faste aftalte intervaller fra Registre, der leverer for ændringsudtræk Skal behandle og opdatere Grunddata i Datafordeleren på baggrund af alle ovenstående dataleverancer fra Registre. Driftsansvarlig og Kunden: Skal levere logudtræk, der over en periode viser tilgængelighed og anvendelse (antal tilgange og overførte datamængder) af enkelte og grupper af Tjenester Skal levere adgang til information både på forretnings- og teknikniveau, der understøtter monitorering Skal levere adgang til vedligeholdelse af brugere og rettigheder 3.3. Ikke-funktionelle krav Hvor funktionelle krav beskriver Funktionalitet, som Systemet skal stille til rådighed, beskriver ikkefunktionelle krav egenskaberne, hvormed Systemet leverer Funktionaliteten. Disse egenskaber skal forstås som karakteristika eller kvaliteter, som gør en løsning attraktiv for dets brugere og interessenter i form af fx pålidelighed, fleksibilitet, genbrugelighed og brugervenlighed. Ikke-funktionelle krav eksempelvis krav til brugervenlighed og svartider ændrer ikke Systemets Funktionalitet, men de kan være udslagsgivende for, om den bliver anvendt af de tiltænkte Brugere. Et andet eksempel er krav til lagdelt og modulær arkitektur, som umiddelbart ikke mærkes af Brugerne, men som er nødvendige for, at Systemet er fleksibelt og nem at vedligeholde.

31 Arkitekturkrav Arkitekturkravene tager udgangspunkt i Digitaliseringsstyrelsens anbefalinger vedrørende OIO Enterprise Arkitektur (OIO-EA 4 ), specifikt: Hvidbog om IT-arkitektur 5 (herefter: Hvidbogen) Overordnede principper og best practice 6 Dertil kommer relevante digitaliseringsstrategier, herunder den fællesoffentlige digitaliseringsstrategi 7 og den fælleskommunale digitaliseringsstrategi 8. Strategierne påvirker arkitekturprincipperne ved at prioritere disse indbyrdes. Kravnr. 3.2 Kravtitel Arkitekturprincipper for datadistribution Kravtype PK Kravområde Arkitektur, O3 Kravbeskrivelse Følgende principper for datadistribution skal overholdes af Systemet Data og objekter skal være tilgængelige Kvalitet og aktualitet af data skal være kendt Data skal være standardiserede og overholde fælles sprog og standarder for fælles objekter Datamodeller skal være åbne Dataansvar skal være klart og gennemskueligt Data skal udstilles på fælles infrastruktur Arkitekturen skal understøtte fleksible og tværgående arbejdsprocesser, eksempelvis udvikling af Tjenester af flere Registermyndigheder i samarbejde Systemet skal baseres på løst koblede komponenter Kravnr. 3.3 Kravtitel Indkapsling af Standardprogrammel Kravtype K Kravområde Arkitektur, O3 Kravbeskrivelse Såfremt der anvendes Standardprogrammel, der ikke er tilgængeligt under en Open Source-licens, skal Standardprogrammellet anvende en standardiseret Systemgrænseflade, der gør det muligt at erstatte Standardprogrammellet med andet tilsvarende programmel. Såfremt der ikke findes en standardiseret Systemgrænseflade til dette Standardprogrammel, skal der udvikles en særlig Systemgrænseflade til det pågældende Standardprogrammel, der indkapsler dette fra resten af Systemet og 4 OIO Enterprise Arkitektur: 5 IT- og Telestyrelsens (nu: Digitaliseringsstyrelsen) Hvidbog om arkitektur: 6 IT- og Telestyrelsens (nu: Digitaliseringsstyrelsen) principper og best practice for arkitektur: 7 Den Fællesoffentlige Digitaliseringsstrategi: 8 Den fælleskommunale digitaliseringsstrategi:

32 32 tillader senere udskiftning. Kravnr. 3.4 Kravtitel Anvend åbne standarder og fællesoffentlige standarder Kravtype PK Kravområde Arkitektur, O3 Kravbeskrivelse Systemet skal i videst muligt omfang anvende åbne standarder, jf. anbefalingerne herom fra Hvidbogen. Ved åbne standarder forstås, at definitionen af standarden er offentligt tilgængelig. Såfremt der findes åbne tekniske standarder (vedtagne eller faktiske) med stor udbredelse inden for de mulige løsninger, foretrækkes disse, frem for ikke-standardiserede løsninger. Basering på standarder øger muligheden for at erstatte Systemets komponenter, og øger vedligeholdelsesvenligheden. Dette krav gælder såvel interne systemsnitflader som eksterne snitflader til Registre, slutbrugere og andre. Kravnr. 3.5 Kravtitel Systemet bygges af løst koblede komponenter Kravtype K Kravområde Arkitektur, O3 Kravbeskrivelse Systemet er opbygget af løst koblede komponenter, der i granularitet mindst svarer til de i underbilag 3a.i beskrevne logiske komponenter. Kravnr. 3.6 Kravtitel Systemarkitektur Kravtype K Kravområde Arkitektur, O3 Kravbeskrivelse Leverandøren har i underbilag 3B beskrevet Systemets overordnede systemarkitektur, herunder hvilke Funktionaliteter, der leveres med Standardprogrammel og hvilke dele, der leveres som Kundespecifikt Programmel. [Tilbudsgiver skal i underbilag 3B beskrive Systemets overordnede systemarkitektur, herunder hvilke Funktionaliteter, der leveres med Standardprogrammel og hvilke dele, der leveres som Kundespecifikt Programmel]. Kravnr. 3.7 Kravtitel Anvend modne og velafprøvede teknologier Kravtype PK Kravområde Arkitektur, O3 Kravbeskrivelse Systemet skal i videst mulig omfang anvende modne og velafprøvede teknologier. Det vil sige, at afprøvede komponenter foretrækkes frem for nyere. Der lægges vægt på, at de teknologier, der anvendes, har været anvendt sammen på lignende måder tidligere, så den resulterende løsningsarkitektur samlet set kan dokumenteres at være moden. I underbilag 3B er beskrevet, hvor og hvordan, de i Projektet anvendte teknologier har været anvendt sammen tidligere, eller hvordan hensynet til modenhed tilgodeses på anden vis. [Tilbudsgiver skal i underbilag 3B angive, hvilke af de tilbudte teknologier og komponenter, som Tilbudsgiver er bekendt med, er blevet anvendt sammen tidligere

33 33 og i hvilke projekter. Der kan endvidere angives andet som understøtter modenheden af de tilbudte teknologier og komponenter] Kravnr. 3.8 Kravtitel Systemet er fleksibelt og interoperabelt Kravtype PK Kravområde Arkitektur, O3 Kravbeskrivelse Systemet skal være fleksibelt og interoperabelt, således at det kan interagere og samarbejde med andre systemer, jf. anbefalingerne herom fra Hvidbogen. Dette indebærer, at Systemet skal både modtage inddata og levere uddata i forskellige formater. Kravnr. 3.9 Kravtitel Uafhængighed af Registre Kravtype PK Kravområde Arkitektur, O3 Kravbeskrivelse Systemet skal være komplet afkoblet fra dens datakilder, såsom Registrene, således, at disse og Systemet kan opdateres og vedligeholdes uafhængigt af hinanden. Kravnr Kravtitel Fjernet Kravtype Kravområde Delleverance Kravbeskrivelse Krav er fjernet Kravnr Kravtitel Genbrug af fællesoffentlige komponenter Kravtype K Kravområde Arkitektur, O3 Kravbeskrivelse Eksisterende fællesoffentlige komponenter, eksempelvis til identifikation og brugerstyring, skal genanvendes i relevant omfang. Kravnr Kravtitel Heterogenitet og fleksibilitet Kravtype PK Kravområde Arkitektur, O3 Kravbeskrivelse Systemet skal opbygges tilstrækkeligt fleksibelt til, at tidssvarende teknologier kan udnyttes eksempelvis en blanding af public cloud og lokal lagring af data ligesom det i fremtiden skal være muligt at ibrugtage kommende teknologier hvis og når det af Kunden vurderes hensigtsmæssigt. Leverandøren har i underbilag 3B beskrevet grundlaget for at anse de anvendte teknologier som tidssvarende samt hvordan Systemets arkitektur understøtter, at de initialt anvendte teknologier vil kunne erstattes af andre teknologier på et senere tidspunkt. [Tilbudsgiver skal i underbilag 3B beskrive grundlaget for at anse de anvendte teknologier som tidssvarende samt hvordan Systemets arkitektur understøtter, at de initialt anvendte teknologier vil kunne erstattes af andre teknologier på et senere

34 34 tidspunkt.] Kravnr Kravtitel Overhold arkitekturkrav under drift Kravtype PK Kravområde Arkitektur, O3 Kravbeskrivelse Drift, vedligehold og videreudvikling af Systemet skal ske i overensstemmelse med arkitekturkravene Brugervenlighed, Look & Feel og tilgængelighed Alle offentlige it-systemer skal så vidt muligt være brugervenlige og tilgængelige for handicappede. Der stilles derfor krav om, at Systemets Grafiske Brugergrænseflader, såsom administrationsinterfaces, skal overholde best practice på disse områder. Kravnr Kravtitel Grafiske Brugergrænseflader i henhold til Best Practice Kravtype PK Kravområde Brugervenlighed, O3 Kravbeskrivelse Systemets Grafiske Brugergrænseflader skal være brugervenlige i overensstemmelse med aktuel best practice på området. Kravnr Kravtitel Handicaptilgængelighed Kravtype PK Kravområde Brugervenlighed, O3 Kravbeskrivelse Systemet skal overholde gældende fællesoffentlige krav til handicaptilgængelighed, herunder at Grafiske Brugergrænseflader skal overholde WCAG 2.0, niveau AA eller tilsvarende Sikkerhed Datafordeleren distribuerer Grunddata fra en række forskellige Registre til en bred vifte af offentlige og private Dataanvendere. Visse af disse Grunddata er af fortrolig eller personhenførbar karakter. Desuden vil hele Systemet have karakter af central infrastrukturkomponent. Det er derfor nødvendigt, at Systemet har et højt sikkerhedsniveau. Kravnr Kravtitel Hacking/Cyberangreb Kravtype PK Kravområde Sikkerhed Delleverance DL0, DL2, DL3, O3 Kravbeskrivelse Leverandøren skal levere sikring mod denial of service-angreb. Kravnr Kravtitel Adgangskontrolforanstaltninger Kravtype PK Kravområde Sikkerhed Delleverance DL0, DL2, DL3, O3 Kravbeskrivelse Leverandøren skal etablere, vedligeholde og dokumentere sikring af Systemet imod uvedkommende indtrængning. Sikringen skal blandt andet omfatte firewalls.

35 35 Kravnr Kravtitel IPS/IDS Kravtype PK Kravområde Sikkerhed Delleverance DL0, DL2, DL3, O3 Kravbeskrivelse Leverandøren skal implementere et intrusion protection system (IPS) og intrusion detection system (IDS) som overvåger ind- og udgående trafik med henblik på at opdage og modvirke uautoriseret anvendelse. Kravnr Kravtitel Inputvalidering Kravtype PK Kravområde Sikkerhed Delleverance DL0, DL2, DL3, O3 Kravbeskrivelse Alle input skal valideres for at forebygge fejl og angreb på Systemet så som bufferoverflow, URL-, form- og SQL-injections, Cross site scripting. Der skal foregå validering server side og valideringen skal være restriktiv, således at kun tilladte tegn accepteres. Kravnr Kravtitel Kryptering Kravtype K Kravområde Sikkerhed Delleverance DL0, DL2, DL3, O3 Kravbeskrivelse Persondata og evt. andre følsomme data skal være krypteret når de overføres internt i Systemet og ved integrationerne med Registrene. Leverandøren skal etablere sikring og kryptering af websteder, kommunikationslinjer samt sikre identifikation og kommunikation mellem offentlige myndigheder/portaler (eks. virksomhedscertifikater, NemID og SSL eller tilsvarende). Krypteringen skal overholde Datatilsynets anvisninger om stærk kryptering 9. Kravnr Kravtitel Beskrivelse af sikkerhedsforanstaltninger Kravtype PK Kravområde Sikkerhed Delleverance DL0, DL2, DL3, O3 Kravbeskrivelse De konkrete foranstaltninger, der skal opfylde kravene til sikkerhed, er beskrevet i underbilag 3B. [Tilbudsgiveren skal i underbilag 3B beskrive de konkrete sikkerhedsforanstaltninger, der implementeres for at sikre kravene til sikkerhed, krav 3.16 til krav 3.20.] Kravnr Kravtitel Opdeling Kravtype K Kravområde Sikkerhed Delleverance DL0, DL2, DL3, O3 Kravbeskrivelse Leverandøren har i underbilag 3B beskrevet, hvordan Systemet er opdelt med henblik på at minimere skadevirkning af sikkerhedshændelser og understøttelse af 9

36 36 afgrænsede brugeradgange (fx uafhængige zoner og miljøer). [Tilbudsgiveren skal i underbilag 3B beskrive hvordan Systemet er opdelt med henblik på at minimere skadevirkning af sikkerhedshændelser og understøttelse af afgrænsede brugeradgange (fx uafhængige zoner og miljøer).] Kravnr Kravtitel Fjernet Kravtype Kravområde Delleverance Kravbeskrivelse Krav er fjernet Kravnr Kravtitel Krypterede kanaler Kravtype K Kravområde Sikkerhed, O3 Kravbeskrivelse Platformen skal understøtte, at Tjenester kan opsættes til at kommunikere via krypterede kanaler. Kravnr Kravtitel Pålidelig levering Kravtype PK Kravområde Sikkerhed, O3 Kravbeskrivelse Systemet skal understøtte, at Tjenester kan konfigureres til at anmode Dataanvendere om kvittering for levering af dataleverancer. Systemet skal endvidere kunne håndtere sådanne kvitteringer, herunder skal det være muligt at fremsøge information om, hvorvidt der er modtaget en kvittering for en given dataleverance. Dette krav kan eksempelvis opfyldes ved understøttelse af OIORASP eller tilsvarende Fejlhåndtering Datafordeleren vil have mange forskellige Dataanvendere og anvendelsesformål, så fejlhåndtering og specielt fejlmeddelelser og tilhørende tekster er et område, hvor det er vigtigt, at de dels er velfungerende, dels i høj grad er selvforklarende for, hvordan en fejlsituation skal håndteres. En Dataanvender skal i stor udstrækning selv kunne identificere evt. forkert eller uhensigtsmæssig anvendelse af Datafordelerens Tjenester og implementere de nødvendige korrektioner på baggrund af den returnerede fejlmeddelelse. I det driftsmæssige perspektiv er robusthed overfor fejlsituationer vigtigt for Datafordeleren, således, at fejl for et område ikke påvirker øvrige områder og Grunddata i Datafordeleren. Eksempelvis skal datafejl i adresse- eller ejendomsdata ikke påvirke anvendelse og distribution af geodata, persondata og virksomhedsdata. Kravnr Kravtitel Fejltyper Kravtype PK Kravområde Fejlhåndtering, O3 Kravbeskrivelse Tjenester som udstilles på Systemet skal levere forklarende fejlmeddelelser og fejlkoder for de forskellige fejltyper, der kan opstå ved drift og anvendelse af Datafordeleren. Følgende overordnede fejltyper skal håndteres:

37 37 - Fejl pga. af forkert/uhensigtsmæssig anvendelse, f.eks. parametre til web service kald der resulterer i at geodata for hele landet utilsigtet skal returneres - Fejl pga. af forkerte parametre til Tjeneste - Fejl afledt af fejl i datamodel/tjenesteinterface - Driftsfejl i Basisinfrastruktur eller Basisplatform - Fejl i Registerplatform eller Geodataplatform Fejlmeddelelser og fejlkoder skal også understøtte anvendelse ved system-til-system kommunikation. Kravnr Kravtitel Robusthed Kravtype PK Kravområde Fejlhåndtering, O3 Kravbeskrivelse Opbygningen af Systemet skal sikre en høj grad af robusthed, bl.a. gennem anvendelse af løst koblede komponenter og services, så fejlsituationer håndteres bedst muligt, herunder at fejl vedrørende specifikke services eller fejl i afgrænsede data ikke har indflydelse på funktionsdygtighed af andre services eller for øvrige data i Datafordeleren. Med mindre der er tale om fatale fejl i grundlæggende komponenter, skal Datafordeleren kunne fortsætte med normal eller tilnærmelsesvis normal drift. Kravnr Kravtitel Logning af fejlsituationer Kravtype MK Kravområde Fejlhåndtering, O3 Kravbeskrivelse Alle fejl og fejlsituationer, der opstår i såvel Funktionalitet som Grunddata, skal logges i både produktions-, test- og udviklingsmiljøer. Afbrudte servicekald eller dataleverancer skal logges med angivelse af fejltype Kravnr Kravtitel Sigende fejlmeddelelser/tekster Kravtype K Kravområde Fejlhåndtering, O3 Kravbeskrivelse Alle kendte fejl skal have sigende fejlmeddelelser/tekster. Kravnr Kravtitel Sprog for fejlmeddelelser Kravtype K Kravområde Fejlhåndtering, O3 Kravbeskrivelse Fejlmeddelelser og fejltekster skal være på dansk eller engelsk. Kravnr Kravtitel Svartider i tilfælde af fejl Kravtype PK Kravområde Servicemål Kravbeskrivelse I tilfælde af fejl skal der returneres en sigende fejlmeddelelse indenfor 1 sekund.

38 Statistik og logning For at overholde krav til beskyttelse af personoplysninger 10, skal Systemet sikre sporing af hændelser, der er relevante for Systemets sikkerhed, herunder adgang til personhenførbare data. Systemet skal endvidere sikre, at det er muligt at foretage rapportering på Systemets performance og svartider, og at der er mulighed for at fakturere efter forbrug. Endelig skal Systemet sikre, at det er muligt at overvåge dette under normal operation, og afgøre om det fungerer indenfor normale driftsparametre. For at Systemet kan sikre opfyldelse af disse overordnede krav, skal der foretages logning i Systemet. Logning skal i udgangspunktet foretages af alle komponenterne med mindre en komponent specifikt undtages. Det er ikke tilstrækkeligt, at Systemet foretager logning. Systemet skal også understøtte, at informationer, der logges, kan gøres tilgængeligt for eksterne systemer Eksterne Systemer. Kravnr Kravtitel Logning af aktiviteter, afvigelser og sikkerhedshændelser Kravtype MK Kravområde Statistik og logning, O3 Kravbeskrivelse Systemet skal omfatte faciliteter, der sikrer at alle aktiviteter, afvigelser og sikkerhedshændelser kan logges og opbevares i en fastlagt periode af hensyn til opfølgning på adgangskontroller og eventuel efterforskning af fejl og misbrug. Dette gør sig gældende på feltniveau i den samlede løsning. Sikringsforanstaltningen skal omfatte alle brugertyper. Det fastlægges i hver afklaringsfase, hvilke aktiviteter, afvigelser og sikkerhedshændelser, der skal aktiveres logning af ved overtagelsen de pågældende Delleverancer. Logningen kan efterfølgende justeres via ændringshåndtering i henhold til Bilag 10. Kravnr Kravtitel Indhold af log Kravtype PK Kravområde Statistik og logning, O3 Kravbeskrivelse Brugerinitierede handlinger og systemmæssige hændelser skal logges med følgende log-data: - Dato, tidsstempel (UTC eller tilsvarende, så der mindst registreres timer, minutter, sekunder, tusindedels sekund) - Organisation/Bruger - IP-nummer - Den udførte handling inklusive evt. parametre - Nøgle på alle udtrukne data ved persondata - Tidsstempel for svar eller anden angivelse af svartid - Størrelse af svar - Evt. fejlkoder 10 Lov om behandling af personoplysninger, og tilhørende sikkerhedsbekendtgørelse,

39 39 Kravnr Kravtitel Logning af afviste adgangsforsøg Kravtype K Kravområde Statistik og logning, O3 Kravbeskrivelse Alle forsøg på adgang til persondata, som afvises af Systemet, skal logges i henhold til 8 i Sikkerhedsbekendtgørelsen 11. Kravnr Kravtitel Central og tidssynkroniseret log Kravtype K Kravområde Statistik og logning, O3 Kravbeskrivelse Logdata for Basisinfrastrukturen skal være tilgængelige et samlet sted og skal tidssynkroniseres, så de kan sammenholdes. Tilsvarende skal logdata for Platformen konsolideres et samlet sted og tidssynkroniseres indbyrdes samt med logdata for Basisinfrastrukturen. Kravnr Kravtitel Styret adgang til log Kravtype K Kravområde Statistik og logning, O3 Kravbeskrivelse Log skal være tilgængelig for Kunden, men adgang skal beskyttes gennem et brugerrettighedssystem. Dele af loggen skal efter aftale med Kunden gøres tilgængelige for 3. part. Adgang skal beskyttes gennem et brugerrettighedssystem. De nærmere forhold vedrørende, hvad der stilles til rådighed for hvilke grupper, aftales i afklaringsfaserne for de relevante Delleverancer. Kravnr Kravtitel Download af logdata Kravtype K Kravområde Statistik og logning, O3 Kravbeskrivelse Systemet skal omfatte Funktionalitet til, at logdata kan downloades. Kravnr Kravtitel Logdata udstilles på servicegrænseflade Kravtype K Kravområde Statistik og logning, O3 Kravbeskrivelse Logdata skal stilles til rådighed gennem et API, således, at log og statistikdata kan anvendes i mere brugervendte sammenhænge, f.eks. LIS-systemer og Dashboard der viser temperaturen på Datafordeleren lige nu. Kravnr Kravtitel Logning af tilgang til log Kravtype K Kravområde Statistik og logning, O3 Kravbeskrivelse Adgang til loggen eller udtrækning af data fra loggen skal logges, da loggen vil indeholde personhenførbare data. Kravnr Kravtitel Standardrapporter og rapportværktøj 11 BEK nr. 528 af 15/06/2000,

40 40 Kravtype K Kravområde Statistik og logning, O3 Kravbeskrivelse I Systemet skal der indgå værktøjer til behandling og filtrering af logdata og til definition og opsætning af standardrapporter. Det skal være muligt at generere grundlæggende statistik på baggrund af loginformation. Kravnr Kravtitel Prædefinerede standardrapporter Kravtype K Kravområde Statistik og logning, O3 Kravbeskrivelse Leverancen skal omfatte mindst fem kundedefinerede log-standardrapporter, der identificeres i den generelle afklarings- og planlægningsfase. Kravnr Kravtitel Fjernet Kravtype Kravområde Delleverance Kravbeskrivelse Krav er fjernet. Kravnr Kravtitel Konfigurerbart logniveau Kravtype K Kravområde Statistik og logning, O3 Kravbeskrivelse Det skal være muligt at konfigurere forskelligt log-/detaljerings-niveau for Systemets forskellige komponenter og udstillede Tjenester i overensstemmelse med øvrige krav til logning. Kravnr Kravtitel Log af faktureringsinformation Kravtype K Kravområde Statistik og logning, O3 Kravbeskrivelse Systemet skal foretage logning til faktureringsformål, således, at informationer om anvendelse af Datafordeleren registreres. Til faktureringsformål indgår data som antal servicekald, type af servicekald, datamængder (antal Entiteter og størrelse i bytes) og identifikation af Dataanvenderen. Kravnr Kravtitel Backup af log Kravtype PK Kravområde Statistik og logning, O3 Kravbeskrivelse Logdata, der ikke indeholder persondata, skal være tilgængelige i mindst 15 måneder efter, at de logges. Logdata, der indeholder persondata, skal være tilgængelige i 6 måneder efter, at de logges, og skal herefter slettes. For at sikre faktureringsgrundlag og øvrig sporbarhed, skal der dagligt tages backup af logdata.

41 Obligatoriske, åbne standarder for software i det offentlige Fra den 1. januar 2008 er syv sæt af åbne standarder obligatoriske at anvende for alle offentlige myndigheder: Standarder for dokumentudveksling (ODF/OOXML) Standarder for dataudveksling mellem offentlige myndigheder (OIOXML) Standarder til elektronisk sags- og dokumenthåndtering Standarder til elektroniske indkøb i det offentlige (OIOUBL) Standarder for digital signatur (OCES) Standarder for offentlige netsteder / hjemmesider og tilgængelighed (HTML/XHTML, CSS og WCAG) Standarder for it-sikkerhed (DS484 kun for staten) Disse standarder skal således også, hvor det er relevant, anvendes af Datafordeleren. Da Systemet ikke skal omfatte dokumentudveksling, sags- og dokumenthåndtering eller elektroniske indkøb, vurderes standarderne vedrørende ODF/OOXML, ESDH og OIOUBL ikke at være relevante for Systemet, men som det er kravsat andetsteds skal standarderne for it-sikkerhed, offentlige netsteder og digital signatur anvendes. Ligeledes vil standarderne for Sag og Dokument-området anvendes i relevant omfang, eksempelvis standarden for Organisation i relation til brugerstyring. Derudover skal standarden for dataudveksling (OIOXML) understøttes af Systemet. Kravnr Kravtitel Standard for dataudveksling Kravtype K Kravområde Standarder, O3 Kravbeskrivelse Systemet skal understøtte, at snitflader til Tjenester, som udbydes igennem Datafordeleren, kan udformes eller dokumenteres i OIOXML eller tilsvarende Lovmæssige og politiske krav De autoritative Grunddata og brugen af Grunddata er underlagt dansk lov og ret. Anvendelse og vedligehold af Grunddata er ligeledes specificeret og reguleret heri, hvorfor det er vigtigt, at Systemet og Projektet både overholder og understøtter dansk lovgivning. Kravnr Kravtitel Gældende dansk lovgivning Kravtype MK Kravområde Lovgivning Delleverance DL0, DL2, DL3, DL4, DL5, O1, O2, O3 Kravbeskrivelse Systemet og Projektet skal overholde gældende dansk lovgivning. Systemet og Projektet skal tilpasses anden relevant lovgivning efter anvisning fra Kunden. Kravnr Kravtitel Specifik lovgivning Kravtype MK Kravområde Lovgivning Delleverance DL0, DL2, DL3, DL4, DL5, O1, O2, O3 Kravbeskrivelse Systemet og Projektet skal specifikt overholde følgende lovgivning der bl.a. regulerer

42 42 de datasæt som Systemet distribuerer: - Persondataloven 12 - CPR-loven 13 - CVR-loven 14 - BBR-loven 15 - INSPIRE-loven 16 - PSI-loven Underbilag 3a.iii: Krav til Fastlagte Delleverancer 4.1. Læsevejledning Dette bilag indeholder udover denne læsevejledning de funktionelle krav til de Fastlagte Delleverancer. Underbilag 3a.iii omfatter følgende punkter: Punkt 4.2: Krav til Delleverance 0 Punkt 4.4: Krav til Delleverance 2 og Delleverance Delleverance 0: Basisinfrastruktur Nærværende punkt indeholder funktionelle krav til Datafordeler Basisinfrastruktur. For overordnet beskrivelse af Basisinfrastruktur, se underbilag 3a.i Frikøb af de autoritative Grunddata vil, grundet de ændrede økonomiske vilkår for anvendelse af disse data, aflede større brug og dermed krav om behov for større netværkskapacitet hvor data udstilles og distribueres. Kravet til tilgængelig båndbredde i produktionsmiljøet vil stige løbende i takt med at anvendelsen stiger og datamængder øges. Der henvises til bilag 2, for en beskrivelse af forventninger til stigningen i anvendelse og datamængder. Kravnr Kravtitel Stigende datamængder Kravtype PK Kravområde Basisinfrastruktur Delleverance DL0 Kravbeskrivelse Datamængder i Datafordeleren forventes at stige løbende over tid. I Bilag 2, punkt 4 Datamængder beskrives den forventede stigning i datamængder som skal understøttes og i bilag 7 er de servicemål Systemet skal opfylde specificeret. 12 LOV nr. 429 af 31/05/2000: Lov om behandling af personoplysninger, 13 LBK nr. 5 af 09/01/2013: Lov om Det Centrale Personregister, 14 LBK nr. 653 af 15/06/2006: Lov om Det Centrale Virksomhedsregister, 15 LBK nr. 160 af 08/02/2010: Lov om bygnings- og boligregistrering, 16 LOV nr af 19/12/2008: Lov om infrastruktur for geografisk information, 17 LOV nr. 596 af 24/06/2005: Lov om videreanvendelse af den offentlige sektors informationer,

43 43 De angivne mængder er alene udtryk for Kundens forventninger ved Kontraktindgåelsen og Systemet skal således om nødvendigt kunne håndtere skalering udover disse forventninger. Datalager skal udvides dynamisk i forhold til den nødvendige kapacitet og samtidig opfylde servicemål specificeret i bilag 7. Bodsmaksimering vedrørende servicemål er angivet i bilag 7. Kravnr Kravtitel Skalering af netværk og båndbredde Kravtype PK Kravområde Basisinfrastruktur Delleverance DL0 Kravbeskrivelse Netværk og båndbredde skal skaleres dynamisk i forhold til den faktiske anvendelse af Grunddata. Bilag 2 punkt 4 beskriver den forventede udvikling i anvendelse af Grunddata som skal understøttes. De angivne mængder er alene udtryk for Kundens forventninger ved Kontraktindgåelsen og Systemet skal således om nødvendigt kunne håndtere skalering udover disse forventninger. De autoritative Grunddata har en forskellig natur og afleder uensartede behov i forhold til systemmæssige ressourcer. Eksempelvis grundet de store datamængder Kortforsyningen arbejder med, er garanterede ressourcer en forudsætning for at kunne levere data i forhold til det krævede servicemål. Der henvises i øvrigt til bilag 2 hvor de eksisterende miljøer er beskrevet. Kravnr Kravtitel Dedikerede ressourcer Kravtype K Kravområde Basisinfrastruktur Delleverance DL0 Kravbeskrivelse Basisinfrastruktur skal tilbyde mulighed for at dedikere specifikke ressourcer som eksempelvis RAM, CPU-kraft eller båndbredde til udvalgte servere eller platforme så der er garanteret rådighed over disse. Kravnr Kravtitel Virtuelle og fysiske servere Kravtype K Kravområde Basisinfrastruktur Delleverance DL0 Kravbeskrivelse Basisinfrastruktur skal understøtte Platformen, både virtuelle servere og evt. fysiske servere, som et sammenhængende miljø, således at Basisinfrastrukturen uanset om en given funktionalitet understøttes af en virtuel eller evt. fysisk server opfylder de funktionelle behov som Platformen stiller til den underliggende infrastruktur. Udnyttelse af infrastrukturfunktionaliteten skal være transparent overfor valg af fysiske eller virtuelle servere, hvor det er performance og tuningsmæssige hensyn der er medvirkende årsag til valg, og at valg/placering kan ændres uden afledte ændringer

44 44 i opsætning og konfiguration af Platformen. Kravnr Kravtitel Multiple driftscentre Kravtype PK Kravområde Basisinfrastruktur Delleverance DL0 Kravbeskrivelse Basisinfrastrukturen skal implementeres med flere driftscentre, således, at al funktionalitet er dubleret på mindst to forskellige fysiske lokationer. Driftscentrene skal være fysisk separerede med en indbyrdes afstand på mindst 1 kilometer. Kravnr Kravtitel Fjernet Kravtype Kravområde Delleverance Kravbeskrivelse Kravet er fjernet Kravnr Kravtitel Fjernet Kravtype Kravområde Delleverance Kravbeskrivelse Kravet er fjernet Kravnr Kravtitel Adskilte udviklings-, test- og Produktionsmiljø Kravtype MK Kravområde Basisinfrastruktur Delleverance DL0 Kravbeskrivelse Leverandøren skal adskille udviklings-, test- og produktionsmiljø. Udviklingsmiljøet skal for Registerplatform og Geodataplatform være funktionelt identisk med driftsmiljøet, dog uden aktive integrationer til Registrene, og det skal stilles til rådighed for Kunden og 3.part efter aftale med Kunden. Testsystemet skal være etableret i et selvstændigt miljø og være en tro kopi af det færdige System (evt. i mindre dimensioner) for at muliggøre en realistisk afprøvning. Testsystemet vil også kunne benyttes til test af fejlrettelser, når Systemet er gået i drift. Testsystemet skal indeholde tilstrækkelige data til, at såvel funktionalitet som performance kan afprøves for nye Tjenester, Registre eller funktionaliteter, der etableres på Systemet. Det initiale omfang af testdata fastlægges i den generelle afklarings- og planlægningsfase og datamængderne kan efterfølgende justeres via processen for ændringshåndtering. Kravnr Kravtitel Optimal ressourceudnyttelse Kravtype K Kravområde Basisinfrastruktur Delleverance DL0 Kravbeskrivelse Basisinfrastrukturen skal opbygges så de tilgængelige ressourcer til enhver tid udnyttes optimalt, f.eks. gennem en load balancer.

45 45 Leverandøren har i underbilag 3B beskrevet, hvordan Basisinfrastrukturen håndterer kapacitetstilpasning. [Tilbudsgiver skal beskrive, hvordan Basisinfrastrukturen håndterer kapacitetstilpasning] Udviklere og andre leverandører af funktionalitet til Datafordeleren vil i udviklingsforløbet have behov for at afprøve foreløbige løsninger og gennemføre PoC på arkitekturændringer og nye teknologier. Dette skal foregå indenfor kontrollerede rammer, således at det kun er udvalgte brugere der har adgang til udviklingsog testmiljøerne. Kravnr Kravtitel Basisinfrastruktur bruger/rettighedsstyring Kravtype PK Kravområde Basisinfrastruktur Delleverance DL0 Kravbeskrivelse Basisinfrastruktur skal omfatte bruger/brugerrettighedsstyring, således at 3. part, udviklere, testere og andre leverandører kan tildeles adgang til udviklingsmiljøet på en måde, så de så vidt muligt kan arbejde uden at påvirke eller blive påvirket af andre udviklere, eksempelvis ved brug af sandboxing, samt tildeles adgang til testmiljø. Tildeling af rettigheder til udviklings- og testmiljø for 3. part sker efter forudgående aftale med Kunden. Kravnr Kravtitel Fjernet Kravtype Kravområde Delleverance Kravbeskrivelse Kravet er fjernet Kravnr Kravtitel Fjernet Kravtype Kravområde Delleverance Kravbeskrivelse Kravet er fjernet Kravnr Kravtitel Fjernet Kravtype Kravområde Delleverance Kravbeskrivelse Kravet er fjernet Kravnr Kravtitel Fjernet Kravtype Kravområde Delleverance Kravbeskrivelse Kravet er fjernet

46 46 Kravnr Kravtitel Fjernet Kravtype Kravområde Delleverance Kravbeskrivelse Kravet er fjernet Kravnr Kravtitel Fjernet Kravtype Kravområde Delleverance Kravbeskrivelse Kravet er fjernet Kravnr Kravtitel Fjernet Kravtype Kravområde Delleverance Kravbeskrivelse Kravet er fjernet Kravnr Kravtitel Fjernet Kravtype Kravområde Delleverance Kravbeskrivelse Kravet er fjernet Kravnr Kravtitel Fjernet Kravtype Kravområde Delleverance Kravbeskrivelse Kravet er fjernet Kravnr Kravtitel Fjernet Kravtype Kravområde Delleverance Kravbeskrivelse Kravet er fjernet Kravnr Kravtitel Fjernet Kravtype Kravområde Delleverance Kravbeskrivelse Kravet er fjernet 4.3. Delleverance 2 og 3: Platformens Funktionalitet Med Basisplatform menes den grundlæggende generelle distributionsfunktionalitet i Datafordeleren, som beskrevet i underbilag 3a.i. I det følgende kravstilles Funktionaliteten i Basisplatform, Geodataplatform og Registerplatform.

47 Delleverance 2 og 3: Generelle krav Kravnr Kravtitel Selvforsvar, syntaksvalidering samt fejlbeskeder Kravtype PK Kravområde Basisplatform Switchboard Kravbeskrivelse Systemet skal indbefatte et såkaldt switchboard, der beskytter de bagvedliggende registerdata og komponenter mod misbrug eller uhensigtsmæssige brugsmønstre. Hvis f.eks. indkomne forespørgsler efter forespørgselsanalyse viser tegn på misbrug (f.eks. et unaturligt stort antal gentagne ens forespørgsler fra samme IP-adresse) eller uhensigtsmæssigt brugsmønster (f.eks. hyppige totaludtræk fra et register) kan de afvises. Kravnr Kravtitel Forespørgselsanalyse og prioritering Kravtype PK Kravområde Basisplatform Switchboard Kravbeskrivelse Systemet skal analysere indkomne forespørgsler. Alle forespørgsler kategoriseres og dirigeres til bedst ledige ressourcer (intelligent load balancing). Forespørgselsanalysen er første trin i forespørgselsprioriteringen. Indkomne forespørgsler skal prioriteres efter forskellige kriterier: Tjenesters eller Grunddatas vigtighed Dataanvendere og Brugere Adfærd (og adfærdsmønstre) Grundlaget for forespørgselsprioritering er foruddefinerede regler. Kravnr Kravtitel Selvforsvar, afvisning af forespørgsler Kravtype PK Kravområde Basisplatform Switchboard Kravbeskrivelse Switchboardet sørger for, at forespørgsler håndteres ensartet, og at fejlbeskeder for de situationer, hvor en forespørgsel afvises, udformes ensartet uafhængigt af, hvilken type serverapplikation, der ligger bagved. På baggrund af analyse af indkomne forespørgsler skal omkostningstunge forespørgsler generelt afvises med sigende fejlbeskeder, der henviser til eventuelt tilsvarende Filudtræk. Grundlaget for afvisning af omkostningstunge forespørgsler er foruddefinerede regler. Kravnr Kravtitel Administration af switchboard Kravtype K Kravområde Basisplatform Switchboard Kravbeskrivelse Systemet skal indbefatte et API og en Grafisk Brugergrænseflade til konfiguration af reglerne, der danner grundlag for switchboardets håndtering af indkomne forespørgsler. Det skal være muligt at se en oversigt over alle definerede regler. Kravnr Kravtitel Administration af datakilder

48 48 Kravtype K Kravområde Basisplatform Administration af Datafordeler Kravbeskrivelse Systemet skal levere et API og en Grafisk Brugergrænseflade, som gør det muligt for Kunden at administrere hvilke Registre, der leverer data til Systemet. Det skal være muligt at oprette, redigere og slette Registre som datakilde til Datafordeleren. Administration omfatter også konfiguration af synkroniserings-mekanismer mellem Registre og Datafordeleren Delleverance 2 og 3: Krav til håndtering af datamodeller Kravnr Kravtitel Opsætning af datamodeller Kravtype PK Kravområde Basisplatform Administration af Datafordeler Kravbeskrivelse Datafordeleren skal kunne rumme flere uafhængige Datamodeller og give mulighed for, at disse Datamodeller kan kobles sammen i Systemet. Systemet skal levere et API og en Grafisk Brugergrænseflade til specifikation af datamodellerne, som data i Datafordeleren lagres i. Det kan både være grundlæggende datamodeller for kopier af data og remodellerede datamodeller for tjenestespecifikke og afledte data. Brugergrænsefladerne skal understøtte oprettelse, ændring og sletning af hele datamodeller såvel som objekter og attributter i modellerne. Kunden skal have adgang til at administrere datamodeller i Systemet, og 3. part herunder Registrene skal kunne gives adgang til at administrere visse datamodeller eller dele heraf. Systemet skal give mulighed for at remodellere data med henblik på at optimere performance og præsentation i tjenester. Systemet giver mulighed for at specificere brugerdefinerede indekser på data for at optimere performance og søgefunktionalitet i tjenester. Kravnr Kravtitel Konfiguration af Tjenester Kravtype PK Kravområde Basisplatform Administration af Datafordeler Kravbeskrivelse Systemet skal levere et API og en Grafisk Brugergrænseflade til konfiguration og opsætning af de Tjenester, der skal udstilles via Datafordeleren. Det kan f.eks. være opsætning af skema, samt hvilket dataformat, der skal leveres. Det skal være muligt at opsætte og aktivere nye Tjenester på Datafordeleren uden, at der skal programmeres moduler eller komponenter. Kravnr Kravtitel Sikring af konsistens Kravtype K Kravområde Basisplatform Administration af Datafordeler Kravbeskrivelse Det skal løbende sikres, at ændringer i Datamodeller eller Tjenester ikke påvirker andre Tjenester negativt. Denne sikring kan eksempelvis indebære konsistenschecks og notifikation af Kunden eller andre ved konstatering af problemer.

49 49 Leverandøren har i underbilag 3B beskrevet, hvordan Systemet understøtter dette, herunder evt. konsistenschecks ved opdateringer og hvordan Kunden notificeres ved konstatering af problemer. [Tilbudsgiver skal beskrive, hvordan Systemet håndterer sikring af, at ændringer i Datamodeller eller Tjenester udbudt via Systemet ikke har uhensigtsmæssige konsekvenser for andre Tjenester på Systemet. Dette kan eksempelvis indebære konsistenschecks og notifikation af Kunden eller andre ved konstatering af problemer] Delleverance 2 og 3: Skalering Driftsstabilitet og svartider er helt afgørende for en så central del af den offentlige it-infrastruktur, som Datafordeleren bliver. Da der samtidig er høje forventninger til minimering af ressourceforbrug og udgifter, vil der løbende skulle foretages justeringer af Systemets kapacitet. Dette behov underbygges af forventningen om væsentlige stigninger i anvendelsen målt i såvel antal udtræk som overførte datamængder, som beskrevet i Bilag 2 (punkt 4). Kravnr Kravtitel Applikations-skalering Kravtype PK Kravområde Basisplatform Skalering / performance Kravbeskrivelse Systemet skal automatisk kunne skalere sit applikationsslag ift. bestemte brugsmønstre og foruddefinerede regler, f.eks. højt træk på bestemte Tjenester. Systemet skal opskalere bestemte applikationer/tjenester, hvis det viser sig, at der i et givet tidsrum er behov for dette, eksempelvis skal der kunne etableres flere databaseinstanser efter behov. Systemet skal derudover automatisk deallokere ressourcer (applikationer/tjenester), når der ikke længere er brug for dem. For relevante servicemål samt information om bod og bodsmaksimering henvises til bilag 7 Kravnr Kravtitel Skaleringsinformation Kravtype K Kravområde Basisplatform Skalering / performance Kravbeskrivelse Systemet skal give løbende information om skalering, herunder hvor meget, kapaciteten er ændret med, og på hvilket grundlag skalering er foretaget. Information skal sendes til Kunden, jf. bilag 8. Kravnr Kravtitel Administration af skalering Kravtype K Kravområde Basisplatform Skalering / performance Kravbeskrivelse Systemet skal levere en Grafisk Brugergrænseflade samt API til konfiguration, opsætning og ændring af de regler, der ligger til grund for skaleringen. Det kan f.eks. være belastningsparametre.

50 Delleverance 2 og 3: Metadata Kravnr Kravtitel Håndtering af Metadata Kravtype K Kravområde Metadata Kravbeskrivelse Systemet skal lagre, håndtere og distribuere metadata. Metadata er informationer der beskriver data, datasæt og Tjenester og som gør det muligt at finde, registrere og bruge data/tjenester. For geodata, omfattet af INSPIRE direktivet, gælder der forordninger og vejledninger i forhold til metadata. Forordningen for metadata: F. Vejledningen for metadata: danmark.dk/nr/rdonlyres/5e0fb9ca-e611-45be-ab89- F1B7D191618D/0/INSPIREmetadatavejledningv1_0.pdf Kravnr Kravtitel Metadata beskrivelser Kravtype K Kravområde Metadata Kravbeskrivelse Systemet skal understøtte at både Grunddata og Tjenester kan dokumenteres så de opfylder formålet om at gøre det muligt at finde og bruge Grunddata/tjenester. Systemet skal lagre, håndtere og distribuere metadata og understøtter således Publish-Find-Bind paradigmet. Metadata er informationer der beskriver Grunddata, datasæt og Tjenester og som gør det muligt at finde, registrere og bruge data/ Tjenester. Kravnr Kravtitel Registry og Repository Kravtype K Kravområde Metadata Kravbeskrivelse Systemet skal indeholde både Registry og Repository Funktionalitet for metadata. Det skal endvidere være muligt at søge på metadata i metadatakataloget, samt redigere i metadata (CRUD-funktionalitet), herunder redigere i metadatabeskrivelser. Systemet skal stille en Grafisk Brugergrænseflade og API til rådighed for dette. Kravnr Kravtitel Metadata tilgængelighed Kravtype K Kravområde Metadata Kravbeskrivelse Systemet skal håndtere metadata på en brugervenlig og tilgængelig måde.

51 51 Metadata skal udstilles via webservices efter gængse standarder. Metadata omfatter specifikke metadata om Grunddata, Tjenester og Systemet, herunder snitfladen fra Datafordeler mod Registre Kravnr Kravtitel Metadata tilgængelighed geodata Kravtype MK Kravområde Metadata Delleverance DL3 Kravbeskrivelse For metadata om geodata skal følgende vejledning følges ved udstilling af geodata: Technical Guidance for the implementation of INSPIRE Discovery Services ( overyservices_v3.0.pdf) Denne vejledning bygger på følgende standard: CSW Catalogue Service (version 2.0.2) http ://portal.opengeospatial.org/files/?artifact_id=20555 Kravnr Kravtitel Metadata model Kravtype K Kravområde Metadata Kravbeskrivelse Systemet skal tillade fleksible modeller for metadata, således at flere forskellige standarder for metadata kan understøttes. Systemet skal indeholde en Grafisk Brugergrænseflade og et API som sætter Kunden i stand til at vedligeholde metadatamodellerne. Den Grafiske Brugergrænseflade og APIet skal understøtte oprettelse, nedlæggelse og redigering af metadatamodeller, herunder såvel tilføjelse som fjernelse af objekter og attributter Delleverance 2 og 3: Fildistribution Systemet skal stille Grunddata til rådighed på flere måder, herunder distribution af filer som indeholder specificerede Filudtræk. Data skal distribueres såvel ved Push fra Systemet som Pull fra Dataanvenderne, og Systemet bør som udgangspunkt understøtte alle gængse formater og protokoller, således at det ikke er Datafordeleren der sætter begrænsninger for anvendelsen af Grunddata. Kravnr Kravtitel Understøttelse af gængse protokoller Kravtype MK Kravområde Fildistribution Kravbeskrivelse Systemet skal understøtte alment anvendte protokoller til Fildistribution, herunder mindst FTP, SFTP/SSH, FTPS/SSL, HTTPS/SSL, SMTP eller tilsvarende. Kravnr Kravtitel Push distribution Kravtype K Kravområde Fildistribution Kravbeskrivelse Systemet skal understøtte, at Filudtræk periodisk og automatisk fremsendes til Dataanvendere.

52 52 Kravnr Kravtitel Notifikation til dataabonnenter Kravtype K Kravområde Fildistribution Kravbeskrivelse Systemet kan levere notifikationer til Dataanvendere når der er nye Filudtræk tilgængelige for dem. Notifikation kan f.eks. publiceres som RSS- eller ATOM feeds. Kravnr Kravtitel Prædefinerede og parameteriserede udtræk Kravtype PK Kravområde Fildistribution Kravbeskrivelse Systemet kan konfigureres med prædefinerede Filudtræk. Der skal for de definerede Filudtræk kunne angives parametre som kan afgrænse udtrækket, såsom geografisk område eller andre registreringer i data. Kravnr Kravtitel Kundespecifikke parametre Kravtype PK Kravområde Fildistribution Kravbeskrivelse Systemet skal lagre og håndtere kundespecifikke parametre såsom lister over Dataentiteter (personer, ejendomme, virksomheder osv.) som der abonneres på. Kravnr Kravtitel Administration af kundespecifikke parametre Kravtype PK Kravområde Fildistribution Kravbeskrivelse Systemet skal indeholde en Grafisk Brugergrænseflade og API til vedligeholdelse af parametre såsom en mængde af personer, som der abonneres på ændringer til. Kravnr Kravtitel Arkivering Kravtype K Kravområde Fildistribution Kravbeskrivelse Systemet skal arkivere Filudtræk i en periode som angives for det enkelte Filudtræk, således, at eksempelvis ejendomsudtræk opbevares i længere tid end personudtræk. Kravnr Kravtitel Oprydning i arkiv Kravtype K Kravområde Fildistribution Kravbeskrivelse Systemet skal omfatte mekanismer til automatisk og manuel oprydning i de lagrede arkiverede Filudtræk, herunder sletning af forældede arkiverede Filudtræk. Kravnr Kravtitel Understøttelse af gængse formater Kravtype PK Kravområde Fildistribution Kravbeskrivelse Systemet skal understøtte alment anvendte formater for Filudtræk, herunder CSV/TSV, XML, JSON, GML eller tilsvarende.

53 53 Ligeledes skal Systemet understøtte forskellige tegnsæt (UTF-8, UTF-16, ASCII osv.). Kravnr Kravtitel Understøttelse af gængse formater Geodata Kravtype PK Kravområde Geodataplatform Delleverance DL3, DL5 Kravbeskrivelse For distribution af geodata skal Systemet understøtte de formater og projektioner der er angivet i Tabel 1 og Tabel 2 eller tilsvarende. Versionsnumre refererer til de sidst publicerede ved udsendelse af udbudsmateriale, men nyeste version er gældende, og endelig præcisering af versionsnumre fastlægges i den generelle afklarings- og planlægningsfase. Tabel 1 og Tabel 2 er en del af dette krav. Kravnr Kravtitel Konfiguration af tiling-skemaer Kravtype K Kravområde Geodataplatform Servicelag til datadistribution Delleverance DL3 Kravbeskrivelse Systemet skal understøtte konfiguration af tiling-skemaer. Tiling-skemaer er specifikke for kortdata (geodata). Tabel 1 Overblik over (geo)specifikke formater, der skal understøttes ved distribution af geodata. Baseret på nuværende understøttelse af formater samt planlagte fremtidige. Tabellen er en del af krav WCS WMS/ WMTS WFS Geonøgler Fildistribution X X X X X X X X X X X MapInfo TAB Esri Shape DSFL Caris ntx Autocad DXF Autocad DWG Geomedia Access Ascii Grid Esri Fil geodatabase Microstation DGN (V7,V8) Lidar, LAS (for punktsky højdedata) (Geo)Tiff X X KML X (Geo)JSON X JSONP X GML (ver til 3.2.1) X X X PNG X JPEG X

54 54 ECW X X CADRG (militært raster format) X Note: WCS kan kun understøtte enkelte GML formater Note: Geonøgler betegner tjenester, der svarer til og kan erstatte de nuværende geonøgler i Kortforsyningen Tabel 2 Overblik over projektioner der skal understøttes ved distribution af geodata. Baseret på nuværende understøttelse af projektioner samt planlagte fremtidige. Tabellen er en del af krav WCS WMS/ WMTS WFS Geonøgle r Fildistribution epsg:25832 UTM Zone 32 etrs89 X X X X X epsg:23032 UTM Zone 32 ed50 X epsg:32632 UTM Zone 32 wgs84 X X X epsg:25833 UTM Zone 33 etrs89 X X X X epsg:23033 UTM Zone 33 ed50 X epsg:32633 UTM Zone 33 wgs84 X X X epsg:4093 DKTM1: Vestlige Jylland X X X X epsg:4094 DKTM2: Østlige Jylland og Fyn X X X X epsg:4095 DKTM3: Sjælland X X X X epsg:4096 DKTM4: Bornholm X X X X ej oprettet i epsg System 34: Jylland X ej oprettet i epsg System 34: Sjælland X ej oprettet i epsg System 34: Bornholm X epsg:2196 Kortprojektion 2000 Jylland X epsg:2197 Kortprojektion 2000 Sjælland X epsg:2198 Kortprojektion 2000 X Bornholm epsg:4230 Geografisk ed50 X epsg:4326 Geografisk wgs84 X X X epsg:4258 Geografisk etrs89 X X X epsg:3395 World Mercator (WGS 84) X epsg:3857 Pseudo Mercator (WGS 84) X X X epsg:32629 UTM Zone 29 wgs84 X X (Færøerne) epsg:23029 UTM Zone 29 ed50 X X X (Færøerne) epsg:25828 UTM Zone 28 etrs89 X X X (Færøerne) epsg:25829 UTM Zone 29 etrs89 X X X (Færøerne) epsg:25830 UTM Zone 30 etrs89 X X X (Færøerne) epsg:32624 UTM Zone 24 wgs84 X X (Grønland) epsg:3178 UTM Zone 18 gr96 (Grønland) X X

55 55 epsg:3179 UTM Zone 19 gr96 (Grønland) X X epsg:3180 UTM Zone 20 gr96 (Grønland) X X epsg:3181 UTM Zone 21 gr96 (Grønland) X X epsg:3182 UTM Zone 22 gr96 (Grønland) X X epsg:3183 UTM Zone 23 gr96 (Grønland) X X epsg:3184 UTM Zone 24 gr96 (Grønland) X X epsg:3185 UTM Zone 25 gr96 (Grønland) X X epsg:3186 UTM Zone 26 gr96 (Grønland) X X epsg:3187 UTM Zone 27 gr96 (Grønland) X X epsg:3188 UTM Zone 28 gr96 (Grønland) X X epsg:3189 UTM Zone 29 gr96 (Grønland) X X EPSG:3571 North Pole LAEA Bering Sea X (X) EPSG:3572 North Pole LAEA Alaska X (X) EPSG:3573 North Pole LAEA Canada X (X) EPSG:3574 North Pole LAEA Atlantic X (X) EPSG:3575 North Pole LAEA Europe X (X) EPSG:3576 North Pole LAEA Russia X (X) Note: Tiling skemaer til WMTS er på nuværende tidspunkt kun lavet for epsg:3857 og epsg: Med epsg:3857 menes den officielle epsg-kode for Web Mercator og epsg: Note: Geonøgler betegner tjenester, der svarer til og kan erstatte de nuværende geonøgler i Kortforsyningen Delleverance 2 og 3: Services og transformation Kravnr Kravtitel Tjenester Kravtype PK Kravområde Register- servicelag til datadistribution Kravbeskrivelse Det skal være muligt at definere og udstille Tjenester på servicelaget. For registerdata skal følgende servicesnitflader eller tilsvarende understøttes: - SOAP, herunder WSDL - REST, herunder WADL og RSDL - RESTful webservices, herunder URL/CGI parametre For hver enkelt Tjeneste skal det være muligt at etablere parameterstyret filtrering, så der eksempelvis kan hentes data fra en given kommune eller en liste af virksomheder. Kravnr Kravtitel Tjenester Kravtype PK Kravområde Geodataplatform Servicelag til datadistribution Delleverance DL3, DL5 Kravbeskrivelse Det skal være muligt at definere og udstille Tjenester på servicelaget. For geodata skal følgende servicesnitflader eller tilsvarende understøttes (versionsnumre refererer til de sidst publicerede ved udsendelse af udbudsmateriale, men endelig præcisering af versionsnumre og eventuelle Conformance Classes

56 56 fastlægges i afklaringsfasen for Geodataplatformen, Delleverance 3): Web Feature Service version Web Map Service version o Styled Layer Descriptor version o Filter Encoding version Web Map Tile Service version Web Coverage Service version Krav til bindings: For WFS skal HTTP GET og HTTP POST som minimum understøttes. For WMTS skal HTTP GET med KVP og RESTful encodings som minimum understøttes. For data omfattet af INSPIRE skal følgende vejledninger ligeledes følges: Technical Guidance for the implementation of INSPIRE View Services Technical Guidance for the implementation of INSPIRE Download Services Leverandøren skal opdatere Tjenester i overensstemmelse med bilag 6, krav Kravnr Kravtitel Versionering Kravtype K Kravområde Register- og Geodataplatform Servicelag til datadistribution Kravbeskrivelse Systemet skal håndtere versionering af Tjenester på en konsistent måde, så Dataanvendere kan have vished for, at de anvender den korrekte version af en Tjeneste. Det er i underbilag 3B beskrevet, hvordan Systemet håndterer versionering af Tjenester. [Tilbudsgiver skal i Underbilag 3B beskrive, hvordan Systemet håndterer versionering af Tjenester]. Kravnr Kravtitel Transformation Kravtype K Kravområde Transformation Kravbeskrivelse Systemet skal understøtte transformation af data til foruddefinerede formater som specificeret af Administratorer for de enkelte Tjenester.

57 Delleverance 2 og 3: Brugerstyring Datafordeleren distribuerer Grunddata fra en række forskellige Registre til en bred vifte af offentlige og private Dataanvendere, hvorfor der er behov for en nem og intuitiv brugerstyring, der samtidig ikke kræver en stor administrativ indsats at vedligeholde. Da mange Brugere af Datafordeleren er offentlige virksomheder, er det vigtigt at der er et velfungerende samspil og integration til de fællesoffentlige løsninger på dette område, og at disse udnyttes optimalt af Systemet. Brugerstyring omfatter administration af de Brugere som skal oprettes som navngivne Brugere i forhold til Datafordeleren, herunder system til system kommunikation. Brugerstyring inkluderer også oprettelse og nedlæggelse af Brugere samt tildeling af rettigheder til både Tjenester samt dataobjekter. Rettigheder tilknyttes til Brugere gennem en rollebaseret model, således at den specifikke sikkerhedspolitik og rettighed ikke tilknyttes en dedikeret Bruger, men derimod en rolle der kan tildeles en Bruger. En specifik Bruger kan være tildelt flere forskellige roller. Kravnr Kravtitel Rollebaseret rettigheder Kravtype PK Kravområde Brugerstyring Kravbeskrivelse Brugerrettigheder skal være rollebaseret og følge RBAC. Systemet skal understøtte at et rollehierarki kan oprettes og redigeres. Kravnr Kravtitel Brugeradministrationsmodul Kravtype K Kravområde Brugerstyring Kravbeskrivelse Systemet skal indeholde Funktionalitet til at administrere Brugere, herunder oprette, ændre, spærre/åbne og nedlægge Brugere. Modulet skal styre: Brugerrettigheder baseret på roller Relationer imellem Brugere og organisationer i overensstemmelse med Sag og Dokument-standarden for Organisation eller tilsvarende Brugerprofiler for Administratorer Kravnr Kravtitel Brugerprofiler Kravtype PK Kravområde Brugerprofiler Kravbeskrivelse Systemet skal håndtere brugerprofiler (typiske Brugere) Registermyndigheder skal kunne definere profiler. Der skal sikres at adgang til Grunddata sker i overensstemmelse med tildelt profil Der kan leveres unikke Tjenester til bestemte profiler (eksempel Valgudtræk). En profil kan beskrive adgang til objekter, geografiske områder (polygoner), Tjenester/datasæt, tid (med og uden historik). Kravnr Kravtitel Profil Bruger relation Kravtype K Kravområde Brugerprofiler

58 58 Kravbeskrivelse Profiler kan samles til et standard sæt der default tildeles til en ny Bruger. Der kan knyttes flere profiler til en Bruger. En profil/rolle kan knyttes til en eller flere Brugere. Kravnr Kravtitel Rettigheder tildelt roller Kravtype PK Kravområde Brugerstyring Kravbeskrivelse Roller kan tildeles rettigheder på følgende niveauer: - Tjenester - Dataentiteter - Attributter - Lag (WMS) Det er muligt at tildele rettigheder på et defineret og afgrænset geografisk område/areal. Der kan eksempelvis være tale om rettigheder til data om personer i en bestemt kommune eller kort over et bestemt område. Geografisk afgrænsning skal kunne angives på baggrund af DAGI områder (polygoner). Hvordan dette konkret håndteres, er beskrevet i underbilag 3B. [Tilbudsgiver skal beskrive hvordan Systemet understøtter den geografiske afgrænsning] Kravnr Kravtitel Selvbetjening af brugeroprettelse Kravtype K Kravområde Brugerstyring Kravbeskrivelse Systemet skal indeholde Funktionalitet til at Brugere kan oprette sig selv og tilknytte deres NemID til den oprettede bruger-id. Kravnr Kravtitel Forespørgsel om adgang til data Kravtype K Kravområde Brugerstyring Kravbeskrivelse Systemet skal indeholde mulighed for at oprettede Brugere kan anmode om adgang til data der ikke er frit tilgængeligt. Advisering om anmodning skal sendes til Kunden. Kravnr Kravtitel System til system kommunikation Kravtype MK Kravområde Brugerstyring Kravbeskrivelse Systemet skal understøtte brugere for system til system kommunikation. Kravnr Kravtitel Ikke-danske Brugere Kravtype MK Kravområde Brugerstyring

59 59 Kravbeskrivelse Brugerrettighedsfunktionaliteten skal understøtte både danske og ikke-danske Brugere, herunder EU-institutioner og andre landes myndigheder. Kravnr Kravtitel Typer af Brugere Kravtype PK Kravområde Brugerstyring Kravbeskrivelse Brugerrettighedsfunktionaliteten skal understøtte, at Brugere kan være personer, organisationer eller medarbejdere i organisationer. Kravnr Kravtitel Tidsbegrænsede Brugere Kravtype K Kravområde Brugerstyring Kravbeskrivelse Der kan oprettes midlertidige Brugere, der i en periode kan tildeles adgang til hele eller dele af Systemet med administrationsadgang opdelt på læserettighed henholdsvis læse/skriverettighed. Tidsbegrænsede Brugere kan kun oprettes efter aftale med Kunden. En tæt relateret Funktionalitet til brugerstyring er autentifikation af de Brugere der tilgår Datafordeleren. Autentifikation understøtter login og validering af de medsendte brugerakkreditiver for korrektheden af disse, samt udstedelse af sikkerhedstoken der benyttes til den efterfølgende autorisation på de sikkerhedshåndhævelsespunkter der er defineret i Datafordeleren. Autentifikationsfunktionaliteten udfører ikke autorisation, men opretter grundlaget for dette. Kravnr Kravtitel Understøttede akkreditiver Kravtype PK Kravområde Autentifikation Kravbeskrivelse Autentifikation kan ske med følgende akkreditiver: - Ingen akkreditiver - Brugernavn/password - Certifikat (eksempelvis FOCES eller tilsvarende) - Token (Ticket) - OIOSAML token eller tilsvarende - NemID Ikke alle typer akkreditiver kan anvendes til alle Systemets komponenter. For geodata skal det være muligt for gængse desktop GIS-klienter (fx ArcGIS, GeoMedia, MapInfo, AutoCAD MAP, Gaia, udig, QGIS eller tilsvarende) og webbaserede løsninger (fx baseret på OpenLayers, VisStedet, VisKort eller tilsvarende) at medsende akkreditiver i forespørgsler, således at Systemets servicesnitflader kan erstatte Kortforsyningens nuværende servicesnitflader, der fx kan tilgås med brugerakkreditiver som parametre i HTTP-forespørgsler. Kravnr Kravtitel Server certifikater Kravtype PK Kravområde Autentifikation

60 60 Kravbeskrivelse Systemet skal understøtte autentifikation af server certifikater i form af FOCES eller tilsvarende. Kravnr Kravtitel Adgang med godkendte akkreditiver Kravtype PK Kravområde Autentifikation Kravbeskrivelse Kun brugere med godkendte akkreditiver skal tildeles adgang, hvor der kræves autorisation. Kravnr Kravtitel Password reset Kravtype K Kravområde Brugerstyring Kravbeskrivelse Systemet skal indeholde Funktionalitet til at Brugere selv kan nulstille deres password. Denne Funktionalitet skal omfatte mekanismer, der sikrer, at det kun er brugerid ets ejer, der kan nulstille password. Kravnr Kravtitel Password regler Kravtype K Kravområde Brugerstyring Kravbeskrivelse Systemet skal understøtte opsætning af regler for valide password, f.eks. længde, og understøtte best practice for password regler. Kravnr Kravtitel Sigende fejlkoder Kravtype K Kravområde Autentifikation Kravbeskrivelse Ikke godkendte akkreditiver skal afvises med en entydig og sigende fejlkode Delleverance 2 og 3: Opdatering af Datafordeler Datafordeleren vil modtage fulde opdateringer og delopdateringer af Grunddata fra Registrene. For at sikre, at delopdateringer ikke resulterer i, at Datafordeleren ikke længere indeholder en korrekt datamæssig afspejling af Grunddata fra Registeret, er der behov for synkroniseringsfunktionalitet, der kan detektere uoverensstemmelser og håndtere udbedringer af disse. Erfaringen viser, at der ved del- eller deltaopdateringer af ændringer over tid vil opstå inkonsistens mellem Registeret og den kopi, der opdateres. Da Datafordeleren omfatter store datamængder, hvor det ikke praktisk er muligt at gennemføre en opdatering med en fuld kopi af alle Grunddata, er der behov for Funktionalitet til at sikre konsistens mellem Datafordeleren og de respektive Registre. Dynamikken og opdateringsfrekvens varierer meget for de forskellige Grunddata, hvilket synkroniseringsfunktionaliteten skal understøtte, således at der fokuseres på ændrede data. F.eks. batchopdateres afledte topografiske data områdevist. Kravnr Kravtitel Aktualitet af data Kravtype PK Kravområde Opdatering af Datafordeler

61 61 Kravbeskrivelse Opdatering af Grunddata i Datafordeler skal som udgangspunkt gennemføres uden forsinkelse når opdateringer eller ændringer modtages Kravnr Kravtitel Transformation Kravtype PK Kravområde Opdatering af Datafordeler Kravbeskrivelse Datafordeleren skal transformere modtagne Grunddata fra den modtagne struktur og format til Datafordelerens interne datamodel for de forskellige datakilder Kravnr Kravtitel Typer af data Kravtype PK Kravområde Opdatering af Datafordeler Kravbeskrivelse Datafordeleren skal håndtere opdateringer af mindst følgende typer af data: - Grunddata - Metadata Kravnr Kravtitel Datafordelerhistorik Kravtype PK Kravområde Opdatering af Datafordeler Kravbeskrivelse Datafordeleren skal vedligeholde historik på entitetsniveau, for hvornår en Dataentitet er opdateret i Datafordeleren. Bitemporale egenskaber for Dataentiteter vedligeholdes af Registreret Kravnr Kravtitel Validering af modtagne data Kravtype PK Kravområde Opdatering af Datafordeler Kravbeskrivelse Datafordeleren skal modtage information der muliggør en validering af, at modtagne Grunddata svarer til de data, der er registreret i Registeret, om at alle Grunddata er modtaget og om der er sket forvanskninger af Grunddata. Datafordeleren skal også validere modtagne Grunddata for overholdelse af det aftalte dataformat, der anvendes ved opdatering. Er der fejl eller mangler i data skal dataleverancen håndteres så fejl ikke påvirker de udstillede Grunddata. Fejlhåndteringen skal sikre integritet mellem Register og Systemet. Kravnr Kravtitel Minimal påvirkning af distribution Kravtype K Kravområde Opdatering af Datafordeler Kravbeskrivelse Opdatering af data i Datafordeler skal gennemføres uden at påvirke performance for distributionen af Grunddata. Kravnr Kravtitel Fuld og/eller del opdateringer Kravtype PK Kravområde Opdatering af Datafordeler Kravbeskrivelse Opdatering af data i Datafordeleren skal understøtte, at der kan modtages fulde

62 62 datasæt samt delopdateringer, hvor delopdateringer kan være på Dataentitetsniveau og omfatte specifikke instanser af en eller flere entiteter. Kravnr Kravtitel Synkronisering med Register Kravtype PK Kravområde Opdatering af Datafordeler Kravbeskrivelse Datafordeleren skal omfatte Funktionalitet der kan validere og synkronisere data i Datafordelen med Registeret, så der sikres konsistens mellem data i Datafordeleren og Registeret. Kravnr Kravtitel Opdatering ved fejl eller mangler Kravtype K Kravområde Opdatering af Datafordeler Kravbeskrivelse Synkroniseringsfunktionaliteten kan initiere en fuld eller del-opdatering, hvis der identificeres fejl eller mangler i data fra et Register. Kravnr Kravtitel Konfigurerbar synkronisering Kravtype K Kravområde Opdatering af Datafordeler Kravbeskrivelse Synkroniseringsfunktionaliteten kan skeduleres, så den kører med faste konfigurerbare intervaller, hvor interval kan differentieres i forhold til data og Registre eller når opdatering af data gennemføres. Der skal være mulighed for at igangsætte synkronisering ad hoc, hvis der rapporteres om potentielle fejl eller mangler i Grunddata. Kravnr Kravtitel Afbrydelse af synkronisering Kravtype K Kravområde Opdatering af Datafordeler Kravbeskrivelse En igangværende synkronisering kan stoppes manuelt, f.eks. hvis der opstår situationer med driftsmæssige problemer. Kravnr Kravtitel Beskrivelse af synkronisering-løsning Kravtype PK Kravområde Opdatering af Datafordeler Kravbeskrivelse Leverandøren har i underbilag 3B beskrevet, hvordan synkronisering fra Registrene til Systemet implementeres, herunder hvilke dele af opgaven, der evt. skal varetages med komponenter som installeres i de enkelte Registre. [Tilbudsgiver skal beskrive, hvordan synkronisering fra Registrene til Datafordeleren implementeres, herunder hvilke dele af opgaven, der evt. skal varetages med komponenter som installeres i de enkelte Registre]. Kravnr Kravtitel Integrationskrav til Register Kravtype PK Kravområde Opdatering af Datafordeler

63 63 Kravbeskrivelse Leverandøren har i underbilag 3B beskrevet, hvilke krav, der skal opfyldes af Registrene, for at opdatering og synkroniseringen kan bringes til at fungere. [Tilbudsgiver skal beskrive krav til Registeret for, at opdatering og synkronisering kan fungere]. Kravnr Kravtitel Sikring af integritet af opdaterede data Kravtype K Kravområde Opdatering af Datafordeler Kravbeskrivelse Systemet skal omfatte Funktionalitet, der sikrer integriteten af de data, der overføres fra Registrene. Dette kan eksempelvis ske ved anvendelse af HMAC i overensstemmelse med RFC fra IETF eller tilsvarende. Systemet skal dokumentere hvilke data der er modtaget, og sende kvitteringer til Registre, så sidstnævnte kan dokumentere at Systemet har kvitteret for modtagelsen. Det er i underbilag 3B beskrevet, hvilke mekanismer, der implementeres for at sikre integriteten af de overførte data. [Tilbudsgiver skal i løsningsbeskrivelsen redegøre for hvordan den tilbudte løsning understøtter sikring af integritet] Delleverance 2 og 3: Referenceimplementeringer For at efterprøve Platformens Funktionalitet og performance, gennemføres referenceimplementeringer på Geodataplatformen og Registerplatformen. Disse referenceimplementeringer omfatter fuld etablering af datamodel og snitflader for de nedenfor specificerede Tjenester. Kravnr Kravtitel Referenceimplementeringer på geoområdet Kravtype PK Kravområde Krav til referenceimplementeringer Delleverance DL3 Kravbeskrivelse På geoområdet skal der oprettes følgende referenceimplementeringer i form af Tjenester på Geodataplatformen for de servicesnitflader, som Geodataplatformen understøtter (servicesnitfladerne, versioner og dataindhold fastlægges endeligt i den generelle afklarings- og planlægningsfase): For Web Feature Service (WFS) eller tilsvarende oprettes en Tjeneste med Danmarks Administrative Geografiske Inddeling (ca. 10 objekttyper). For Web Map Service (WMS) eller tilsvarende oprettes en rasterbaseret Tjeneste med et skærmkort (ét lag) og en vektorbaseret Tjeneste med Danmarks Administrative Geografiske Inddeling (ca. 10 lag), som understøtter Styled Layer Descriptor (SLD) og Filter Encoding eller tilsvarende. For Web Map Tile Service (WMTS) eller tilsvarende oprettes en Tjeneste med et 18

64 64 rasterbaseret skærmkort i Kortforsyningens tilingskema for Danmark i EPSG: For Web Coverage Service (WCS) eller tilsvarende oprettes en Tjeneste med Danmarks Højdemodel. Kunden leverer testdata til brug for udviklingen af referenceimplementeringen. Referenceimplementeringen omfatter opdatering fra og synkronisering med Register for de dele af Grunddata, som benyttes til referenceimplementeringen. Referenceimplementeringen idriftsættes permanent med eksterne brugere ved Overtagelsen af Delleverance 3. Kravnr Kravtitel Referenceimplementeringer for Adresse Web Service (AWS) Kravtype PK Kravområde Krav til referenceimplementeringer Delleverance DL2 Kravbeskrivelse For OIS/AWS skal AWS (Adresse Web Service) suiten version 3.0 eller senere implementeres som referenceimplementering. Det fastlægges endeligt i den generelle afklarings- og planlægningsfase, hvilken version, der skal implementeres. Dette involverer: 1. Publicering af de nævnte Tjenester inklusive testkald 2. Kopiering af BBR-registeret inklusive adresse tabeller 3. Løbende replikering mellem BBR-registeret og Datafordeleren og/eller opkobling af direkte adgang. Kunden leverer testdata til brug for udviklingen af referenceimplementeringen. Referenceimplementeringen omfatter opdatering fra og synkronisering med Register for de dele af Grunddata, som benyttes til referenceimplementeringen. For yderligere beskrivelse henvises der til: Referenceimplementeringen idriftsættes permanent med eksterne brugere ved Overtagelsen af Delleverance 2.

65 65 5. Underbilag 3a.iv: Krav til Agile Delleverancer 5.1. Læsevejledning Udover denne læsevejledning indeholder underbilag 3a.iv følgende kapitler: Punkt 5.2 indeholder de generelle krav til de Agile Delleverancer Punkt 5.3: Indeholder krav til Konsolidering (DL4, DL5, O1 og O2) Punkt 5.4: Indeholder krav til Option 3 Punkt 5.5: Beskriver eksempler på videreudviklingsydelser 5.2. Generelle krav til de Agile Delleverancer Kravnr Kravtitel Anvend allerede leveret funktionalitet Kravtype MK Kravområde Agile Delleverancer A Delleverance DL4, DL5, O1, O2, O3 Kravbeskrivelse De Agile Delleverancer og Option 1 og Option 2 skal baseres på anvendelse af den funktionalitet, der er leveret de Fastlagte Delleverancer, specifikt Basisinfrastrukturen og Platformen. De i underbilag 3.a.ii angivne generelle krav til Leverancen omfatter også de Agile Delleverancer. Datafordeleren vil indeholde en opdateret kopi af de udpegede Registre i forhold til den aftalte opdateringshyppighed og dataaktualitet for det enkelte Register. Ved opdatering af data i Datafordeleren er det løsningsmæssigt essentielt at aftale, hvor initiativet ved en opdatering ligger, uanset om det er en nær-realtid opdatering eller en opdatering, der gennemføres med et fast defineret tidsinterval. Initiativet kan ligge hos Registeret, hvilket kaldes for Push-mønster, eller det kan være Datafordeleren, der tager initiativet, hvilket i denne sammenhæng kaldes for Pull-mønster. Præcist hvilket mønster, der er optimalt og realiserbart, vil være individuelt for det enkelte Register og stærkt afhængig af teknologisk platform og valgte Funktioner i Platformen. For eksempel vil der være behov og basis for at lave nær-realtidsopdateringer af persondata, adressedata og visse andre registerdata, mens de fleste geodata vil opdateres med en meget lavere frekvens. Til gengæld vil geodata skulle opdateres i ganske store kørsler såsom en årlig indlæsning af luftfotos af store dele af Danmark. Der skal derfor designes opdateringsløsninger for hvert Register ud fra mulighederne i Registrenes teknologiske platform og den teknologiske platform som Datafordeleren bygges på, med udgangspunkt i de generiske Push/Pull mønstre. Den logiske arkitektur for Push/Pull integration af Datafordeleren er illustreret i nedenstående figur, hvor retning på pilene angiver initiativet for opdateringen.

66 66 Basis Platform Basisinfrastruktur Push Pull Grunddataregistre Figur 7 Opdatering fra Register I nedenstående beskrives generelle use cases for de to opdateringsmønstre. Use case 5 Push-mønster Brug af Push-mønsteret forudsætter, at der er en Datafordeler komponent i Registeret, der har til opgave at administrere hvilke opdaterede data i Registeret, der skal sendes til Datafordeleren. Denne logiske komponent er også ansvarlig for at håndtere afsendelse af data til Datafordeleren og gennemfører evt. Transformation til det aftalte udvekslingsformat mellem Registeret og Datafordeleren. Den logiske komponent administrerer, at data sendes til Datafordeleren med den aftalte opdateringshyppighed. Use case 6 Pull-mønster Ved Pull-mønsteret omfatter Registeret ikke Funktionalitet til at administrere dataafsendelse til Datafordeleren, da det er Datafordeleren, der er initiativtager til at data opdateres og har ansvaret for gennemførelse af opdatering. Både for Push og Pull-mønsteret gælder, at det er både Grunddata og metadata, der udveksles mellem Register og Datafordeleren. I nedenstående beskrives de overordnede trin som vil være gældende for de to mønstre, hvor der for hvert trin kort angives de aktioner, der skal gennemføres. Af forståelsesmæssige grunde er også medtaget initierende aktioner, der ligger udenfor Datafordeleren (jf. i øvrigt svømmebanediagrammer ovenfor). Push-mønster variant beskrevet som nær-realtids opdatering Trin Handling 1 Sagsbehandler initierer opdatering i Register 2 Opdatering persisteres i Register 3 Register sender opdaterede objekt(er) til Datafordeler 4 Datafordeler kvitterer for modtagelse af opdatering 5 Datafordeler persisterer modtagne Grunddata i datalager 6 Opdaterede Grunddata er tilgængelig i Datafordeler og kan distribueres Push-mønster variant tidsbestemt opdatering

67 67 Ved tidsbestemt opdatering vil der være et tidsinterval mellem trin 2 og trin 3, og der vil sandsynligvis blive sendt flere opdateringer samtidigt til Datafordeleren. Trin Handling 1 Sagsbehandler initierer opdatering i Register 2 Opdatering persisteres i Register 3 Datafordeler beder om ændrede data fra Register 4 Register sender opdaterede objekter til Datafordeleren/Datafordeler henter opdaterede objekter 5 Hvis objekter sendes til Datafordeler kvitteres for modtagelse 6 Datafordeler persisterer modtagne Grunddata i datalager 7 Opdaterede Grunddata er tilgængelig i Datafordeler og kan distribueres Den specifikke løsning og valg af Push og Pull-mønsteret for det enkelte Register detaljeres i de særlige afklaringsfaser for Delleverancerne, hvor de forskellige Registre er placeret (jf. bilag 1), hvor dataopdatering designes og specificeres i samarbejde med Leverandøren. Kravnr Kravtitel Implementering af integrationsmønstrene Kravtype PK Kravområde Opdatering af Datafordeler A Delleverance DL4, DL5, O1, O2 Kravbeskrivelse Leverandøren implementerer Datafordeler-delen af integrationsmønstrene for CPR, CVR, OIS/AWS og Kortforsyningen. Kravnr Kravtitel Fleksibel teknologi Kravtype PK Kravområde Opdatering af Datafordeler A Delleverance DL4, DL5, O1, O2 Kravbeskrivelse Leverandøren skal basere integrationsmønstrene på tilstrækkeligt fleksibel teknologi til, at de eksisterende Registre kan levere data efter det valgte mønster til Systemet, hvor også nye datasæt vil kunne integreres på samme type mønstre. Kravnr Kravtitel Integrationer detaljeres i afklaringsfase Kravtype K Kravområde Opdatering af Datafordeler Ø Delleverance DL4, DL5, O1, O2 Kravbeskrivelse Den præcise løsning og valg af integrationsmønster for det enkelte Register skal detaljeres og fastlægges i samarbejde med Leverandøren, i den afklaringsfase, der ligger forud for den Delleverance, hvor Registret skal konsolideres. Kravnr Kravtitel Kategorisering af Tjenester Kravtype K Kravområde Tjenester Ø Delleverance DL4, DL5, O1, O2 Kravbeskrivelse Alle Tjenester skal i forbindelse med implementeringen og etableringen på Systemet kategoriseres i forbindelse med kravnedbrydning (krav 11.62) i overensstemmelse med bilag 7 Servicemål.

68 Konsolidering af Registre Generelle krav til Konsolidering I det følgende beskrives Konsolidering af de eksisterende distributionsplatforme til Systemet. Konsolidering dækker over implementering af de Tjenester på Datafordelerens Platform, som i fremtiden skal distribuere Grunddata om personer, virksomheder, adresser og geografi, herunder også etablering af overførsler af og databaseunderstøttelse af de Grunddata, som Systemet skal udstille. For uddybning af Basisinfrastruktur og Platform henvises til beskrivelserne ovenfor. Helt overordnet har Kunden forretningsmæssigt behov for at Tjenester og Grunddata etableres på Datafordeleren hurtigst muligt og på en måde, som sikrer de lavest mulige samlede omkostninger for distribution af Grunddata. Konsolideringen er illustreret i figur 11. Geodata Platform Register Platform Basis Platform Basisinfrastruktur Push Pull Grunddataregistre Figur 8 Konsolidering af registre på en Platform og Basisinfrastruktur. Konsolidering på Platformen vil datamæssigt implementeres ved, at alle Registerets Grunddata overføres til Systemet, og at der etableres opdatering af Grunddata, også selvom det ikke er alle Tjenester der i første omgang konsolideres. Delleverance 4 omfatter Konsolidering af OIS/AWS Delleverance 5 omfatter Konsolidering af Kortforsyningen Option 1 omfatter Konsolidering af CPR Option 2 omfatter Konsolidering af CVR Konsolidering omfatter at implementere tilsvarende Funktionalitet og Tjenester som de eksisterende distributionsløsninger for Grunddata på Datafordelerens Platform, og sikre at dataopdateringer fra Grunddataregistre fremadrettet sker til Platform, Geodataplatform og Registerplatform.

69 69 I grunddataprogrammet vil en række Registre og Grunddata blive forbedret, og i den forbindelse vil kvalitetsspor under grunddataprogrammet levere reviderede Tjenestebeskrivelser til implementering på Datafordeleren. Det er derfor væsentligt at være opmærksom på initiativer beskrevet i punkt i indeværende bilag. Konsolideringer forventes generelt at skulle koordineres med grunddataprogrammets indsats vedrørende ny datamodel, og for Tjenester som er omfattet af kvalitetsinitiativer at følge den i figur 2.1 beskrevne proces. Kravnr Kravtitel Fjernet Kravtype Kravområde Delleverance Kravbeskrivelse Kravet er fjernet Kravnr Kravtitel Fjernet Kravtype Kravområde Delleverance Kravbeskrivelse Kravet er fjernet Kravnr Kravtitel Implementering af opdatering fra Grunddataregistre Kravtype MK Kravområde Generelle krav til Konsolidering A Delleverance DL4, DL5 Kravbeskrivelse Leverandøren skal levere en løsning, der opdaterer og synkroniserer data mellem Grunddataregistrene og Datafordelerens Platform i henhold til krav beskrevet i Punkt Synkronisering og opdatering skal tillade dobbeltdrift med de eksisterende distributionsplatforme. Kravnr Kravtitel Fjernet Kravtype Kravområde Delleverance Kravbeskrivelse Kravet er fjernet Kravnr Kravtitel Afprøvning af Konsoliderede løsninger Kravtype MK Kravområde Generelle krav til Konsolidering A Delleverance DL4, DL5 Kravbeskrivelse Leverandøren skal gennemføre afprøvning af Konsoliderede distributionsløsninger jf. Bilag 14 Afprøvning Delleverance 4: Konsolidering af OIS/AWS Konsolideringen af OIS/AWS forventes at være koordineret med grunddataprogrammets indsatser vedrørende ejendomme og adresser jf. henvisninger i punkt Yderligere beskrivelser af ejendoms- og

70 70 adresseprogrammet kan findes på følgende hjemmeside: Ejendomsprogrammet vil have indflydelse på konsolideringen af Grunddata og Tjenester fra BBR, Matriklen og Ejer. Matriklen er i dag en del af både OIS/AWS og Kortforsyningen. Adresseprogrammet vil have på indflydelse konsolideringen af Grunddata fra dansk adresse register (DAR som tidligere var en del af BBR), og for AWS Tjenester. Endelig forventes analyse vedrørende myndigheders håndtering af adresser i udlandet at skulle koordineres med Konsolideringen af OIS/AWS. Kravnr Kravtitel Konsolidering af OIS/AWS Kravtype PK Kravområde Generelle krav til Konsolidering A Delleverance DL4 Kravbeskrivelse Leverandøren skal Konsolidere de Tjenester, der er nødvendige for at distribuere OIS/AWS-data på Platformen i overensstemmelse med det forventede omfang der er angivet i bilag 2. Kravnr Kravtitel Fjernet Kravtype Kravområde Delleverance Kravbeskrivelse Kravet er fjernet Delleverance 5: Konsolidering af Kortforsyning Konsolideringen af Kortforsyningen forventes at skulle koordineres med grunddataprogrammets indsatser vedrørende ejendomme, adresser, vanddata og geodata jf. henvisninger i punkt Yderligere beskrivelser af indsatser på ejendoms- og adresseområdet kan findes på følgende hjemmeside: Ejendomsprogrammet vil have indflydelse på konsolideringen af Grunddata og Tjenester fra Matriklen. Matriklen er i dag en del af både OIS/AWS og Kortforsyningen. Adresseprogrammet vil have indflydelse konsolideringen af Grunddata og Tjenester fra DAGI. Kravnr Kravtitel Fjernet Kravtype Kravområde Delleverance Kravbeskrivelse Kravet er fjernet Kravnr Kravtitel Konsolidering af Kortforsyningen Kravtype PK Kravområde Konsolidering af Kortforsyningen A Delleverance DL5 Kravbeskrivelse Leverandøren skal Konsolidere de Tjenester, der er nødvendige for at distribuere Geodatastyrelsens Grunddata på Platformen i overensstemmelse med det forventede omfang, der er angivet i bilag 2.

71 71 Kravnr Kravtitel Fjernet Kravtype Kravområde Delleverance Kravbeskrivelse Kravet er fjernet Option 1: Konsolidering af Persondata Konsolideringen af Grunddata og Tjenester om personer (CPR) forventes at skulle koordineres med grunddataprogrammets analyse vedrørende persondata jf. henvisninger i punkt Kravnr Kravtitel Konsolidering af Persondata Kravtype MK Kravområde Konsolidering af Persondata A Delleverance O1 Kravbeskrivelse Leverandøren skal Konsolidere de Tjenester, der er nødvendige for at distribuere persondata på Platformen i overensstemmelse med specifikationer, der leveres af Kunden senest i forbindelse med afklaringsfasen for Option 1. Det forventede omfang af Tjenester, der skal implementeres er angivet i bilag 2 Kravnr Kravtitel Fjernet Kravtype Kravområde Delleverance Kravbeskrivelse Kravet er fjernet Option 2: Konsolidering af CVR Konsolideringen af Grunddata og Tjenester fra CVR forventes at skulle koordineres med grunddataprogrammets indsatser vedrørende virksomheds- og selskabsdata jf. henvisninger i punkt Kravnr Kravtitel Konsolidering af CVR Kravtype MK Kravområde Konsolidering af CVR A Delleverance O2 Kravbeskrivelse Leverandøren skal Konsolidere de Tjenester, der er nødvendige for at distribuere CVRdata på Platformen i overensstemmelse med specifikationer, der leveres af Kunden senest i forbindelse med afklaringsfasen for Option 2. Det forventede omfang af Tjenester, der skal implementeres er angivet i bilag 2 Kravnr Kravtitel Fjernet Kravtype Kravområde Delleverance Kravbeskrivelse Kravet er fjernet 5.4. Option 3: Udvidet Platform Option 3 beskriver Kundens krav til udvidelser til Funktionalitet i Systemet, der kan tilkøbes af Kunden.

72 Option 3: Abonnement og distribution af Hændelser Dette punkt indeholder krav til abonnement på Hændelser og distribution af de tilhørende Hændelsesbeskeder til de Dataanvendere der abonnerer på hændelser. Punktet indeholder også beskrivelse af generisk forløb for en Hændelse fra generering til distribution. For at beskrivelsen og kravene skal være så entydige som muligt, opsummeres de vigtigste begreber igen, da forløbet omfatter Register, Datafordeleren og Dataanvenderen, der som afslutning på forløbet, modtager besked om en opstået Hændelse. Dataanvenderens videre behandling er specifikt for Dataanvenderens forretning og forretningsprocesser, og er udenfor scope af Datafordeleren. Der henvises i øvrigt til svømmebanediagram i underbilag 3a.i. Definition af vigtigste begreber, herunder Hændelser, Hændelsesbesked og Abonnement er anført i punkt Der skelnes mellem datanære Hændelser og forretningsmæssige Hændelser. Datafordeleren kan kun danne datanære Hændelser, det vil sige Hændelser der kan fortælle, at et Dataentitet er oprettet, ændret eller slettet. En forretningsmæssig Hændelse er en mere detaljeret og forretningsmæssig sigende beskrivelse af en oprettelse, ændring eller sletning. En forretningsmæssig beskrivelse af Hændelsen kræver, at denne fortolkning eller beskrivelse leveres fra Registeret. Eksempler på forretningsmæssige Hændelser for en oprettelse af et personobjekt kan være, at personen er født, eller har fået dansk statsborgerskab. Eksempler på forretningsmæssige Hændelser, der beskriver en ændring for et personobjekt kan være at personen er flyttet, har fået nyt efternavn eller at personen er død. Et eksempel på en forretningsmæssig Hændelse for en sletning af et personobjekt kan være, at personen er slettet pga. en tidligere fejloprettelse i registeret. Nedenstående beskrivelse illustrerer det generiske forløb fra Hændelsens tilblivelse i Grunddataregisteret til håndtering og distribution af Hændelsesbesked og Grunddata fra Datafordeleren. 1. Der gennemføres en opdatering af data i Registeret, f.eks. civilstand ændres for person 2. Der registreres en hændelseskode i Registeret 3. De opdaterede data inklusiv hændelseskode sendes fra Register til Datafordeleren 4. Datafordeleren opdaterer Grunddata 5. Datafordeleren identificerer Hændelsen i de modtagne data 6. Datafordeleren undersøger om der findes aktive abonnenter på Hændelse eller berørte Dataentitet 7. Findes aktive abonnenter opbygges Hændelsesbesked og den sendes til Dataanvendere med aktive Abonnementer Kravnr Kravtitel Registrering af Abonnement Kravtype K Kravområde Hændelser Ø Delleverance O3 Kravbeskrivelse Datafordeleren skal omfatte en Grafisk Brugergrænseflade og API, hvorigennem det er muligt for Datafordelerens anvendere at definere og vedligeholde Abonnement på de Hændelser som Datafordeleren tilbyder. Ovenstående brugergrænseflader skal udstille en oversigt over de Hændelser som Datafordeleren tilbyder.

73 73 Kravnr Kravtitel Geografisk afgrænsning for abonnement Kravtype K Kravområde Hændelser A Delleverance O3 Kravbeskrivelse Abonnement skal understøtte at der angives et geografisk område (bounding box) som afgrænsning for hvilke Dataentiteter der er omfattet af hændelsesabonnement. Geografisk område angives som koordinater. Abonnement skal understøtte at der angives et geografisk område på baggrund af DAGI områder (polygoner). Abonnement skal understøtte at der angives et geografisk område som et punkt og en radius. Kravnr Kravtitel Kort for Geografisk afgrænsning for abonnement Kravtype K Kravområde Hændelser Ø Delleverance O3 Kravbeskrivelse Systemet skal stille Grafisk Brugergrænseflade og API til angivelse af et geografisk område (bounding box, DAGI områder og punkt/radius) til rådighed. Der vil være behov for at Hændelser kan afsendes både med og uden dataindhold. Hvis der medsendes dataindhold består det af Dataentiteten i den tilstand det har efter Hændelsen er indtruffet. Fx betyder det, at hvis en person er flyttet, så medsendes det opdaterede Dataentitet, hvor personens nye adresse fremgår. I andre tilfælde vil det dog ikke være hensigtsmæssigt at medsende selve Dataentiteten, hvorfor der også skal være mulighed for kun at fremsende Hændelsesbeskeden, samt en reference til Dataentiteten. I grunddataprogrammet har pågået en afklaring omkring håndtering af hændelser. Den følgende tekst i kursiv er de foreløbige beskrivelser fra denne afklaring og vedrører de nuværende forventninger til hvordan beskeder håndteres. Beskeder skal i denne sammenhæng forstås som Hændelsesbeskeder. Beskeder generelt (Referencearkitekturen) Beskeder transporteres som en kuvert som konceptuelt består af fire dele som vist på nedenstående figur.

74 74 Beskeden er struktureret med en teknisk del som bør indeholde teknisk information om beskedafsenderen fx system og tid, routingsinformation, sikkerhedsmekanismer som tjeksum og signering, sikkerhedsklassifikation for beskeden som helhed som et udtryk for de forretningsmæssige data der transporteres. Den næste del udgør forventninger til de fælles og dermed generelle egenskaber som modtageren kan forvente i alle beskeder i samme specifikke implementation. Her formidles typen af hændelse og især forskellig information om konteksten for forretningshændelsen i en række obligatoriske og frivillige felter. Nedenstående figur viser typiske elementer der beskriver og uddyber hændelsen. Den tredje del udgør forventninger til individuelle egenskaber som afsenderen evt. sætter op. Sådanne yderligere data om hændelsen kan med fordel benyttes til mere præcis filtrering af beskeder ifm. abonnement eller optimering af beskedevalueringen efter modtagelsen. Der kan være tale om fx relaterede objekter, før/efter værdier og uddybende information om hændelsen eller registreringen af denne. Felterne her kan også indgå i abonnementsudtryk. Elementer i denne del har ikke en standardiseret form og har derfor navne bestemt af afsenderen af den pågældende type beskeder måske med aftalte navnekonventioner eller given kontekst.

75 75 Hvor de tre første dele af beskeden kan benyttes til filtrering af beskeder, består den sidste del af beskeden af private egenskaber, der ikke tilgås af Systemet. Der kan være tale om data af vilkårlig natur i form af vedhæftede data. Kravnr Kravtitel Indhold af Hændelsesbesked Kravtype K Kravområde Hændelser A Delleverance O3 Kravbeskrivelse En Hændelsesbesked der afsendes, skal både indeholde hændelseskode, hvor kode angiver hvilken Hændelse der er opstået, samt enten Dataentiteten som Hændelsen vedrører eller en entydig reference til Dataentiteten, der på dataanvendersiden kan benyttes til at slå Dataentiteten op på Datafordeleren. Indhold af Hændelsesbesked afklares i den supplerende afklaringsfase for Option 3 Kravnr Kravtitel Indhold af Hændelsesbesked konfiguration Kravtype K Kravområde Hændelser A Delleverance O3 Kravbeskrivelse Det skal være muligt at konfigurere Hændelsesbeskeder således, at de både kan afsendes med selve det ændrede Dataentitet, eller en entydig reference til Dataentiteten, der på dataanvendersiden kan benyttes til at slå Dataentiteten op på Datafordeleren. Kravnr Kravtitel Abonnement på specifikke Hændelser Kravtype K Kravområde Hændelser A Delleverance O3 Kravbeskrivelse Det skal være muligt at abonnere på specifikke Hændelser eller på objekter, dvs. alle Hændelser der sker for de valgte Dataentiteter. Det skal samtidigt være muligt at kombinere disse to abonnementsmuligheder således, at der abonneres på specifikke Hændelser for udvalgte objekter. Som en variant af Dataentiteter skal der være muligt at angive Abonnement på objekttyper. Kravnr Kravtitel Formatet for Hændelsesbeskeder Kravtype K Kravområde Hændelser A Delleverance O3 Kravbeskrivelse Ændringsbeskeder/Hændelser skal leveres i forskellige formater, som Dataanvendere kan vælge imellem for den enkelte type af Hændelsesbesked. De gængse formater skal understøttes i overensstemmelse med krav Hændelsesbeskeder skal leveres i grunddataprogrammets fælles beskedformat, som fastlægges i forbindelse med den generelle afklarings- og planlægningsfase. Kravnr Kravtitel Modtagelse af Hændelsesbesked Kravtype K Kravområde Hændelser Ø Delleverance O3 Kravbeskrivelse Dataanvender skal i forbindelse med opsætning af Abonnement på Hændelser vælge, hvor og hvordan Hændelsesbeskeder ønskes modtaget fra Datafordeleren, jf. i øvrigt krav

76 76 Kravnr Kravtitel Nær-realtids afsendelse af Hændelsesbesked Kravtype K Kravområde Hændelser A Delleverance O3 Kravbeskrivelse Hændelsesbesked skal afsendes nær-realtid til abonnenter, efter at forretningsmæssige Hændelser er modtaget fra Register eller efter Hændelsesbesked er dannet i Datafordeler. Kravnr Kravtitel Modtagelse af Hændelser i Datafordeleren Kravtype K Kravområde Hændelser A Delleverance O3 Kravbeskrivelse Datafordeleren modtager Hændelser fra Registeret, som en del af dataleverancen herfra. Hændelser vil være specifikke datafelter hvor hændelsestypen er angivet. Datafordeleren skal identificere Hændelserne og reagere i forhold til disse. I det følgende beskrives eksempler på scenarier, hvor datadistribution via Hændelser forventes at være en relevant distributionsmodel, enten som et supplement til eller som et alternativ til Filudtræk og Onlineopslag. Opdatering mellem Registre sker ved hjælp af Hændelser: I det omfang et Register har behov for at få besked om ændringer i et andet Register, sker dette via Hændelser. Et eksempel kunne være Registeret med Persondata, som ønsker at modtage besked når bestemte adresser i adresseregisteret ændrer sig, eller virksomhedsregisteret, der ønsker at modtage besked når bestemte personer ændrer status eller flytter. Vurderingen er, at både forretningsnære og datanære Hændelser kan være relevante for at understøtte opdateringer mellem registre. Et sagssystem i en kommune ønsker at reagere på baggrund af bestemte Hændelser, eksempler kunne være Hændelser, der fortæller hvis personer flytter ind i den kommune, systemet abonnerer på Hændelser for. På baggrund af Hændelsen vil kommunen fx igangsætte processer for lægevalg eller lignende relevante processer, der skal gennemføres når en person flytter mellem kommuner. Vurderingen er at især forretningsnære hændelser er relevante i kommunikationen med sagssystemer Option 3: Linked Data, RDF og SPARQL Der skal som en udvidelse af Datafordeleren leveres Funktionalitet som understøtter følgende forretningsmæssige behov: Behovet for, at Dataanvendere dynamisk kan sammensætte Grunddata på tværs af datakilder, både fra Systemets egne databaser, men også fra eksterne datakilder. Behovet for let og maskinelt at søge og tilgå supplerende oplysninger om Grunddata, både i form af metadata og i form af relations- og attributbeskrivelser. Behovet for entydigt at kunne identificere Systemets Grunddata i sammenhænge, der også rækker udenfor Systemet. For at kunne opfylde disse behov skal det være muligt at lade Datafordelerens Grunddata være repræsenteret og gjort tilgængelige efter de principperne for linked data der er beskrevet af W3C. 19 Der 19

77 77 henvises i øvrigt til følgende overordnede beskrivelser vedrørende linked data Begreber og teknologier relateret til Linked Data RDF 20 RDF er en forkortelse for Resource Description Framework. RDF er et standardrammeværk for beskrivelse af ressourcer og en standardiseret model for dataudveksling. RDF er grundlaget for RDF Schema og OWL. I den resterende del af nærværende dokument benyttes RDF som fællesbetegnelse for RDF, RDF Schema og OWL. RDF Schema 21 RDF Schema udvider RDF med klasser og relationer/egenskaber. OWL 22 SPARQL 23 GeoSPARQL 24 Triple store Ontologi OWL er en forkortelse for Web Ontology Language. OWL bygger på RDFog RDF Schema-fundamentet og tilføjer blandt andet beskrivelseslogik. SPARQL er en forkortelse for SPARQL Protocol and RDF Query Language. SPARQL er et sprog til at finde, hente og manipulere data gemt i et RDFformat. SPARQL understøttelse geodata. Denne specifikke implementering af SPARQL skal sikre sammenhængende og tværgående SPARQL-baseret søgefunktionalitet, hvor geodata kan indgå på lige fod med øvrige data. Database der håndterer data i RDF-format. Ordet benyttes i nærværende dokument som betegnelse for en RDFbaserede begrebs- og datamodel. De følgende punkter i kursiv beskriver Kundens foreløbige forventninger til de forretningsmæssige mål og behov, hvor Linked Data kan have relevans. Dermed kan de tjene til inspiration for den Overordnede Løsningsbeskrivelse. Udfordringer - generelt Offentlige organisationers muligheder for videndeling og effektivt indbyrdes samarbejde er direkte afhængig af integrationsmulighederne mellem samme organisationers it-systemer. Det offentlige informationslandskab består i dag af et stort antal ikke-sammenhængende systemer, der ikke let lader sig sammenbinde og ikke let og hurtigt inddrager nye informationstyper og brugssituationer. Denne datamæssige ø-dannelse betyder blandt andet: At en fuldt dækkende, effektiv og troværdig søgning på tværs af potentielt interessante datakilder ikke er mulig i dag, At de fleste data ikke uden væsentlig bearbejdning er egnet til at indgå i tværgående itsamarbejde. At samarbejde mellem organisationer kan blive besværliggjort og være omkostningstungt når samarbejdet kræver deling og/eller integration af data mellem forskelligartede systemer. Uden en fælles standard der kan forbinde data og informationer, kan ellers relevant kombination af data fra forskelligartede it-systemer ikke udføres automatisk uden ressourcekrævende indgreb

78 78 Nedenstående illustration viser en generaliseret brugersituation. Opgaveløsningen for brugeren i Organisation 2 kræver information fra andre kilder end dem Organisation 2 selv råder over. En del af informationen hentes fra Organisation 1 via dennes hjemmeside. Herfra kopierer brugeren data og indsætter data i eget systems, System Bs, brugergrænseflade. Denne øvelse kan kræve omformatering eller opbrydning af de kopierede data. Yderligere oplysninger hentes, via et API System C tilbyder, fra Organisation 3. Scenariets problemstillinger Integrationen til System A er tidkrævende for brugeren. Kender brugeren ikke på forhånd til det website der præsenterer information fra System A, så skal brugeren først finde frem til site et og til den relevante information. Når brugeren har fundet informationen skal der bruges tid på at kopiere og konvertere informationerne. Ønsker brugeren en bedre, mere formel integration til System A vil det erfaringsmæssigt kræve en ikke-ubetydelig inddragen af it-kyndige. Integrationen til System C gør Organisation 2 afhængig af Organisation 3s beslutninger. Organisation 2 er afhængig af at Organisation 3 har defineret hvilke data der kan hentes og i hvilke kombinationer Organisation 2 er afhængig af at skulle ændre i eget system når Organisation 3 ændret ved sit systems API. Nye informationskilder: Brugerens og/eller organisationens kendskab til eksistensen af anvendelige informationer er ofte begrænset til den viden der er opnået gennem personlige kontakter. Det betyder at reelt at potentielle datakilder ikke forsøges benyttet.

79 79 Når nye informationskilder er fundet og fundet egnede vil integration til kilderne oftest medfører et større ressourcetræk på både fagkyndige og it-personer. o Grænseflader (og eventuelt kommunikationsprotokol) skal læres og forstås på både syntaktisk og semantisk niveau. o Der skal konverteres fra det ene systems anvendelse af syntaks og semantik til det andet systems syntaks og semantik. o Der skal indgås aftaler om sikkerhed og rettigheder. At nå fra dagens ikke-sammenhængende informationslandskab frem til en semantisk sammenhængende informationsinfrastruktur giver følgende overordnede udfordringer der skal håndteres: Systemintegration i et systemlandskab med forskelligartede grænseflader og kommunikationsprotokoller. Data kan være underlagt en syntaks der ikke på forhånd er kendt af det modtagende system. Data er ikke beskrevet med en maskinforståelig semantik. Manglende fælles tværgående semantik for maskiner og for personer. Ovennævnte scenarie omhandler data fra flere organisationer, men problematikken gælder også internt i mange organisationer. Linked Data Linked Data 25 er en standard rammemodel og metode der muliggør: Data der er selvbeskrivende (for maskiner og personer). Ræsonnering ud fra modeller og data så nye relationer og data kan udledes. Beskrivelse af sammenhæng mellem data fra adskilte og forskelligartede datakilder. En ensartet måde at søge efter og hente data uafhængigt af de datakildernes forskelligartethed. En bred vifte af mulige formater til repræsentation af data. Implementeringsprincipper Brugen af Linked Data-arkitekturen respekterer de it-relaterede investeringer der er foretaget gennem årene ved at bruge løsninger der ikke påtvinger organisationer et radikalt teknologisk skifte af underliggende systemer. Linked Data principperne anvendes til at udvide og løfte eksisterende systemer parallelt med at disse forsat anvender de hidtil anvendte protokoller og dataformater hvis det ønskes. Dermed vil det i langt de fleste tilfælde være muligt at foretage de teknologiske forbedringer som en trinvis proces der sikrer tid til koordinering af organisatoriske processer, ressourcer og økonomi. Linked Data-arkitektur Linked Data-arkitekturen baseres på tre søjler: REST 26 som kommunikationsmetode mellem it-systemer. RDF som rammemodel der entydigt kan beskrive ressourcer og deres indbyrdes relationer 27. SPARQLQuery Language for RDF som søge og opdateringssprog mod heterogene informationskilder

80 80 Semantisk integration Semantisk integration er forudsætningen for at opnå fleksible og dynamiske integrationsmuligheder mellem data, der er skabt indbyrdes uafhængigt og placeret i forskellige systemer. Semantisk integration inkluderer: Standardiserede grænseflader mod informationskilder til at hente og/eller opdatere informationer og data gennem. Standardiserede grænseflader der giver mulighed for at foretage søgninger, forespørgsler og analyser mod alle tilgængelige it-systemer på en gang. Standardbaseret ramme for sammenhængende ressourcebeskrivelse. En enkel, men udtryksfuld logik (beskrivelseslogik) der kan anvendes til at drage slutninger/konklusioner ud fra eksisterende data og som resultat af disse slutninger - at danne nye data og dermed ny information. Semantisk integration gør det muligt at gå væk fra nuværende foruddefinerede punkt-til-punkt-integration og udveksling, og gå hen imod at kunne håndtere den ikke-forudsete anvendelse, hvor brugere og applikationer kan finde og anvende data når behovet opstår. Med anvendelse af Linked Data-principperne etableres tværorganisatorisk standardisering på integrationsniveau, for at lette anvendelse og udveksling af data. Med Linked Data etableres der semantisk og syntaktisk entydighed på tværs af eksisterende systemer, så data kan præsenteres i både en syntaktisk korrekt form og i en semantisk forståelig form. Implementering af Linked Data vil gøre det muligt: At data fra forskelligartede kilder kan integreres fleksibelt, hurtigt og med et minimum af ressourceforbrug. At offentlige organisationers brugere og it-systemer bringes frem til en situation, hvor data kan hentes og kombineres, på det tidspunkt hvor behovet opstår. At foretage søgninger og datasammensætning på tværs af datakilder. At ovenstående punkter i væsentligt øget omfang kan automatiseres og overlades til maskinelle processer. Linked Data på Datafordeleren Datafordeleren vil, ved understøttelse af Linked Data-principper, kunne indgå i en dansk informationsinfrastruktur med enklere dataintegration baseret på semantiske modeller i form af ontologier. Ontologier forventes udviklet af Registermyndigheder og udstilles på Systemet. Disse ontologier kan starte som simple en-til-en-repræsentationer af de underliggende data, og løbende udvides med forretningsbegreber efter behov forretningsbegreber der kan spænde over flere Registre.

81 81 Mellem de enkelte ontologier defineres relationer både relationer der er i databaserne er eksplicitte og implicitte. De udstillede ontologier kan udgøre et grundlag for semantisk entydig kommunikation it-systemer imellem. Decentralt altså uden for Datafordeleren - kan lokalt udviklede begrebsmodeller/ontologier anvende og udvide ontologierne, og dermed sikre sammenhæng, genkendelighed og øgede muligheder for lettere integration it-systemer imellem. Med implementering af et eller flere SPARQL endpoints kan Datafordeleren tilbyde friere søgemuligheder på tværs af Datafordelerens databaser.