SERES II-prosjektet - Brønnøysundregistrene
SERES II-prosjektet - Brønnøysundregistrene
SERES II-prosjektet - Brønnøysundregistrene
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>SERES</strong> <strong>II</strong>-<strong>prosjektet</strong><br />
<strong>SERES</strong> - Semantikkregisteret for elektronisk samhandling – skal tilby verktøy og metoder for<br />
definisjon og bruk av metadata (data om data) som omfatter semantiske definisjoner<br />
(meningsinnhold) og informasjonsstrukturer for data som skal utveksles/brukes elektronisk<br />
med og innen offentlig sektor, dvs. mellom offentlige institusjoner, mellom det offentlige og<br />
privatpersoner, og mellom det offentlige og kommersielle/ideelle virksomheter.<br />
<strong>SERES</strong> er forventet å bidra til å realisere og forbedre/effektivisere en rekke av de pålagte oppgaver<br />
som <strong>Brønnøysundregistrene</strong> har, men kan også bidra tilsvarende for hele offentlig sektor. <strong>SERES</strong> <strong>II</strong><strong>prosjektet</strong><br />
ble startet høsten 2007. Prosjektet er en oppfølger til <strong>Brønnøysundregistrene</strong>s TORprosjekt<br />
som utviklet den opprinnelige <strong>SERES</strong>-løsningen. Årsaken til reorganiseringen og<br />
refokuseringen i <strong>SERES</strong> <strong>II</strong>-<strong>prosjektet</strong> var bl.a. funn knyttet til skalering og ytelser i foreslått løsning<br />
og behovet for å spisse arbeidet med henblikk på eksisterende produksjoner i Altinn. Løsningen som<br />
utvikles har beholdt navnet <strong>SERES</strong>. Det påpekes imidlertid at resultater og erfaringer fra TOR<strong>prosjektet</strong><br />
har vært viktige innspill i <strong>SERES</strong> <strong>II</strong>-arbeidet.<br />
<strong>SERES</strong> <strong>II</strong>-<strong>prosjektet</strong>s hovedformål er å bidra til å gjeninnsette nødvendig funksjonalitet og<br />
modernisere metadataforvaltningen som del av Oppgaveregister-operasjonen, som også inkluderer<br />
metadataleveranser i form av meldingsspesifikasjoner (XSDer) til Altinn for Skattedirektoratet<br />
(SKD). I gjennomføringen av dette arbeidet var det også nødvendig å forstå relevante<br />
problemstillinger knyttet til samordning, samarbeide og samhandling, og gjennom dette finne en<br />
plass og en forankring i det utredningsarbeidet som pågår rundt norsk eForvaltning og samhandling.<br />
En prioritert oppgave i <strong>SERES</strong> <strong>II</strong> har derfor vært å søke tillit og forankring internt i<br />
<strong>Brønnøysundregistrene</strong> og ellers i offentlig sektor. Prosjektet har vært synlig på ulike arenaer som<br />
seminarer, fagforum, samt på offentlige og eksterne prosjektarenaer. Det har vært dialog med ulike<br />
offentlige aktører – for eksempel SKD som er en viktig samarbeidspartner for<br />
<strong>Brønnøysundregistrene</strong>. Krav fra SKD var den direkte foranledning til valg av prosjektfokus i<br />
<strong>SERES</strong>-arbeidet, se punkt 1 i opplistingen under.<br />
Følgende figur gir et svært overordnet, men viktig, bilde av de ulike funksjonsområdene for <strong>SERES</strong>,<br />
og de omgivelser man ønsker at <strong>SERES</strong> skal spille på lag med. Det er repositoryløsningen som er<br />
kjernen i løsningen – med ulike klientverktøy rundt, herunder modelleringsverktøyene. Detaljer om<br />
hvilke eller hvor mange verktøy eller programvarekomponenter som skal løse de ulike<br />
funksjonsområdene er bevisst utelatt.<br />
Modellvalidering<br />
Tjeneste & Analyse<br />
Konfigurasjoner ,<br />
Endringer , Versjoner<br />
<strong>SERES</strong> Funksjonsområder<br />
Modellering &<br />
Modeller<br />
Repository<br />
Metadata<br />
Sikkerhet<br />
XSD<br />
Generator<br />
OMGIVELSER<br />
ALTINN<br />
OPPGAVEREGISTERET<br />
OVERVÅKNING,<br />
Begreper<br />
OFFENTLIGE<br />
ETATER<br />
KOMMUNAL<br />
SEKTOR<br />
BEDRIFTER, PRIVATE<br />
<strong>SERES</strong> <strong>II</strong> KLIENTER
<strong>SERES</strong> <strong>II</strong>-<strong>prosjektet</strong> har gjennomført en rekke aktiviteter i ulike delprosjekter. Her er en kort<br />
presentasjon av fire av de viktigste:<br />
1. Metadatafangst fra Oppgaveregisteret (OR) og produksjon av metadataløsninger for Altinn;<br />
Metadatafangst fra Oppgaveregisterets (OR) meldingsspesifikasjoner. Disse<br />
meldingsspesifikasjonene foreligger på XML-form som XSD-er (heretter kalt ORxsd-er).<br />
Følgende figur som illustrerer prosjektgjennomføringsplanen, forklares ikke i detalj i dette<br />
dokumentet.<br />
<strong>SERES</strong>-<strong>II</strong>: XSD<br />
ORxsd<br />
Informasjonsmodell<br />
Kjernemodell<br />
ORetat<br />
Domenemodeller<br />
XSD-dokument<br />
Generator<br />
ORxsd<br />
XForms<br />
<strong>SERES</strong>-<strong>II</strong>: meldings<br />
XMI<br />
OR-skjemaobjekt<br />
(XML)<br />
Meldingsmodeller<br />
OR - metadata & andre<br />
Transformasjon<br />
ORxsd<br />
Transformasjon<br />
XMI<br />
<strong>SERES</strong> <strong>II</strong> Fase 1:<br />
ALTINN I<br />
Forenklet figurforklaring: Figuren viser hvordan man ved å tolke eksisterende ORxsd-er og<br />
oversette (transformere) innholdet i den til en <strong>SERES</strong> informasjonsmodell via XML 1 - baserte<br />
meldingsformater. Oversettelsesreglene er definert ved bruk av hyllevareverktøy og åpne XMLbaserte<br />
W3C-standarder som XML, XSD 2 , XSLT 3 og UML 4 s XMI 5 . I den resulterende <strong>SERES</strong>informasjonsmodellen<br />
legges det vekt på å frikople data- og presentasjonsrelaterte deler av ORxsdene<br />
slik at man får et godt og mer strukturert utgangspunkt for å videreutvikle, forbedre og ikke<br />
minst gjenbruke deler av informasjonsmodellen. Det har vært viktig å sikre at det ikke er tap av<br />
informasjon i noen steg i denne prosessen. Selv om det for noen virker overflødig, har det derfor<br />
vært viktig å regenerere ORxsd-er både når man har oversatt ORxsd-en til et ORskjemaobjekt<br />
(internrepresentasjon) og videre til en informasjonsmodell.<br />
2. Kravinnhenting for <strong>SERES</strong> <strong>II</strong>-løsning; Det har vært gjennomført en omfattende og systematisk<br />
runde med innsamling, behandling og detaljering av krav. Arbeidet har i hovedsak fokusert på<br />
bruksrelaterte og funksjonelle aspekter ved løsningen. Dette arbeidet har resultert i to<br />
kravspesifikasjoner: en for <strong>SERES</strong> <strong>II</strong> verktøyportefølje og en for <strong>SERES</strong> repositoryløsning.<br />
Arbeide med kravene for øvrige løsninger pågår kontinuerlig.<br />
1 XML – eXtensible Markup Language<br />
2 XSD – XML Schema Definition<br />
3 XSLT - Extensible Stylesheet Language Transformations<br />
4 UML – Unified Modeling Language<br />
5 XMI – XML Metadata Interchange
3. Konseptskisse for <strong>SERES</strong> <strong>II</strong>-løsningen 6 : Det har vært gjennomført en faglig utredning som har<br />
resultert i en konseptskisse for modelleringsarbeidet i <strong>SERES</strong> og <strong>SERES</strong> som løsning. I tillegg<br />
gir dokumentet en oversikt og analyse av problemområdet samordning, samarbeide og<br />
samhandling. Hovedelementer i konseptet er:<br />
a. Introduksjon av nav-eike-prinsipp for å bidra til å redusere antall<br />
integrasjonspunkter, hvor eikene knytter hver av aktørene mot et felles nav.<br />
Sammenknytninger kan skje på flere nivåer. For eksempel kan navet være kilde for<br />
felles definisjoner, tilby oversettertjenester for distribusjon fra datakilde til<br />
abonnenter (eikene representerer da transformasjonsrutinene), orkestrere<br />
funksjonelle tjenester som er tilbudt av ulike aktører, tilby tjenesterepository for<br />
automatiserte tjenester (for eksempel web services) hvor ulike aktører kan registrere<br />
tjenester, og tjenestebrukere kan finne aktuelle tjenester eller ev. dokumentere<br />
behov/krav til nye tjenester, utstede digital id og sertifikater.<br />
b. Et sett med ulike, relaterte informasjonsmodeller på ulike abstraksjonsnivåer<br />
(begreper, begrepsstrukturer og meldingsstrukturer) for ulike formål og for ulike<br />
modelleiere (domene- og kjernemodeller).<br />
c. Transformasjonsprinsipper for oversettelse mellom domenemeldinger via<br />
kjernemelding.<br />
d. Prinsipp for unike identifikatorer som er tolkbare både for menneske- og maskin.<br />
4. Kompetanseoppbygging; Det har vært viktig for <strong>prosjektet</strong> å bygge opp kompetansen i den<br />
innledende fasen. Dette har vært gjort gjennom deltakelse på interne/eksterne seminarer, kurs,<br />
gjennom deltakelse i prosjektaktiviteter og med støtte og veiledning av arkitektur- og<br />
modellekspertgruppe (AEG og MEG). Deltagelse i Semicolon-<strong>prosjektet</strong> har også vært en<br />
prioritert oppgave. Det har også vært viktig å utnytte synergien med andre prosjekter. Parallelt<br />
med <strong>SERES</strong> <strong>II</strong>-<strong>prosjektet</strong>, har <strong>Brønnøysundregistrene</strong> gjennomført et modelleringsprosjekt med<br />
Kommunal- og regionaldepartementet (KRD) som oppdragsgiver. I <strong>prosjektet</strong> skulle metadata<br />
relatert til KOR-/KOSTRA-skjemaer modelleres. Dette <strong>prosjektet</strong> har hatt nyttige<br />
synergieffekter med <strong>SERES</strong>-<strong>prosjektet</strong> både i forhold til kompetanseoppbygging relatert til<br />
modellering og utarbeidelse av modelleringsprinsipper og mønster («patterns») for å understøtte<br />
modelleringen. Som en felles ressurs mellom prosjektene ble det etablert en <strong>SERES</strong>wiki med<br />
mye relevant informasjon som felles vokabular, retningslinjer, modelleringspatterns m.m.<br />
Motivasjon for semantikk i samhandling<br />
Det foregår elektronisk samhandling innen og med offentlig sektor i dag. Omfanget av slik<br />
samhandling er begrenset. Årsaken til denne begrensningen er sammensatt; slik som manglende<br />
kunnskap om lokalisering av data, manglende kunnskap om eksistensen av data, manglende<br />
tilgjengeliggjøring av data, ikke minst manglende systemstøtte for lesing av dataene. Det fleste<br />
datautvekslinger skjer mellom parvise aktører. Typisk mottas store datamengder i såkalte «batch»filer.<br />
Dataene importeres så og lagres på annen form i datamottakers systemer, og i flere tilfeller<br />
holdes kopidataene hos datamottaker à jour uten at kvalitetsforbedringer/ endringer tilbakeføres til<br />
dataansvarlig enhet. I noen tilfeller får mottager for mye data - i andre tilfeller ufullstendige data. I<br />
tillegg er det direkte kostnader knyttet til bruken av grunndata. For eksempel,<br />
<strong>Brønnøysundregistrene</strong> betaler årlig et større beløp (ca. kr.1 400 000) for å motta ukentlige data fra<br />
Folkeregisteret. Andre etater betaler tilsvarende beløp. Samlet fører disse forholdene til redusert<br />
datakvalitet, noe som igjen fører til redusert saksbehandlingskvalitet. Ulike utfordringer relatert til<br />
håndtering av data i det offentlige har derfor store konsekvenser for effektivitet, kvalitet og kostnad.<br />
Siden data representerer en kjerneverdi i offentlig saksbehandling, må målet være å fjerne alle<br />
elementer som direkte hindrer en videre utvidelse av offentlig samhandling.<br />
6 «Konseptskisse for <strong>SERES</strong>», v. 1.0, <strong>Brønnøysundregistrene</strong>, 11.6.2008
Læren om meningsinnhold av enkeltord og sammenstilte ord i setninger kalles semantikk.<br />
Semantikken brukes som grunnlag for kategorisering og strukturering av informasjon. En<br />
informasjonsmodell er en strukturbeskrivelse av ulike typer ting/fenomener/objekter innenfor et<br />
valgt interessefelt og med en etablert semantikk. Informasjonsmodellen defineres ved bruk av et<br />
beskrivelsesspråk som kan være tekstlig, grafisk eller en kombinasjon av disse. Uttrykkskraften i<br />
språket varierer, og noen språk er spesielt utformet for en gitt bruk og derfor spesielt velegnet for<br />
dette. En informasjonsmodell kan også beskrive hvordan ting oppfører seg i bruk, og eventuelt<br />
hvordan tingene implementeres og presenteres på maskiner.<br />
Når to eller flere mennesker eller maskiner samhandler, utveksler de informasjon. For å lykkes i en<br />
slik informasjonsutveksling er det fundamentalt at partene har den samme forståelse av hva<br />
informasjonen betyr. Metadata brukes for å sikre at to samhandlende aktører (menneske/menneske,<br />
menneske/maskin eller maskin/maskin) har lik forståelse av det de samhandler om. Uten kjente<br />
definisjoner og oppfatninger av hva informasjonen betyr og brukes til, kan man ikke være sikker på<br />
riktig fortolkning av den. Dermed reduseres informasjonskvaliteten, selv om informasjonen i seg selv<br />
er riktig. Dette medfører gale beslutninger!<br />
I et samhandlingsperspektiv skilles det mellom følgende problemområder: organisatorisk, semantisk<br />
og teknisk interoperabilitet, hvor «Semantisk interoperabilitet» omfatter evne til samhandling basert<br />
på felles forståelse av prosesser, tjenester og presentasjon – i tillegg til lik forståelse av<br />
informasjon/data. Fornyings- og administrasjonsdepartementet (FAD) sier i FAOS-rapporten 7 at<br />
felles metadatadefinisjoner for grunndata er et godt eksempel på tiltak for å etablere felles forståelse<br />
av data.<br />
For å tilby full interoperabilitet i elektronisk samhandling kreves mer enn å legge et stort datasett på<br />
en fil, tilgjengeliggjøre datasettet for de som måtte være interessert i innholdet, og tolke, oversette og<br />
kopiere innholdet lokalt. Når dataene inneholder feil rettes de oftest lokalt uten at rettelsen meddeles<br />
dataforvalter. Hvorfor kan man ikke hente akkurat de dataene man trenger når man trenger dem,<br />
samt tilbakemelde feil/mangler på en enkel og effektiv måte når man oppdager dem? Vrimmelen av<br />
lokale kopier av informasjon som ikke er innbyrdes «synkronisert» medfører at ukorrekte og<br />
foreldede data blir brukt i stor utstrekning. Dette er til stor ulempe for alle parter. En døgnåpen<br />
offentlig forvaltning forutsetter at informasjonen flyter effektivt mellom etater og brukere. Det er<br />
dessverre få av dagens løsninger som oppfyller slike krav.<br />
Tenkt eksempel: I forbindelse med en ulykke ringes det inn til en alarmsentral og det oppgis adresse,<br />
skadeomfang etc. Informasjonen videreformidles til ambulansen. Uheldigvis har det oppgitte<br />
gatenavnet endret seg nylig og kartgrunnlaget som brukes for navigering er ikke oppdatert med<br />
forandringen. Ambulansen finner ikke umiddelbart ut hvor de skal dra og livsviktig tid går tapt.<br />
<strong>SERES</strong> er til for elektronisk samhandling i offentlig sektor<br />
<strong>SERES</strong> er uavhengig av teknologivalg for samhandlingsløsningen, men<br />
skal tilby metoder og verktøy for å definere innhold og struktur på<br />
dataflyten i samhandlingen – uavhengig av om dataene f.eks. utveksles i<br />
en tjenesteorientert løsning, batchfilorientert løsning eller dataene leveres<br />
elektronisk på en CD. <strong>SERES</strong> bidrar til å høyne kvaliteten i<br />
samhandlingen ved å understøtte etableringen og bruken av metadata, og<br />
gjennom gradvis bedring av datakvaliteten som et resultat av en<br />
systematisk gjennomgang av de metadata som inngår i dagens<br />
rapporteringsløsninger.<br />
7 FAOS= Felles IKT-arkitektur i offentlig sektor<br />
<strong>SERES</strong><br />
Begrepsdefinisjoner<br />
<strong>SERES</strong> meldingsspesifikasjoner<br />
(f.eks. <strong>SERES</strong> XSD)<br />
Til bruk i f.eks.:<br />
•Funksjonelle tjenestegrensesnitt<br />
• eBlanketter<br />
•eDialoger/eProsesser<br />
•dataleveranser som batchfil,<br />
på CD e.lign.
Ideen er at når en aktør tilgjengeliggjør elektroniske data for andre, skal denne være utformet på en<br />
standard måte i henhold til en meldingsspesifikasjon, og med forklarende metadata som del av<br />
dataene. En slik samling av data kalles som regel en melding, for eksempel melding som et XMLdokument.<br />
Metadataene må være beskrevet et sted hvor alle som utvikler og vedlikeholder<br />
datasystemer for å sende informasjon eller motta informasjon, kan hente de detaljene de trenger.<br />
<strong>SERES</strong> tilbyr støtte for å utvikle meldingsspesifikasjonene i sin løsning. Beskrivelsene er laget som<br />
informasjonsmodeller. Disse er laget for ulike formål og på ulike abstraksjonsnivåer avhengig av<br />
hva de skal beskrive; dvs. om de beskriver a) begreper og sammenhenger mellom dem, b) generelle<br />
og gjenbrukbare informasjonsstrukturer for domener og kjernen, eller c) om de beskriver konkret<br />
datainnhold og struktur på elektroniske dokumenter.<br />
Når det gjelder c), støttes for tiden XML-baserte meldingsspesifikasjoner i form av XSDdokumenter.<br />
Både XML og XSD er basert på åpne W3C 8 -standarder. Om fremtidige behov skulle<br />
tilsi at flere notasjoner/ standarder skal støttes så er løsningen utvidbar slik at en ny generator for<br />
disse kan inkluderes. Dette gjøres ved at det defineres et generelt grensesnitt som alle generatorer<br />
støtter, men hvor resultatet (output) er i henhold til valgt språk (XML Schema eller andre) (jf.<br />
adapter pattern).<br />
Neste figur viser ulike XSD-er som definerer lovlige struktur for meldinger som kan sendes til eller<br />
mottas fra aktørers systemer via såkalte funksjonelle tjenestegrensesnitt i en tjenesteorientert<br />
arkitektur.<br />
Ulike XSDer for ulike<br />
datautvekslinger<br />
XSD-er<br />
for elektronisk<br />
samhandling<br />
Samvirkende tjenester<br />
Melding inn<br />
Funksjonell tjeneste 1<br />
Melding ut<br />
Melding inn<br />
Funksjonell tjeneste 2<br />
Melding ut<br />
Merk at når en funksjonell tjenestes ut-melding ikke «matcher» neste tjenestes inn-melding, må<br />
bruker definere hvordan oversettelsen mellom ut- og inn-meldingene skal gjøres. Forskjellene kan<br />
gjelde hvilke begreper (termer) som er brukt, datastrukturer og formater på dataverdiene. <strong>SERES</strong><br />
skal tilby støtte for å definere slike oversettelsesregler via en kjernebeskrivelse, jf. nav-eikeprinsippet.<br />
Slike modeller kan for eksempel utarbeides i samsvar med Object Management Groups<br />
(OMGs) standard Common Warehouse Metamodel (CWM).<br />
8 W3C – World Wide Web Consortium, www.w3c.org