ESDH høring igen

ITST har igen sendt specifikationerne for sag og dokumentområdet til offentlig høring, nu i en slankere udgave, hvor bl.a. en del elementer har skiftet status fra obligatoriske krav til optioner. Den arkitekturmæssige tilgang er dog uændret, og ambitionsniveauet for standardiseringen er fortsat meget højt, idet man beskriver grænseflader for alle systemer i den offentlige forvaltning, der vil tilbyde eller benytte dokumenthåndteringsfunktioner i et andet system. Det er altså ikke kun ESDH systemerne, der er målet for den nye standardisering, men hele samspillet mellem den offentlige forvaltnings systemer.

Vi anbefaler alle leverandører af fagsystemer, portaler og infrastruktur til den offentlige forvaltning at holde et vågent øje med de nye dokumentstandarder, for hvis OIO udvalget får magt som de har agt, vil specifikationerne indgå i de fleste offentlige udbudskrav allerede fra næste år.

EA Fellows har tidligere sat fokus på dokument standarderne i et høringssvar. Det blev fulgt op med en omtale af alle indkomne kommentarer.

I dette indlæg uddyber vi det første af vore kommentarpunkter, og bringer en lille vejledning, som fx kan bruges til at prioritere standardiseringsprojektets aktiviteter.

 

Hvad er formålet?

Hvad er det overordnede formål med standardiseringsinitiativet, har vi tidligere spurgt. Det er ikke så let at blive klog på, for der er ikke formuleret et operationel strategi for standardiseringsprojektet. Men læser man referencearkitekturen, og de enkelte specifikationers formål, kan man fornemme, at OIO udvalget for sags- og dokumentområdet har en vision om en mangfoldighed af systemer i den offentlige forvaltning, hvor alle systemer kan bytte roller og tilbyde funktionalitet til hinanden på kryds og tværs. Nøglen hertil er, at alle systemer har fået “monteret” et OIO-standardiseret interface.

Når alle systemer er “plug-and-play”, vil markedskræfterne råde, og hver myndighed kan vælge frit på alle hylder, når det gælder esdh- og fagapplikationer. OIO udvalgets vision synes at være, at en omfattende standardisering kan eliminere behovet for en systemarkitektur, både hos myndigheder og leverandører. Men det er nok et spørgsmål, om den standardiseringsstrategi passer lige så godt på den offentlige sagsbehandling, som den passer på et usb-stik.

Det kan undre, at IT og Telestyrelsen med sit standardiseringsarbejde søger at fremme en strategi, hvor funktionerne kan fordeles ad libitum på mange små systemer, mens Finansministeriet med Statens IT arbejder i den modsatte retning, frem mod en konsolidering af de offentlige kernefunktioner, for at hente stordriftsfordele.

Hvis de to initiativer var koordinerede, ville man kunne hente betydelige gevinster til det offentlige, fx ved at Statens IT tilbyder fælles services til sags- og dokumenthåndtering, og ITST definerer for myndigheder og leverandører, hvordan de skal anvendes. Både Statens IT og Finansministeriet er repræsenterede i OIO udvalget, så man har da lov til at håbe, at de selv vil få denne ide. Og den må meget gerne komme, inden leverandørerne tvinges til at implementere en masse funktioner og grænseflader, som kun et fåtal har brug for.

Hvad er det værd?

Hvis vi skal beskrive, hvordan en standardisering af ESDH-grænsefladerne kan skabe værdi i samfundet, vil det være naturligt at bruge klassiske metoder fra EA værktøjskassen: Vi starter med at se på de forvaltningsprocesser, der kan optimeres, og følger derefter sporet til IT løsningerne. Undervejs kan vi optimere de strategiske beslutninger omkring standardiseringens omfang, forløb osv., og hente vigtige input til at opstille en business case for standardiseringsprojektet. Vi kan fx starte med 5 simple spørgsmål som disse:

