tjekliste_til_fods-arkitekturreview_version_1.2
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

View only
 
ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
Princip/regelImplikationerGrundlagSpørgsmål til review / compliancevurderingReview-
vurdering af relevans for projektet
Review-
vurdering af projektets opfyldelse
Anbefalings-
type
Noter / Anbefaling
2
Styring
3
Princip 1: Arkitektur styres på rette niveau efter fælles rammerEr der det fornødne fokus på tværgående styring?
4
AR1.1: Styr arkitekturen på rette niveauer og sammenhængende
Arkitektur fastlægges så lokalt og tæt på opgaven som muligt, dvs. i de enkelte myndigheder eller domæner. Hvor der er fælles mål og behov for det laves arkitektur, som forbinder disse. Det indebærer samarbejde og aftaler på tværs af domæner og beslutningsniveauer.
•Et klart ansvar for projekters arkitekturleverancer forankres i projektets styregruppe og ledelse.
•Projekter identificerer tidligt de dele af projektet, der stiller krav til interoperabilitet og tværgående arkitektur. Det er fx tværgående processer, datadeling eller fælles komponenter, der skal fungere eller anvendes på tværs.
•De dele af arkitekturen, der er en forudsætning for det tværgående samarbejde aftales med de relevante parter. Det kan fx være en fælles logisk datamodel, som de involverede domæner og aktører kan mappe deres egne fysiske datamodeller til uden at skulle ændre deres interne datamodeller.
•Styring af tværgående arkitektur respekterer, at der hvor nødvendigt kan anvendes domænespecifikke sprog, datamodeller og standarder.
•Den fælles arkitektur specialiseres og profileres, hvor der er behov for det, og hvor det giver ekstra værdi. Det gælder fx både principper og tekniske specifikationer. Dog skal det sikres, at dette ikke modvirker overordnede behov for tværgående interoperabilitet.
Er der styr på hvilke dele af projektets arkitektur der skal styres i dialog med andre parter og processerne for dette?
5
AR1.2: Optimér arkitektur efter projektets og de fælles mål
Projekters arkitekturleverancer optimeres ikke blot med henblik på projektets egne mål, men også under hensyn til de strategiske mål om sammenhæng og effektivitet med borgere og virksomheder i centrum. Projekter skal således bidrage til en udvikling af en stadig mere digitalt sammenhængende offentlig sektor, der deler data og har et stadigt mere sammenhængende it-landskab.
• Hvis der er modstrid mellem et projekts behov og den fælles arkitekturs krav, dokumenterer projektet dette med argumentation for, hvorfor man ikke følger tværgående hensyn og den fælles arkitektur.
• Hvis der er en finansieringsmæssig udfordring (en ”høste-så problematik”), eskaleres problemstillingen til behandling på højere niveau.
Er der styr på projektets udfordringer i forhold til at følge den fælles arkitektur, er det dokumenteret og er der evt. søgt afklaring af finansielle udfordringer?
6
AR1.3: Anvend fælles ramme for beskrivelse af arkitekturen
Projekter udarbejder arkitekturleverancer efter den fællesoffentlige dokumentationsramme, som udpeger krav til arkitekturbeskrivelser, som skal indgå i projektstyringen og i forbindelse med arkitektur-review. Det gør det nemmere at skabe overblik og analysere, udarbejde, reviewe, godkende og anvende dokumentation på tværs af aktører.
• Projekter udarbejder relevant og aftalt arkitekturdokumentation efter den fællesoffentlige dokumentationsramme til kvalitetssikring i forbindelse med dialog med interessenter, arkitektur- og projekt-review og eventuelle høringer.
• Projekter udstiller og deler arkitekturdokumentationen, således at andre kan få adgang til denne og genbruge relevante dele.
https://arkitektur.digst.dk/node/18/

