1 Indledning. 2 Den fællesoffentlige datafordeler. 1.1 Hvad er grunddata



Relaterede dokumenter
Bilag 2 - Fælles arkitekturramme for GD1-GD2-GD7. Etablering af datadistribution på den Fællesoffentlige Datafordeler

BBR - Kontekstdiagram

OIS - Applikationskatalog

Datafordeleren - status, muligheder, udvikling

Grunddata på Datafordeleren

Grunddataprogrammet. Præsentation den 24. februar 2016 Deniz Gøgenur

Datafordeleren - status, muligheder, udvikling

Notat om metadata om grunddata

Teknikken bag Datafordeleren Distribution af data. Fællesoffentlig datadistribution

Vilkår vedrørende brug af Støttesystemet Beskedfordeler

Vilkår for brug af Støttesystemet Sags- og Dokumentindeks

Løsningsbeskrivelse. Den fælleskommunale Serviceplatform

Version 1.0. Vejledning til brug af Støttesystemet Organisation

Anvendelse af dobbelthistorik i GD2

Dagens program. Hvad er grunddata og hvad er status på programmet? Hvilke fordele og forbedringer kan vi opnå med grunddata? Hvad sker der fremover?

Grunddata. 7. Marts 2012 Peter Falkenberg

(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne)

(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne)

Ejerfortegnelse Løsningsarkitektur Bilag C Processer Grunddataprogrammet under den Fællesoffentlig digitaliseringsstrategi

Fælles datafordeler - Analyse af afhængigheder til GD1-Ejendomsdata og GD2-Adressedata

Klik her for at angive tekst. Vejledning til brug af Støttesystemet Sags- og Dokumentindeks

Scope dokument for Advisservice

Underbilag 2O Beskedkuvert Version 2.0

BESKEDFORDELER -ET AF DE OTTE STØTTESYSTEMER. Version 2.0

Fællesoffentlig beskedmodel version 1.0

Fælles arkitekturramme for GD1-GD2-GD7

Underbilag 2Q Vilkår for integration til støttesystemet Klassifikation

Klik her for at angive tekst.

Fordeling af journalnotater og dokumenter Udkast til løsningsmodel. Marts 2014

INSPIRE i infrastrukturen. Ulla Kronborg Mazzoli

OIS - - Vision, mål og strategier

10. sept 2013 NOTAT. Integrationsmodel støttesystemer

UDSNIT 8. februar 2008

De fællesoffentlige samarbejder inden for geodataområdet. Kåre Clemmesen, KMS 10. maj 2011

SERVICEPLATFORMEN FOSAKO MØDE 21. MARTS Forretningsudvikler Tomas Volf

Grunddatabeskedmodel version 1.0

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

Introduktion til MeMo

Klik her for at angive tekst. Anvenderkrav til Støttesystemet Sags- og Dokumentindeks

Gode grunddata potentialer for finanssektoren? Jens Krieger Røyen, 30. april 2013

Bilag 12. Drift af SUP-systemer. Udkast af 12. juni Udarbejdet for. SUP-Styregruppen

Overblik over egne sager og ydelser

Indholdsfortegnelse. Systembeskrivelse kapitel 8 Administrationsdatabase

Version 1.0. Vilkår for brug af Støttesystemet Adgangsstyring

Den fællesoffentlige digitaliseringsstrategi Oplæg Ved Charlotte Münter, Direktør, Digitaliseringsstyrelsen

(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne)

INSPIRE og Geodata-info

<navn på proces eller use case>

Mads Bjørn-Møldrup Områdechef, Geodatastyrelsen Nyborgmøde Ny infrastruktur - Datafordeleren SIDE 1

SAPAs forretningsmæssige behov i relation til Dialogintegration. SAPAs behov for Dialogintegration. Fordele ved brug af dialogintegration i SAPA

SDI NUUK den 23. november 2010 Tema: Hvad er grundlaget for SDI? Erfaringer fra Danmark

