Introducing Nikita

Så langt har det vært veldig mye om prosjektet fra et overordnet perspektiv, nå må vi konkretiserer det litt mer. Jeg liker veldig godt fri programvare og dette kommer hovedsaklig fra et pedagogisk perspektiv og der er fri programvare fantastisk når det gjelder deling og videreutvikling av kunnskap. En konkret implementasjon av en ide som en programvare kan bety mye for forståelsen av den ideen. En standard kan fort mistolkes, men når du lager en programvare så er det ikke rom for en mistolkning. En implementasjon kan også påpeke svakheter og det vil da være lettere å ha en diskusjon om systemet faktisk løser de problemene systemet skal løse. Dette prosjektet bygger på fri programvare og vil resultere i fri programvare.

Prosjektet begynner med valg av en tjenestebuss. Mule pekte seg ut som en populær tjenestebuss, men jeg ble allikevel advart mot å bruke den. Dette var mest pga en personlig preferanse rundt dokumentasjon. Jeg leste meg raskt opp på dette med tjenestebusser og siden jeg forholder meg til fri programvare så var det ikke så mange å velge fra. Etter litt lesing valgte jeg Apache ServiceMix. Litt fordi en del av de andre teknologiene jeg ønsket å jobbe med kom fra Apache så jeg tenkte det kunne være like greit å forholde meg til Apache, men ServiceMix er også brukt som basis for JBOSS Fuse så hvis noen ønsker å ta dette prosjektet videre så er det mulig å gjøre det med teknologi der vi vet det finnes support. Så valget baserer seg mer på at det er det som føles riktig, og er ikke basert på en grundig undersøkelse. I utgangpunktet trodde jeg at ServiceMix var noe jeg ville programmere med, men har til slutt skjønt at ServiceMix er et produkt jeg skal jobbe med. ServiceMix er bygget på Apache Karaf som er en container for kjøring av programmer. Jeg tror dette er egentlig noe jeg har lett etter hele programeringslivet mitt og ble veldig glad da jeg fant det. Karaf gir deg en container som gjør at du kan bygge programvare inn i det. Hvis programmet trenger en liten webserver så kan du feks bruke jetty. Karaf lar deg gjør enkle ting som starte/stoppe programmene dine i containeren. Karaf kommer jeg definitivt bruke i senere prosjekter.

Det virker som om det mangler bøker om ServiceMix, så jeg kjøpte Instant Apache ServiceMix How-to, for å lære mer om ServiceMix. Ofte synes jeg Internett resurser blir for overfladiske og forventer en del forehåndsforståelse for å gjøre noe praktisk og nyttig. Bøker bruker mer tid til å gå i dybden. Boken er forsåvidt bra, men er egentlig bare en veldig overfladisk gjennomgang av hva ServiceMix er og hvordan du bruker det. Noe av det jeg kommer til å gjøre de nærmeste dagene er å komme i gang med ServiceMix basert på oppskriftene i boken. Det er mulig at jeg hadde høyere forventinger til ServiceMix fordi jeg egentlig ikke forsto hva ServiceMix gjorde.

ServiceMix skal være tjenestebussen i nikita. En tjenestebuss kan gjøre en del ting. Det første er å holde orden på kommunikasjonen og hvem som kommuniserer med hvem og hvordan. Her ser jeg for meg at all tredjeparts kommunikasjon til et fagsystem kan bli tvunget via tjenestebussen. Bussen skal også kunne omforme data. Så et system som bruker en SOAP-basert meldingsformat kan kommunisere med en tjeneste som bruker en REST-basert meldingsformat. Dette skjer ved at kommunikasjon går gjennom bussen og omforming fra feks JSON til SOAP skjer i bussen. Bussen blir en sentral node som ser nesten all datatrafikk. Faktisk gjør ServiceMix ingen av de ovennevnte tingene dvs omformingen osv, det blir håndtert av noe som heter Apache Camel.

