Bedre offentlig IT

Mange steder i det offentlige system er man faktisk godt klar over, at anvendelsen af IT kunne være mere hensigtsmæssig, og i den seneste tid har hele 3 rapporter om digitalisering set dagens lys, alle initieret af det offentlige Danmark:

Finansministeriets IT udredning om statslige it-projekter

OECD rapporten:
Denmark – efficient e-government for smarter public service delivery

Teknologirådets rapport: Bedre styring af offentlig it

Mens Finansministeriets rapport sætter fokus på en professionalisering af arbejdet med IT projekter, har OECD rapporten et mere strategisk sigte, og anbefaler en samlende strategisk vision for digitaliseringen. Det sidste skud på stammen kommer fra en arbejdsgruppe under Teknologirådet, som anbefaler at se nøjere på de rammebetingelser og styringsmekanismer, der skal få strategi og gennemførelse til at hænge sammen.

Arbejdsgruppens efterlyser en holdningsændring på fire væsentlige punkter.

  1. Et skift væk fra det ensidige fokus på kontrol, til mere vægt på dialog og innovation.
  2. En central beslutningskompetence, som tager ansvar for en samlende strategisk vision.
  3. En ny bevillingspraksis, som fremmer samarbejde på tværs.
  4. Større satsning på forandring med kalkuleret risiko.

Teknologirådets rapport er resultatet af et projekt, som EA Fellows foreslog allerede i 2006: Vi pegede på, at styringsmodellerne for tværoffentlige teknologiprojekter må forbedres, hvis vi ønsker flere succesfulde digitaliseringsprojekter. Som deltager i arbejdsgruppen er vi helt enige i, at det er på tide at sætte fokus på den overordnede styring af Danmarks IT anvendelse.

Som led i projektet afholdt Teknologirådet en Workshop, hvor arbejdsgruppen drøftede både problemer og perspektiver med en række inviterede eksperter og en bred gruppe af interessenter. Dagen bød på mange gode indlæg og en livlig debat, som kan opleves som podcast på Teknologirådets hjemmeside.

Rapportens anbefalinger er delt op i tre temaer: Rammevilkår, strategi og styring. Under disse overskrifter sætter arbejdsgruppen fokus på de egentlige grunde til at så mange offentlige IT satsninger ryger i hegnet. Her er et uddrag af rapportens anbefalinger, som de fleste enterprise arkitekter vil nikke genkendende til:

Detaljerede kravspecifikationer hjælper ikke kunden til at reducere risikoen, men øger derimod omkostningerne, både til rådgivere og leverandør. Det ville være bedre, hvis kræfterne blev brugt til en mere omhyggelig analyse af behovet og planlægning af hvordan det bedst muligt kan opfyldes.

Manglende dialog mellem kunde og leverandør er et af de centrale problemer ved den nuværende udbudsform. Konkurrencestyrelsens fortolkning af EU’s udbudsregler har en klar negativ indflydelse på kvaliteten af offentlige IT-projekter. Arbejdsgruppen peger på alternative udbudsformer, hvor muligheden for en løbende dialog er til stede.

Strategisk fokus mangler i mange offentlige forandringsprojekter – planlæggerne glemmer at indregne de samfundsmæssige effekter, der skal opnås, og koncentrerer sig i stedet om de rene IT omkostninger. Vi bør lægge større vægt på projekternes forretningsmæssige værdi, og de offentlige bevillingssystemer skal justeres, så de understøtter dette.

Høste – så problematikken: Det er ofte anført som en barriere i IT-projekter, at gevinsten ligger et andet sted end hos dem, som leder og bekoster projektet. Den samme form for barriere optræder, når projektets fordele først indtræffer langt ude i fremtiden, så de nuværende beslutningstagere ikke kan få del i gevinsten.

Tværgående nytænkning har svære kår – vi oplever stadig, at mange offentlige problemer forsøges løst med et ”IT-system”, der skal kontrollere pengeforbruget. I stedet burde man beskæftige sig med at løse de underliggende problemstillinger og processer – især når de går på tværs af flere ressortområder.