https://arkitektur.digst.dk/node/563
Er der styr på hvilke arkitekturprodukter projektet skal lavere og hvornår i hvilken kvalitet?
7
AR1.4: Sørg for at projektets arkitektur reviewes
Projekters arkitekturleverancer kvalitetssikres efter den fællesoffentlige ramme for arkitektur-review, der beskriver proces, roller, ansvar og formater for review, afrapportering samt beslutninger.
• Det afklares tidligt om og hvornår et projekt skal gennem arkitektur-review. For at undgå tilbageløb bør review ske allerede i idé- og analysefasen. Efter behov kan der også ske review i senere faser.
• Projekter udarbejder aftalt dokumentation til grund for review. Her tages der udgangspunkt i den fælles dokumentationsramme.
• Projektets styregruppe behandler review-rapporten og tager stilling til reviewets anbefalinger.
https://arkitektur.digst.dk/node/190Er der styr på om og og i givet fald hvornår projektets arkitektur skal reviews?
8
AR1.5: Hav tilstrækkelige kompetencer til arkitekturarbejdet
Evnen til at arbejde med arkitektur skal betragtes som en del af en organisations modenhed på linje og i sammenhæng med evnen til at styre projekter, leverandørrelationer og drift. Derfor skal digitaliseringsprojekter bemandes med ressourcer, der har tilstrækkelig kompetence og viden til at sikre at arkitekturprodukterne har den kvalitet, som projektet kræver.
• Projekter planlægger hvilke produkter, der kræver arkitekturfaglige kompetencer, hvornår de skal udarbejdes og hvem der skal udarbejde dem.
• Projektejer sikrer, at projektet har adgang til de nødvendige ressourcer med de rigtige arkitekturkompetencer til rådighed på rette tidspunkt i projektforløbet.
https://arkitektur.digst.dk/node/511/
9
Strategi
10
Princip 2: Arkitektur fremmer sammenhæng, innovation og effektivitetEr der det fornødne fokus på sammenhæng?
11
AR2.1: Anvend og udbyg den fællesoffentlige rammearkitektur
Digitaliseringsprojekter anvender den fællesoffentlige rammearkitektur og tilhørende referencearkitekturer, byggeblokke og specifikationer for at fremme sammenhæng, innovation og effektivitet.
• I udformningen af deres forretnings- og it-arkitektur tager projekter udgangspunkt i den fællesoffentlige rammearkitektur, herunder de relevante referencearkitekturer og byggeblokke samt de fællesoffentlige tekniske standarder og infrastrukturkomponenter som fx NemID/MitID og NemLog-in.
• Projekter med ansvar for udvikling og realisering af dele af den fællesoffentlige rammearkitektur, fx en referencearkitektur, en standard eller en teknisk komponent, medvirker til at sikre at der er en plan og ansvar for fremtidig styring, drift og vedligeholdelse.
https://arkitektur.digst.dk/node/17Hvordan forholder projektet sig til anvendelse af og bidrag til den fælles rammearkitekturs retningslinjer og byggeblokke?
12
AR2.2: Anvend åbne og internationale standarder
Offentlige digitale løsninger bygger så vidt muligt på internationale specifikationer og standarder, der modsvarer de konkrete behov og om er åbne, udbredt internationalt og sikret vedligeholdelse.
Ved at bygge på internationale standarder og specifikationer kan Danmark høste gevinster af det internationale standardiseringsarbejde, som ofte kræver mange ressourcer. Når internationale standarder og specifikationer er åbne og modne, øges mulighederne for, at der er flere leverandører og produkter og dermed øget konkurrence, innovation og lavere priser. Når der anvendes internationale standarder, herunder særligt fælleseuropæiske standarder, øges mulighederne for international interoperabilitet.
• Som udgangspunkt anvendes åbne, internationale standarder og specifikationer. Dette skal altid bero på en konkret vurdering.
• Hvor nødvendigt udvikles danske profiler på internationale standarder og specifikationer. Hvor det er relevant, oversættes standarder til dansk.
https://arkitektur.digst.dk/node/17Følger projektet retningslinjer for valg, udvikling og vedligehold af standarder og profiler på standarder?
13
AR2.3: Undgå afhængighed af leverandører og proprietære teknologier
Offentlige myndigheder skal så vidt muligt undgå tekniske løsninger, der skaber bindinger til specifikke leverandører og til proprietære teknologier og produkter. Dette medvirker også til at udvikle et marked, hvor flere leverandører kan konkurrere om at levere systemer og services innovativt, billigt og fleksibelt til den offentlige sektor, og hvor der både er plads til standardløsninger og moduler fra flere leverandører baseret på åbne snitflader.
• I forbindelse med nyanskaffelser og videreudvikling af it-løsninger stilles så vidt muligt krav om anvendelse af åbne standarder med stor udbredelse, der er uafhængige af bestemte leverandører, teknologier eller produkter.
• Hvor det er relevant anvendes bæredygtige open source komponenter.
• Der sikres aftalemæssige og tekniske rammer for, at der senere kan skiftes til en anden leverandør, herunder at data er dokumenteret og kan trækkes ud af it-løsningen.
Sikrer kravspecifikation og kontrakt uafhængighed af leverandører og proprietær teknologi?
14
AR 2.4: Byg forandringsparat med udgangspunkt i brugeren
Offentlig digitalisering skal være værdiskabende og skabe rum for innovation og effektivisering. Derfor skal udviklingen af løsninger tilrettelægges, så er er optimale muligheder for at skabe nye løsninger på konkrete behov og for at tilpasse og udskifte løsninger, når de forretningsmæssige og rugernes behov eller de teknologiske muligheder skifter.
• Brugerne inddrages fra starten og løbende i forbindelse med udvikling og test af nye løsninger.
• Løsninger udvikles, hvor det er relevant og muligt iterativt efter agile metoder, således at der løbende kan læres, prioriteres og justeres, hvor der er behov for det.
• Nye løsninger opdeles, hvor det er relevant og muligt, i mindre moduler med snitflader baseret på åbne standarder, således at det enkelte modul nemt kan udskiftes.
https://digst.dk/digital-service/brugeroplevelse/Har projektet inddraget brugerne og sikret at løsningen kan videreudvikles efter nye behov?
15
AR 2.5: Stil data og løsninger til rådighed for private
Offentlige data og it-services er aktiver, som i mange tilfælde kan skabe værdi for samfundet udover det oprindelige formål. Derfor bør de stilles til rådighed for private, hvor det er relevant og muligt.
• Projekter skal tidligt vurdere mulighederne for at data, it-services og komponenter stilles til rådighed for private
• Hvis det besluttes, at dele data, it-services eller komponenter laves en plan for at håndtere eventuelle barrierer af økonomisk, organisatorisk, juridisk eller teknisk karakter.
https://www.retsinformation.dk/Forms/R0710.aspx?id=163488