Adresseregister Løsningsarkitektur

Ledelsen har sikret, at der er etableret en hensigtsmæssig itsikkerhedsorganisation

Serviceplatformen informationsmateriale. Leverandørmøde 7. februar 2013

Plan for tilbagekonvertering til OIS. - fra de nye versioner af grunddataregistrene

Ejendomsdataprogrammet - Ejerfortegnelse Løsningsarkitektur

Grunddata som kilde til vækst og innovation. Oplæg for Midtjysk Erhvervsudviklingsakademi v/ Rikke Gram-Hansen 21/8-2013

Faktaark for BBR 2.0

Datafordelerens sikkerhedsmekanismer

REFERENCEARKITEKTUR FOR SELVBETJENING OG REFERENCEARKITEKTUR FOR SAGS- OG YDELSESOVERBLIK

Er INSPIRE relevant for Grønland? SDI Seminar i Nuuk den november 2010 Ulla Kronborg Mazzoli Kort og Matrikelstyrelsen, Danmark

Ja Sættes til -1. ExporterIndicator Ja Ikke en del af CVR grunddata. Sættes til tomt. Har aldrig været required i CVR (citat ERST)

Referencearkitektur for håndtering af hændelser - "Event-Driven Architecture"

Brokere i Identitetsinfrastrukturen

Introduktion til Klassifikation

23. maj 2013Klik her for at angive tekst. HHK/KMJ. Vejledning til brug af Støttesystemet Adgangsstyring

Den samlede erhvervsløsning i næste generation af NemID og NemLog-in3

Introduktion til Støttesystem Organisation

Programbeskrivelse. 5.5 Kommunal implementering af grunddata. 1. Formål og baggrund. Juni 2016

Ejendomsdataprogrammet - BBR Løsningsarkitektur Bilag C Processer

Digital Sundhed. Brugerstyringsattributter - Introduktion. - Specificering af nye og ændrede attributter i id-kortet

Bilag 3. Implementering af grunddataprogrammet. 16. september 2012

Faktaark for DAR 1.0

BILAG 2 KRAVSPECIFIKATION

Denne FAQ giver svar på de oftest stillede spørgsmål angående GD1, Ejendomsdataprogrammet.

Vilkår vedrørende anvendelsen af Støttesystemet Organisation

Introduktion til Støttesystem Ydelsesindeks

Gevinster ved grunddataforbedringer på ejendomsdataområdet. Peter Lindbo Larsen, Programleder: Ejendomsdataprogrammet (GD1)

Støttesystemet Beskedfordeler. Beskedfordeler Et af de otte Støttesystemer

Ejendomsdataprogrammet - Matriklen Løsningsarkitektur

Umbrella Blanketløsning

EFFEKTMÅLING DREJEBOG FOR KVANTITATIVE MÅLEPUNKTER EFFEKTMÅLING AF INITIATIVET SAMMENHÆNG OG GENBRUG MED RAMMEARKITEKTUREN

Løsningsarkitektur - Bilag A 1 Sammenstillede services

Den fælleskommunale Rammearkitektur. - en arkitektur for den kommunale digitalisering

Mads Bjørn-Møldrup Områdechef, Geodatastyrelsen Oplæg Rigsarkivet Ny infrastruktur - Datafordeleren SIDE 1

Informationsmøde Genudbud af Datafordeleren

Affødte krav til SDN fra Arkitekturen. Ved Esben P. Graven, Digital sundhed (SDSD)

Hændelser på dåtåfordeleren

It-principper. Bilag 1 til It- og Digitaliseringsstrategi for Sønderborg Kommune

- fra de nye versioner af grunddataregistrene

Introduktion til Støttesystem Sags- og Dokumentindeks

Introduktion til MeMo

Beskrivelse af løsningsmodeller til fordeling af MedCom Advis til flere kommunale fagsystemer

Introduktion til Digital Post. Digitaliseringsstyrelsen August 2019

