Tidligere Fælleskommunale Arkitekturprincipper

Arkitekturprincipperne har som formål at understøtte og kommunikere den valgte retning i den fælleskommunale arkitekturstyring.

Principper anvendes til at sikre konsistens og sammenhæng i beslutninger på tværs af projekter – som en vejledning, der anvendes til at træffe de konkrete beslutninger. Principperne er derimod ikke de faktiske beslutninger. Det enkelte princip skal altid vurderes ift. det enkelte projekt m.v., hvor de konkrete afgørelser træffes.

Principperne anvendes til at vurdere overensstemmelsen mellem de konkrete beslutninger i kommunale it-projekter, road-maps og strategier og den overordnede retning og vision for kommunal it-udvikling. Der kan være gode grunde til at vælge at afvige i konkrete tilfælde, men afvigelsen bør altid forklares. Herved sikres, at arkitekturen overordnet bevæger sig i den ønskede retning, og at afvigelser vælges af vigtige strategiske og operationelle hensyn.

Principperne er grupperet efter, om de anvendes som vejledning til beslutninger på områderne:

• A. Strategi, primært henvendt til politikere og beslutningstagere i den kommunale forretning.
• B. Forretning og Information, primært henvendt til beslutningstagere og forretningsudviklere eller
• C. Applikation og Teknologi, primært henvendt til kravstillere og leverandører. 

Beskrivelser af de tidligere arkitekturprincipper foreligger også samlet i en print-venlig version, se nedenfor:

A. Strategi

A1. Der arbejdes mod en fælles rammearkitektur

Beskrivelse

En rammearkitektur giver en fælles anerkendt skabelon til at analysere den kommunale forretning på en ensartet måde, ligesom den opstiller rammerne for, hvordan den fysiske it skal designes, udvikles og implementeres. Den fælleskommunale rammearkitektur er designet, så det sikres, at den kommunale it besidder de egenskaber, kommunerne har behov for, for at opfylde målsætningerne om en effektiv og attraktiv kommunal sektor. Det omfatter bl.a. integration og sammenhæng med andre it-løsninger i det fælleskommunale it-landskab, skabeloner for, hvordan eksisterende løsninger kan leve op til rammerne etc.

Den fælleskommunale rammearkitektur vil være under konstant udvikling i de kommende år. Det bør i det enkelte projekt vurderes, hvordan projektet bedst gør brug af rammearkitekturen, og evt. bidrager til videreudvikling af rammearkitekturen. Dette kan fx gøres gennem en gap-analyse af road-maps eller systembeskrivelser. Det kan være små justeringer, der er nødvendige for at være i overensstemmelse med rammearkitekturen. Flere projekter vil endda bidrage aktivt til udvikling af rammearkitekturen, eksempelvis ved definition af en rammearkitektur for et afgrænset forretningsområde.

Strategiske mål

Den fælleskommunale rammearkitektur er kommunernes fælles redskab til at balancere og nå de fem arkitekturmål:

• Sammenhængende it
• Genbrug
• Byg til forandring
• Flere leverandører
• Driftsstabilitet.

Rationale

Realiseringen af rammearkitekturens vision og målsætninger er et af de vigtige midler til at skabe sammenhængende, fremtidssikret og effektiv it, udviklet på et flerleverandørmarked – og derved realisere gevinster ved digitalisering.

Implikationer

• For at realisere rammearkitekturen er det nogle gange nødvendigt at foretage investeringer, hvor gevinsterne først vil kunne høstes på den lidt længere bane. Investeringerne skal balanceres, så der høstes på både kort og lang sigt, og for at kortsigtede investeringer ikke spænder ben for langsigtede gevinster. Vurdering af projektets brug af og overensstemmelse med rammearkitekturen medvirker til at kortlægge projektets både kort- og langsigtede konsekvenser.
• Kommunerne anvender den fælleskommunale rammearkitektur som overordnet ramme for investeringer i forretnings- og it-udvikling.
• Det enkelte projekt skal tage aktiv stilling til, hvordan det bruger rammearkitekturen, evt. bidrager til videreudvikling af rammearkitekturen og evt. afviger fra rammearkitekturen. Projekter vil sende feedback til arkitekturrådet, hvis der findes behov for justeringer eller udvidelser i rammearkitekturen.
• Projektets business cases indeholder en vurdering af investeringsbehov og gevinster på både kort og lang sigt. En kortsigtet business case er ikke nødvendigvis i modstrid med den langsigtede. Det kan fx være fordelagtigt med små løsninger, som anvendes midlertidigt, indtil den "rigtige" løsning kommer.

Konsekvens ved afvigelse

