1

Hvidbog omIT-arkitektur

Arbejdsgruppe om IT-arkitektur i regi afDet Koordinerende Informationsudvalg 2003

2

Publikationen kan hentes på www.oio.dk/arkitektur

Udsendt af Ministeriet for Videnskab, Teknologi og UdviklingBredgade 431260 København KTlf. 3392 9700E-post: vtu@vtu.dkISBN: 87-91258-64-2

Juni 2003, oplag: 1000 eksemplarer.

Tryk: Schultz Grafisk

3

Indhold

Forord ........................................................ 5

1. Resumé .................................................. 6

2. Anbefalinger .......................................... 82.2. En fælles IT-arkitekturramme .................132.3. Kommunikation og kompetenceudvikling 192.4. Konsekvenser ...........................................20

3. Hvidbogens formål og baggrund ......... 233.1. Visionen om digital forvaltning .................233.2. Fra Grønbog til Hvidbog til …. ...................263.3. Danmark i internationalt perspektiv ........283.4. Arkitekturarbejdets ledetråde .................32

4. Den digitale byplanlægning ................. 334.1. Byplan og IT-arkitektur ............................334.2. Hvordan skal vi arbejde

med IT-arkitektur? ...................................364.3. En arkitekturudvikling i

flere hastigheder ......................................474.4. Økonomiske perspektiver.........................49

4

5. Principper ............................................ 525.1. Interoperabilitet ........................................535.2. Sikkerhed ..................................................555.3. Åbenhed ....................................................575.4. Fleksibilitet ...............................................585.5. Skalerbarhed ............................................595.6. Retningslinier for IT arkitektur ................60

6. Standarder og løsninger ...................... 636.1. Infrastrukturløsninger .............................646.2. Tekniske Standarder .................................686.3. Informationsarkitektur .............................726.4. Sikkerhedsarkitektur ...............................73

7. Praksisfællesskaber omarkitekturkomponenter ....................... 767.1. Porteføljer af arkitekturkomponenter .....777.2. Fælles kontraktmodeller ..........................807.3. Fælles funktionsbeskrivelser ...................817.4. Fælles datamodeller.................................827.5. Fælles komponenter og services .............837.6. Fælles infrastrukturmønstre....................84

8. Koordinering, kompetencerog kommunikation ............................... 868.1. Koordinering .............................................868.2. Kompetencer og kommunikation .............92

Bilag A ..................................................... 94

5

Digital forvaltning handler i høj grad om at få de offentlige IT-systemer gearet til at spille sammen. Myndighederne skal havemulighed for at anvende hinandens data, så borgere,virksomheder og sagsbehandlere ikke skal aflevere ogkontrollere de samme informationer mange gange. Det kræverfor eksempel fælles definitioner af data og sammenhæng ihåndteringen af sikkerhed og brugere. Og det kræver at mangør op med »teknologiske øer«, hvis man skal skabe grundlagfor nye måder at løse opgaverne på.

En sammenhængende offentlig IT-arkitekturramme er envæsentlig faktor i denne sammenhæng. Derfor har Danmarkligesom en række andre lande nu sat IT-arkitektur højt pådagsordenen, fordi det er gennem IT-arkitekturen, man kanstyre hvordan IT-systemer indrettes og spiller sammen. Det erbaggrunden for denne hvidbog om principperne for en fællesoffentlig IT-arkitektur.

Hvidbogen er udarbejdet af det KoordinerendeInformationsUdvalg (KIU) – et tværoffentligtkoordinationsorgan på det IT-faglige område – som en direkteopfølgning på Videnskabsministeriets grønbog, konference ogelektroniske høring om emnet i efteråret 2002. Arbejdet medIT-arkitektur er en del af Projekt Digital Forvaltning og KIUrefererer til bestyrelsen for Projekt Digital Forvaltning itværoffentlige sager vedrørende IT-arkitektur.

Hvidbogen giver forslag til et både bredere og mere kvalificeretarbejde med IT-arkitektur i den offentlige sektor i Danmark.Formålet er at opnå et generelt kvalitetsløft af den proces,hvorunder offentlige IT-systemer udvikles i et samarbejde medIT-branchen.

Du kan læse mere om IT-arkitektur på http://www.oio.dk.

På vegne af det Koordinerende Informationsudvalg

Marianne Rønnebæk

Forord

6

Regeringens moderniseringsprogram har sat som mål atforbedre servicen overfor borgere og erhvervsliv – og samtidigøge effektiviteten af den offentlige administration. Midlet er atkombinere IT med en stor organisatorisk omstilling, hvorledelse, arbejdsdeling, arbejdsprocesser og kompetencer erunder forandring.

Projekt Digital Forvaltnings opgave er at fremme digitalforvaltning på tværs af den offentlige sektor blandt andet ved atfjerne eller begrænse barrierer af teknologisk karakter. Enafgørende forudsætning for at Danmark kan tilbydesammenhængende offentlige services til borgere ogvirksomheder, er, at de forskellige systemer, der leverer disseservices, hænger sammen. Det fremhæves ofte, at denorganisatoriske side af en omstillingsproces udgør 80%, mensteknologi kun udgør 20%. Men det betyder naturligvis ikke, atden teknologiske del ikke er vigtig, i og med at det ofte erfundamentet for at man kan ændre organisationen.

Danmarks Statistiks undersøgelse af offentlig IT-brug i 2002viser, at nogle af de vigtigste barrierer for digital forvaltningnetop ligger inden for IT-arkitekturområdet. På tværs af stat,amter og kommuner er det således omkring 7 ud af 10myndigheder, som savner fælles offentlige løsninger oginfrastruktur, og nogenlunde lige så mange savner fællesstandarder for dataudveksling. Lidt over halvdelen af deadspurgte statslige institutioner forventer endvidere en stigningi IT-udgifterne i 2002 til 2003 til integration af eksisterendeapplikationer.

Hvidbogen er som en del af Projekt Digital Forvaltningudarbejdet i et samarbejde mellem stat, amter og kommuner iregi af det Koordinerende Informationsudvalg. Hvidbogenshovedanbefalinger er:• Den offentlige sektor – enkeltmyndigheder og fælles

projekter – bør tage et mere aktivt ansvar for egen IT-arkitektur.

1 Resumé

7

• Der bør etableres en fælles IT-arkitekturramme forplanlægning af offentlige IT-systemer med særligt henblikpå sikring af interoperabilitet.

• Der bør ske en markant indsats for at udbrede viden om ogudvikle kompetencer vedrørende IT-arkitektur, specieltomkring de fælles offentlige initiativer.

Den fælles IT-arkitekturramme skal indeholde følgendeelementer:• Fælles koordinering, herunder etablering af en IT-

arkitekturkomité med reference til Det KoordinerendeInformationsudvalg

• Fælles metoderamme i form af proces, begreber ogbeskrivelsesstandarder for IT-arkitektur.

• Fælles valg vedrørende standarder og infrastruktur medvidere, blandt andet i form af en referenceprofil ogprincipper for IT-arkitekturen.

• Fælles værktøjer i form af blandt andet fælles databaser ogbiblioteker over aftalemodeller, procesbeskrivelser,datadefinitioner, softwarekomponenter samt beskrivelser afinfrastrukturløsninger.

Et øget fokus på IT-arkitektur og en vis koordinering på tværsaf de offentlige myndigheder – med skyldig hensyntagen tilsåvel den private sektor og internationale forhold – er enforudsætning for at realisere visionerne om digital forvaltning.Gevinsterne ved et øget fokus på IT-arkitektur kan høstes fleresteder:• Værdien af investeringerne bliver optimeret.• Risikoen for det enkelte projekt bliver minimeret.• IT-markedet bliver mere fleksibelt og konkurrencen øget.

I alle IT-projekter tages der »bevidst eller ubevidst«arkitekturbeslutninger om forskellige hensyn, perspektiver ogmål. Målet med Hvidbogen er at gøre beslutningerne merebevidste. De fælles arkitekturprincipper vil samordne dissebeslutninger og dermed skabe øget værdi i det offentliges ITanvendelse. Arkitekturarbejdet er en investering (fra detoffentlige), som giver gevinster i hele systemets levetid.

8

Digital forvaltning kan ikke realiseres, hvis de offentlige IT-systemer ikke er gearet til at spille sammen. Digital forvaltninghandler blandt andet om at give myndighederne mulighed for atanvende hinandens data, så borgere, virksomheder ogsagsbehandlere ikke skal aflevere og kontrollere de sammeinformationer mange gange.

I regeringens moderniseringsprogram Med borgeren ved roretfra maj 2002 er det udtrykt således:

Ny teknologi skal være med til at skabe øget samarbejde påtværs af den offentlige sektor og traditionellesektorafgrænsninger. Under hensyntagen til borgernesretssikkerhed skal det sikres, at der kan udvekslesinformationer mellem offentlige IT-systemer, så borgerneoplever den offentlige sektor som en effektiv ogvelfungerende helhed. Dermed undgås dobbeltarbejde, ogborgerne slipper for at afgive de samme informationer fleregange.

Det stiller nye krav til IT-systemerne, når mange systemer skaltil at spille sammen. Det kræver for eksempel fællesdefinitioner af data og sammenhæng i håndteringen afsikkerhed og brugere. Det kræver, at man gør op med»teknologiske øer«, hvis man skal skabe det teknologiskegrundlag for nye måder at løse opgaverne på. Etablering af enfælles ramme for IT-arkitektur er en væsentlig faktor i dennesammenhæng.

IT-arkitektur beskriver den grundlæggende organisering af eteller flere IT-systemer, herunder principper for systemernesdesign og udvikling og for deres indbyrdes sammenhæng.Etableringen af en fælles ramme for IT-arkitekturen betyder, atløsningerne beskrives udfra en fælles begrebsramme, og at denenkelte IT-løsning organiseres således, at den kan indgå i etfunktionelt samspil med de øvrige.

Dette er en erkendelse i Danmark, der – ligesom i en rækkeandre lande – har sat IT-arkitektur højt på dagsordenen, fordi

2 Anbefalinger

9

det er gennem IT-arkitekturen, at man kan styre, hvordan IT-systemer indrettes og spiller sammen. Bestyrelsen for ProjektDigital Forvaltning, der består af administrative topchefer frastat, amter og kommuner, har således peget på, at der isammenhæng med udviklingen af forvaltningensforretningsprocesser og organisering også skal ske etsystematisk arbejde i relation til indretningen af de IT-løsninger, som skal understøtte de nye måder at arbejde på.

Den følgende figur illustrerer hvorledes et højtmodenhedsniveau for den digitale forvaltning har to basaleforudsætninger: For det første kræves en modning afforretningen og koordinering af nye og gamleforvaltningsprocesser, og for det andet skal IT-systemernekunne understøtte specielt de nye processer. Til hvertmodenhedsniveau knytter sig både en forretnings-mæssigvision og et teknologisk fundament – og arkitekturprocessensopgave er at binde disse to elementer sammen.

Figur 1 - Modning af digital forvaltning med services forborgere og virksomheder

Effektiviserings-potentiale

Teknologiskeforudsætninger

Serviceniveau

Integrerede on-line services påtværs af organisationer, fuldautomatisering

Transaktioner, afgrænsedeselvbetjeningsløsninger

Portaler, simple blanketter, søgemaskiner

Simple hjemmesider

10

Modningsprocessen sker så at sige ved at gå på to ben, altsåved en samtidig udvikling af forretning og teknologi. Medarkitekturprogrammet søges tilvejebragt forudsætningerne foren forretningsorienteret strategi for IT-udviklingen med detformål at fremme de værdiskabende processer. Derfor er detnødvendigt, at de organisatoriske processer er tilrettelagt ioverensstemmelse med visionen, før IT-løsningerne optimeres iforhold til arbejdsgangene. Uden det organisatoriske forarbejdevil kravene til IT-systemet være upræcise, og mangeforventninger til IT-understøttelsen vil ikke kunne opfyldes.Det er således ofte konstateret, at IT-systemernes fleksibilitetikke kan kompensere for manglende eller upræcis planlægningaf de processer, systemerne skal støtte.

Ministeriet for Videnskab, Teknologi og Udvikling har alleredeklart meldt ud, at ministeriet vil fungere som facilitator ogunderstøtte denne udvikling gennem en række initiativer.

I september 2002 udgav Ministeriet for Videnskab, Teknologiog Udvikling en grønbog om IT-arkitektur, som havde tilformål at sætte det fælles behov for en offentlig IT-arkitekturpå dagsordenen og lægge op til en debat om fælles offentligeprin-cipper for IT-arkitektur. Grønbogen lagde op til enoffentlig debat om spørgsmålene: Skal vi have en fælles rammefor IT-arkitektur? Hvordan skal den se ud? Hvordan sikrer vi, atden rent faktisk bliver brugt?

Debatten er i gang, og potentialerne er åbenlyse: For detoffentlige er det øget kvalitet i sagsbehandlingen med konstanteeller faldende udgifter til følge. For industrien er der tale om etklart potentiale for rationel udvikling af avancerede løsningertil digital forvaltning.

Processen har givet mange konstruktive indspark fra såvel stat,amter og kommuner såvel som fra leverandører, konsulenthuseog brancheforeninger med flere og har entydigt vist, at der erbehov for en fælles ramme.

11

Denne Hvidbog er udarbejdet af Det KoordinerendeInformationsudvalg som en direkte opfølgning på Grønbogenog med inddragelse af de mange indspark fra høringsprocessen.Den giver forslag til et både bredere og mere kvalificeretarbejde med IT-arkitektur i den offentlige sektor i Danmark.Formålet er – som et bidrag til arbejdet med digital forvaltning– at opnå et generelt kvalitetsløft af den proces, hvorunderoffentlige IT-systemer udvikles i et samarbejde med IT-branchen.

Grønbogen og Hvidbogen er de første trædesten i en langproces. I næste fase bør der sættes gang i opbygningen af detkonkrete grundlag, som kan sikre både udviklings- ogdriftsopgaver knyttet til en mere sammenhængende og effektivIT-anvendelse i det offentlige.

Hvidbogens hovedanbefalinger er:• Den offentlige sektor – enkeltmyndigheder og fælles

projekter – bør tage et mere aktivt ansvar for egen IT-arkitektur.

• Der bør etableres en fælles IT-arkitekturramme forplanlægning af offentlige IT-systemer med særligt henblikpå sikring af interoperabilitet.

• Der bør ske en markant indsats for at udbrede viden om ogudvikle kompetencer vedrørende IT-arkitektur og de fællesoffentlige initiativer.

Disse anbefalinger bør følges op hurtigst muligt, idet derløbende gennemføres investeringer i IT-projekter medbetydelige konsekvenser for fremtiden. Jo før man kommer igang, desto bedre. En handlingsplan bør være pragmatisk ogbygge aktiviteterne op løbende. Den samlede udfordring iprojekt digital forvaltning er stor, og alt kan ikke nås på kort tideller på én gang. Derfor bør der satses på at starte opbygningenaf den fælles ramme og implementering i større strategiskeprojekter.

12

2.1. Det offentliges ansvar for egen IT-arkitekturHvidbogens centrale anbefaling er, at det offentlige bør tage etmere aktivt ansvar for sin IT-arkitektur for at kunne realiseremålene for digital forvaltning.

Det kan give problemer for udviklingen af den digitaleforvaltning, hvis den enkelte myndighed opbygger IT-systemerpå en måde, som reelt kommer til at forhindre, at deressystemer kan indgå i det fællesskab, hvor myndigheder – ogprivate – arbejder sammen, deler data og integrerer hinandenselektroniske services. Derudover kan det også give problemerfor den enkelte myndighed, fordi man over tid vil stå med en altfor bred portefølje af IT-systemer, som ikke kan integreres, ogsom er relativt tung at vedligeholde.

Mange offentlige IT-systemer er hidtil blevet udviklet ud franogle relevante, men samtidig ret snævre hensyn, hvor »bedstog billigst« princippet i mange tilfælde har været ensbetydendemed at køberen har fokuseret på at få opfyldt sine egnefunktionelle behov til den lavest mulige pris, og leverandørenhar optimeret arkitekturen ud fra sin egen produktportefølje. Vihar derfor ofte set løsninger, hvor den leverede funktionalitetsvarer godt til den ønskede, men hvor overordnede oglangsigtede hensyn, herunder muligheden for integration medandre systemer, er blevet prioriteret lavere.

Nye krav til sammenhængende løsninger fordrer, at deoffentlige myndigheder ved strategiske systemanskaffelsertager stilling til de spørgsmål, som er afgørende forsystemernes værdi over hele levetiden og deres mulighed for atindgå i et samarbejde med andre systemer. Det betyder foreksempel, at den enkelte myndighed må stille krav tilsystemernes organisering – og ikke blot til deres funktion. Detbliver dermed myndighedens ansvar at sikre, at IT-arkitekturenikke snævert dækker et enkelt system, men derimod dækker etkompleks af systemer, så de kan fungere sammen.

13

Systemleverandørerne vil fortsat have til opgave atsammensætte infrastruktur-komponenter til en samlet løsningog at implementere forretningslogikken i disse komponenter.Når det offentlige stiller krav til IT-arkitekturen, vil valget afkomponenter og snitflader imidlertid blive underlagt et sætfælles principper, som skal sikre sammenhængen mellem deoffentlige IT-systemer. IT-arkitekturen skal sikre, at løsningensoverordnede struktur svarer til de forvaltningsmæssige krav ogde fælles arkitekturprincipper. Derfor bør arkitekturarbejdetforankres i den offentlige myndighed, men kan eventueltvaretages af en konsulent på myndighedens vegne.

En væsentlig konsekvens af at stille krav til arkitekturen er, atkonkurrencen øges. Når en offentlig myndighed stiller krav tilet IT-systems organisering, opnås en større sammenlignelighedmellem de tilbudte løsninger, og mulighederne for at kombineremoduler fra forskellige leverandører forbedres.Arkitekturkravene kan indgå i de offentlige udbudsforretningerpå linie med de funktionelle og operative krav.

For at kunne løfte ansvaret for IT-arkitekturen og levere deønskede resultater i forbindelse med visionen om digitalforvaltning må de offentlige myndigheders IT-arkitektur byggepå en fælles referenceramme, så de lokale systemer kan indgå iden samlede digitale forvaltning. Desuden må der løbende skeen udvikling af viden og kompetencer omkring IT-arkitektur.Dette gælder beslutningstagere i såvel forretningslaget som iteknologilaget.

2.2. En fælles IT-arkitekturrammeHvidbogen anbefaler, at den fælles IT-arkitekturrammeindeholder følgende elementer:• Fælles koordinering, herunder etablering af en IT-

arkitektur komité med reference til Det koordinerendeInformationsudvalg.

• Fælles metoderamme i form af proces, begreber ogbeskrivelsesstandarder for IT-arkitektur.

14

• Fælles valg og principper vedrørende standarder oginfrastruktur med videre, blandt andet i form af enreferenceprofil og den serviceorienterede IT-arkitektur.

• Fælles værktøjer i form af blandt andet fælles databaserog biblioteker over aftalemodeller, procesbeskrivelser,datadefinitioner, softwarekomponenter samt beskrivelser afinfrastrukturløsninger.

Fælles koordineringDet er en forudsætning for en succesrig videreudvikling afarbejdet med IT-arkitekturen, at der etableres passende formellerammer for arbejdet. Rammer, der inddrager og ansvarliggørnøgleinteressenterne på området.

Arkitekturarbejdet bør tage udgangspunkt i nærhedsprincippetsamtidig med at roller og mål for arkitekturarbejdet børfastlægges i et samarbejde mellem forretningslaget (de øverstebeslutningstagere) og teknologilaget (IT-chefer, IT-arkitekter,rådgivere, leverandører med flere).