1. I hvilke scenarier kan standardisering gøre en positiv forskel?

Lad os få sat fingeren på konkrete offentlige opgaver, hvor arbejdsgangen kan lettes, når de underliggende IT løsninger bringes til at spille bedre sammen. Og på de situationer, hvor kørende systemer skal konsolideres, fx i Staten eller i kommunerne.

2. Hvilken konkret værdi vil standardiserede grænseflader bidrage med?

For de valgte scenarier ser vi nu på, i hvilken grad en standardisering af grænsefladen kan skabe værdi. Det kunne være besparelser ved at undgå genindtastning af data, eller bedre muligheder for at finde og sammenstille oplysninger på tværs af flere systemer. Husk , at alle værdielementer skal opgøres i en fælles valuta, DKK.

3. Hvilke investeringer og indsatser skal ydes for at opnå fordelene?

For at standardiseringen kan få den ønskede effekt, skal den jo også implementeres, både teknisk og organisatorisk. Hvad koster det, for myndighederne, for leverandørerne, for borgerne? Og hvordan skal de forskellige parter motiveres til at investere.

4. Hvilke forudsætninger skal være opfyldt for at gevinsten kan høstes?

En række konkrete faktorer skal være på plads for at sikre standardernes effekt, fx bagud-kompatibilitet, certificering af løsninger, implementering i fællesoffentlige registre, finansieringsmodeller, markedsforhold og meget mere. Vurderingen af disse faktorer bør omfatte både omkostninger og risiko.

5. Findes der alternative initiativer, som kunne give en tilsvarende eller større værdi?

Før standardiseringsprojektet iværksættes, skal vi lige sikre os, at den valgte strategi også er den bedste. Det kunne jo tænkes, at en stor del af værdien hidrører fra en lille delmængde af projektet – så man med fordel kunne reducere scopet. Det kunne også være, at eksisterende standarder var bedre end de nye fra ITST? Eller måske kan fordelene bedre nås gennem konsolidering af systemer, i stedet for standardisering?

Disse grundlæggende spørgsmål bør stilles og vurderes omhyggeligt, før man formulerer en strategi for standardiseringen af sags- og dokumentområdet, som jo er en vigtig del af den offentlige administration. Vi kan kun anbefale, at IT- og Telestyrelsen giver de strategiske spørgsmål en høj prioritet.

EA for Innovation

Det er ofte hævdet, at begreber som strategisk planlægning og overordnet arkitektur står i direkte modsætning til innovativ udvikling. Påstanden bygger som regel på en misforstået opfattelse af, at strategisk tænkning altid er en topstyret proces, der skal resultere i et ensartet og forudsigeligt resultat. Men sådan behøver det slet ikke at være.

EA som innovationsmetode

Enterprise Architecture (EA) er en anerkendt metode til at organisere en virksomheds processer, informationer og teknologier, så alle dele af virksomheden fungerer optimalt sammen og skaber de projekterede resultater. Kernen i EA metoden er at udvikle processer og teknologiske løsninger, med udgangspunkt i de strategiske mål. Denne tilgang er ikke blot velegnet ved udvikling af virksomheder, men er også yderst værdifuld ved udvikling af innovative produkter og services. Her sætter vi anvendelsesprocesserne i centrum, og maksimerer den værdi, produktet kan skabe hos kunden. EA metoden relaterer produktets egenskaber til værdiskabelsen, i stedet for at tage udgangspunkt i teknologien. Dermed sikres, at vi tænker “out of the box” og skaber nye løsninger, der opfylder de overordnede behov bedre end de eksisterende produkter og services.

En god strategi kan indeholde et sæt rammebetingelser, som skaber en platform for udviklingen, i stedet for at foreskrive, hvordan alle opgaver skal løses.

Enterprise arkitektur er en strategisk disciplin, der organiserer løsningens elementer, og sikrer at de spiller sammen om at opfylde de ønskede mål. Og det er jo netop hvad vi har brug for, når nye produkter og tjenester skal udvikles.