Konsekvensen ved at afvige er, at de fem arkitekturmål på sigt ikke realiseres.

Det betyder også:

• Større risiko for usammenhængende it, særligt på tværs af leverandører, og derved flere genindtastninger af samme data, ingen procesautomatisering etc.
• Større risiko for manglende genbrug af funktionalitet på tværs, hvorved flere it-systemer udfører de samme funktioner, så kommunerne betaler for udvikling og vedligehold flere gange.
• Større risiko for systemer der er ufleksible og svære at tilrette, når der sker ændringer i lov og organisation m.v.
• Udvikling af proprietære integrationer, som kan være dyre og svære at vedligeholde.
• Tilgang til og ændring af data gennem brugergrænseflader kan være systemafhængig og dermed svær at ændre.
• Kommunerne risikerer at udvikle løsninger, som på kort sigt løser et forretningsbehov, men som på længere sigt både bliver dyrere at vedligeholde og giver en dårligere understøttelse af forretningen.

A2. Arkitekturen skal sikre mod leverandør-”lock-in”

Beskrivelse

Når kommunerne har en defineret strategi for leverandørskifte, som indarbejdes i leverandørkontrakterne, maksimeres muligheden for kontinuitet i overgangsperioder. Herved bliver det nemmere at skifte mellem leverandører, og uventede omkostninger ved leverandørskift og udfasning kan nemmere undgås. Samtidig skal udvikling og drift holdes adskilt, så det bliver muligt at skifte driftsleverandør.

Strategiske mål

• Flere leverandører.

Rationale

Kommunerne kan have behov for at skifte leverandør for at sikre en fornuftig prisstruktur og skabe bedre rammer for innovation. Det kan være både dyrt og besværligt at flytte data mellem systemer, hvis det ikke er tænkt ind i designet fra starten. Kommunerne risikerer, at det ved et leverandørskifte bliver svært at tilgå data, som egentlig er kommunens ejendom. Det er derfor nødvendigt at stille krav til leverandørerne om, hvordan data kan overføres til en anden leverandør.

Implikationer

• Krav om en formuleret strategi for leverandørskifte kan gøre systemarkitekturen mere kompliceret.
• Dokumentation skal indeholde beskrivelse af eksport og import af løsningens informationer.
• Der skal udarbejdes særskilt udviklings- og driftskontrakt for at sikre, at disse dele kan sættes i udbud uafhængigt af hinanden.
• Der bør udarbejdes et sæt standardkrav til brug ved kommunernes udbud af it-systemer.

Konsekvens ved afvigelse

• Leverandørskifte – også som følge af påkrævet udbud – kan blive unødigt dyrt, have en negativ indvirkning på både drift og forretning, eksempelvis gennem reduceret tilgængelighed for borgere og medarbejdere.
• Det kan blive både svært og dyrt at eksportere og importere data i forbindelse med et leverandørskifte.

A3. It-sikkerhed tænkes ind i løsninger fra starten

Beskrivelse

Fortrolighed og it-sikkerhed er særdeles vigtig for den kommunale forretning. Hvis it-sikkerhed tænkes ind for sent i processen, får det ofte karakter af en “skal”, der lægges uden om it-systemet. I stedet bør it-sikkerhed være en integreret del af løsningen og imødekomme både brugernes og lovgivningens behov.

Strategiske mål

• Sammenhængende it.
• Driftsstabilitet.

Rationale

Det kræver indsigt i alle aspekter af en løsning at udarbejde det rigtige design, herunder it-sikkerhed. Når it-sikkerhed er en naturlig del af analysearbejdet, på lige fod med andre funktionelle behov, udfordres løsningen i forhold til den krævede sikkerhed, og sikkerhedskravene udfordres i forhold til forretningsbehovene.

Implikationer

• It-sikkerhed skal sættes på agendaen allerede i analysefasen.
• Der bør være en it-sikkerhedsekspert og juridisk ekspertise tilgængelig for projekterne.

Konsekvens ved afvigelse

• It sikkerhed bliver “påklistret” it-løsningerne i stedet for at blive en del af dem. Det fører ofte til meget ufleksible løsninger, hvor implementeringen af it-sikkerhed ikke er en naturlig del af løsningen og giver en oplevelse af dårlig brugervenlighed.
• It-sikkerhed som ikke er tilstrækkeligt tænkt ind i en løsning kan også føre til performanceproblemer.

B. Forretning

B1. Forretningsservices genbruges på tværs af it-løsninger

Beskrivelse

Når et it-projekt igangsættes, genbruges allerede eksisterende funktionalitet i form af forretningsservices.

Strategiske mål

• Sammenhængende it.