Camel kan gjøre en del ting som å håndtere innkommende trafikk og route det til riktig sted og omforme et dataobjekt fra et format til et annet feks XML til JSON. Prosjektet vil innlemme ServiceMix og Camel men foreløpig ser det ut som om det vil brukes i liten grad. Det er fordi casen jeg bruker er begrenset til en domene og en snevert probleAmstilling innenfor det domenet. Det brukes allikevel i prosjektet fordi uten det har jeg egentlig bare en liten del av en tjenesteorientert arkitektur som kan ta tak i interoperabilitetsproblematikken. Foreløpig har jeg ingen god case på interoperabilitet, men det er noe som kan komme senere.

ServiceMix støtter Apache CXF, som er en bibliotek som går på webservices og det er noe som helt klart blir en sentral del av prosjektet. Både ServiceMix og Camel støtter/bruker Apache CXF, så jeg er usikker hvor de skal brukes. Det kan være at når du bruker Camel på toppen av ServiceMix så er det opplagt at det er Camel og Apache CXF som gjelder. Hvis du har en mindre komplisert arkitektur holder det kanskje med ServiceMix og Apache CXF.

Tanken så langt er at alle systemer og grensesnitter håndteres av tjenestebussen. Det jeg er ut etter er et sted i arkitekturen der prosessbeskrivelser, innsynsforespørsler, interoperabilitetsproblematikken og datakvalitet kan behandles. Dette blir en sentral node i arkitekturen og med dette får du de klassiske problemene med sentralisering. Hvis bussen blir hacket kan potensialt alt lekke ut og det kan også bli noe problemer med tanke på resursbruk og hvordan systemet kan skalere. Men dette er en forskingsprosjekt, ikke en kommersiell produkt. Disse spørsmålene ville måtte svares hvis det skulle realiseres som et kommersiell produkt.

Framover kommer jeg til å jobbe med følgende. Få ServiceMix i gang med Camel og viser en enkel transformasjon av data. Ta tak i en definert grensesnitt og få den i gang på toppen av Camel. Se nærmere på domeneforståelse og  brukerhåndtering. Jeg regner de fleste kommuner bruker ActiveDirectory så jeg må jobbe med noe som gjenskaper den funksjonalisten, utan at jeg må selv bruke ActiveDirectory.

Arkivet som premissleverandør av interoperabilitet

Sammen med Tor Arne Dahl hadde vi på høsten et emne som het Metadata og Interoperabilitet. Dette var noe nytt for meg og jeg lærte masse av å ha vært en del av prosessen med å utvikle og forelese på emnet. En av våre studenter var veldig bekymret rundt dette med økt interoperabilitet. Hva med alle dataene som kommer til å komme på avveie?  En venn fra Danmark fortalte at de har store problemer med personsensitivdata på avveie etter at de kom i gang med digitalisering. Samtidig var DIFI og Datatilsynet ut og delte noen tanker rundt dette med økt digitalisering.

Det ble en del fundering over denne problemstillingen. Hvem er det som tar ansvar for at data ikke kommer på avveie? Det virket som om DIFI egentlig ikke så det som et problem, dette vil løse seg selv. Datatilsynet var av en annen oppfatning og mer bekymret at det er en reel fare at personsensitiv data kan komme på avveie. Hvem er det egentlig som har ansvaret? Det blir nok IT-folkene. Jeg er utdannet IT-ingeniør og etikk og personvern var aldri en del av pensumet og selv om det er blitt bedre  er jeg usikker om det er blitt så mye bedre. Programvareutvikling er veldig dyrt og mye av det settes ut til andre land for å spare penger. Det er fullt mulig at vi kommer i en situasjon der vi tar tak i digitaliseringsproblemetikken uten at vi tar tak i personvernproblemetikken. Tanken ble forsterket med et innlegg på digi der jeg tolker en leverandør slik en at personvern er og blir en bi-tanke i digitaliseringsarbeidet.

Vi kan spørre hva som skjer i den virkelige verden hvis NAV eller andre (feks Politiet) vil ha informasjon fra et forvaltningsystem om en spesifikk person. De vil være nødt til å henvende seg til arkivet og spørre om denne informasjonen. En kommunal TOA vil være nødt til gjenskape prosesser fra den virkelige verden i den digitale verden på en effektiv måte. Igjen peker arkivet seg ut som en viktig del av arkitekturen. Arkivets rolle i en TOA vil være å tilrettelegge for at interoperabilitet finner sted på en trygg måte i henhold til lover og regler og har ansvar for å minimerer datalekasje. Da blir det kanskje slik at vi ikke løser interoperabilitetsproblematikken uten at vi løser arkivproblematikken og hvis vi slår disse to (interoperabilitet og arkiv) sammen i en TOA så løser vi kanskje mye av problemene kommunal forvalting står overfor.