SYSTEMBESKRIVELSE DIGITALISERINGSSTYRELSEN POC PÅ ORKESTRERINGSKOMPONENTEN. Version: 1.1. Godkender: Forfatter:

Vilkår for dialogintegration SAPA

Adresseprogrammet - Målarkitektur Bilag D - Arkitekturrammer

En teknisk introduktion til NemHandel

Miljøet i Skyen - DMPs erfaringer med Cloud Jesper Nørmark Hede, CTO, Danmarks Miljøportal Nils Høgsted, sekretariatsleder, Danmarks Miljøportal

ecpr erstatnings CPR Design og arkitektur

Transkript:

1 Indledning 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 kilderegistre) 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ælles offentlig datafordeler. 1.1 Hvad er grunddata Grunddata er de væsentligste data om personer, virksomheder, ejendomme, adresser og steder, som anvendes i mange myndigheder, og som er fundamentet for den offentlige forvaltning. Grunddata er dermed et udsnit af de data, der findes i CPR, CVR, BBR, Matriklen, Tingbogen og Kortforsyningen. Grunddata og deres sammenhæng er beskrevet i nedenstående figur. 2 Den fællesoffentlige datafordeler Datafordeleren ses som en fælles infrastrukturkomponent, der håndterer distributionen af grunddata, men hvor selve vedligeholdelsen af grunddata uforandret skal ske i grunddataregistrene. Datafordeleren skal indeholde en spejlet, tidstro og altid opdateret kopi af grunddata fra de bagvedliggende grunddataregistre, og understøtte både fil- og onlinedistribution, men høj stabilitet, god performance og 24/7 drift. Datafordeleren skal dermed erstatte de eksisterende distributionsløsninger som i dag eksisterer til distributionen af de omfattede data, men samtidig levere et teknisk setup der sikrer fleksibilitet i forhold til løbende at udvide nye data. Fx kunne indkomstdata og data

vedr. offentlige organisationer være potentielle fremtidige udvidelser. For at benytte cloud-terminoligi skal datafordeleren altså ses som en platform (PaaS) til distribution af data. 2.1 Kontekst Nedenstående figur illustrerer den kontekst som datafordeleren skal indplaceres i, både i forhold til de forskellige offentlige myndigheders brug af grunddata, men også i forhold til de enkelte grunddataregistre. Data der i dag udstilles og vedligeholdes i grunddataregistrene og fremadrettet udstilles via datafordelen er kun en del af de data der indgår i den offentlige sagsbehandling, hvorfor datafordeleren skal ses i kontekst med udstilling og vedligeholdelse af de mere sagsog fagspecifikke data. Dette er ud fra en teknisk synsvinkel illustreret i nedenstående figur. Datafordeler arkitektur teknisk dialog 2

Datafordeleren distribuerer ikke domænedata, men er det fundament de løsninger udstiller disse data kan basere sig på. 2.2 Datafordelerens funktionalitet Den funktionalitet der forventes tilbudt af en fællesoffentlig datafordeler, kan beskrives som en række logiske komponenter. Disse komponenter kan kategoriseres i forhold til forretningsorienterede komponenter og infrastruktur komponenter. Forretningsorienterede komponenter Komponent Beskrivelse Forretningsobjektlag og regler Accounting/Statistik Forretningsobjekter er den forretningsvendte aggregering af data som Datafordeleren udstiller og som der kan genereres hændelser på. Til hvert forretningsobjekt defineret i Datafordeleren kan der tilknyttes et antal forretningsregler der opererer på forretningsobjektet. Komponenten omfatter derfor både et regel repository og en regel maskine der kan eksekvere de enkelte forretningsregler Understøtter opsamling af data der kan danne basis for faktureringsgrundlag. Data skal registrere i forhold til de kunder/abonnenter der er registreret og skal være opdelt i forhold til grunddataregistrene. Statistik på evt. on-line betalinger håndteres også af komponenter således at disse køb kan bogføres korrekt, og tildeles den rette beløbsmodtager Endvidere omfatter komponenten opsamling af statistikdata til brug for forretningsmæssig rapportering. Faktureringsgrundlag videresendes til økonomisystem/myndigheder, hvor den egentlige fakturering forventes effektueret. Afregning (betaling) Understøtter afregning overfor brugerne af Datafordeleren i forhold til aktuelt forbrug eller det givne abonnement. Forbrug kan f.eks. være antal dataobjekter der er forespurgt på, men kan også være antal hændelser som er sendt til specifik kunde. Afregningsservice skal kunne understøtte de betalingsmodeller som arbejdet i spor 4 resulterer i. Abonnement Komponenten understøtter vedligeholdelse af abonnement på hændelser vedrørende data og dataobjekter samt produkter, f.eks. opdatering af datasæt eller objekter. Abonnement på hændelser kræver vedligeholdelse af hvilke data og dataobjekter en given bruger har adgang til på et gi- Datafordeler arkitektur teknisk dialog 3