Det anbefales at oprette en IT-arkitekturkomité, der somansvarsområde får arbejdet med at udvikle og vedligeholde denfælles IT-arkitekturramme. En væsentlig opgave for en sådankomité vil være at afveje den enkelte myndigheds interesser iforhold til den samlede offentlige sektor i Danmark.Afvejningen vil danne baggrund for de anbefalinger ogvejledninger, som komitéen udgiver. En anden vigtig opgave vilvære at tilbyde rådgivning i forbindelse med strategiskeoffentlige udviklingsprojekter.

Komitéen bør forankres i det KoordinerendeInformationsudvalg og herigennem referere til bestyrelsen forProjekt Digital Forvaltning. Komitéen bør sammensættes medeksperter, der dækker et bredt spektrum af især IT-faglig, menogså forvaltnings- og forretningsfaglig viden.

Det Koordinerende Informationsudvalg og IT-arkitekturkomitéen bør have til opgave at facilitere arbejdet

15

med IT-arkitektur i stat, amter og kommuner. I mange tilfældeforudsætter implementeringen af ny tværgående IT-arkitektur,at der foreligger forretningsmodeller, som kan skabe detnødvendige incitament.

Eksempelvis har bestyrelsen for Projekt Digital Forvaltningudpeget en række indsatsområder, hvor det er bestyrelsensvurdering, at der er særligt behov for at skabe nye tværgåendeforretningsmodeller. I forlængelse af disse forretningsmodellerskal der i mange tilfælde aftales IT-arkitekturer på tværs afforvaltningsgrænser; IT-arkitekturkomitéen vil skulle biståstyregrupperne hermed.

Blandt komitéens konkrete opgaver kan nævnes:• Valg, udvikling og vedligeholdelse af fælles koncepter,

metoder og principper.• Valg, udvikling, vedligeholdelse og formidling af relevante

standarder.• Facilitere deling af viden, erfaringer og værktøjer.• Sparring og rådgivning af enkeltmyndigheder og

fællesprojekter.• Bidrag til den videre planlægning af konkrete tiltag.

Sparring og rådgivning bør fokusere på igangværende projekterog aktiviteter inden for højt prioriterede sektorer. Sparring tilprojekter kan tage form af et aktivt review af arkitekturen tiloffentlige IT-projekter, og den generelle arbejdsform vil væremere faciliterende end kontrollerende.

Komitéen vil i praksis have behov for et sekretariat, der kanpåtage sig rollen som omdrejningspunktet i et nationaltkompetencemiljø for offentlig IT-arkitektur.Videnskabsministeriet foreslås som sekretariat, og ministerieter allerede begyndt at opruste kompetencerne på området.

Herudover bør der opbygges et forum for IT-arkitektur, hvorspecialister hos myndigheder, leverandører, rådgivere ogforskere blandt andet kan samarbejde gennem dialog og

16

videndeling. Dette forum vil være en del af kompetencemiljøetog vil blandt andet kunne fungere som en underbygning tilkomitéen.

Fælles metoderammeHvidbogen understreger behovet for, at arkitekturarbejdet måarbejde hen imod større ensartethed i begrebsapparatet,metoder og procesbeskrivelser.

Arkitekturen bliver til i en sammenhængende proces, der skalsikre, at visionens pejlemærker bliver afspejlet i de tekniskeløsninger, så IT-løsningerne er optimerede i forhold til denoffentlige forvaltnings overordnede behov. IT-arkitektur er enkontinuerlig proces, der har til formål at sikre en løbendeforbedring af IT-anvendelsens værdi. Kontinuiteten iarkitekturprocessen er vigtig, specielt i en verden hvor agilitet,nytænkning og forandring præger udviklingen.

I arkitekturprocessen formulerer man de konceptuellearkitekturprincipper, som styrer valget og organiseringen af ITløsningerne. En nøglefaktor er at beskrive de ønskede – ellerpåtvungne – forretningsmæssige ændringer, som IT skalunderstøtte. Arkitekturprincipperne benyttes som udgangspunktfor den løsningsorienterede og praktiskeimplementeringsproces, der indeholder anskaffelses- ellerudviklingsprojekter.

Der bør udvikles fælles metoder og begrebsapparat tiludarbejdelse af IT-arkitektur. Det er afgørende, at der etablereset fælles sprog og fælles procedurer, hvis man skal nå de målomkring samarbejde, harmonisering og deling i relation til IT-arkitektur, som Hvidbogen beskriver.

Arkitekturens metoder og begrebsapparat bør dokumenteresgennem løbende udgivelse af vejledninger og checklister. Derbør for eksempel udgives en kogebog for god arkitekturpraksisog en checkliste for arkitekturbeslutningerne i konkreteprojekter.

17

Det fælles metodeapparat bør endvidere omfatte enbeskrivelsesstandard for arkitekturprocessens beslutninger ogprincipper og for fælles arkitekturkomponenter, som kangenanvendes. Ved en sådan fælles beskrivelsesform lettessammenligningen af forskellige projekter og tværgåendeudnyttelse af erfaringer og viden.

Valget mellem forskellige IT-implementeringer – som foreksempel centrale eller decentrale servere – vil blive baseret påanalyse af en række afgørende faktorer som datamængder,opdateringsfrekvens, kommunikationsmønstre etc., som alle erestimeret ud fra den beskrevne opgave og anvendelsessituation.Det er ikke en forudsætning for at optimere den samledeoffentlige IT arkitektur, at alle løsninger benytter den sammekonkrete arkitektur – tværtimod anbefales det, at man i detenkelte projekt foretager en lokal optimering, under anvendelseaf det samme metodegrundlag.

Grundkonceptet for godt IT-arkitekturarbejde er, at det erprincipstyret. Arkitekturarbejdet skal sikre sammenhængenmellem kravene og principperne, således at forretningskravenevil være opfyldt af en løsning, der efterlever principperne, og atde gældende principper altid er begrundet medforretningsmæssige krav.

Fælles valg og principperArkitekturprincipperne opstilles i et hierarki med flere niveauer.Det øverste niveau omfatter fælles, overordnede principper,som blandt andet afspejler behovet for sammenhæng på tværsaf den offentlige sektor. Det næste niveau omfatter principper,som typisk har til formål at optimere IT-løsningerne inden foren enkelt sektor eller et indsatsområde. På det laveste niveaufinder vi principper, som er rettet mod et konkret system elleren portefølje af systemer i en enkelt institution.

Hvidbogen anbefaler som et overordnet princip enserviceorienteret arkitekturmodel, hvor IT-løsninger designesmodulært, opdelt i services (tjenester) med veldefinerede

18

grænseflader til hinanden og i videst muligt omfang til alleredeeksisterende offentlige IT-systemer.

Det gennemgående princip i den serviceorienteredearkitekturmodel er, at de enkelte komponenter er organiseret ilag, som tilbyder og benytter services hos hinanden. Det fælleskoncept betegnes derfor som den serviceorienteredearkitekturmodel. I modsætning til simpel dataadgang giverservices mulighed for at udveksle informationer i en kontekstog åbner dermed for avanceret interoperabilitet mellem denoffentlige administrations IT-systemer. Lagdelingen gør detmuligt at kategorisere de enkelte services, så de kansammenbinde forskellige systemer på samme funktionelleniveau.

En del af de fælles principper er en standardisering, der kansikre at data kan udveksles i den offentlige sektor uden tekniskebarrierer. Standardiseringen skal fokusere på understøttelse afinteroperabilitet, sikkerhed og tilgængelighed og bør omfattebåde de tekniske standarder, som gør sammenkoblingen mulig,og informationsstrukturen, som definerer den fælles forståelseaf data. Et eksempel er valget af udvekslingsformatet XML iDanmark. Den tekniske standardisering bør tage udgangspunkti internationale, åbne standarder eller i mangel heraf de factostandarder. Det vil være en central opgave for komitéen atudarbejde en oversigt over standarder med anbefalinger omderes anvendelse. En sådan oversigt – en referenceprofil – kanfor eksempel indgå i de offentlige myndighedersudbudsmateriale. Referenceprofilen skal løbendevedligeholdes.

Andre principper beskriver brugen af fællesinfrastrukturløsninger, herunder services knyttet tildataudveksling, sikkerhed og identifikation. Et eksempel herpåer valget af digital signaturløsning i Danmark. Her er det enarkitekturopgave at organisere sikkerhedsfunktionerne og atspecificere deres egenskaber, så de opfylder visionen. Derfor erder også på sikkerhedsområdet behov for, at krav og løsninger

19

beskrives udfra et fælles koncept og koordineres på detoverordnede plan.

Fælles værktøjerEn vigtig opgave består i at facilitere anvendelsen ogudbredelsen af standardarkitekturer og løsninger. Det anbefalesat stille faglig/administrativ kapacitet til rådighed for driften afen fællesoffentlig informationsbase i form af envidereudvikling af det fælles offentlige netsted oio.dk oginfostrukturbasen. Denne skal blandt andet indeholde bibliotekover designløsninger, komponenter, processer og services.Desuden kan der med fordel stilles egentlige ledelsesmæssige,analytiske og tekniske værktøjer til rådighed for eksempel tilbenchmarking og analyse.

Udover de i Hvidbogen fremlagte temaer må arbejdet iarkitekturkomitéen have adgang til viden om de eksisterendesystemer i det offentlige og de koncepter, disse er modelleretefter. Der mangler i dag tilstrækkeligt overblik over densamlede offentlige systemportefølje. Der bør derfor systematiskindsamles viden på dette område. Ligeledes er det nødvendigtat følge den internationale udvikling på dette område. Dette vilsom sideeffekt have identifikation af en række fremtidsrettedeprojekter, hvoraf nogle givetvis vil kunne tjene som bedstepraksis eksempler for andre løsninger. Denne dataindsamlingvil kunne udfylde en vigtig funktion som koordinator mellemoffentlige IT-projekter.

Samarbejde og videndeling mellem offentlige myndighedersåvel som private leverandører, rådgivere og forskere med flerevil være en afgørende forudsætning for at nå målene om digitalforvaltning.

2.3. Kommunikation og kompetenceudviklingFor at sikre udbredelsen af de fælles principper, metoder ogprocesser er der behov for både kommunikation ogkompetenceudvikling. Komitéen og sekretariatet for IT-

20

arkitektur vil som en af sine væsentlige opgaver have at sikrebred information om og markedsføring af arkitekturtanken.

Der bør ske en synliggørelse af projekter med god IT-arkitekturog af IT løsninger, der er opbygget i overensstemmelse med deudgivne retningslinier og standarder (referenceimplementeringer).

IT-arkitektur er ikke et udbredt fag på de højere uddannelsereller i andre undervisningssammenhænge. En vigtig opgave vilvære ledet af den foreslåede IT-arkitekturkomité, at beskriveog deltage i opbygningen af kompetencegivendeuddannelseselementer, typisk med afsæt i eksisterendeuddannelser og efteruddannelser. En egentlig certificering ansesfor at være et vigtigt incitament for at øge kompetenceniveauetindenfor IT-arkitektur.

2.4. KonsekvenserEt øget fokus på IT-arkitektur og en vis koordinering på tværsaf de offentlige myndigheder – med skyldig hensyntagen tilsåvel den private sektor og internationale forhold – er enforudsætning for at realisere visionerne om digital forvaltning.Hvis man ikke igangsætter initiativer, som svarer til dem, somdenne hvidbog anbefaler, er der risiko for, at mange projekterikke vil leve op til forventningerne og blive unødvendigt dyre.

En fælles offentlig ramme for IT-arkitekturen vurderes derforsom en helt afgørende parameter for udbredelse af digitalforvaltning. Den fælles ramme skal sikre, atarkitekturbeslutningerne tilgodeser behovet for tværgåendesammenhæng mellem det offentliges IT-systemer, samtidigmed at systemerne optimeres i forhold til de lokale behov.

IT-arkitektur er et velegnet redskab til at sikre en fælles rammemed henblik på kvalitetsforbedring, ressourceoptimering ogomkostningsreduktion. Et samarbejde omkring IT-arkitekturengiver ikke blot bedre sammenhæng mellem IT-systemerne – detåbner også mulighed for store gevinster på to fronter, for det

21

første ved at værdien af investeringerne bliver optimeret, og fordet andet ved at omkostningerne bliver reduceret med genbrugaf fælles komponenter og services. På denne måde er arbejdetmed IT arkitektur et vigtigt redskab til understøttelse afregeringens øvrige effektiviseringsinitiativer.

En fælles ramme for IT-arkitektur, der blandt andet prioritereråbne standarder vil desuden medvirke til at skabe øgetgennemsigtighed og konkurrence på markedet. Det vil betydebåde lavere priser og mindsket leverandørafhængighed.

De enkelte myndigheder vil naturligt have et varierende niveauaf kompetence på IT-området, og de kan derfor indtageforskellige roller i arkitekturarbejdet: For eksempel vil enmyndighed i visse situationer kunne læne sig op ad en fællesoffentlig referenceprofil og genbruge velfungerende løsninger,således at arkitekturen (næsten) vil være prædefineret i IT-projekter, som ligger meget tæt op af projekter i andremyndigheder. I andre tilfælde vil det være aktuelt at benyttearkitekturprincipperne som del af kravspecifikationen for atsikre, at et nyt system vil overholde de fælles behov forinteroperabilitet. Hvor det drejer sig om store systemer, nyteknologi eller understøttelse af nye arbejdsgange, vil det værehensigtsmæssigt at gennemføre en lokal IT-arkitekturproces forat sikre, at systemet er optimeret til processen, samtidig med atdet overholder de fælles principper for interoperabilitet.

Indførelsen af en fælles IT-arkitekturramme vil medføre størreværdirealisering, fordi systemerne lettere vil kunne understøtteændringer i organisation og arbejdsgange. Desuden vil detmedføre en mindsket risiko i udviklingen af IT-løsninger, fordider er klare fælles rammer og muligheder for genbrug afgennemprøvede løsninger.

I alle IT-projekter tages der arkitekturbeslutninger i en elleranden form – bevidst eller ubevidst om forskellige hensyn,perspektiver og mål. Hvidbogens anbefalinger vil ændrerollefordelingen mellem de offentlige myndigheder,

22

leverandører og rådgivere. Økonomisk set indebærer dette ikkeen øget udgift, men måske en marginal omfordeling af poster ide offentlige IT-budgetter. Til denne pointe knytter sigimidlertid en styringsmæssig udfordring: Det er ikke altid den,der skal tage de arkitektoniske hensyn og investeringer, derhøster gevinsten.

Det er ligeledes vigtigt at gøre sig klart, at det kan kostevæsentlige investeringer at implementere strategiskearkitekturvalg med henblik på interoperabilitet. Det gælderbåde i forbindelse med nyinvesteringer og ændringer afeksisterende systemer. Omvendt kan arkitekturvalg, der tagerkortsigtede og snævre hensyn, vise sig at blive en dyrinvestering på sigt.

Arkitekturvalg, der understøtter interoperabilitet, kan være enforudsætning for, at et forvaltningsprojekt overhovedet kanrealiseres. Derfor skal investeringer vurderes i lyset af konkretebusiness cases, der kan begrunde at en sammenhængende IT-arkitektur er rentabel på lidt længere sigt. IT-arkitekturarbejdetvil primært finde sin relevans i tværgående projekter, herunderdigitalisering af servicefællesskaber, hvor der er et stortpotentiale for serviceforbedring og genanvendelse af data. Hvisman medregner, at struktur og opgavefordeling i det offentligekan ændre sig i fremtiden, bliver fordelene ved en fleksibelarkitektur af endnu større betydning.

23

3 Hvidbogens formål og baggrund

Målet med at arbejde med IT-arkitektur i det offentlige er atsikre det teknologiske fundament for udviklingen af digitalforvaltning, som omfatter hele den offentlige sektor og harvidtgående betydning for hele samfundet, inklusive borgere ogerhvervsliv.

3.1. Visionen om digital forvaltningHvidbogen tager udgangspunkt i de fire pejlemærker for dendigitale forvaltning, som er formuleret af bestyrelsen forProjekt Digital Forvaltning:

1. Den digitale forvaltning skal ruste borgere og virksomhedertil netværkssamfundet.

2. Den offentlige sektor skal arbejde og kommunikere digitalt.3. Den offentlige sektors ydelser skal leveres

sammenhængende og med borgere og virksomheder icentrum.

4. Opgaverne i den offentlige sektor skal udføres, hvor dehåndteres bedst.

Disse pejlemærker kan oversættes til processer, som vil forløbeover flere år og med forskelligt indhold og udviklingslogik.Nedenstående figur er et forsøg på at illustrere sammenhængenmellem pejlemærkerne og modningen af digital forvaltning.

24

Figur 2 - Pejlemærker og modenhed

Mod

enhe

dM

oden

hed

TidTid

Ruste borgere og virksomheder til netværkssamfundet

Off. Sektor kommunikerer digitalt

Ud fra de fire pejlemærker (primært pejlemærke 2-4) er deropstillet en række mål, som IT-arkitekturen skal understøtte. IT-arkitekturen skal:a. Give bedre offentlig service gennem bedre kvalitet i IT

understøttelsen.b. Støtte udviklingen af innovative tværgående

forvaltningsprocesser gennem større sammenhæng iinformationerne.

c. Opnå en mere effektiv forvaltning gennem højereeffektivitet i IT anvendelsen.

d. Give mulighed for hurtig støtte af nye eller ændredeforvaltningsprocesser eller organisatoriske forandringergennem adgang til gennemprøvede infrastrukturløsninger.

e. Give lettere adgang til offentlige informationer gennemåbne grænseflader overfor borgere, virksomheder ogmyndigheder.

f. Give en tilstrækkelig beskyttelse af offentlige informationergennem sikre løsninger for behandling og udveksling afdata.

g. Skabe flere succesfulde IT-løsninger gennem størreforudsigelighed af resultaterne af IT investeringer.

25

h. Give et solidt grundlag for den offentlige administrationgennem stabile IT systemer med tilstrækkelig kapacitet.

Nedenstående illustration giver et eksempel på et af de mestradikale aspekter ved det nye paradigme, som digitalforvaltning er udtryk for. I figuren sker der et skift:• Fra det traditionelle scenario, hvor borgere og

virksomheder må rende fra Herodes til Pilatus og selvkoordinere deres problemløsning – ofte uden overblik ogegen motivation.

• Til det nye scenario, hvor borgeren/virksomheden sættes icentrum, ved at myndigheder og andre aktører, der errelevante i forhold til at løse den samlede opgave,koordinerer såvel brugergrænsefladen som debagvedliggende systemer og processer.

Figur 3 - Fra traditionel til digital forvaltningTraditionel ForvaltningVirksomheden kommunikerermed flere myndigheder

Digital ForvaltningVirksomheden i centrum

Virksomhed

Organisation 1

Organisation 1

Myndighed A

Myndighed A

Myndighed AMyndighed B

Myndighed AMyndighed B

Myndighed AMyndighed D

Myndighed AMyndighed D

Myndighed AMyndighed E

Myndighed AMyndighed E

Myndighed AMyndighed C

Myndighed AMyndighed C

Organisation 2

Organisation 2

Virksomhed

Hvis det nye scenario skal realiseres – og hvis visioner og målfor digital forvaltning som beskrevet ovenfor – skal nås, kræverdet at visse spilleregler overholdes. I Hvidbogen præsenteres etbud på nogle centrale, overordnede principper.

26

3.2. Fra Grønbog til Hvidbog til ….Den 30. september 2002 udgav Ministeriet for Videnskab,Teknologi og Udvikling en Grønbog om IT-arkitektur.Grønbogen havde til formål at sætte offentlig IT-arkitektur pådagsordenen og at starte en debat med udgangspunkt i trehovedspørgsmål:• Skal vi have en fælles ramme for IT-arkitektur?• Hvordan skal den se ud?• Hvordan sikrer vi, at den rent faktisk bliver brugt?

