Grunddatamodellen har snitflader til andre projekter og planlagte komponenter i den fællesoffentlige it-arkitektur. Disse snitflader er med til at opsætte rammer og formål for, hvordan modellen bedst udformes. Den fælles it-arkitektur er ikke nødvendigvis fastlagt eller stabil, og på samme måde må reglerne for modellering af Grunddatamodellen have et vist mål af dynamik for at kunne understøtte integration med den omkringliggende arkitektur.

I det følgende gennemgås en række af de elementer i den fællesoffentlige it-arkitektur, som har en direkte indvirkning på modelreglerne - primært for at danne referenceramme ved diskussion af formålet for de enkelte regler. For flere af elementerne gælder, at de ikke er færdigudviklede og i drift og dermed ikke udgør konkrete arkitekturkomponenter, som kan sætte præcise mål for Grunddatamodelleringen. Derfor indeholder de følgende afsnit en række antagelser, som er blevet lagt til grund for udformningen af modelreglerne. Antagelserne er baseret på dialog med de organisationer, som er ansvarlige for implementeringen af komponenterne, og er tilstræbt så tro mod intentionerne, som det har været muligt. Skulle antagelserne vise sig ikke at afspejle det fremtidige landskab, må det bevirke justering af modelreglerne.

3.2 Datafordeleren

Der er i regi af Grunddataprogrammet etableret en datafordeler, som effektivt og sikkert distribuerer data fra grunddataregistrene, læs mere på Datafordelerens hjemmeside. Data, som tilgås via Datafordeleren er også de data, som modelleres i Grunddatamodellen. 

Datafordeleren indgår i en modeldrevet arkitektur, hvor specifikationen af data håndteres i regi af modellen af data frem for i dokumentation, som er adskilt fra data. Datafordeleren understøtter distribution af hændelsesbeskeder og den udsender beskeder om datahændelser til en fremtidig beskeddrevet arkitektur EDA.

Nærværende dokument indeholder regler, som skal gøre det nemmere at konvertere de udviklede UML-modeller til andre typer datamodellering. I første runde sigtes der til, at gøre det muligt, at autogenerere XML Schema på baggrund af UML-modellen. På den måde kan det på sigt gøres muligt, at udvikle grænseflader, hvor databrugere selv sammensætter udtræk og datasnitflader på baggrund af modellen.

Autokonvertering af UML-modeller til XML Schema foregår for eksempel i øjeblikket i regi af INSPIRE. Samtidig vil det være muligt, at omtolke UML-modellen til RDF. RDF-modellen kan danne udgangspunkt for en række forskellig repræsentationer af data, ligesom den kan bruges ved udstilling af grunddata i en Linked Data/Semantic Web sammenhæng.

Yderligere indeholder dokumentet regler, som skal sikre, at data, der er nødvendige for at danne hændelsesbeskeder, er tilstede i Grunddata.

3.3 Den Fælleskommunale Rammearkitektur

I regi af KL og KOMBIT arbejdes der med, at implementere infrastrukturkomponenter som realisering af rammearkitekturens arkitekturbyggeklodser, der skal varetage generelle funktioner i forbindelse med opbevaring og udstilling af organisations-strukturer og andre typer af referencedata, se Den fælleskommunale rammearkitektur. Sammen med en beskedfordeler er disse komponenter i udbud. Modellering og anvendelse af grunddata kan effektiviseres betydeligt ved at anvende funktionalitet fra denne arkitektur, hvorfor modelreglerne er udfærdiget med hensyntagen til nedenstående antagelser om byggeklodserne og komponenterne.

3.3.1 Organisationskomponent

Standarderne for sag- og dokumentområdet beskriver en logisk struktur for, hvordan en given organisations organisering kan udstilles i et generelt format, som tillader eksterne systemer at referere til dele eller helheder i organisationen se Organisation. De refererbare aktører i organisationen kan være både specifikke (person, it-system, funktion) eller overordnede (afsnit, kontor, organisation). Enkelte kommuner har allerede implementeret systemunderstøttelse for organisationskomponenten, og KOMBIT forbereder et udbud af en generelt anvendelig komponent - se Den fælleskommunale rammearkitektur - støttesystemer.

Antagelser:

• Det antages, at organisationskomponenten bliver en permanent og entydig del af den offentlige it-arkitektur.

• Det antages, at staten vil anvende en tilsvarene komponent til udstilling af organisation.

• Det antages, at data om aktører i organisationskomponenten har identitet og bitemporale egenskaber, hvorved de kan anvendes distribueret.

Af disse grunde anbefaler reglerne i det følgende for eksempel, at information om den aktør, som er ansvarlig for dataobjektets registrering i databasen og for dets virkning, lagres og udstilles som en reference til en organisation, udstillet i en organisationskomponent.