Tjenesteorientering og grensesnitt handler langt på vei om å sikre en effektiv og smidig dataflyt mellom systemer, uten behovet for menneskelig interaksjon. Det blir veldig skremmende hvis systemer skal kobles sammen uten at noen tar ansvar for at dataene blir prosessert på en forsvarlig måte.

det opprinnelige prosjektet fikk en ny vinkling. Arkivet må ha en tydeligere rolle i en kommunal tjenesteorientert arkitektur og arkivet må være premissleverandør for interoperabilitet. Arkivaren vil ha ansvar for flyten av data inn og ut av arkitekturen. Dette er egentlig ikke så langt unna dagens situasjon der arkivet har ansvaret for innkommende og utgående dokumenter og vurdering av offentlighet. Bare nå øker omfanget av ansvaret til å inkludere informasjon for hele kommunen. Det er mulig at det har vært et ønske om dette, men datasiloene har gjort at arkivtjenesten ikke har fått utføre rollen sin tilstrekkelig. En TOA der arkivets rolle er tydelig gjør at arkivtjenesten endelig kan se bredden i informasjon de er ansvarlig for.

Med dette som bakteppe har prosjektet fått et nytt navn. Nikita – Noark basert Kommunal IT Arkitektur. Men det er fortsatt i tråd med det opprinnelige tanken «Hva er arkivets rolle i en tjenesteorientert?”, bare at arkivet blir selve arkitekturen og ikke bare en komponent i den.

Det er veldig mye som må utvikles her og uten friprog versjonen av dots (en tidlig utgave som ikke er godkjent som Noark 5-kjerne) så hadde jeg aldri prøvd meg engang. Denne vil nå bytte navn til nikita og være grunnlaget for det videre arbeidet.

Prosjektet skal fortsatt se nærmere på KS Resultat XML, men jeg er usikker om vi skal faktisk implementere det eller bare utvikle grensesnittet og delen som går på prosess beskrivelse og datakvalitet. Jeg ønsker også å se nærmere på automatisert avlevering til depot. TOA’n skal kunne fortløpende avlevere materiale til et depot (en IKA). Jeg var delvis involvert i forprosjektet til IKA Kongsberg og synes det hadde vært spennende å utvikle en prototype løsning som viser omfanget av dette.

Så dette med TOA altså …

Mange er enige at TOA er løsningen for å få til en effektiv og smidig forvaltning, men det virker som om det er vanskelig å gjøre noe med det. Mindre kommuner har simpelheten ikke råd til å sitte med TOA-arkitekter og det må være de større kommunene som baner veien og Bærum kommune har gjort seg bemerket på dette området.

Mange har stillt spørsmålet om hvordan vi kan få til økt digitalisering og et bedre nivå av interoperabilitet og svaret er tjenesteorientering. Tjenesteorientering er en anderledes måte å tenke programvare på. Vanligvis kjøper man et programvare som løser et behov innenfor en bestemt kontekst eller fagområde. Hvis du vil ha et sak/arkiv system så kjøper du det og  hvis du vil ha et system som håndterer barnehage søknader så er det det du kjøper. Disse programvarene løser behovene innenfor et fagområde og er ofte ikke laget til å snakke sammen. Tidligere var programvare ofte utviklet uten å tenke på  interoperabilitet og deling av informasjon og denne  foreldet utviklingsmodellen er en av hovedgrunnene vi har problemer med interoperabilitet.

modeller

Figur 1. Utvikling av programvareutvikling

