Arkivets rolle i en tjenesteorientert arkitektur. Thomas Sødring thomas.sodring@hioa.no. HiOA

Transkript

1 Arkivets rolle i en tjenesteorientert arkitektur Thomas Sødring thomas.sodring@hioa.no HiOA

2 Arild Haraldsen mener* Hvor langt har kommunene kommet i samordning av sine digitale tjenester? Hvordan går samspillet og samarbeidet mellom kommunal og statlig sektor? Hvor langt og hvor vellykket har KommIT som prosjekt vært med hensyn til å bidra til å nå resultater på de to spørsmålene ovenfor? Henviser til en IKT-Norge undersøkelse i kommunesektoren og konkluderer med at det ikke er grunn til å juble *

3 Arild Haraldsen mener Kommunal sektor er lite innovativ i å utvikle nye IKT- løsninger løsningen blir den samme som utgangspunktet, nemlig en «digitalisering» av den papirbaserte prosessen Kommunesektoren har derfor en betydelig utfordring i å være mer innovative Kommunene er selvstendige; det er ikke lett å få 428 kommuner til å samarbeide Men ennå viktigere er at kommunal sektor er dominert av noen få IKT-leverandører Kommunesektoren er derfor mer leverandørdrevet og -styrt enn statlig sektor.

4 Hva skal digitaliseres... en «digitalisering» av den papirbaserte prosess Men hva skal kommunen egentlig gjøre Pleie- og omsorg, Grunnskole, Administrasjon, Sosialtjenesten, Kommunehelse, Kultur, Barnehage, Barnevern, Samferdsel, Brann- og ulykkesvern Hva slags IT-innovasjon trenger vi her? Utenom å rive ned siloene Digitalisering kan redusere kostnader og frigjøre resurser Men den papirbaserte prosessen resulterer ofte i rettighetsdokumentasjon og skal i arkivet

5 Innovasjon Det er leverandørene som bestemmer hva kommunene kan kjøpe Et innovasjonsløst landskap en slags ørken av manglende innovasjon Alle kommunene burde ha en TOA og leverandører skal levere komponenter til denne Slutt å kjøp frittstående systemer Hvis vi løser opp i silo-problematikken så kan vi få mer innovasjon men flyten av metadata og dokumenter vil utfordre bevaring Hvordan er bevaringsprossen i en TOA?

6 Mr Jan Tore Sanner. Tear down this wall!

7 Hva er problemet? Problemet er at forvaltningen kjøper systemer som skal løse et bestemt behov Sektorløsning Data 'tilhører' forvaltningsorganet Tradisjonelt så tenker man ikke at andre kan ha bruk for disse dataene Det er en dynamikk i databehovene internt og på tvers av forvaltningsnivåene Om vi hadde løst dette i dag så ville det om kort tid måtte endres uansett

8 Interoperabilitet er løsningen Vi må akseptere at andre systemer kanskje trenger tilgang til disse dataene (i framtiden) Vi må forstå at dataene eksisterer i et økosystem og skal være en del av økosystemet Det er et ønske om interoperabilitet på tvers av forvaltningsnivåene (kommune, fylke, stat) Men systemene var ikke laget for dette

9 Interoperabilitet Interoperabilitet er den evnen og det potensialet forretningsprosessene med tilhørende IKT-løsninger har til å utveksle data og dele informasjon

10 Interoperabilitet Fire dimensjoner av interoperabilitet: Teknisk Systemer kan kommunisere og utveksle data Syntaktisk Systemer bruker standardiserte utvekslingsformater Semantisk Systemer 'forstår' dataene de utveksler Organisatorisk Prosesser mellom ulike systemer samkjøres

11 interoperabilitet Organisatorisk Semantisk Syntaktisk Organisatorisk Semantisk Syntaktisk Graden av interoperabilitet vil være avhengig av graden av strategisk synergi mellom de samhandlende organisasjonene Staten, fylkeskommunen og kommunene Teknisk Teknisk