Som opfølgning på Grønbogen har Det KoordinerendeInformationsudvalg i regi af Projekt Digital Forvaltning nedsaten arbejdsgruppe med repræsentanter fra stat, amter ogkommuner, som har fået i opdrag at besvare disse spørgsmål iform af nærværende hvidbog. Arbejdsgruppens kommissoriumog sammensætning fremgår af bilag A.Såvel Grønbogen som udviklingen af Hvidbogen har væretgenstand for en bred dialog med en lang række forskelligeaktører i den offentlige sektor – blandt andre bestyrelsen forProjekt Digital Forvaltning, det KoordinerendeInformationsudvalg (KIU), Statens IT-råd og Statens IT-Forum– og organisationer som Dansk IT og IT-brancheforeningen ogSSLUG. Der har ligeledes været dialog med en rækkeleverandører som KMD, CSC, IBM, SAP og Microsoft, samtmed rådgivere som PLS-Rambøll Management, DevoteamFischer & Lorenz, Gartner Group og META Group.

Generelt har dialogparterne understøttet intentionerne iGrønbogen og understreget den strategiske betydning af IT-arkitektur og fælles, åbne standarder. På det overordnedestrategiske niveau er der stor enighed omarkitekturprogrammets betydning.Dialogen viser dog også, at når man kommer nærmere ind ispørgsmålene kan der – ganske forventeligt – være behov for atafveje forskellige interesser. Nogle myndigheder har foreksempel særlige behov i relation til sikkerhed oginteroperabilitet på grund af opgavernes særlige krav tilfortrolighed, eller særligt store spænd i den teknologiske

27

modenhed hos de aktører, som man kommunikerer med. I denprivate sektor er det naturligt at forsvare eller fremme egneinteresser og forretningsstrategier. For eksempel vilapplikationsudviklere fokusere på interoperabilitet mellem egneapplikationer, mens systemhuse vil fokusere på interoperabilitetpå informations- og serviceniveau. Dette konkretiseres foreksempel i forskellige vurderinger af betydningen af åbenhedeller hvorvidt det er rentabelt at bygge »skaller« omkringdiverse legacy-systemer.

Hvidbogen søger ikke at tage stilling i alle de mangespørgsmål, men derimod at tage højde for sådanne naturlige oglegitime spænd i behov og interesser gennem de generelleprincipper for styring og udvikling af IT-arkitekturen.Hvidbogsarbejdet har ikke haft til formål at afklare alle demange ofte meget specifikke problemstillinger, somhøringsprocessen har bragt frem, men i højere grad at foreslåen ramme, der kan håndtere disse problemstillinger i den videreproces. IT-arkitektur handler om at tage valg, men somrammeværk søger Hvidbogen samtidig af sikre et bredtfundament i form af bred opbakning og konsensus.

Processen har givet vigtige bidrag til arbejdet og har haft storbetydning både i forhold til at tage temperaturen og i forhold tilat give inspiration både hvad angår principper og anbefalingeraf konkrete initiativer.

I Hvidbogen præsenteres ikke alle løsningerne, da disse skalvokse frem i et bredt samarbejde med hele forvaltningen ogmarkedet. Hvidbogen skal skabe et grundlag og en ramme forde kommende års arbejde med at skabe en optimeret ogsammenhængende IT-arkitektur i det offentlige.

IT-arkitektur er både en proces, der skal indføres og et resultat,der skal implementeres. Hvidbogen er et bidrag til processen ogen del af resultatet i og med, at den kommer med en rækkeanbefalinger. Anbefalingerne skal bidrage til et

28

beslutningsgrundlag for den videre proces mod udviklingen afen fælles offentlig IT-arkitektur.

Implementeringen som igen er en del af processen mod dendigitale forvaltning, omfatter udviklingen af fælles, konkretearkitekturmodeller og fælles standarder som kan anvendes iforbindelse med indkøb og udvikling af offentlige IT-løsningermed videre.

Arkitekturarbejdet bør foregå på flere niveauer: På nationaltplan bør tages overordnede beslutninger, der sikrerinteroperabilitet (at IT-systemer kan »tale sammen«) og andrefælleshensyn, og i de enkelte projekter optimeres arkitekturen iforhold til den enkelte opgave og i forhold til den enkelteorganisation. Det fælles arkitekturarbejdes resultater omfatteretablering af rammer for arbejdet, altså om at designe selvearkitekturprocessen.

Desuden bør arkitekturarbejdet resultere i etableringen affællesoffentlige tjenester og værktøjer, implementeret somfælles systemer. Det kan for eksempel væreressourcestyringssystemer, brugeridentifikation ogadgangskontrol.

3.3. Danmark i internationalt perspektivUndersøgelsen Realizing the Vision udført af Accenture i 2002viste, at de førende lande med hensyn til digital forvaltning erCanada, USA og Singapore. I den næste gruppe finder man 10lande, herunder Australien, England, Danmark, Finland, Norgeog Tyskland. De førende lande er også de lande som mestsystematisk har taget initiativer til at arbejde med den offentligeIT-arkitektur.

Danmark kan lære meget af andre lande, ligesom vi oplever, atman i mange andre lande i stigende grad fatter interesse for detarbejde, der pågår i Danmark. På flere områder er Danmarkimidlertid så langt fremme, at der ikke er mange erfaringer atlæne sig op ad. Når det drejer sig om datastandardisering og IT-

29

arkitektur er der i realiteten få lande, der har gennemførttilsvarende processer – ikke mindst med et omfang og enkompleksitet, der svarer til det danske ambitionsniveau, deromfatter ikke blot for eksempel staten/ministerierne, men iprincippet hele den offentlige sektor.

Mange lande har i dag iværksat store initiativer inden for digitalforvaltning. Men initiativernes art og omfang er forskellige, ogderes fokus varierer betydeligt. I lande, hvor den elektroniskeinfrastruktur endnu ikke er bredt udbygget, er det naturligt atfokusere indsatsen på opbygningen af en platform for dendigitale forvaltning i form af borgeradgang til offentligesystemer og elektroniske netværk mellem forskelligeforvaltningsenheder.

I lande med en mere udbygget infrastruktur er initiativernetypisk rettet mod at øge synligheden af offentlige informationog tilbyde elektronisk adgang til velkendte offentligeservicetilbud, som for eksempel bibliotek og folkeregister.Disse tilbud har dog ofte en begrænset funktionalitet, da denødvendige sikkerhedsmekanismer, eller den nødvendigesammenhæng mellem forvaltningerne ikke er til stede.

De elektroniske løsninger, der kan erstatte en samletarbejdsgang, som for eksempel indgivelse af en selvangivelse,er de som giver størst nytteværdi. Dette kræver imidlertid ikkeblot en sikker forbindelse til borgeren, men også en tætintegration af de bagvedliggende systemer og en tilpasning afarbejdsgangene i den offentlige forvaltning. De mestfremtrædende eksempler på digital forvaltning er karakteriseretaf følgende fælles træk:

• Kombination af politisk lederskab og klare mål i arbejdetmed digital forvaltning.

• Design af grænseflader og services med udgangspunkt iborgernes behov og ønsker.

• Etablering af portaler med tværgående services i stedet forforvaltningsspecifikke websites.

30

• Tilbud om komplekse services (transaktioner) og ikke kuninformation.

• Borgernes selvbetjening er reel i den forstand at de udfører(dele af) forvaltningens sagshåndtering.

Alle disse egenskaber er nært forbundet med eksistensen af enoverordnet ramme for IT-arkitekturen der sikrer, at de politiskeog administrative visioner omsættes i løsninger, som opnår enbred accept hos borgerne og giver administrative fordele iforvaltningerne.

Lande som USA, Canada, Tyskland, England og Sverige harvalgt forskellige tilgange til etablering af digital forvaltning:• Canada er nok verdens mest avancerede land med hensyn

til implementering af en digital forvaltning – både storbredde i løsninger, høj kompleksitet og stor accept hosbrugerne. Grundlaget er en fælles arkitektur (tekniskarkitektur, informationsarkitektur og forretningsarkitektur)og stærk ledelse, forankret i regeringen med et FederatedArchitecture Program (2000- ) og et centralt budget.

• USA har opnået relativt stor dækning og volumen, men lavkompleksitet og integration. Arbejdet med FederalEnterprise Architecture (FEA) påbegyndtes ved lov i 1996og er blevet opprioriteret i de sidste par år. Lovenforeskriver, at hver myndighed råder over enarkitekturansvarlig. Et antal serviceområder er udvalgtesom særlige indsatsområder, der »arkitektes« under stram,central styring.

• Tyskland har i de sidste par år satset meget på digitalforvaltning. SAGA er et arkitekturrammeværk, derindeholder en fælles standard-liste for IT-arkitekter, somklart udmelder tekniske og softwarepolitiske valg, tagetcentralt. Rammeværket indeholder ingen egentligearkitekturbeskrivelser, men skal ses som et regelsæt for dekonkrete projekter. Overholdelsen af SAGA-standarderne eren formel del af projekternes godkendelse.

• England har under ledelse af Office of the e-Envoyetableret et ambitiøst program, UK Online, med forankring

31

på højeste niveau i regeringen. Government Gateway er encentralt finansieret infrastrukturløsning, der sammenkoblereksisterende systemer med forskellige datastrukturer.Dokumentet e-GIF (eGovernment InteroperabilityFramework) fastlægger blandt andet en række standarderfor tekniske dataudvekslingsformater og protokoller. Vedoverholdelse af de tekniske standarder kan den enkeltemyndighed udnytte de stordriftsfordele, der opstår viaudbudet af centrale løsninger og principper.

• Sverige har en meget decentral beslutningsproces og harindtil for nylig været et eksempel på at lad 1000 blomsterblomstre hjulpet på vej med en central facilitator kan føretil en dynamisk digital forvaltning med løst koblede IT-systemer. Med infrastrukturløsningen SHS har man enfælles transport-service til udveksling af data, udviklet til atsammenbinde forvaltninger. Den svenske regeringnedsætter i år en delegation som skal styre finansiering påtværs af myndighedsgrænser, samt en kooperativ instans forfælles arkitekturbeslutninger.

Danmark kan og bør lære af følgende erfaringer fra lande, somhar gennemført tilsvarende processer i væsentligt omfang:• Forankring på regeringsniveau er nødvendigt.• En tværministeriel organisation/governance er nødvendig.• Standardisering af datastruktur og funktionelle interfaces

bør indgå.• Valg af tekniske standarder bør indgå.• Fælles infrastrukturløsninger understøtter sammenhængen.• Forankring i form af certificering og praksisfællesskaber

bør indgå.

Danmark indgår i en lang række internationale samarbejder,blandt andet via EU-programmer, og vil i den kommende tidintensivere samarbejdet med henblik på netop ovenståendeområder.

32

3.4. Arkitekturarbejdets ledetrådeHvidbogen har på baggrund af grønbogshøringen og envurdering af udenlandske erfaringer opstillet overordnedeledetråde og principper for arkitekturarbejdet:1. Den serviceorienterede arkitektur bør være paradigme for

offentlige IT-investeringer, der skal bidrage tilsammenhængende digital forvaltning.

2. Perspektivet er, at alle myndigheder og institutioner over tidbliver i stand til at deltage aktivt som aktører i denserviceorienterede arkitektur.

3. Den nationale IT-arkitektur bør være en lavestefællesnævner, som giver plads til at bygge ovenpå (en fællesminimalarkitektur eller dogmeregler)

4. En given IT-arkitektur skal afspejle forretningens vision ogsamtidig nogle nødvendige valg. Der skal være bredopbakning bag sådanne valg – og helst konsensus.

5. Den nationale IT-arkitektur bør overholdes, hvor der erreelle forvaltningsmæssige/forretningsmæssige behov ogmed udgangspunkt i forretnings-analyser, der viser, at detkan betale sig.

6. Det er ikke hensigten, at alle gamle systemer skal skrottes,eller at alle nu skal til at benytte samme platform. Menomvendt er der heller ingen systemer, der på forhånd erfredet.

7. Arkitekturarbejdet bør skride pragmatisk og iterativt frem.Der skal både tages beslutninger, der giver kortsigtedegevinster og beslutninger, der sikrer den langsigtede strategi.

8. IT-arkitektur bør respektere nærhedsprincippet, det vil sige,at beslutninger skal træffes på lavest mulige politiske/administrative niveau.

9. Arkitekturprogrammet skal koordineres med tilsvarendearbejde på internationalt plan, og Danmark bør forholde sigproaktivt til det internationale standardiseringsarbejde.

10. IT-arkitekturarbejdet omfatter blandt andet en rækkeanbefalinger og krav vedrørende standarder som publicerespå www.oio.dk.

33

4 Den digitale byplanlægning

I dette kapitel introduceres Hvidbogens model forarkitekturarbejdet. Der tages et metaforisk afsæt iplanlægningen af en bystruktur med huse, veje og ledninger,for at illustrere hvorledes arkitekten bidrager til atsystematisere og organisere. Arkitekturmodellens kernebegreber to forløb: Cykliske, iterative; to forløb, der gensidigtpåvirker og beriger hinanden. Delelementerne i de to forløbforklares og konkretiseres i forhold til de aktuelle mulighederog vilkår i Danmark.

Hvidbogen lover ikke nemme løsninger, men peger på deafgørende mekanismer af både organisatorisk, procesmæssig ogteknologisk natur, der må tages i ed, styres og evalueres for atkunne realisere den særdeles reelle gevinst ved planlagte,styrede, IT-arkitekturbevidste udviklingsprogrammer oginvesteringer.

Hvidbogen går ikke ud på ensretning, monopolisering ellerbureaukratisering af beslutningsprocesserne. De offentligeenheder er langt hen ad vejen selvstyrende, har deres egenkulturelle og lovgivningsmæssige kontekst. Derfor lægges dervægt på, hvordan generelle arkitekturprincipper, forankret iønsket om effektivitet og fællesoffentligt samspil, kanudmøntes lokalt til fællesskabets bedste uden at sætte det lokaleselvstyre over styr.

4.1. Byplan og IT-arkitekturUdviklingen af offentlige IT-systemer er et forløb med mangelighedspunkter med byudvikling. I vore byer er der utalligeprojekter i gang og det er svært at overskue alle detaljer. Derforer der brug for nogle overordnede planlægningsrammer, somsikrer en ordnet udbygning og systemer med bedre mulighedfor sammenhæng.

IT-arkitekturarbejdet kan sammenlignes med byplanlægning,der planlægger fælles ressourcer og lægger regler foranvendelse af disse, for eksempel fælles sikkerhedsløsninger.IT-arkitektur kan – ligesom anden byplanlægning, der spænder

34

fra overordnet national/regional planlægning til planlægning foret lokalområde – udvikles på flere niveauer:• Nationalt.• Sektor/servicefællesskab/indsatsområde.• Enkelt organisation/myndighed.

En byplan sætter rammer for byens udvikling – udpegning aferhvervs- og boligområder, krav til vand-, varme og el-forsyning, planlægning af trafikbelastning. En byplan er ensocial overenskomst, som muliggør en fornuftig udvikling afbyen gennem de lokale projekter, som byens indbyggere ogvirksomheder gennemfører.

Uden en byplan er risikoen for kaos overhængende – byenhænger ikke sammen, og investeringer i trafik og forsyning eruden indre sammenhæng. Byplanen er etmyndighedsinstrument, som sætter grænser for, hvad der mågøres, og som opstiller mål for, hvor udviklingen skal gå hen.Alt sammen under skyldig hensynstagen til alle de interesser,der skal afspejles i de overordnede beslutninger. Det eruundgåeligt, at enkelte borgere eller virksomheder føler sigbegrænset i deres private projekter af byplanen eller føler atderes projekter bliver unødigt kostbare pga. byplanen. Derforbygger byplanlægning på en politisk proces.

Byer har forskellige forudsætninger med hensyn til foreksempel geografi, demografi, historie, erhvervs- ogkompetencestruktur. Derfor har byerne forskellige byplaner, derdog for det utrænede øje godt kan ligne hinanden meget, mensom i realiteten handler om vidt forskellige »virkeligheder« oger opstået i vidt forskellige sammenhænge. Byplanlæggere ogarkitekter har naturligvis også en fælles arv gennem uddannelseog faglige fællesskaber, men det, som kendetegner, en godplanlægger og arkitekt er først og fremmest derespraksiskendskab og erfaring.Byplanarbejdet omfatter først etablering af regler for denenkelte ejendoms placering og udformning, som for eksempel

35

• Standardisering – dimensionering af rør, strømstyrke,vejbredde.

• Certificering – autorisation af planlæggere og installatører.• Styring – reglement og anmeldelser/godkendelser/

tilladelser.

Desuden omfatter byplanlægning principper for de fællesservices, som en ejendom kan eller skal tilsluttes:

• Forsyning med vand, elektricitet, varme med mere.• Spildevands- og renovationssystemer.• Telefon, kabel-tv, Internet med mere.

Etablering af services er en fælles investering, og brugen afdisse reguleres med henblik på at opnå en acceptabelrentabilitet af investeringen, samtidig med at den kan tilbydestil en attraktiv pris for den enkelte ejendom.

I IT-verdenen er der på samme måde behov for både reguleringaf det enkelte systems opbygning og etablering af fællesservices på områder hvor det er hensigtsmæssigt at løseopgaverne i fællesskab. For begge disse tiltag er enstandardisering af tilslutningspunkterne (i form af veldefineredegrænsesnit) en forudsætning for at opnå sammenhæng mellemIT-systemerne.

Historisk har der i Danmark været en tendens til atinvesteringer i infrastrukturen har været offentlige og underoffentlig kontrol. I de senere år har man dog i stigende gradladet markedet bære investeringerne og ladet det offentligefokusere på den nødvendige regulering for at sikre stabilforsyning og rimelige markedsvilkår.

Med i billedet skal tages det forhold, at byplanlægning er enproces i flere tempi, der kan strække sig over flere årtier (foreksempel Ørestad) til få uger (simple ombygninger m.v.) og harvarierende detaljeringsgrader. Traditionelt set er der tale om en

36

arbejdsdeling mellem byplanarkitekten, sektorplanlægningenog den tekniske forvaltning.

4.2. Hvordan skal vi arbejde med IT-arkitektur?På IT-området er der ligesom i byplanlægning tale omprocesser i flere tempi og om forskellige niveauer iplanlægnings- og arkitekturarbejdet. Når vi i Hvidbogen harvalgt at bruge begrebet IT-arkitektur, er det et samlingsbegrebfor flere forskellige niveauer i arkitekturens brede fagområde:

Både strategiprocessen og implementeringsprocessen ercykliske forløb, som systematisk bringer IT anvendelsen pålinie med de forretningsmæssige mål.

Arkitekturmodellen bygger på internationalt anerkendteprincipper for Enterprise architecture, og modellen udtrykkersom sådan de processer det offentlige må igennem undertransformationen til digital forvaltning.

Figur 4 - Arkitekturprocesser

Visionerog

pejle-mærker

Forretnings-arkitektur

Informations-arkitektur

Tekniskarkitektur

Konceptuellearkitekturprincipper

Dokumenter eksisterende situation

Prioritering ogplanlægning

Gapanalyse

Tekniske og forretningsmæssige trends

Implementeringsprojekter

Arkitekturprocesserne favner bredere end blot det IT-fagligeområde, idet det er en forudsætning for etablering af en

37

passende teknisk arkitektur, at visioner og mål på detforretningsmæssige område er klart defineret, så de kananvendes som planlægningsgrundlag for IT-udviklingen.Arkitekturprocessen er således baseret på en frugtbar dialogmellem forretning og IT.

I Danmark har det offentlige forberedt sig ved, på overordnetnationalt niveau, at lade det tværoffentlige Projekt DigitalForvaltning stå for opstillingen af visioner og pejlemærker.Herigennem arbejdes med udvikling af nye modeller for atudbyde den offentlige service mere brugerrettet og mereeffektivt, end det er tilfældet i dag. Den Digitale Taskforce, somer sekretariat for bestyrelsen for Projekt Digital Forvaltning,støtter de mange myndigheder i den forretningsrettede del afarbejdet, mens Ministeriet for Videnskab, Teknologi ogUdvikling står for de tekniske perspektiver, som opstilling afinformations- og tekniske arkitekturer.