Hvis strategi og arkitektur formuleres som overordnede principper, bliver de værdifulde redskaber for den kreative opfinder. Her skal vi se på, hvorledes enterprise arkitekturen kan bruges i innovationens tjeneste.

Hvordan får man en god ide?

De fleste forbinder innovation med nye ideer og opfindelser, som pludselig opstår, når man mindst venter det, fx under en spadseretur i naturen eller mens man tager brusebad. Hvad er den bedste måde at få gode ideer på? Mange mener at omgivelserne er vigtige: Hvis man bevæger sig væk fra dagens rutineopgaver, kan man åbne for inspirationen, og nye indtryk kan give konkrete ideer til nye produkter og tjenester. Men det er meget individuelt, hvad der skal til for at fremme de gode ideer: Mange opfindere er faktisk mest kreative, mens de er i gang med at lave noget helt andet.

De fleste opfindelser starter med opdagelsen af et nyt behov – eller en ny måde at opfylde et gammelkendt behov på. Kravet er, at opfindelsen skal skabe værdi: Man skal kunne se, hvad der kan gøres bedre – eller man skal finde nye forretningsmodeller, der kan skabe et økonomisk potentiale.

Her kan man med fordel benytte begreber og koncepter som findes i EA værktøjskassen: Vi anbefaler ikke at følge en bestemt arkitekturmetode slavisk, men at plukke de relevante elementer efter behov. Fx kan man tage udgangspunkt i den proces, som man ønsker at forbedre, og gennemgå dens deltagere og interessenter, se på deres motiver og spørge, hvorledes processen skaber værdi. Så vil man ofte finde alternative måder at gøre tingene på, eller kunne se et oplagt behov for en opfindelse, der kan hjælpe i processen.

Gode enterprise arkitekter stiller ofte spørgsmålet “hvorfor”, når de skal sikre sammenhængen mellem en løsning, og det behov, den skal dække. Denne nysgerrighed er et af de vigtigste redskaber for opfinderen (og forskeren) , der ønsker at udvikle sine ideer.

Hvordan fører man ideen ud i livet?

Innovation kræver en balance mellem spontanitet og systematik. De vilde ideer skal parres med erfaring og sund fornuft, herunder en afvejning af ideernes værdi og en analyse af hvorledes de kan realiseres på den mest optimale måde. Til disse vurderinger, som gennemføres i de første faser af opfindelsens tilblivelsesproces, er det relevant at inddrage erfaringer med produkter, som er sammenlignelige med den nye ide – eller som bliver dens konkurrenter i fremtiden. Vurderingen kan iscenesættes som en systematisk proces, hvor man bruger klassiske metoder fra EA værktøjskassen. Det betyder fx, at man beregner, hvorledes opfindelsen kan skabe værdi for kunderne, og optimerer dens opbygning herefter. På denne måde kan man sikre at opfindelsen vil stå så stærkt i konkurrencen, at den automatisk bliver det foretrukne produkt for kunder, der har de samme værdibegreber.

En systematisk vurdering på dette tidspunkt kan med stor nøjagtighed beskrive opfindelsens potentiale, og med stor sandsynlighed eliminere de betydelige risici, der ligger i et fejlskøn. Det er som bekendt de fejltagelser, der begås i projektets første faser, der ender med at blive de dyreste.

At realisere en opfindelse kræver dog meget mere end en god og holdbar ide. Her kommer vi til det, der traditionelt kaldes “transpirationsfasen”, som indeholder en masse hårdt arbejde. Der skal endeløse forsøg , vurderinger og sammenligninger af alternative modeller til, for at finde den bedste løsning til at opfylde et konstateret behov. For hver ny løsningskomponent, for hver ny funktion og for hver ny egenskab i løsningen er det vigtigt at relatere den – dels til de kommende kunders behov og præferencer , og dels til de tidsmæssige og økonomiske konsekvenser, det vil have for projektet. Det er en klassisk EA disciplin.