• Genbrug.

Rationale

Beskrivelsen af en forretningsservice definerer og specificerer entydigt en forretningsservice i form af informationer, processer og regler. Forretningsservicen er således ikke et stykke programmel, men en række specifikationer, der sammen danner model for den it, der skal udvikles for at understøtte den ønskede funktionalitet. Udvikling af it, der understøtter funktionaliteten i en forretningsservice skal leve op til disse ydre rammer. Derfor vil genbrug af forretningsservices på tværs af it-løsninger sikre, at der kan udvikles mod ensartede og standardiserede grænseflader, og at der kan anvendes velkendte operationer.

Det betyder endvidere, at de fysiske komponenter der implementerer en forretningsservice nemmere kan udskiftes.

Implikationer

• Ved nyudvikling bør der afsættes tid og ressourcer i it-projekter til for-analyse eller deciderede for-projekter, der identificerer:
  • allerede eksisterende forretningsservices der indgår i forretningsområdet og
  • potentialet for at det nyudviklede kan indgå som forretningsservice for andre.
• Den fysiske implementering af en forretningsservice skal leve op til den konceptuelle forretningsservice.
• Genbrug skal være muliggjort i udbud.
• Der skal tages højde for genbrug i kontrakten.
• Forretningsservices skal dokumenteres ensartet vha. en fælles obligatorisk model, udstilles offentligt og gennemgå en kvalitetssikringsproces.
• Alle anskaffelser skal kunne bruge/konsumere forretningsservices og udstille egen funktionalitet som services. Ligeledes vil det være naturligt, at der udvikles og vedligeholdes et overblik over tilgængelige forretningsservices.

Konsekvens ved afvigelse

Uden genbrug af forretningsservices bliver omkostningerne ved udvikling og/eller anskaffelse af it-løsninger højere, og projekterne bliver potentielt mere risikofyldte. Uklar eller manglende dokumentation af forretningsservices vil gøre samarbejdet mellem flere leverandører vanskeligt. Kommunerne vil have ringe mulighed for at koordinere udvikling. Denne uklarhed vil medføre øgede indirekte omkostninger på et projekt eller i en løsning. Mange leverandører vil være udelukket fra markedet.

B2. Arbejdsgange er dokumenterede på tværs af forretnings-domæner

Beskrivelse

En kommunal opgave vil ofte gå på tværs af fagdomæner og sågar på tværs af myndigheder: For brugerne (borgerne og virksomhederne) bør det fremstå som en samlet opgaveløsning, uanset hvordan kommunen har organiseret sig, og hvilke myndigheder der er indblandet. For at sikre denne sammenhæng er det nødvendigt, at hele opgaven er dokumenteret på tværs af domærnerne.

Strategiske mål

• Sammenhængende it.
• Genbrug.

Rationale

Det er en strategisk målsætning, at den offentlige sektor leverer en så god og sammenhængende service som muligt til borgerne, og at borgerne ikke oplever skel mellem arbejdsområder i det offentlige. At nå dette mål kræver, at det er præcist defineret, hvad der sker ift. proces- og ansvarsfordeling, når en opgave skifter domæne. En sådan definition vil sikre en smidig fortsættelse af arbejdet i andet regi og være med til at realisere ambitionerne om ”én indgang til det offentlige”.

Princippet gælder alle arbejdsgange, inkl. arbejdsgange lokalt i kommunerne, der går på tværs af områder eller muligvis kommunegrænser og overordnet for arbejdsgange, der går på tværs af den offentlige sektor.

Implikationer

• Arbejdsgangene og ikke mindst ansvarsskiftene skal identificeres og beskrives på en ensartet måde efter fælles metode og begrebsapparat.
• Det skal defineres, hvilke informationer der overdrages fra det ene forretningsområde til det næste.
• Der skal etableres en organisation af ansvarlige fagfolk, som har pligt til at sikre en altid opdateret dokumentation.
• Opgaveejeren har ansvaret for, at arbejdsgange er veldokumenterede, og at de udstilles og vedligeholdes.

Konsekvens ved afvigelse

Uden klare regler for overdragelse af opgaver, vil borgerne opleve sagsbehandling med gentagne afbrydelser. Der vil også være større risiko for, at ejerskabet af opgaver ikke er klart defineret med mangelfuld service til følge. Der er ligeledes større risiko for, at samme data registreres flere steder og dermed også større risiko for inkonsistente data.

B3. Brugere inddrages aktivt i behovsafklaring og udviklingsforløb

Beskrivelse