Ambitionsniveauet er for lavt –  planlæggerne går med museskridt i digitaliseringen, og tænker for lidt i radikale forandringsprojekter, hvor man gennemfører grundlæggende ændringer i forretning og arbejdsprocesser. På denne måde kunne vi få store produktivitetsgevinster, specielt når det drejer sig om tværgående samarbejder. Men det kræver, at der bruges flere kræfter på planlægning og risikostyring.

En business case skal være et styringsgrundlag og ikke et bevillingsinstrument. Business casen skal gennem hele projektet bruges som et fleksibelt redskab med ajourføringer og justeringer, så fokus på mål og resultater fastholdes. Samtidig skal business casen også tage højde for og behandle ideer, som opstår i projektforløbet.

Kunden skal erkende og håndtere risici ved projektets start. Offentlige IT-projekter indeholder mange risikofaktorer. Arbejdsgruppen peger på to af de vigtigste: Projektets radikalitet og kundens modenhed. Desuden bør store, risikable IT-projekter først testes f.eks. i begrænsede lokationer eller brugergrupper.

Vi savner en overordnet arkitektur for digitaliseringen, som giver plads til en høj grad af decentralisering, det vil sige med fokus på interfaces og standarder, som gør det muligt for de forskellige domæner at udveksle data, og udvikle kompatible og sammenhængende løsninger. 

Brugen af standarder er en afgørende faktor. Det skal være et krav i forbindelse med investeringer i både løsninger og  infrastruktur, at der tages udgangspunkt i veletablerede standarder, som er bredt understøttet. Det er således ikke mængden af nye standarder, der er afgørende, men værdien som kan skabes i samfundet ved at opnå kompatibilitet mellem de offentlige IT-løsninger.

Beslutningstomrum

Rapportens vigtigste konklusion er nok, at en række vigtige beslutninger om digitaliseringen stadig svæver i luften, og at vi savner embedsmænd og politikere, der tør tage dem. De offentlige IT-projekter lider under manglen på et strategisk bindeled mellem de overordnede politiske målsætninger og det taktiske niveau i regioner og kommuner. Tværgående og meget omfangsrige domæner som sundhed og erhverv er blandt de mest oplagte eksempler på de ”nye siloer” i digitaliseringen af den offentlige sektor. Manglen på overordnede beslutninger for hele den offentlige sektor får domænerne til at definere lokale principper, med følgelig suboptimering og etablering af nye barrierer for tværgående initiativer..

Et eksempel på en af de beslutninger, som mangler, er en plan for hvilke løsninger og it-services, der skal etableres i fællesoffentligt regi (som fx Navision Stat), og hvilke løsninger der skal bygges decentralt, i statslige, regionale og kommunale organisationer, eller servicefællesskaber. Uden en sådan plan er der overhængende risiko for, at de decentrale organisationer disponerer deres ressourcer uhensigtsmæssigt, og etablerer løsninger, der ikke fungerer ordentligt sammen.

En fælles digitaliseringsramme

Arbejdsgruppen peger på, at der er behov for et nyt strategisk niveau for styring af den offentlige IT anvendelse – placeret mellem den nationale strategi og de forskellige domæner i den offentlige forvaltning. Digitaliseringsrammen, som niveauet kaldes, skal samle alle de fælles beslutninger, som udstikker kursen med strategiske retningslinjer og dermed sikrer større ensartethed projekterne imellem og modvirker suboptimering. Digitaliseringsrammen kan f.eks. indeholde fælles arkitekturprincipper, governancemodel, udbudspraksis, standarder, metoder og business cases. Digitaliseringsrammen bør være forankret i en central beslutningskompetence, der kan tænke horisontalt i koordinering og konsolidering.

