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.

 

Legg igjen en kommentar

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