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