Udfordringen ved at etablere en overordnet arkitektur er at skabe interoperabilitet mellem de forskellige løsninger uden at hæmme eller begrænse de velfungerende, lokalt forankrede arkitekturer. Derfor er det afgørende at den fælles digitaliseringsramme indeholder netop de nødvendige og tilstrækkelige elementer til at sikre en koordineret digitalisering af den danske forvaltning.

Læs mere om rapporten i Teknologirådets nyhedsbrev Fra Rådet til Tinget.

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.

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.

Digitalisering på tværs

Når den offentlige sektor skal arbejde bedre sammen, spiller teknologien en væsentlig rolle. Det gælder om at dele informationer og at samordne brugen af IT. I arkitektursammenhæng betyder det at rive siloerne ned og skabe en fælles infrastruktur, som fundament for forvaltningens fagsystemer.

Staten har taget et væsentligt initiativ i denne retning med dannelsen af den nye organisation Statens IT. Der er defineret et scope for Statens ITs opgaver men vi har endnu ikke et klart billede af, hvilken grad af harmonisering og konsolidering af systemer og infrastruktur, der er på tegnebrættet.

I mellemtiden har virksomheden Informi GIS givet et bud på, hvad den fælles infrastruktur bør indeholde. Geografisk information udgør en værdifuld fællesnævner i mange offentlige og private forretningsprocesser. Virksomheden illustrerer i et whitepaper Geografisk information i en enterprise arkitektur, hvorledes en geografisk tilgang kan fungere som løftestang for effektivisering, kvalitetsforbedring og styrket samarbejde i den offentlige sektor.

GIS systemer har traditionelt været betragtet som et fagsystem, som mest anvendes i tekniske forvaltninger til administration af veje, kloakker og byggetilladelser. Men ved at gøre de geografiske informationer tilgængelige som en infrastrukturservice, kan de bruges i mange andre sammenhænge, fx ved dynamisk styring af energi og offentlig transport. Det giver store perspektiver for tilrettelæggelsen af den offentlige service, og ikke mindst for samarbejdet mellem offentlige og private organisationer.

Vi venter spændt på at se, hvilke værdiskabende services der i fremtiden skal indgå i den fælles offentlige IT infrastruktur. GIS er et godt bud – hvem kommer med det næste?

Disclaimer: EA Fellows har bidraget med inspiration til publikationen fra Informi GIS.

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.

Supertanker eller optimistjoller?

I lyset af den skare af nyheder om offentlige it-projekter, der forsinkesfordyres eller på anden måde forringes, vi for tiden får nys om, så er det vel naturligt, at spørge sig selv om den måde vi planlægger og udfører vores store offentlige IT-projekter overhovedet er i tråd med hvordan man bedst udvikler løsninger? Og hvad med det samlede billede? – er der tænkt på hvordan man går fra strategi til specifikation af de byggeklodser der skal indgå i løsningskomplekset ?

For at starte i omvendt rækkefølge, så er der desværre noget der tyder på at vi endnu ikke har lært af Amanda og alle de andre dødssejlere der er blevet søsat i tidens løb.

Nye udbud dukker hele tiden op, hvor digitale supertankere ladet med et utal af komplekse teknologier skitseres og kastes i hovedet på de forsvarsløse leverandører, der føler sig forpligtede til at byde uanset hvor ækel den digitale mutant ser ud.

Løsningerne har ændret form over de seneste år fra de let forsimplede “strøm på blanketterne” udbud til de mere gennemgribende ændringer i arbejdsgangene ved indførelse af digitalisering, med en øget grad af automatisering via straksafgørelser mv. som følge.

Dette koblet med input fra mange fantasifulde konsulentfirmaer, der frit fortolker begreber som “åbne standarder” og OIOs hvidbog på hver deres kreative måde. Dette resulterer ofte i et væld af erklæringer om, at den intetanende leverandør skal leve op til snart sagt alle gældende standarder indenfor sikkerhed, Web Services og workflow.

Læg hertil et forhåndskrav fra kunden/konsulenten om, at leverandøren SKAL benytte en given proprietær infrastruktur til at implementere en fleksibel og åben løsning, og resultatet bliver den største selvmodsigelse man kan forestille sig.