https://joinup.ec.europa.eu/sites/default/files/custom-page/attachment/2017-10/sharing_and_reuse_of_it_solutions_framework_final.pdf
Har projektettaget stilling til deling af data og tekniskeløsninger med private?
16
Jura
17
Princip 3: Arkitektur og regulering understøtter hinandenEr der det fornødne fokus på juridiske bindinger?
18
AR3.1: Tag højde for juridiske bindinger i forhold til deling og genbrug af data og it-systemer
Arkitekturarbejdet sikrer, at gældende regulering overholdes, identificerer problemstillinger vedr. juridiske bindinger i forhold til tværgående processer, datadeling og genbrug af it-systemer samt giver løsningsforslag til disse problemstillinger.

Digitale løsninger skal følge loven, men som følge af digitaliseringen opstår også nye muligheder for at indrette den offentlige sektor på en mere hensigtsmæssig måde eller at regulere på en bedre måde. Derfor skal arkitekturen også anvendes til at udvikle nye og bedre muligheder for regulering og lovgivning.
• Projekter sikrer, at der er taget højde for gældende dansk lovgivning, herunder forvaltningsloven, arkivloven og relevant EU-regulering.
• Projekter identificerer som led i arkitekturarbejdet problemstillinger i forhold til datadeling og genbrug af data og it-services samt opstiller løsningsforslag, der sikrer, at forretnings- og it-arkitekturen overholder juridiske bindinger, og hvor det er relevant, opstiller forslag til ændring af disse.
https://www.datatilsynet.dk/generelt-om-databeskyttelse/lovgivning/Er der taget højde for juridiske bindinger i lovgivning, udbudsbekendtgørelse, kjontrakter o.l. som har betydning for tværgående processer, deling af data eller genbrug af it-komponenter og it-services?
19
AR3.2: Bidrag til digitaliseringsklar lovgivning
Arkitekturen i digitaliseringsprojekter skal, hvor det er relevant, bidrage til fremover at skabe et bedre grundlag for digitaliseringsklar lovgivning, fx ved at skabe klarhed om de processer, regler og informationer, der indgår i den fælles opgaveløsning og ved den it-løsning, der anvendes.