12 Plattformavhengighet Den tradisjonelle modellen er hvor vi kjøper frittstående programvare på en bestemt plattform Vi blir fort låst til en leverandør og denne innlåsingen kan føre til tilleggskostnader senere Annen programvare utvikles utelukkende for en plattform Kan være vanskelig å komme vekk eller bytte plattform Kan ha en negativ effekt på konkurranse og dermed får vi høyere priser

13 LiMux München byttet ut MS-plattformen med en Linux-basert plattform Spare penger på lisenser Minske innlåsingseffekter Åpne for mer konkurranse blant programvareleverandører Ulike meninger om det er suksess, men et av hindrene er at dokumenter som kommer fra andre deler av forvaltningen i MSOOXML-format skaper problemer i LibreOffice Vurderer å bytte tilbake

14 Innlåsing i Oslo kommune I 2013 måtte Oslo kommune ut med et anbud på 3000 Windows Phone for Pleie- og omsorgsetaten Leverandør av et system kommunen trengte fungerer utelukkende på Windows Er det så galt? Leverandører priser produktene sine basert på hva markedet er villig til å betale Når monopolsituasjoner oppstår, går ikke prisen ned

15 Valg av plattform Mye av det forvaltningen produserer av brev er av en slik natur at de kunne skrives i LibreOffice Stort sett skrives disse i MS Office Forvaltningen trenger ikke MS Office men brukerne vil ha det Forvaltningen bør velge plattformen som gir mest for pengene Alt settes på anbud Hva koster slike avhengigheter?

16 Dokumentet et hinder? Dokumenter er en av de mest sentrale objektene som beveger seg fra Innbygger til forvaltning Forvaltning til forvalting Forvaltning til innbygger Produksjon, oppdatering og gjengivelse av dokumenter er essensielt viktig Hvis vi lar et dokumentformat låse oss til en plattform så har gjort oss selv en bjørnetjeneste Forvaltingen skal være plattform uavhengig

17 Sikre uavhengighet Forvaltningsstandarder prøver så godt de kan å sikre interoperabilitet Sektorløsninger (naturlig) lander på en plattform og vi må da leve med potensielle innlåsingseffekter Løsningen er først å tenke plattformuavhengighet JAVA, PHP, C++, Qt med flere Bruk på desktop varierer Deretter må vi tenke tjenester og internett

18 Frittstående programvare Start med å tenke på programvare som en tjeneste La oss si to stykker på kontoret trenger et program som konverterer MS DOC filer til PDF Bilde fra :

19 Frittstående programvare Da kjøper du dette enten som et frittstående program eller som en del av et annet program F.eks. en plugin til MS Office Etterhvert kjøper dere et nytt dokumenthåndteringssystem som automatisk konverterer DOC til PDF Systemet konverterer kun dokumenter som er i systemet fra før Nå betaler du dobbelt opp Disse snakker ikke med hverandre fordi de er frittstående systemer

20 Frittstående programvare Så kjøper du et fagsystem som kan håndtere skjemaer fra innbyggere innsendt på Internett Disse skjemaene blir til DOC-filer som må konverteres til PDF Dette fagsystemet kan ikke bruke PDF-konvertering fra de andre systemene Nå har du betalt for samme 'tjeneste' tre ganger Vi må se på behovene våre og kjøpe programvare som snakker til annen programvare og som oppfører seg som en tjeneste

21 Hva er tjenesteorientert arkitektur? Elektroniske tjenester rettet mot borgere og bedrifter/ næringsliv Virksomhet Et sett av arkitekturprinsipper for utforming av systemer slik at datautveksling enkelt skjer mellom komponenter Arkitektur En programmeringsmodell for utviklere når de lager systemer Programmering

