Retningslinjer for formidling og dokumentation af arkitektur i digitaliseringsprojekter
Version 0.8.4 Version 1.0 Marts 2019
2
Indledning............................................................................................................. 3
Pejlemærker for projekter ..................................................................................... 8
Interessenter og interesser .................................................................................. 10
Interessenternes behov for information .............................................................. 12
Arkitekturperspektiver og -visninger .................................................................... 14
Arkitekturreol ..................................................................................................... 18
Arkitekturleverancer ........................................................................................... 19
Arkitekturprodukter ............................................................................................ 20
Arbejdet med arkitekturprodukter ...................................................................... 22
Modellering ........................................................................................................ 34
Navngivning ........................................................................................................ 41
Konfigurations- og versionsstyring ....................................................................... 41
Bilag 1: Tjekliste vedrørende arkitekturdokumentation ........................................ 43
Bilag 2: FDA-grundperspektiver ........................................................................... 46
Bilag 3: Liste over udvalgte arkitekturprodukter ................................................... 55
Bilag 4: Liste over udvalgte modelsprog og tilhørende åbne
udvekslingsformater ........................................................................................... 64
3
Indledning Arkitektur er en central del af et digitaliseringsprojekt. Arkitektur har først og fremmest
til formål at sikre et fornuftigt design af en given løsning i udviklingsforløbet. Dokumen-
tation skal understøtte dialog mellem forretning og it, mellem kunde og leverandør og
mellem projektets interessenter. Og en del af dokumentationen skal desuden under-
støtte den efterfølgende drift, vedligeholdelse og videreudvikling af løsningen.
Dette dokument beskriver fællesoffentlige retningslinjer for dokumentation og formid-ling af arkitektur i digitaliseringsprojekter. Retningslinjerne understøtter princippet Ar-kitektur styres på rette niveau efter fælles rammer og arkitekturregel 1.3 Anvend fælles ramme for beskrivelse af arkitekturen i Hvidbog om fællesoffentlig digital arkitektur (FDA).
Retningslinjerne er udarbejdet med udgangspunkt i internationale standarder og best practice erfaringer fra danske myndigheder og deres leverandører.
Formål Formålet med disse retningslinjer er, at øge synligheden af arkitekturaspekter i forbin-
delse med digitalisering, så der kan samarbejdes om at opnå høj kvalitet med rette pri-
oritering og så arkitekturen løbende kan anvendes og forbedres.
Retningslinjerne skal give en fælles ramme og terminologi for dokumentation af arki-
tekturen i digitaliseringsprojekter. Det er væsentligt nemmere at samarbejde og ”få
stikkene til at passe sammen”, når arkitektur er beskrevet efter samme ramme.
Retningslinjerne skal kunne bruges uafhængigt af leverancemodel, projektmetode, sy-
stemudviklingsmetode og arkitekturværktøj.
Overordnet set skal retningslinjerne støtte projekter i, at udarbejde arkitekturdoku-
mentation i form af to hovedleverancer:
Målarkitekturen, der beskriver de overordnede mål og principper for den løs-ning, der skal udarbejdes, og lægger rammerne for fastlæggelsen af løsningsar-kitekturen. Typisk fokus for kunden / ledelsen.
Løsningsarkitekturen, der beskriver det detaljerede design af den løsning, der skal udvikles/er under udvikling/er udviklet. Typisk fokus for leverandøren.
Det er samtidig vigtigt at understrege, at der også skal være fokus på, at der produce-
res den fornødne dokumentation til, at de udviklede løsninger efterfølgende kan drif-
tes, vedligeholdes og videreudvikles så effektivt som muligt. Og at der etableres den
nødvendige governance til at understøtte dette.
Endelig skal retningslinjerne bidrage til, at der kan etableres overblik over system-/løs-
ningsporteføljen, fx til brug for prioritering af kommende indsatser, jf. strategi for it-
styring i staten.
4
Målgruppe Målgruppen for dette dokument er forretnings- og it-arkitekter samt projektledere hos
myndigheder og deres leverandører med ansvar for at udarbejde dokumentation i of-
fentlige digitaliseringsprojekter.
Anvendelse Den fælles dokumentationsramme er nem at tage i brug og tilpasse til konkrete behov i
et projekt/program og en myndighed/organisation. Retningslinjerne kan anvendes uaf-
hængigt af projekt- og udviklingsmodel. Retningslinjerne er vejledende og kan frit an-
vendes af alle myndigheder.
For projekter i regi af den fællesoffentlige digitaliseringsstrategi (FODS), er der aftalt
krav om, at projekterne skal følge retningslinjerne med særligt fokus på at understøtte
arkitekturstyring og kvalitetssikring gennem review.
Som led i FODS vil der blive etableret tilbud om kompetenceudvikling og rådgivning ift.
anvendelse af disse retningslinjer, som stilles til rådighed for alle myndigheder og leve-
randører på markedsvilkår.
For statslige it-projekter gælder, at hvor der i forvejen er defineret produkter og frem-
gangsmåde i it-projektmodellen er dette gældende. Hvor retningslinjerne giver supple-
rende vejledning kan denne følges.
Værdiskabelse
Fælles retningslinjer bidrager til en digitalt sammenhængende sektor ved at un-derstøtte hvidbogens principper og den fællesoffentlige rammearkitektur
Arkitekturbeskrivelse skal ses som del af en analyse, der bidrager til at facilitere og fastholde beslutninger og kan bruges som et styringsværktøj relateret til sty-ringsdokumenter som fx et projektgrundlag / PID.
Projekter og løsninger kan styres bedre via overblik over de væsentligste arkitek-turelementer og -udfordringer – både internt og på tværs
Dialog mellem projektledelsen, forretnings- og it-arkitekter og udviklere om struktur og indhold i løsningen bliver nemmere og mere entydig med fælles ter-minologi
Løsninger kan udvikles, driftes og vedligeholdes mere effektivt ved hjælp af en fælles dokumentation
Myndigheder og projekter får et bedre grundlag for samarbejde, koordinering og genbrug af deres arbejde, når arkitektprodukter kan sammenstilles
Ressortændringer og opfølgning på ny lovgivning kan lettes gennem arkitektur-dokumentation efter fælles ramme
5
Arkitekturarbejde kan bedre kvalitetssikres gennem peer-review på grundlag af ensartet dokumentation på tværs af myndigheder, projekter og løsninger
Med en fælles tilgang til dokumentation bliver det nemmere at opbygge rele-vante kompetencer på tværs af myndigheder og projekter, fx gennem kurser og netværk.
Perspektivet er, at myndighederne og deres leverandører bliver bedre til at kravspecifi-
cere og designe løsninger ved at anvende de samme fælles internationale standarder
for metode og notation og fælles sprog for arkitekturens indhold. På sigt kan det give
en mulighed for systematisk og eventuelt automatisk at vurdere om en given arkitektur
eller løsning overholder fælles aftale krav i henhold til den fælles digitale arkitektur.
Tilblivelse og vedligehold Retningslinjerne er forankret i Styregruppen for data og arkitektur i regi af initiativ 8.1
Gode data og effektiv datadeling i regi af den fællesoffentlige digitaliseringsstrategi. De
er udarbejdet af Digitaliseringsstyrelsen i samarbejde med en fællesoffentlig arbejds-
gruppe bestående af erfarne enterprise og løsningsarkitekter fra deltagende myndighe-
der. Udkast til retningslinjerne har været genstand for offentlig kommentering.
Retningslinjerne er baseret på erfaringer med hvilken dokumentation, der giver mest
værdi. Erfaringer er bl.a. baseret på flere års brug af OIO EA og er bl.a. hentet ind via
arkitektarbejdsgruppen og fra myndigheder og leverandører, der har bidraget med
kommentarer i forbindelse med udarbejdelsen af disse retningslinjer.
Retningslinjerne bygger de på internationalt forankrede og velafprøvede metoder og
arkitekturrammeværker, primært The Open Group Architecture Framework (TOGAF).
Retningslinjerne kan ses som en opdatering af det fællesoffentlige rammeværk OIO EA,
som ikke længere er gældende eller vedligeholdes.
Retningslinjerne vil blive revideret efter behov på baggrund af indhøstede erfaringer
med anvendelsen.
Indhold Dokumentet kommer omkring følgende:
Pejlemærker for projekterne ift. arkitekturarbejdet
Identifikation af centrale interessenter og deres interesser
Grundlæggende perspektiver på arkitekturen
Fælles arkitekturreol så arkitekturprodukter er nemme at dele og genfinde
Udvalgte arkitekturprodukter som projekter bør være opmærksomme på
6
Governance i forhold til arkitekturdokumentation
Fælles tilgang til modellering og genbrug af byggeblokke
Bilag 1 indeholder en tjekliste for projektledere og arkitekter vedrørende arkitekturdo-
kumentation.
Sammenhæng til andre FDA-dokumenter Nærværende retningslinjer er del af et samlet sæt af dokumenter, som skal tjene til at
definere den fællesoffentlige digitale arkitektur og give retningslinjer, vejledning og
værktøjer med henblik på at understøtte anvendelse.
Nedenstående diagram giver et overblik over de mest relevante dokumenter i sam-
menhæng med nærværende retningslinjer. Diagrammet viser sammenhæng til tre af
hvidbogens arkitekturregler og sammenhæng til side- og underordnede dokumenter,
som giver vejledning i, hvordan man arbejder indenfor rammerne af den fællesoffent-
lige digitale arkitektur.
FIGUR 1 SAMMENHÆNG MELLEM ARKITEKTURREGLER OG RETNINGSLINJER
7
Det understreges at dette er et tids- og kontekst afhængigt ”snapshot”1. På sigt vil disse
fx kunne blive suppleret med retningslinjer og vejledninger om relaterede emner, som
fx modellering af processer og regler.
Desuden er der udarbejdet en række mere specifikke dokumenter, der supplerer nær-
værende retningslinjer. Det drejer sig om:
Begrebsmodel og -liste vedr. digital arkitektur og arkitekturdokumentation
Tjekliste om arkitekturdokumentation
Liste over grundlæggende arkitekturperspektiver
Liste over udvalgte arkitekturdokumenter
Liste over udvalgte og tilhørende udvekslingsformater
Det til enhver tid gældende sæt af retningslinjer og vejledninger samt supplerende in-
formation vedrørende arkitekturmetodik publiceres på https://arkitektur.digst.dk/me-
toder.
Centrale begreber Arkitektur er fundamentale begreber og egenskaber af et system i dets miljø legemlig-
gjort i dets elementer, relationer og principper for design og udvikling. Dvs. at arkitek-
tur er beskrivelse af egenskaber ved et system, som kan være udtryk for en løsning.
Et system defineres her generelt som ”et system er en kombination af interagerende
elementer, der er organiseret for at opnå et eller flere erklærende formål.” ligesom i
[ISO/IEC 15288]2. Det bemærkes også at ”Et system er i denne sammenhæng menneske-
skabt og består ikke blot af hardware, software og data, men også af mennesker, pro-
cesser, procedurer, faciliteter og materialer og naturlige genstande”. Et it-system er et
system, der består af digitale informationsteknologier.
Med løsning forstås et svar på et problem, som adresserer interessenters interesser.
En forretningsmæssig løsning er de samlede processer, regler, begreber, funktioner og
it-systemer mv., der udgør det samlede produktionsapparat på tværs af forretning og
it. En it-løsning er et it-system, der opfylder et forretningsbehov.
Arkitekturbeskrivelse er mundtlig eller skriftlig formidling af de væsentligste egenska-
ber ved arkitektur.
1 Dokumentet Standard for beskrivelse af it-systemer forventes publiceret i anden halvdel af 2019.
2 ISO/IEC 15288 (Systems and software engineering -- System life cycle processes)
8
Et arkitekturprodukt er arbejdsprodukt som bruges til at beskrive en del af en arkitek-
tur. Et selvstændigt og afgrænset arbejdsprodukt med indhold, der relaterer sig til arki-
tektur. Kan dække et eller flere arkitekturperspektiver og kan indeholde en eller flere
visninger af arkitekturen i form af fx matricer eller diagrammer. Kan indgå i andre ar-
bejdsprodukter, fx formaliserede arkitekturleverancer, udbudsmateriale, kravspecifika-
tioner, systemdokumentation og specifikationer. Der kan udarbejdes mange arkitektur-
produkter i løbet af et projekt og en løsnings livscyklus. Nogen anvender den alterna-
tive term artefakt.
En arkitekturleverance er et arkitekturprodukt eller en samling af arkitekturprodukter,
som er kontraktmæssigt defineret og vil blive formelt gennemgået og vedtaget af de
berørte parter. Leverancer udgør output fra projekter. Leverancer i dokumentations-
form arkiveres typisk ved projektets afslutning eller overføres til en et arkitekturarkiv
som en referencemodel, standard eller som et snapshot af arkitekturlandskabet på et
givet tidspunkt.
Arkitekturdokumentationen laves i to hovedleverancer:
Målarkitekturen, som er en beskrivelse af en fremtidig tilstand af arkitekturen (en-
terprise eller løsningsarkitektur), der udvikles for en organisation. Den beskriver de
overordnede mål og principper for den løsning, der skal udarbejdes, og lægger
rammerne for fastlæggelsen af løsningsarkitekturen.
Løsningsarkitekturen, som er en beskrivelse af en bestemt forretningsaktivitet, og
hvordan informations- og IT-systemer understøtter denne aktivitet. Den beskriver
det detaljerede design af den løsning, der skal udvikles/er under udvikling/er udvik-
let.
Den samlede dokumentation af målarkitektur og løsningsarkitektur udgør tilsammen
dokumentationen af, hvordan en løsning producerer de ydelser/services, der modsva-
rer de opgaver, som projektet/myndigheden skal løse. Arkitekturdokumentationen i
begge hovedleverancer opdateres løbende.
Udvalgte begreber og fagtermer forklares efterhånden som de introduceres. Herud-
over henvises til ordbogen på https://arkitektur.digst.dk/fda-begreber og dokumentet
Digital arkitektur - Begrebsliste i ISO-format: Digital arkitektur der finde på hjemmesi-
den.
Pejlemærker for projekter Arkitekturregel 1.3 Anvend fælles ramme for beskrivelse af arkitekturen stiller krav om,
at projekter udarbejder relevant arkitekturdokumentation efter nærværende retnings-
9
linjer og deler denne, således at andre kan anvende denne til indsigt og genbrug. Ret-
ningslinjerne skal anvendes pragmatisk med fokus på en balance mellem værdi for det
enkelte projekt og værdi for det bredere fællesskab på tværs af projekter.
Fra projekter spørges typisk: Hvilke arkitekturprodukter skal vi lave? Hvorfor skal vi lave
disse produkter? Hvornår skal vi lave dem? Hvilken kvalitet skal de have? Hvordan skal
vi lave dem? Er der metodefrihed? Hvordan skal de bringes i spil i forhold anvendelse
og vedligeholdelse?
Projekterne bør tage udgangspunkt i følgende principper som pejlemærker:
? Hvad skal vi lave og hvorfor?
Den nødvendige og tilstrækkelige dokumentation udarbejdes. Det betyder, at projektet - med udgangspunkt i projektmodel og -type - skal tage højde for behov ift. relevante processer og interessenter, herunder særligt behov ift. styring (styregruppe), analyse og konceptudvikling (nøgleaktører og arkitekter), projekt- og arkitekturreview (statens it-projektråd, review-panel), anskaffelse og udvikling (systemejer, leverandør) samt overlevering til drift, support og videreudvikling.
? Hvornår og i hvilken kvalitet?
Dokumentation udarbejdes til rette tid og formål. Det betyder, at der løbende som led i projektets aktiviteter udarbejdes doku-mentation, der understøtter projektet. Prioriter gerne ud fra de behov interes-senterne har på et givet tidspunkt, ud fra de informationer, der er til stede på dette tidspunkt og at dokumentationen har en form og format, som modsvarer behovet.
? Hvordan skal vi gøre - er der metodefrihed?
Der er metodefrihed indenfor fælles rammer. Det betyder, at retningslinjerne giver pejlemærker for, hvad projekterne bør tage stilling til og tænke ind i planlægningen, men som udgangspunkt ikke be-grænser anvendelse af standarder og almindelig god praksis. Hvor der undta-gelsesvist laves begrænsende regler, er det af hensyn til at understøtte det tværgående samarbejde, herunder deling og genbrug af arkitekturdokumenta-tion. Metodefriheden stopper der hvor vi skal udveksle information.
? Hvordan skal de anvendes og vedligeholdes?
Arkitekturprodukter skal anvendes hvor relevant og vedligeholdes efter af-tale. Det betyder, at projektets arkitekturprodukter skal bringes i anvendelse i rele-vante sammenhænge. Først og fremmest internt i projektet, hvor et arkitektur-produkt kan betragtes som en stafet der fx går fra arkitekt til udvikler, og som dermed bidrager til et klart grundlag for arbejdet med løsningen. Desuden skal
10
relevante dele af projektets arkitekturprodukter kommunikeres og deles med andre interessenter uden for projektet, fx dokumentation af data, services og snitflader. Nogle arkitekturprodukter kommer fra eller skal blive del af en over-ordnet rammesættende (enterprise) arkitektur. Der skal være klare rammer for ansvaret for vedligehold af de blivende arkitekturprodukter.
Interessenter og interesser I dette afsnit beskrives de grundlæggende interessenter og deres grundlæggende inte-
resser i forhold til den arkitekturdokumentation, der udarbejdes. Det sker med ud-
gangspunkt i standarden ISO/IEC/IEEE 42010 “Systems and software engineering — Ar-
chitecture description”.
En interessent er et individ, en gruppe eller en organisation (eller klasser deraf), der
har en interesse i eller anliggender i forhold til arkitekturens resultat. Stakeholder an-
vendes ofte som alternativ term. Interessenter har typisk en eller flere opgaver de hver
især skal løse ift. en løsning/system. Det kan fx være at beslutte, om og hvordan løs-
ningen skal laves, at betjene sig selv via løsningen, at udvikle løsningen, at sørge for at
løsningen er sikker eller supportere brugere af løsningen. Disse interessenter har hver
især interesse (concern) i et eller flere aspekter af løsningen/systemet for at kunne løse
deres opgave.
Følgende interessenter er generelt relevante at tænke ind ift. afklaringen af hvilken ar-
kitekturdokumentation, der kan være relevant. NB! De angivne grupper er nogle grove
grupperinger. Samme aktør kan optræde i flere interessentroller og dermed have flere
forskellige sæt af interesser. I praksis vil det være relevant at lave en mere præcis liste i
den konkrete kontekst.
Ejer - herunder topledelse, opgaveansvarlig, produktejer, dataejer, it-systemejer,
it-serviceejer. Interessent med ansvar for business case.
Forretning – herunder ledere, specialister og medarbejdere, som er udførende i op-
gavevaretagelse og produktleverance.
Bruger - herunder brugertyper og målgrupper blandt borgere, virksomheder og
medarbejdere samt andre brugere af systemet. Kan også optræde som datasubjekt
i forhold til ”mine data”.
Projektleder - herunder også projektmedarbejdere med ansvar for anskaffelse.
Arkitekt/udvikler - herunder arkitekter med interesse på vegne af de ansvarlige for strategi og målsætning og et helhedssyn på arkitekturen som fx enterprise arkitekt og løsningsarkitekt. Specialiserede interessenter på kundesiden såsom forretnings-arkitekter, dataarkitekter, applikationsarkitekter, udviklere, UX’ere og servicedesig-nere, testansvarlige samt teknologiarkitekter.
11
Juraansvarlig – herunder jurister knyttet til et givent projekt, men også politikere,
lovgivere og lovfortolkere samt rettighedshavere.
Sikkerhedsansvarlig – særligt Data Protection Officer (DPO), men også andre roller
med ansvar for håndtering af sikkerhed på forskellige områder (data, løsning, infra-
struktur, drift), jf. ISO 27000x-serien.
Dataejer-/behandler – herunder dataansvarlige, databehandlere og datadistributø-
rer.
Leverandør - herunder fx leverandørens projektleder, arkitekter, udviklere, UX’ere,
servicedesignere og testansvarlige.
Drift - herunder it-systemforvaltere, ansvarlige for drift, vedligehold og videreud-
vikling, systemoperatører og support.
Governance-ansvarlig – herunder standardiseringsorganisationer og fora med an-
svar for tværgående governance, fx styregruppe der repræsenterer ejere og anven-
dere af fælles infrastruktur.
Tilsvarende er følgende overordnede interesser i forhold til hvad en given løsning skal
opfylde af krav generelt relevante at tænke ind:
Løsningens formål og overordnet vision.
Arkitekturens egnethed til opnåelse af løsningens formål og understøtte visionen.
Muligheden for at udvikle og implementere løsningen.
Forventet livscyklus og levetid for løsningen - roadmap
Indvirkning på omkringliggende systemlandskab
Løsningens potentielle risici og virkninger for dens interessenter i hele dens livscy-
klus.
Tværgående samarbejde, processer, semantisk og teknisk interoperabilitet, inte-
grationer og tværgående infrastrukturunderstøttelse.
Løsningens egenskaber ift. vedligehold og udvikling.
Nedenstående figur opsummerer hovedelementer der skal på plads, når offentlige skal
samarbejde digitalt i forhold til tværgående processer, datadeling og fælles løsninger.
12
FIGUR 2 FORTÆLLING OM FORUDSÆTNINGER FOR DIGITAL SAMMENHÆNG
Interessenternes behov for information Formålet med formidling og dokumentation af arkitektur er at understøtte interessen-
ters afklaring af, hvordan deres interesser varetages i forbindelse med udviklingen af
digitale løsninger. Det kan fx være i forhold til realisering af gevinster, tilrettelæggelse
af processer og arbejdsgange, strukturering af information, brugergrænseflader eller
plan for migration fra eksisterende til fremtidigt system.
Information er enhver kommunikation eller repræsentation af fakta, data, eller hensig-
ter, i ethvert medium eller form, herunder tekstmæssige, numeriske, grafiske, karto-
grafiske, beskrivende eller audio-visuelle former.
Desuden skal dokumentation potentielt understøtte udvikling, drift og vedligehold af
løsninger i hele deres livscyklus. Derfor er det vigtigt at have øje for hvilken del af doku-
mentationen, der skal kunne det.
Set fra et organisatorisk og projektsynspunkt handler det om at give svar på spørgsmå-
let: ”Hvordan skaber vi evnen til at svare på interessenternes spørgsmål, håndtere de-
res interesser og hjælpe dem med at løse deres opgave ift. projektet og løsningen?”
Det er ligeledes vigtigt at finde den rette balance mellem sammenhængende dokumen-
tation og målrettet formidling. Den grundlæggende dokumentation kan i mange til-
fælde ske i struktureret form med brug af fx et modelsprog som Archimate, BPMN eller
13
UML. Formidlingen skal være målrettet interessenternes forskellige behov og kan såle-
des udformes i form af mere letforståelige illustrationer og tekst.
Dokumentationen af arkitekturen skal som udgangspunkt understøtte mange forskel-
lige behov for information. Til formidling er der behov for at udarbejde forskellige mo-
deller, visninger og tekster, som kan indgå i forskellige ledelses- og specialistprodukter
– fx som bilag til et projektgrundlag eller en kravspecifikation.
Overordnet set har enterprise-arkitekten og løsningsarkitekten ansvar for sikring af do-
kumentation i et helhedsperspektiv gennem udarbejdelse og vedligehold af samlede
modeller over enterprise- og løsningsarkitektur – udarbejdet i formelle, logiske notati-
onssprog. Der er forskellige sprog med forskelligt fokus og primære målgrupper (læs
mere i afsnittet Fælles notationssprog for arkitekturdokumentation). De formelle mo-
deller kan danne grundlag for visninger formidlet i et format, der er forståeligt af inte-
ressenterne.
Dokumentation har bl.a. til formål at understøtte formidling. Det kan fx være formid-
ling til beslutningstagere om målarkitektur og krav til løsningen, til leverandør og udvik-
ler om tekniske detailkrav til løsningen, eller til systemoperatører og support om konfi-
guration af løsningen. Førstnævnte har brug for information, som giver overblik og er
relativt statisk, mens sidstnævnte har brug for detaljeret og opdateret information.
Arkitektur kan beskrives på mange måder og i mange formater. Typisk er det i form af
ustruktureret og struktureret tekst og visualisering. Hyppigt anvendte formater er kata-
loger (lister), matricer (tabeller) og diagrammer (visuelle modeller). Diagrammer kan
udarbejdes med eller uden anvendelse af et formelt notationssprog. Modeller er gode
fordi de afskærmer fra irrelevante detaljer og kan struktureres stramt og logisk. Til for-
midling kan man anvende fx tegninger, tegneserier, mockup af skærmbilleder og video.
De primære brugere af dokumentation udarbejdet med formelle notationssprog er ar-
kitekter og udviklere, som skal designe og udvikle løsningen samt aktører, som har be-
hov for præcis information i forbindelse med drift, fx systemoperatører. De øvrige inte-
ressenter har typisk behov for formidling, som ikke er for teknisk og detaljeret. Neden-
stående tabel illustrerer, hvilke typer af information de forskellige interessenter typisk
har behov for – og som de kan forstå og anvende til at løse deres opgaver.
Behov for logisk struktureret dokumen-tation i form af diagrammer i formelle notationssprog
Behov for formidlet dokumentation i form af tekst, billeder, video, mundtligt
Arkitekt / udvikler
Sikkerhedsaktør - især DPO
Bruger
Ejer
14
Forretning
Dataejer/-behandler
Leverandør – især ansvarlige ift. kravspecifikation
Drift - især ansvarlige ift. konfigura-tion af teknisk løsning
Governance-aktør
Sikkerhedsaktør
Juraansvarlig
Forretning
Sikkerhedsaktør
Ovenstående er en grov forenkling. Valget mellem formel og uformel repræsentation
bør altid tage konkret udgangspunkt i modtagers individuelle kapacitet og kompeten-
cer.
Information om arkitektur skal have en form der understøtter, at den kan for-stås og anvendes korrekt af modtager.
Arkitekturprodukter i form af diagrammer, kataloger og matricer bør suppleres med tekst med henblik på at uddybe og forklare særlige forhold og problemstil-linger samt sikre korrekt fortolkning.
Arkitekturperspektiver og -visninger I dette kapitel defineres en række grundlæggende perspektiver på og visninger af arki-
tekturen, der understøtter interessenternes behov for information. Det sker ligeledes
med udgangspunkt i TOGAF og standarden ISO/IEC/IEEE 42010 “Systems and software
engineering — Architecture description”.
Man kan sige, at en interesse kan udtrykkes som et spørgsmål fra et bestemt perspek-
tiv og en visning er et svar.
Et perspektiv definerer udgangspunktet, hvorfra en visning er oprettet. En synsvinkel
er en specifikation af de principper, der er blevet anvendt til at konstruere og anvende
en visning. En visning er det man ser; et perspektiv er hvor man ser fra – det udsigts-
punkt eller synsvinkel, der afgør hvad du ser. Man kan også anvende alternative TOGAF
termer som synsvinkel / viewpoint.
En visning er repræsentationen af en samling be-
slægtede anliggender. En visning er det der ses fra
et bestemt synspunkt. En arkitekturvisning kan re-
præsenteres med en repræsentation af (en del af)
en model for at vise interessenterne deres særlige
interesseområder i arkitekturen. En visning behøver
ikke nødvendigvis at være visuel eller grafisk. Ofte
anvendes den alternative engelske term view.
FIGUR 3 EN INTERESSENT MED ET PERSPEKTIV
DER SER EN VISNING DER MODSVARER INTE-
RESSEN
15
Figur 3 En interessent med et perspektiv der ser en vis-
ning der modsvarer interessenviser en spørgende inte-
ressent, der ser på en visning af arkitekturen ud fra et
perspektiv med fokus på det der interesserer ham – her
er det den forretningsmæssige opgaveløsning med fokus
på processer og arbejdsfunktioner.
Det er vigtigt at skelne mellem den faktiske model og vis-
ningerne. Modellen afspejler arkitekturens indhold (ele-
menter/byggeblokke) og deres relationer, som beskrevet
af arkitekten. En visning indeholder et udsnit af modellen. Visningen skal designes så
den er meningsfuld for den specifikke interessent, og dennes specifikke interesser, som
visningen er tiltænkt. En eller flere visninger kan indgå i et arkitekturprodukt. Jf. Figur
4.
De grundlæggende FDA-perspektiver er defineret med
udgangspunkt i hvidbogens principper, som hver især
sætter rammerne for centrale problemstillinger, der skal tages højde for i digitalise-
ringsprojekters arkitekturarbejde. De otte perspektiver danner tilsammen en helheds-
tilgang til digitalisering, som kan beskrive en samlet fortælling om arkitekturen, her i
forenklet form:
De offentlige parter -staten, kommunerne og regionerne - vil udvikle sammenhæn-
gende digitale services sammen. De må derfor sætte fælles rammer op for at styre
hvordan de kan realisere dette, herunder aftale konkrete initiativer og projekter.
(Styring)
Parterne formulerer en fælles strategi med vision og mål, en plan for realisering in-
klusiv en fælles rammearkitektur og en plan for at bevæge sig fra den eksisterende
situation (as is arkitektur) til målbilledet (to be eller mål-arkitektur). (Strategi)
Projekterne skal sikre, at love, regler og kontrakter understøttes af planen og at
eventuelle juridiske barrierer kan fjernes. Det kan udfordre eksisterende lovgivning
eller kontrakter, som derfor muligvis må revideres. (Jura)
For at skabe sammenhængende løsninger, hvor man kan arbejde sammen og dele
data og digitale løsninger skal der etableres fælles rammer for tillid (trust
framework), der kan sikre at krav til sikkerhed og privacy overholder fælles krav på
tværs af alle aktørers forretning og it-løsninger. Det omfatter fx opmærkning af
data, adgangskontrol og rettighedsstyring i forhold til brugerne og teknisk beskyt-
telse ifbm lagring, behandling og transmission. (Sikkerhed)
FIGUR 4 VISNING BYGGER PÅ MO-
DEL OG KAN INDGÅ I ARKITEKTUR-
PRODUKTER
16
Er der tale om tværgående processer og services skal de medvirkende organisatio-
ner sikre, at deres respektive processer og services kan bringes i samspil på forret-
ningsmæssigt niveau. Det kræver fx en dokumentation af arbejdsgange og identifi-
kation af de forretningshændelser, der kan give anledning til at igangsætte proces-
ser på tværs af aktører. Ofte giver det anledning til tilpasning og effektivisering af
arbejdsgange – og evt. forenkling og automatisering. (Opgaver)
For at services og processer kan hænge samme skal data kunne deles, genbruges
og sammensættes uden tab af datas betydning. Det kan både være brug af fælles
masterdata som fx grunddata, genbrug af fælles klassifikationer fx for opgave-
emne, kommunikation af forretningshændelser og transaktionsdata. Det kræver at
der er fælles forståelse af semantik, datakvalitet. Og at data kan deles i et aftalt
format og med overholdelse af gældende regler. (Information)
Når der sættes strøm på og it-systemer skal integreres skal der være enighed om
hvilke applikationer der skal kunne tale sammen, hvordan de integreres (integrati-
onsmønstre), og hvilke protokoller der anvendes, så data udveksles sikkert og ef-
fektivt. (Applikation)
Endelig skal det sikres, at både dataudveksling og levering af sammensatte services
sker på et robust og sikkert fundament. Derfor skal aktørerne aftale, hvilke infra-
strukturkomponenter, der skal i spil og aftale et niveau for hvordan de skal fungere
sikkert og effektivt. (Infrastruktur)
FDA har således otte grundperspektiver som dækker en helhedsorienteret arkitektur:
Styring, Strategi, Jura, Sikkerhed, Opgaver, Information, Applikation og Infrastruktur. Jf.
Figur 5 De otte grundlæggende FDA-arkitekturperspektiver.
FIGUR 5 DE OTTE GRUNDLÆGGENDE FDA-ARKITEKTURPERSPEKTIVER
17
Bilag 2: FDA-grundperspektiver indeholder en mere detaljeret gennemgang af FDA
grundperspektiverne, hvor de relateres til relevante principper, arkitekturregler, inte-
ressenter og interesser samt arkitekturprodukter.
Der kan defineres mange andre perspektiver, som kan gå på tværs af disse grundper-
spektiver. Fx sammenhæng mellem hvilke applikationsservices der understøtter hvilke
forretningsservices eller hvilke informationer der udveksles mellem hvilke applikatio-
ner.
De fire øverste perspektiver Styring, Strategi, Jura og Sikkerhed går i høj grad på tværs
af de fire nederste perspektiver. Fx skal styring forholde sig til alle aspekter af løsnin-
gen fra strategi til infrastruktur og lovgivning kan sætte rammer for opgaver og brug af
data og tekniske løsninger.
De fire horisontale lag kan endvidere deles op i domæner, fx ved brug af FORM-opga-
venøglen, som er en fællesoffentlig referencemodel og klassifikation over offentlige op-
gaver.
De otte grundlæggende arkitekturperspektiver som defineres i FDA modsvarer tilsva-
rende i internationale arkitekturrammeværker som fx TOGAF og The European Inter-
operability Framework (EIF). Der er varianter i terminologi, snit og struktur, men i ho-
vedtræk kan alle de gængse rammeværker mappes til hinanden - og FDA kan ligeledes
mappes til disse. FDA-perspektivet ”Opgaver” svarer fx i store træk til ”Forretning” i
TOGAF og ”Organisation” i EIF.
FDA skal ikke ses som en konkurrent til rammeværker som TOGAF, EIF og tilsvarende,
men som et supplement. FDA definerer derfor heller ikke sin egen metamodel, men
alene de otte grundperspektiver, som anvendes til at definere en arkitekturreol, som
kan understøtte samarbejde og videndeling op tværs af den offentlige sektor – og på
tværs af rammeværker.
FIGUR 6 FIRE TVÆRGÅENDE PERSPEKTIVER PÅ FORRETNINGS- OG IT-ARKITEKTUREN
18
Arkitekturreol Dette kapitel handler om FDA-arkitekturreolen, som anvendes til at placere arkitektur-
produkter på ”hylder”, så de er nemme at finde og dele. Vertikalt er reolen delt op ef-
ter de otte grundperspektiver. Horisontalt er den delt i tre niveauer, der beskriver gra-
den af konkretisering og detaljer:
Konceptuel - har fokus på overblik og rummer færrest detaljer. Henvender sig især
til beslutningstagere samt interessenters/integrationsparters arkitekter og nye ar-
kitekter på løsningen. Beskrivelser er typisk nemme at afkode uden særlige forud-
sætninger.
Logisk - har fokus på sammenhænge og konsistens og rummer de vigtigste detaljer.
Beskrivelserne er typisk med klare definitioner og relationer mellem de forskellige
elementer, der indgår i arkitekturen. Henvender sig især til arkitekter, projektle-
dere og eksperter inden for de enkelte perspektiver.
Fysisk - har fokus på, hvordan løsningens forskellige elementer realiseres og rum-
mer alle nødvendige detaljer for udvikling, implementering og drift. Henvender sig
især til dem, der skal udføre opgaver i forretningen, udvikle løsningen samt løse
opgaver i drift og support.
Nedenstående figur viser reolens opbygning. Overskriften til de enkelte hylder er ud-
tryk for et bud på en pragmatisk fordeling af de mange forskellige ledelses- og arkitek-
turprodukter, som udarbejdes og anvendes i virksomheden og dens projekter. Reolen
kan i princippet rumme alle slags arkitektur ifbm digitalisering og it, og kan både
rumme arkitektur for den enkelte løsning og en samlet virksomhedsarkitektur.
19
FIGUR 7 FDA ARKITEKTURREOLEN
FDA arkitekturreolens struktur anvendes som en klassifikation til at opmærke arkitek-
turprodukter, når de skal udstilles og deles, så det bliver nemt at fremsøge dem.
Arkitekturleverancer I dette kapitel beskrives kort to overordnede arkitekturleverancer i et digitaliserings-
projekt, mens det følgende kapitel uddybende beskriver en række udvalgte arkitektur-
produkter, som indgår i arbejdet med at udfolde disse.
Digitaliseringsprojekter har overordnet set to primære arkitekturleverancer:
Målarkitekturen, der beskriver de overordnede mål og principper for den løs-ning, der skal udarbejdes, og lægger rammerne for fastlæggelsen af løsningsar-kitekturen.
Løsningsarkitekturen, der beskriver det detaljerede design af løsningen, der skal udvikles/er under udvikling/er udviklet.
Målarkitekturen udarbejdes relativt tidligt i projektet som grundlag for analyse, udbud
og gennemførelse. Den udarbejdes af kunden. Den har ledelse og projektledelse som
primære målgrupper.
Løsningsarkitekturen udarbejdes i samarbejde med leverandøren og kan nemt fylde 50,
100 eller flere hundrede sider. Den udarbejdes typisk iterativt i løbet af projektet og
løsningens levetid. Takt, omfang og arbejdsdeling afhænger af det enkelte projekts
kompleksitet og udviklingsmetode. I starten er beskrivelsen relativt abstrakt (logisk);
tilslut er den meget konkret (fysisk) og detaljeret. Den er så vidt muligt dokumenteret i
20
en sammenhængende arkitekturmodel. Den vil forekomme i forskellige hovedversioner
i løsningens livstid: Fx som resultat af analysefasen til brug ifbm kravspecifikation til ud-
bud, som løsningsforslag fra leverandøren, opdateret løsningsdokumentation ved over-
dragelse til drift, og løbende opdateret ifbm vedligehold og videreudvikling. Udvikles
typisk i en arbejdsdeling mellem kunden og leverandøren. Løsningsarkitekturens pri-
mære målgrupper er projektleder, arkitekt, udvikler og leverandør – samt ikke mindst
ansvarlige for drift, vedligehold og videreudvikling.
For at lave en målarkitektur er der en række forhold, som det er relevant at kortlægge
som grundlag for denne og som derfor kan betragtes som tidlige arkitekturprodukter.
Indenfor grundperspektiverne styring og strategi drejer det sig især om følgende mål,
gevinster, vision/målbillede, kapabiliteter, udfordringer og principper. De er det strate-
giske udgangspunkt for at definere den overordnede målarkitektur og eventuelle trin
på vejen til realisering i form af en migrationsstrategi. Men samtidig skal der typisk ar-
bejdes med en række arkitekturprodukter der beskriver forretnings- og it-arkitektur in-
den for grundperspektiverne Opgaver, Information, Applikation og Infrastruktur. I før-
ste omgang med fokus på et overordnet billede af de opgaver, der indgår i form af for-
retningsservices, processer, organisation, roller og forretningsobjekter/data, og den
tekniske understøttelse i form af applikationskomponenter, -services og -snitflader
samt de underliggende infrastrukturelle teknologiservices. Endelig skal der tages højde
for de overordnede juriske rammer i form af love og aftaler, der giver såvel mandat
som bindinger for løsningen. Og sidst men ikke mindst er det vigtigt, at tænke sikker-
hed og privatliv ind fra starten med henblik på bl.a. robust drift, tillid og gennemsigtig-
hed, herunder understøttelse af databeskyttelsesloven.
Arkitekturprodukter I dette kapitel beskrives en række arkitekturprodukter, som offentlige digitaliserings-
projekter bør som led i projektplanlægningen. De udvalgte produkter indgår typisk i ar-
bejdet med at udarbejde mål- og løsningsarkitekturen i digitaliserings- og anskaffelses-
projekter. De beskrevne arkitekturprodukter er udvalgt fordi, de
Understøtter de to primære arkitekturleverancer i et projekt: Målarkitektur og løsningsarkitektur
Understøtter overordnet design, styring, koordinering, review og kvalitetssik-ring.
Typisk er af interesse for andre end myndigheden og projektet selv.
Særligt projekter med tværoffentlig betydning må generelt set forventes at vurdere,
om de er relevante i forhold til projektets karakter.
NB! Det skal understreges, at det ikke er en udtømmende liste. I et projekt kan der
være mange andre dokumenter og arkitekturprodukter som også er relevante. Det
samme gælder i forhold til enterprise arkitektur fx på virksomheds-/koncern niveau,
21
hvor der er mange andre typer af arkitekturpro-
dukter. Ikke alle arkitekturprodukter, der udarbej-
des med henblik på at højne kvaliteten i et pro-
jekt, er relevante for at skabe sammenhængende
digitalisering på tværs af myndigheder. Nogle pro-
dukter er relevante for projektet, mens andre er
væsentlig blivende dokumentation, som skal ligge
til grund for fremtidig digitalisering, drift og vedligehold. Forskellige arkitekturproduk-
ter tjener således forskellige formål.
Det skal også bemærkes, at et digitaliserings- eller anskaffelsesprojekts egen kontekst
og proces sætter rammer for arkitekturen og denne er derfor taget med i form af en
række proces- og ledelsesdokumenter, der fx hører under en projektmodel, fx interes-
sentanalyse og forretningsmål, eller hører under porteføljestyring og sikkerhedshånd-
tering på virksomhedsniveau, fx arkitekturprincipper og sikkerhedsstrategi/mønster.
Et arkitekturprodukt kan dække et eller flere perspektiver og omfatte flere visninger. I
denne sammenhæng er de enkelte produkter for overblikkets skyld placeret ind på én
enkelt hylde. Figur 8 viser at nogle arkitekturprodukter går på tværs af grundperspekti-
verne Opgaver, Information, Applikation og Infrastruktur. Det gælder fx målarkitektur
og sikkerhedsmodel, der repræsenterer forskellige helhedsbilleder på de væsentligste
egenskaber ved arkitekturen. En række arkitekturprodukter indenfor de tværgående
grundperspektiver kan dog først dannes og udfol-
des i takt med, at der udvikles arkitekturprodukter
inden for de øvrige grundperspektiver. I praksis
udarbejdes de fleste arkitekturprodukter rent pro-
cesmæssigt typisk med forskellige grader af iterationer og parallelitet. En række af pro-
dukterne udarbejdes som et udgangspunkt/grundlag for andre. Produkterne i de fire
tværgående grundperspektiver er rammesættende i forhold til produkterne i de øvrige
grundperspektiver.
Begge overordnede arkitekturleverancer er i nedenstående arkitekturreol repræsente-
ret ved et arkitekturprodukt - Målarkitektur (resumé) og Løsningsarkitektur (resumé).
Disse resuméer er korte overbliksskabende dokumenter (1-5 sider) baseret på detalje-
rede arkitekturprodukter.
FIGUR 8 NOGLE ARKITEKTURPRO-
DUKTER GÅR PÅ TVÆRS AF GRUND-
PERSPEKTIVERNE
22
FIGUR 9 FDA-REOL MED UDVALGTE ARKITEKTURPRODUKTER
Bilag 3 Liste over udvalgte arkitekturprodukter beskriver i kort form de udvalgte arki-
tekturprodukter.
Nærværende retningslinjerne har ikke til formål, generelt at definere disse produkter i
detaljer. For enkelte produkter er der dog nærmere regler og retningslinjer i regi af
FDA, jf. følgende afsnit om modellering.
Det anbefales at tage udgangspunkt i god praksis i eksisterende rammeværker som fx
Open Groups arkitekturprodukter (kaldet artefakter). Dvs. at man for en mere detalje-
ret vejledning bør tage udgangspunkt i TOGAF eller tilsvarende rammeværk. TOGAF de-
finerer eksempelvis en detaljeret indholds-metamodel, som er grundlag for definition
af arkitekturprodukter og arkitekturleverancer. Disse omfatter struktureret information
i form af kataloger, matricer og diagrammer.
De udvalgte produkter er nærmere beskrevet i oversigtlig form i bilag 3 Liste over anbe-
falede arkitekturprodukter, hvor de bl.a. relateres til TOGAF og udvalgte modelsprog.
Arbejdet med arkitekturprodukter Dette kapitel giver en overordnet introduktion til hvordan arkitektur kan gribes an i for-
hold til projektmodeller og agile metoder samt hvordan man kan arbejde med priorite-
ring og governance i forhold til arkitekturprodukter.
23
De produkter, som er beskrevet ovenfor udarbejdes af forskelle aktører og i forskelligt
regi og forskellige faser. Fx er der en række arkitekturprodukter, som er rammesæt-
tende for flere projekter. Det kan fx være forretningsmål, arkitekturprincipper og sik-
kerhedsstrateg. Disse udarbejdes typisk af ledelsen assisteret af en tværgående funk-
tion, fx en EA eller sikkerhedsfunktion. Andre produkter udarbejdes af/til projektledel-
sen. Det er fx interessentanalyse, gevinstmodel og ændringsanmodningslog. Og så er
der en række specialistprodukter, som udarbejdes primært af arkitekter i samarbejde
med forskellige grupperinger af projektets interessenter.
Nogle produkter kan således være udarbejdet før projektet og fungere som (ramme-
sættende) input. Andre udarbejdes tidligt i projektet og er rammesættende for de øv-
rige produkter. Og så er der alle de produkter, der udarbejdes efterhånden som projek-
tet skrider frem og der skabes klarhed over behov og løsningsmuligheder. Dette kan
ske efter forskellige metoder – mere eller mindre vandfald eller agilt og eventuelt med
brug af formaliserede metoder som fx Scrum og et rammeværk som fx TOGAF – der
sagtens kan anvendes i kombination. Det er op til projektet at vælge og tilpasse egnede
metoder.
FDA-dokumentet Vejledning om arkitekturmetode giver – som et eksempel og til inspi-
ration - en introduktion til anvendelse af TOGAF’s arkitekturudviklingsmetode i forhold
til FDA.
Arkitekturprodukter i projektfaser I dette afsnit beskrives i oversigtform form de vigtigste arkitekturprodukter i forhold til
hovedfaserne i den statslige it-projektmodel. Den konkrete opdeling bør altid planlæg-
ges i kontekst af det enkelte projekt og sættes i forhold til den valgte udviklingsme-
tode.
Nedenstående figur illustrerer, at der er en udvikling med forskellige arkitekturproduk-
ter og leverancer til forskellig anvendelse.
24
FIGUR 10 ARKITEKDOKUMENTATION I FORHOLD TIL PROJEKTFASER
En første overordnet version af målarkitekturen bør udarbejdes i idé- og foranalysefa-
sen og vedlægges som bilag til projektgrundlaget og opsummeres kort i projektgrundla-
gets teknik-afsnit. En første version af løsningsarkitekturen kan enten udarbejdes i ana-
lysefasen, når der er tale om interne udviklingsprojekter, eller i gennemførselsfasen,
når der er tale om anskaffelser med ekstern leverandør. En konsolideret beskrivelse af
løsningsarkitekturen, herunder et samlet overblik og relevante detail-beskrivelser, bør
leveres i forbindelse med overdragelse til drift.
Nedenstående figur illustrerer en række eksempler på, hvordan der i løbet af et projekt
typisk sker en forædling, uddybning og konkretisering af arkitekturdokumentationen.
FIGUR 11 ILLUSTRATION AF HVORDAN ARKITEKTURPRODUKTER UDVIKLES ITERATIVT
25
De blå pile viser hvordan et produkt er grundlag for et andet gennem berigelse med
flere detaljer, fx fra begrebsmodel til logisk informationsmodel, til logisk datamodel til
fysisk datamodel, eller gennem sammenstilling af flere elementer, fx aktør + proces el-
ler proces + begreb.
Idé I denne fase er fokus i forhold til arkitekturen at skabe et projektgrundlag der tydelig-
gør vision og mål samt scope forud for det videre forløb. Målarkitekturen er her kun
beskrevet meget overordnet og typisk på konceptuelt niveau.
Til et projektgrundlag og et scopereview bør der som minimum være arkitekturproduk-
ter i form af en vision/målbillede gerne suppleret med et systemkontekstdiagram, der
giver en overordnet beskrivelse af den påtænkte tekniske løsning og det miljø, den skal
indgå i. Det vil sige at der både skal være en overordnet beskrivelse af det it-system der
skal (videre)udvikles og af de vigtigste integrationer til andre it-systemer. De fleste af
de udvalgte arkitekturprodukter i kolonnen konceptuel kan påbegyndes og bidrage til
beskrivelsen af målarkitekturen.
Analyse Her er fokus på at afklare, uddybe og beskrive målarkitekturen, som grundlag for ud-
bud og leverandørens udarbejdelse af løsningsarkitekturen.
I denne fase sker der en uddybning og modning i form af den overordnede målarkitek-
tur, på logisk niveau. Alle de udvalgte arkitekturprodukter bør overvejes i denne fase.
Målarkitekturen udfoldes, men er stadig ikke konkretiseret fuldt ud. Løsningsoverblik-
ket i kolonnen Fysisk kan omfatte de dele af den fremtidige arkitektur der allerede fin-
des / er kendt.
Den bør så vidt muligt dokumenteres i en sammenhængende arkitekturmodel (i Archi-
mate) suppleret med detaljerede modeller for fx processer (fx i BPMN), begreber og
data (i UML/RDF) og use case (fx i UML) og som endelig udmøntes i en kravspecifika-
tion. Detaljeringsgraden af såvel arkitekturmodeller som kravspecifikation afhænger af
den valgte udviklingsmetode.
Afhængigt at projektet kan der være behov for at dykke særligt langt ned i enkelte om-
råder med henblik på at kunne identificere særlige udfordringer og krav. Det kan fx
være forretningskrav til funktionalitet eller snitfalder der skal følge fællesoffentlige
standarder. Eller det kan være andre udfordringer knyttet til sikkerhed fx i forbindelse
med genudbud eller opgradering og videreudvikling af et eksisterende system. ”Deep
dives” bør laves der hvor det er nødvendigt som grundlag for at udarbejde en kravspe-
cifikation såvel som en business case og risikoanalyse på et detaljeniveau som svarer til
den konkrete projektkontekst.
26
Det er i den sammenhæng væsentligt at understrege, at (mål)arkitekturen bør bringes i
direkte forbindelse med business case og risikoanalyse. Det vil bidrage til at højne rea-
lismen og kvaliteten i alle tre produkter. Arkitekturen er især vigtig i forhold til at bi-
drage til overblik over elementer i løsningen, deres logiske sammenhæng og kan bi-
drage til nøjagtighed i estimering af økonomi og risici. Ligesom business casen og risiko-
analysen bør (mål)arkitekturen løbende opdateres – og dette skal naturligvis ske på
tværs af de tre produkter. Arkitektur bør i overbliksformat være ”allestedsnærvæ-
rende” og ”tilgængeligt” som bilag til drøftelser og beslutninger. Ved rettelser / udspe-
cificering af arkitekturen skal denne kunne give grundlag for underbygget opdatering af
business case og risikoanalyse.
Som udgangspunkt bør de fleste af de udvalgte arkitekturprodukter udarbejdes i denne
fase. Og mange af disse bør opdateres i senere faser. Udvalgte produkter der skal an-
vendes i drift og videreudvikling skal eventuelt vedligeholdes løbende.
Gennemførelse Hvis der er tale om anskaffelse og ikke blot egenudvikling starter denne fase med en
anskaffelsesfase3, hvor der udarbejdes en kravspecifikation. Denne udarbejdes med re-
levant detaljeringsgrad, alt afhængig af projektets kontekst. Til dette arbejde er de arki-
tekturprodukter, der allerede er udarbejdet et centralt input. Disse opdateres og sup-
pleres evt. med yderligere arkitekturprodukter, hvor relevant, så de kan anvendes som
bilag til kravspecifikationen. Da det typisk er i denne fase, at der kommer jurister ind
over kravspecifikationen, kan der opstå behov for at arbejde med både kravformulerin-
ger og de modsvarende arkitekturprodukter. Dvs. at der her kan være behov for en tæt
dialog mellem arkitekter og jurister.
I denne fase konkretiseres og uddybes arkitekturen til en egentlig løsningsarkitektur.
De mange enkelte arkitekturprodukter konsolideres og løsningsoverblikket opdateres
løbende.
I denne fase er leverandøren en vigtig deltager i dokumentationsarbejdet. Igen afhæn-
ger det af den valgte udviklingsmetode. I denne fase bør man bygge videre på og vedli-
geholde de arkitekturprodukter, som er udarbejdet i de foregående faser.
Desuden vil der typisk være en lang række løsningsnære arkitekturprodukter, som bør
udarbejdes. I denne fase vil der typisk blive behov for at udarbejde dokumentation, der
rækker ud over de udvalgte produkter. Fx løsningsnær dokumentation til brug for kon-
figuration, test og drift.
3 I en tidligere version af statens it-projektmodel var dette en selvstændig fase mellem analyse- og gennemførelsesfasen.
27
Realisering I denne fase er der primært tale om anvendelse og vedligehold af de blivende produk-
ter i forbindelse med drift, vedligehold og videreudvikling.
I denne fase skal man være særligt opmærksom på konfigurationsdokumentation og på
opdatering af arkitekturbeslutningsloggen (hvor det er relevant), samt på opdatering af
de grundlæggende arkitekturmodeller.
Nedenstående figur illustrerer (groft forenklet) fokus i disse hovedfaser i forhold til fo-
kus i reolen.
FIGUR 12 FOKUS PÅ ARKITEKTURPRODUKTER I FORHOLD TIL PROJEKTERS HOVEDFASER
Arkitekturprodukter i agile projekter Der er mange der spørger om hvordan man arbejder med arkitektur i forbindelse med
agile udviklingsmetoder som Scrum og Scaled Agile (SAFE).
Set ud fra arkitektens synspunkt er det indlysende at bruge agile metoder i et løsnings-
projekt, fordi agile værktøjer som eksempelvis Scrum netop lægger op til at skabe bro
mellem teknik og forretning gennem en tæt dialog – hvilket er it-arkitektens fornemste
opgave. Når man kører Scrum er man – i fællesskab i Scrum-teamet - tvunget til at for-
klare, hvad behovet er, hvordan man vil løse det, udvikle det og bagefter forklare, hvor-
for man har gjort det på den måde, og hvad man har lært. Men koblingen til det bre-
dere enterprise-perspektiv og de klassiske arkitekturrammeværker og metoder kan
være en udfordring. Dette emne er stadig ret umodent.
Kernen i den agile tilgang er beskrivelser af funktionelle behov i form af Epics, Capabili-
ties, Features og Stories. Disse fire artefakter er centrale for design og udviklingsarbej-
det. Epics er den overordnede beskrivelse. En vision og et målbillede kan således siges
28
at bestå af en række Epics på det mest overordnede niveau. Epics kan nedbrydes i Ca-
pabilities. Her er man stadig typisk på det konceptuelle niveau i arkitekturen. Capabili-
ties kan igen nedbrydes til features, hvor det bliver relevant at arbejde mere logisk og
stringent. Med nedbrydningen af features til Stories er man typisk på det konkrete ni-
veau, som er styrende for den fysiske udførelse. Dette er illustreret i nedenstående fi-
gur.
FIGUR 13 SAMMENHÆNG MELLEM BESKRIVELSESNIVEAU I SAFE OG FDA REOL
Hvilke arkitekturprodukter der er relevante at udarbejde afhænger dels af den kon-
krete kontekst – dvs. indholdet i en given Epic, Capability, Feature, Story.
I projektplanlægningen vil man typisk kende Epics og Capabilities først. Disse kan give
et overordnet billede af arkitekturproblemstillinger og dermed behov for arkitekturpro-
dukter. Er der tale om effektivisering af processer, så er opgaveperspektivet særlig vig-
tigt. Er der tale om tværgående deling og genbrug af data på tværs af domæner, så er
informationsperspektivet særlig vigtigt. Er der tale om et system med mange kompo-
nenter og integrationer, så er applikationsperspektivet særlig vigtigt. Er der tale om mi-
grering til en ny cloudbaseret platform så er infrastrukturperspektivet vigtigt.
I et agilt set-up vil det dog typisk først være når man når frem til at arbejde med en
konkret Feature og Story at man bliver skarp på behovet for konkrete arkitekturpro-
dukter. Er der fx fokus på processer, funktioner, data eller applikationer i den givne
story?
Dette er illustreret i nedenstående figur
29
FIGUR 14 SAFE PRODUKTER KAN DÆKKE ALLE PERSPEKTIVER I FDA REOLEN
Endelig er der en pointe i forhold til krav. I ethvert projekt er der både funktionelle og
nonfunktionelle krav. I et klassisk vandfaldsprojekt og i et virksomhedsperspektiv (en-
terprise arkitektur) samles krav i en kravspecifikation/kravsamling. I det agile setup er
funktionelle krav formuleret som Epics, Capabilities, Features og Stories. Som led i do-
kumentationen af en løsning kan en konsolideret samling af disse udgøre en del af
kravsamlingen.
I den agile proces er der typisk mange iterationer, hvorfor det er vigtigt at finde en
ramme for governance i forhold til udvikling og vedligehold af arkitekturprodukter, så
de giver maksimal værdi – både inden for det enkelte projekt, i relaterede projekter og
fremadrette i forhold til drift og enterprise arkitekturfunktion.
Nedenstående figur illustrerer den løbende konkretisering af de overordnede behov,
som er defineret som Epics og som nedbrydes i Capabilities og derefter til features og
endelig til de detaljerede User Stories, der anvendes til at definere konkrete krav og
opgaver der skal udføres i løsningsudviklingen. I realiseringsfasen kan de definerede
user stories aggregeres og konsolideres til forretningsmæssige user stories, der kan
give værdi som blivende dokumentation til støtte for revision, drift, vedligehold og vi-
dereudvikling.
30
FIGUR 15 SAFE PRODUKTER BERIGES GENNEM PROJEKTPROCESSER OG KAN GIVE VÆRDI SOM
BLIVENDE DOKUMENTATION
Det er endnu kun få danske myndigheder der er gået i gang med at anvende den agile
tilgang i stort omfang og erfaringerne er stadig begrænsende. Digitaliseringsstyrelsen
modtager derfor gerne input om dette med henblik på en fremtidig justering af næ-
rende retningslinjer, så de understøtter den agile tilgang bedste muligt.
Generelt om prioritering Hvor skal man lægge kræfterne? Hvor skal man fx lægge snittet mellem kundens og le-
verandørens ansvar for at udarbejde og vedligeholde dokumentation? Og hvor mange
kræfter skal man bruge på dokumentation af den eksisterende arkitektur (as-is) versus
den kommende (to-be)?
Det er svært at sige noget generelt om prioritering af arkitekturdokumentation, men
myndigheden skal som kunde fokusere på de forretningsmæssige forhold og behov.
Man skal naturligvis forholde sig til de overordnede spørgsmål vedr. teknikken, men fx
ikke fokusere for meget på infrastruktur, da det i stigende grad er muligt at bygge pak-
keløsninger, fx i form af cloubaseret Platform as a Service (PaaS). Samtidig er der for en
tendens til outsourcing af hele funktioner og opgavesamarbejder ”ud af huset”, som
leder frem til økosystemer og dermed behov for større fokus på eksterne services og
integrationer, som skal være effektive og sikre – og så nemme og billige at etablere og
vedligeholde som muligt.
Lad gerne leverandøren stå for analyse og dokumentation på de løsningsnære aspekter
i forhold til data, applikationer og infrastruktur. Særligt detaljeret information om den
tekniske løsning bør tilvejebringes, vedligeholdes af leverandøren – og deles med kun-
den efter behov og aftale. Figur 16 Kundens og leverandørens fokus illustrerer hvor der
– groft sagt – typisk lægges et snit i mellem kundens og leverandørens fokus i arkitek-
turarbejdet sat i forhold til reolen.
31
FIGUR 16 KUNDENS OG LEVERANDØRENS FOKUS
I forhold til vægtens mellem at dokumentere den nuværende arkitektur i forhold til
den fremtidige kan det ofte bedst betale sig, at fokusere kræfterne på analyse og doku-
mentation af to-be i forhold til forretningsarkitekturen. Til gengæld vil det ofte være
vigtigt, at der er en god viden om as-is i forhold til it-arkitekturen. Særligt applikations-
landskabet med integrationer skal være tilstrækkeligt dokumenteret til at analysere ud-
fordringer, gap og konsekvenser i forhold til de ændringer, som projektet indebærer.
Governance for arkitekturprodukter Dette afsnit beskriver forskellige forhold omkring udvikling, vedligehold og anvendelse
af arkitekturdokumentation.
På udvalgte områder er det væsentligt, at der anvendes ensartede metoder. Disse ud-
dybes i FDA retningslinjer og vejledninger, der præciserer god praksis i forhold til hvilke
elementer, relationer og øvrige informationer der bør indgå i produkterne.
Dette gælder udvalgte produkter til støtte for projektgrundlag (fx til behandling i FODS
styregrupper og i Statens It-råd) og til arkitekturreview (fx til behandling i FODS re-
viewboard).
Ved udarbejdelse af arkitekturprodukter er det vigtigt at være opmærksom på føl-
gende:
Dokumentationen bør – hvor det er relevant - udarbejdes med tydelige refe-rencer til strategier, handlingsplaner, rammearkitektur, referencearkitektur og byggeblokke, der er gældende for projektet/løsningen.
En række produkter bør så tidligt og vidt muligt udarbejdes med brug af rele-vante uddybende retningslinjer og vejledninger, der fastlægger bedste praksis.
32
Som eksempler på vejledninger kan nævnes Introduktion til FDA rammearkitektur, Vej-
ledning om anvendelse af Archimate og Regler for begrebs- og datamodellering.
Udvikling og vedligehold af arkitekturprodukter De fleste arkitekturprodukter udvikles, forfines, detaljeres og vedligeholdes løbende i
det enkelte projekt, og hvor det er relevant på tværs af projekter. Derfor er det vigtigt
dels at afklare forventninger til kvaliteten af et arkitekturprodukt på et givent tidspunkt
dels at afklare hvilke arkitekturprodukter der primært ”bor” i det enkelte projekt og
hvilke der bor andetsteds, og eventuelt på tværs af flere projekter. Fx kan der være da-
tamodeller, som skal anvendes i et projekts løsning, men som ejes andetsteds.
Det er også vigtigt at være opmærksom på, at det er god praksis at starte med at bygge
et enkelt grundlag for arkitekturmodellen og for forskellige visninger, ved at opbygge
områder i arkitekturen som samlinger eller grupper. Fx en samling af mål, principper,
processer, forretningsobjekter eller applikationer. Når man har styr på de enkelte sam-
linger kan man udvikle mere sammenhængende visning på tværs af disse. Det kan fx
være i form forretningsservices der anvender hvilke applikationer eller hvilke forret-
ningsobjekter der udveksles via hvilke snitflader mellem applikationer. Man kan også
lave såkaldte fodspor (”footprints”), som viser den røde tråd fra fx et mål eller princip
til forretnings- og applikationsservices.
Dokumentationen udarbejdes, så der er sammenhæng og konsistens mellem arkitektprodukter, fx således at procesmodeller bruger begreber og attributter fra begrebs- og datamodellen. På den måde kan man bedre holde styr på, hvor ændringer ét sted vil kunne have konsekvenser.
Du kan læse mere om udvikling af arkitekturdokumentation i Vejledning om arkitektur-
metode.
Midlertidig versus blivende dokumentation Det er vigtigt at skelne mellem blivende dokumentation, som fx skal anvendes i forbin-
delse med drift og videreudvikling, og dokumentation, der alene er til anvendelse i for-
bindelse med udviklingsprocessen i et projekt. De grundlæggende arkitekturmodeller
er eksempelvis et blivende aktiv, der bør vedligeholdes og være tilgængelig i forbin-
delse med drift, vedligehold og videreudvikling, mens mange konkrete visninger ikke er
relevante, når løsningen er udviklet, og derfor kan arkiveres. Det sidste gælder især
den dokumentation, der udarbejdes i de tidlige faser, og som evt. er erstattet af anden
og opdateret dokumentation.
Arkitekturdokumentation og modenhed Endelig er det vigtigt at tage højde for den organisatoriske modenhed der er i projek-
tet, herunder særligt i forhold til
Kompetencer – her forstået som evnen til at forstås, udarbejde og anvende ar-kitekturprodukter,
33
Governance – her forstået som evnen til at sikre at leverancer udarbejdes, an-vendes og vedligeholdes og
Konfigurationsstyring – her forstået som evnen til at styre samlingen af arkitek-turelementer og arkitekturprodukter, herunder styring, dokumentation og kommunikation af versionering, ændringer og ændringsønsker.
Anbefalinger i forhold til den enkelte løsning / projekt Disse retningslinjer vedrører primært dokumentation af løsninger, som udarbejdes i
regi af digitaliseringsprojekter. Det anbefales, at der for det enkelte projekt / løsning
For hver løsning bør der være en overordnet beskrivelse af strukturen i doku-mentationen. Dvs. hvilke arkitekturprodukter der udarbejdes og hvordan de hænger sammen.
Sørg for en tværgående governance, der sikrer, at den fornødne dokumenta-tion udarbejdes og vedligeholdes – også når udviklingsprojektet lukkes og løs-ningen overgår til drift.
Relevant arkitekturdokumentation bør gøres tilgængeligt for relevante mål-grupper via relevante udstillingsplatforme.
Anbefalinger til den enkelte organisation Dette afsnit indeholder fem overordnede anbefalinger til, hvordan man som organisa-
tion kan komme i gang med gode praksis i forhold til arkitekturprodukter. De er inspire-
ret af tilsvarende anbefalinger vedrørende begrebs- og datamodellering, hvor de fem
anbefalinger understøttes af en fælles metoderamme med regler, værktøjer, ressour-
cer og kompetenceudvikling. Se publikationen God begrebs- og datamodellering i det
offentlige – 5 organisatoriske anbefalinger.
Hvis man som organisation ønsker at arbejde med arkitekturprodukter på en ensartet
og struktureret måde anbefales følgende tiltag:
1. Betragt arkitekturprodukter som potentielt forretningskritiske aktiver Vurder og prioritér hvilke arkitekturprodukter, der er forretningskriti-
ske fx til udvikling, drift og eksternt samarbejde 2. Placér organisatorisk ansvar for arkitekturprodukter
Sørg for at der er et klart ansvar for udarbejdelse, vedligehold og an-vendelse (genbrug) af arkitekturprodukter
3. Fastlæg processer, metoder og værktøjer til arkitekturprodukter Understøt sammenhæng mellem arkitekturprodukter på tværs af dem
der skal udarbejde dem og dem der skal anvende dem 4. Sikr tilstrækkelige kompetencer og ressourcer til modellering
Sørg for at organisationen har evnen til at udvikle, vedligeholde, kvali-tetssikre og anvende arkitekturprodukter. Det gælder også leverandø-rer
5. Vedligehold et overblik over organisationens arkitekturprodukter Sørg for at organisationen har evnen til at finde og anvende arkitektur-
produkter. Det gælder for relevante produkter også samarbejdsparter og leverandører.
34
Alle organisationer har en mængde eksisterende arkitekturdokumentation udarbejdet i
relation til tidligere projekter og eksisterende systemer. En del af denne dokumenta-
tion kan være vigtige aktiver, som bør indgå i den fremadrettede arkitekturdokumenta-
tion. I givet fald bør man overveje følgende:
Er der arkitekturprodukter og anden dokumentation, der skal opmærkes og ud-stilles i forhold til FDA reolen og dens produkter, således af den er nem at finde og relatere til den dokumentation der udvikles fremadrettet?
Er der arkitekturprodukter, der bør revideres, således at de kommer til at følge FDA retningslinjerne? Fx ved at følge modelregler, genbruge fælles terminologi, referere til FDA referencearkitekturer, principper, byggeblokke osv.?
Anbefalinger til tværgående governance Der vil kunne være situationer, hvor der er modstrid mellem et ønske om at udarbejde
modeller, der hænger sammen på tværs af sektorer, organisationer og de behov, der er
i den konkrete kontekst for en opgave. Det betyder, at for stram styring i forhold til
fælles regler kan indebære, at der ikke tages relevante hensyn til behov i det enkelte
projekt. Dermed kan der opstå en parallel dokumentationsopgave ud fra forskellige no-
tations- og modelsprog. Det vil påføre det enkelte projekt og dermed de enkelte myn-
digheder en væsentlig opgave i at kunne håndtere begge.
Den enkelte organisation bør så vidt muligt følge fællesoffentlige standarder og det enkelte projekt følge egen organisationsstandarder. Hvor der er tale om modstrid og et projekt, med betydelige eksterne interessenter, fx et fællesof-fentligt projekt, bør der tages konkret stilling til håndtering af dette i dialog med nøgleinteressenterne.
Hvor projekter identificerer fælles forretningskritiske arkitekturprodukter, bør der etableres et ansvar, evt. i form af et formaliseret samarbejde i form af et ”change-board”, der behandler modellers udformning, taksonomi og versione-ring. Overvej også om der er behov for en erfagruppe indenfor det pågældende samarbejdsdomæne med henblik på at dele viden og erfaringer vedr. konkrete modeller.
Modellering En væsentlig del af arkitekturdokumentation udarbejdes i form af modeller, der beskri-
ver arkitekturens elementer og sammenhæng på en logisk stringent måde og som kan
visualiseres som diagrammer suppleret med forklarende tekst.
Arkitekturprodukternes indhold bør (på sigt og så vidt muligt) kunne udarbej-des og gemmes som objekter der kan genbruges og krydsrefereres imellem.
Arkitekturprodukterne bør udarbejdes med brug af de fællesoffentligt udvalgte notations- og modelsprog.
Den enkelte myndighed/program/projekt kan have gode grunde til at foretage andre valg end dem, der peges på i disse retningslinjer. I givet bør man sikre sig, at dette er clearet med relevante nøgleinteressenter.
35
Notations- og modelsprog Et formelt notations- og modelsprog definerer et sæt af elementer, relationer, regler
og symboler til visuel repræsentation. Nærværende retningslinjer tager udgangspunkt i
at der ikke findes ét notationssprog, der dækker alle behov, og at det derfor er nødven-
digt at kunne anvende flere modelsprog ud fra formålet. For at sikre størst mulig sam-
menhæng i dokumentationen er der i regi af FDA udpeget en række udvalgte notati-
onsstandarder. Listen findes i bilag 4 i dette dokument.
Projekter bør således tage udgangspunkt i udpegede notationsstandarder for udarbej-
delse af modeller, hvor det er relevant. Notationssprog har hver deres målgrupper, fo-
kus, formål og styrker og svagheder. Det er derfor altid en konkret overvejelse, hvad
der bør anvendes til en given dokumentationsopgave.
I regi af den fællesoffentlige digitale arkitektur er følgende notationssprog fastlagt som
fælles modelsprog:
ArchiMate - til beskrivelse af den samlede arkitektur på højniveau. Fungerer bedst til at vise sammenhæng mellem forskellige lag i arkitekturen.
UML - Unified Modeling Language - til detaljeret beskrivelse af begreber og data.
Følgende notationssprog er identificeret som kandidater til fremtidige fællesoffentlige
modelsprog:
BPMN - Business Process Modeling Notation - til beskrivelse af forretningspro-cesser og detaljeret beskrivelse af arbejdsgange.
DMN - Decision Modeling Notation - til beskrivelse af regler.
At de er kandidater betyder, at der endnu ikke er taget en formel beslutning om at
vælge dem. Der er derfor heller ikke taget stilling til om der fx skal udarbejdes fælles
regler for deres anvendelse, jf. fx Regler for begrebs- og datamodellering.
ArchiMate er som modelsprog interessant særligt fordi, det kan dække alle grundper-
spektiver i arkitekturen. ArchiMate kan fx bruges til at skabe den røde tråd fra strategi
over processer til applikationer. ArchiMate er således godt til at understøtte en spor-
barhed og løbende at sikre en integritet i forholdet mellem arkitekturmodellen og den
konkrete løsning. ArchiMate har således et stort potentiale i forhold til styring af såvel
den enkelte løsning som en samlet portefølje.
ArchiMate henvender sig især til enterprise- og løsningsarkitekter, BPMN og DMN især
til forretningsarkitekter og UML især til dataarkitekter og til applikations- og teknologi-
arkitekter og udviklere.
Brug Archimate på konceptuelt og logisk niveau til overblik og de områder der ikke ud-
føres bedre med andre modelsprog.
36
Forskellige roller skal forstå og eventuelt mestre forskellige sprog og værktøjer:
Brug ArchiMate på konceptuelt niveau til arkitekter, men giv ledelsen alterna-tive visninger, der er ”rige” og letforståelige.
Projektlederen skal forstå ArchiMate på overordnet niveau og tilsvarende de specialiserede modelsprog, hvor det er relevant, typisk særligt i forhold til pro-cesser og applikationslandskab.
Specialister som fx forretning-, informations- og applikationsarkitekter som skal kunne forstå og anvende de specialiserede modelsprog korrekt i forhold til de opgaver og arkitekturprodukter, som de arbejder med.
Nedenstående figur giver et overblik over, hvor de forskellige notationssprog typisk vil
finde anvendelse ift. arkitekturreolen. Bemærk, at der i nogle af reolens hylder er flere
notationssprog. Dette skyldes, at der er forskellige typer af arkitekturbeskrivelser, der
kan være relevante. Fx ArchiMate til overblik over processer og forretningsobjekter. Til
den detaljerede modellering anvendes fx UML til modellering af begreber, information
og data, BPMN til modellering af arbejdsprocesser og DMN til modellering af forret-
ningsregler. Hård parentes [] angiver kandidater.
Bemærk at der yderst til højre er angivet ”rig visualisering”. Her er der stadig tale om
modeller, men ikke baseret på et formaliseret notationssprog. Modeller kan her være
”hvad som helst”. Det er typisk uformelle modeller med kasser, figurer og streger, men
det kan også være fx tegneserier, fotos, film og fysiske materialer i 2D eller 3D.
FIGUR 17 EKSEMPLER PÅ MODELSPROG MAPPET TIL FDA ARKITEKTURREOLEN
Fælles regler for modeller I FDA regi udarbejdes supplerende retningslinjer for modeller.
37
I første omgang er der udarbejdet regler for beskrivelse af begreber og logiske datamo-
deller i UML og en vejledning i brug af modelsproget ArchiMate til udarbejdelse af en
række af de andre arkitekturprodukter. På sigt kan der eventuelt og efter behov udvik-
les yderligere vejledning, skabeloner og eksempler til de nævnte arkitekturprodukter.
Modelleringsniveau Modellering er en måde at lave abstraktioner over og strukturere virkeligheden, så den
bliver mere overskuelig og enkel. Fx således at det tydeligt fremgår hvilke elementer,
der implementeres i it-systemer, og hvordan de hænger sammen.
Dvs. at modelarbejdet handler om at lave koncepter på et egnet niveau ift. formålet og
opgaven.
Når man modellerer er det vigtigt at vælge rette niveau og modelsprog. Som supple-
ment til de i indledningen nævnte pejlemærker for arkitekturarbejdet kan projektet
tage udgangspunkt i følgende tommelfingerregler:
Modellér til formål: Definér relevante perspektiver og tilhørende visninger ud fra det som projektets interessenter efterspørger på et givent tidspunkt.
Modellér på et egnet niveau: Tag udgangspunkt i, hvor langt projektet er og i den viden der forefindes, kan skaffes og at der er behov for den ift. formålet.
Modellér med et sprog egnet til opgaven: Tag højde for behov for detaljerings-niveau og egnede modelsprog ift. domænet, der skal beskrives.
Kommunikér så det forstås: Lav visninger, der kan forstås af modtageren. Det kan fx være en forsimpling af en formel model, som du har liggende bagved.
Dokumentér rationaler for det anvendte metodeapparat og notationsformer.
Figur 18 illustrerer, hvordan de forskellige modelsprog understøtter forskellige koncep-
ter og niveauer i arkitekturarbejdet.
38
FIGUR 18 ILLUSTRATION AF MODELSPROGS ANVENDELSE PÅ FORSKELLIGE NIVEAUER
På det øverste niveau finder man de mest abstrakte og generiske begreber og metamo-
deller, som er grundlag for al anden modellering. På enterprise-arkitekturniveau er der
tale om de begreber og modeller, som er nødvendige og tilstrækkelige til at give et
overordnet overblik, der kan gå på tværs af perspektiver. På det nederste niveau er der
de arkitekturdomænespecifikke modeller, der her er udtryk for specialiseret modelle-
ring typisk indenfor subdomæner i arkitekturen såsom processer, data, regler, use-ca-
ses, brugergrænseflader.
Sammenhæng på tværs af modeller Indenfor rammerne af det enkelte projekt og den enkelte løsning vil intern sammen-
hæng i den samlede arkitekturmodel altid være helt central. Også selvom der anvendes
forskellige modelsprog. Derfor er det også vigtigt, at tage stilling til hvordan dette sker i
praksis, fx ved anvendelse af et arkitekturværktøj, der understøtter genbrug og sam-
menhæng, således at eksempelvis en procesmodel genbruger begreber og attributter
fra datamodellen.
Hvis der er krav til eller behov for at skabe sammenhæng mellem modeller, der etable-
res i forskellige projekter, organisationer og domæner – og på tværs af modelsprog - er
det vigtigt at overveje, hvordan dette gøres mest hensigtsmæssigt.
Importer ekstern model i eget værktøj: Det er ofte det nemmeste, men kræ-ver at man har styr på håndtering af eventuelle og relevante ændringer i kilde-modellen.
Her er nogle generelle eksempler på tilgange, hvis man ikke råder over et værktøj, der
understøtter dette:
Ekstern reference: Lav en reference i en note til en model, der hvor du udstiller modellen. Det kræver blot en tekst og link, fx på en hjemmeside eller powerpo-int.
Intern reference i modelvisning: Lav en reference i en note inde i en visning (view). Det kræver, at der kan laves noter direkte på en visning i dit model-værktøj.
Intern reference i modelelement: Lav en reference i en dedikeret attribut i et modelelement. Det kan kræve konfiguration af attributterne i skabelonen i dit modelværktøj, så der er en note eller referenceattribut.
Vælg en tilgang, der svarer til behov og mulighed for vedligeholdelse af referencer.
Undgå tilsanding af modellerne. Modeller skal indkapsle kompleksitet og afskærme an-
dre modeller fra denne. Derfor skal man passe på med detaljer og relationer på tværs
af modeller. Man skal så at sige have styr på dimensionerne i modelarbejdet. Hvis en
model med eksterne reference skal leve længe, skal man have styr på håndtering af
versionering af det, som der refereres til.
39
Byggeblokke I arkitekturarbejdet er der et særligt begreb, som er centralt: Byggeblokke (forkortes
BB). En byggeblok er en fælles term for et aspekt i arkitekturen, som kan afgrænses
som et element, som (potentielt) kan genbruges, når man designer arkitektur/løsnin-
ger.
FDA anvender begrebet på baggrund af standarden The Open Group Architecture
Framework (TOGAF) og lægger sig desuden op ad den tilgang, som er udtrykt i The Eu-
ropean Interoperability Reference Architecture (EIRA). FDA anvender ligesom EIRA
byggeblokbegrebet i en bred betydning og der findes byggeblokke inden for alle de
otte grundperspektiver. Fx er et juridisk bindende instrument som en lov en væsentlig
byggeblok i et juridisk perspektiv i forbindelse med digitalisering. Her kan fx lov om di-
gital post ses som en løsningsbyggeblok, der sikrer fælles juridiske rammer for anven-
delse af digital post for alle myndigheder, borgere og virksomheder.
Som led i FDA opbygges et fællesoffentligt katalog over byggeblokke – dvs. de mest væ-
sentlige og genbrugelige dele af arkitekturen. Kataloget udstilles dels som Archimate
model dels som en taksonomi i regneark-format.
Kataloget kan anvendes som en tjekliste / plukkatalog, når man skal opbygge projektets
arkitekturmodel og som taksonomi, når man skal navngive elementer i sin egen arki-
tektur (sine egne byggeblokke). FDA-byggeblokkataloget har ligesom EIRA fokus på det,
der er vigtigt for interoperabilitet og digital sammenhæng. Du kan læse mere om dette
i dokumentet Introduktion til Fællesoffentlig Rammearkitektur og du kan finde et kata-
log over byggeblokke på FDA hjemmesiden.
Byggeblokke kan relateres til arkitekturer eller til løsninger. Der findes to grundtyper af
byggeblokke. En arkitekturbyggeblok (forkortes ABB) er en abstrakt, men veldefineret
delmængde af arkitekturmodellen. Der findes logisk set kun én af hver arkitekturbygge-
blok. En løsningsbyggeblok (forkortes LBB) modsvarer en arkitekturbyggeblok, men er
konkret og kan anvendes i en konkret løsning. Der kan være flere løsningsbyggeblokke,
der kan realisere en arkitekturbyggeblok. En løsningsbyggeblok kan fx være en konkret
og detaljeret specifikation af en proces, service, applikation eller produkt. Og det kan
være et konkret fysisk produkt eller løsning - fx et standard CMS eller en fællesoffentlig
infrastrukturservice som Digital Post. Og som nævnt ovenfor kan både arkitektur- og
løsningsbyggeblokke findes indenfor alle otte perspektiver, hvis de (potentielt) kan
genbruges.
En byggeblok kan kombineres med andre byggeblokke til at levere arkitekturer eller
løsninger. En byggeblok kan også være sammensat af andre byggeblokke. Byggeblokke
kan således defineres på forskelligt detaljeniveau afhængig af, hvilken fase arkitektur-
udviklingen er på. Fx kan en byggeblok på et tidligt tidspunkt blot være et navn eller en
40
skitseret beskrivelse eller specifikation. Senere kan en byggeblok nedbrydes i flere de-
taljerede byggeblokke og suppleres med detaljerede specifikationer.
Når man beskriver arkitekturen, sker det på flere måder alt afhængigt af, hvad der er
relevant i den konkrete kontekst. Nedenstående eksempel viser tre måder at beskrive
en forretningsservice på. Den første visning er forenklet til en forretningsservice bygge-
blok, den anden vist som en opdeling i seks adskilte byggeblokke, og den sidste viser
disse seks som en gruppering. Alt efter behov kan man tale om servicen som en helhed
eller om de forskellige dele. Dette er fx relevant, når man skal afklare, hvor der skal af-
tales egenskaber og fælles standarder.
Simpel fremstilling, hvor én service an-vendes til at illu-strere en større, men skjult komplek-sitet
En mere udfoldet fremstilling, hvor flere elementer er vist som selvstændige byggeblokke
En gruppering, hvor en række byggeblokke er sam-mensat til en helhed i form af en gruppe
FIGUR 19 ILLUSTRATION AF FORMIDLING AF BYGGEBLOKKE PÅ FORSKELLIGT DETAILNIVEAU
Værktøjer og formater Når man skal modellere kræver det et egnet værktøj. De forskellige modelsprog stiller
forskellige krav til værktøjernes egenskaber. Nogle værktøjer understøtter flere model-
sprog, mens andre er specialiserede.
Nærværende retningslinjer kræver ikke anvendelse af særlige værktøjer. En myndig-
hed, leverandør eller projekt må derfor vælge det værktøj, der understøtter det kon-
krete behov. Man skal dog sikre sig, at det valgte værktøj understøtter de rette versio-
ner af modelsprog og udvekslingsformater.
Bilag 4 Liste over modelsprog og udvekslingsformater beskriver anbefalede versioner af
modelsprog og udvekslingsformater.
Hvis man udveksler mellem to ens værktøjer, kan man godt udveksle med proprietært
format, men når man skal dele på tværs af værtøjer, herunder publicere i fællesoffent-
lige kataloger, bør det ske med brug af et FDA-anbefalet åbent udvekslingsformat.
Sekretariatet for FDA vil efter behov understøtte udvalgte modelsprog i enkelte værk-
tøjer. Det kan være med skabeloner, kompetenceudvikling og lign.
41
Udstilling, deling og genbrug af arkitekturmodeller I forbindelse med udveksling og deling af arkitekturprodukter kan der naturligvis være
behov for og værdi i at dele fx modeller og diagrammer i originalt format.
Som hovedprincip anbefales det, at dele og udveksle arkitekturprodukter som mini-
mum i pdf. Det giver en garanti for at afsender og modtager kan læse og se det samme.
Modeller udført i samme modelsprog og udvekslet i fælles format kan stadig opføre sig
forskelligt i forskellige værktøjer.
Navngivning Det er hensigtsmæssigt, at arkitekturprodukter gives et meningsfyldt og anvendelses-
neutralt navn, for så vidt det er intentionen, at de skal kunne læses, anvendes og gen-
bruges af andre, og det vil lette formidling, fremsøgning og anvendelse.
Arkitekturprodukter bør forsynes med meningsfyldte navne, der refererer til et eller
flere af disse:
Arkitekturproduktets navn, hentes fx fra FDA-listen over arkitekturprodukter i bilag
3, jf. ovenstående reol i figur 9.
Det faglige domæne, fx it-fagligt ”brugerstyring” eller forretningsfagligt ”bolig-
støtte”
Den centrale del af arkitekturen som beskrives, fx applikationsbyggeblokken ”orke-
streringskomponent”, hvor det er relevant kan navne evt. hentes fra FDA bygge-
blokkataloget
Kontekst for konkret anvendelse, fx i forbindelse med det konkrete system ”xx fag-
system”.
Navngivningen bør både afspejles i en titel på repræsentationen (det artefakt / doku-
ment, som man ser) og i selve filnavnet (til fremsøgning i fx en stifinder).
Efter navnet bør angives versionsnummer og dato for seneste opdatering. Igen gerne i
både repræsentation og filnavn.
For at vise sammenhæng i flere arkitekturprodukter kan der fx anvendes præfix til at
organisere filer. For projekter i den fællesoffentlige digitaliseringsstrategi kan det fx
være: FODS-I8.1-P4_xxx. Hvilket er kort form for FODS = Fællesoffentlig digitaliserings-
strategi, I8.1 = Initiativ 8.1, P4 = Projekt 4.
Konfigurations- og versionsstyring Det er grundlæggende et lokalt ansvar at holde styr på konfiguration og versionering i
forhold til arkitekturprodukter og arkitekturmodeller. Det kræver stor organisatorisk
42
modenhed at styre versionering på tværs af domæner, og er derfor meget svært. Det
bør tilstræbes, at der indenfor et domæne (organisation / fagområde) så vidt muligt er
en ensartet governance og metodik omkring versionsstyring.
Det anbefales, at alle arkitekturprodukter så vidt muligt forsynes med versionsnummer
og dato for seneste opdatering. Dette er væsentligt både for den interne konfigurati-
onsstyring og ikke mindst for andre brugere af et arkitekturprodukt.
Ved at arkitekturprodukter forsynes med oplysninger om versionering og seneste op-
dateringsdato, bliver det lettere for brugeren at vurdere, om produktet eller elementer
herfra kan anvendes til et bestemt formål. Brugeren kan blandt andet let afgøre, hvil-
ken version af et specifikt arkitekturprodukt, der er den nyeste, og hvornår der sidst er
sket ændringer i produktet.
Det anbefales at arkitekturproduktets seneste opdateringsdato og versionsnummer så
vidt muligt tager udgangspunkt i følgende metode (som her er inspireret fra tilsvarende
regler for begrebs- og datamodellering):
Dato opbygges med formatet yyyy.mm.dd. Angiv 'seneste opdateringsdato' = fx 2017-10-25 [https://www.w3.org/TR/xmlschema-2/#dateTime],
Versionsnummer opbygges med brug af udfaldsrum med en major-version, mi-nor-version og revision adskilt med punktum, fx:1.0.1 [https://semver.org/ ]
Hvor det er relevant og værktøjet understøtter det, er det godt at opmærke arkitektur-
produkter og modeller med tidligere og nyere versioner. Angiv fx ”Denne version”, ”Se-
neste version” (kan være den samme) og ”Tidligere version”.
For identifikation og versionering af de enkelte elementer i modeller henvises til detal-
jerede regler og vejledninger, hvor de findes, såsom de fællesoffentlige regler for be-
grebs- og datamodellering.
43
Bilag 1: Tjekliste vedrørende arkitekturdokumentation Denne tjekliste er beregnet til at projektleder og arkitekt sammen kan planlægge arbej-
det med arkitekturdokumentation i et projekt. Den uddyber tjeklisterne i dokumentet
Introduktion til fællesoffentlig rammearkitektur.
Særligt det første og det sidste punkt i tjeklisten har typisk projektlederen som primær
driver, mens de øvrige typisk udføres af arkitekturspecialister.
Tjeklisten kan anvendes flere gange i løbet af et projekt. Brug den initialt til at få over-
blik over hvad der skal tænkes ind i projektet og genbesøg den undervejs i projektet.
Måske er der behov for at genbesøge planen, stramme op på metoden eller en påmin-
delse om, hvad man skal huske at gøre, fx i forhold til at dele projektets dokumenta-
tion.
Nr. Emne Tjek
1. Lav en plan for projektet arkitekturprodukter:
Arkitekturproduktet Metodeanvendelse beskriver den anvendte frem-gangsmåde med tilhørende arkitekturprodukter, som indgår i projek-tets leveranceplan. Omfatter tilpasning af metoder og notationer til projektets kontekst. Vedligeholdes gennem projektetslevetid.
Lav en overordnet plan for udarbejdelse af arkitekturdokumentation, som en del af projektplanlægningen. Planen bør omfatte hvilke arkitek-turvisninger, der skal udarbejdes og krav til kvalitet (fx niveau af detal-jer).
Planen bør overordnet tydeliggøre hvilke roller der skal udarbejde, bi-drage til og anvende produkterne samt krav til timing, således at det er klart hvilke forventninger, der er til hvad der skal laves hvornår, og i hvilken kvalitet. Husk at tage højde for projektets udviklingsmetode (fx vandfald, agil) og at der læres undervejs.
Afklar formelle arkitekturleverancer med projektets styregruppe. Brug en arbejdsgruppe og arkitekt til støtte og dialog om øvrige arkitektur-produkter der er relevante for projektet. Benyt eventuelt muligheden for rådgivning fra sekretariatet for initiativ 8.1. Tag udgangspunkt i li-sten over udvalgte arkitekturprodukter.
Afklar hvilken dokumentation, der bør være i forbindelse med projekt-grundlag og review, fx arkitekturreview i regi af styregruppen for data og arkitektur. Som minimum anbefales vision/målbillede og et system-kontekstdiagram, der giver en overordnet beskrivelse af den påtænkte tekniske løsning og det miljø, den skal indgå i.
Afklar hvilken dokumentation, der skal være blivende og derfor skal underlægges eventuelle særlige krav til kvalitetssikring og vedligehold.
2. Etabler projektets arkitekturmetode:
44
Lav på baggrund af nærværende retningslinjer - og en evt. fælles stan-dard på organisationsniveau - en tilpasset metode og valg af notation og formater for visninger, der kan understøtte projektets plan for udar-bejdelse af arkitekturdokumentation.
Dette omfatter også plan for anvendelse af værktøjer, udvekslingsfor-mater, navngivning og versionsstyring, som bør være på plads så tidligt som muligt.
Til den overordnede arkitekturmodel (helhedsoverblik) anbefales mo-delsproget Archimate. Anvend FDA Vejledning om brug af ArchiMate.
Til begrebs og datamodeller anbefales UML. Anvend FDA Regler for be-grebs- og datamodellering.
Til andre detaljerede modeller anvendes relevante metoder og notati-onssprog som fx BPMN, DMN, UML, wireframes.
3. Udarbejd arkitekturprodukter
Start med en overordnet skitse over den samlede arkitektur i projektet. Start gerne med en kombination af relevante abstrakte arkitekturbyg-geblokke og kendte konkrete løsningsbyggeblokke.
Fokuser i første omgang på formål/forretningsbehov, forretningsopga-ver og forretningsobjekter samt applikationslandskabet med integrati-oner – og identifikation af de væsentligste udfordringer! Fx hvor er der behov for at gå i dybden med hensyn til optimering af arbejdsgange el-ler standardisering af snitflader?
Udarbejd og vedligehold løbende arkitekturmodeller og andre arkitek-turprodukter efter princippet ”til rette tid og i rette kvalitet”. Pas på med ikke at drukne i perfektionisme. Skitser er ofte nok til indledende afklaringer (”less is more”).
Tænk ”relevans” ifht timing, format og kvalitet ifht målgruppe og an-vendelseskontekst for en arkitekturvisning. Husk at visninger i form af fx et diagram skal kunne afkodes af målgruppen og typisk skal supple-res med mundtlig eller skriftlig forklaring, der kan sikre at væsentlige problemstillinger og muligheder står tydelige for interessenterne.
4. Brug fælles terminologi:
Udarbejd projektets arkitekturmodeller med brug af fælles termino-logi, fx defineret i regi af FDA, fagdomæne som fx sundhed eller i egen organisation.
Hav løbende fokus på at anvende fælles terminologi og begreber på tværs af de forskellige projektleverancer. Vær bevidst om oversættelse til lægmandssprog i fx ledelsesprodukter, således at der løbende tages højde for mulige misforståelser.
FDA terminologi findes via FDA hjemmesiden i bl.a. FDA-ordbogen, FDA-byggeblokkataloget og FDA-modelkataloget. Typisk fremgår både
45
foretrukne og tilladte termer, så man nemmere kan finde termer der matcher anvendelseskontekst og målgruppe.
5. Genbrug arkitektur og arkitekturbyggeblokke:
Orienter jer i relevante referencearkitekturer, hvor I dels finder de mål og principper, begreber og byggeblokke, som I skal tage stilling til om er relevante i projektet. Gennemgå relevante tjeklisterne.
Orienter jer ligeledes i fællesoffentlige kataloger over byggeblokke, modeller o.l. via FDA hjemmesiden.
Afsøg tilsvarende indenfor egen organisation og relevant(e) do-mæne(r). Opsøg og brug relevant eksisterende dokumentation.
Orienter jer så vidt muligt om andre projekter har en pipeline med le-verancer, der kan være relevante for jeres projekt, fx i form af nye refe-rencearkitekturer og standarder eller forskellige former for arkitektur-byggeblokke.
6. Genbrug løsninger og løsningsbyggeblokke:
Hav øje for om der i FDA regi eller i andet relevant domæne peges på konkrete løsningsbyggeblokke, som kan eller skal anvendes.
Identificer kandidater til konkrete løsningsbyggeblokke, som projektet kan genbruge og indarbejd dem i projektets arkitektur. De kan både være danske og internationale, fx fra EU.
Afsøg tilsvarende indenfor egen organisation og relevant(e) domæne(r) hvad angår løsninger, standarder, infrastrukturkomponenter mv.
Sørg også for at orientere jer i andre projekters pipeline, om der er løs-ningsbyggeblokke, der potentielt kan genbruges helt eller delvis af pro-jektet.
Dokumentér valg - og fravalg. Det gælder både i forhold til muligheder for at genbruge eksisterende løsningsbyggeblokke eller at bidrage med genbrugelige løsningsbyggeblokke.
7. Del projektets arkitekturdokumentation:
Tag stilling til hvordan ”det nye” bliver en del af den fremtidige helhed, dvs. hvordan kan projektets produkter fx indgå i FDA eller andet do-mænes fælles arkitektur og portefølje af løsningsbyggeblokke.
Sørg for at kommunikere eventuelle bidrag fra projektet til den fælles-offentlige rammearkitektur.
Sørg for at udstille relevant dokumentation på FDA hjemmesiden eller på anden relevant hjemmeside.
46
Bilag 2: FDA-grundperspektiver Dette bilag beskriver de otte grundlæggende arkitekturperspektiver i den fællesoffent-
lige digitale arkitektur (FDA).
FIGUR 20 DE OTTE GRUNDLÆGGENDE FDA-ARKITEKTURPERSPEKTIVER
For hvert perspektiv beskrives kort:
Arkitekturperspektiv – beskrivelse med angivelse af fokusemner.
Princip - reference til hvidbogens principper og arkitekturregler, som er særlig rele-
vante ift. perspektivet. Projekter skal kunne dokumentere hvordan disse realiseres.
Interessenter – udvalgte/særligt vigtige interessenter og eventuelt deres fokus.
Interesser - udvalgte eksempler på centrale/hyppige spørgsmål, der er relateret til
interessenternes interesser.
Det bemærkes, at de nævnte fokusområder og spørgsmål er generelle og eksempler.
Det enkelte projekt skal tage udgangspunkt i de konkrete interessenters konkrete
spørgsmål og behov for beskrivelse.
Fremstillingen er udformet med brug af reolens farvekoder således, at det er nemt at
orientere sig.
47
Styring
Arkitekturperspektiv med fokus på styring. Omfatter aktører, mål, indsatser, metoder og procedurer. Den politiske og organisa-toriske kontekst for beslutninger og ansvar ift. løsningens udvikling og drift. Overord-nede mål og gevinster, som skal realiseres. Aftalte programmer, projekter, fora, pro-cesser og procedurer til styring. Metode og dokumentation, der håndterer eller un-derstøtter dette. Principper P1 Arkitektur styres på rette niveau efter fælles rammer. AR 1.1: Styr på arkitekturen på rette niveauer og sammenhængende. AR 1.2: Optimér arkitektur efter projektet og de fælles mål. AR 1.3: Anvend fælles ramme for beskrivelse af arkitekturen. AR 1.4: Sørg for at projektets arkitektur reviewes. AR 1.5: Hav tilstrækkelige kompetencer til arkitektur-arbejdet. Interessenter
Ejer - især systemejer og program- og projektledelse.
Arkitekt/udvikler - især enterprise-arkitekt og løsningsarkitekt.
Governance-aktør - særligt aktører med ansvar for tværgående opgaveløsning, standarder og infrastruktur.
Leverandør - især leverandør af teknisk løsning og konsulenter.
Drift - især driftsansvarlig.
Interesser
Om løsningen giver forventede værdi.
Systemets potentielle risici og virkninger for dets interessenter i hele dets livscy-klus.
Hvem der har ansvar for de forskellige dele, der skal indgå, så de nødvendige be-slutninger kan tages på rette niveau.
Om løsningen lever op til krav til tid, budget, kvalitet.
48
Strategi
Arkitekturperspektiv med fokus på ønskede fremtidige tilstande. Omfatter visioner, målbilleder, strategiske kapabiliteter, som skal realiseres. Ud-fordringer og principper, som skal iagttages. Målarkitektur, migrationsstrategi med aftalte skridt på vejen (plateauer).
Principper P2 Arkitektur fremmer sammenhæng, innovation og effektivitet. AR 2.1: Anvend og udbyg den fællesoffentlige rammearkitektur. AR 2.2: Anvend åbne og internationale standarder. AR 2.3: Undgå afhængighed af leverandører og proprietære teknologier. AR 2.4: Byg forandringsparat med udgangspunkt i brugeren. AR 2.5: Stil data og løsninger til rådighed for private.
Interessenter
Ejer - især systemejer.
Arkitekt/udvikler - især enterprise-arkitekt samt forretningsarkitekt og løs-ningsarkitekt.
Governance-aktør - særligt aktører med ansvar for fælles byggeblokke i form af standarder, komponenter og infrastruktur.
Forretning - især forretningsledelse.
Leverandør - leverandør af teknisk løsning og konsulenter samt leverandør af teknisk infrastruktur.
Interesser
Systemets formål.
Arkitekturens egnethed til opnåelse af systemets formål.
Muligheden for at opbygge og implementere systemet.
Systemets egenskaber ift. vedligehold og udvikling.
Hvad er de strategiske mål og vejen til realisering.
49
Jura
Arkitekturperspektiv med fokus på digitaliseringens juridiske aspekter. Omfatter lovgivning og kontrakter som er juridisk rammesættende for løsnin-gens egenskaber samt for udbud, drift og anvendelse. Omfatter persondata- og registerlovgivningens aspekter ift. sikkerhed og privatliv.
Principper P3 Arkitektur og regulering understøtter hinanden. AR 3.1: Tag højde for juridiske bindinger ift. deling og genbrug af data og it-syste-mer. AR 3.2: Bidrag til digitaliseringsklar lovgivning.
Interessenter
Ejer - især systemejer.
Arkitekt/udvikler - især enterprise-arkitekt, løsningsarkitekt, applikationsar-kitekt og teknisk arkitekt.
Sikkerhedsaktør - især DPO og ansvarlig for implementering og drift af sik-kerhedsmodel samt ansvarlig for monitorering og cybersikkerhed.
Juraansvarlig - jurister og andre, der udarbejder og anvender kravspecifikati-oner.
Forretning - især ift. effektiv opgaveløsning.
Bruger - især som datasubjekt.
Dataejer/-behandler - især ift. roller og ansvar.
Leverandør - især leverandør af teknisk løsning.
Drift - især driftsansvarlig og systemoperatører.
Interesser
Hvilke lovmæssige bindinger løsningen skal leve op til.
Lovgivningsmæssige barrierer, der skal udfordres.
Juridiske bindinger ift. deling og genbrug af data og løsninger.
Hvilke funktionelle og nonfunktionelle krav løsningen skal leve op til.
50
Sikkerhed
Arkitekturperspektiv med fokus på sikkerhed og beskyttelse af data, så fortro-lighed, tilgængelighed og integritet sikres. Omfatter håndtering af trusler og sikkerhedsrisici. Krav til håndtering af sikker-hed og privatliv, herunder processer og regler (fx sikkerhedspolitikker og kon-troller), data (fx datapolitik og sikkerhedsklassifikation) samt relevante tekniske services (fx adgangs- og rettighedsstyring, log, monitorering, cybersikkerhed).
Principper P4 Sikkerhed, privatliv og tillid sikres. AR 4.1: Opfyld krav til informationssikkerhed og privatlivsbeskyttelse. AR 4.2: Anvend fælles arkitektur for informationssikkerhed.
Interessenter
Ejer - især systemejer.
Arkitekt/udvikler - især enterprise-arkitekt og løsningsarkitekt.
Sikkerhedsaktør - især DPO og ansvarlig for implementering og drift af sik-kerhedsmodel samt ansvarlig for monitorering og cybersikkerhed.
Forretning - især ift. krav til sikkerhed i opgaveudførsel.
Bruger - især som datasubjekt og ift. rettigheder.
Leverandør - leverandør af teknisk løsning og af teknisk infrastruktur.
Drift - især driftsansvarlig og systemoperatører.
Interesser
Systemets potentielle risici og virkninger for dets interessenter i hele dets livscyklus ift. sikkerhed og privatliv.
Hvordan brugerrettighedsstyring håndteres ift. persondata og fortrolige og følsomme data.
Hvilke(n) sikkerhedsmodel(ler), der anvendes, herunder til understøttelse af tværgående processer og datadeling.
Om der er styr på sikkerhed og privatliv end-to-end i løsningen.
51
Opgaver
Arkitekturperspektiv med fokus på den forretningsmæssige opgaveløsning og levering af service. Omfatter aktørers og rollers håndtering af forretningsinformation i processer ud-ført i forretningsfunktioner efter forretningsregler og leveret som forretningsser-vices via en grænseflade.
Principper P5 Processer optimeres på tværs. AR 5.1: Design sammenhængende brugerrejser. AR 5.2: Optimér tværgående processer efter fælles mål.
Interessenter
Ejer - især opgaveansvarlig og systemejer.
Arkitekt/udvikler- især forretningsarkitekt, løsningsarkitekt og enterprise-ar-kitekt.
Governance-aktør - særligt aktører med ansvar for tværgående serviceleve-ring gennem fx portaler (fx Digitaliseringsstyrelsen, Erhvervsstyrelsen, Sund-hedsdatastyrelsen, EU).
Sikkerhedsaktør - især ansvarlig for implementering af sikkerhed i organisati-onen og dens forretningsprocesser.
Forretning - ledelse, eksperter og medarbejdere.
Bruger - alle der skal løse opgaver via it-løsning.
Leverandør - af teknisk løsning, leverandør af teknisk infrastruktur.
Interesser
Hvilke brugerrejser, der skal understøttes, herunder om der er tværgående brugerrejser.
Hvilke forretningsbehov løsningen skal understøtte.
Hvilke opgaver, processer og funktioner, der påvirkes og skal understøttes af løsningen.
Om der er taget højde for opgaveløsning, der går på tværs fx i forbindelse med tværgående brugerrejser.
Information
52
Arkitekturperspektiv med fokus de informationer, der skal håndteres af såvel forretningen som af teknikken. Omfatter begreber, terminologi, data og repræsentationer af data. Sikring af ensartet beskrivelse og forståelse, datatilgængelighed og aftalt datakvalitet. Mu-lighed for sammenhængende genbrug og sammenstilling af data. Standarder for data og dokumenter.
Principper P6 Gode data deles og genbruges. AR 6.1: Del og genbrug data. AR 6.2: Anvend fælles regler for dokumentation af data. AR 6.3: Giv data den kvalitet, som efterspørges. AR 6.4: Udstil oplysninger om datakilder, begreber og datamodeller.
Interessenter
Ejer - især systemejer både som eventuel dataejer og som databehandler.
Arkitekt/udvikler - især informationsarkitekt og applikationsarkitekt ift. ud-vikling af informationsarkitekturen.
Governance-aktør - ejere af fælles byggeblokke i form af specifikationer (fx Digitaliseringsstyrelsen, EU med SEMIC, W3C og OASIS).
Sikkerhedsaktør - især DPO ift. klassifikation af data med henblik på håndte-ring af persondata og følsomme data.
Forretning - især ift. datas forståelighed, egenskaber og kvalitet ift. opgave-løsning.
Bruger - især ift. semantik og forståelse (borger, virksomhed, sagsbehandler) og tryghed ved data (datasubjekt).
Dataejer/-behandler – især dataafgrænsning, roller og ansvar.
Leverandør - især krav til datamodel og krav til eksterne snitflader og data-standarder.
Interesser
Hvilke forretningsobjekter og data, der skal behandles i løsningen.
Hvilke datasæt, der er berørt, hvad der er de autoritative datakilder og om eksterne data er tilgængelige.
Om der er styr på datas betydning og struktur og om datakvaliteten er i or-den.
53
Applikation
Arkitekturperspektiv med fokus på applikationskomponenter og -services, der understøtter forretningsservices. Omfatter applikationers funktioner og brugergrænseflader. Applikationers tekni-ske snitflader og roller og relationer i tekniske integrationer.
Principper P7 It-løsninger samarbejder effektivt. AR 7.1: Design og udstil snitflader efter fælles integrationsmønstre og tekniske standarder.
Interessenter
Ejer - især systemejer ift. funktionalitet, kompleksitet, robusthed og fleksibi-litet i koden i applikationer, services, snitflader og integrationer.
Arkitekt/udvikler - især løsningsarkitekt, applikationsarkitekt og udviklere (programmører) samt UX-ansvarlige.
Sikkerhedsaktør - især DPO og ansvarlig for implementering og drift af sik-kerhedsmodel.
Forretning - effektiv understøttelse af opgaveløsning.
Bruger - især ift. brugergrænseflade (UX og tilgængelighed).
Dataejer/-behandler - effektiv og sikker datadeling.
Leverandør - af teknisk løsning, særligt softwareleverandører og leverandø-rer med ansvar for integrationer.
Drift - især driftsansvarlig og systemoperatører.
Governance-aktør - ejere af fælles byggeblokke i form af tekniske specifikati-oner og open source komponenter (fx Digitaliseringsstyrelsen, EU med CEF Digital, W3C og IHE).
Interesser
Brugeroplevelse og om brugergrænsefladen er nem at bruge.
Hvilke applikationskomponenter, der indgår i løsningen (i dag og i fremti-den) og deres rollefordeling.
Hvilke eksterne services, interfaces og integrationer, der skal understøttes.
54
Infrastruktur
Arkitekturperspektiv med fokus på teknologi-services, som leverer den gene-relle infrastruktur. Omfatter teknologi, platform, hosting, integrationsinfrastruktur, brugerstyring, sikkerhedsinfrastruktur, netværk, protokoller.
Principper P8 Data og services leveres driftsikkert. AR 8.1: Levér data og services iht. aftalte servicemål.
Interessenter
Ejer - især systemejer. Ejere af fælles byggeblokke (fx Digitaliseringsstyrelsen og EU med CEF Digital).
Arkitekt/udvikler - især enterprise-arkitekt, løsningsarkitekt, applikationsar-kitekt og teknisk arkitekt.
Governance-aktør - ejere af fælles byggeblokke i form af tekniske specifikati-oner og infrastrukturkomponenter (fx Digitaliseringsstyrelsen, SDS, EU med CEF Digital, W3C og IHE).
Sikkerhedsaktør - især DPO og ansvarlig for implementering og drift af sik-kerhedsmodel samt ansvarlig for monitorering og cybersikkerhed.
Forretning - løsningens robusthed i understøttelse af opgaveløsning.
Leverandør - leverandør af teknisk løsning og af teknisk infrastruktur.
Drift - især driftsansvarlig, systemoperatører og support.
Interesser
Hvilket miljø løsningen skal indgå i (platform, lokalt landskab og større øko-system).
Hvordan infrastrukturen leveres.
Om infrastrukturen lever op til krav om sikkerhed og effektivitet.
Om infrastrukturen understøtter valgte sikkerhedsmodeller for (tværgå-ende) identitets- og rettighedsstyring.
Om der er den fornødne information til at supportere drift og brugere.
55
Bilag 3: Liste over udvalgte arkitekturprodukter Dette bilag definerer de udvalgte arkitekturprodukter i den fællesoffentlige digitale ar-
kitektur (FDA).
FIGUR 21 FDA-REOL MED UDVALGTE ARKITEKTURPRODUKTER
For hvert arkitekturprodukt beskrives kort:
Arkitekturproduktnavn – det navn som anvendes i regi af FDA. Der anvendes i prak-
sis ofte beslægtede navne og synonymer.
Beskrivelse (kort) – en kort beskrivelse af produktet. Der er ikke tale om en formel
definition.
Kommentarer – en uddybende beskrivelse af fx formål anvendelse, indhold og rela-
tion til andre produkter og sammenhæng til fx projektmodel.
Forslag til format – eksempler på typiske og anvendelige formater.
AR nr. - reference til hvidbogens arkitekturregler, som er særlig relevante ift. pro-
duktet. Kan støtte projekter i at forstå sammenhæng til hvidbogen, fx til kvalitets-
sikring af projektplan og til forberedelse til arkitekturreview.
Det bemærkes, at de nævnte produkter er udtryk for et generelt udvalg og skal opfat-
tes som eksempler. Det enkelte projekt skal tage udgangspunkt i de konkrete styrings-
rammer for projektet og i interessenters konkrete spørgsmål og behov for beskrivelse,
når de udvælger hvilke produkter der skal udarbejdes og hvornår.
Fremstillingen er udformet med brug af reolens farvekoder således, at det er nemt at
orientere sig.
56
Styring Arkitekturpro-
duktnavn
Beskrivelse (kort) Kommentarer Forslag til for-
mat
AR nr.
Governance-
model
Beskriver de overordnede organisa-
toriske rammer for at udøve gover-nance.
Skal sikre, at der etableres en ramme for governance,
der kan sikre, at målarkitekturen realiseres ved at arki-tekturarbejdets produkter udvikles, vedligeholdes og
bringes i anvendelse. Kan fx omfatte aktører/fora og
beslutningsprocesser i forhold til arkitektur og løsning. Vil helt eller delvist kunne være dækket af projekt-
grundlag eller PID.
RACI matrice
eller Archimate diagram.
AR 1.1
Interessentana-
lyse
Beskriver de vigtigste interessenter
og interesser i forhold til løsningen og dens arkitektur (stakeholder con-
cerns).(Resumé)
Her er fokus på styring af arkitekturegenskaber og ikke
proces- og projektstyring. Skal sikre, at der tages højde for relevante forhold ift. at realisere de givne mål og
kan danne grundlag for plan for inddragelse og kom-
munikation i forhold arkitekturarbejdet. Vil helt eller delvist kunne være dækket af den klassiske interessent-
analyse, jf. afsnit projektgrundlag eller PID.
Tabel eller Archi-
mate diagram
AR 1.2
Forretningsmål Beskriver de overordnede forret-ningsmål, som projektet / løsningen
skal fremme.
Kan fx relateres til interessentanalyse og anvendes til at udarbejde gevinstmodel. Anvendes til styring og priori-
tering. Vil helt eller delvist kunne være dækket af afsnit
projektgrundlag eller PID.
Liste, tabel eller Archimatediagram
AR 1.2
Kvalitetsplan Beskriver hvordan projektet vil sikre den tilstrækkelige kvalitet,
herunder test og compliancevurde-
ring.
Kan også omfatte plan for høringer af eksterne interes-senter. Vil helt eller delvist kunne være dækket af af-
snit projektgrundlag eller PID.
Tekstdokument AR 1.2 AR 2.4
Gevinstmodel Beskriver de vigtigste gevinster, som skal realiseres. Nedbrydes fx i
et forudsæt-ningsdiagram, som ska-
ber sporbarhed mellem arkitektur-produkter og gevinster.
Kan udformes som et hierarki eller diagram. Kan danne udgangspunkt for en gevinst- og forudsætningsdiagram
og -analyse. Omfatter også negative gevinster. Kan
mappes til interessenter, udfordringer, kapabiliteter, plateauer og andre elementer i den samlede arkitektur.
Vil helt eller delvist kunne være dækket af afsnit pro-
jektgrundlag eller PID.
Tabel eller dia-gram, fx med brug
af ArchiMate
AR 1.2
Metodeanven-
delse
Beskriver fremgangsmåde med til-
hørende (arkitektur)produkter, som
indgår i leveranceplan.
Fx om projektet er underlagt statens program eller it-
projektmodel, om der anvendes agile metoder, om der
anvendes aftalt arkitekturrammeværk og notation. Om-fatter tilpasning af metoder og notationer til projektets
kontekst. Vil helt eller delvist kunne være dækket af af-
snit projektgrundlag eller PID.
Tekstdokument AR 1.3
AR 1.4
AR 1.5
Ændringsan-
modningslog
Beskriver anmodninger om ændrin-ger i projektets produkter. Vedlige-
holdes i projektets og løsningens le-
vetid.
Et levende projektstyringsdokument. Tabel AR 1.1
Arkitekturbe-
slutningslog
Beskriver beslutninger med væsent-lig betydning for løsningens arkitek-
toniske egenskaber.
Fx valg mellem alternativer, scope, standarder. Bør omfatte rationale og konsekvenser. Dokumenterer tek-
nisk gæld. Vedligeholdes i projektets og løsningens le-
vetid. Koordineres med Ændringsanmodningslog og re-levant beslutningsdokumentation fra projektprocesser
og relaterede processer (fx EA). Dokumenterer fravi-
gelser fra overordnede arkitekturrammer, som kan sam-les i produktet Arkitekturcompliance.
Tabel AR 1.1
Deploy-
ment/staging-
plan
Beskriver rammer og tidsplan for
deployment og staging.
Understøtter koordering mellem forretning og IT, og
mellem udvikling og drift.
Tekstdokument,
gerne med tabeller og diagrammer, fx
i ArchiMate for-
mat
AR 1.1
57
Strategi Arkitek-
turpro-
duktnavn
Beskrivelse (kort) Kommentarer Forslag til for-
mat AR nr.
Vision /
målbillede
Beskriver den kommende løsnings hovedegenskaber.
Giver et klart billede af forretningens strategiske vision og målbillede for løsningen. Hovedegenskaber kan fx være ud-
trykt som eller relateres til strategiske kapabiliteter. Vil helt
eller delvist kunne være dækket af afsnit projektgrundlag eller PID. Nedbrydes i strategiske kapabiliteter og videreudvikles
til målarkitektur og løsningsarkitektur.
Tekst og visuali-sering, evt. Archi-
Mate
AR 1.2 AR 2.1
Strategi-
ske kapa-
biliteter
Beskriver de strategiske kapabili-
teter, der skal realiseres.
En kapabilitet er en formåen en organisation, person, eller et
system har. Udtrykkes typisk i generelle termer og består ty-pisk af en kombination af organisation, mennesker, processer
og teknologi. Kan være indenfor forretning, teknik eller arki-
tektur. Beskriver en forretningsværdi og gerne modenheds / kvalitetsniveauer for denne. Kan fx være i form af en opera-
ting model, der oversætter strategiske mål til strategiske arki-
tektur-, forretnings-, og it-kapabiliteter. Kan fx mappes til ge-vinstmodel, strategier og projekter.
Tekst og fx Ar-
chiMate diagram
AR 1.2
AR 2.1
Udfor-
dringer
Beskriver summerisk problemer
og muligheder, som arkitekturen skal adressere og gerne hvordan.
Fx i form af en SWOT analyse.
Scopet for dette kan variere meget. Fra udfordringer, der ved-
rører én specifikt løsning til udfordringer for mange, fx en or-ganisations portefølje eller tværorganisatorisk. Kan fx være i
form af en SWOT analyse.
Tekst, tabel, evt.
Archimate dia-gram
AR 1.1
AR 1.2 AR 1.4
AR 2.1
Arkitek-
turprin-
cipper
Beskriver principper, der under-
støtter de vigtigste egenskaber ved den fremtidige løsning.
Omfatter tværgående rammesættende principper (fx FDA
principper, koncern EA, domæne EA) og egenudviklede prin-cipper (løsning). Beskriver hvordan projektet forholder sig til
disse. Fravigelser fra principper kan fx samles i dokumentet
Arkitekturcompliance.
Tekst, evt Archi-
Mate diagram
AR 1.1
AR 1.2 AR 2.1
Arkitek-
turcompli-
ance
Beskriver afvigelser fra ramme-sættende arkitektur og begrundel-
ser herfor samt beskrivelse af tek-
nisk gælder der etableres.
Forholder sig til tværgående rammer som fx arkitekturprincipper, referencearkitekturer, standarder mv.
Samler dokumentation fra arkitekturbeslutningslog mhp re-
view og rapportering til EA funktion o.l..
Tekst, tabel AR 1.1 AR 1.2
AR 2.1
AR 2.2 AR 2.3
Målarki-
tektur-re-
sumé
Beskriver de vigtigste elementer i
den fremtidige arkitektur. (Re-sumé).
Resumé, der giver et samlet tværgående overblik. Bør dække
både forretningsopgaver/processer og it-landskabet. Supplerer og bygger på en given samling af arkitekturprodukter. En ud-
gave af TOGAF produktet arkitekturdefinitionsdokument. Er-
tattes af løsningsarkitektur når den realiseres.
Diagram og tekst AR 2.1
AR 2.2 AR 2.3
Migre-
ringstra-
tegi
Beskriver hvordan målarkitekuren realiseres over tid. (Roadmap)
Et overordnet roadmap, der viser eventuelle plateauer (trin/iteration) for målarkitekturens realisering. Kan fungere
som grundlag for detaljeret planlægning. Kan fx omfatte kon-
traktudløb, dataportabilitet, integrationer og andre afhængig-heder. Samler et antal målarkitekturer serielt. Vil typisk sup-
plere og evt. danne grundlag for en projekt- eller program-
plan, fx en udrulnings eller bølgeplan.
Tekst, diagram, tabel
AR 2.1 AR 2.4
Exitstra-
tegi
Beskriver overordnet hvordan den fremtidige løsning kan forlades.
Forholder sig fx til kontraktudløb, dataportabilitet, integratio-ner og andre afhængigheder. Forholder sig til de væsentligste
egenskaber i løsningsarkitekturen og kontraktuelle bindinger.
Tekst AR 2.3 AR 2.4
Løsnings-
arkitek-
tur-re-
sumé
Beskriver de vigtigste elementer i den konkrete løsning. (Resumé)
Resumé, der giver et samlet tværgående overblik. Supplerer og bygger på en given samling af arkitekturprodukter. Udar-
bejdes typisk af eller i samarbejde med leverandører og vedli-
geholdes løbende efter aftale. Supplerer og bygger på en gi-ven samling af arkitekturprodukter. En udgave af TOGAF
produktet arkitekturdefinitionsdokument. Ertatter målarkitek-
tur når dennne realiseres.
Diagram og tekst AR1.1 AR 2.1
AR 2.3
AR 2.4
58
Jura Arkitektur-
produkt-
navn
Beskrivelse (kort) Kommentarer Forslag til for-
mat AR nr.
Juridiske
bindinger
Beskriver juridiske bindinger, som har væsentlig betydning for
mandat og begrænsninger for
løsningens arkitektur og anven-delse. (Overblik)
Bindinger findes typisk i love, fordringer, direktiver, udbuds-bekendtgørelser, kontrakter o.l.
Tekst evt. supple-ret med Archi-
Mate diagram
AR 2.5 AR 3.1
AR 3.2
Krav(sam-
ling)
Beskriver forhold, der kræves
eller ønskes overholdt i løsnin-
gen.
De enkelte krav kan referere til specifikationer andre arkitek-
turprodukter. Kan både omfatte tværgående krav (EA/virk-
somhedskontekst) og specifikke krav til den enkelte løsning. Kan omfatte forhold og opgaver af materiel og ikke materiel
karakter og omfatter ikke kun den tekniske løsning. Et over-
blik over væsentlige krav og temaer for krav kan anvendes til arkitekturstyring. Krav indarbejdes i forskellige kontrakter og
aftaler.
Tekst, tabel, evt.
overordnet i Ar-
chiMate. Kan ud-foldes via user
stories, jf agile
metoder. Skal kunne indarbejdes
i kravspecifika-
tion efter evt. ska-belon.
AR 2.1
AR 2.2
AR 2.3 AR 3.1
Databe-
handleraf-
tale
Skriftlig aftale mellem to virk-
somheder - eller en person og en virksomhed - der fortæller,
hvordan den virksomhed, der
behandler dataene, skal be-handle dem.
Kaldes også DPA – Data Processing Agreement Tekst AR 3.1
AR 8.1
Serviceaftale Skriftlig aftale mellem en tjene-
steyder (leverandør) og slutbru-
geren (kunde), der beskriver
serviceniveauet forventet hos
tjenesteudbyderen.
Kaldes også SLA Tekst AR 3.1
AR 8.1
59
Sikkerhed Arkitektur-
produktnavn
Beskrivelse (kort) Kommentarer Forslag til for-
mat AR nr.
Sikkerheds-
strategi / -
mønstre
Beskriver på overordnet niveau til-
gang til sikkerhed, der skal styre løs-ningen fra start til slut og end to end.
Omfatter metoder til sikring af adgang til data. Fx to-
faktor, ”lokal” brugerstyring, føderering.
Tekst AR 4.1
AR 4.2
Trussels- og
risikokatalog
Beskriver væsentlige identificerede
sikkerhedsmæssige risici og krav til
mitigering.
Områder, hvor der skal indgå risikovurdering og sikker-
hedsforanstaltninger, omfatter fx processer, aktører,
data, snitflader og driftmiljø.
Tekst, tabel AR 4.1
AR 4.2
Sikkerheds-
model
Beskriver hvordan krav til sikkerhed og fortrolighed påvirker løsningens
egenskaber.
Fokus på den tekniske håndtering af brugerrettigheds-styring indenfor og på tværs af sikkerhedsdomæner.
Kan omfatte overordnet sikkerhedsklassifikation af data
og principper for sporbarhed, hvilke data der gem-mes/udveksles, roller ift brugerrettigheder og adgang-
styring til applikationer samt anvendt infrastruktur. Kan
omfatte styring på tværs af løsninger og sikkerhedsdo-mæner (føderation), granularitet i rettighedsstyring og
roller ift. ansvar. Kan omfatte andre sikkerhedsaspekter.
Tekst, diagrm fx i ArchiMate
AR 4.1 AR 4.2
AR 7.1
AR 8.1
Sikkerheds-
kontroller
Beskriver sikkerhedsforanstaltninger i form af procedurer for kontroller.
Dokumentationen skal sikre, at der er veldefinerede sik-kerhedsforanstaltninger bygget ind i organisation og
processer, teknik og fysiske rammer, og at de er udfø-
res, så deres effektivitet kan vurderes. Kan være: Orga-nisatoriske som fx autorisation af adgang, retningslinjer
mod trusler som organiseret kriminalitet, uautoriseret
adgang til data. Tekniske som fx autentificering, krypte-ring mod trusler som modificering af data, spionage etc.
Fysiske som fx overvågning, alarm mod trusler som na-
turkatastrofer, brand mm.
Tekst, liste, ta-bel/matrice
AR 4.1 AR 4.2
AR 8.1
60
Opgaver Arkitek-
turpro-
duktnavn
Beskrivelse (kort) Kommentarer Forslag til for-
mat AR nr.
Opgave-
/serviceka-
talog
Beskriver de forvaltnings- og forretningsopgaver (eller ser-
vices), der indgår i projektets
løsning. (Overblik)
Dokumentation, der beskriver forretningsservices og modtagere af disse. Termen ”opgaver” anvendes her som samlebegreb for
termer, som forretningsservices, forretningstjenester eller (ho-
vedforretnings)funktioner. Oversigten kan relateres til aktører i form af, hvem der udfører og modtager.
Liste, tabel eller ArchiMatedia-
gram
AR 5.1 AR 5.2
Domæne-
model
Beskriver de faglige eller orga-
nisatoriske domæner.
Forretningsoverblik der kan omfatte aktører og evt. systemer.
Fx et organisationsdiagram med en opdeling i sundhed/social,
region/kommune eller organisatoriske enheder.
Diagram og tekst AR 5.1
AR 5.2
Proces-
landskab
Beskriver de interne og eksterne processer, som skal understøttes
af it. (Overblik)
Kan omfatte enkeltstående såvel som tværgående processer. Kan fx mappes til opgaver og funktioner samt applikationer.
Grundlag for beskrivelse af procesmodeller og brugerrejser.
ArchiMate dia-gram
AR 5.2
Aktører /
roller
Beskriver anvendere af løsnin-gen.
Kan fx omfatte aktører, roller og personaer, der skal indgå i pro-cesser og brugerrejser.
Liste, matrice, di-agram, fx i Archi-
mate og UML til
use cases
AR 5.1 AR 5.2
Procesmo-
del
Beskriver aktørers udførelse af opgaver i et forløb.
Beskrives typisk som svømmebaner. Kan detaljeres som ar-bejdsgang / workflow med forretningshændelser, forretningsob-
jekter og forretningsregler.
BPMN diagram AR 5.1 AR 5.2
Bruger-
rejse
Beskriver en brugers anven-
delse af løsningen, og evt. til-grænsende løsninger, i et forløb.
Kan fx udarbejdes med brug af procesdiagram, tegneserie,
mock-ups. Beskriver oplevelsen fra en brugers perspektiv.
Tegneserie, Archi-
mate eller BPMN diagram
AR 5.1
Use case /
user story
Beskriver en brugers behov.
Udfolder kapabiliteter og fea-
tures, som en løsning skal reali-
sere.
Grundlag for servicedesign og applikationsudvikling. Kan fx udarbejdes
som UML use
case diagram eller
user story (agil
metode)
AR 5.1
AR 5.2
Servicemo-
del
Beskriver interne og eksterne services, herunder forretnings
krav til data og funktionalitet.
Grundlag for snitfladebeskrivelser. Tekst AR 5.1 AR 5.2
AR6.1
Arbejds-
gang / -be-
skrivelse
Beskriver hvordan en opgave
skal udføres.
Detaljeret beskrivelse af hvordan en opgave skal udføres i den
konkrete løsning.
Tekst evt supple-
ret med visualise-ring, fx i form af
workflow diagram
i BPMN
AR 5.1
AR 5.2
61
Information Arkitek-
turpro-
duktnavn
Beskrivelse (kort) Kommentarer Forslag til for-
mat AR
nr.
Centrale
forret-
ningsob-
jekter
Beskriver de væsentligste forret-ningsobjekter, som løsningen skal
håndtere. (Overblik)
Anvendes fx til scope projektet og udpege områder for se-mantisk standardisering samt identificere afhængigheder til
andre løsninger. Især vigtig hvor veldefinerede data skal
kunne udveksles mellem systemer / komponenter. Også værdifuld som grundlag for sikkerhedsvurdering.
Archimate dia-gram
AR 2.1
AR
6.1
Begrebsli-
ste/-model
Beskriver begreber med definitioner
(liste) og eventuelt relationer (mo-
del).
I praksis er det en uddybning af forretningsobjektmodellen.
Kan udformes som en UML model eller en liste.
Liste eller UML
diagram
AR
6.1
AR 6.2
Informati-
onsmodel
Beskriver hvilke informationer, der
indgår i en afgrænset kontekst og
hvordan de logisk hænger sammen, herunder attributter og relationer.
Et klassediagram som med attributter og associationer viser
sammenhæng mellem dataobjekter.
UML klassedia-
gram
AR
6.1
AR 6.2
Logisk da-
tamodel
Beskriver hvilke informationer, der
indgår i en afgrænset kontekst og hvordan de logisk hænger sammen,
herunder kardinaliteter og datatyper.
Et klassediagram med attributter, associationer, kardinalite-
ter og datatyper. Svarer til Informationsmodel beriget med multipliciteter og datatyper. Dokumenterer en bestemt data-
struktur (fx relationel), om end ikke produktspecifik (som
fx MySQL).
UML klassedia-
gram
AR
6.1 AR
6.2
Datasæt Beskriver de konkrete datasæt, der behandles i løsningen. (Overblik)
Kan omfatte data og dokumenter placeret i forskellige regi-stre og repositorier. Skal bidrage til at skabe overblik over
data fx ifbm sikring af data og fortrolighed, ejerskab og an-
svar for data, datadeling og identifikation af behov for ind-sats ifht semantisk og teknisk interoperabilitet.
Archimate dia-gram
AR 6.1
AR
6.4
Dataud-
vekslings-
format
Beskriver struktur for opstilling af
data med henblik på udveksling i
maskinlæsbar form.
For hver integration skal der aftales udvekslingsformat. Fx XML eller
JSON skema, el-
ler CSV fil sup-pleret med tekst-
beskrivelse
AR
6.1
AR 6.2
AR 7.1
62
Applikation Arkitektur-
produktnavn
Beskrivelse (kort) Kommentarer Forslag til for-
mat AR
nr.
Systemland-
skab / kon-
tekstdiagram
Beskriver konteksten for de applika-
tionskomponenter, der er i spil i løs-ningen. (Overblik)
Et væsentligt input til målarkitektur med fokus på løs-
ningens eksterne snitflader og datadeling. Kan fx også sætte applikationskomponenter i relation til de vigtigste
aktører og anvendelser.
Diagram, fx Ar-
chiMate
AR
2.1 AR
7.1
Applikations-
landskab +/-
integration
Beskriver applikationskomponenter
og integrationer. (Overblik)
Skal omfatte integrationer til både andre interne og eks-
terne løsninger.
ArchiMate dia-
gram
AR
2.1 AR
7.1
Applikationer
mappet til for-
retning
Beskriver hvilke applikationer, der
understøtter hvilke dele af forretnin-gen.
Kan fx være applikationskomponenter eller -services
mappet til fx forretningsservices, processer og/eller ak-tører. Kan fx beriges med roller og CRUD-handlinger.
Kan være vigtigt input til sikkerhedsmodellen.
ArchiMate dia-
gram
AR
5.1 AR
5.2
AR 7.1
Applikation
mappet til in-
formation
Beskriver hvilke applikationer, der
bruger hvilke forretningsobjekter / data.
Kan beskrives på forskelligt abstraktionsniveau, fx ifht
forretningsobjekt, datasæt, dataobjekt eller datakildesy-stem
ArchiMate dia-
gram
AR
6.1 AR
7.1
Applikations-
design
Beskriver design af en konkret appli-
kation på et detailniveau, der specifi-cerer funktionalitet og brugergrænse-
flade.
Kan være en modellering eller egentlig eksekverbar
kode.
Kan være en mo-
dellering, mockup, wire-
frames eller
egentlig ekse-kverbar kode.
AR
2.4
Løsningskom-
ponent
Applikationskomponent, der kan de-
ployes.
Fx ArchiMate for
overblik og i re-
levant kode
AR
2.1
AR 2.2
AR 7.1
Snitfladebe-
skrivelser
Beskriver hvad en service leverer og
hvordan den tilgås og anvendes.
Servicebeskrivelsen kan med fordel have to dele: 1) En
teknologi-uafhængig del, hvor servicen beskrives ud fra
hvad den gør. Hvor der er tale om data, bør der være en semantisk beskrivelse. Dette kan også omfatte tekno-
logi-uafhængige dele af en SLA (service level agree-
ment). 2) En teknologi-afhængig del, hvor der findes detaljer om hvordan servicen er/bør blive implemente-
ret. Dette kan omfatte integrationsmønstre, samt de tek-
nologi-afhængige dele af en SLA (service level agree-ment).
Fx WSDL
(SOAP), Open
API 3.0 (REST), JSON LD, FTP
suppleret med
tekstbeskrivelse
7.1
Testscenarier Beskriver hvilke tests der skal udfø-
res og hvordan.
Tekst, fx som del af user story skabelon (acceptkrite-
rier)
Tekst, fx i fast
skabelon
AR
1.2
AR 2.4
AR
5.1 AR
7.1
AR 8.1
63
Infrastruktur Arkitekturpro-
duktnavn
Beskrivelse (kort) Kommentarer Forslag til for-
mat AR
nr.
Infrastruktur-
koncept og -møn-
stre
Beskriver tilgang til de grundlæg-
gende teknologiservices. (Overblik)
Valg af teknologier, platforme og infrastrukturan-
svar, der sætter de grundlæggende tekniske rammer for løsningen. Fx om der bruges cloud computing og
fælles infrastrukturservices. Et væsentligt input til
målarkitektur og migrationsstrategi.
Tekst, tabel, evt
diagram i Archi-Mate
AR
8.1
Infrastruktur-
landskab
Beskriver de vigtigste teknologiser-vices og infrastrukturkomponenter.
(Overblik)
Omfatter fx platform og komponenter til drift, inte-grationer, brugerrettighedsstyring og sikkerhed. Fo-
kus på delte (infrastruktur)applikationer de applika-
tioner der drives internt og evt. snævert knyttet til den enkelte løsning.
ArchiMate dia-gram
AR 8.1
Infrastrukturop-
sætning
Dokumentation af de helt konkrete
teknologier, der anvendes.
Fx servere med deres konfigurationer af processorer,
RAM, ROM, IP-adresser; software med præcise ver-
sionsnumre og licensaftaler, osv. Støttedokumenta-tion til driften samt for nye projekter, så man til en-
hver tid kan orientere sig i hvad der findes i organi-sationen.
Tabel, diagram, fx
i ArchiMate
AR
8.1
64
Bilag 4: Liste over udvalgte modelsprog og tilhørende åbne udvekslingsformater Dette bilag indeholder en oversigt over udvalgte modelsprog og tilhørende åbne ud-
vekslingsformater.
Listen indgår som led i den fællesoffentlige digitale arkitektur (FDA), der har til formål
at understøtte sammenhæng i den offentlige digitalisering.
Listen opdateres løbende. Listen vedligeholdes af Digitaliseringsstyrelsen.
Modelsprog Version Udvekslingsformat
ArchiMate 3.0.1 ArchiMate Exchange File Format for ArchiMate 3.0
UML 2.5.1 XML Metadata Interchange / XMI 2.5.1
BPMN 2.0 Object Management Group tilbyder to XML formater til udveksling af BPMN 2.0: 1) Et format, der bruger XML Schema Definition (XSD) og 2) Et format, der bruger XML Metadata Interchange (XMI). Begge giver grundlæggende samme egenskaber, men XSD er angiveligt mest popu-lært.
DMN 1.14 Object management Group tilbyder XML formater til ud-vekling af DMN 1.1
4 Version 1.2 ventes snarligt
Retningslinjer om dokumentation af arkitektur i digitaliseringsprojekter
arkitektur.Digitaliseringsstyrelsen.dk