vet tidspunkt. Abonnement er dynamisk af natur og skal udstille funktionalitet, således at brugere selv kan vedligeholde abonnementsdata. Administration af Datafordeler Selvbetjening/abonnentinitieret udtræk Produkthåndtering Administrationskomponenten er intern administration af Datafordeler og benyttes af systemadministrator til vedligeholdelse af Datafordeleren og samt Datafordeler metadata (dog ikke metadata vedrørende indholdet i datafordeleren). Administrationskomponenten kan ikke benyttes til at vedligeholde data der kommer fra grundregistre, da vedligeholdelse af disse data alene foretages i grundregistrene. gøres mere klart at det er konfigurationen af datafordeleren. Service der giver brugere mulighed for selv at initiere batch hentning/udtræk af data på ad-hoc basis (gælder kun filbaseret distribution). Brugere der abonnerer på udtræk med fast eller variabelt interval kan bestille og eksekvere de typer dataudtræk som abonnement inkluderer. Produktkomponent indeholder funktionalitet til at understøtte definition, konfiguration og styring af de produkter i Datafordeleren: Produkterne er prædefinerede og kan enten hentes direkte (via enten on-line opslag eller fil-baseret distribution) eller der kan abonneres på produkter. Infrastruktur komponenter Afregningsgrundlag vil også blive genereret i forhold til de definerede produkter. Komponent Brugerstyring Autentifikation Beskrivelse Brugerstyring omfatter administration af de brugere som skal oprettes som navngivne brugere i forhold til datafordeleren, herunder system til system brugere. Brugerstyring inkluderer oprettelse og nedlæggelse af brugere samt tildeling af rettigheder til både services samt dataobjekter/attributter. 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. Autentifikationskomponenten udfører ikke autorisation men opretter grundlaget for dette. Datafordeleren skal udstille data til ikke-danske kunder og disse kunder skal understøttes på lige fod med danske kunder Datafordeler arkitektur teknisk dialog 4

