Choices made on the road to 0.1

You can drive yourself mad wondering if you made the right choice with regards to technology. This really is a difficult question to answer as you have to pick components that have longevity and that are in widespread use. The truth is that you just have to pick something and go with it. I think about popularity of libraries, how active development is etc before I make a choice but it’s not easy to just decide. Any component I use now will follow the project and code for a long time going forward.

This week I was wrestling with AngularJS and ReactJS. Basically it boils down to whether or not  I go with Google or Facebook. I picked up some cheap courses on Angular and that kinda made that decision. I’m not really that bothered by the GUI side of things at the moment, but I do need an administrative GUI and would like to have an idea how a proof-of-concept GUI would look. Given that this is a REST service, it will be possible to swap Angular out with whatever you want anyway. It is a very time consuming process trying to figure these things out.

The last month has been spent wondering how I should structure the project. If I get the foundation wrong, it will have a negative effect on the project.  Baeldung has an interesting project structure with a clean definition of modules and what should be within the modules. This quickly became the basis of my project structure. I kept coming across jhipster and after days of hassle (installing npm, bower, yo) getting it installed I managed to get an interesting project setup. What I learnt from the jhipster sample app was support for swagger, metrics, spring-security, angulaJS and yaml project configuration. I was initially unable to get the jhipster app to run so I have spent the time studying the code and structure and gradually copied elements over to my project. This has resulted in the nikita code base supporting swagger, the introduction of metrics support, and spring security  user configuration, all copied from  the jhipster sample application.

This approach has really saved me a lot of time and answered many questions about spring and spring-based applications. I have learnt so much from this approach. A plus with such an approach where I try to study best practices is that I hopefully will end up with a good project structure and robust code. A negative is that I’m learning as I go along. Ideally I’d sit down and figure everything out in advance but I think that’s the primary reason why it has been difficult to move this project forward over the last couple of years, I never had my own concrete project structure to work with and was unsure how to proceed.

I also switched coding from Eclipse to Eclipse STS to IntelliJ Idea.  I never seemed to be able to get things working nicely in Eclipse and STS. I always ended up with issues like it wasn’t possible to find   source code when debugging  or download sources and documentation didn’t work properly. I spent a lot of time on stackexchange but it really felt like a waste of time and I didn’t have an environment I felt comfortable and productive in. Idea has been a dream to work with. It just does things intuitively and the integration with git has allowed me to push code and changes quickly to githhub. I have never been so impressed with an IDE as I have been with Idea. It just seems to make sense.

I was also able to confirm that OData support is still in the draft version of Noark 5 v4 and will more than likely be in the final version. This complicates development of the REST-service significantly but I think I will solve this in the  codebase by supporting two apis, one with OData and one without. The reason for this is that OData support requires me to handle all incoming HTTP requests manually. To be honest I am unsure about the usefulness of  OData in a running installation, but if the standard specifies it then we simply will have to implement it. There is very little REST OData support in the java ecosystem, but there is something available that we can use.

Currently the code is very much a pre alpha version of v0.1. It  is mainly a working  project structure with the above mentioned libraries and  with the domain model copied in and the fonds object is accessible via a REST controller. Don’t expect the code to work until it hits the v0.1 mark as I am updating it continuously. You can check out the code from the github repository.

Current project structure

One of the main challenges with this project is that I am not in a position to work on it full time. In the last month I have probably spent 80 hours and half of that is coming from my own free time. So whatever time I do have has to be spent wisely. I have few days to thoroughly explore issues and threads of thoughts are split up over several days.

In the last month I have made some interesting progress. I have spent the time working on the project structure and have moved files around quite a lot.

Currently the project is a multi module maven project with the following modules

  • core-client
  • core-common
  • core-conversion
  • core-extraction
  • core-webapp

core-client is where most of the domain modelling of Noark 5 can be found. All persistence related objects are here, DTO’s etc.

core-common contains a lot of common functionality related to REST handling etc. This is code that could be reused in other Noark 5 REST related projects.

core-conversion will be a REST-service that can convert documents from a production format to an archive format. I will only implement integration to LibreOffice but it is easily imaginable to implement integration to MS Office. I haven’t started this yet.

core-extraction will be a standalone executable jar that can extract the contents of the core in accordance with the extraction rules. Currently a weak arkivstruktur.xml generator has been implemented and that’s just to show a proof-of-concept.

core-webapp is the actual web application that is a spring-boot application and starts up a REST service.

Another module that needs to be implemented will be core-postjournal that talks to the database and publishes postjournal  in various formats. Integration with altinn and digipost etc (core-dispatcher) all are obvious candidates for work, but currently the project needs a clear defined roadmap so these can all come later.

All the modules are encapsulated inside a parent module called nikita-noark5-core.

Roadmap to version 1.0