Et vigtigt aspekt i design af løsningen er at identificere de komponenter, koncepter, metoder etc, som gør løsningen unik, og som kan beskyttes mod kopiering gennem hemmeligholdelse, patentering eller andre former for rettighedsbeskyttelse. Den samlede løsningsarkitektur bør udformes sådan, at de overordnede fordele ikke kan opnås af en kunde eller konkurrent, der ikke har adgang til de centrale komponenter.

Især i denne fase er det vigtigt at stille spørgsmålet “hvorfor” gentagne gange. For hvis løsningen ikke er optimeret benhårdt mod det behov, den skal opfylde, er det helt sikkert at dens liv vil blive kort. Det skal den globale konkurrence nok sørge for.

Hvordan sikrer man det forretningsmæssige resultat?

Når en ny ide (eller en forbedret gammel ide) skal omsættes til fordele og økonomisk værdi, er det naturligt at gennemføre en interessentanalyse, hvor man kortlægger hvad opfindelsen kan gøre for alle, der er direkte berørt af opfindelsen, fx kunderne, der skal købe og bruge opfindelsen, producenterne, der skal omsætte ideen til fysiske eller logiske produkter og services, og ikke mindst for opfinderen og eventuelle andre rettighedshavere. Denne analyse bør være grundlaget for de forretningsmodeller, man vælger, og den tilhørende strategi for opfindelsens produktion og udbredelse.

Parallelt med udviklingen af én eller flere prototyper, skal vi i gang med at designe og producere det færdige, salgbare produkt. Afhængigt af opfindelsens art skal der gennemføres forskellige former for koncept- og produktudvikling, teknologiudvikling osv. I denne fase møder vi en stor risiko for, at det endelige produkt ikke vil kunne give de forventede resultater, på grund af forsinkelser, tekniske udfordringer -eller fordi produktet “rammer ved siden af” det markedsbehov, man søger at opfylde.

En referencearkitektur er det vigtigste redskab til at sikre en sammenhæng mellem ide, koncept og det færdige produkt. Ved at definere rammerne for produktudviklingen som arkitekturprincipper, kan en klassisk EA model sætte rammerne for udviklingen, uden at definere alle detaljer i forløb og design. Det betyder blandt andet, at vi har frihed til at vælge udviklingsmetode og -værktøjer efter opgaven (fx Agile) , og at vi har fleksibilitet til at vælge eksterne underleverancer (sourcing) for at optimere planlægningen. Arkitekturprincipperne vil gennem hele forløbet sikre en velbegrundet sammenhæng mellem de strategiske pejlemærker og den praktiske implementering. På denne måde reducerer vi risikoen for at produktet flopper, og samtidig finder vi den billigst mulige løsning, der kan levere den projekterede værdi til kunderne, producenterne – og til opfinderen selv.

Innovation overalt

Det er ikke kun i små, teknologiske opstartsvirksomheder, at der er behov for en målrettet udvikling af nye ideer og en transformation fra koncepter til produkter. Også store, veletablerede firmaer møder hele tiden nye konkurrenter og nye markedstrends, som tvinger dem til at skrue op for innovationstakten. I den offentlige sektor er der ligeledes brug for fornyelse – her bruges ordet “modernisering” om den stærkt efterspurgte udvikling af nye elektroniske servicetilbud.

I alle situationer er det vigtigt at huske, at ny teknologi sjældent giver fordele alene: Der skal arbejdes med processer, data og IT-funktioner under én hat – og ikke sjældent skal de overordnede mål og regler tages op til revision, for at man kan skabe konkret værdi. Det er her, enterprise arkitekten er en nyttig rådgiver og hjælper for den innovation, virksomheden skal leve af i fremtiden.

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.