af autentifikation. Adgang/Profiler håndtering Profil-komponenten vedligeholder et sæt af profiler, der beskriver hvilke dataobjekter og dataattributter en given profil giver adgang til. Adgang diffentieres i forhold til data og metadata leveret af grundataregistre og Datafordeler metadata. Profiler for data og metadata fra registre kan kun tildeles rettigheder Læs til. Profilerne benyttes af Filtrering der i denne sammenhæng betragtes, som den udførende komponent i forhold til håndhævelse af de data sikkerhedsmæssige forhold. Profilerne dækker de profiler og profiltyper som benyttes i grunddataregistre, der leverer data til Datafordeleren. Profilerne oprettes som udgangspunkt som grunddataregister-specifikke profiler, baseret på en rollemodel. Håndtering og distribution af hændelser Kunderne til Datafordeleren skal kunne abonnere på hændelser for specifikke dataobjekter eller for en gruppe/type af dataobjekter, hvor Abonnement etablerer en kobling mellem dataobjekter/typer og hændelsestyper der kan opstå. Hændelser genererer en hændelsesbesked når der identificeret en handling der vedrører en hændelsestype på et dataobjekt. Hændelsesbeskeden overleveres til beskedfordeler funktionaliteten i komponenten. Komponenten sender hændelsesbeskeden til den/de abonnenter så abonnenten kan reagere hensigtsmæssigt. Filtrering Switchboard Filtreringsservicen sikrer at der kun vises de specifikke dataobjekter og dataattributter som adgangsakkreditiver og den aktive profil giver adgang til. Med aktiv profil skal forstås det sæt af profiler der er gældende for ID angivet i akkreditiverne. Filtrering har en meget tæt kobling til Adgang/profil, men har udover hvad der normalt ligger under dataautorisation også andre aspekter i forhold til filtrering. Filtrering arbejder bl.a. også ud fra abonnement, idet der for visse typer services kun skal vises de dataobjekter der abonneres på Switchboard sikrer optimal udnyttelse af de tilgængelige ressourcer og dirigerer forespørgsler eller udtræk/distribution til den/de tekniske ressourcer der har ledig kapacitet til at eksekvere disse. Switchboard kan også foretage en prioritering af forespørgsler, således visse forespørgsler eller udvalgte kunder har hø- Datafordeler arkitektur teknisk dialog 5

jere prioritet og dermed bedre svartider Switchboard arbejder på flere områder i den lagdelte arkitektur som STORM-modellen beskriver. Som udgangspunkt vil følgende STORM lag være omfattet af switchboard: Platforme (software platforme) Information (Forretningsobjekter) Service/forespørgsel validering Komponenten håndterer proaktiv validering og overvågning af forespørgsler og servicekald, således at Datafordeleren er sikret mode uhensigtsmæssig udnyttelse eller direkte misbrug/angreb. Misbrug kan f.eks. være udtrækning af alle grunddata på et område, data dumpning. Af kandidater kan nævnes CVR og Kort-data. De vigtigste områder komponenten skal validere er: Validering af forespørgsel, så fejlforespørgsler eller meget tunge forespørgsler afvises Data dumpning forhindres Metadata Metadata i Datafordelen er data om de data som Datafordeleren er distributionsplatform for. Metadata modtages delvist fra grunddataregistrene, men Datafordeleren vil have egne metadata, der bl.a. benyttes internt i Datafordeleren. Metadata omhandler også et katalog over alle objekttyper og attributter der distribueres via Datafordeleren. Kataloget indeholder navn og definition og er versioneret så der holdes styr på udviklingen i definitionerne. Servicelag til datadistribution Fildistribution Datalag Servicelag datadistribution er den Datafordeler komponent der udstiller de forretningsservices der kan tilgås for online opslag eller online udtræk af data. Fildistribution er komponent til håndtering af fil-baserede dataudtræk og distribution til dataabonnenter. Dataudtræk sker på konfigurerede tidspunkter og med fastsatte intervaller. Distribution kan ske ved at udtræk placeres på et ftp-område, hvorfra kunder selv henter de udtrukne data. Som en del af funktionalitet for denne komponent ligger også administration af ftp-områder, oprydning etc. Distribution kan også være en direkte push til kunderne, således at udtrukne data skubbes ud til kunden. Teknologisk skal fildistribution understøtter de filoverførselsmekanismer og kanaler der pt. anvendes af grunddataregistrene Datalag komponent understøtter tilgang til de fysiske data, Datafordeler arkitektur teknisk dialog 6