Deadlines og økonomi er ofte også stramme, men man kan sige at det ligger i projektformens natur at man skal blive enige om disse ting ved starten, i stedet for at arbejde iterativt frem mod at løse det faktiske behov . Vi ser mange kontrakter, der indgås på et urealistisk grundlag. Hellere søge tilgivelse for forsinkelser end fortabe sig i forhandlinger, virker være logikken.

Nytænkning tak

Der er behov for nytænkning af den måde vi beslutter hvilke både vi vil have sat i søen i det offentlige digitale rum. Det nytter ikke noget at bygge en supertanker, hvis man blot skal krydse Gudenåen! Man skal måske tænke mere i brug af optimistjoller, hvis vi nu skal fortsætte på (dybt) vand – og så løse problemerne i små isolerede klumper i stedet for udfra en veltilrettelagt sejlrute og letfattelige samspilsregler.

Det kræver betydelige arkitektur-skills hos opgavestilleren, når man skal “hjemtage ansvaret for arkitekturen”. Og den kompetence findes sjældent hos kunden eller hans konsulenter i vore dage. Når de alligevel prøver, bliver det ofte en svær opgave for leverandøren – og en dårlig løsning.

Der er brug for en opsang. To gange endda: Først og fremmest til kunden for at stille krav om noget han ikke har forstand på. Men dernæst også til leverandøren for at byde på noget han ikke kan/bør levere, hvis han skal stå inde for løsningen med sin faglighed.

Men det er jo ikke blot fordi begge parter er dumme. Problemet opstår tit når de ikke kan finde deres plads i arkitekturprocessen, og at partnerne ikke kan finde ud af at fokusere på det de er bedst til: Dybest set at kunden kan sin forretning, og leverandøren kan sine løsninger og teknologi. Vi plejer at kalde det for “Danske Bank-modellen”: Hver part gør, hvad de er bedst til.

Det er ikke kundens opgave at stille detaljerede tekniske krav, for det er ikke her, han har sin styrke. Og det bør tilsvarende ikke være leverandøren rolle at definere kundens vision og målsætninger. På hvert niveau skal der være en arbejdsdeling, der svarer til parternes forudsætninger (og interesser), og en tilsvarende ansvarsfordeling.

Hvis kompetencerne som udgangspunkt er anderledes fordelt blandt parterne, så er det det der skal rettes op på – fx med styrkelse af kundens proces-udviklingsevne. Men det ville da også være forfriskende med en leverandør, der afslog at afgive bud med henvisning til at den ønskede tekniske arkitektur er uegnet, men at man gerne vil hjælpe med at udvikle et bedre alternativ …

Udfordringen er at få sigtelinierne fra strategien til at ramme rigtigt på de konkrete implementeringer i virkelighedens verden. Der er desværre ofte en tydelig “missing link” mellem strategien og projekterne. Kunden stiller nemlig ikke krav (især til sig selv) om, at projekterne reviewes med fokus på alignment, hverken før, under eller efter implementeringen.

Og hvad kan vi så gøre ved det? Tja, man har jo længe forsøgt sig med trylleformularen “business case”. Men det opfattes vist af de fleste myndigheder som en teoretisk tvangsøvelse, man skal igennem for at kvalificere et projekt til at få en bevilling, ikke som et aktivt styreredskab. Vi har i hvert fald endnu ikke mødt et offentligt projekt, hvor strategi, business case, udbudsmateriale og kontrakt hænger logisk og økonomisk sammen.

Et bedre udbud

Det er på tide at gøre op med de traditionelle fejltagelser, som silotænkning, proprietær infrastruktur, specialudviklede standardløsninger, osv. Vi har brug for et rammeværk for udbudsprocessen, der følger god EA praksis, og lægger vægt på randbetingelser, sigtelinier, risikostyring og økonomi. Det skal selvfølgelig passe sammen med K1 og K2, ITSTs arkitekturkrav, B103 standarderne og den digitale strategi. Idéen er at hjælpe opgavestilleren til at besvare en række spørgsmål som afgrænser opgaven, definerer forudsætningerne og beskriver de succeskriterier, som samarbejdet med leverandøren skal opfylde.