Skandalerne er tilbage

En gang i 90’erne hørte det til dagens orden at offentlige IT projekter udviklede sig til “IT skandaler”. Definitionen på en skandale var ganske simpelt at tidsplanen og budgettet blev overskredet i væsentligt omfang. Men så fik vi DANSK IT’s Dogmer for offentlige IT projekter og Bonnerup rapporten, som gav gode råd om hvordan man gennemfører store IT projekter. Snakken om skandaler stilnede af, og vi begyndte at tale om ”fine” ting som modenhed og standarder …

Nu er den gal igen

Finansminister Lars Løkke er netop citeret i Computerworld for at han “vil have styr på løbske it-projekter”. Udtalelsen er bl.a. foranlediget af Rigsrevisionens seneste rapport om styringen af 5 statslige digitaliseringsprojekter med udviklingsbudgetter på mellem 20 og 131 mio. kr. Denne rapport var knapt nok udkommet, da Computerworld præsenterede en anden undersøgelse af fire store statslige it-projekter, som viste endnu større budgetoverskridelser og forsinkelser.

Det kunne lyde som om historien gentager sig, men en nærlæsning af de seneste skandalerapporter viser faktisk at det offentlige er blevet bedre til at gennemføre projekterne. Det er i højere grad forudsætningerne og planlægningen, det kniber med. I beretningen fra Rigsrevisionen hedder det således, ”at beslutningsgrundlaget for de fem digitaliseringsprojekter, som revisionen har undersøgt, i flere tilfælde ikke var fyldestgørende”. Også Computerworlds gennemgang indeholder eksempler på projekter, hvor budgettet er eksploderet pga. af ”uforudsete ændringer i eksisterende systemer”.

Planlægningen mangler

De ustyrlige projektforløb er faktisk en naturlig konsekvens af mangelfuld planlægning. Som Rigsrevisionen påpeger, er mange af projekterne igangsat uden en fyldestgørende business case, som viser hvorledes projektets målsætninger konkretiseres og måles. Uden en sådan ”målepind” er både projektleder og styregruppe på herrens mark, når der skal tages store beslutninger i projektforløbet. Og der er en overhængende risiko for, at resultaterne ikke står mål med investeringerne i projektet.

For at skabe sammenhæng mellem det forretningsmæssige behov og løsningens egenskaber, benyttes i de fleste projekter en traditionel kravspecifikation. Som regel opstilles kravene dog længe efter, at budget og tidsplan er fastlagt, og det sker ofte, at specifikke, funktionelle krav nødvendiggør større strukturelle ændringer – eller valg af en ny teknologi. Sådanne overraskelser kan nemt få budgettet til at skride – eller gøre det nødvendigt at skære i de leverede resultater.

En bedre praksis

Vil man undgå skandaleramte digitaliseringsprojekter, må man sikre et solidt styringsgrundlag for det enkelte projekt. Finansministeriet tog i 2008 et vigtigt skridt i denne retning ved at gøre udarbejdelsen af en business case obligatorisk for projekter over 10 mio. kr. Men det er ikke nok at have de økonomiske rammer på plads. Man må også sikre sig, at de leverede resultater lever op til forventningerne. Hertil skal vi bruge en model der sammenkobler de overordnede målsætninger med løsningens konkrete egenskaber. Det hedder en enterprise arkitektur. Her opstilles rammerne for løsningen i principform, lige fra forretningsmodeller og arbejdsgange, til de tekniske systemer og platforme.

Arkitekturen er ikke en detaljeret specifikation, men en overordnet ramme for den løsning, der skal bygges. Den gør det muligt at definere projektet præcist mht. struktur og leverancer, og sikrer moduforudsete vanskeligheder i løsningens samspil med eksisterende systemer.

Opfølgningen