der er placeret i Datafordeleren. Datalag komponenten afkobler bl.a. servicelag fra den fysiske lagring af data, så disse dels er teknologiuafhængige dels giver mulighed for distribuering af data og understøtte load balancing på en intelligent måde. Skal understøtte geografisk forespørgsel og indeksering (spatial) Opdatering af data i Datafordeler Opdatering af data i Datafordeler har til opgave at gennemføre og administrere opdatering af data i Datafordeler med data modtaget fra eller hentet i grunddataregistrene. Opdatering af data i Datafordeler skal understøtte følgende opdateringsmønstre: Realtid Nær realtid Batch (tidsforskudt opdatering) Skalering / performance Skalering og performance er en teknologi komponent i Datafordeleren der tilbyder funktionalitet til understøttelse af vertikal og horisontal skalering. Komponenten sikrer en automatisk skalering i forhold til antal anvendere, men også i forhold til datamængder efterhånden som grunddataregistre vokser. Logning og monitorering Komponenten sikrer logning af systemmæssige hændelser og fejlsituationer og stiller disse data til rådighed for monitoreringsdelen af komponenten. Monitoreringsdelen kan sende beskeder til overvågningssystem eller systemovervågning om at der er forhold der skal igangsættes korrigerende aktioner for. Transformation Synkronisering med grunddataregistre Understøtter transformation af data til forskellige strukturer og forskellige formater. Det kan f.eks. være de samme data der udstilles via servicelaget som f.eks. både XML og JSON. Komponenten understøttet validering af at data i Datafordeleren er i fuld overensstemmelse med data i Grunddataregistrene i forhold til sidste opdatering af data i Datafordeleren for det enkelte Grunddataregister. I tilfælde af uoverensstemmelse mellem data i Datafordeleren og Grunddataregisteret håndterer komponenten at der sker en synkronisering af data således at Datafordeleren indeholder en korrekt datamæssig afspejling af data i Grunddataregisteret. Datafordeler arkitektur teknisk dialog 7