Måten programvareutvikling har utviklet seg og kan sees i Figur 1 (a) til (c). Dette er nok en oversimplifisering, men allikevel relevant. I Figur 1 (a) ser vi  programvaren hadde direkte til databasen og programvarelogikken og brukergrensesnittet var veldig tett koblet sammen. På et tidspunkt ble dette endret og det ble utviklet et eget lag som utgjorde programvarelogikken. Dette vises i Figur 1 (b). De fleste systemene bruker denne modellen og det gjør det enklere å endre på programmeringslogikken uten å måtte endre på brukergrensesnittet. Figur 1 (c) viser en mer moderne tilnærming som er i retning av tjenesteorientering. Da lages det et eget grensesnitt på toppen av applikasjonslaget som brukergrensesnittet og andre programmer kan forholde seg til. Dette gjør at andre programmer kan bruke det aktuelle programmet uten at interaksjon må gå gjennom brukergrensesnittet. Et grensesnitt er er en type protokoll som synligjør og tilbyr noe av funksjonaliteten i progamvaren til andre.  

Det er kanskje ikke vanskelig å se hvordan Figur 1 (a) resultater i en situasjon der programvaren oppleves som en datasilo. Tilgang til data er kun via et brukergrensenitt og vi er da avhengig av interaksjon med et menneske for å få tilgang til dataene. Løsningen i Figur 1 (b) hjelper egentlig ikke situasjnen så veldig heller, men det vil være mulig å lage et grensesnitt til denne programvaren. Vi ser flere eksempler på dette i dag.  Løsningen i Figur 1 (c) har en tydelig grensesnitt som gjør at programvare kan snakke med andre programvare og dele data. Jeg tror veldig mange av programmene i bruk i kommunene er en enten som Figur 1(a) eller 1(b). Men er det noen som leverer programvare av typen vist i Figur 1 (c)? Noen leverandører har utviklet grensesnitt til programvaren sin, men i noen tilfeller er dette set på som ekstra funksjonalitet og kan være kostbart å ta i bruk.

Det vil være utfordrende og kostbart å gjøre noe med programvaren av typen som vist i Figur 1 (a). Programvarelogikken er låst i brukergrensesnittet og det må bygges et nytt applikasjonslag. Dette vil være eldre programvare som er sikkert moden for utskifting. Programvare av typen som vist i Figur 1 (b) er enklere, det er et applikasjonslag, men vi trenger et grensesnitt. De fleste leverandørene ville nok klart å lage en grensesnitt, men hvis ikke det er et standardisert grensesnitt (standardisert av en uavhengig organ) så løser vi bare en del interoperabilitets problematikken, det vil fortsatt være en kompleks arkitektur å forholde seg til og det vil være kunstige kostnader bundet opp mot tilpasninger og integrasjoner. Standardisert grensesnitt gjør at det blir enklere og dermed billigere for leverandører av tredjeparts programvare som må integrere med eksisterende programvare. Hvis kommunene kjøper programvare som er lik det som er vises i Figur 1 (c) så vil vi ha kommet et godt stykke på veien for å oppnå økt interoperabilitet.

Dette er også en av grunnene hvorfor det er vanskelig å komme i gang med tjenesteorientering. Leverandører er ikke tjent på denne modellen. De selger ofte et programvare som et produkt  med en tydelig merkevare. Produktet er ofte en helhetlig produkt som inkluderer dokumenthåndtering, integrasjon med ePost osv. De er ikke tjent med at sitt produkt skal bli redusert til en komponent i en tjenesteorientert arkitektur. Merkevaren blir utvannet og statusen nedjustert. Så det kan være vanskelig å få leverandører i markedet over på denne tankegangen.

Det kan virke som om det er bare å skaffe en tjenesteorientert arkitektur og så er du i gang. Jeg tror ikke det er så lett. På samme måte som vi lager en modell av en ny bydel før vi går i gang med utbygging, er vi også nødt til å gjøre en modelleringsjobb før vi går i gang med en implementasjon av en TOA.

Og det er her jeg tror det vil være mange forskjellige meninger om hva som skal gjøres, valg av plattform, valg av funksjonalitet osv. Det er nok ingen entydig fasitsvar på en kommunal TOA, men det er mulig å lage modeller som kan brukes som grunnlag for diskusjon og en endelig implementasjon. Jeg har en hypotese at mye av IT-funksjonaliteten en kommune trenger er knyttet til dokumenthåndtering på et eller annet nivå. Det er bare å se på lovverket, offentlighetsloven bygger på et dokumentbegrep. Arkivloven og saksdokument blir veldig mye noe som ligner en digital versjon av et A4-ark. Riksrevisjonens rapport på kommunale arkiv peker på mye rettighetsdokumentasjon som er låst i fagsystemer, som igjen ofte ligner på et A4-ark. Dokumenthåndtering må være det sentrale funksjonalitet i en kommunal IT-arkitektur.

