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.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *