Standardisering af ESDH

I sidste uge var der høringskonference om ESDH standarderne. På bordet lå Referencearkitektur for sags- og dokumentområdet -en diger sag på næsten 100 sider, der bl.a. indeholder en nyudviklet begrebsmodel for den offentlige sagsbehandling. På konferencen fremlagde OIO udvalget for Sag og Dokument de (5) specifikationer af forretningsservices, som skal supplere – og med tiden afløse – de eksisterende FESD standarder.

Som nogen vil vide, var erfaringerne med FESD projektet noget blandede – et hovedformål var at skabe konvergens mellem markedets dokumenthåndteringssystemer, så de forskellige dele af forvaltningen kunne arbejde bedre sammen. Med IT- og Telestyrelsen i spidsen blev der standardiseret på livet løs -en lang række af systemernes funktioner og grænsesnit blev beskrevet i finurlige detaljer. Men i praksis var det så som så med kompatibiliteten – og med leverancernes kvalitet.

Nu spiller IT- og Telestyrelsen ud med et nyt sæt standarder. Denne gang er vi ikke begrænset til ESDH systemer, for standarderne skal også dække de mange fagsystemer der indeholder (eller benytter) ESDH funktionalitet. De nye standarder vil altså beskrive, hvorledes en meget stor del af systemerne i den offentlige forvaltning skal spille sammen.

På høringskonferencen var der flere deltagere, der var imponerede over dette meget høje ambitionsniveau. Vi var også nogle stykker, der var lidt bekymrede. For at hjælpe arbejdet lidt på vej, har EA Fellows skrevet en høringskommentar fra enterprise arkitektens synsvinkel.

Fra høringssvaret kan vi referere disse punkter:

1.      Forretningsmæssige begrundelser

En god arkitekturpraksis har til opgave at levere et velunderbygget beslutningsgrundlag for IT-investeringerne. Det betyder, at alle valg af løsningsmønstre og principper er begrundet i de opstillede mål, og at konsekvenserne er beskrevet, så det fx er muligt at opstille en business case for implementeringen af arkitekturen. Referencearkitekturen, som skal udgøre grundlaget for standardiseringen, har efter vor opfattelse ikke formidlet dette budskab klart nok. Dokumentet indeholder – i overensstemmelse med god praksis – afsnit om mål og visioner, forretningsservices og integrationsmønstre. Men disse afsnit er ikke systematisk kædet sammen, så man kan se begrundelsen for de trufne valg – og dokumentet indeholder i øvrigt ikke mange konkrete krav til arkitekturen. Således er de udmeldte principper henvist til et bilag, og er ikke relateret til hverken Referencearkitekturen eller Strategien for digital forvaltning. Vi anbefaler, at den næste version af referencearkitekturen udvikles til et mere komplet grundlag for ESDH udviklingen.

2.      Komplicerede grænseflader

Når målet er at opnå en bedre interoperabilitet, er det afgørende at der standardiseres på grænseflader i stedet for de indre strukturer, og de fremlagte specifikationer sigter da også i denne retning. Det er leverandørernes valg, i hvilken grad den indre struktur i databaser, programkode, etc. skal svare til det begrebsbillede, som de foreliggende specifikationer præsenterer. En gylden regel for standardisering af interfaces er imidlertid, at man kun skal medtage de parametre, der er nødvendige for at give forretningsmæssig værdi. Det er bekymrende, at specifikationerne ikke følger denne praksis, men i stedet lægger op til at eksponere en lang række interne parametre på grænsefladen. Erfaringerne fra en lang række cases viser, at den tilsigtede tætte integration ikke opnås ad denne vej, fx pga. manglende integritet i de udvekslede data. Desuden repræsenterer den tætte integration et brud på princippet om løs kobling, som det er udtrykt i referencearkitekturen. Vor anbefaling er at benytte de erfaringer, man fx har gjort i Norge, hvor overgangen fra NOARK-4 til NOARK-5 viser en tydelig flytning af fokus fra indre til ydre strukturer, og en simplificering af grænsefladerne, efter at man måtte konstatere at de komplicerede udvekslingsformater ikke gav de ønskede sammenhænge.

3.      Ambitionsniveauet

Både omfanget og antallet af de foreliggende specifikationer synes at være unødigt højt. Erfaringerne fra FESD1 viser tydeligt, at leverandørernes evne og vilje til levere et robust og kundetilpasset produkt vurderes højere af brugerne end muligheden for at få implementeret alle de fællesoffentlige standarder. Risikoen for at skabe et betydeligt gab mellem standarden og de konkrete implementeringer, bliver større jo mere der standardiseres. Vi kan derfor kun anbefale, at den obligatoriske standardisering holdes på et minimum, som kan give sammenhæng på udvalgte, centrale områder, og at de øvrige standarder bliver optioner, der kan tilvælges, hvis myndigheden har et forretningsmæssigt behov for en interoperabilitet, der går ud over der basale niveau. Hvis det høje ambitionsniveau fastholdes, er der risiko for, at myndighederne får en række specialudviklede (men stort set identiske) løsninger at vælge imellem, med dertil hørende negative virkninger for markedssituationen.

4.      Innovation

Flere steder i Referencearkitekturen understreges det, at IT udviklingen skal understøtte forandring i den offentlige forvaltning, og vi kunne ikke være mere enige. Men vi er samtidig bekymrede for, at den udbredte standardisering af arbejdsgange og løsninger på ESDH området vil begrænse moderniseringen af den offentlige sektor. Innovation handler primært om, at man tænker nye sammenhænge og nye processer, i stedet for at sætte strøm til de gammelkendte forvaltningsrutiner. En referencearkitektur der i vidt omfang bygger på eksisterende praksis, kan let komme til at modvirke nytænkningen. Vi kunne ønske os et større fokus på nytænkning og forenkling, og mindre vægt på automatisering af arbejdsgange, der allerede er komplicerede nok. En fremtidsorienteret arkitektur skal være udformet, så den kan understøtte nye og ændrede opgaver uden en større “ombygning”. Det betyder som regel, at arkitekturen skal være simpel og klart kommunikeret. Som et aktuelt eksempel kan nævnes, at en række forvaltningsmæssige opgaver i fremtiden forventes løst i et offentlig-privat partnerskab (OPP). Det ville derfor være hensigtsmæssigt hvis det offentliges ESDH systemer var gearet til at spille sammen typiske systemer i den private sektor, fx Customer Relation Management (CRM), Service Management etc.  En sådan fremsynethed kan opnås, hvis enterprise arkitekten spørger ind til begrundelsen for de udførte opgaver, og måden de udføres på. Det er her, innovationen starter og nye løsninger opstår. Modne organisationer har ofte succes med at orkestrere innovationen, fx ved at udskrive en konkurrence blandt medarbejdere eller belønne ledere der forenkler gammelkendte arbejdsgange eller udvikler nye services.

Læs de øvrige punkter om Privacy, Fællesoffentlig reference, Standardiseret infrastruktur, Scope, Roadmap og Governance her.