5 Integrasjon av IT-systemer for elektronisk samhandling

5.1 Bakgrunn

5.1.1 Prosesser, skjermdialoger, saksflyt og rutiner

5.2 Modeller og metoder for integrasjon av datasystemer

5.2.1 Informasjonsutveksling og samhandling

5.2.2 Ulike typer integrasjon

5.2.3 Resultat XML.

5.2.4 Noark 4 Webservices (N4WS)

5.2.5 Mellomvare

5.2.6 Relevante tiltak

5.1 Bakgrunn

Kommunene tilbyr borgere og næringsliv en rekke tjenester, og disse blir nå i økende grad gjort tilgjengelige elektronisk. Det setter økte krav til kommunens håndtering av datafangst, integrasjon og informasjonssikkerhet.

Datafangst og bruk av informasjon fra datafangst må tilpasses behovet til den enkelte virksomhet. Behovene varierer sterkt ut fra virksomhetenes forvaltningspraksis, systemportefølje, arbeidsrutiner mv., og dette får igjen følger for hvordan de må legge opp integrasjonen mellom sine systemer.

5.1.1 Prosesser, skjermdialoger, saksflyt og rutiner

Innføringen av et elektronisk skjema i en organisasjon vil by på ulike utfordringer spesielt når man skal få skjema og skjemadata inn i kommunens ulike system som sak/arkiv og fagsystem.

De enkelte skjema er også avhengig av en dokument- og informasjonsflyt som ivaretar kravene til saksbehandlingsrutiner, journalføring, sikkerhet og andre forhold.

Et elektronisk skjema er bare en av flere prosesser rundt utøvelse av en tjeneste, men ulik grad av elektronisk behandling vil ha stor innvirkning på tjenesteleveransen. Utnyttelse av teknologi, integrasjon av skjemadata, automatisering, gjennomgang og forenkling av rutiner er viktige faktorer for å etablere kostnadseffektive tjenester.

Et elektronisk skjema kan settes inn i en verdikjede som kan se slik ut:

Figur 1: Modell prosess/saksflyt for en elektronisk tjeneste. Kilde: Smaalensveven

For å kartlegge ønsket elektronisk skjemaflyt, hvilke system og instanser som er involvert og hvilke automatiske og manuelle rutiner som blir berørt ved mottak og behandling av et elektronisk skjema er det nyttig med en prosesskartlegging.

I prosesskartleggingen vises de ulike roller og funksjoner som er involvert, hva hver instans har ansvar for og utfører og visualiserer skjemaflyten gjennom organisasjonen og ulike elektroniske system.

Skjemaflytmodell:

Kilde: http://www.beste-praksis.no/ddo/BestPractices.aspx?bu=75756&req=1⟨=1&scale=100&fit=False&node=100154&type=0

Se leveransen fra prosessgruppen for mer informasjon om dette emnet.

5.2 Modeller og metoder for integrasjon av datasystemer

5.2.1 Informasjonsutveksling og samhandling

Ved elektronisk samhandling ønsker to eller flere aktører å samhandle for å oppnå et felles mål. Denne samhandling forutsetter kommunikasjon. Kommunikasjon igjen forutsetter koding og dekoding av budskap og dette budskapet må være egnet til å oppnå målet. Dette kapittelet blir supplert av kapittel 4 "Beskrivelse og anbefaling av tekniske løsninger" i sluttdokumentet fra sikkerhetsgruppa[1].

Når en enhet i en kommune trenger data fra andre for å gjøre sin saksbehandling/ tjenesteproduksjon er det i kommunal sektor vanlig å velge en av følgende prinsipper for å dekke databehovet:

- Utveksling: Data kopieres eller flyttes fra et system til et annet

- Innsyn: En saksbehandler i enhet A, får adgang til å se på og bruke data i et system hos enhet B, uten at data kopieres eller utveksles. Enhet B kan være for eksempel en annen kommune eller fylkeskommune.

Realisering av disse to prinsippene er teknisk forskjellige. En prosessmodell for saksbehandling må høyst trolig ta hensyn til om det ene eller andre prinsippet velges. Således kan en se på valg av prinsipp som et eksempel på at teknologivalg påvirker måten vi kan designe prosessmodeller.

Videre vil vi fokusere primært på utvekslingsprinsippet. Ved utveksling av data mellom systemer kan man dele dette prinsippet opp i flere ulike elementer som er:

1. Representasjon av data som gjør dem egnet for utveksling (XML, Resultat XML, Pdf, tekstfiler, jpg bildefiler, etc.)

2. Transport av data fra et system til et annet (FTP, WS, http, etc.)