Når et forretningsområde analyseres, skal brugerne inddrages aktivt i problem-og løsningsformulering. Det sikrer, at det leverandørerne bygger, svarer til kommunernes forventninger. Kommunerne bør tilstræbe et iterativt udviklingsforløb, således at projektet (kommune og leverandør i fællesskab), kan blive klogere undervejs og dermed få præcise og tidssvarende it-løsninger, der dækker brugernes behov.

Strategiske mål

• Sammenhængende it.

Rationale

Kommunerne skal bygge løsninger til brugerne og til at understøtte de forretningsmæssige behov. Det skal sikres, at alle behovsaspekter er afdækket. På den måde får kommunerne it-løsninger, som dækker det konkrete behov.

Kommunerne skal dog stadig have rammearkitekturen og fællesbeslutninger for øje, således at sammenhæng til kommunernes øvrige it sikres.

Implikationer

• Brugere inviteres løbende til at komme med feedback i analyse- og kravfasen af et projekt.
• Der skal afsættes ressourcer til at opsamle og dokumentere brugernes behov.
• Brugerne skal inddrages i prioritering af kravene i kravspecifikationen.
• Brugerne skal inddrages i udviklingsforløbet i et projekt (fx gennem brugervenlighedstests og andre løbende afklaringer).

Konsekvens ved afvigelse

Kommunerne får løsninger, der ikke afspejler brugerens behov, og dermed vil brugerne heller ikke tage ejerskab til dem. Dermed risikerer kommunerne at foretage investeringer i it-løsninger, hvis gevinster ikke bliver indfriet i fuldt omfang.

B4. It-løsninger udfordrer og effektiviserer eksisterende arbejdsgange og regler

Beskrivelse

Udviklingen af kommunale it-løsninger vil ofte udfordre organisatoriske forhold, arbejdsgange, regler og lovgivning. Det er ikke rammearkitekturens opgave at ændre regler eller lovgivning; men eksisterende processer skal udfordres og optimeres, hvor det kan give et kvalitetsløft for borgere og virksomheder eller kan effektivisere den kommunale sagsbehandling.

Strategiske mål

• Byg til forandring.

Rationale

De kommunale arbejdsprocesser skal være fleksible og foranderlige i samme grad, som der stilles krav til, at it skal være det. Der skal være overensstemmelse mellem den måde forretningen tænker, og den måde it-leverandøren tænker. Under arbejdet med at udvikle nye it-løsninger, vil man ofte opleve forhindringer i form af love eller regler på området eller eksisterende arbejdsgange, der ikke fungerer optimalt.

Projektet bør udfordre disse regler og love samt effektivisere arbejdsgangene, der hvor der er behov for det.

Implikationer

• Organisatoriske og/eller lovgivningsmæssige udfordringer skal identificeres og beskrives, således at de relevante interessenter kan tage stilling til evt. ændringer. På den måde dannes grundlag for at gennemføre ændringer.
• Der skal være et tæt samarbejde med dem, der skriver love og regler, således at det er muligt at påvirke dette arbejde.
• Der skal udarbejdes en standard for beskrivelse af eksempelvis regler, således at risikoen for misfortolkning af lovens intentioner mindskes.

Konsekvens ved afvigelse

Identificeres det ikke, hvor arbejdsgange, love og regler giver problemer kan de forhindre projektet i at opnå de effektiviseringsgevinster, det ellers havde været mulige. Udfordres og ændres organisationen ikke, hvis det er nødvendigt, opnås ikke den fulde gevinst ved implementering af nye it-systemer.

B5. Der anvendes altid et standardiseret begrebsapparat

Beskrivelse

Udvikling af it-systemer baserer sig på en standardiseret beskrivelse af de informationer (forretningsdata), som systemerne håndterer. Generelle begrebsstandarder er ved at blive udarbejdet inden for forskellige domæneområder. Foreligger en sådan standard på domænet for et projekt, skal denne anvendes.

Hvor OIO standarder eller tilsvarende begrebsstandarder findes, anvendes de (eksempelvis grunddata-standarder eller OIO-XML skemaer).

Endvidere bør der anvendes internationale og nationale begrebsstandarder, hvor det er muligt.

Strategiske mål

• Sammenhængende it.
• Genbrug.
• Flere leverandører.

Rationale

Anvendelse af et standardiseret begrebsapparat medfører, at alle implicerede parter har samme forståelse af anvendte begrebers betydning (semantik). Dette gør samarbejde lettere og forbedrer kommunikation mellem parterne. Brug af fælles begreber er ikke kun en fordel i det tekniske arbejde, men for alle dele af et projekt. De tekniske snitflader udarbejdes ud fra de standardiserede beskrivelser og navngivning.

Implikationer