For år tilbage havde det offentlige England problemer med at gennemføre moderniseringsprojekter, derfor udviklede den engelske Office of Government Commerce projektstyringsmetoden PRINCE2. Der var også problemer med IT drift og support, her blev resultatet ITIL. Begge disse metoder er i dag udbredt i hele verden, også i den danske offentlige sektor.

Danmarks Statistik udgiver hvert år en undersøgelse af den offentlige sektors brug af IT. Rapporten for 2008 er netop udkommet, og viser at 57 pct. af myndighederne nu bruger en projektmodel til styring og gennemførelse af digitaliseringsprojekter. De fleste af de myndigheder som har en projektmodel, bruger også en business case. Kun 23 % foretager dog en systematisk opfølgning på projektmålene.

Rigsrevisionen har nu sat fokus på omkostningerne ved de danske digitaliseringsprojekter, og finansministeren har udmeldt, at regeringen vil nedsætte en arbejdsgruppe, der skal se på, hvordan vi kan få bedre styr på de statslige IT-projekter. Vi er spændt på at se, hvilke tiltag ministeren vil iværksætte for at optimere de offentlige IT investeringer.

Vi er også rigtigt spændt på hvad Dorte Toft bringer på banen, nu hvor hun ovenpå IT Factory sagen har kastet sig over offentlige IT-indkøb.

Tilbageblik og fremsyn

Hvad er årets bedste nyhed på arkitekturfronten i det offentlige Danmark? EA Fellows kommer med et bud. Men først skal vi ønske bloglæsere, kunder, venner og partnere en glædelig jul og et fremgangsrigt nytår.

I vores andet blogindlæg om supertankere og optimistjoller langer vi lidt ud efter det offentlige arkitekturarbejde. Der er dog samtidig nogle rigtigt spændende initiativer på banen.

Arkitektur i FORM!

Årets bedste nyhed på arkitekturfronten i det offentlige Danmark mener vi er den fællesoffentlige forretningsreferencemodel FORM, der netop er blevet offentliggjort.

FORM er et redskab til at finde, analysere og udnytte moderniseringsmuligheder i den offentlige sektor, herunder specielt muligheder for fælles offentlig opgaveløsning og digitalisering.

FORM’s opgavekatalog er bygget op om de tre grundlæggende begreber: tjenester, opgaveområder og serviceområder. Et eksempel på et opgaveområde er ”Servicering af lovforberedelse”, der består af tjenester som administration af lovforslag og beslutningsforslag, gennemførelse af høring om lovforslag, udarbejdelse af betænkning, m.v.

FORM er udarbejdet af en ekspertgruppe med folk fra KL, IT- og Telestyrelsen, Økonomistyrelsen og Den Digitale Taskforce. Konsulenter på opgaven har været IBM, hvilket forklarer at FORM trækker heftigt på nogle af IBMs best practices. Den officielle forklaring er vist at man har ladet sig inspirere af nordamerikanske erfaringer fra bl.a. det føderale USA’s FEA-arbejde, men her har IBM også været konsulent, så hvordan man end vender den, så er der malet med blåt henover tingene.

Det med blåt består i, at man læner sig op af et af IBMs favoritakronymer, CBM, Component Business Model, som i al sin enkelthed blot handler om at ”udstille” hele forretningen på en side. Den offentlige forretning Danmark, der udtrykkes i FORM, fylder en A3-side (hvis den skal være læsbar). Andre forretninger passer nok ind på en A5-side, må man antage.

Det gode ved FORM er, at vi med den har et vigtigt redskab for udfoldelsen af en fællesoffentlig arkitektur. FORM giver overblikket over forretningen, og tilgangen kan bruges til at koble politik, strategi, forretning og teknologi – altså, skabe den altid-vigtige alignment.

Da Lars Frelle og Kristian Hjort-Madsen fremlagde FORM på aEAs gå-hjem-møde, talte de om at en af anvendelserne af FORM vil være at identificere områder, hvor der med fordel kan sættes ind med arbejdskraftbesparende teknologi. Altså skal FORM ultimativt bruges til at skrue på varme/kolde hænder-ratioen.