Hvis en sådan model blev obligatorisk for udbud over en vis størrelse (og for systemer med en central placering i digitaliseringen), kan der skabes overblik over de mange projekter, enten gennem tvungen rapportering opad, eller bare ved gennem åbenhed at synliggøre, om de lokale projekter er alignet med strategien.

At være eller ikke være enterprise arkitekt

Både i den videnskabelige litteratur, hos analyse institutter, og på blogs “i den virkelige verden” er der en rimelig enighed om hvad betegnelsen enterprise arkitektur (EA) står for. Men samtidig er der en klar tendens til, at stadig flere IT professionelle får betegnelsen “arkitekt” føjet til deres visitkort.

Det kan være en udfordring at få øje på enterprise arkitekten blandt alle de andre typer af arkitekter som vi møder: infrastruktur-, sikkerheds-, applikations-, løsnings-, informations-, database arkitekter – og der kommer stadig flere til!

Alle disse gode mennesker er utvivlsomt kompetente og effektive til at planlægge, designe og implementere IT-løsninger, men det kan nok diskuteres, om de alle beskæftiger sig med arkitektur. For arkitektur handler om at organisere på et overordnet niveau, i modsætning til at udforme løsningens detaljer.

I forbindelse med de konkrete opgaver, som EA Fellows løser for større kunder, er vi stødt på flere af de ovennævnte arkitekter, og mange tankevækkende beskrivelser af arkitektur. Derfor vil vi her give vores bud på, hvad arkitektur er, og – måske lige så vigtigt – hvad det ikke er.

Arkitektur er ikke tomme ord

“Arkitektur” er ikke en ny og opgraderet version af “bullshit-bingo” hvor det gælder om at kunne benytte flest akronymer og frameworks, på en måde så al tale bliver sort for dem som lytter. Hvis det er oplevelsen, så er det en sælger der taler – og ikke en arkitekt.

Arkitektur er ikke en konsulentydelse

“Arkitekter” er ikke en titel der er forbeholdt konsulenter, der er også en stor andel arkitekter i forskningsmiljøet og blandt de ansatte i offentlige og private virksomheder.

Arkitektur er ikke programmering

“Arkitektur” er mere end udvikling af ny software. Programmører og projektledere er ikke arkitekter, det er personer der har til opgave at skrive kildetekst, lave applikationer og styre implementeringen. Arkitektur handler om at organisere løsningens elementer på et overordnet niveau, og tage de principielle beslutninger for løsningens udformning.

Arkitektur indeholder mange discipliner

Der er mange discipliner indenfor arkitektur, og de har hver til sin tid en berettigelse. Hvis discipliner udelades, det være sig tekniske, organisatoriske eller procesmæssige, så bliver resultatet ensidigt og ukomplet. Alle discipliner må balanceres efter opgave, organisation og modenhed, for et skævt fokus vil føre til bristede illusioner og gode spildte kræfter for alle involverede.

Arkitektur kræver samarbejde og governance

En “stærk ledelsesforankring” eller anden form for “stærkt lederskab” bliver ofte nævnt som et element i arkitekturen, men det vil i sig selv aldrig løse opgaven for forretningen. Arkitekturen er en “opskrift”, som forretningsorganisationen sammen med ledelsen kan bruge til at løse de konkrete problemer og udfordringer, men det kræver at organisationen er i stand til at tage beslutninger og handle, for at realisere opskriften.

Arkitektur starter i forretningen

“Arkitektur” der ikke tager udgangspunkt i service til forretningen, krav eller ønsker fra forretningen, er ikke arkitektur, men elementer i en løsning. En “rigtig” arkitektur er en udmøntning af forretningsstrategien, og indeholder elementer som forretningsmodel (business case), nøgleprocesser og forbedringspotentiale (benefit realization), som definerer løsningens succesparametre.