22 Tjenesteorientering Tjenesteorientert arkitektur er et konsept der applikasjoner og automatiske prosesser får tilgang til informasjonsressurser gjennom standardiserte tjenestegrensesnitt, uten at det krever programmering eller kunnskap om systemene på lavere nivå Tjenesteorientert utvikling skal være et grunnprinsipp for all IKT-utvikling innenfor de problemstillinger som egner seg for denne tilnærmingen, og der resultatet skal være gjenbrukbart og deles mellom flere brukere

23 TOA Brukergrensesnitt Klienten nettverk Kjørbart program Applikasjonsserver Tjeneren Programdata Brukergrensesnittet er adskilt fra programmet og utveksler data med programmet via et standardisert grensesnitt Dette grensesnittet er en slags funksjonalitetskontrakt mellom brukergrensesnittet og programmet

24 TOA versus frittstående TOA Brukergrensesnitt Klienten nettverk Kjørbart program Applikasjonsserver Tjeneren Frittstående Brukergrensesnitt Kjørbart program Programdata Programdata

25 TOA Brukergrensesnitt Klienten nettverk Kjørbart program Applikasjonsserver Tjeneren Programdata I teorien kan du bytte ut enten brukergrensesnittet eller programmet uten å måtte endre det andre

26 Når alle snakker til alle... Applikasjon 1 Applikasjon 2 Applikasjon 3 Applikasjon 4 Applikasjon 5 Applikasjon 5

27 så blir det kaos!

28 Noe må holde orden Applikasjon 1 Applikasjon 2 Applikasjon 3 ESB Applikasjon 4 Applikasjon 5 Applikasjon 5

29 Noen områder til ESB Konvertere data fra ett format til et annet XML til REST XML til subset/superset av XML Virtuelt slå sammen tjenester så det ser ut som én tjeneste Håndtere transaksjoner Håndtere regler for data

30 TOA og ESB TOA handler om å bygge mindre og modulære programvarekomponenter der komponentene implementerer virksomhetsprosesser ESB handler om kommunikasjon mellom TOA-tjenester for å holde orden

31 ESB Du trenger ikke bruke en ESB bare fordi du bruker TOA F.eks. der det er kun to tjenester med samme protokoll Hvis det er en blanding av protokoller og flere tjenester, så er en ESB nyttig God planlegging forenkler framtidige endringer og videreutvikling

32 Felleskomponenter På mange måter blir disse TOA-instansene felleskomponenter Noen blir viktigere enn andre Autentiseringstjenesten Det digitale arkivet burde være en sentral felleskomponent i en slikt arkitektur Litt som i den analoge verden Alle dokumenter lagres i sentralarkivet

33 Arkivets rolle her Prosesser defineres i TOA og her bør arkivet ha en tilstedeværelse Spørsmålet jeg ønsker å jobbe med er: Hva er arkivets rolle i en TOA? Applikasjon 1 Applikasjon 2 Applikasjon 3 ESB Applikasjon 4 Applikasjon 5 Applikasjon 5

34 ESB komponent Applikasjoner n5kjerne Data broker (intern) Brukeridentifikasjon/ pålogging NAV POLITI Data broker (ekstern)

35 Prosjektet Innovasjonsprosjekt som skal resultere i en proof-of-concept demo Noark 5 kjerne KS Resultat-XML beskrivelser TOA buss (ServiceMix) Nettsky plattform (docker) Ingen komersielsering og jeg bruker ikke tid til å få noen til å det videre Sånn kan man gjøre det hvis du vil

36 Noen tanker Hvordan håndtere Rolle på tvers av applikasjoner Søk Hvordan håndtere sikker sone? Vanskelig å vite om teknologi valg er riktig Prosjektet kommer til å bli kritisert men det er proof-of-concept og kun det

37 Avslutning Kort prosjekt Egentlig snakk om 6-7 måneder Kildekode vil gjøres tilgjengelig fortløpende via github Enkel formidling av tanker og resultater