Arkitekturen bliver til i en kompleks proces, der på ét niveaugår fra vision til implementering, drift og evaluering. Processener langt fra lineær, ligesom det er en misforståelse at seprocessen som en, der går fra punkt A til punkt B. IT-arkitekturer en kontinuerlig proces, der har til formål at sikre en løbendeforbedring af IT-anvendelsens værdi.

Arkitekturprocessen indgår i et samspil med enimplementeringsproces. De to processer er sammenkoblede ogskal køre i takt, men med forskellige hastigheder.Arkitekturprocessen er den konceptuelle, strategiske oglangsigtede proces, mens implementeringsprocessen erløsningsorienteret, praktisk og har et kortere sigte.Arkitekturprocessen udstikker målene forimplementeringsprocessen, men den modsatte kobling er ogsåvigtig: De systematisk opsamlede erfaringer fraimplementeringen bør også indgå i den overordnedeplanlægning. Den samlede proces kan beskrives således:

38

Arkitekturprocessen tager sit udgangspunkt i visionen og deeksterne trends og munder ud i konceptuellearkitekturprincipper, som relaterer sig til IT. Alle faser iarkitekturprocessen gennemløbes med baggrund i en analyse aftrends og krav. Betragt konkurrenter, kunder og leverandører oglyt til strategiske rådgivere. Forløbet har følgende faser:• Visioner og Pejlemærker beskriver de strategiske

forretningsmål, pejlemærker og visioner, specielt de somrelaterer sig til IT. Dialog med den øversteforretningsledelse og det politiske niveau er nødvendig.

• Forretningsarkitektur beskriver de arbejdsprocesser somIT systemet skal understøtte, både hvad angår funktionalitetog driftsmæssige egenskaber. Denne beskrivelse erresultatet af en analyse og efterfølgende optimering af deeksisterende arbejdsgange.

• Informationsarkitektur beskriver forretningsstrategienskrav til informationernes organisering, både på detoverordnede niveau, og som specifikke databeskrivelser,udformet under anvendelse af et fælles begrebsapparat.

• Teknisk arkitektur. Opdelt efter en fælles systematikbeskrives kravene til de tekniske løsninger. Den tekniskearkitektur beskriver både systemets overordnede opdeling imoduler, og organiseringen af funktionerne i det enkeltemodul. En nøglefaktor er at afspejle de ønskede – ellerpåtvungne – forretningsmæssige ændringer, som IT skalunderstøtte.

• Konceptuelle arkitekturprincipper er et sæt regler forvalget af IT-løsninger, som kan sikre, at disse opfylder deidentificerede krav til informationsstrukturen og dentekniske arkitektur.

Samtidig med den strategiske arkitekturproces kører denløsningsorienterede og praktiske implementeringsproces, derindeholder følgende faser:• Dokumentér den eksisterende situation. Beskrivelsen

skal tjene som udgangspunkt for den fremadrettedeplanlægning og vedligeholdes løbende, som en del afdriftsopgaverne. Dokumentationen er ligeledes et vigtigt

39

grundlag for opstilling og revision af visionen ogpejlemærkerne.

• Gap-analysen beskriver hvordan de eksisterende løsninger,metoder og organisation passer med de konceptuellearkitekturprincipper.

• Prioritering og planlægning. I denne fase beskrives dentekniske migrering, der skal til for at bringe deneksisterende løsning de ønskede skridt nærmere tilarkitekturprincipperne og de forretningsmæssige mål.Denne planlægning prioriterer de ændringer som har størstforretningsmæssig værdi og identificerer dereskonsekvenser.

• Implementeringsprojekter. Gennemfør implementeringeni form af et antal projekter, der er indbyrdes koordineredeog rettet mod samme overordnede mål. Projekterne styressom en portefølje, med aktiv risikostyring ogudbytteoptimering.

IT-arkitektur udstikker retningslinjer for den overordnedeorganisering af data og valg af funktionelle komponenter for ételler flere IT-systemer, med henblik på at:• Optimere systemernes målopfyldelse i forhold til de

forretningsmæssige krav.• Optimere systemernes interoperabilitet med andre relevante

systemer.• Optimere omkostningseffektiviteten af systemerne gennem

hele deres livscyklus.

IT-investeringer skal naturligvis give værdi. En gennemtænktIT-arkitektur kan øge værdien af IT-investeringerne ved atskabe en ramme, som samordner IT-investeringerne. IT-arkitektur er en investering i en proces og en række værktøjer,som blandt andet kan tage form af et sæt overordnededesignprincipper, en tjekliste eller et standardbilag til enkravspecifikation. En offentlig IT-arkitekturramme skalmedvirke til at undgå at IT-projekter baseres på proprietære oglukkede løsninger og fremme at de overholder fælles standarderog anvender genbrugsfilosofien.

40

Baggrunden for det nye fokus for IT-arkitektur er de øgede kravom sammenhæng og effektivitet i forvaltningen. Dette er de nyemuligheder, som teknologien har skabt og de nye mål omdigital forvaltning, som er sat politisk. Hvis disse mulighederog mål skal realiseres kræver det, at de mange forskelligeaktører i en vis udstrækning harmoniserer deres IT-systemer,således at de overholder visse fælles standarder og regler,herunder standarder for interoperabilitet (for eksempel XML)og sikkerhed (for eksempel OCES). Dette kan understøttes af,at visse tjenester realiseres i fælles regi, det gælder foreksempel funktioner til udveksling af data og løsninger tilhåndtering af digital signatur.

Kernen i det fælles offentlige arkitekturarbejde er valget af denserviceorienterede arkitekturmodel, som definererinteroperabiliteten mellem IT-systemerne som services, dertilbydes af een systemkomponent og benyttes af en anden. Vedat vælge dette koncept sikrer vi de bedste muligheder forsammenhæng imellem IT-systemerne ved brugen afharmoniserede servicedefinitioner.

Den serviceorienterede arkitekturmodel er en videreførelse afden klassiske lagdelte arkitekturmodel, som i Grønbogenillustreredes med følgende figur:

41

Figur 5 - Trelags modellen

Bruger-interface laget

Forretningslogik laget

Opbevaringslaget

Kilde: Realising eGovernment, CSC, 2002.

Denne klassiske 3-lags arkitekturmodel er en logisk (det vilsige konceptuel) model, som repræsenterer en mere komplekssammenhæng (med flere lag). For at beskrivesystemarkitekturens designkrav og implementeringsstrategi harvi brug for en mere detaljeret model.

Figur 6 - Fra trelagsmodel til infrastrukturmønstermodel

Infrastruktur-mønstermodellen

3-lagsmodellen

Bruger-interfacelaget

Forretningslogiklaget

Opbevarings-laget

Netværk

Datalager

Server Hardware/OS

Database Server

Integrations Server

Applikations Server

Præsentation

API / Service

42

Når interoperabiliteten mellem forskellige systemer skal sikres,er det vigtigt at sammenkoblingen foregår på en måde, hvorkonceptuelt ækvivalente komponenter forbindes. Derfor er detnødvendigt at benytte en mere detaljeret opdeling af de tre lag,og figuren illustrerer derfor hvorledes de 3 lag er underopdelt.Der er tale om en opdelt (modulariseret) model, der givermulighed for at beskrive sammenhængen mere normativt.

Ofte kaldes denne mere normative model for enserviceorienteret arkitektur, som adskiller sig fra tidligerearkitekturmodeller (som mainframe og client/server). Denfølgende tabel giver eksempler på de forskelligearkitekturmodellers karakteristika:

Mainframe- Client/server- Serviceorienteretarkitektur arkitektur arkitektur

Platforme Monolitisk Homogent Forskelligartet ogog centraliseret og kontrolleret uforudsigelig

Netværk Begrænset og lukket LANs udbredte Internet,men isolerede allesteds-

nærværendeog sammenkoblet

Dataformater Uigennemsigtig Binær og proprietær Semantisk og deltog utilgængelig

Teknologi- Operativsystem Database Grænsefladefokus

Brugere IT-operatører Sagsbehandlere Leverandører,ansatte,kunder/brugere

Forretnings- Digitalisering af data- Give dataene Fremmende forværdi centriske operationer til brugerne forretnings-

mæssig behæn-dighed, omstil-lingsevne ogsamvirke

Karakteristika ved systemarkitekturer (Kilde: The Stencil Group)

43

Den serviceorienterede arkitektur er en model forsystemelementer, der taler sammen, for eksempel via webservices. Web services er en specifik implementering af enserviceorienteret arkitektur. Modellen kan imidlertid medfordel ses som en model for offentlige e-services – det vil sigeservices til borgere, virksomheder og andre myndigheder såvelsom interne services.

Begrebet services kan i denne sammenhæng forstås på flereniveauer• Konceptuelt repræsenterer en service-orienteret arkitektur

en model, i hvilken løst koblede applikationer samarbejderved at stille services til rådighed for hinanden.

• Forretningsmæssigt er services udtryk for data- ogfunktionstjenester, som en part kan stille til rådighed forandre eventuelt på forretningsmæssige vilkår.

• Teknisk benytter serviceorienteret arkitektur en gruppe afstandarder under stadig udvikling, som definererprotokoller og skaber en løst koblet ramme forprogrammeret kommunikation mellem forskellige systemer.

• Konkret er webservices en betegnelse for en metode dermuliggør at en applikation kan kaldes af andreapplikationer ved at modtage og besvare data i etstandardiseret sprog (XML).

Den serviceorienterede arkitektur foreskriver ikke i sig selvnogle bestemte teknologistandarder, selvom mangeleverandører tilbyder et specifikt teknologisk fundament hertil.Valget af standarder udtrykkes i de konceptuellearkitekturprincipper, som sammenfatter arkitekturprocessensbeslutninger. Standardiseringen af servicegrænseflader er i fuldgang i adskillige internationale standardiseringsorganer (W3C,OASIS, WS-I med flere). Standardiseringsprocessen forventesat løbe over de næste år og bringe en konsolidering omkring etfælles sæt modne teknologiske standarder. Anvendelsen af dissestandarder i den offentlige IT-arkitektur vil være en centralopgave i arkitekturarbejdet i de kommende år.

44

Figur 7 - Værdiskabende IT-arkitektur

Konceptuellearkitekturprincipper

Dokumenter eksisterende situation

Prioritering ogplanlægning

Gapanalyse

Implementeringsprojekter

Visionerog

pejle-mærker

Forretnings-arkitektur

Informations-arkitektur

Tekniskarkitektur

Tekniske og forretningsmæssige trends

Arkitekturprocessens strategiske cyklus er i den ovenståendefigur illustreret inden for den øverste ramme.

IT-arkitekturens opgave er at organisere det overordnede designaf IT systemerne på en måde, så værdien af IT-investeringernebliver maksimeret, målt med forretningens definition afværdien. Det betyder, at arkitekturprocessen skal tageudgangspunkt i forvaltningens forretningsmæssige behov, somså skal omsættes til identificerede behov for IT-understøttelse,således at man kan optimere IT-anvendelsen herefter. Deteknologiske muligheder og IT-markedets konkrete produkterspiller i denne sammenhæng en vigtig, men sekundær rolle sominstrumenter til at realisere IT-understøttelsen på den mesthensigtsmæssige måde.

Når den offentlige forvaltnings udbytte af IT-understøttelse skaldefineres, må det frarådes at tage udgangspunkt i deeksisterende forvaltningsprocesser. En simpel IT-understøttelseaf eksisterende arbejdsgange vil ikke realisere alle de muligefordele, fordi de eksisterende processer er udviklet i en verdenmed begrænsninger, som IT kan fjerne. IT-understøttelsen giver

45

således nye muligheder for optimering af arbejdsprocesserne,så effektiviteten og kvaliteten kan hæves. Til gengæld vil det imange tilfælde være nødvendigt at processerne omlægges, forat investeringerne i IT-understøttelse bliver rentable.

Derfor kan det være relevant, at forvaltningens mål og visionersamtidig tages op til overvejelse på de berørte områder. Der kanvære mange grunde til, at eksempelvis grænser ogsamarbejdsrelationer til andre myndigheder og private kanændres og opblødes som følge af nye teknologiske mulighederog som følge af opgaveudviklingen.

Succesfulde IT-projekter er baserede på en dyb forståelse afforvaltningsprocesserne og af de muligheder, som IT giver forat optimere værdien i alle led. Der bør derfor gennemføresaktiviteter i form af procesanalyse og procesoptimeringsamtidig med arkitekturarbejdet og med samme overordnedeforankring i forvaltningens ledelse. Et centralt led i IT-arkitektur-processen er den dialog, hvor forvaltningsforståelseog teknologiforståelse mødes.

Værdiskabelsen er et centralt element i denne optimering, ogdet er derfor vigtigt at identificere, hvor og hvordan værdienskabes. I mange sammenhænge vil man kunne påpege internegevinster i form af øget hastighed, produktivitet og kvalitet isagsbehandlingen. Men i andre situationer, særligt vedetablering af samarbejde med eksterne parter og ved indførelseaf selvbetjening for borgere, vil betydelige gevinster falde udenfor den offentlige administration, for eksempel som sparet tidhos borgeren eller sparede omkostninger i virksomhederne. Nårværdien af IT understøttelsen skal opgøres, er det derfor vigtigtat anlægge et helhedssyn, som i rimeligt omfang medtager desekundære og eksterne fordele.

IT-arkitekturarbejdet kræver en løbende, kvalificeret dialogmed forvaltningens ledelse, som i denne sammenhæng harrollen som bygherre, og det er arkitektens opgave at formulerede IT strategiske beslutninger som forretningsmæssige valg,

46

hvor fordele og ulemper er tilstrækkeligt belyst til at udgøre etsikkert grundlag for beslutningen. For at skabe dette grundlag,kræves et indgående kendskab til IT-løsningernes komponenterog deres egenskaber i anvendelsessituationen, så der kanopstilles realistiske beregninger af konsekvenserne, både hvadangår omkostnings- og nytteværdivurderingen. IT-arkitekturarbejdet bør derfor som et af sine redskaber betjenesig af systematiskeBenchmarking modeller, baseret på erfaringer frasammenlignelige situationer og IT-løsninger.

I alle faser af arkitekturarbejdet vil beslutningerne kunneformuleres som del af en optimeringsproces. For eksempel vilinformationsarkitekturen skulle vælges efter, hvilken tilgang tilinformationerne der er brug for hos alle systemets brugere:Hvis der er behov for synkron tilgang til fælles data fra et antalgeografisk opdelte kontorer, kan det være optimalt atcentralisere data, hvorimod de tilfælde hvor informationerneprimært benyttes lokalt, vil tilsige en distribueretinformationsarkitektur. Disse overvejelser er naturligvispåvirket af de tilgængelige kommunikationsmuligheder(kvalitet og pris), holdt op mod eventuelle stordriftsfordele vedat behandle data centralt.

Når IT arkitekturen optimeres udfra værdibaserede mål, børkonsekvenserne gennem hele IT-løsningens livscyklusmedtages. I arkitekturarbejdet tages ofte beslutninger, der harlangt-rækkende konsekvenser, for eksempel ved valget afspecifikke grænsesnit eller datastrukturer. Det betyder, atefterfølgende beslutninger om modernisering eller integrationaf løsningen med andre systemer kan blive påvirket positivteller negativt af de tidligere valg på dette område.Arkitekturarbejdet bør derfor baseres på et antal overordnedeprincipper, som udtrykker det offentliges retningslinier foroptimering af IT arkitekturen og som fastholdes over enårrække. Både på lokalt niveau og for større dele af denoffentlige sektor skal disse principper sikre, at behovet for

47

integration kan tilgodeses, samtidig med at værdien af denenkelte IT-løsning optimeres.

IT-arkitektur har ikke blot stor betydning for etablering af nyeIT-løsninger. Også ved modernisering og udbygning afeksisterende løsninger er det vigtigt at vælge teknologier,grænsesnit og dataformater, som bidrager til at lette denfunktionelle integration af IT løsningerne i den offentligesektor. En koordineret planlægning af både de eksisterendeløsningers udvikling og nye systemers etablering, er nødvendigfor at der opnås sammenhæng på tværs af systemerne, med denstørst mulige omkostningseffektivitet gennem systemernessamlede livscyklus.

I denne sammenhæng er det vigtigt at sigte mod flerstrengedeløsninger, der kan opfylde forskellige organisationers behov,uden at tilsidesætte behovet for tværgående interoperabilitet.Det vil være hensigtsmæssigt at etablere et sæt overordnederetningslinier for vurdering af det offentliges behov forintegration mellem de overordnede IT strukturer og at beskriveværdien af denne integration. En sådan vurdering vil kunnebenyttes i strategiske valgsituationer, hvor den fremtidigeudvikling af forældede IT-løsninger skal defineres.

4.3. En arkitekturudvikling i flere hastighederPå vejen mod Digital Forvaltning vil vi ofte stå overfor valgetmellem taktiske og strategiske investeringer i IT løsningerne.Det taktiske valg kan for eksempel være at skabe ad hocforbindelser mellem eksisterende systemer, mens denstrategiske løsning vil være at omlægge systemerne til atbenytte en fælles service, som giver mulighed for en merevidtgående integration.

I den overordnede IT planlægning må det afspejles, at detaktiske og strategiske tiltag ikke er gensidigt udelukkende, menofte repræsenterer supplerende midler til at opnå detoverordnede mål. På hvert trin i udviklingen vil forskelligetiltag være hensigtsmæssige, og afvejningen heraf foretages

48

bedst ved at betragte løsningsalternativerne som investeringermed hver deres omkostnings- og udbytteprofil. På den måde erdet muligt at vurdere, hvornår initiativer med strategiskperspektiv (for eksempel funktionel sammenkobling afsystemer) bør have højere prioritet end initiativer, der giverkortfristede fordele (for eksempel ved dataudveksling mellemeksisterende systemer). I hvert enkelt tilfælde medtages ikkeblot de lokale konsekvenser, men også virkningerne påområder, som i fremtiden forventes berørt gennemdatafællesskab eller funktionel integration.

Den fælles ramme for IT arkitekturen skal hjælpe med atkoordinere alle tiltag, der bidrager til interoperabiliteten af deoffentlige IT systemer, uanset om de vedrører taktiske ellerstrategiske initiativer. Ved at opstille en fælles referencerammefor vurderingen af de enkelte integrationsinitiativers værdi, kanman sikre, at afvejningen mellem lokale og nationale hensyn,såvel som afvejningen mellem kortsigtede og langsigtedeinvesteringer overalt bliver udført på en optimal måde.

Både på det taktiske og det strategiske plan vil der være behovfor fælles initiativer, for at skabe sammenhæng og prisoptimaleIT-løsninger. En central opgave vil derfor være at identificerefunktioner, som med fordel kan løses i fælles regi og at designedisse løsninger, så de giver maksimal værdi for det enkelteprojekt, samtidig med at omkostningerne minimeres. Detgælder for eksempel fælles services, hvor en central funktionstilles til rådighed for en lang række offentlige IT systemer, istedet for at de lokale systemer løser den i eget regi. Eksemplerpå dette kunne være kontrol af en brugers identitet ellergennemførelse af en udbetaling til en borger.

På andre områder vil en fælles ramme for IT arkitektur kunnegive store fordele gennem harmonisering af den funktionalitet,som IT systemerne implementerer. Eksempler på dette kunnevære beregning af offentlige ydelser, eller udførelse afgenerelle funktioner i den offentlige sagsbehandling. Ved atgenbruge den IT-mæssige implementering af sådanne

49

funktioner kan udgiften til de lokale systemer reduceresbetydeligt, og den resulterende ensartethed afimplementeringerne vil lette en fremtidig integration.

De fælles initiativer bør altså ikke blot omfatte et fællesregelsæt for overordnede IT beslutninger, men også et forslagtil design og implementering af udvalgte services i fælles regi,som på samme tid kan sikre sammenhæng mellem systemerneog reducere omkostningerne i det enkelte projekt.

