Artikler om Modernisering

ESDH høring igen

Tuesday, 27. October 2009

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.

(more…)

EA for Innovation

Tuesday, 18. August 2009

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.

Denne artikel er først publiceret på www.zebranet.dk af Allan Bo Rasmussen.

Standardisering af ESDH

Tuesday, 30. June 2009

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.

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.

(more…)

Skandalerne er tilbage

Sunday, 25. January 2009

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 mod uforudsete 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

Monday, 17. December 2007

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!

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

Monday, 4. September 2006

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.

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.

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

Thursday, 22. June 2006

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.