Det er vanskelig å få til progresjon i prosjektet når man ikke jobber med det på heltid. Prosjektet får kun oppmerksom når jeg ikke har undervisning og på en måte er det håpløst å jobbe sånn, men når vi ikke har ressurser så må det bli sånn.

Dette semesteret (Vår, 2016) har jeg også begrenset med tid da jeg underviser MBIB4140 Metadata og interoperabilitet og det tar mye av oppmerksomheten. Jeg har gitt meg selv et hårete mål å komme i mål til sommern. Jeg tviler jeg rekker det, men jeg ønsker å sette et strek for dette prosjektet og er nødt til å sette strek en eller gang.

N5-kjerne prosjektet har vært gjennom flere runder med utvikling og har sakte blitt bedre. Jeg begynner med grunn versjonen fra 2013. For det meste er det annotert datamodell som er nyttig der. I fjor lagde vi kdrs-toolbox-innsyn,  en prototype noark 5 “kjerne” med spring/spring-boot. Dette var et forsøk på få på plass en forståelse hvordan REST og kjernen vil samhandle og koden er å se på som en alpha utgave av en innsynsløsning for Noark 5 uttrekk. Vi lagde også en prototype for en Noark 5 uttrekk validator og et program som kan importere et Noark 5 uttrekk for innsynsløsningen.

I januar satt  jeg og grublet lenge hvordan jeg skal komme videre. Spring er et fantastisk verktøy og gir deg veldig mye av det en Noark 5 kjerne trenger. Det finnes mye annet som er relevant som er laget av Apache og det å lage en Noark 5 kjerne basert på fri programvare og som fri programvare er langt mer realistisk i dag enn for noen år tilbake.

Nå har jeg valgt å gjøre hele prosjektet om til et spring prosjekt. Det tror jeg var en bra avgjørelse da jeg merker at progresjon nå ikke er så vanskelig. Men jeg synes spring er utforende å lære om. Så jeg kjøpte meg tilgang til et Spring kurs som har gitt meg veldig mye kunnskap om det å bygge profesjonelle spring applikasjoner. Det kommer en oppfølger som går på sikkerhet som jeg også kommer til å benytte meg av. Disse kursene anbefaler jeg til alle som har lyst til å begynne å lære om spring.

Så nå er jeg i gang med utviklingen. Jeg jobber opp mot Noark 5 tjenestegrensesnittet og det ser for såvidt greit ut. Det som bekymrer meg litt er kravet til implementasjon av OData filtrene. Det virker ikke som om det er noe enkel implementasjon av dette med spring-rest. Men det finnes et bibliotek for Jersey. Det virker som om utviklingen er aktiv så kanskje dette kan være løsningen.

Jeg velger nå å publisere en  Roadmap to version 1.0.  Disse versjonen vil publiseres her når de er klare.

0.1 Datamodellen implementert, arkiv via REST
0.2 Tjenestegrensesnittet implementert – REST
0.2.1 Støtte for OData syntaks
0.3 Indrekjerne funksjonalitet
0.4 Ytrekjerne funksjonalitet
0.5 Påloggingsmodul implementert,
0.6 Uttrekksmodul ferdig utivklet
0.7 Konverteringsmodul (til arkivformat)
0.8 JUnit testing
1.0 Versjon 1.0 Beta

Jeg er godt i gang med versjon 0.1. Jeg bruker spring-kursets oppsett som et mal og får et veldig godt oppsett med mye nyttig kode. Uttrekksmodulen er kommet i gang og vi klarer alt nå å lage arkivuttrekk.xml. Konverteringsmodulen er en viktig modul og vil for vår del være en REST-tjeneste som sitter på toppen av LibreOffice for konvertering.

Utviklingstrategien er å bruke tjenestegrensesnittet som mal for arbeidet. Dette vil etterhvert føre til versjon 0.4 og da skal vi se på integrasjon med påloggingtjenester. Feide er naturlig i første omgang.

Jeg tør ikke definere hvor lang tid jeg skal bruke på dette. Men spring gir meg veldig mye enterprise funksjonalitet så jeg tror ikke det trenger så mye arbeid. Framover kommer jeg til å skrive om hvordan utviklingen går og hvilken biblioteker jeg har valgt.

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.


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.


 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.


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.

Første runde med innspill

Jeg deltok på kdrs dagene i Trondheim fra 12. til 13. November 2014 og som vanlig var det en god blanding av det faglige og det sosiale. Jeg presenterte prosjektet og har fått mye gode tilbakemeldinger.

Prosjektet er fortsatt som beskrevet, men jeg har blitt utfordret til å tenke anderledes , dvs å ikke være bundet opp mot den tradisjonelle forvaltnings terminologien.