4.4. Økonomiske perspektiverErfaringerne fra organisationer, der har indført en fællesarkitekturproces viser, at en satsning på IT-arkitektur er ensærdeles god investering. Grundlæggende er der tale ombeslutninger, der altid er blevet truffet. Når de offentligeorganisationer stiller krav til arkitekturen, flyttesarkitekturbeslutningerne fra leverandøren til systemets ejer. Detbetyder, at disse beslutninger forankres i brugerorganisationenog tages med et større økonomisk rationale. Resultatet er enbetydelig nettogevinst, der optræder både i IT budgettet og iforretningsprocesserne.

Besparelser skal ses i relation til omkostningerne ved ikke atarbejde systematisk med arkitekturen er øgede omkostninger tilvedligeholdelse og tilpasninger. Gevinsten kan høstes somtotalbesparelser gennem hele systemets levetid. Det vil sige derationaler, der ligger i begreberne ROI, Return of Investment ogTCO, Total Cost of Ownership. Den økonomiske opgørelseomfatter alle indtægter og besparelser samt alle omkostningertil løsningens etablering og drift, herunder omkostninger til foreksempel videnopbygning og træning af IT-teknisk personaleog i brugerorganisationen.

Fordelene ved en hensigtsmæssig IT arkitektur rækkerimidlertid videre end til besparelser på IT-løsningerne.Arkitekturen er nemlig afgørende for den nytteværdi, somorganisationen får ved at anvende IT løsningen, for eksempel iform af højere produktivitet, kvalitet og brugertilfredshed.

50

Hertil kommer, at det bliver lettere at tilpasse til nye opgaver ogny opgavefordeling. Disse fordele er svært kvantificerbare udenobjektive målemetoder. Derfor bør arkitekturinitiativerbegrundes med en business case, og følges op med ensynliggørelse af resultaterne.

Det overordnede formål med at optimere IT arkitekturen er atreducere omkostningerne og forøge udbyttet af IT løsningerne.Men ofte falder fordelene et andet sted, end der hvorinvesteringen afholdes, og det kan give vanskeligheder iforbindelse med at retfærdiggøre investeringen. Desuden mådet tages i betragtning, at en væsentlig del af udbyttet af en godarkitektur først høstes i driftsfasen og derfor først vil give etpositivt bidrag til økonomien i årene efter at beslutningerne ertaget og investeringen er afholdt. Der er brug for et helhedssyn,når rentabiliteten vurderes:

• For det første kan der være brug for at betragte ITinvesteringer som en fælles investering for en gruppe afinstitutioner eller på tværs af flere sektorer. Det betyder, atder må indføres økonomiske mekanismer, som sikrer, atbåde investeringer og fordele bliver fordelt på enhensigtsmæssig måde. Et eksempel på en sådan mekanismekunne være fordelingsnøgler for investeringen.

• For det andet kan der være behov for at sammenkædeinvesteringerne i etableringsfasen med de løbende fordele,der høstes i løbet af IT-løsningens levetid, gennemreducerede omkostninger og forøget nytteværdi. Det rejserbehovet for en finansieringsmodel for IT-løsninger, derlægger op til at de arkitekturmæssige beslutningeroptimeres i forhold til løsningens totaløkonomi. Eteksempel på dette kunne være en central investering, derforrentes af løbende forbrugsafgifter.

• For det tredje kan der være behov for en afvejning afbehovet for specielle løsninger op imod muligheden for atbruge allerede udviklede løsninger, enten i form af koncept-genbrug eller i form af tilslutning til fælles løsninger.Selvom et givet IT behov tilsiger en simpel løsning, kan der

51

være fordele ved at benytte en fælles løsning, selvom den ermere kompliceret eller har højere serviceniveau, hvis denpå grund af stordriftsfordele er mere økonomisk attraktiv.

Sammenfattende bør der etableres passendestyringsmekanismer til at sikre at arkitekturmæssigebeslutninger tages med henblik på at optimere totaløkonomien iløsningerne for alle de berørte parter. Det kan for eksempelinvolvere ledelsesprincipper, incitamenter eller aftaler. Sominspiration til valget af disse styringsmekanismer kan nævnesfølgende økonomiske modeller:• Centrale investeringer i fælles infrastruktur, med fordeling

af omkostninger efter forbrugsnøgler eller ideelle andele.• Forbrugstaksering af services som stilles til rådighed for

andre organisationer, med udgangspunkt i kostægte priser.• Salg af licenser til leverandører, som driver fælles services

eller applikationer på kommercielle vilkår.• Tilskud til IT-projekter, der tilslutter sig fælles services eller

benytter fælles specifikationer af funktionalitet ellerdatastrukturer.

De økonomiske modeller skal fremme optimering af IT-investeringerne. De skal desuden også medvirke til en øgetudbredelse af viden, forståelse og accept af IT-arkitekturarbejdet og dets resultater. Fordelene vil være sparedeinvesteringer i det lokale projekt, en gevinst i hurtigereimplementeringstid og en fortjeneste ved brugen af fællesfaciliteter, fordi prisen for dette vil være billigere end at kørelokalt. På den måde øges brugerorganisationernes mulighed forat vælge og konstruere IT-løsninger, der har en højeremålopfyldelse og større effektivitet.

52

5 Principper

En god IT-arkitektur er kendetegnet ved, at arkitekten haropnået en god balance i forhold til mange og komplekse krav. Ikonkrete løsningssammenhænge er der typisk en lang rækkeløsningskrav om given funktionalitet, samt en rækkeoperationelle krav om for eksempel ydeevne og stabilitet.Arkitekturen (byplanen) skal sikre, at den konkrete løsning kanopfylde de lokale behov inden for rammerne af den fællesplanlægning.

Figur 8 - Principstyret IT-arkitektur

Visionerog

pejle-mærker

Forretnings-arkitektur

Informations-arkitektur

Tekniskarkitektur

Dokumenter eksisterende situation

Prioritering ogplanlægning

Gapanalyse

Tekniske og forretningsmæssige trends

Implementeringsprojekter

Konceptuellearkitekturprincipper

Grundkonceptet for godt IT-arkitekturarbejde er at det erprincipstyret. Det betyder, at først analyseresforretningskravene, og på baggrund heraf opstilles et sætkonceptuelle arkitekturprincipper, som benyttes vedorganiseringen og de tekniske valg. Arkitekturarbejdet skalsikre sammenhængen mellem kravene og principperne, såledesat forretningskravene vil være opfyldt af en løsning, derefterlever principperne, og at de gældende principper altid erbegrundet med forretningsmæssige krav.Arkitekturprincipperne opstilles i et hierarki med flere niveauer.Det øverste niveau omfatter fælles, overordnede principper,som blandt andet afspejler behovet for sammenhæng på tværs

53

af den offentlige sektor. Det næste niveau omfatter principper,som typisk har til formål at optimere IT-løsningerne inden foren enkelt sektor eller et indsatsområde. På det laveste niveaufinder vi principper, som er rettet mod et konkret system elleren portefølje af systemer i en enkelt institution. I dette afsnitgives et bud på de overordnede principper i dette hierarki. Detvidere arkitekturarbejde vil være rettet mod at videreudvikledisse overordnede principper til en fælles IT-arkitekturramme.

De overordnede arkitekturprincipper har til formål at sikreindfrielsen af visioner og mål i regeringensmoderniseringsprogram og Projekt Digital Forvaltning. Disse erbeskrevet i kapitel 2. En fælles offentlig ramme for IT-arkitektur skal først og fremmest indeholde følgende femprincipper:

• Interoperabilitet.• Sikkerhed.• Åbenhed.• Fleksibilitet.• Skalerbarhed.

Principperne er vigtige i forhold til at opnå ensammenhængende digital kommunikation indenfor detoffentlige med deraf følgende effektivitets- ogkvalitetsforbedring, hvor der samtidig optimeres i forhold tilden samfundsmæssige værdi af de offentlige serviceydelser.

I de følgende afsnit beskrives disse principper og under hvertprincip begrundes hvilken del af visionen (visionselementerneovenfor) de understøtter. I slutningen af dette kapitel beskrives,hvordan man kan arbejde med retningslinier.

5.1. InteroperabilitetInteroperabilitet er afgørende for at skabe en bedre og meresammenhængende service, der sætter brugeren i centrum.Interoperabilitet er også en forudsætning for at skabeinnovation, effektivitet og hurtig støtte af nye regler og rammer

54

for forvaltningen. Dette gælder for eksempel i forbindelse medorganisatoriske ændringer, hvor man har behov for at ændre påsamspillet mellem eksisterende IT-systemer eller ved at tilføjenye. Interoperabilitet har også betydning for sikkerhed ogbeskyttelse af offentlig information, i og med at det er enforudsætning for at etablere tværgående sikkerhedsløsninger.

Interoperabilitet, der kan forstås som det at etablere dennødvendige sammenhæng på den mest effektive måde, kansåledes ses som den vigtigste nøgle til digital forvaltning. Iarkitektursammenhæng handler interoperabilitet især om, at deter nødvendigt med fælles integrationsprincipper og standarderfor udvekslingen af informationer.

Hvidbogens anbefaling af en serviceorienteret arkitekturmodelfremhæver, at interoperabiliteten ikke blot er baseret på ataflæse data fra andre systemer, men at der skal etableres enfunktionel sammenhæng mellem systemerne, for eksempel vedat det ene system leverer en tjeneste til det andet. En sådansammenhæng kræver blandt andet enighed om dataindholdetsbetydning, og funktionel integration kræver desuden en fællesdefinition af den kontekst, informationerne udveksles i.Definitionen kan indeholde krav om for eksempeldatakonsistens eller adgangskontrol, og vil være afgørende forhvor tæt en kobling af systemerne der vælges.

Interoperabilitet kan være baseret på bilaterale aftaler, hvorspillereglerne for kommunikationen defineres for hvert nytsystem, der tilkobles. Denne model fungerer både i princippetog i praksis fint, hvor der kun er få og veldefinerede parter medveldefinerede og stabile behov for udveksling af data. Men hvisdette ikke er tilfældet kan det være en omkostningstung ogufleksibel metode til at skabe interoperabilitet. I situationer,hvor mange systemer skal kommunikere, er enflerlagsarkitektur med brug af fælles standarder langt atforetrække, fordi der så ikke skal bruges kræfter på at definereog implementere et stort antal grænseflader med samme formål.

55

Når information let skal kunne udveksles mellem myndigheder,er det nødvendigt at IT-systemerne taler samme sprog. Kernen iinteroperabilitet er fastlæggelsen af fælles datamodeller ogfælles protokoller for udveksling af data. Protokollerne skalbære datamodellerne via såkaldte metadata (det vil sigeinformation om data), som bruges til at beskrive og defineredata. Det betyder med andre ord, at de organisationer(myndigheder, institutioner og virksomheder), der skaludveksle med hinanden skal være enige om definitioner af data.

Ministeriet for Videnskab, Teknologi og Udvikling har etableretet nationalt, centralt bibliotek (repository) formetadataspecifikationer. Denne såkaldte infostrukturbase er etvæsentligt element i forbindelse med en fælles national IT-arkitektur, fordi det er her, at informationer om indholdet afoffentlige registre, ESDH systemer, content managementsystemer og andre IT-systemer skal lagres.

5.2. SikkerhedSikkerhed er afgørende for at beskytte de offentligeinformationer og en forudsætning for at alle aktører vil deltage– det gælder fra myndigheder over private virksomheder tilborgerne. Uden vished for at data behandles sikkert vil der ikkevære den fornødne tryghed hos hverken udbydere eller brugereaf digital forvaltning. Sikkerhed er derfor også en afgørendeforudsætning for digital forvaltning og et overordnet krav til IT-arkitekturen.

Arkitektens opgave er at organisere sikkerhedsfunktionerne påen sådan måde, at de forretningsmæssige (både forvaltningensog borgerens) krav til sikkerheden opfyldes i en grad der eracceptabel i den aktuelle anvendelsessituation. Desuden gælderdet, at løsningen skal kunne justeres til nye (skærpede) kravsom måtte blive aktuelle, uden at en stor del af de tidligereinvesteringer i sikkerhed bliver værdiløse.

Sikkerhedsarkitekturen tager sit udgangspunkt i deforretningsmæssige krav til arbejdsgangene, informationernes

56

følsomhed og en analyse af det aktuelle risikobillede.Sikkerhedsarkitekturen skal opfylde både de lovmæssige krav,borgerens rimelige forventning om en sikkerinformationsbehandling og myndighedernes behov for at ydeeffektiv sagsbehandling og god service. For at beskrive desamlede krav til sikkerheden, bør man gå ud fra en fællesdefinition af sikkerhedsbegreberne på det forretningsmæssigeniveau.

I mange situationer vil kravet om sikkerhed synes at væremodstridende i forhold til for eksempel interoperabilitet ogåbenhed. Her vil det være IT arkitektens opgave at strukturereinformationerne efter følsomhed og at graduere adgangen efterde enkelte parters behov. En grundlæggende beslutning kan foreksempel være, om særligt følsomme data skal lagres sammenmed øvrige data, eller om de skal placeres i adskilte IT-systemer. Sådanne afvejninger omkring sikkerheden har storekonsekvenser for de arkitekturmæssige valg, og det er derfor afstørste betydning, at de betragtes som overordnede principperfor arkitekturarbejdet. En senere udbygning afsikkerhedsfunktioner til eksisterende systemer vil være kostbareller umulig.

De konkrete sikkerhedsløsninger (adgangssystemer,certifikater, sikkerhedskopiering osv.) bør vælges, så deoverholder de overordnede krav om interoperabilitet m.v. Detbetyder, at de baseres på fælles standarder (evtentuelt somfælles løsninger) og en fælles forståelse (aftale) omtroværdighed, ægthed og administrative procedurer. På dettepunkt adskiller de sig ikke fra de øvrige arkitekturprincipper.

Sikkerhedaspekterne ses af mange som den væsentligste faktorfor udbredelsen af digital forvaltning, og bør derfor have højprioritet i det videre arbejde. Ministeriet for Videnskab,Teknologi og Udvikling har etableret et nyt råd for IT-sikkerhed, et kompetencemiljø omkring IT-sikkerhed og tagetkonkrete beslutninger omkring digital signatur.

57

5.3. ÅbenhedÅbenhed i relation til grænseflader og modeller for de data, derskal udveksles, er altafgørende for at etablere en velfungerendeservicearkitektur. Åbenhed har ikke blot betydning forinteroperabilitet – og dermed de dertil knyttede målsætninger.Det at basere sig på åbne standarder kan desuden have storbetydning for IT-investeringernes succes og soliditet på såvelkort som langt sigt. Ved at basere sig på åbne standarder kanman blandt andet undgå leverandørafhængighed. Adgang tilkildekode (evt. fælles eller åben adgang) kan have betydningfor kvaliteten og prisen for specialudviklet software.

Man kan tale om åbenhed på flere niveauer:

• Åbne standarder (for eksempel W3C standarder).• Åbne grænseflader (for eksempel XML-baserede).• Åbne beskrivelser (for eksempel dokumenterede med

schema i infostrukturbasen).• Åben kildekode (for eksempel når en myndighed får

specialudviklet software).

Der findes en række formelle standardiseringsorganer som foreksempel ISO, CEN, CEFACT og IEC. Det er disse organersom kan lave formelle standarder. Derudover findes der enrække organisationer der udarbejder åbne specifikationer, der imange tilfælde får karakter af de facto standarder. Vigtigeeksempler er OASIS og W3C. W3C (World Wide WebConsortium) laver for eksempel specifikationer – såkaldteanbefalinger (Recommendations) omkring netsteder oginternetarkitektur. W3C har blandt andet defineret standarderneHTML og XML, herunder en række teknologier, somtilsammen udgør en væsentlig del af teknologigrundlaget for enserviceorienteret arkitektur. Sådanne industri-udvikledespecifikationer får i reglen karakter af de facto standarder ogstår ofte uden konkurrence fra mere formelle standarder pga.den arbejdsdeling, der er vokset frem igennem årene.

58

I princippet bør man som offentlig myndighed anvende åbne,formelle standarder, men hvor det ikke er muligt eller attraktivt,bør man overveje fordele og ulemper ved at anvende åbne defacto standarder. Åbne de facto standarder kan give en ret godfremtidssikring, hvis de nyder en bred og stærk opbakning framarkedet. En de facto standard kan også være baseret påproprietær teknologi, der ikke hører under etstandardiseringsorgan eller under en åben organisation, mensom har opnået bred anvendelse på markedet. Et eksempel pådette er Microsofts operativsystem Windows ogdokumentformatet .DOC. Ulempen ved proprietære de factostandarder er, at de vil kunne binde til en bestemt leverandøreller kreds af leverandører. Generelt bør man så vidt muligtundgå sådanne bindinger.

Et åbent IT-system skal blandt andet have veldefineredegrænseflader (for eksempel såkaldte APIer, ApplicationProgramming Interfaces), der overholder åbne standarder somOIOXML eller, hvis det ikke er muligt, bredt accepterede defacto standarder. I en serviceorienteret arkitektur kan derdesuden være behov for åbenhed i forhold til for eksempeldatamodeller (for dataportabilitet) eller diverse driftsdata (forfejlfinding eller optimering).

5.4. FleksibilitetFleksibilitet i betydningen designet til forandring ogvidereudvikling er afgørende i en foranderlig verden.Fleksibilitet har både betydning for innovation og evnen til attilpasse løsninger til ændringer i behov, regler, arbejdsgange,organisation osv. I en foranderlig verden har fleksibilitet ogsåafgørende betydning for succes af IT-projekter og robusthed iIT-løsningerne.Arkitekturen bør tænke i et modulært design, hvor systemerdesignes således, at alle deres funktionaliteter udvikles separat imoduler, der så når de kombineres korrekt udfører hele denønskede proces. De enkelte moduler kan løbende tilpasses nyekrav. Det kan for eksempel være lovændringer, der påvirkerberegningsmetoder. Eller det kan være ønsker/krav om ny

59

funktionalitet, for eksempel flere output-kanaler fra et offentligtfagsystem, som skal kunne kommunikere med andre systemer/services. De enkelte moduler kan ofte benyttes i fleresammenhænge – også af eksterne services – og såledesintegreres i nye systemer. Hermed kan man relativt let, billigtog hurtigt reagere på nye behov og muligheder.

De enkelte moduler bør kunne genbruges i andre systemer enddet system modulet er udviklet/leveret til – de enkelte modulerbør være åbent specificerede, både hvad angår funktionalitet oggrænseflader. Modulerne kan (og vil ofte) indeholdeproprietære elementer, men bør kunne udskiftes som en helhed,evt. med et tilsvarende modul fra en anden leverandør. Et godtprincip er at definere modulerne som komplette funktioner ogat sikre at alle kan leveres af en alternativ leverandør.

5.5. SkalerbarhedSkalerbarhed er en egenskab, der bør indbygges i et system frastarten af. Hvis systemerne ikke kan »følge med« den faktiskebrug af dem, bliver hverken serviceniveau eller effektivitet godnok. Ingen kæde er stærkere end det svageste led og ikomplekse IT-løsninger er det vigtigt at alle elementerunderstøtter den nødvendige og tilstrækkelige skalering til atsikre robusthed.

Det er vigtigt at kunne opretholde både funktionaliteten ogeffektiviteten af en IT løsning, når behovet ændres, foreksempel hvad angår brugerantal, transaktionsvolumen ellerdatamængder. Det er arkitektens rolle at sørge for, at der ikke erunødvendige flaskehalse, der kan skabe problemer ved spids-og overbelastning.

Det understreges, at skalerbarhed ikke er krav om en bestemtkapacitet, men et princip om at systemet skal kunne udbygges(eller formindskes), så det til stadighed dækker det aktuellebehov på en optimal måde.

60

I praksis betyder det, at arkitekturen skal være modulær på ensådan måde, at kapaciteten kan varieres ved indsættelse af flereeller færre elementer (af samme slags) på alle områder, hvorder er brug for skalerbarhed. Denne variation må på intet stedvære begrænset af tekniske eller logiske hindringer, foreksempel i form af begrænset kapacitet af et enkelt element, derikke kan suppleres med flere.