• Beskrivelserne udføres vha. standardiserede beskrivelsesmetoder. Fx beskrives begrebs- og informationsmodeller vha. UML klassediagrammer.
• Der skal etableres en organisation af fagfolk, som har pligt og ansvar til at sikre en altid opdateret dokumentation.
• It-projekter skal forholde sig til initiativer hos andre offentlige aktører, hvilket kan medføre øget tid til kravspecifikation og udvikling i projekter.
• Kommunale standarder skal harmoniseres mellem institutioner, initiativer og direktiver.
• Generelt foretrækkes internationale standarder og løsningselementer frem for nationale, og nationale frem for lokale.
• Kravet om brug af standarder medfører et behov for én samlet indgang til viden om fællesoffentlige standarder samt eksisterende initiativer, der eventuelt skal tages højde for. Brugen af de fælles standarder skal håndhæves gennem en fælleskommunal governancestruktur.

Konsekvens ved afvigelse

Uden standardiserede og forståelige begreber, er der stor risiko for, at parterne involveret i et projekt – og ikke mindst deres samarbejdsparter - ikke opnår enighed pga. forvirring vedrørende begrebers betydning. Ofte anvendes forskellige ord for samme begreb, mens det også sker, at samme ord anvendes med forskellig betydning. Det medfører øget risiko i it-projekter.

B6. Der er defineret entydigt ejerskab af data og processer

Beskrivelse

For at kunne genbruge processer og information på tværs af kommunens forvaltninger er det vigtigt, at man kan stole på de processer og data, der genbruges. De skal være entydige og korrekte. For at opnå det, skal der være et ejerskab til dem. Et ejerskab, der forpligter, men samtidig muliggør genbrug.

Rammearkitekturens forretningsservices udgør en enhed for ejerskab, som indeholder informationer(data), processer og regler for et afgrænset forretningsområde.

Strategiske mål

• Genbrug.
• Byg til forandring.

Rationale

Entydigt ejerskab forpligter den opgaveansvarlige til at beskrive og vedligeholde beskrivelsen af forretningsservicen (data, processer og regler), således at fx integrationer og afhængigheder ift. andre løsninger og arbejdsgange er nemt gennemskuelige.

Implikationer

• Det skal defineres meget klart, hvem der ejer forretningsservices (inkl. data og processer), fx indenfor ydelsesområdet. KL har en centralt koordinerende rolle og har ansvaret for den fælleskommunale rammearkitektur.
• Der bør oprettes en fælles oversigt over ejerskab for fælleskommunale processer.
• Entydigt ejerskab betyder, at kun den procesansvarlige aktør kan ændre i proces-, data og regelbeskrivelserne. Uddelegeres denne opgave, er det vigtigt, at opgaveejeren beholder ansvaret for beskrivelser og definitioner og godkender det uddelegerede arbejde.

Konsekvens ved afvigelse

Er ejerskabet for forretningsservices ikke defineret, findes der heller ikke entydigt ansvar for vedligeholdelse af dokumentation og beskrivelser. Dette vil føre til problemer med genbrug. Det fører igen til, at forskellige leverandører og it-projekter bygger deres egen udgave af en given proces i stedet for, enten at genbruge en, der allerede er bygget eller bygge en efter de korrekte specifikationer.

B7. Enhver betydelig forretningshændelse meddeles omverdenen

Beskrivelse

Forretningshændelser skal meddeles omverdenen, således at der kan ageres på det i andre it-systemer. En forretningshændelse kan eksempelvis være ”person xx har fået oprettet en dagpengesag”.

Strategiske mål

• Sammenhængende it
• Flere leverandører.

Rationale

Med adgang til meddelelser om forretningshændelser kan omverdenen – som eksempelvis kan være andre leverandørers løsninger - agere på en opstået situation. Derved opnås en reel løs kobling mellem de it-systemer en kommune anvender på tværs af domæner og på tværs af leverandører.

Indførelsen af denne måde at kommunikere på, vil ændre den måde kommunerne tænker it-systemer på.

Implikationer

• For at kunne se fordelene ved at gøre et it-system i stand til at udsende hændelser, kan det være nødvendigt at inddrage data fra de modtagende parter af en forretningshændelse i en business case. På den måde minimeres risikoen for, at it-systemet analyseres isoleret, og at åbenhed omkring udsendelse af forretningshændelser vurderes udelukkende som en omkostning.
• Kan betyde stort arbejde med at rette alle eksisterende services, der ikke baseres på Event Driven Architecture. Det er derfor vigtigt at gøre det, hvor det giver forretningsmæssig værdi.
• En standard for hændelsesbeskeder skal vedtages.
• En standard for at definere et abonnement skal vedtages.
• Hændelsesbeskeder skal udstilles og gøres tilgængelige for andre.