Så det bør være mulig å utvikle en konkret arkitektur, dvs skissere, delvis implementere og teste den. Hvis vi gjør det så kan dette bli gjenstand for forskning og diskusjon og her kan UH-sektoren spille en stor rolle og det er her jeg velger å prøve meg på en implementasjon av en TOA der dokumenthåndtering  og rollen til arkivet blir et sentral element. Noark standarden vil være en veldig godt grunnlag for en slik arkitektur og legge føringer for funksjonaliteten som TOA’n må tilby. Det vi egentlig snakker om her er å gjøre selve TOA’n til en type Noark kjerne. Dette er egentlig ikke en ny tanke. Jeg hørte at NAV har også jobbet med Noark på denne måten. Hvorvidt det har vært en suksess er jeg usikker.

Beveger vi oss i retning av TOA?

I November, 2014 hadde Digi en artikkel om samordning i offentlig sektor.  Fagsystemer må kommunisere med hverandre sier Ingelin Killengreen. Hvis jeg har forstått det riktig så skal det ikke utvikles nye fagsystemer, men alle de forskjellige applikasjonene skal tvinges til å kommunisere med hverandre. Applikasjoner som snakker med hverandre vil da generere trafikk og dette må håndteres på en eller annen forsvarlig måte som gjør at data ikke kommer på avveie.

På en måte kan datatrafikk sammenlignes med biltrafikk. Hvis det ikke er regler og en koordinering av trafikken blir det kaos, slik som vi ser i Figur 1.

800px-Moscow_traffic_congestion

 Figur 1. Uregulert trafikk skaper kaos (C)

En eller to applikasjoner kan, relativt sett, lett videreutvikles til å snakke sammen. Det kan utvikles grensesnitt (SOAP/REST-baserte) som standardiserer kommunikasjon mellom applikasjoner. Et grensesnitt er en standardisert protokoll en applikasjon kan bruke til å kommunisere med en annen applikasjon. Det vil være  av stor betydning  hvordan disse applikasjoner var utviklet for å få til et grensesnitt. Hvis en del av funksjonaliteten i en applikasjon er utviklet i brukergrensesnittet og ikke i et eget virksomhetslogikklag så må det først utvikles et virksomhetslogikk lag, og det kan være kostbart. Det vil være en utfordring å få forvaltningens applikasjoner til å oppføre seg som tjenester som kan brukes i en TOA og en av de største utfordringene her være brukeridentifikasjon (autentisering og autorisasjon) fordi en del applikasjoner  er utviklet med egne måter å håndtere brukere.

I Figur 2  ser vi at applikasjonene får et grensesnitt som gjør det mulig å kommunisere med hverandre. Det er denne situasjonen DIFI ønsker å oppnå.  Bare dette enkle bildet der seks applikasjoner potensielt skal kommunisere viser deg seg at det fort kan bli komplekse trafikkmønstre. For å bedre forstå utfordringen offentlig sektor står overfor må du også ta høyde for hundrevis av applikasjoner  på tvers av forvaltningsnivåer (dvs kommunikasjon over Internett som betyr kryptering), ufullstendige prosesss beskrivelser og innlåsing til plattformer og dokumentformater for å nevne noen.

TOA kaos

Figur 2. Applikasjoner med grensesnitt

Men det er ikke en umulig oppgave å løse. Løsningen ligger i begrepet TOA eller  tjenesteorientering. TOA er blitt påpekt som løsning i mange år, men det er få som har klart å ta det ordentlig i bruk og oppnåd stor suksess med det. Bærum kommune tror jeg har kommet lengst med TOA.

En TOA er en måte å organisere alle diss eapplikasjonene på slik at de kan snakke sammen. Det første steget for å komme i gang med TOA må være å utvikle grensesnitt  for de forskjellige applikasjonene. Etter dette bruker vi en tjenestebuss som regulerer trafikken. Bussen kontrollerer trafikken og omformer data ved behov. På engelsk heter dette en Enterprise Service Bus (ESB).  Figur 3 viser hvordan situasjonen i Figur 2 blir langt mer ryddig når vi setter inn en ESB for å kontrollere arkitekturen.