FORM kan og skal selvfølgelig ikke stå alene. I FEA-termer er en ”komplet EA referencemodel” foruden en forretningsreferencemodel (BRM) også fire andre referencemodeller for hhv. performance (PRM), servicekomponenter (SRM), data (DRM) og teknologi (TRM). Den danske ”oversættelse” vil svare til at FORM er BRMen, FOKUS er PRM, OIOXML/ISB er DRMen og OIO-kataloget er TRMen. Vi mangler således blot en SRM, servicekomponentreferencemodel, kunne man fristes til at sige. Men der mangler i den grad også sporbarhed mellem de forskellige referencemodeller.

Tillykke, Taskforce! Nu ser vi frem til at se de offentlige parter komme i FORM.

PS: OIO-kataloget er forresten under revidering, og indtil jul er 20 tekniske standarder i høring. Vi har med interesse gennemlæst høringsmaterialet, men ser ingen grund til at indsende et høringssvar, da der er tale om en rutinemæssig og ustrategisk ajourføring, som vi trygt overlader til bureaukraterne i Holsteinsgade. ”Nothing here, move on”.

Disclaimer: En del af de heromtalte organisationer er/var kunder hos EA Fellows.

Nye styringsmodeller for offentlig IT

Digitaliseringen af den offentlige administration har medført en omfattende udvikling af både arbejdsgange, IT-systemer og lovgrundlag. I de seneste år er der samtidig sket en stor omorganisering indenfor den offentlige forvaltning. Vi mener, at tidspunktet nu er det rigtige for en kortlægning af hvordan styringsmodellerne for tværoffentlige teknologiprojekter fungerer – og en debat om hvordan de kunne optimeres.

Forslag til Teknologirådet

Uhensigtsmæssige rammebetingelser har mange steder været den væsentligste barriere for at høste gevinsterne ved moderniseringen af den offentlige sektor. EA Fellows har i et projektforslag til Teknologirådet peget på, at styringsmodellerne for tværoffentlige teknologiprojekter må optimeres for at matche den omfattende udvikling af både arbejdsgange, IT-systemer og lovgrundlag, som digitaliseringen medfører.

I digitaliseringens barndom var der skarpt fokus på leverandører og produkter. Der var en almindelig opfattelse, at teknologisvigt var den største fare for et IT-projekt. Nu er både produkter og leverandører mere modne, og det er sjældent, at et IT projekt kuldsejler pga. tekniske svigt. Til gengæld er der ofte problemer med de bløde sider i gennemførelsen, fx hvad angår planlægning og organisatorisk implementering. Her kommer de strategiske valg i fokus, fx omkring forretningsstrategi og valg af tekniske standarder.

IT governance

Fra mange sider hører vi, at der er brug for tvang og topstyring af den offentlige IT udvikling. EA Fellows mener, at vi bør gå et spadestik dybere: Hvis rammer og incitamentstrukturer for offentlige ledere afspejler samfundets interesser, bliver det lettere at gennemføre tværgående reformer.

I forbindelse med kommunalreformen og etablering af de nye regioner, er der sket store ændringer i rollefordelingen mellem stat, region og kommune. De nye enheder har fået ansvar for levering af mange ydelser til borgere og virksomheder, og der er i forandringsprocessen blevet udvist stor kreativitet og beslutsomhed for at etablere nye organisationer, der kan løfte ansvaret. Den nye fordeling af opgaverne stiller nye krav til samarbejdet mellem enhederne, ikke blot hvad angår den tekniske integration, men også hvad angår effektiviteten og kvaliteten i de leverede ydelser. Her er der brug for optimering på et overordnet plan.