Modularitet og skalérbarhed skal også stå i relation til opgavensart og omfang. Det vil være dyrt og unødvendigt at tage højdefor alle tænkelige udvidelser, hvis det aktuelle system skalopfylde et statisk behov. Derfor afhænger behovet forskalerbarhed i høj grad af systemets størrelse, rolle oganvendelse. For eksempel vil skalerbarhed ikke være etvæsentligt spørgsmål i små systemer, der ikke indgår i samspil,hvor der kan komme kraftige belastninger og store udsving idatatrafikken. Omvendt er det afgørende i store systemer, derskal spille sammen i et kompleks mellem flere store systemermed megen trafik eller med potentiale for udvikling af stortrafik over tid.

5.6. Retningslinier for IT arkitekturDet er nødvendigt at iværksætte en række nationale initiativerfor at understøtte at disse fem principper kan anvendes ipraksis. Én måde er at udarbejde fælles retningsliner forhvordan man konkret skal forholde sig til disse principper. Ikapitel 7 gennemgås mulighederne for at understøtteprincipperne via praksisfællesskaber og fællesreferencemodeller, biblioteker og lignende.

Arkitekturarbejdet i såvel den enkelte myndighed som itværgående projekter skal sikre at de fem grundlæggendeprincipper efterleves og at de projektspecifikke løsningskravtilgodeses. Derfor bør IT-arkitekturarbejdet følge et sæt fællesretningslinier, som beskriver hvorledes de strategiskearkitekturvalg bør foretages og definerer de fælles valg afgrænseflader og andre arkitekturkomponenter.

61

Det anbefales, at retningslinierne som udgangspunkt beskriverfølgende forhold, som knytter sig til en proces frabehovsidentifikation over kravspecifikation tilløsningsbeskrivelse:

• Forretningsarkitekturen for hver enkelt løsning bør tageudgangspunkt i en analyse af de arbejdsgange, som skalstøttes af IT-løsningen. Før IT løsningen designes, bør detundersøges, om arbejdsgangene kan forenkles ellereffektiveres og konsekvenserne af de anbefaledeomlægninger bør beskrives. Når disse valg er taget,beskrives arbejdsgangene og den IT-støtte der ønskes.Retningslinerne skal angive generelle metoder til analyseog beskrivelse.

• Der bør udarbejdes en overordnet beskrivelse afinformationsarkitekturen, med begrundelse for valget afnetop denne struktur. For alle datastrukturer som skaludveksles med andre systemer, bør det undersøges om enåben definition af en tilsvarende datastruktur er tilgængeligi de fællesoffentlige biblioteker og om den med fordel kanbenyttes. Hvis dette ikke er tilfældet, bør årsagerne hertildokumenteres og de anvendte dataformater beskrives ogtilbydes til det fælles bibliotek (infostrukturbasen).

• Der bør udarbejdes en overordnet beskrivelse af løsningen,herunder af de funktionelle komponenter(applikationskomponenter), med begrundelse for valget afdisse. For alle komponenter bør det undersøges om entilsvarende løsning er tilgængelig i fællesoffentligebiblioteker og om den med fordel kan benyttes. Hvis detteikke er tilfældet, bør årsagerne hertil dokumenteres og detalternative valg tilbydes til det fælles bibliotek.

• Planlægningen af IT-infrastrukturen skal baseres på enrække begrundede valg mellem løsninger, der er specifikkefor den enkelte system og tjenester, der kan benyttes afforskellige applikationer. De fælles valg påinfrastrukturområdet kan enten implementeres på enensartet måde (men uafhængigt) i de enkelte systemer, ellerde kan implementeres i fælles regi som

62

infrastrukturtjenester, der benyttes af en lang rækkeoffentlige IT systemer.

I relation til den sidste pind gælder det i begge tilfælde, atformålet er at skabe større sammenhæng mellem de offentligeIT systemer, samtidig med, at omkostningerne til udvikling afækvivalente løsninger reduceres. IT-infrastrukturens tjenester,som stilles til rådighed for IT-systemer på de forskelligeområder, skal tilbydes via en række standardiserede, åbnegrænsesnit. Det er således især ved fastlæggelse afinfrastrukturens arkitektur, at brugen af åbne standarder errelevant. Anvendelsen af standarder skal prioriteres udfra encentral vurdering af standardens relevans, modenhed og densposition på markedet, samt en lokal vurdering af behovet forinteroperabilitet med andre systemer inden for den konkreteløsnings levetid.

63

6 Standarder og løsninger

For at fremme udviklingen af en national ramme for IT-arkitektur anbefales det at iværksætte en række initiativer,herunder:• Udvikling og konkretisering af arkitekturprincipper.• Organisering og beskrivelse af infrastrukturløsninger.• Etablering og vedligeholdelse af en referenceprofil over

anvendte standarder og teknologier i digital forvaltning.• Etablering og vedligeholdelse af sikkerhedsarkitekturer.• Etablering og vedligeholdelse af informationsarkitekturer.

Disse indsatser er nødvendige for at bygge bro mellemrammerne og den konkrete implementering. På denefterfølgende figur er implementeringsaktiviteterne illustreret irammen nederst til højre.

Figur 9 - Implementering af IT-arkitekturen

Dokumenter eksisterende situation

Prioritering ogplanlægning

Gapanalyse

Implementeringsprojekter

Visionerog

pejle-mærker

Forretnings-arkitektur

Informations-arkitektur

Tekniskarkitektur

Konceptuellearkitekturprincipper

Tekniske og forretningsmæssige trends

Indsatsen er centreret omkring etableringen af fælles referencerog værktøjer for arkitekturprocessen, samt implementering affælles løsninger, der kan demonstrere værdien af en fælles IT-arkitektur.

64

6.1. InfrastrukturløsningerLigesom i byplanlægningen benytter man i sammenhæng medIT planlægning også begrebet infrastruktur. IT-infrastrukturenleverer en række services, som er generelle for en gruppe af ITsystemer, for eksempel i form af generelle print- ellerlagringsfunktioner. Den nedenstående figur illustrerer hvorledesIT-infrastrukturen udgør fundamentet for applikationen,samtidig med at den hviler på den øvrige infrastruktur, som foreksempel bygningens fysiske rammer.

Figur 10 - IT-infrastrukturen er fundamentet forapplikationen

IT-infrastruktur

Andeninfrastruktur

ByplanTransportmidler • Kommunikationsmidler • Elektricitet • Vand • Gas • Varme • Affald • Kloak

EjendomFællesareal • Parkering • Rengøring • Portner

BygningOvervågning • Elektricitet • Læsserampe • Bæreevne • Elevator

Data CenterKøling • UPS • Brandslukning • Adgangskontrol

HardwareServere PC'er • Diske • Netværk

SoftwareMiddleware • Operativsystem

Database

Infrastruktur-services

Applikation

Når vi definerer IT-infrastruktur som services udenforretningslogik, har vi samtidig beskrevet IT-infrastrukturensom en del af systemerne, som kan genbruges på tværs af deforskellige forvaltninger. Men IT infrastrukturen er ikke blotvigtig som fælles grundlag for implementering af forskelligfunktionalitet, den har også en central rolle somintegrationsgrundlag. I IT-infrastrukturen etableres destandardiserede grænsesnit, som giver mulighed for

65

sammenkobling af forskellige forvaltningssystemer. Det er altsåi forbindelse med udvikling af IT-infrastrukturen, at valget aftekniske standarder er afgørende for at skabe interoperabilitetmellem systemerne.IT-infrastrukturen har to væsentlige formål: Dels skal denudgøre et fælles fundament for forretningslogikkens udfoldelse,som giver hurtigere, billigere og mindre risikofyldte IT-projekter, dels skal den udgøre en fælles ramme forinteroperabiliteten imellem systemerne.

Det offentliges opgaver er imidlertid langt fra så ensartede, atde kan understøttes med én fælles IT-infrastruktur. Forskelle ianvendelsessituationen, geografisk udbredelse, eller i debenyttede informationsstrukturer, giver behov for forskelligeydelser fra IT-infrastrukturen. Til gengæld vil der væresituationer, hvor meget forskellige systemer stiller de sammebasale krav til IT-infrastrukturen. Der er altså brug for enkontrolleret mangfoldighed af infrastrukturløsninger. Denenkelte infrastrukturløsning skal være forbundet til de øvrigemed veldefinerede integrationsmekanismer, så de på forhånd erintegreret og tilsammen kan understøtte behovet forsammenhæng mellem den offentlige forvaltnings applikationer.At organisere og planlægge IT-infrastrukturen er en centralopgave i IT-arkitekturen og i de følgende afsnit gives forslag tilhvorledes fordelene ved en harmoniseret IT infrastruktur kanopnås.

MønstreInfrastrukturen kan organiseres og beskrives som mønstre, detvil sige standardiserede beskrivelser af krav, komponenter ogservices, som tilsammen udgør den nødvendige ogtilstrækkelige infrastruktur for en given applikation/forretningslogik. I den nedenstående figur illustreres denoverordnede beskrivelse af et infrastrukturmønster i form af enlagvis klassificering af funktionerne og en liste over de tekniskekomponenter på hvert lag:

66

Figur 11 - Eksempel på et infrastrukturmønster

SAP BAPI

Apache Web Server

SAP proprietær

IBM MQSI

Oracle 8

SUN Solaris

EMC SAN

Ethernet + Frame

KomponenterNetværk

Datalager

Server Hardware/OS

Database Server

Integrations Server

Applikations Server

Præsentation

API / Service

Ved at organisere infrastrukturen i mønstre, hvis opbygning ogegenskaber beskrives på en ensartet måde, kan denne del af ITsystemet genanvendes til en række applikationer, der stiller desamme krav til infrastrukturen. På nedenstående figurillustreres princippet for mønster-baseretinfrastrukturplanlægning: I stedet for at opbygge en separatinfrastruktur for hver applikation, udvikles infrastrukturen somet sæt mønstre, der hver understøtter flere applikationer:

Figur 12 -Fra traditionel arkitektur til mønsterbaseret arkitekturTraditionel arkitektur

Mønster-baseret arkitektur

Speciel infrastruktur for hver applikation

Infrastrukturen fælles for flere applikationer

App App App App App

Infra. Infra. Infra. Infra. Infra.

App App App

Mønster A Mønster B

App App

67

For at kunne understøtte et bredt spektrum af applikationer, vildet være nødvendigt at opbygge en portefølje af infrastruktur-mønstre. Til gengæld vil hvert mønster i porteføljen kunneunderstøtte en hel klasse af applikationer og dermed give storebesparelser i udviklingen af infrastrukturen.

Mønstre beskrives ikke blot ved deres tekniske komponenter,men også ved mange andre konkrete parametre, for eksempelderes egenskaber og mulige anvendelsesområder.

Fælles InfrastrukturFor at sikre interoperabiliteten mellem det offentliges ITsystemer vil det være hensigtsmæssigt at implementere dele afIT-infrastrukturen som fællesoffentlige løsninger, medens andrekan opbygges som mere begrænsede fælles løsninger, derbetjener en sektor eller et indsatsområde. Bredden i sådanneimplementeringer vil ofte være bestemt af de driftsmæssigeforhold, eller sektorens specifikke funktionelle behov.

Opbygningen af fælles IT-infrastrukturløsninger kan principieltopdeles i to kategorier:

1. Services, som ikke indeholder specifik forretningslogik (foreksempel kommunikations-funktioner), bør implementeressom del af infrastrukturen og skal overholde en fællesspecifikation af funktionaliteten, med veldefinerede, åbnegrænseflader mod applikationerne og omverdenen.

2. Services, som indeholder forretningslogik, kan placeres iforbindelse med de enkelte systemer, eller somselvstændige applikationer, implementeret i fælles regi.Dette vil for eksempel være tilfældet i specifikke gateway-eller brokerservices.

Forskellen mellem infrastrukturservices og fælles applikationerkan kort beskrives således: Hvis et fælles system yder enforskellig tjeneste overfor de parter, det betjener og dermedindeholder en forretningslogik, betragtes det som en fælles

68

applikation. I modsætning hertil betegnes et system som yderden samme tjeneste til alle parter som en service.

I et fællesskab om services og applikationer, er det essentielt atkontrollen over den fælles funktionalitet bevares hos kredsen afinteressenter, både af hensyn til fleksibiliteten i forbindelsemed nye forvaltningsprocesser og for at undgå afhængighed afeksterne leverandører.

For services, der implementeres i infrastrukturen, må det væreet krav at de opfylder de aftalte krav til funktion og drift.Hvorledes en sådan service realiseres, er derimod ikkeafgørende for brugerorganisationen, og den vil derfor kunneudliciteres til en ekstern leverandør. Hvis der bliver behov forjusteringer i servicen, må specifikationen ajourføres, ogservicen genforhandles.

Anderledes forholder det sig med en fælles applikation, foreksempel i form af en brokerfunktion, som indgår i en offentligarbejdsgang. Her er det af stor betydning, at selve funktionensarkitektur er kendt og styret af de involverede forvaltninger, forkun på den måde kan det sikres, at funktionen vil kunnetilpasses fremtidige forvaltningsprocesser. Hvis en sådanfunktion udliciteres, bør brugerorganisationen sikre sigrettighederne til forretningslogikken, for at undgå afhængighedaf en ekstern leverandør. Forretningslogikken kan for eksempelbestå af distributionslister, regelsæt eller netværksadresser.Hvis forvaltningsprocessen skal omlægges, vil der være behovfor at ændre disse logiske komponenter.

6.2. Tekniske StandarderEn effektiv digital forvaltning, der yder borgerne den optimaleservice, forudsætter at information kan flyde frit indenforforvaltningen – frit i betydningen uden tekniske hindringer,men naturligvis i overensstemmelse med gældende lovgivningpå området.

69

En central arkitekturovervejelse i forbindelse med etablering afet IT-system bør være, hvorledes det sikres at systemet kaninteroperere – snakke sammen med – andre IT-systemer. Detteaspekt er relateret til infrastrukturarbejdet på den måde, at det irealiteten er her rammerne sættes, for hvorledes et mønster kanopbygges eller designes. Det er derfor af største vigtighed, atder etableres et fælles udgangspunkt på dette område i form afen referenceprofil, hvori man kan checke hvilke tekniskestandarder et givet mønster skal understøtte.

Figur 13 - Fælles valg af kommunikationsmønstreBruger

grænseflade

Netværk

Integration

Applikation

Mønster A Mønster B Mønster C

Applikations Server

Præsentation

Integrations Server

Database Server

Server Hardware/OS

Datalager

Netværk

Applikations Server

Præsentation

API

Integrations Server

Database Server

Server Hardware/OS

Datalager

Netværk

Applikations Server

Præsentation

API

Integrations Server

Database Server

Server Hardware/OS

Datalager

Netværk

Referenceprofilen anbefaler de tekniske standarder, der liggertil grund for kommunikationen mellem mønstrene og deresomgivelser. På figuren er dette illustreret med tværgående rør.Fælles valg af kommunikationsmønstre sikrer at forskelligemønstre kan kommunikere med hinanden.

Konventionen bør operationaliseres ved at pålægge en centralmyndighed eller komité ansvaret for oprettelse ogvedligeholdelse af referenceprofilen. Referenceprofilen er i sinnatur et strategisk middel til opnåelse af interoperabilitets- ogstandardiseringsgevinster på længere sigt, hvorfor initiativetogså må håndteres i overensstemmelse hermed, altså som enlangsigtet strategisk indsats styret og understøttet via processer,der sikrer kontinuiteten.

70

ReferenceprofilenReferenceprofilen vil indeholde beskrivelser af og enstillingtagen til udvalgte standarder, teknologier og protokollersom man ønsker anvendt og understøttet i forbindelse medudbygningen af digital forvaltning i Danmark. Ved at etablereen konvention om hvilke standarder der skal understøttes i deenkelte mønstre opnår vi de effektiviseringer,serviceforbedringer og besparelser som er målet for digitalforvaltning.

Ved introduktionen af referenceprofilen er det vigtigt atdefinere om dens funktion skal være som positivliste ellernegativliste, samt om den skal virke som anbefaling eller sompåbud/forbud. I princippet kan regeringen brugereferenceprofilen meget politisk til at detailstyre markedet –som i Tyskland, hvor derese-GIF (SAGA) foreskriver brugen af Java og Linux, og hvorregeringen dermed har styret markedet med en synlig hånd.

Det anbefales, at referenceprofilen i udgangspunktet er megettydelig omkring profilens funktion og de valg, der træffes.Referenceprofilen bør udarbejdes og ajourføres på baggrund afhøringer og en åben dialog med markedet. Referenceprofil børdesuden koordineres med internationalt arbejde med såkaldtee-GIF, e-Government Interoperability Framework, herunder iregi af EU.

Referenceprofilens formål er at give overblik over status foraktuelle og opkommende standarder, samt at præsentereoverordnede vurderinger af, i hvilke situationer en bestemtstandard bør understøttes. Referenceprofilen bør være opdelt ikategorier af standarder, for eksempel som anført inedenstående tabel.

71

BrugergrænsefladerInterface til formidling for og kommunikation med personer, altså den græn-seflade en person vil opleve i forbindelse med interaktion med systemer (in-klusive for eksempel tilgængelighed for handicappede brugere)

Dokument- og dataudvekslingDataformater og teknologier til dataudveksling mellem personer og/eller sy-stemer og personer

Webbaserede servicesTeknologier til etablering af services via netværk – kan være relevante i forbin-delse med etablering af web baserede services og andre funktionelle koblingermellem systemer i realtid.

Content management metadata definitionEmnesystem til opmærkning og beskrivelse af data

DataintegrationData formater og teknologier til dataudveksling mellem systemer

Specifikationer for interkonnektivitetGrundlæggende teknologier til forbindelse og etablering af services via net-værk (Internettet)

NetværkDefinerer de fysiske forbindelsers karakteristika. Dette er det eneste lag dersender bits fra en computer til en anden computer.

Hver kategori vil indeholde en beskrivelse af relevantestandarder, struktureret efter en generel skabelon, som foreksempel kan tage udgangspunkt i følgende inddeling:

En komponent kan være et teknologiområde eller en specifikteknologi eller protokol der anvendes eller kan anvendesindenfor digital forvaltning. Et eksempel på en komponent er»sikkerhed«, der er et højt prioriteret område i forbindelse medrealiseringen af visionen for digital forvaltning i Danmark. Enkategori kan indeholde en eller flere komponenter medtilhørende undergrupper.

Undergrupper er typisk specifikke teknologier ellerprotokoller der anvendes eller kan anvendes indenfor digitalforvaltning. Et eksempel på en undergruppe underkomponenten »sikkerhed« kunne være IP security.

72

Beskrivelsen af en komponent eller en undergruppe er typiskden tekniske betegnelse. I eksemplet IP security villebetegnelsen være IP-SEC RFC2402/2404 der angiver dentekniske betegnelse og reference til RFC-specifikationen afkomponenten eller undergruppen.

Status er udtryk for komponentens eller undergruppensanvendelighed efter vurdering af det relevante, kompetenteorgan i relation til implementeringen af digital forvaltning iDanmark. Vurderingen skal afspejle både standardensmodenhed og de anvendelsessituationer, hvor det er relevant,anbefalet eller påkrævet at følge den.

Noterne er der, hvor komponentens eller undergruppensfunktionalitet beskrives og der hvor der redegøres for deovervejelser der ligger bag status-angivelsen.

6.3. InformationsarkitekturI Danmark er der truffet aftale mellem stat, amter og kommunerom, at benytte XML som fælles udvekslingsformat. De metoderog principper, som anbefales i regi af XML-komitéen kananvendes også i forbindelse med intern dataudveksling ogsystemintegration.

Det fælles XML arbejde består af to delprojekter:• Standardiseringsprocessen har til mål at fastlægge