Så bort med ting som saksmappe, journalpost, sakspart og korrespondansepart og inn med mere abstrakte enheter som en kontekst og en aktør. En kontekst kan sees på som en abstraksjon av saksmappe eller en journalpost og en aktør er en sakspart eller korrespondansepart. Det kan være lurt å bryte med en terminologi som er sterk bundet opp mot Noark da det kan være lettere å integrere andre fagområder. Det betyr ikke at vi går bort fra Noark, det vil være en tydelig arkivstruktur der de tradisjonelle arkivenhetene er synlig, men vi vil ‘mappe’ (engelsk begrepet to map som betyr å kartlegge)  mer abstrakte digitale objekter tilbake til Noark. En annet positiv side av en slik tilnærming er at det åpner for å utvikle den underliggende datastrukturen i RDF. Dette er ikke noe jeg i utgangspunktet er komfortabel med, men allikevel er en spennende dimensjon. Dette innspillet kom fra Trondheims miljøet med Jean-Phillipe Caquet i spissen.

Ole Myhre Hansen fra Riksarkivet tipset om XMP og jeg er enig at det ville være interessant å se om det er noe som kan brukes og/eller videreutvikles. Men jeg er litt usikker i hvilken grad ODF/MSOOXML/OOXML støtter XMP. Jean Philippe påpekte at det er veldig mye metadata i feks et Word dokument som automatisk kan brukes i en registrering/journalpost og vi burde se om vi kan automatisere informasjon uthenting sammen med dokumentfangsten.

Et annet spennende forslag fra Hansen var at arkitekturen burde ha en type feltbank koblet til seg. Noark 5 metadataktalogen er et godt eksempel på en feltbank som er knyttet til et veldig spesifikk fagområde. Det er mange elementer fra en generell feltbank som kunne gjenbrukes i forskjellige fagområder feks tittel, oppretteDato osv. En slik feltbank vil også være gjenstand for mye diskusjon og forskning.

Dette kan være en viktig element for at prosjektet kan realiseres utenfor en akademisk ramme og faktisk gjøre det enklere å utvikle systemer som kan kobles til arkitekturen. Andre som ønsker å utvikle et fagsystem eller lignende kan slå opp i feltbanken og få en beskrivelse og veileding til bruk av metadata elementer. Mine første tanker her er å se på standarder som inngår i DIAS prosjektet og Noark 5. Spesielt PREMIS og METS tror jeg vil ha en del elementer som kan gjenbrukes.

Etter diskusjonen sitter jeg igjen med  assosiasjoner til programvare patterns der man utvikler generelle gjenbrukbare løsningsforslag til ofte møtt problemstillinger. Da snakker vi om å lage patterns som kan brukes i prosesss modellering (BPM) i arkitekturen.

Del med måte

Det var en liten debatt på som poengterte viktigheten og utfordringer rundt  deling av informasjon . Lillian Røstad argumenterer at deling er ikke farlig og faktisk kan det være viktig fra et personvernstandpunkt.  Trude Talberg-Furulund svarer med dette som en slags “del med måte”-oppfordring. Jeg oppfatter at begge er for deling og at begge mener at man må være forsiktig. Den varslete opptrapping av digitaliseringsarbeidet i offentlig sektor vil medføre stor risiko for at data kommer på avveie, det er ingen tvil om det og i de kronikkene over ser vi kanskje utålmodigheten til DIFI til å komme i gang og lidenskapen til Datatilsynet til å sikre personvernet.

Det finnes mange eksempler der data kommer på avveie. Når du velger å gjøre data tilgjengelig i et nettverk så velger du å utsette deg selv for en risiko at dataene kan komme på avveie.  Bare nylig hadde digi en artikkel om en sikkerhetshull som ga tilgang til Folkeregisteret. Dette vil vi nok lese mer om i framtiden.

En av de viktigste felleskomponentene i TOA-arkitekturen vi skal jobbe med er en data-broker. En modul som tar imot forespørsler om data og bestemmer hvilken data som skal returenes. Innleggene understreker viktigheten med en slik felleskomponent. For det første så må det finnes. All integrasjon med ekstern programvare må gå gjennom en sentral data-broker som sier ja eller nei til forespørsler om data, men det er også viktig at hendelsen blir logget og informasjon om hvem som spurte, hva de spurte etter og hva de faktisk fikk deles med brukeren det gjelder. Det kan være tilfeller der feks politiet må ha tilgang til data uten at brukeren skal vite, men her kunne data-broker komponenten publisere antall slike hendelser per fagområde per år. Sporbarhet og åpenhet vil være viktige egenskaper til en slik komponent, spesielt fra et demokrati-perspektiv.

Det går fint an å dele informasjon mellom sektor løsninger og på tvers av forvaltningsnivåer, det må bare gjøres på en måte der personvernet er i varetatt. Personvernet kan ivaretaes hvis det blir en sentral del av kommunens IT-arkitektur.