3. Kvitteringsmekanismer mellom systemene (sende bekreftelse på at data er mottatt)

4. Sikkerhetsmekanismer (sikre konfidensialitet, integritet, autensitet, sporbarhet)

Per i dag har vi noen spesifikasjoner og standarder som beskriver utveksling av data som dekker ett eller flere av disse nivåene. Eksempler på slik er Noark4 web-services[2] eller BEST[3].

5.2.2 Ulike typer integrasjon

For at data som er samlet inn etter utfylling av et elektronisk skjema skal komme fram til og bli importert på en vellykket måte hos riktig mottakersystem, er det tre hovedområder som det må tas stilling til. Hvert av disse punktene blir diskutert videre i egne dokumenter fra prosjektets sikkerhetsgruppe.

5.2.2.1 Transport

Med dette menes de ulike transportmetodene som er mulig å benytte for å overføre Resultat XMLen og PDF-filen på.

5.2.2.2 Transformasjon

I de aller fleste tilfeller må resultat XMLen avbildes eller transformeres til en XML-fil på en form som mottakersystemet forventer og forstår.

5.2.2.3 Import

Når Resultat XMLen og PDF-filen fra datafangsten har kommet til mottakersystemet, og er på riktig format, er filene klare for import inn i mottakersystemet.

5.2.3 Resultat XML

På samme måte som vi bruker norsk grammatikk til å beskrive reglene for hvordan et stykke norsk prosa kan settes sammen av ord, benytter vi Resultat XML til å beskrive regler for hvordan XML dokumenter skal representeres og settes sammen. Et stykke norsk prosa vil bruke ord fra en norsk ordbok, tilsvarende vil Resultat XML bruke sine ord fra en ordbok. Hittil i arbeidet har ord/begreper fra Noark-standarden og SERES grunndata blitt benyttet.

Når en kommune skal ta i bruk et nytt fagsystem er det ønskelig at dette fagsystemet enkelt kan integreres med andre systemer både i kommunen og systemer hos tilretteleggere som skjemaleverandører etc. I kommunal sektor har integrasjon stort sett vært basert på utveksling av data, og da de senere år ved bruk av XML for å representere data. Utfordringen er at systemleverandørene har benyttet XML på ulike måter, dvs de har ikke benyttet en felles ordbok, så Babels tårn[4] har igjen klart å vokse opp. Det er nå et pågående initiativ fra KS for å lage anbefalte måter å for hvordan XML skal benyttes. Det er blitt laget forslag til Resultat XML som er modeller for hvordan data som utveksles skal representeres i XML.

Ytterligere motivasjon for og eksempel på Resultat-XML er beskrevet i eget Appendix.

5.2.4 Noark 4 Webservices (N4WS)

Det er etablert en nasjonal standard for elektronisk datafangst samt utveksling av dokumenter/informasjon mellom sak/arkiv-systemer og fagsystemer og grensesnitt mot publikumsorienterte portalløsninger. Standarden er døpt Noark-4 Web Services og er publisert på Riksarkivets hjemmesider og på KS IKT-forum. Riksarkivet har adoptert standarden som anbefalt utvekslingsformat til/fra Noark-baserte arkivsystemer, og det er antatt at utvekslingsformatet vil inngå som en del av det pågående arbeidet med å fornye Noark-standarden til Noark-5. KS har forpliktet seg til å fremme bruk av standarden og bistå til videreutvikling i tråd med medlemmenes behov. Standarden er utviklet med tanke på kommunale tjenester, men er også anvendelig for fylkeskommunal- og statlig sektor. Tjenestene er avgrenset til metode for at fagsystem skal kunne

- arkivere direkte i arkivsystem

- spørre etter data fra arkivsystem

Alle de fire sertifiserte leverandørene av Noark-baserte sak/arkiv-systemer i kommunesektoren har deltatt i standardiseringsarbeidet og har kvalitetssikret kode og meldinger gjennom pilotering og test i multi-leverandørmiljøer. Noark-4 WS er allerede implementert i standard produksortiment hos alle leverandørene.

De fire pilotarenaene i prosjektet har suksessfullt idiftsatt løsninger basert på bruk av Noark-4 WS:

- Arendal kommune, EDB-gruppen og portalleverandør har etablert byggesaksportal med selvbetjent byggesaksbehandling inkludert implementering av Noark-4 WS for informasjonsutveksling mellom sak/arkiv - portal - fagsystem. MinSide-løsning med innsyn i egen byggesak er implementert.

