eNorge-planen krever at offentlige systemer samvirker effektivt. Offentlige myndigheter skal anvende hverandres data slik at samme informasjon ikke må oppgis eller kontrolleres flere ganger. En felles arkitektur er en mulig løsning på dette men vi tror ikke at én arkitektur for offentlig sektor er mulig. Til det er behovene for forskjellige. For å nå målene i eNorge, må arkitekturene som brukes samvirke og være beskrevet i en felles enterprise arkitektur. Målet med dette dokumentet er å beskrive etablering og forvaltning av et felles rammeverk for offentlige IT-arkitekturer1.
Offentlige sektor består i dag av mange adskilte teknologiske øyer hvor it-systemene historisk er utviklet for å løse en bestemt oppgave for en enkelt myndighet. Det er lite gjenbruk av data og funksjoner. Både medarbeidere og borgere bruker tid på å administrere data som kunne vært lest direkte fra andre systemer. Publikumstjenestene preges av at man kun har «elektronisfisert» eksisterende blanketter og informasjonsflyt. Dette har vært et viktig skritt mot digital forvaltning, men har også synliggjort et stort potensiale for effektivisering. Borgernes krav til forenkling og åpenhet vil vokse i takt med at stadig flere bruker internett mot private tjenesteytere. Offentlige it-oppgaver må løses felles og uavhengig av organisasjonsstrukturer. Dette forutsetter samarbeid om interoperabilitet og standardiserte grensesnitt mellom systemer. KomInn-serien setter fokus på interoperabilitet og en tjenesteorientert arkitektur med gjenbruk av data og funksjoner.
IT-systemer utvikles ofte etter et “best og billigst” prinsipp som betyr at kjøperen fokuserer på å dekke funksjonelle behov billigst mulig. Leverandøren realiserer arkitekturen ut fra sin egen produktportefølje. Resultatet blir IT-systemer som vanskelig kan integreres, og som er ressurskrevende å vedlikeholde. Kortsiktige funksjonelle krav er dekket mens andre langsiktige hensyn er nedprioritert.
En IT-arkitektur må dekke mer en ett enkelt system for å sikre samspill mellom systemene. Dette krever at det offentlige fokuserer på hele levetiden til systemene slik at fremtidige integrasjonsbehov kan løses uten omfattende nyutvikling. På samme måte må et felles rammeverk sikre integrasjon mellom ulike arkitekturer. En digital forvaltning kan ikke realiseres uten et felles rammeverk for IT-arkitektur.
Enterprise arkitektur er en helhetsplan for hvordan monolittiske løsninger kan konverteres til felles løsninger som oppbevarer data og utfører oppgaver for hverandre. En tjenesteorientert arkitektur sikrer at hvert system ikke belaster borgere, medarbeidere og it-systemer med vedlikehold av data som kan leses direkte fra andre systemer. Målet er at data opprettes og administreres ett sted via komponenter med åpne grensesnitt som gir andre komponenter tilgang til de data og funksjoner de har bruk for. Komponentene utfører felles oppgaver slik at forvaltningen ikke behøver utvikle og vedlikeholde funksjoner som allerede finnes i andre systemer. Ved å fokusere på likheter, kan data og funksjoner fra forskjellige områder implementeres i samme komponent. Et regelsett styrer hvem som kan gjøre hva med hvilke data.
Et mål for digital forvaltning er at hele offentlig sektor skal fremstå som ett sammenhengende
IT-system. Borgeren skal ikke merke at han bruker forskjellige komponenter som også anvendes til andre formål.
Arkitekturkrav øker konkurransen i markedet, gjør det lettere å sammenligne løsninger og gir mulighet for å kombinere moduler fra ulike leverandører. Kravene må inngå i de offentlige tilbudsforespørslene på lik linje med funksjonelle og operative krav.
Erfaringer viser at gjenbruk og felles arkitektur ikke kommer av seg selv. Mange prosjekter har hatt intensjon om å utvikle standarder og generelle komponenter, men et prosjekt styrt av lokale målsetninger har hverken økonomi eller evne til å forutse andres fremtidige behov. Felles løsninger må fra starten utformes som generelle komponenter hvor fremtidige systemeiere samarbeider om utvikling av grunnstrukturer og fleksibilitet.
Statens IT-politikk skal sikre at IT-investeringer skaper en åpen, effektiv og sammenhengende forvaltning. Et avgjørende innsatsområde er styrket samarbeid omkring IT-arkitektur på tvers av hele offentlig sektor. En felles statlig IT-politikk endrer ikke at hovedansvaret for utvikling av it-systemer, på samme måte som ansvaret for utvikling, organisering og arbeidsprosesser, fortsatt ligger desentralt.
I dag har de enkelte forvaltningsenheter kontroll over egne systemer og data. For å oppnå gevinster med en enterprise arkitektur, må man akseptere gjensidig avhengighet mot andre. Jo flere som samarbeider, jo større gevinster oppnår den enkelte. Jo større og færre tjenestefellesskap, jo færre systemøyer i fremtiden. Det grunnleggende suksesskriterium er et forpliktende tjenestefellesskap innen de store sektorene på tvers av stat, fylker og kommuner.
Det må etableres et sentralt organ i AAD for koordinering av prosjekter, innsatsområder og tjenestefellesskap. Organet må ha kompetanse om arkitektur og koordinere utvikling av nasjonale standarder, retningslinjer og verktøy for å sikre så store tjenestefellesskap som mulig. I tillegg må organet fokusere på grunnleggende tjenesteområder med grensesnitt til det meste av offentlig sektor.
Når en enkelt myndighet arbeider med enterprise arkitektur på konsernnivå, eller i et
tjenestefellesskap, må deltagerne inngå en forpliktende samarbeidsavtale om
fremtidige it-løsninger.
En enterprise arkitektur er en samlet plan for fremtidig arkitektur hvor ansvaret for de enkelte komponenter fordeles mellom fellesskapets komponenteiere. Fellesskapet lager også en plan for implementerings- og migreringsrekkefølge. Planen må tilgodese både arkitekturens og interessentenes krav og prioriteringer.
Etablering av felles løsninger krever at komponenteierne forplikter seg til å implementere komponentbrukernes fremtidige behov. Arkitekturen sikrer at komponenten fra starten er designet fleksibelt. Prisen for felles og billigere it-løsninger er at man ikke er alene om å styre sine IT-kostnader, men må være forberedt på å reagere på krav fra andre. Dette er en utfordring for budsjettering og ressursplanlegging, men sikrer at komponentene utnyttes og utvikles optimalt.
En felles tjenesteorientert arkitektur forutsetter at de enkelte områdene i offentlig sektor gjennomfører tverrgående arkitekturarbeid før man utarbeider anbudsinnbydelser. Mange vil hente arkitekturkompetanse hos private konsulentfirmaer. Men eksterne konsulenter kan ikke lede en arkitekturprosess som forutsetter mange felles beslutninger på tvers av forvaltningsenheter. Forvaltningen må ta ansvar for arkitekturprosessen og sikre at det er kompetanse og myndighet til å gjennomføre harmoniseringsbeslutninger.
Når arkitekturprosessen er gjennomført, er neste skritt ofte å innhente anbud. Resultatene må inngå i kravspesifikasjoner og anbudsmateriell. Komponentene kan implementeres hos enhver leverandør som overholder arkitekturbeslutninger og standarder. I statsforvaltningen vil det typisk kun være en instans av hver komponent, mens det på kommune- og fylkesnivå vil forekomme at samme funksjonalitet implementeres hos forskjellige leverandører.
Standarder kan virke konserverende. Offentlig sektor har behov for utvikling og å ivareta mangfold. Enterprise arkitektur gir rom for kreativitet og valgfrihet, samtidig som utviklingen styres i en retning. I dette kapittelet drøfter vi hvordan man oppnår dette.
Kravet til samvirkende løsninger forutsetter at følgende områder styres av arkitekturprinsipper.
Interoperabilitet
Sikkerhet
Åpenhet
Fleksibilitet
Skalerbarhet
Innen disse områdene vil nasjonale hensyn og standardbruk alltid overstyre lokale ønsker.
Interoperabilitet krever felles datamodeller og protokoller for utveksling av data. Alle spesifikasjoner lagres i et nasjonalt bibliotek (repository). Der en datadefinisjon finnes, skal den brukes av alle prosjekter. Videre skal nye datadefinisjoner som oppstår i prosjektet meldes inn til biblioteket.
Dette er nærmere beskrevet i rapporten KomInn XML.
Sikkerhetsløsninger må også samvirke. Felles sikkerhetsmodell er et krav for at ulike systemer skal kunne utveksle data. Norske myndigheter har besluttet å bruke elektroniske sertifikater som felles sikkerhetsmodell for offentlig sektor. Teknisk sett byr en slik løsning på få problemer, men troverdigheten i løsningen forutsetter at norske myndigheter tar et ansvar for å sikre allment tilgjengelige sertifikater av tilstrekkelig styrke.
Dette er nærmere beskrevet i rapporten KomInn PKI.
Samvirkende løsninger er hovedmålet med arkitekturen. Åpenhet er en forutsetning for at løsninger fra ulike leverandører skal samvirke. I kontekst av rammeverk og arkitektur refererer åpenhet seg til åpne grensesnitt, databeskrivelser og dokumentasjon av disse. Kravet til åpenhet må stilles både til “open source” produkter og proprietære løsninger. Ingen av delene er implisitt åpne eller lukket. Om et produkt er “open source” er irrelevant i en arkitekturbetraktning.
I forhold til det offentlige vil åpenhet avgjøres av om løsningen som vurderes er publisert og dokumentert i det nasjonale biblioteket som er omtalt ovenfor.
Dette er nærmere beskrevet i rapporten KomInn Standardisering.
Arkitekturen må sikre at løsninger kan gjenbrukes utenfor det enkelte prosjekt. Ofte må arkitekturen også ta opp i seg løsninger som allerede eksisterer, men som kanskje skal fases ut over tid.
Arbeidet med å fastlegge en arkitektur vil ofte avsløre potensiale for samdrift. God skalerbarhet er avgjørende for å ta ut stordriftsfordeler.
Dette er nærmere beskrevet i rapporten KomInn Konsept.
Plogen er en norsk rådgivingsorganisasjon som tilbyr et bredt spekter av profesjonelle tjenester innen IKT utvikling og anvendelse.
1Alle refererte rapporter fra Plogen er tilgjengelig under KomInn på Plogens hjemmesider (http://www.plogen.no)
- felles løft mot felles mål