Grunddataregister komponenter Grunddataregister komponenter der betragtes som værende del af Datafordeler Komponent Opdatering af data PUSH Beskrivelse Opdatering af data PUSH komponenten har til opgave at administrere hvilke data i Grunddataregisteret, hvor der skal sendes opdaterede data til Datafordeleren. Komponenten er ansvarlig for og håndterer afsendelse af data Datafordeleren og gennemfører evt. transformation til det aftalte udvekslingsformat mellem Grunddataregisteret og Datafordeleren. Komponenten administrerer at data sendes til Datafordeleren med den aftalte frekvens og i forhold til det aftalte opdateringsmønster (Realtid, nær-realtid, batch Opdatering af data PULL Opdatering af data PULL er meget lig Opdatering af data PUSH komponenten. Dog indeholder komponenten ikke funktionalitet til at administrere dataafsendelse til Datafordeleren, da det er Datafordeleren der er initiativtager til at data opdateres i Datafordeleren og har ansvaret for gennemførelse af opdatering. 2.3 Fysisk arkitektur for datafordeler Grundet grunddata der distribueres af datafordeleren, samt de forskellige lov og reguleringsmæssige forhold der gælder for disse f.eks. Inspire-direktivet for geo-data, samt forskellig natur af de data som skal udstilles, ses datafordeleren fysisk opbygget som et sæt af infrastrkuktur (IaaS) og platforms (PaaS) komponenter og services. Benyttelsen af cloud-terminologi betyder dog ikke at den fysiske løsning forventes etableret i skyen, men fungerer kun, som en accepteret måde at gruppere lagene i løsningen på. De identificerede IaaS/PaaS komponenter illustreret i nedenstående figur, er IaaS der omfatter services så som servere, netværk og øvrig basis infrastruktur. Fælles PaaS der omfatter de platformsservices som alle datadistributører kan benytte fx autentifikation og skalering. Domænespecifik PaaS som omfatter de services, hvor der vurderes at være behov for funktionelt at opdele services i domænespecifikke grupper, fx et servicelag til distribution af geografiske data, og et servicelag til distribution af register Komponent til synkronisering med grunddataregistre omfatter services som skal etableres på de eksisterende registre for at sikre at data kan flyde fra register til datafordeler effektivt og sikkert. Datafordeler arkitektur teknisk dialog 8

Foreløbige krav til en datafordeler Baggrund: I det følgende er de væsentligste foreløbige krav i forhold til datafordeleren beskrevet. Disse krav skal opfattes som inspiration, og foreløbigt grundlag for den analyse som leverandøren skal gennemføre, samt give et indtryk af det forudgående arbejde, leverandøren kan tage afsæt i. Krav vedrørende tilgængelighed af data K1: Løsningen skal sikre et overblik, over hvorfra data skal hentes K2: Løsningen skal udstille data via standardiserede grænseflader K3: Løsningen skal på basis af rettigheder kunne regulere adgang til data K4: Løsningen skal levere hurtig, sikker og stabil data-hentning og kunne skaleres op til fx 200, 500, 1000 eller 2000 opslag i sekundet K5: Løsningen skal levere en 99,9 % tilgængelighed 24 timer i døgnet, 7 dage om ugen K6: Løsningen skal udstille aktuelle data fra de bagvedliggende kilderegistre Principper for datafordeling K7: Kvalitet og aktualitet af data skal være kendt K8: Data skal være standardiserede og datamodeller skal være åbne K9: Dataindsamling og produktion skal forgå digitalt K10: Data opdateres kun et sted og tilgås via datafordeleren ved kilden. Kopier af data kan benyttes af performancemæssige grunde og efter aftalte spilleregler. Datafordeler arkitektur teknisk dialog 9

K11: I Datafordeleren foretages ikke transformation eller forædling af data. Dette sker i kilderegistrene. Dog vil der i Datafordeleren være services, der sammenstiller data fra flere kilderegistre. Principper for forretning K12: Datafordeleren skal understøtte et multileverandør-miljø, hvor flere leverandører kan bidrage med komponenter til fx serviceudbud K13: Datafordeleren skal understøtte at komponenter til fx serviceudbud kan anvendes til andre data end grunddata K14: Datafordeleren skal understøtte et konkurrencemarked for udvikling af løsninger, der inkluderer datafordeleren som serviceudbyder Krav vedrørende organisering K15: Organisationen omkring datafordeleren har driftsansvaret for distributionen af de udstillede data, herunder leverandørstyring, driftsrapportering, vejledning til databrugere, samt understøttelse af de løbende udviklingsbehov. K16: Organisationen omkring datafordeleren skal orientere de bagvedliggende registre, eller ansvarlige myndigheder når de bliver opmærksomme på fejl i data. Et ansvar som dog også gør sig gældende for øvrige myndigheder som opdager/bliver gjort opmærksomme på fejl K17: Organisationen har i tæt samarbejde med de involverede registre det overordnede ansvar for metodefællesskabet K18: Vedligehold for data vil foregå uændret, dog vil registermyndigheder have ansvar for at datafordeleren også modtager data når disse er opdaterede. K19: Registermyndigheder har fortsat ansvaret for at udstille services, hvorfra grunddata kan opdateres, når der er et distribueret ansvar for datavedligehold. K20: Databrugere skal tilgå de autoritative grunddata via datafordeleren, men myndigheder kan i forbindelse med opdatering tilgå data direkte fra kilderegisteret. Funktionelle krav: K21: Datafordeleren skal stille en hændelses-/abonnementsservice til rådighed: Altså en service, der kan distribuere beskeder om ændringer i objekter. K22: Datafordeleren skal stille services til håndtering af masseopslag til rådighed altså service der giver mulighed for at udtrække et stort datasæt - fx alle enheder i en kommune K23: Det skal være muligt at søge på tværs af data i datafordeleren og levere tværgående søgninger. K24: Datafordeleren skal stille en metadataservice til rådighed altså en service der giver mulighed for at hente informationer om selve services: Metadataservice skal understøtte discovery og inspection, fx som den løsning, der er etableret på geodata-info.dk K25: Datafordeleren skal etablere services, der giver mulighed for at udtrække statistik vedrørende driftstabilitet, forbrug (til understøttelse af fakturering), og yderligere forretningsrelevant statistik. Datafordeler arkitektur teknisk dialog 10