standarder i XML for udveksling af data mellem offentligemyndigheder og mellem offentlige og private institutioner.

• Infostrukturbasen er en database som indeholderinformationer om indholdet af offentlige databaser samtinformationer om, hvordan man får adgang til disse data.

Som led i standardiseringsarbejdet udarbejdes en rækkekogebøger:• Implementerings-kogebogen: En vejledning for

projektledere, der går på tværs af de øvrige kogebøger.• Modelleringskogebogen: Modelleringsprincipper i UML

(Unified Modeling Language) præsenteret ved en case

73

(sygedagpengerefusion) samt mapningsregler der styrermapningen fra UML-model til XML Schema.

• Standardiserings-kogebogen: En vejledning istandardiseringsprincipperne som er gældende forstandardisering af grænseflader ved hjælp afInfostrukturbasen.

• XML Schema regelsamlingen: Regelsamling for udviklingaf XML Schemaer, således at de kan indgå i denfællesoffentlige datamodel.

• Integrationskogebogen: En teknisk vejledning, hvoremner som protokolvalg, sikkerhed og versionering afservices behandles.

Der er nedsat en permanent XML-komité, som har reference tilDet Koordinerende Informationsudvalg og derigennembestyrelsen for Projekt Digital Forvaltning, der høres omprincipielle problemstillinger og anbefalinger. XML-komitéenhar ansvaret for at sikre sammenhæng og fremdrift i XMLstandardiseringen på tværs af den offentlige sektor. Dernedsættes arbejdsgrupper under komitéen, som forestårstandardisering på forskellige prioriterede områder.

6.4. SikkerhedsarkitekturEn struktureret håndtering af IT-sikkerheden vurderes som enhelt afgørende parameter for udbredelse af digital forvaltning.Sikkerhed er imidlertid ikke blot en komponent eller et produkt,der kan tilsættes den færdige løsning for at opfyldeforretningens krav. Sikkerhedskravene må være indarbejdet iarkitekturprocessen lige fra visionsstadiet og være grundlag forudformningen af sikkerhedsarkitekturen.

Det er en forudsætning for sammenhæng påsikkerhedsområdet, at krav og løsninger beskrives udfra etfælles koncept og koordineres på det overordnede plan.Sikkerheden må styres ud fra principper (med udgangspunkt isikkerhedspolitik, love og regler), som både indeholdertekniske og organisatoriske elementer. Sikkerhedsarkitekturenbeskriver den overordnede organisering af

74

sikkerhedsfunktionerne og specificerer løsningernesegenskaber, så de opfylder visionen. Det betyder for eksempelat arkitekturen beskriver hvilke funktioner og metoder derbenyttes, når en bruger skal identificeres, eller nårinformationer skal beskyttes mod tab eller forvanskning.

En fælles ramme for sikkerhedsarkitekturen bør omfatte flereområder:• En grundig risikoanalyse er afgørende for valget af

sikkerhedsarkitektur og sikkerhedsløsninger. Her beskrivesde trusler, som det er nødvendigt at beskytte sig mod og detvurderes hvilken indsats der vil være passende at investere ibeskyttelsen. Det anbefales, at det offentlige benytter fællesprincipper for denne analyse.

• Sikkerhedsegenskaber kan konceptuelt struktureres i foreksempel identitet, isolation, adgangskontrol,tilgængelighed, integritet. Et fælles begrebsapparat for detteer en forudsætning for at beskrive sikkerhedsbehovet på enensartet måde for forskellige systemer. Det anbefalesderfor, at en fælles ramme definerer disse begreber påentydig måde.

• For at kunne vælge sikkerhedsforanstaltninger, der matcherdet aktuelle risikobillede, er det nødvendigt at strukturerebehovet for sikkerhed udfra et fælles koncept. Detanbefales, at det offentlige benytter fælles begreber ogklassificeringer (for eksempel brugerroller ogdatafølsomhed) som basis for at tillade interoperabilitet,hvor følsomme informationer indgår.

• De konkrete sikkerhedsløsninger indeholder både teknik ogprocedurer (regler) og kun ved en kombination af de hårdeog de bløde elementer kan det ønskede sikkerhedsniveauopretholdes. Derfor er der behov for en fælles ramme for,hvorledes sikkerhedsløsningernes egenskaber vurderes.

En serviceorienteret arkitektur opdeler en applikation i et antalservices, som handler på vegne af andre services eller på vegneaf en bruger. Det stiller særlige krav til den sikkerhedsmæssigehåndtering af samspillet mellem de forskellige services. I

75

fremtiden vil langt flere data blive behandlet i heterogenesystemer med hver deres sikkerhedsløsning. Opgaven er atskabe sikkerhed fra start til mål, uanset hvilken vejinformationerne tager.Sikkerhedsområdet er en del af informationsteknologien, hvorintegrationen mellem specifikke løsninger endnu er på et megetlavt niveau, og en reel interoperabilitet kræver derfor en storkoordinerende indsats. En sammenhængende IT-arkitektur, derogså omfatter sikkerheden, kan spare de offentligeorganisationer for at investere i enkeltstående løsninger, der vilvære en barriere for interoperabiliteten, fordi deressikkerhedskoncepter er modstridende.

I det internationale standardiseringsarbejde tages der tilløb til atdefinere, hvorledes man skaber en sikkerhedsterminologi, derkan forene de eksisterende, ikke-kompatible teknologier. Detvil være en vigtig del af det fortløbende arbejde med denoffentlige IT-arkitektur at følge og påvirke dette arbejde.

76

7 Praksisfællesskaber omarkitekturkomponenter

Praksisfællesskaber med fælles metoder, værktøjer ogstandarder er vigtige for at understøtte bedre sammenhæng.Med en fælles referenceramme kan fællesskaber mellemoffentlige myndigheder udnytte potentialerne i genbrug af altfra aftaler og forretningsprocesser til datamodeller,applikationer og infrastruktur.

Praksisfællesskaber skal her forstås som fællesskaber mellemparter, der har fælles opgaver og interesser og derfor indgårsamarbejde. Det kan for eksempel være i form af etservicefælleskab, hvor aktørerne ønsker at koordinere ogsamordne deres servicering af borgere eller interneadministrative opgaver. Et praksisfællesskab kan eksempelvisstøtte udvikling af fælles løsninger og fælles standarder,videndeling og ressourcedeling. Praksisfællesskaber kandermed ses som et andet udtryk for lærende systemer, der gårpå tværs af administrative grænser.

Den enkelte myndighed kan deltage i mange forskelligepraksisfællesskaber. Projekt Digital Forvaltning rummer såmange udfordringer for såvel fællesskabet som for den enkeltemyndighed, at der er store gevinster at hente ikke bare istandardiserede grænseflader, men også i samarbejde om enrække af de byggeklodser, der skal til for at bygge løsninger.Denne tankegang har en lang tradition for eksempel indenforsundhedsområdet, hvor Medcom er et godt eksempel. Detnationale XML projekt er udtryk for en videreudvikling afdenne tankegang og en udvidelse af bredden i perspektivet. Deværktøjer som er udviklet i forbindelse med XML projektet,herunder den såkaldte infostrukturbase, som er et bibliotek overfælles ressourcer, har til formål at understøtteinformationsudvekslingen i hele den offentlige sektor på tværsaf sektorer.

Tanken med praksisfællesskaber begrænser sig ikke til danskemyndigheder, men bør også omfatte private organisationer ogvirksomheder, herunder leverandører, såvel som udenlandskemyndigheder. Selve begrebet tager nemlig udgangspunkt i de

77

fællesnævnere som kan defineres i forbindelse med udøvelsenaf praksis.Derfor bør arkitekturarbejdet såvel lokalt som nationalt have såvidt et udsyn som muligt. Samarbejdet med den private sektorer ofte afgørende for succes og det samme gælder i stigendegrad internationalt samarbejde.

7.1. Porteføljer af arkitekturkomponenterIT arkitekturen har til formål at organisere komponenterne i engiven IT løsning på en sådan måde, at forvaltningernes behovfor IT-understøttelse af arbejdsprocesserne kan imødekommespå en optimal måde, hvad angår effektivitet og kvalitet. Detbetyder, at IT-funktionerne skal opfylde de stillede krav,samtidig med at omkostningerne skal reduceres til det lavestmulige niveau.

Når omkostningerne vurderes, bør man medtage hele IT-systemets livscyklus og inkludere alle omkostninger tilplanlægning og design, over implementering og test til drift ihele systemets levetid. Ved en sådan betragtning spiller det enstor rolle, om systemet opbygges på grundlag af kendtekomponenter, hvis egenskaber kendes på forhånd – eller omsystemet designes alene udfra et teoretisk oplæg.

Som støtte til arkitekturarbejdet foreslås det at organisere enrække fælles komponenter, så de kan genanvendes i forskelligesammenhænge. Ved at basere arkitekturarbejdet på kendtedelløsninger, reduceres tiden og indsatsen i designfasenbetydeligt, samtidig med at usikkerheden i den efterfølgendeimplementering reduceres. Når systemet senere sættes i drift, erder flere store fordele at hente, fordi man kan tilrettelæggedriften udfra erfaringer med andre systemer, hvor de kendtekomponenter indgår.

Både på nationalt niveau, i den enkelte sektor og i det enkelteprojekt er det muligt at reducere omkostningerne og forøgenytteværdien ved genanvendelse af fællesarkitekturkomponenter.

78

Når et konkret IT system skal realiseres, vil der ofte være brugfor en afvejning af det lokale behov for specialudvikledeløsninger imod fordelene ved at bruge fælles specifikationer,datastrukturer og funktioner. Selv i de tilfælde, hvoranvendelsen nødvendiggør en nyudvikling, der ikke erkompatibel med eksisterende løsninger, vil der være storefordele ved at lade de nyudviklede komponenter indgå i etfælles bibliotek, fordi de dermed kan være kandidater til fælleskomponenter på et nyt område.

I forbindelse med IT-arkitekturarbejdet benytter vi betegnelsenarkitekturkomponent om en række forskellige komponenter, derindgår på forskellige trin i arkitekturprocessen. De fællesarkitekturkomponenter opdeles i følgende kategorier:• Aftalegrundlag, for eksempel aftalekomponenter og fraser.• Forvaltningsarkitektur, for eksempel procesbeskrivelser i

form af UML diagrammer.• Informationsarkitektur, for eksempel databeskrivelser

beskrevet i XML schemaer.• Applikationsarkitektur, for eksempel komponenter som

rummer forretningslogik som kan genbruges• Infrastruktur, for eksempel beskrivelse af infrastruktur i

form af mønstre.

De fem kategorier af arkitekturkomponenter er i nedenståendemodel ordnet efter, hvor de indgår i arkitekturprocessen. Tilhver kategori er tilknyttet en database, hvor de fælleskomponenter lagres og beskrives, så de kan genbruges i andreIT løsninger.

79

Figur 14 - Arkitekturkomponenter

Aftalegrundlag Kontraktmodeller(fx standardkontrakt, skabelon)

Proces beskrivelser(fx diagrammer, UML)

Infostruktur beskrivelser(fx XML skema)

Fælles komponenter(fx åben kildekode, stylesheet og webservices)

Infrastruktur mønstre(fx portefølje af mønstre)

Forvaltningsarkitektur

Informationsarkitektur

Applikationsarkitektur

Infrastruktur

I den følgende figur bruges modellen til at vise hvordanpraksisfællesskaber og standardisering understøtter den enkeltemyndighed og kan bidrage til kvalitetssikring og besparelserbåde for den enkelte og for fællesskabet.

Figur 15 - Praksisfællesskaber støtter den enkeltemyndighed

Aftalegrundlag

Forvaltnings-arkitektur

Informations-arkitektur

Applikations-arkitektur

Infrastruktur

AftalerBenyt fælles aftaler eller kontraktmodeller

En konkret case kan illustrere betydningen af dette. Someksempel kan tages administrationen af sygedagpenge, hvorman kan tænke sig en digital løsning, der betyder at data lettereflyder på tværs af de involverede aktører (arbejdsgiver,

80

arbejdstager, myndighed og eventuelt læge med flere). Meddette udgangspunkt kan man på hvert trin i arkitekturprocessentænke sig en række spørgsmål besvaret og løsningerne hertildokumenteret, for eksempel:

Aftale:Hvem har ansvar for hvad (om data når frem, sendeblanketten videre, hvem er ansvarlig for sikkerhed,afslutning af proces, arkivering)?

Proces:Hvordan ser processen ud (hvordan er den optimale proces,er der alternative processer)?

Information:Hvilke data skal udveksles (datadefinitioner, hvor findesdata, datakvalitet, klassifikationssystemer)?

Applikation:Hvilke komponenter skal bruges til at behandle ogpræsentere data og funktionalitet (programmodul, service)?

Infrastruktur:Hvilken teknisk infrastruktur skal der til for at understøtteden digitale proces? (server, teknisk håndtering afsikkerhed, med videre)?

I de følgende afsnit beskrives mulighederne for genanvendelseaf arkitekturkomponenter på alle fem niveauer.

7.2. Fælles kontraktmodellerEn væsentlig del af udfordringen ved integration af systemer iden offentlige forvaltning er opbygningen af et aftalegrundlag,som regulerer ansvar og rettigheder omkring de involveredeinformationer og funktioner. Her vil der være væsentligefordele ved at opbygge en samling af fælles kontraktmodeller,som udgør et fælles regelsæt for adgang til informationer ellerbrug af tjenester, som stilles til rådighed for/af en anden part. Etfælles regelsæt vil være værdifuldt, både når det drejer sig omfælles offentlige services og når det gælder samarbejde medleverandører og samarbejdspartnere uden for den offentligesektor.

81

Nedenstående tabel giver et overblik over mulige fordele iforbindelse med udarbejdelse og deling af kontraktmodeller:

Samarbejde om… Lokalt perspektiv Fælles perspektiv

Selve Kan sikre konsistens i Ressourcepooling ogudviklingsprocessen forhold til andre aktører. besparelse. Koordine-

Kan fjerne usikkerhed ring i forhold til fjernel-om andres handlinger se af eventuelle barrie-og motiver. rer i lovgivning o.l.

Standardiseringsarbejde Der vil ofte være stor Standardformuleringerinteresse i at koordinere vil gøre det lettere atmed andre for at kvalitets- håndtere ændrede ram-sikre løsningen og for at mevilkår for aftaler, forpåvirke andre aktører. eksempel lovændringer.

Koordinering af Ved at gøre det lettere, Afgørende for at der kankontrakter og aftaler billigere og mere trygt skabes nye samar-

kan nye aktører „lokkes bejds- og forretnings-ud af busken“ og der kan modeller med tværgå-lettere skabes nye sam- ende processer ogarbejds- og forretnings- mange aktører invol-modeller. veret.

7.3. Fælles funktionsbeskrivelserEn del offentlige forvaltninger benytter sammenlignelige ellerendog identiske arbejdsprocesser, fordi de udfører den sammeopgave overfor borgerne. Det giver mulighed for at genanvendede overordnede beskrivelser af forvaltningsprocesserne, ellerblot gennemgående dele heraf, som for eksempel udbetaling afen ydelse, eller udsendelse af et brev til en borgers adresse. Vedat samle disse procesbeskrivelser i en fælles database istruktureret form, vil kravspecifikation i forbindelse medsystemanskaffelser blive lettet betydeligt, samtidig med at dekommende systemer vil blive langt lettere at integrere, fordi defunktionelt er tættere på hinanden. De vil desuden kunne dannegrundlag for udvikling af relevante modelbeskrivelser, foreksempel i UML.

Nedenstående tabel giver et overblik over mulige fordele iforbindelse med udarbejdelse og deling affunktionsbeskrivelser:

82

Samarbejde om… Lokalt perspektiv Fælles perspektiv

SelSelSelSelSelvvvvveeeee Mange organisationer Mulighed for at genbru-udviklingsprudviklingsprudviklingsprudviklingsprudviklingsprocococococesesesesessensensensensen springer over her. ge analyser og beskri-

Mulighed for at lære af velser. Det kræver me-„naboen“ kan være af stor get arbejde og der kanværdi, især for organisa- derfor spares ressour-tioner som er små og som cer. Samtidig vil fællesder findes mange ens af. udvikling også kunne

bidrage til kvalitets-sikring.

TTTTTesesesesest af prt af prt af prt af prt af procococococesesesesessens ogsens ogsens ogsens ogsens og Øget tryghed ved at kunne En nødvendig sikring afbeskrivbeskrivbeskrivbeskrivbeskrivelsens kvelsens kvelsens kvelsens kvelsens kvalitalitalitalitalitetetetetet sammenligne. Kan lettere fælles forståelse og om

bruges til benchmarking nødvendigt fælles hånd-når man følger samme tering af konkrete pro-metode og stiller resul- cesser og delprocesser.tater til rådighed forhinanden.

KoorKoorKoorKoorKoordinering afdinering afdinering afdinering afdinering af Øget tryghed i forhold til Afgørende parameterprprprprprocococococeseleseleseleseleselementementementementementererererer samarbejdspartnere, når for at etablere tætte

man ved hvordan de hånd- samarbejder både rentterer processer. forretningsmæssigt,

processuelt og teknisk.

7.4. Fælles datamodellerEn forudsætning for at interoperabiliteten mellem forskelligeforvaltninger kan sikres, er adgangen til fælles modeller for dedata, der skal udveksles. Dette kan opnås gennem etablering afen fælles database for datadefinitioner, således som det alleredeet realiseret i Infostrukturbasen (ISB). Det giver mulighed forgenanvendelse i andre implementeringer og vil bane vejen foren stadig forbedret integration mellem systemerne.Nedenstående tabel giver et overblik over mulige fordele iforbindelse med udarbejdelse og deling af standardiserededatamodeller og -beskrivelser.

83

Samarbejde om… Lokalt perspektiv Fælles perspektiv

Selve Kan have strategisk Hvis datadefinitionerudviklingsprocessen betydning i forhold til kan genanvendes af

bl.a. at kunne spille andre billiggør og lettersammen med systemer det generelt integra-og aktører, herunder tionsarbejdet i detaktuelt ukendte parter. offentlige og i den pri-Letter integrations- vate sektor.arbejdet.

Standardiseringsarbejde Der vil ofte være stor En afgørende forudsæt-interesse i at koordinere ning for at realisereog påvirke andre aktører visionerne om digitalfor ikke at ende i blind- forvaltning, herundergyde. brugeren/borgeren i

centrum, servicefælles-skaber samt datadeling.

Deling af Mulighed for at kunne Facilitering af deling afdatastandarder benytte andres datadefini- datastandarder for at

tioner og skemaer og at sikre hurtig og effektivandre benytter ens egne. implementering.

7.5. Fælles komponenter og servicesPå applikationsniveauet vil de fleste projekter være baseret pået standardudviklingsmiljø, med de forvaltningsspecifikkefunktioner implementeret som specialkomponenter ellerservices. Mange systemer i den offentlige forvaltning udførerfunktioner, som er stort set identiske. Der er derfor et stortpotentiale for genanvendelse af specialudviklede komponenter,som kan realiseres, hvis hvert enkelt projekt bidrager ved atlægge en kopi af specialudviklede komponenter i et fællesbibliotek, hvor andre projekter kan hente kildekode ellerdesign.

Nedenstående tabel giver et overblik over mulige fordele iforbindelse med udarbejdelse og deling af komponenter ogservices:

84

Samarbejde om… Lokalt perspektiv Fælles perspektiv

Selve Kan have strategisk Hvis kode kan genan-udviklingsprocessen betydning i forhold til vendes af andre myn-

bl.a. at anvende flere digheder kan der sparesleverandører og undgå udviklingsomkostningerlock-in. Letter desuden og tid.integrationsarbejdet.

Test af komponentens/ Der vil ofte være stor En typisk stordriftsfor-servicens kvalitet interesse i at tredjepart del kan betyde at fæl-

kan teste/lave review. lesskabet er en relevantramme, men det er op-lagt at overlade mestmuligt til markedet.