Hvor der identificeres uhensigtsmæssige barrierer for digitalisering i lovgivningen eller i regler for sagsbehandling o.l., skal projekter bidrage til at udfordre lovgivningen og reglerne med relevante løsningsforslag.
• Projekter skal være opmærksomme på, om der er uhensigtsmæssige krav til anvendelse af bestemte teknologier i lovgivningen, som fx hæmmer områdets teknologiske dynamik og muligheder for innovation.
https://digst.dk/afbureaukratisering/digitaliseringsklar-lovgivning/Har projektet identificeret uhensigtsmæssige barrierer og darresseret disse på en relevant måde?
20
Sikkerhed
21
Princip 4: Sikkerhed, privatliv og tillid sikresEr der det fornødne fokus på sikkerhed og privatliv?
22
AR4.1: Opfyld krav til informationssikkerhed og privatlivsbeskyttelse
Når der etableres digital understøttelse af tværgående processer og deling af data sker det på baggrund af en gennemarbejdet og fyldestgørende sikkerhedsmodel. Informationssikkerhed skal være et integreret element lige fra udbudsproces til go-live af systemer.
• Projekter foretager tidligt en risikovurdering og en vurdering af konsekvenserne for privatlivets fred og informationssikkerheden i overensstemmelse med de lovgivningsmæssige og fællesoffentligt aftalte krav hertil.
• Hvis cloud computing er en del af projektet tages højde for de særlige krav hertil.
• Den digitale løsning designes således, at privatlivsbeskyttelse og sikkerhed sikres, herunder at kun nødvendige følsomme data udveksles og opbevares.
https://digst.dk/sikkerhed/vejledninger-til-sikkerhedsarbejdet/konsekvensvurdering-for-privatlivet/

https://sikkerdigital.dk/

https://www.iso.org/isoiec-27001-information-security.html
Er der styr på håndtering af hensyn til privacy og informationssikkerhed?
23
AR4.2: Anvend fælles arkitektur for informationssikkerhed
Forudsætningen for, at der kan skabes sammenhængende brugerrejser og tværgående arbejdsprocesser og datadeling på tværs af domæner, er, at sikkerhed
håndteres på en sammenhængende måde, herunder at håndtering af brugerrettigheder, sikkerhedsprocesser, sikkerhedsmodeller og infrastrukturkomponenter
er sammenhængende og interoperabel.
• Projekter tager udgangspunkt i den fællesoffentlige referencearkitektur for brugerstyring, der fastsætter rammerne for, hvordan offentlige myndigheder skal arbejde med digital brugeradministration og adgangskontrol.
• Projekter sikrer, at der ved tværgående processer aftales og anvendes sikkerhedsmodeller, der håndterer sikkerhed på tværs af domæner.
https://www.iso.org/isoiec-27001-information-security.htmlAnvendes fælles arkitektur for informationssikker, herunder bruger og rettighedsstyring?
24
Opgaver
25
Princip 5: Processer optimeres på tværs Er der det fornødne fokus på brugere og processer?
26
AR5.1: Design sammenhængende brugerrejser
Digitale services designes med brugeren som udgangspunkt og med et kendskab til hele processen, således at brugeren oplever en god, nem og sammenhængende service også på tværs af myndigheder.
• Projekter sikrer, at udviklingen af digitale løsninger tager udgangspunkt i en identifikation og forståelse af relevante brugerrejser i forbindelse med brugernes opgaver.
• Projekter analyserer både brugerrejser og brugeroplevelser med henblik på at optimere de digitale services, så de er intuitive, effektive og sammenhængende.