Konsekvens ved afvigelse

Et mere heterogent leverandørlandskab, hvor kommunerne kan lade forskellige leverandører deles om end-to-end processen vha. løst koblede systemer, vil være vanskeligere at opnå. Det vil det være vanskeligere at udskifte leverandører, da kommunikationen i højere grad foregår via punkt-til-punkt udvekslinger.

B8. Fælles autoritative reference- og grunddata anvendes

Beskrivelse

It-løsninger i kommunerne bør anvende fælles autoritative referencedata (fx KLE, FORM, m.m.) samt grunddata (CPR, CVR, BBR, m.m.).

Strategiske mål

• Sammenhængende it.
• Genbrug.
• Flere leverandører.

Rationale

• Brug af fælles referencedata muliggør en sikker og entydig udveksling af informationer og overflødiggør dyre dobbeltregistre. Ved at opmærke med og henvise til fælles referencedata opnås langt bedre muligheder for kommunikation og genbrug af data.
• Etablering af en fælles referenceramme (vha. fælles referencedata) sikrer et fælles grundlæggende sprog.
• Anvendelse af fælles grunddata som en fælles autoritativ kilde sikrer pålidelige og opdaterede data.

Implikationer

• Leverandører af kommunale it-løsninger skal kende standarderne og være i stand til at bruge dem.
• Der skal etableres hurtige og pålidelige dataforbindelser til grunddata.
• Der skal være en stærk governance omkring både grund- og referencedata, da data skal være pålidelige og opdaterede.

Konsekvens ved afvigelse

Uden anvendelse af fælles definitioner af data og brug af standarder vil der ikke kunne foretages integrationer og udveksling af data på en enkel måde, hvilket vil have negativ indflydelse på de strategiske mål om mere sammenhængende kommunal it (dyre dobbeltregistre, redundante oplysninger, misforståelse af data etc.).

B9. Adskil det foranderlige fra det uforanderlige

Beskrivelse

Når et forretningsområde analyseres, skal der lægges vægt på at adskille de dele af processerne, som ændrer sig ofte, fra de dele af processerne, som ændrer sig sjældent. Dette sikrer en robusthed overfor eksempelvis lovændringer.

Strategiske mål

• Byg til forandring.

Rationale

I dag oplever kommunerne løsninger, hvis adskillelse af funktionalitet og data ikke er stringent, og hvor regler og data fx er indbygget i koden. Dette giver problemer ved ændringer i lovgivning og arbejdsprocesser, idet ændringer i systemerne må foretages gennem udviklingsarbejde. Det er derfor et mål for kommunerne at anskaffe løsninger med klar adskillelse af arkitekturlag (fx brugergrænseflader, forretningsregler/workflow og data).

Implikationer

• Der skal fokuseres på en opdeling i arkitekturlag allerede i analysen af forretningen.
• Denne opdeling skal videreføres i applikationsdesignet. Ved at vide, hvilke dele af forretningen der ændres ofte, og hvilke dele der ændres sjældent, vil det være muligt at udvikle løsninger med indbygget forandringsparathed. Dvs. at ændringer i eksempelvis loven ikke fører til omfattende udviklingsprojekter, men i stedet kan håndteres gennem ændringer af konfigurationer.
• Kravspecifikationen skal definere, hvad der er foranderligt, og hvad der ikke er.
• Omkostningerne ved løsninger der kan konfigureres, kan være højere. 
• Problemer med at forudse, hvad der vil ændre sig, og hvad der ikke vil, kan gøre det svært at efterleve princippet.

Konsekvens ved afvigelse

Kommunerne fortsætter, som hidtil, med monopolitiske silosystemer, hvor regler og forretningsgange er defineret som programmeret kode. Konsekvensen er dyre udviklingsprojekter ved lov- eller procesændringer.

C. Teknik

C1. Data udstilles via åbne snitflader og kan genbruges

Beskrivelse

Relevante forretningsdata skal stilles til rådighed gennem åbne snitflader, bygget på fælles begrebsmodeller (se B5. Der anvendes altid et standardiseret begrebsapparat).

Strategiske mål

• Sammenhængende it.
• Genbrug.
• Flere leverandører.

Rationale

Adgang til data vil skabe grobund for innovation. Ved at bruge de informationer, kommunerne allerede har, vil nye aktører kunne konkurrere på markedet og bygge nye applikationer og services.

Herudover vil en åben adgang til data sikre sammenhængende it, ved at data hentes der, hvor de er skabt i stedet for at blive lagret lokalt, hvilket kan føre til, at brugere bliver bedt om at indtaste samme data flere gange.