Arkitektur er ikke en akademisk øvelse

Arkitekturarbejde som ikke er operationaliseret eller kan operationaliseres af andre, kan ikke betegnes som arkitektur. Det er akademiske øvelser, henstillinger, visioner eller dokumenter, som med stor sandsynlighed har størst værdi for forretningen i anden sammenhæng. “Rigtig” arkitektur giver grundlag for en praktisk implementering.

Arkitektur skal ikke være smuk – den skal være rigtig

Når vi taler om god arkitektur, er det altså ikke et spørgsmål om smag, men om løsningerne er hensigtsmæssigt struktureret i forhold til de opgaver de skal understøtte, og opfylder de overordnede målsætninger for den forretning, der skal bruge løsningerne.

Arkitektur giver ingen gevinster i sig selv

“Arkitektur” er ingen “silver bullet” eller frelsende Yourdon projektmodel, som giver løfte om umiddelbart målbare gevinster. Til gengæld er arkitekturarbejdet en god metode til at binde forretning og IT sammen på en måde, der sætter det positive samspil i fokus og giver mulighed for at høste nye fordele.

Disciplinen “arkitektur” er inde i en udvikling, hvor der er utrolig stor efterspørgsel, men få klare og entydige definitioner, endnu færre målepunkter for kvalitet og succes. I samarbejdet med vores kunder sætter vi fokus på at få defineret arkitektur i kundens kontekst og i forhold til organisationens modenhed. Vi bidrager også med konkretisering af arkitektur funktionens mandat og rolle, så arkitekturprocessen placeres rigtigt i forhold til de eksisterende forretnings og IT-funktioner i kundens organisation.

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.

Principper eller sagsbehandling

De fleste kender eksempler på, at der i en styregruppe, bestyrelse eller en anden form for topledelse, bliver brugt alt for megen tid på praktisk sagsbehandling. Et eksempel kunne være, at en kommunalbestyrelse bruger timer på at diskutere om en bestemt grundejer skal have dispensation til at bygge en carport, og hvor tæt på vejen den må opføres. Sådan kan det gå, hvis reglerne er uklare, eller hvis der er tradition for, at man vurderer hver enkelt sag for sig.

På IT området kan der på samme måde gå lang tid med at diskutere konkrete løsninger, produkter og leverandører i hver enkelt anskaffelsessag, hvis man ikke på forhånd har taget stilling til, hvilke generelle krav og standarder, de nye systemer skal leve op til. Naturligvis kan man bare uddelegere beslutningen til en fagmand, som fx IT chefen. Men kan man nu være sikker på, at han vælger, som ledelsen ville have gjort? Eller vil han lade sine egne præferencer spille ind?

Så er det måske bedre at sætte sagen i udvalg, og bede om en indstilling fra en gruppe af interessenter? På den måde vil det helt sikkert koste endnu flere ressourcer, før beslutningen er truffet.

Hvis man vil økonomisere med ledelsesressourcerne, og sikre at beslutningerne bliver taget til tiden, er det nyttigt at være “på forkant”. Det betyder, at man i ledelsesgruppen formulerer (og godkender) principper, som definerer den “normale” afgørelse af ofte forekommende sager.

På den måde reduceres behovet for sagsbehandling i ledelsesgruppen, fordi mange spørgsmål kan afgøres administrativt udfra principperne. Men det udelukker jo ikke muligheden for, at den enkelte sag kan forelægges ledelsesgruppen, hvis der er grund til at fravige princippet – eller hvis princippet skulle trænge til en justering.

Mange principper kan defineres på baggrund af vigtige beslutninger, man tidligere har taget (og investeret mange kræfter i). Det er en udbredt praksis i den offentlige administration. Så hvorfor ikke bruge den samme metode, når vi taler om IT ?

Fordelen ved at benytte principper, er at man undgår at diskutere de samme problemstillinger igen og igen. Det betyder, at ledelseskræfterne kan frigives til ledelse.