Der er allerede gennemført en bemærkelsesværdig innovation indenfor levering af kerneprodukterne efter etablering af nye regioner og kommuner, og udviklingen af nye tværoffentlige systemer som fx ESDH og EPJ er i fuld gang. Det kan imidlertid være en udfordring at etablere et effektivt og velfungerende tværoffentligt samarbejde, hvis der mangler styringsmodeller, som kan fremme samarbejdet mellem økonomisk selvstyrende enheder som fx ministerområder, regioner og kommuner.

Vi har mange steder i den offentlige sektor (ligesom i den private) fundet gode eksempler på beslutningsmodeller og incitamentsstrukturer, der har været afgørende for et succesfuldt tværgående samarbejde. Men der findes desværre også mange eksempler på, at uhensigtsmæssige rammebetingelser har været den væsentligste barriere for moderniseringen af den offentlige sektor. Det har været svært at omsætte IT investeringerne til administrative gevinster, fordi styringsmekanismerne ikke er blevet ajourført i takt med den teknologiske udvikling.

Derfor mener vi, at det er på tide at sætte fokus på den overordnede styring af Danmarks IT anvendelse.

Fælles og åbne standarder

Folketingets allersidste gerning inden politikerne gik på sommerferie var en overraskende enstemmig vedtagelse af De Radikales beslutningsforslag, B103, om anvendelse af åbne standarder for it i det offentlige. Beslutningen indebærer, at det offentlige som princip skal benytte åbne standarder, og at regeringen aktivt skal fremme udviklingen. Den 1. januar 2008 er sat som en skæringsdag, men med en kattelem hvis man kan påvise at der er tekniske umuligheder.

På mange måder kan man sige, at Folketinget har vedtaget at 1. januar 2008 er den næste eDag. Men spørgsmålet er, om de offentlige parter og politikerne vil lade sig nøje med eDagenes kampagnepræg og generelle uforpligtethed.

Der har været ført en længerevarende debat om hvilke konsekvenser det har at indføre åbne standarder i det offentlige, og mange synspunkter er fremført. Alle er enige om, at åbne standarder er vejen frem, men ikke om hvilke midler de skal indføres med. Regeringen henviser til et embedsmandsudvalg, det såkaldte Interoperabilitetsudvalg, som senest 15. august skal præsentere en betænkning med forslag til det videre arbejde.

Videnskabsministeriet har i et forstudie anbefalet, at åbne standarder gøres obligatoriske hvor det er nødvendigt for at skabe interoperabilitet og dermed en integreret forretningsproces, og hvor de opnåede gevinster er større end omkostningerne i den konkrete forretningsproces.

Argumentet fremført af Videnskabsministeren er, at de økonomiske gevinster ved indførelsen af standarder ikke alene følger af, at standarderne er åbne, men derimod skyldes at de er både fælles og åbne. Den store værdi kommer af at tale samme sprog, ikke at stille en ordbog til rådighed for alle, som Helge Sander udtrykte det for nylig i Folketinget. Således har IT-arkitekturkomitéen da også allerede lagt op til en vis stramning af OIO-kataloget, bl.a. ved at påpege at alle standardområder bør have en (og kun en) anbefalet standard. Men er det så nemt?

De fleste er enige i, at brugen af fælles standarder er et vigtigt værktøj til etablering af interoperabilitet mellem de offentlige it-løsninger, og at åbne standarder naturligvis bør foretrækkes. Men at gå så vidt som til at omdanne OIO-kataloget til en snæver positivliste, som alle offentlige myndigheder skal følge, vil næppe finde bred accept. Dertil er myndighedernes forudsætninger og opgaver nok for forskellige.

For generelle applikationer vil det være naturligt at vælge een fælles standard for hele den offentlige sektor, men når det kommer til fagspecifikke opgaver og systemer, er situationen mere kompleks. Vi tror, at standardvalget bør kædes sammen med det forretningsmæssige behov for samspil mellem de offentlige myndigheder, og det er en opgave for enterprise arkitekterne.