https://digst.dk/digital-service/brugeroplevelse/Har I inddraget brugerne og klarlagt de optimale brugerrejser?
27
AR5.2: Optimér tværgående processer efter fælles mål
Tværgående processer optimeres med udgangspunkt i fælles mål for sammenhængende, effektive og værdiskabende arbejdsgange.
• Projekter optimerer de tværgående processer ud fra de fælles mål for hver proces og dokumenterer dem efter aftalt metode, inklusive relevante hændelser, aktiviteter og beslutningsregler i processerne. Dokumentation udstilles
og deles, så den kan genbruges, hvor processer er generiske og kan implementeres i flere organisationer.
• Projekter sikrer, at de berørte myndigheder opstiller et sæt af fælles kvalitetsmål og målepunkter, som skal være styrende for, hvordan aftalte tværgående processer optimeres. Fx vedr. kvalitet, ressourceforbrug, ventetid, gennemløbstid og konkrete krav til aktiviteter. Der udarbejdes aftaler, der tydeliggør, hvem der har ansvar for hvad i de tværgående processer.
https://arkitektur.digst.dk/node/563Har I analyseret, optimeret og dokumenteret tværgående processer samt sikret at deltagende myndigheder har opsat relevante kvalitetsmål?
28
Information
29
Princip 6: Gode data deles og genbrugesEr der det fornødne fokus på datadeling?
30
AR6.1: Del og genbrug data
Hvis egnede data skabes eller indsamles af én myndighed, skal de i videst mulig omfang genbruges af andre myndigheder, hvis det er lovmedholdeligt og praktisk muligt. Borgere og virksomheder skal ikke belastes unødigt med at aflevere de
samme oplysninger til det offentlige flere gange.

Som udgangspunkt for beslutninger om deling og genbrug vurderer projekter i analysefasen potentialer og begrænsninger. Vurderingen foretages fx ud fra, om der er tale om personhenførebare eller fortrolige data, om data har karakter af master data, eller om der er tale om transaktionsdata eller midlertidige data, om der er tale om små eller store mængder data, om data er simple eller komplekse osv.
• Projekter, der skal bruge nye data, undersøger om tilsvarende data allerede indsamles af andre myndigheder eller virksomheder. Hvis andre indsamler stort set tilsvarende data, undersøges det, om der kan laves en fælles indsamling og kvalitetssikring af data.
• Projekter sikrer, at relevante myndigheder stiller relevante data til rådighed for relevante parter.
• Hvor der er behov for det, laves der en klar aftale om ansvar i forhold til indsamling, dokumentation, udstilling, opdatering og anvendelse af data.
https://arkitektur.digst.dk/node/611

https://arkitektur.digst.dk/node/618

https://www.retsinformation.dk/Forms/R0710.aspx?id=163488

https://joinup.ec.europa.eu/sites/default/files/custom-page/attachment/2017-10/sharing_and_reuse_of_it_solutions_framework_final.pdf
Er der styr på muligheder og begrænser for deling af data og at disse håndteres?
31
AR6.2: Anvend fælles regler for dokumentation af data
For at fremme genbrug af data beskrives data og begreber efter fælles regler. Det er nødvendigt for at sikre, at data forstås korrekt og passer sammen, når de anvendes på tværs af myndighedernes forskellige processer og it-systemer.
• Projekter anvender de fællesoffentlige regler for begrebs- og datamodellering til at beskrive den semantiske betydning og modellering af data. Reglerne understøtter, at der skabes sammenhæng fra begreberne i lovgivningen til data, der udstilles via et it-systems snitflader.
• Projekter beskriver deres data og begreber så fyldestgørende, at de kan forstås og genbruges i andre sammenhænge.
https://arkitektur.digst.dk/node/81/Har projektet fulgt regler for dokumentation af begreber og data?
32
AR6.3: Giv data den kvalitet som efterspørges
Data, der indsamles eller skabes i en it-løsning, skal være i en kvalitet, der muliggør tværgående anvendelse og genbrug i andre it-løsninger. Der kan spares offentlige ressourcer ved at anvende og genbruge data på tværs af offentlige myndigheder og private virksomheder, men gevinsten ved at genbruge data kan først realiseres, når data har en tilpas høj kvalitet.
• Projekter dokumenterer kvaliteten af data efter fælles sprog for datakvalitet.
• Projekter undersøger, om der er en positiv business case for at løfte datakvaliteten gennem samarbejde og evt. samfinansiering med andre myndigheder eller private aktører.
• Projekter undersøger i hvilket omfang borgere og virksomheder kan inddrages i indsamling og kvalitetssikring af data.
https://arkitektur.digst.dk/node/625Har projektet sikret, at der er taget stilling til kvaliteten af data der deles og at kvaliteten er beskrevet?
33
AR6.4: Udstil oplysninger om datakilder, begreber og datamodeller
Beskrivelser af datakilder, begreber og datamodeller udstilles således, at myndigheder og private kan få indsigt i, hvilke data offentlige myndigheder har og dermed vurdere potentielle muligheder for genbrug.
• Beskrivelser af datakilder, begreber og datamodeller udstilles efter fælles standarder, fx på myndighedens hjemmeside eller i et fælles katalog.
https://arkitektur.digst.dk/node/610