Deling af kildekode Interesse i at kunne Facilitering af delingbenytte andres kildekode, af åben kildekode ogfor eksempel i form af samarbejde.udbygninger til egneapplikationer.

7.6. Fælles infrastrukturmønstrePå det nederste niveau er der mulighed for genanvendelse afinfrastrukturløsninger, som er opbygget af en lang rækkestandardkomponenter, der allerede er integreret. Infrastrukturenindeholder ingen forretningslogik men tilbyder de generelleservices, som applikationerne benytter, når forretningslogikkenimplementeres. En typisk service fra infrastrukturen kan væreidentifikation af en bruger.

Infrastrukturen kan organiseres og beskrives som mønstre, detvil sige standardiserede beskrivelser af krav, komponenter ogservices, som tilsammen udgør den nødvendige ogtilstrækkelige infrastruktur for en given applikation. Ved atorganisere infrastrukturen i mønstre kan denne del af ITsystemet genanvendes til en række applikationer, der stiller desamme operationelle krav til infrastrukturen. For at kunneunderstøtte et bredt spektrum af applikationer vil det værenødvendigt at opbygge en portefølje af infrastruktur-mønstre.Til gengæld vil hvert mønster i porteføljen kunne understøtteen hel klasse af applikationer og dermed give store besparelseri udviklingen af infrastruktur løsninger.

85

Nedenstående tabel giver et overblik over mulige fordele iforbindelse med samarbejde om infrastrukturmønstre.

Samarbejde om… Lokalt perspektiv Fælles perspektiv

Selve IT-investeringen Udgift, risiko og fordele Fællesskabet bør kunbæres og høstes mest træde ind hvor det ermuligt lokalt. Hvis fælles- strategisk vigtigt forskabet kan tilbyde konkur- fællesskabet. Alternativtrencedygtige løsninger, kan fællesskabet værevil de blive foretrukket. leverandør til den lokale

enhed.

Test og kvalitetssikring En ressourcekrævende En typisk stordriftsfor-af løsningselementer opgave, som helst undgås, del kan betyde at fæl-og produkter men muligvis kan være et lesskabet er en relevant

krav til en leverandør i ramme, men det er op-konkrete tilfælde. lagt at overlade mest

muligt til markedet.

Udarbejdelse af mønstre Motivation til at udvikle Stor fordel ved at få ud-mønstre til egen porte- viklet mønstre som kanføljestyring, men kun hvis benyttes af mange.behov er erkendt og skøn-nes fordele heraf. Evt.motivation til at bidragetil fællesskab.

Deling af mønstre Interesse i at benytte Stor fordel ved facilite-mønstre med »varede- ring af deling af møn-klarerede« egenskaber. stre og samarbejde.Betalingsvillighed hvisder er nytteværdi.

86

8 Koordinering, kompetencerog kommunikation

Det vigtigste aspekt inden for den offentlige IT arkitektur er atarkitekturarbejdet gribes an på en koordineret måde. Hvismålene for digital forvaltning skal indfries fordrer det, at enrække IT-arkitektoniske beslutninger tages koordineret på tværsaf myndigheder og sektorer.

En fælles ramme for IT arkitekturen betyder, at arkitekturvalglettes betydeligt, fordi man i det enkelte projekt kan tageudgangspunkt i de fælles valg af standarder samt trække påerfaringerne fra andre offentlige IT-systemer. Man kan ogsåbasere den konkrete løsning på komponenter og strukturer, somer gennemprøvede og har veldefinerede egenskaber.

En fælles ramme for IT arkitektur skal sikre optimal udnyttelseaf ressourcerne – derfor er det essentielt, at allebeslutningstagere på IT området udnytter fordelene ved atvælge fælles arkitekturelementer, både i form af funktionellekomponenter og services og i form af fælles infrastruktur-løsninger, for at optimere de enkelte forvaltningssystemer ogskabe sammenhæng mellem dem.

I det følgende stilles forslag til, hvordan rollerne kan fordeles,hvordan man kan sikre den nødvendige udvikling af viden ogkompetencer blandt beslutningstagere samt hvordan man kanarbejde med fælles ledelsesværktøjer.

8.1. KoordineringArkitektur og styring på flere niveauerSom det er fremgået af det foregående vil det værehensigtsmæssigt at beskrive og optimere IT-arkitekturen påflere niveauer på samme måde som for de fysiskebygningsværker. Opdelingen vil omfatte tre niveauer:• Det overordnede niveau: Nationalt eller internationalt.• Afgrænsede samarbejder: For eksempel inden for en sektor,

et servicefællesskab eller et indsatsområde.• Det lokale niveau: Den enkelte myndighed, institution eller

et projekt.

87

IT-arkitekturen repræsenterer sammenhængen mellem deforretningsmæssige/politiske mål og den overordnedeorganisering af IT systemerne. Den bør i øvrigt styres udfranærhedsprincippet. Det betyder, at beslutninger bør træffes pålavest mulige politisk/administrative niveau og at et højereniveau kun skal tage beslutningerne, når det er nødvendigt afhensyn til det større fællesskab.

Som en konsekvens af dette princip børarkitekturbeslutningerne i forbindelse med tværgåendeinitiativer tages af de involverede parter med hensyntagen til dehøjereliggende niveauer.

Det betyder for eksempel• at staten eller et tværoffentligt organ med den nødvendige

kompetence på nationalt niveau kan fastlægge nationalearkitekturprincipper.

• at offentlige myndigheder i stat, amter og kommuner påeget initiativ og eventuelt i fællesskab (evt. sammen medprivate aktører) kan fastlægge mere detaljeredearkitekturprincipper på det pågældende område.

88

Arkitekturprincippernes opdeling er søgt anskueliggjort inedenstående tabel:

Arkitektur niveau Hvem tager arkitekturbeslutninger DækningsområdeFokusDet oDet oDet oDet oDet ovvvvverererererororororordnede nivdnede nivdnede nivdnede nivdnede niveaueaueaueaueau Fx bestyrelsen for Projekt Digital Forvaltning, det

Koordinerende Informationsudvalg (KIU) eller IT-arkitekturkomitéen afhængig af,hvor principiel og vidtgående beslutningen er. Dækker hele den offentligesektor. Kan i princippet også gælde samarbejde med leverandører og partnere.Vil typisk være orienteret mod overordnede rammer for interoperabilitet og sikker-hed samt fælles services/infrastruktur.SamarbejdsnivSamarbejdsnivSamarbejdsnivSamarbejdsnivSamarbejdsniveaueteaueteaueteaueteauet Fx en styregruppe for et servicefællesskab eller etfælleskommunalt samarbejde. Kan være sammensat på tværs af stat, amter ogkommuner og eventuelt med private parter. Vil typisk være orienteret modnødvendig overholdelse af fælles standarder for at sikre operationelle løsninger.Det lDet lDet lDet lDet lokalokalokalokalokale nive nive nive nive niveaueaueaueaueau Den enkelte myndighed eller institution beslutter selv kompe-tencefordeling Kan for eksempel være en kommune, et amt, eller et ministe-rium. I sidstnævnte tilfælde kan departement, styrelser m.v. ses adskilte eller somen samlet koncern. Vil typisk være orienteret mod økonomi, effektivitet og over-ordnet målstyring.

Både på nationalt niveau, i det enkelte servicefællesskab og iden enkelte myndighed er det vigtigt, at de strategiskebeslutninger om IT-anvendelse tages på grundlag af etkonstruktivt samspil mellem ledelsen og IT specialisterne.

Det betyder, at IT-organisationen skal tage ansvaret for detekniske valg, som er udtrykt i IT-arkitekturen og dereskonsekvenser på en måde, så afvejningen mellem fordele,økonomi og risiko kan foretages af forvaltningens ledelse somen sikker beslutning.

Arkitektur niveau Hvem tager arkitekturbeslutninger Dækningsområde Fokus

Det overordnede Fx bestyrelsen for Projekt Digital Dækker hele den Vil typisk være ori-niveau Forvaltning, det Koordinerende offentlige sektor. enteret mod over-

Informationsudvalg (KIU) eller Kan i princippet også ordnede rammerIT-arkitekturkomitéen afhængig af, gælde samarbejde for interoperabili-hvor principiel og vidtgående med leverandører og tet og sikkerhedbeslutningen er. partnere. samt fælles ser-

vices/infrastruktur.

Samarbejds- Fx en styregruppe for et service- Kan være sammensat Vil typisk være ori-niveauet fællesskab eller et fælleskom- på tværs af stat, amter enteret mod nød-

munalt samarbejde. og kommuner og even- vendig overholdel-tuelt med private parter. se af fælles stan-

darder for at sikreoperationelle løs-ninger.

Det lokale niveau Den enkelte myndighed eller institution Kan for eksempel være Vil typisk være ori-beslutter selv kompetencefordeling en kommune, et amt, enteret mod øko-

eller et ministerium. nomi, effektivitetI sidstnævnte tilfælde og overordnet mål-kan departement, styring.styrelser m.v. sesadskilte eller somen samlet koncern.

89

Ser man på det enkelte projekt vil der typisk være tre primærespillere, der tilsammen skal kvalitetssikre IT-arkitekturen:Forvaltninger og institutioner:

Den øverste ledelse har rollen som bygherre for ITsystemet, er ejer af forretningsprocesserne og definererforretningskrav til funktionalitet, kapacitet etc.

IT-organisation:Optimerer IT-løsningernes overordnede struktur underhensyntagen til centrale og lokale krav.

Leverandører og partnere:Har mange roller og samarbejdsformer, både påinfrastruktur- og applikationsniveau.

IT-arkitekturkomité og kompetencemiljøFor at sikre implementering og styring af det nationalearkitekturrammeværk er det nødvendigt, at der etableres etfælles offentligt organ med ansvar for den nationale IT-arkitekturramme. På denne baggrund foreslår arbejdsgruppenoprettelsen af en IT-arkitekturkomité.

Som del af Projekt Digital Forvaltning bør komitéen havereference til Det koordinerende Informationsudvalg ogherigennem til bestyrelsen for Projekt Digital Forvaltning.

Arkitekturkomitéen bør sammensættes af eksperter fra denoffentlige sektor. Man bør desuden overveje, hvordanrepræsentanter fra den private sektor kan indgå iarkitekturarbejdet af hensyn til:• Sikring af den fornødne ekspertise.• Behovet for at skabe sammenhæng mellem den offentlige

og den private sektors IT-anvendelse.• Den offentlige sektors samarbejde med IT-leverandørerne.

Det bør sikres at komitéen i sin sammensætning dækker etbredt og relevant felt af ekspertiser. Komitéen børsammensættes således at der er en god balance mellem IT-faglige kompetencer og forretningsmæssig baggrund. Komitéen

90

bør på sine møder kunne suppleres med ekspertbistand, særligtinviterede gæster og lignende.

Komitéen vil have behov for støtte af et sekretariat. Desudenbør der etableres et kompetencemiljø baseret på en mindrekerne i form af sekretariatet og et netværk af relevanteeksperter i såvel offentlige myndigheder som iforskningsverdenen og i den private sektor.

Komitéen og de dertil knyttede støttefunktioner skal varetagefølgende primære opgaver:• At udvikle og vedligeholde fælles koncepter, metoder og

principper.• At give anbefalinger om anvendelse af relevante standarder.• At give anbefalinger om udvikling af fælles

infrastrukturservices• At rådgive om implementeringen af de overordnede

beslutninger om IT-arkitektur, som tages i regi af stat, amterog kommuner i fællesskab.

• At bidrage til den videre planlægning af konkrete tiltag.• At facilitere deling af viden og erfaringer.• At forvalte eventuelle centrale midler.

Som mere konkrete eksempler på aktiviteter i forbindelse medarkitekturarbejdet kan nævnes:• Etablering af overordnede rammer for uddannelse og

certificering.• Videndeling, koordinering og rådgivning i forhold til

konkrete projekter.• Planlægning af en fælles offentlig IT infrastruktur med

fælles tjenester.• Beskrivelse/publicering af fælles arkitekturelementer,

herunder porteføljer af kontraktmodeller,procesbeskrivelser, infostrukturbeskrivelser,forretningslogik (applikationskomponenter) oginfrastrukturløsninger.

• Assistance og rådgivning til aktørerne i de decentraleprocesser omkring IT-arkitektur.

91

• Kvalitetssikring af decentrale beslutninger omkring ITarkitektur.

• Synliggørelse af resultater og fordele.

Ethvert arkitekturarbejde må tage udgangspunkt i de aktuelleforhold. Der mangler i dag tilstrækkeligt overblik over densamlede offentlige systemportefølje. Det foreslås derfor, at deretableres rammer for en formaliseret indsamling af viden pådette område. Dette vil som sideeffekt have identifikation af enrække fremtidsrettede projekter, hvoraf nogle givetvis vil kunnetjene som bedste praksis eksempler for andre løsninger ognogle på sigt indgå som fælles komponenter i den samledeoffentlige IT-arkitektur. Denne dataindsamling vil tillige kunneudfylde en vigtig funktion som koordinator mellem offentligeIT-projekter.

BenchmarkingIT arkitekturprocessen har som sit væsentligste formål atforbedre effektiviteten og kvaliteten af den offentlige ITanvendelse.

For at synliggøre resultaterne af en koordineret indsats for enfælles IT-arkitektur er det nødvendigt at etablere en fællesmodel for benchmarking af det offentliges IT-anvendelse. Vedbenchmarking forstås måling og sammenligning af en rækkekonkrete parametre, som indikerer værdien af en fælles IT-arkitektur. Der er igangsat arbejde med benchmarking i regi afstatens IT-politik.

Målingens resultater skal ikke blot anvendes til vurdering afetablerede løsninger og synliggørelse af deres udvikling overtid. Gennem en systematisk erfaringsopsamling vil en fællesbenchmarking metode tillige have stor værdi som model vedbudgettering af omkostninger for planlagte initiativer, herundersammenligning af alternative scenarier for etablering af nyeløsninger og modernisering af de eksisterende.

92

En fælles metode for benchmarking for stat, amter ogkommuner, naturligvis med frihed til at udvide efter specifikkebehov, kan blive et meget nyttigt redskab for såvel den enkeltemyndighed som for fællesskabet. Metodeapparatet bør omfattefælles rammer for modenhedsmåling af arkitekturarbejdet, samtkortlægning og analyse af eksisterende IT-løsninger.

8.2. Kompetencer og kommunikationFor at sikre udbredelsen af de fælles principper, metoder ogprocesser er der behov for både kommunikation ogkompetenceudvikling. Komitéen og sekretariatet for IT-arkitektur vil som en af sine væsentlige opgaver have at sikrebred information om og markedsføring af arkitekturtanken.

Der kan med fordel tages udgangspunkt i eksisterende projekterog aktiviteter inden for højt prioriterede sektorer. Der børtilbydes sparring til igangværende offentlige projekter,eventuelt i form af et aktivt review af arkitekturen. Dengenerelle arbejdsform bør være faciliterende, ikke regulerendeeller kontrollerende.

Der bør ske en synliggørelse af projekter med god IT-arkitekturog af IT løsninger, der er opbygget i overensstemmelse medretningslinier og standarder (reference implementeringer). Enfremhævelse af de fordele, man har opnået, samtidig med enåben og seriøs analyse af de problemer, man støder ind i og deudfordringer, man står overfor.

IT-arkitektur bør fremmes som disciplin, med fokus på densamlede proces for Enterprise Architecture. IT-arkitektur erikke et udbredt fag på universiteter eller i andreundervisningssammenhænge. En vigtig opgave vil være atbeskrive og deltage i opbygningen af kompetencegivendeuddannelseselementer, typisk med afsæt i eksisterendeuddannelser og efteruddannelser. De fælles offentligeprincipper og metoder for IT-arkitekturen bør endvidereudbredes i uddannelsessektoren, med henblik på indarbejdelse irelevante uddannelser. Til dette formål bør der etableres en

93

dialog med højere uddannelsesinstitutioner og relevante andreorganisationer med henblik på at etablere encertificeringsordning for IT-arkitekter, for at sikre et fællesvidengrundlag hos IT-arkitekterne. En egentlig certificeringanses for at være et vigtigt incitament, hvis der hurtigt skal nåsen synlig vækst i antallet af IT-arkitekter i Danmark. Derforanbefales det at prioritere denne indsats højt.

For at fremme synligheden af det offentliges indsats for atharmonisere IT-arkitekturen, kan institutioner og virksomhederder råder over certificerede IT arkitekter synliggøres ligesomprojekter, der er bygget på en god arkitektur, kan fremhæves ioffentligheden.

Udover de mere specifikke tekniske kompetencer er der behovfor en bred forståelse af relationen mellem forvaltnings/forretningsledelse og optimering af IT investeringer. Det ernødvendigt for at motivere de politiske, de administrative og dekommercielle spillere til at bakke op om en fælles ramme forstyring af IT arkitektur. Dette gælder også den private sektor irollen som leverandør, samarbejdspartner og rådgiver for detoffentlige.

Derfor er det vigtigt at der gennemføres aktiviteter, som kansikre spredning af viden, forståelse og accept af det arbejde,som skal sættes i gang og af de koncepter og metoder, som skalbringes i anvendelse. På denne baggrund bør der oprettes etforum for IT-arkitektur, det vil sige et fagligt supplement tilarkitekturkomitéen og en del af kompetencemiljøet. Et sådantforum kan medvirke til at facilitere deling af viden, erfaringerog værktøjer på tværs af organisatoriske grænser. Målgruppenfor forum’et er foruden IT-arkitekterne i det offentlige ogsåeksperter i det private og i forskningsverdenen.Praksisfællesskaberne vil naturligt også være repræsenteret.

94

Bilag A: Kommissorium forarbejdsgruppe om IT-arkitektur

(Uddrag af det Koordinerende Informationsudvalgs kommissorium forarbejdsgruppen, der har skrevet Hvidbog om IT-arkitektur)

OpdragArbejdsgruppen skal udarbejde en hvidbog om IT-arkitektur.Hvidbogen skal beskrive rammerne for offentlige strategier forudviklingen af en tidssvarende IT-arkitektur og givepejlemærker for implementeringen, herunder pege på konkretearkitekturmodeller, tekniske standarder med videre.

Hvidbogen skal blandt andet bygge på den grønbog om IT-arkitektur, som Ministeriet for Videnskab, Teknologi ogUdvikling, IT- og Telestyrelsen, udsender i offentlig høring iseptember 2002 og på de svar, som kommer i forbindelse medhøringen

Hvidbogen skal koordineres med arbejdet med udvikling afforretningsprocesser og prioriteringer i regi af Den DigitaleTaskforce.

Arbejdsgruppens sammensætningGruppen består af 10-12 personer. Ministeriet for Videnskab,Teknologi og Udvikling har efter samråd med KIU og StatensIT-forum inviteret en relevant kreds til at deltage iudarbejdelsen af Grønbogen som referencegruppe. Detanbefales, at samme gruppe fortsætter som arbejdsgruppen,men den kan suppleres med yderligere medlemmer, hvis KIUønsker dette.IT- og Telestyrelsen varetager formandskab ogsekretariatsfunktion.

95

MedlemmerMichael Bang Kjeldgaard,

IT- og Telestyrelsen (formand)Jens Ole Back,

Den Digitale TaskforceWinn Nielsen,

Den Digitale TaskforceMichael Hald,

KLJesper Nørgaard Andersen,

Nordjyllands Amt /AmtsrådsforeningenBo Møller,

Ministeriet for Flygtninge, Indvandrere og IntegrationMartin Pedersen,

ErhvervsministerietLilian Sølbeck,

KulturministerietMogens Andersen,

Told og SkatStig Katznelson,

VidenskabsministerietSøren Bauer,

ØkonomistyrelsenSøren Klostergaard Pedersen,

BanestyrelsenVagn Lauersen,

Undervisningsministeriet

Sekretariat, IT-og Telestyrelsen:John GøtzeSøren Alain MortensenTorsten Møller MadsenAllan Bo Rasmussen, konsulent