3.3.2 Klassifikationskomponent

På samme måde planlægger KOMBIT (se Den fælleskommunale rammearkitektur - støttesystemer) at den fælleskommunale rammearkitektur skal indeholde en klassifikationskomponent - også beskrevet i Sag & Dokument-standarderne [Klassifikation].
Klassifikationskomponenten skal opbevare og udstille strukturerede data - taksonomier og grafer - som afspejler forretningsviden, der har en intern struktur og kan bruges til at give forvaltningsobjekterne kontekst. Eksempler er FORM (se FORM-online og KLE-online), som er strukturerede beskrivelser af det offentliges forretning. I forbindelse med grunddata, kan de strukturerede data anvendes til at give forvaltningsobjekterne kontekst og sammenhæng - for eksempel angivelse af hvilket forretningsområde, der er ansvarlig for opdateringen af data. Data, som opbevares i klassifikationskomponenten tildeles dobbelthistorik og revisionsspor, ligesom rammearkitekturen tilsigter distribution og opdatering af indholdet. Derfor er komponenten ideel til opbevaring af en lang række udfaldsrum - også simple lister.

Antagelser:

• Det antages, at klassifikationskomponenten bliver en permanent og entydig del af den offentlige it-arkitektur.

• Det antages, at staten vil anvende en tilsvarende komponent til udstilling af strukturerede data.

• Det antages, at de enkelte klasser i klassifikationskomponenten har identitet og bitemporale egenskaber, hvorved de kan anvendes distribuere.

Af disse grunde anbefaler reglerne i det følgende for eksempel, at et forvaltningsobjekts forretningsområde, forretningsproces og forretningshændelse (se regel 6.4), lagres og udstilles som en reference til strukturerede data, udstillet i en klassifikationskomponent. Forvaltningsobjektets status kan også udstilles ved brug af klassifikationskomponenten.

3.3.3 Beskedfordeler/Beskeddrevet arkitektur

Formålet med beskedfordeling er, at kæde administrative processer sammen på tværs af myndigheder. Når en administrativ forretningshændelse resulterer i en datahændelse, vil hændelsen ofte udløse en række andre administrative processer - typisk hos en anden myndighed. Relevante myndigheder skal derfor adviseres om datahændelsen ændringen i dataobjektet.

Beskeddrevet arkitektur handler om, at det skal være muligt for et brugersystem at abonnere på datahændelser - i form af en besked. Formålet er, at modtageren af beskeden, for eksempel et IT-system eller en sagsbehandler kan reagere på beskeden og igangsætte administrative processer som følge heraf. For eksempel kan en ændring i en persons adresse udløse en ændret ydelse (Effektiv Sagsbehandling og Kontrol (ESK) forudsætter en helt automatiseret løbende sagsbehandling, hvor en systemgenereret besked udløser en automatisk genberegning af for eksempel en ydelse). Dette forudsætter, at beskeder om ændringer i data kan distribueres på en meningsfuld måde, hvor det er muligt at opsætte filtre (abonnementer), som kan fordele beskeder til de relevante modtagere.

Indeholder beskeden kun oplysning om selve datahændelsen, vil modtageren selv skulle analysere sig frem til, i hvilket omfang hændelsen har relevans for modtagerens forretning. Ved en ændring af en persons adresse, er en sagsbehandler for eksempel nødt til at vide, om ændringen skyldes, at personen faktisk er flyttet, eller der blot er tale om at vejen har fået nyt navn. Langt større kvalitet opnås derfor, hvis beskeden indeholder informationer om den forretningshændelse (i virkeligheden), som udløste ændringen samt om det forretningsområde og den forretningsproces, som har været involveret i ændringen i data. Derved kan beskeden fordeles til den relevante anvender og indgå i en relevant proces i modtagerorganisationen. Automatiseret beskedfordeling kan derfor forudsætte, at disse informationer er til stede i den rigtige form, således, at de kan understøtte distributionen af beskeder.

Antagelser:

• Det antages, at datahændelser i grunddata skal afføde hændelsesbeskeder, som skal distribueres af Datafordeleren

• Det antages, at disse beskeder skal tilflyde den fælleskommunale rammearkitektur/serviceplatform

• Der gøres ingen antagelser om den infrastruktur, som skal udsende og modtage beskeder, hvorfor der ikke i dette dokument er yderligere behandling af teknisk protokol eller aftalegrundlaget for beskedfordeling.

Derfor opsætter regel 6.4 en række forslag til, hvordan datamodellen kan understøtte systematisering og udstilling af egenskaber ved datahændelsen (forretningshændelse, -område og -proces) som kan understøtte automatiseret beskedfordeling.