https://arkitektur.digst.dk/node/618
Har projektet sikret at oplysninger om relevante datakilder udstilles efter fælles standard.
34
Applikation
35
Princip 7: It-løsninger samarbejder effektivtEr der det fornødne fokus på snitflader i det digitale økosystem?
36
AR7.1 Design og udstil snitflader efter fælles integrationsmønstre og tekniske standarder
Projekter sikrer at data og services kan udstilles med åbne snitflader og at relevante selvbetjeningsløsninger, fagsystemer og generelle infrastrukturservices kan integreres med hinanden således, at den sammenhængende service og tværgående proces understøttes digitalt. Når de enkelte projekter gang på gang skal udvikle løsninger på problemstillinger, der allerede er løst, betyder det forøgede udviklings- og vedligeholdelsesomkostninger, længere udviklingstid og større risiko for fejl. Integration af it-løsninger sker derfor ved brug af fælles integrationsmønstre og data udveksles i henhold til aftalte protokoller.
• Projekter beskriver eksplicit konkrete behov for snitflader, der efterspørges fra offentlige myndigheder eller virksomheder.
• Projekter sikrer, at de mest hensigtsmæssige integrationsmønstre identificeres og aftales med udgangspunkt i de afklarede krav til informationsindhold og servicemål.
• Integrationer designes vha. fælles aftalte integrationsmønstre.
• Snitflader og services overholder aftalte tekniske formater og protokoller, der understøtter sikker og effektiv transport af data.
• Projekter sikrer at oplysninger om snitflader udstilles efter fælles standarder, så de er tilgængelige for relevante parter, fx i et fælles katalog.
https://arkitektur.digst.dk/node/537Sørger projektet for at snitflader følger fælles retningslinjer?
37
Infrastruktur
38
Princip 8: Data og services leveres driftssikkertEr der det fornødne fokus på tværgående driftssikkerhed?
39
AR8.1: Levér data og services i henhold til aftalte servicemål
Efterhånden som tværgående processer, datadeling og fælles komponenter udbredes i den offentlige sektor, vil de enkelte it-løsninger blive mere og mere afhængige af it-services, der ligger uden for kontrol af den enkelte myndighed.

Myndigheder og andre dataanvendere, som fx virksomheder, skal kunne stole på, at væsentlige data og it-services er tilgængelige inden for aftalte tidsrum og med aftalte kvalitetskriterier.
• Projekter afklarer hvordan effektiv og sikker levering sker bedst. Det kan være med egen distributionsløsning eller fx via en af de større distributionsplatforme, som fx den nationale serviceplatform på sundhedsområdet, den fælleskommunale serviceplatform og den fællesoffentlige datafordeler.
• Projekter sikrer, at der udarbejdes og publiceres aftaler om tilgængelighed, svartider, operationelle forhold og relevante kvalitetskriterier for data og itservices, der udstilles til genbrug.
• Projekter vurderer, om robusthed og tilgængelighed af byggeblokke, der indgår i flere it-løsninger eller i fælles infrastruktur, opnås gennem høje servicemål eller via flere installationer.
• Projekter sikrer, at der gennemføres relevante test, herunder test af sikkerhed, belastning og skalerbarhed.
https://digst.dk/styring/systemstyring/

https://arkitektur.digst.dk/node/677
Har projektet sikret end-to-end robusthed hvor relevant?
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
Loading...