Implikationer

• Krav om udstilling af data bør indgå i kravspecifikationen.
• Krav om opdaterede datakataloger og informationsmodeller med en høj kvalitet i den semantiske definition.
• Der skal formuleres retningslinjer for, hvorledes adgang til data skal etableres.
• Antallet af lokale dataregistre skal begrænses så vidt muligt. I det omfang der gemmes lokale kopier, skal tilknyttede applikationer opdatere data med den hyppighed, forretningen fordrer.
• Data har kun én ejer med entydigt ansvar for vedligeholdelse (se B6. Der er defineret entydigt ejerskab af data og processer).
• Alle objekter har kun én master, der til gengæld skal være replikérbar. Replikering skal foregå efter en fastlagt procedure.
• Data skal udstilles via snitflader bygget på åbne standarder.
• Udstillet data skal beskrives og dokumenteres i fællesoffentlige datakataloger, fx på digitaliser.dk.

Konsekvens ved afvigelse

Uden udstilling af data gennem åbne snitflader opnås der ikke maksimal udnyttelse af de kommunale data, og vedligeholdelse af data bliver dyrt. Data ”låses” hos de enkelte leverandører, og kan ikke anvendes til bedre service eller innovation.

C2. Alle objekter er uafhængige af systemet, hvor de er skabt

Beskrivelse

Forekomster af et forretningsobjekt må ikke begrænses af det system, de aktuelt er opbevaret i. Fx skal en sag kunne overføres fra en it-løsning til en anden. Det betyder, at forekomster af et forretningsobjekt og dets relationer skal kunne eksporteres og importeres i en ny it-løsning.

Strategiske mål

• Byg til forandring.
• Flere leverandører.

Rationale

Oplysninger om de forretningsobjekter, der håndteres i kommunens arbejdsgange eksisterer uafhængigt at den it, der aktuelt behandler dem. Det er de samme objekter, der behandles og de samme oplysninger om disse forretningsobjekter, der er behov for, uanset om arbejdsgangen er it-understøttet eller ej. Behovet er således uafhængigt af, hvilken konkret it-løsning, forretningsobjekterne findes og behandles i.

Uafhængigheden opnås som følge af en fælles standard for objektet og dets attributter samt en global unik identifikation. Princippet vil understøtte samarbejde på tværs af systemer og domæner samt mindske problematikker ift. leverandør “lock-in” (se A2. Arkitekturen skal sikre mod leverandør-”lock-in”).

Implikationer

• Opgaveejeren får ansvaret for, at forretningsobjekter kan anvendes på tværs af it-systemer, hvor det er nødvendigt.
• Når en instans af et forretningsobjekt opstår, skal der tildeles en global unik identifikation, som bruges gennem hele instansens levetid uanset den aktuelle opbevaring. Det betyder, at forretningsobjekter kan importeres og eksporteres på tværs af systemer. Eksempelvis vil en sag kunne flyttes mellem ESDH-systemer og stadig have samme entydige reference.
• Enighed om standarden for objekters identifikation og en fælles opfattelse af objektets indhold er nødvendig.
• Forekomster af et objekt skal både kunne eksporteres fra en it-løsning og importeres i en anden.

Konsekvens ved afvigelse

Manglende unikt ID kan medføre problemer med kompatibilitet mellem systemer. Hvis eksempelvis en sag tildeles en identifikation lokalt i et givent ESDH-system, vil den blive opfattet som en ny sag, blot fordi den flyttes til et nyt system. Flyttes den tilbage til det oprindelige system, vil dette system ikke kunne identificere, at der i virkeligheden er tale om det samme objekt, og der vil blive oprettet en parallel forekomst af sagen.

Manglende overholdelse af fælles vedtagne standarder, der beskriver et forretningsobjekts indhold, fører til inkonsistente data på tværs af it-systemer.

C3. Data identificeres entydigt

Beskrivelse

Alle forretningsobjekter bør have én teknisk nøgle, der er uforanderlig. Objektet kan dog samtidig have et ubestemt antal brugervendte nøgler, der skal kunne ændres. Tekniske nøgler er globalt unikke. Dvs., at der ikke findes andre objekter med samme id. Brugervendte nøgler er unikke indenfor samtlige forekomster i samme kontekst.

Strategiske mål

• Genbrug.
• Byg til forandring.

Rationale