- Kristiansand kommune har satt i drift webbaserte søknader for støtte til frivillige organisasjoner basert på løsninger fra Software Innovation, Idavall fagsystem, Oracle BPEL prosessmanager og Noark-4 WS.

- Lillesand kommune har i samarbeid med sin leverandør, ACOS, totalintegrert 12 selvbetjeningsløsninger direkte mot sak/arkiv basert på utvekslingsformatet Noark-4 WS. Tjenestene er samtidig prosessmodellert og prosessmodellene danner basis fo arbeidsflytstøtte i saksbehandlingen og statusoversikt i MinSide.

- Lyngdal kommune benyttet KS-standarden, Noark-4 WS for sikker og effektiv utveksling av dokumenter mellom Lyngdal kommune og Fylkesmannen i Vest-Agder - spesifikt klagesaker relatert til byggesøknad. Samtidig uttviklet og testet de åpen integrasjon mellom sak/arkivsystemer og kartsystemer basert på WFS standarden og åpne URL-spørringer.

5.2.5 Mellomvare

Mellomvare kan defineres som en programvare som muliggjør utveksling av data mellom heterogene systemer. Istedenfor å lage en integrasjon fra a til b, lages det en integrasjon fra a til mellomvaren, og deretter fra mellomvaren til b. I mellomvaren ligger logikk som definerer hvem som er sender og hvem som er mottager av dataene. Dermed unngår man punkt-til-punkt integrasjon, som er svært kostbart både å bygge og vedlikeholde.

Når mange kommuner nå har etablert elektroniske tjenester vil behovet for en mer omfattende mellomvareløsning bli mer fremtredende. Mange kommuner har et stort antall systemer som i utgangspunktet ikke er knyttet godt nok sammen. Flere leverandører har laget enkelstående løsninger for integrasjon mellom for eksempel skjermdialog og arkiv. Denne typen «punkt til punkt» integrasjon er lite hensiktsmessig, spesielt når man søker å sette sammen prosesser som er avhengige av flere systemer. Erfaring viser at denne typen integrasjonsløsniger også er kostbare både å utvikle og drifte. Flere kommuner jobber nå aktivt med å kartlegge prosesser knyttet til elektroniske tjenester, og disse knyttes til eksempelvis fagsystemer, portal og arkiv. En mellomvareløsning vil være basert på en SOA-plattform som kan skalere fra en liten kommune med enkle behov, til de største kommunene med komplekse prosesser og datautveksling.

Flere store kommuner som Bærum, Oslo og Bergen har i større eller mindre grad laget egne løsninger hvor mye av funksjonaliteten burde kunne gjenbrukes av andre kommuner. Dette vil representere store gevinster i prosjekter hvor man utvikler en mellomvareløsning med utgangspunkt i en fri programvareplattform. Det finnes mange alternative plattformer, men det er kun et fåtall som kan regnes som gode alternativer med utgangspunkt i de behov man finner i kommunesektoren. JBoss og Mule er mellomvare plattformer som er brukt i store prosjekter i offentlige sektor både i Norge og andre land. Bærum kommune har valgt Mule som utgangspunkt for sin SOA-plattform, dette vil være et godt utgangspunkt for en kommunal mellomvareløsning. Effekten av slik gjenbruk vil være størst hvis denne løsningen designes og utvikles med tanke på gjenbruk helt fra Bærum kommune starter sin utvikling. Et prosjekt hvor man bygger videre på erfaringen fra prosjektet «Tjenester på nett» for utvikling av piloter for gjenbruk av denne type løsning vil kunne danne grunnlaget for en kommunal mellomvareløsning basert på fri programvare.

5.2.6 Relevante tiltak

FADs stortingsmelding nr. 17[5] peker mellom annet på en sentral formidlingssentral som en komponent i en felles arkitektur for offentlig virksomhet. I denne sammenhengen kan den ses på som et mellomsteg for oversending, eventuelt også oversetting, av informasjon mellom eksempelvis skjermdialogløsninger og fagsystemer eller sak-/arkivsystemer.

Figur hentet fra FADs St. meld. nr 17 (2006-2007) "Eit informasjonssamfunn for alle" s. 121

[1] http://ksikt-forum.no/haandboker/sikkerhetshandbok_for_tjenester_pa_nett

[2] http://www.arkivverket.no/noark-4/Noark-4_Web_Services1.pdf

[3] http://www.efylke.no/hovedEnkel.aspx?m=33802

[4] http://no.wikipedia.org/wiki/Babels_t%C3%A5rn

[5] http://www.regjeringen.no/nb/dep/fad/dok/regpubl/stmeld/20062007/Stmeld-nr-17-2006-2007-/7/3/2.html?id=441579