TOA ESB

En tjenestebuss/ESB brukes til å holde orden på en komplisert arkitektur bestående av mange kommuniserende applikasjoner/tjenester.  Jeg  ble introdusert til buss-konseptet for et par år tilbake og må innrømme at det var vanskelig å forstå det. Når du ser et bilde av en ESB så virker det som om det er en fysisk ting, feks en kabel som kobler forskjellige systemer sammen. I realiteten er det bare en programvare installert et sted i nettverket ditt som styrer og kontrollerer kommunikasjon mellom tjenester. I stedet for at systemer snakker direkte med hverandre så snakker de med ESB’n.

Jo mer jeg ser på utfordringene i offentlig sektor jo mer jeg blir overbevist om at det vi trenger er en standardisering av en kommunal tjeneste orientert arkitektur. Dette er en viktig felleskomponent som kommunene burde utvikle.

Men den største utfordringene som oppstår når systemer begynner å snakke sammen er at det øker sjansen at informasjon kommer på avveie. Digi har hatt en par artikler (1, 2) der vi ser konsekvensen av en offentlig sektor som åpner opp. Dessverre må vi nok leve med at data kommer på avveie i det offentlig sektor digitaliseres.  Med økt digitalisering kan vi aldri sikre oss at data kommer på avveie, men vi sørge for at personvern kommer først.

 

 

Figur 1 er hentet fra Wikipedia og brukes under Creative Commons Attribution-Share Alike 3.0 Unported. (c) Nevermind2.

 

Personvern først

Før jul var det en interessant artikkel på digi. Et punkt som bekymrer meg når man snakker om digitalisering i offentligsektor er dette med personvern. Det virker som om det er en holdning at det egentlig ikke er så farlig, det ordner seg. Det er nesten som om teknologi er viktigere enn mennesker.

Det som jeg reagerte veldig på og som var grunnlaget for kommentaren min i disqus var følgende:

“IT-sikkerhet og personvern knyttet til økt digitalisering vil man alltid kunne sette spørsmålstegn ved. Dette er viktig og må adresseres, men er mulig å løse.”

Det er noe ubehagelig med denne uttalelsen. Det virker som om man skal først løse et digitaliseringsproblem og la personvern og IT-sikkerhet være noe som vi tar senere, ved behov, hvis det virkelig trengs.

Økt digitalisering vil utfordre personvernet  og det er  mulig å løse det. Ja, men da burde vi løse det først før vi går i gang med en storstilt digitalisering. Personvernsproblematikken burde være en av de viktigste forsknings områdene akkurat nå.

Poenget i kronikken er god, tidsriktig og det er fint å se store leverandører som Evry pushe denne type tankegang. Men eksemplene som blir brukt handler om å flytte data og inkluderer personsensitiv data. Det er feil at ikke personvern er det viktigste elementet når man snakker digitalisering.

Skal vi prioritere personvern  eller digitalisering? Svaret er selvfølgelig “ja takk, begge deler”, men da må vi mene det. Da kan ikke personvern være noe som er mulig å løse, det må være noe som man må løse først eller i hvertfall som en hoveddel av digitaliseringsarbeidet. Dette gjenspeiler egentlig utvekslingen Datatilsynet og DIFI hadde nylig på digi om personvern og deling. Jeg tror Datatilsynet er redd at det er for mye fokus på digitalisering og at det ikke nok fokus på personvern og IT-sikkerhet. DIFI mener kanskje at vi må få fortgang.

Det finnes nok av rapporter som forteller oss hvordan  sektorløsninger ødelegger for interoperabilitet og det siste vi trenger nå er å utvikle nye sektor løsninger. Kommunene trenger først og fremst å utvikle en IT-infrastruktur som legger til rette for deling av informasjon der personvern og IT-sikkerhet er prioritert.  Deretter kan denne brukes som et grunnlag for digitalisering. Det siste vi trenger nå er at kommunene begynner å bygge løsninger der man låser prosesserer, dokumenter og metadata i proprietære sektor løsninger. Det må tenkes arkitektur først.