Unikke tekniske nøgler er en forudsætning for udveksling af forretningsobjekter. Foranderlige brugervendte nøgler (som dog stadig er unikke) sikrer, at brugerne af et it-system lettere kan forholde sig til nøglen, og dermed letter det brugen af systemet. Ofte er brugervendte nøgler genereret ud fra de data, som objektet beskriver. Eksempelvis indeholder et personnummer information om fødselsdato og køn. Ændrer en persons fødselsdato eller køn sig, vil den tekniske nøgle være uforandret (det er jo den samme person), mens den brugervendte nøgle er ændret.

Implikationer

• Der skal vælges en standard for globale unikke nøgler (UUID).
• Ændring af en brugervendt nøgle kommunikeres på samme måde som en ændring af andre attributter.

Konsekvens ved afvigelse

Registre i forskellige systemer vil indeholde forskellige nøgler for den samme instans af et objekt. Det vil derfor være nødvendigt at rense data ofte og udveksling af data vil være dyrt og i nogle tilfælde umuligt.

C4. It-løsninger er skalerbare efter formål

Beskrivelse

It-løsninger skal være skalerbare. Det vil sjældent være sådan, at it-løsninger opnår deres fulde anvendelse fra dag 1 og derfor skal, især driften, kunne skaleres. Især når it-løsninger begynder at genbruge funktioner fra allerede udviklede løsninger på tværs af fagområder, vil der opstå et øget ressourcetræk.

Strategiske mål

• Driftstabilitet.

Rationale

Kommunerne vil gerne væk fra monolitiske systemer og hen imod genbrug af både funktionalitet og data. Dette vil betyde flere integrationer på tværs af leverandører og dermed potentielt større behov for skalerbare løsninger. Skalerbarhed er derfor en vigtig egenskab, der vil imødegå dårlig performance og flaskehalsproblemer.

Implikationer

• Skalerbarhed skal være en del af driftsaftaler.
• Skalerbarhed skal tænkes både vertikalt (udvidelse af kapacitet på samme logiske enhed) og horisontalt (muligheden for at køre flere instanser af samme logiske enhed parallelt).
• Applikationer skal udvikles til at være skalerbare.

Konsekvens ved afvigelse

Større risiko for dårlig performance og systemnedbrud, med reduceret brugertilfredshed og reduceret tillid til systemerne til følge.

C5. It-løsninger er robuste overfor egne og andre systemers nedbrud

Beskrivelse

Ved fejl i integrationer, skal applikationen kunne fortsætte i de dele, der ikke direkte er relateret til den fejlramte integration. I forlængelse heraf skal der være en høj grad af logning/overvågning, således at tegn på nedbrud identificeres tidligt.

Strategiske mål

• Driftsstabilitet.

Rationale

Robuste applikationer har mindre nedetid, og derved mindre spildtid.

Implikationer

• Driftsstatus og fejlrapportering skal foregå på en ensartet måde for at øge overblik og stabilitet. Ensartet rapportering er en forudsætning for at kunne monitorere og styre driftsstabiliteten af de kommunale forretningsapplikationer effektivt. Ensartet rapportering giver også bedre mulighed for at sammenligne leverandører og stille bedre krav.
• Det kan overvejes at anvende proxyer og redundante data tæt på løsningerne (i samme driftsmiljø) for at sikre oppetid. Redundans kræver opmærksomhed på opdatering af de redundante data fra kilden.
• Applikationer og integrationer skal være veldokumenterede. Der bør udvikles en standard som sikrer, at applikationer og integrationer dokumenteres på samme form, så de kan sammenlignes.
• Det forudsætter et stort kendskab til data og integrationer. Der stilles store krav til leverandørsamarbejdet. Komplekse applikationer kan give kompleks infrastruktur.
• Der skal sikres tilstrækkelig kapacitet på udgående køer, så længere driftsforstyrrelser hos modtageren ikke giver datatab.
• Transaktioner skal opbygges, så informationstab undgås i tilfælde af fejl.
• ”Two phase commit” bør så vidt muligt undgås, da det giver kompleksitet i driften.

Konsekvens ved afvigelse

• Uden robuste applikationer risikeres det, at fejl i en del af en applikation såsom brugerautentificering, kommer til at påvirke den samlede tilgængelighed.
• En manglende gennemsigtighed i afrapportering om drift kan give et forkert billede af en applikations tilgængelighed. Uden kendskab til applikationen og forudsætningerne, kan man risikere, at driftsstabiliteten forringes for en applikation. Uden standardiserede data om driftsstabilitet bliver det sværere at sammenligne løsninger og at udfordre leverandørerne i kontraktforhandlinger.

Sammenhæng mellem Arkitekturprincipper og -mål

Det enkelte princip understøtter som oftest flere af de fem Tidligere Fælleskommunale Arkitekturmål - nedenstående tabel angiver hvilke arkitekturmål, princippet understøtter.