Retningslinjer for dokumentation og formidling af arkitektur i digitaliseringsprojekter

Juni - udkast version 0.9 til ekstern kommentering,

Indledning...............................................................................................................3

Formål......................................................................................................................3

Målgruppe................................................................................................................3

Anvendelse...............................................................................................................3

Indhold.....................................................................................................................4

Sammenhæng til andre FDA-dokumenter................................................................5

Centrale begreber....................................................................................................5

Pejlemærker for projekterne...................................................................................5

Interessenter og deres interesser............................................................................7

Interessenternes behov for information..................................................................8

Arkitekturperspektiver og -visninger.......................................................................9

Arkitekturreol.......................................................................................................11

Arkitekturprodukter..............................................................................................12

Prioriterede og anbefalede arkitekturprodukter....................................................13

Modellering...........................................................................................................14

Notations- og modelsprog......................................................................................14

Modelleringsniveau................................................................................................15

Sammenhæng på tværs af modeller......................................................................16

Byggeblokke...........................................................................................................16

Værktøjer og formater...........................................................................................18

Bilag 1: Tjekliste vedrørende arkitekturdokumentation.........................................19

Bilag 2: Definition af grundperspektiver.................................................................21

Bilag 3. Liste over anbefalede arkitekturprodukter................................................30

Bilag 4: Liste over modelsprog og udvekslingsformater..........................................35

Bilag 5: Ordliste og begreber.................................................................................36

2

IndledningDette dokument beskriver fællesoffentlige retningslinjer for dokumentation og formidling af arkitektur i digitaliseringsprojekter. De understøtter arkitekturregel 1.3: Anvend fælles ramme for beskrivelse af arkitekturen i Hvidbog om fællesoffentlig digital arkitektur (FDA).

FormålFormålet er at give et fælles sprog for dokumentation af arkitekturen i digitaliseringsprojekter, at højne kvaliteten i digitaliseringsprojekter og understøtte sammenhængende digitalisering. Det er væsentligt nemmere at samarbejde og ”få stikkene til at passe sammen”, når arkitektur er beskrevet efter samme metodik.

MålgruppeMålgruppen er forretnings- og it-arkitekter, projektledere og leverandører med ansvar for at udarbejde dokumentation i digitaliseringsprojekter.

AnvendelseRetningslinjerne skal anvendes af projekter i den fællesoffentlige digitaliseringsstrategi (FODS), med særligt fokus på arkitekturstyring og kvalitetssikring gennem review.

Værdi for projekter

Konkret skal retningslinjerne skabe værdi for projekter ved at understøtte:

At projekter anvender hvidbogens principper og den fællesoffentlige rammearkitektur

At projekter kan anvende en fælles metoderamme, som er nem at tage i brug og tilpasse til det konkrete projekt

At projekter kan styres optimalt via bedre overblik over de væsentligste elementer og udfordringer i projekter

At projekter kan udvikle løsninger effektivt ved hjælp af et fælles sprog om løsningen mellem projektledelsen og forretnings- og it-arkitekter

At projekternes arkitekturarbejde og løsninger kan koordineres og genbruges

At projekternes arkitekturarbejde kan kvalitetssikres gennem peer-review på grundlag af ensartet dokumentation på tværs af projekter

At projekter kan nyde godt af kompetenceopbygning på tværs af myndigheder og leverandører gennem kurser og netværk.

Som led i FODS vil der blive etableret tilbud om kompetenceudvikling og rådgivning ift. anvendelse af disse retningslinjer. Retningslinjerne vil blive revideret efter behov på baggrund af indhøstede erfaringer med anvendelsen.

3

Retningslinjerne er baseret på erfaringer med hvilken dokumentation, der giver mest værdi, og på internationalt forankrede og velafprøvede metoder og arkitekturrammeværker. De kan ses som en opdatering af det fællesoffentlige rammeværk OIO EA.

Perspektivet er, at der myndighederne bliver bedre til at designe og kravspecificere løsninger ved at anvende 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 aftalte krav i henhold til den fælles digitale arkitektur.

Rammearkitektur

Fælles arkitektur i en veldefineret, organisatorisk kontekst.

En fælles aftalt tilgang til levering af services. Begrænses gerne til nødvendige fællesnævnere med fokus på interoperabilitet. Kan bl.a. omfatte fælles principper, begreber, modeller, specifikationer og løsninger. Eksempler: Den fællesoffentlige rammearkitektur (FDA), den fælleskommunale rammearkitektur og den europæiske rammearkitektur (The European Interoperability Architecture - EIA).

Det skal understreges, at nærværende retningslinjer ikke omhandler de processer og aktiviteter og roller, der anvendes i arbejdet med at udvikle og dokumentere arkitektur. Dette kan eventuelt blive genstandsfelt for en selvstændig vejledning om metode i arkitekturarbejdet på et senere tidspunkt.

Det skal ligeledes understreges, at retningslinjerne i nærværende udgave ikke forholder sig til udviklingsmetode, herunder anvendelse af vandfalds eller agile metoder. Det kan eventuelt indgå i en fremtidig revision.

IndholdDokumentet 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

De vigtigste arkitekturprodukter som adresserer interessenternes behov

Fælles tilgang til modellering og anvendelse af byggeblokke

Bilag 1 indeholder en udvidet tjekliste for projektledere og arkitekter vedrørende arkitekturdokumentation. Denne supplerer tjeklisterne i dokumentet Introduktion til

4

Fællesoffentlig Rammearkitektur, som understøtter anvendelse af FDA Rammearkitektur.

Sammenhæng til andre FDA-dokumenterNæ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 sammenhæng med nærværende retningslinjer. Diagrammet viser sammenhæng til tre af hvidbogens arkitekturregler og sammenhæng til side- og underordnede dokumenter.

FIGUR 1 SAMMENHÆNG MELLEM ARKITEKTURREGLER OG RETNINGSLINJER

Det understreges at dette er et tids- og kontekst afhængigt ”snapshot”. På sigt vil disse fx kunne blive suppleret med vejledninger om metode i arkitekturarbejdet og om modellering af processer og regler. Ligeledes vil der, hvis der er behov for det, kunne blive udarbejdet vejledninger i anvendelse af værktøjer til modellering og anvendelse af FDA byggeblokke.

Centrale begreberI sammenhæng med arkitekturdokumentation anvendes en række faglige termer og begreber, som er beskrevet nærmere i Bilag 5 Ordliste og begrebsmodel.

Pejlemærker for projekterneArkitekturregel 1.3 Anvend fælles ramme for beskrivelse af arkitekturen stiller krav om, at projekter udarbejder relevant arkitekturdokumentation efter nærværende

5

retningslinjer og deler denne, således at andre kan anvende denne til indsigt og genbrug.

Retningslinjerne 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. Projekterne tager udgangspunkt i følgende som pejlemærker:

Den nødvendige og tilstrækkelige dokumentation udarbejdes. Det betyder, at projektet 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).

Dokumentation udarbejdes til rette tid og formål. Det betyder, at der udarbejdes dokumentation, der modsvarer de behov interessenterne har på et givet tidspunkt ud fra de informationer, der er til stede på dette tidspunkt og i en form og format, som modsvarer behovet.

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 begrænser anvendelse af standarder og almindelig god praksis. Hvor der laves begrænsende regler, er det af hensyn til at understøtte det tværgående samarbejde, herunder deling og genbrug af arkitekturdokumentation.

6

Interessenter og deres interesser I dette afsnit beskrives de grundlæggende interessenter og deres grundlæggende interesser. Det sker med udgangspunkt i standarden ISO/IEC/IEEE 42010 “Systems and software engineering — Architecture description”.

Interessenter (stakeholders) kan betragtes som aktører, der har 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øsningen 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 aktører 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 arkitekturdokumentation, der kan være relevant. NB! De angivne grupper er nogle grove grupperinger. I praksis vil det være relevant at lave en mere præcis liste i den konkrete kontekst.

Bruger - herunder borgere, virksomheder og medarbejdere samt andre brugere af systemet. Optræder også som datasubjekt.

Ejer - herunder anskaffere, bygherrer af systemet, systemejerrollen og kundens projektleder.

Arkitekt/udvikler - herunder enterprise- , løsnings-, forretnings-, data-, applikations-, teknologiarkitekt samt softwareudviklere.

Governance-aktør – herunder standardiseringsorganisationer og aktører med ansvar for tværgående governance, fx ejere af fælles infrastruktur.

Juraansvarlig – herunder jurister knyttet til et givent projekt, men også politikere, lovgivere og lovfortolkere.

Sikkerhedsaktør – særligt Data Protection Officer (DPO), men også andre roller med ansvar for håndtering af sikkerhed på forskellige områder (data, løsning, infrastruktur, drift).

Forretning – herunder forretningsansvarlig (leder), -eksperter og medarbejdere.

Dataejer/-behandler – herunder datadistributører.

Leverandør - herunder udviklere af systemet og leverandørens projektleder.

Drift - herunder ansvarlige for drift og vedligehold, systemoperatører og support.

Tilsvarende er følgende overordnede interesser generelt relevante at tænke ind:

7

Systemets formål.

Arkitekturens egnethed til opnåelse af systemets formål.

Muligheden for at udvikle og implementere systemet.

Systemets potentielle risici og virkninger for dets interessenter i hele dets livscyklus.

Tværgående samarbejde, processer, semantisk og teknisk interoperabilitet, integrationer og tværgående infrastrukturunderstøttelse.

Systemets egenskaber ift. vedligehold og udvikling.

Interessenternes behov for informationFormålet med formidling og dokumentation af arkitektur er at understøtte interessenters afklaring af, hvordan deres interesser varetages i forbindelse med udviklingen af digitale løsninger. Desuden skal formidling og dokumentation understøtte udvikling, drift og vedligehold af løsninger i hele deres livscyklus.

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 deres interesser og hjælpe dem med at løse deres opgave ift. projektet og løsningen?”

Formidlingen skal være målrettet interessenternes forskellige behov. Dokumentationen af arkitekturen skal derfor som udgangspunkt være helhedsorienteret, så den kan understøtte mange forskellige behov for information. Ideelt set beskrives en løsning i én samlet arkitekturmodel. I praksis vil der typisk være mange delmodeller og mange forskellige visninger og fortællinger (narrativer), som repræsenteres i mange forskellige ledelses- og specialistprodukter.

Overordnet set har enterprise arkitekten og løsningsarkitekten ansvar for sikring af dokumentation i et helhedsperspektiv gennem udarbejdelse og vedligehold af samlede modeller over virksomheds- og løsningsarkitektur – udarbejdet i formelle, logiske notationssprog. Der er forskellige sprog med forskelligt fokus og primære målgrupper (læs mere i afsnittet Fælles notationssprog for arkitekturdokumentation). De formelle modeller kan danne grundlag for visninger formidlet i et format, der er forståeligt af interessenterne.

8

FIGUR 2 EN INTERESSENT MED ET PERSPEKTIV SER EN VISNING DER MODSVARER INTERESSEN

Dokumentation har bl.a. til formål at understøtte formidling. Det kan fx være formidling til beslutningstagere om målarkitektur og krav til løsningen, til leverandør og udvikler om tekniske detailkrav til løsningen, eller til systemoperatører og support om konfiguration 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 tekst, matricer og diagrammer. Diagrammer kan udarbejdes med eller uden anvendelse af et formelt notationssprog. FDA stiller dog krav til anvendelse af formel notation til en række arkitekturprodukter. Til formidling kan man desuden anvende tegninger, tegneserier, mockup af skærmbilleder, video og andre formater, der er egnet til formidling.

De primære brugere af dokumentation udarbejdet med formelle notationssprog er arkitekter og udviklere, som skal designe og udvikle løsningen samt aktører, som har behov for præcis information i forbindelse med drift, fx systemoperatører. De øvrige interessenter har typisk behov for formidling, som ikke er for teknisk og detaljeret. Nedenstå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 dokumentation 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

Forretning

Dataejer/-behandler

Leverandør – især ansvarlige ift. kravspecifikation

Drift - især ansvarlige ift. konfiguration af teknisk løsning

Bruger

Ejer

Governance-aktør

Sikkerhedsaktør

Juraansvarlig

Forretning

Sikkerhedsaktør

Arkitekturperspektiver og -visningerI dette kapitel defineres en række grundlæggende perspektiver på og visninger af arkitekturen, der understøtter interessenternes behov for information. Det sker ligeledes med udgangspunkt i standarden ISO/IEC/IEEE 42010 “Systems and software engineering — Architecture description”.

9

En repræsentation af en del af arkitekturen kaldes en visning (view), som udarbejdes i henhold til et veldefineret perspektiv (viewpoint), der repræsenterer relevante interessenters behov for viden om systemet. En interesse er et spørgsmål fra et bestemt synspunkt (point of view). En visning er et svar. Tegningen viser en interessent, der ser på arkitekturen i et perspektiv med fokus på opgaveløsning.

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. FDA har således otte grundperspektiver som dækker en helhedsorienteret arkitektur: Styring, Strategi, Jura, Sikkerhed, Opgaver, Information, Applikation og Infrastruktur.

FIGUR 3 DE OTTE GRUNDLÆGGENDE ARKITEKTURPERSPEKTIVER

Bilag 2: Definition af grundperspektiver indeholder en mere detaljeret gennemgang af FDA grundperspektiverne, hvor de relateres til relevante principper, arkitekturregler, interessenter og interesser samt arkitekturdokumenter.

Der kan defineres mange andre perspektiver, som kan gå på tværs af disse grundperspektiver. 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øsningen fra strategi til infrastruktur og lovgivning kan sætte rammer for opgaver og brug af data og tekniske løsninger.

10

FIGUR 4 FIRE TVÆRGÅENDE PERSPEKTIVER PÅ FORRETNINGS- OG IT-ARKITEKTUREN

ArkitekturreolDette kapitel handler om FDA-arkitekturreolen, som anvendes til at placere dokumentation på ”hylder”, så det er nemt at finde og dele dokumentation. Vertikalt er reolen delt op efter de otte grundperspektiver. Horisontalt er den delt i tre niveauer, der beskriver graden af konkretisering og detaljer:

Konceptuel - har fokus på overblik, rummer mindst detaljer. Henvender sig især til beslutningstagere. Beskrivelser er typisk nemme at afkode for lægmand uden særlige forudsætninger.

Logisk - har fokus på præcision 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, projektledere og eksperter inden for de enkelte perspektiver.

Fysisk - har fokus på, hvordan ting er i virkeligheden og rummer alle nødvendige detaljer for 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 udtryk for et bud på en pragmatisk fordeling af de mange forskellige ledelses- og arkitekturprodukter, som udarbejdes og anvendes i virksomheden og dens projekter. Reolen kan rumme både løsnings- og enterprise arkitektur.

FIGUR 5 FDA ARKITEKTURREOLEN

FDA arkitekturreolens struktur anvendes som en klassifikation til at opmærke arkitekturdokumenter, når de skal udstilles og deles, så det bliver nemt at fremsøge dem.

11

ArkitekturprodukterI dette kapitel beskrives de arkitekturprodukter, som typisk indgår i arbejdet med digitalisering.

På baggrund af erfaringer fra arbejdet med digitalisering, it-udvikling og drift og anvendelse af rammeværker som fx OIO EA og TOGAF er det muligt at lave et overblik nogle af de mange typer af dokumenter, som indgår i arbejdet med at beskrive arkitektur på løsningsniveau eller enterprise niveau. De nævnte dokumenter er nogle af de mest almindeligt anvendte og vigtigste at tage stilling til. Nogle af disse dokumenter er rammesættende som fx national lovgivning, andre udarbejdes på et overordnet organisatorisk niveau fx strategier som del af en koncern- eller porteføljestyring. Og så er der de dokumenter, som udarbejdes af det enkelte projekt eller i relation til den enkelte løsning. Tilsvarende er der produkter, der udarbejdes af fx projektledere, jurister, forretningseksperter og andre der udarbejdes af arkitekturspecialister.

Et givent 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 hver især.

Nedenstående figur viser en reol med eksempler på sådan dokumentation i et samlet overblik, hvor dokumenterne er placeres på hylderne ud fra en overordnet vurdering af, hvor de hører mest hjemme. NB! Det understreges, at denne oversigt hverken er normativ eller udtømmende.

FIGUR 6 FDA ARKITEKTURREOL FYLDT MED EKSEMPLER PÅ DOKUMENTATION DER INDGÅR I ARKITEKTURARBEJDET

12

Prioriterede og anbefalede arkitekturprodukterDette afsnit udpeger de prioriterede og anbefalede arkitekturprodukter, som projekterne skal være særligt opmærksomme på. Disse er en delmængde af indholdet i reolen i forrige afsnit. NB! Det skal understreges, at det ikke er en udtømmende liste. I et projekt kan der være mange andre produkter som også er relevante.

FIGUR 7 FDA ARKITEKTURREOLEN MED ANBEFALEDE ARKITEKTURPRODUKTER FRA PROJEKTER

De anbefalede produkter er nærmere beskrevet i Bilag 3. Liste over anbefalede arkitekturprodukter.

De anbefalede produkter understøtter især overordnet design, styring, koordinering, review og kvalitetssikring.

Projektet skal sikre at dokumentationen tydeligt referer til relevante dele af FDA rammearkitektur, herunder referencearkitekturer og byggeblokke.

For alle produkter anbefales det, at diagrammer (visuelle modeller) suppleres med tekst med henblik på at uddybe og forklare særlige forhold og problemstillinger samt sikre korrekt fortolkning.

En række produkter udarbejdes med brug af FDA-vejledninger.

I første omgang er der udarbejdet regler for beskrivelse af begreber og logiske datamodeller. Desuden forventes en vejledning i brug af modelsproget ArchiMate til udarbejdelse af en række af de andre dokumenter. På sigt kan der eventuelt og efter behov udvikles yderligere vejledning, skabeloner og eksempler til de nævnte arkitekturprodukter.

13

ModelleringEn væsentlig del af arkitekturdokumentation udarbejdes i form af modeller, der beskriver arkitekturens elementer og sammenhæng på en logisk stringent måde og som kan visualiseres som diagrammer suppleret med et tekstligt narrativ.

Notations- og modelsprogEt formelt notations- og modelsprog definerer et sæt af elementer, relationer, regler og ikoner til visuel repræsentation.

Projekterne skal anvende udpegede notationsstandarder for udarbejdelse af modeller, hvor det er relevant. Notationssprog har hver deres målgrupper, fokus, 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:

ArchiMate - til beskrivelse af den samlede arkitektur på højniveau. UML - Unified Modeling Language - til detaljeret beskrivelse af begreber og

data.

Følgende notationssprog er identificeret som kandidater:

BPMN - Business Process Modeling Notation - til beskrivelse af forretningsprocesser og detaljeret beskrivelse af arbejdsgange.

DMN - Decision Modeling Notation - til beskrivelse af regler.

ArchiMate henvender sig især til enterprise- og løsningsarkitekter, BPMN og DMN især til forretningsarkitekter og UML især til dataarkitekter og -udviklere.

Nedenstående figur giver et overblik over, hvor de forskellige notationssprog typisk vil finde anvendelse ift. arkitekturreolen. Hvor der er en hård parentes [] er der ikke taget formel beslutning endnu.

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 forretningsobjekter vs. UML til begrebsmodeller eller BPMN til modellering af arbejdsprocesser og DMN til modellering af forretningsregler.

14

FIGUR 8 FDA ARKITEKTURREOLEN MED ANBEFALEDE MODELSPROG

ModelleringsniveauModellering er en måde at lave abstraktioner over virkeligheden. 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 supplement 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. 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

detaljeringsniveau 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.

Nedenstående figur illustrerer, hvordan de forskellige modelsprog understøtter forskellige koncepter og niveauer i arkitekturarbejdet.

15

FIGUR 9 ILLUSTRATION AF MODELSPROGS ANVENDELSE PÅ FORSKELLIGE NIVEAUER

Sammenhæng på tværs af modellerHvis der er krav til eller behov for at skabe sammenhæng mellem forskellige modeller – og på tværs af modelsprog - er det vigtigt at overveje, hvordan det gøres mest hensigtsmæssigt.

Her er nogle generelle eksempler på tilgange:

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 powerpoint.

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 modelværktøj.

Intern reference i modelelement: Lav en reference i en dedikeret attribut i et modelelement. Det kræver 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 reference. Undgå tilsanding af modellerne. Hvis en model skal leve længe, skal man have styr på håndtering af versionering af det, som der refereres til.

ByggeblokkeI arkitekturarbejdet er der et særligt begreb, som er centralt: Byggeblokke (forkortes BB). En byggeblok er en metafor for et element, som kan genbruges, når man designer arkitektur/løsninger. Det er et fælles sprog for ”kasserne” på tegningerne. Det må ikke opfattes som et eksakt videnskabeligt sprog, men det bruges til at støtte dialog om noget, der ofte er meget komplekst og kan være svært at afgrænse og tale om.

16

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 European Interoperability Reference Architecture (EIRA). Begrebet er væsentligt, fordi det anvendes til at definere et fælles sprog om de mest væsentlige og genbrugelige dele af arkitekturen. FDA rammearkitektur fastlægger således et sæt af fællesoffentlige byggeblokke, som udgør et fælles sprog i form af en taksonomi over de vigtigste arkitekturbyggeblokke, som projekterne skal være opmærksomme på - med 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 katalog over byggeblokke på FDA hjemmesiden.

En byggeblok repræsenterer en (potentielt) genanvendelig del af en virksomhedskapabilitet, der kan kombineres med andre byggeblokke til at levere arkitekturer eller løsninger. Byggeblokke kan kombineres og bestå af andre byggeblokke, og kan således være mere eller mindre atomare eller sammensatte.

Byggeblokke kan defineres på forskelligt detailniveau afhængig af, hvilken fase arkitekturudviklingen er på. Fx kan en byggeblok på et tidligt tidspunkt blot være et navn eller en skitseret beskrivelse eller specifikation. Senere kan en byggeblok nedbrydes i flere detaljerede byggeblokke og suppleres med detaljerede specifikationer.

Når man beskriver arkitekturen, kan det ske 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 byggeblok, 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 aftales egenskaber og fælles standarder.

Simpel fremstilling, hvor én service anvendes til at illustrere en større, men skjult kompleksitet

En mere udfoldet fremstilling, hvor flere elementer er vist som selvstændige byggeblokke

En gruppering, hvor en række byggeblokke er sammensat til en helhed i form af en gruppe

FIGUR 10 ILLUSTRATION AF FORMIDLING AF BYGGEBLOKKE PÅ FORSKELLIGT DETAILNIVEAU

17

Byggeblokke kan relateres til arkitekturer eller til løsninger. Der findes to grundtyper af byggeblokke. En arkitekturbyggeblok (forkortes ABB) er en abstrakt, men deldefineret delmængde af arkitekturmodellen. Der findes logisk set kun én af hver ABB. 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.

FDA anvender 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 digital post ses som en løsningsbyggeblok, der sikrer fælles juridiske rammer for anvendelse af digital post for alle myndigheder, borgere og virksomheder.

Værktøjer og formaterNå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 modelsprog, mens andre er specialiserede.

Nærværende retningslinjer kræver ikke anvendelse af særlige værktøjer. En myndighed, leverandør eller projekt må derfor vælge det værktøj, der understøtter det konkrete behov. Man skal dog sikre sig, at det valgte værktøj understøtter de rette versioner af modelsprog og udvekslingsformater.

Bilag 4: Liste over modelsprog og udvekslingsformater beskriver krævede eller anbefalede versioner af modelsprog og udvekslingsformater. [I endelig version publiceres og opdateres denne selvstændigt på FDA hjemmesiden.]

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ællesoffentlige kataloger, skal det som minimum ske med brug af et FDA-godkendt åbent udvekslingsformat.

Sekretariatet for FDA vil efter behov understøtte udvalgte modelsprog i enkelte værktøjer. Det kan være med skabeloner, kompetenceudvikling og lign.

18

Bilag 1: Tjekliste vedrørende arkitekturdokumentationDenne tjekliste er beregnet til at projektleder og arkitekt sammen kan planlægge arbejdet med arkitekturdokumentation i et projekt.

Projektlederens tjekliste

1. Afklar i dialog med projektets styregruppe hvilken arkitekturdokumentation, der skal udarbejdes i projektet og hvornår. Brug en arbejdsgruppe og arkitekt til støtte. Benyt eventuelt muligheden for rådgivning fra sekretariatet for initiativ 8.1.

2. Afklar hvilken dokumentation, der bør være i forbindelse med et eventuelt arkitekturreview i regi af styregruppen for data og arkitektur.

3. Lav som en del af projektplanlægningen en overordnet plan for udarbejdelse af arkitekturdokumentation i de forskellige faser. Planen bør omfatte hvilke arkitekturvisninger, der skal udarbejdes og krav til format og kvalitet i projektets hovedfaser.

4. Sørg for at kommunikere eventuelle bidrag fra projektet til den fællesoffentlige rammearkitektur.

5. Sørg for at udstille relevant dokumentation på FDA hjemmesiden eller på anden relevant hjemmeside.

Arkitektens tjekliste

6. Lav på baggrund af nærværende retningslinjer en tilpasset metode og valg af notation, der kan understøtte projektlederens plan for udarbejdelse af arkitekturdokumentation. Benyt eventuelt muligheden for rådgivning fra sekretariatet for initiativ 8.1.

7. Lav en overordnet skitse over den samlede arkitektur i projektet – fokuser i første omgang på formål/forretningsbehov, forretningsopgaver, forretningsobjekter og applikationskomponenter – og de væsentligste udfordringer!

8. Orienter jer i relevante referencearkitekturer og løsningsskabeloner, 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 tjeklister i referencearkitekturer.

9. Sørg for at orientere jer i hvilke referencearkitekturer, løsningsskabeloner og løsningsbyggeblokke, der er i pipeline i andre projekter, og som kan have betydning for projektet.

19

10. Udarbejd projektets overordnede arkitekturmodel i ArchiMate med brug af arkitekturbyggeblokke fra FDA byggeblokkataloget. Udarbejd relevante detaljerede modeller i relevant notationssprog.

11. Hav løbende fokus på at anvende fælles terminologi og begreber, som defineres som del af FDA og som findes i FDA-ordbogen og FDA-modelkataloget.

12. Udarbejd relevante visninger af arkitekturen med udgangspunkt i nærværende retningslinjer. Husk at diagrammer/visualiseringer skal kunne afkodes af målgruppen og skal suppleres med narrativer, der kan sikre at væsentlige problemstillinger og muligheder står tydeligt for interessenterne.

13. Identificer kandidater til konkrete løsningsbyggeblokke, som projektet kan genbruge og indarbejd dem i projektets arkitekturmodel. De kan både være danske og internationale, fx fra ISA2 og CEF Digital fra EU.

20

Bilag 2: Definition af grundperspektiverDette bilag definerer de otte grundlæggende arkitekturperspektiver i den fællesoffentlige digitale arkitektur (FDA).

For hvert perspektiv beskrives kort:

Arkitekturperspektiv – definition med angivelse af fokusemner.

Princip - reference til hvidbogens principper og arkitekturregler, som er særlig relevante ift. perspektivet.

Interessenter – udvalgte/særligt vigtige interessenter og eventuelt deres fokus.

Interesser - udvalgte eksempler på centrale/hyppige spørgsmål.

Arkitekturprodukter - med fokus på de prioriterede/anbefalede arkitekturprodukter fra projekter, som er særlig relevante ift. perspektivet.

Det bemærkes, at de nævnte interesser, spørgsmål og produkter 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 som en udvidet reol med brug af reolens farvekoder således, at det er nemt at orientere sig.

21

Styring

Arkitekturperspektiv med fokus på styring.Omfatter aktører, mål, indsatser, metoder og procedurer. Den politiske og organisatoriske kontekst for beslutninger og ansvar ift. løsningens udvikling og drift. Overordnede mål og gevinster, som skal realiseres. Aftalte programmer, projekter, fora, processer og procedurer til styring. Metode og dokumentation, der håndterer eller understøtter dette.

PrincipperP1 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.

Spørgsmål Om løsningen giver forventede værdi.

Systemets potentielle risici og virkninger for dets interessenter i hele dets livscyklus.

Hvem der har ansvar for de forskellige dele, der skal indgå, så de nødvendige beslutninger kan tages på rette niveau.

Om løsningen lever op til krav til tid, budget, kvalitet.

ArkitekturprodukterGovernancemodel, Interessentanalyse, Mål, Gevinstmodel, Metodeanvendelse, Arkitekturbeslutningslog.

22

Strategi

Arkitekturperspektiv med fokus på ønskede fremtidige tilstande.Omfatter visioner, målbilleder, strategiske kapabiliteter, som skal realiseres. Udfordringer og principper, som skal iagttages. Målarkitektur, migrationsstrategi med aftalte skridt på vejen (plateauer).

PrincipperP2 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øsningsarkitekt.

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.

ArkitekturprodukterVision/Målbillede, Kapabilitetsoverblik, Udfordringer, Arkitekturprincipper, Målarkitektur, Migrationsstrategi, Løsningsoverblik.

23

Jura

Arkitekturperspektiv med fokus på digitaliseringens juridiske aspekter.Omfatter lovgivning og kontrakter som er juridisk rammesættende for løsningens egenskaber samt for udbud, drift og anvendelse. Omfatter persondata- og registerlovgivningens aspekter ift. sikkerhed og privatliv.

PrincipperP3 Arkitektur og regulering understøtter hinanden.AR 3.1: Tag højde for juridiske bindinger ift. deling og genbrug af data og it-systemer.AR 3.2: Bidrag til digitaliseringsklar lovgivning.

Interessenter Bruger - især som datasubjekt.

Ejer - især systemejer.

Arkitekt/udvikler - især enterprise arkitekt, løsningsarkitekt, applikationsarkitekt og teknisk arkitekt.

Sikkerhedsaktør - især DPO og ansvarlig for implementering og drift af sikkerhedsmodel samt ansvarlig for monitorering og cybersikkerhed.

Juraansvarlig - jurister og andre, der udarbejder og anvender kravspecifikationer.

Forretning - især ift. effektiv opgaveløsning.

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.

ArkitekturprodukterJuridiske bindinger, Krav.

24

Sikkerhed

Arkitekturperspektiv med fokus på sikkerhed og beskyttelse af data, så fortrolighed, tilgængelighed og integritet sikres.Omfatter håndtering af trusler og sikkerhedsrisici. Krav til håndtering af sikkerhed og privatliv, herunder processer og regler (fx sikkerhedspolitikker og kontroller), data (fx datapolitik og sikkerhedsklassifikation) samt relevante tekniske services (fx adgangs- og rettighedsstyring, log, monitorering, cybersikkerhed).

PrincipperP4 Sikkerhed, privatliv og tillid sikres.AR 4.1: Opfyld krav til informationssikkerhed og privatlivsbeskyttelse.AR 4.2: Anvend fælles arkitektur for informationssikkerhed.

Interessenter Bruger - især som datasubjekt og ift. rettigheder.

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 sikkerhedsmodel samt ansvarlig for monitorering og cybersikkerhed.

Forretning - især ift. krav til sikkerhed i opgaveudførsel.

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.

ArkitekturprodukterSikkerhedsbegrænsninger, Sikkerhedsmodel.

25

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 udført i forretningsfunktioner efter forretningsregler og leveret som forretningsservices via en grænseflade.

PrincipperP5 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 Bruger - alle der skal løse opgaver via it-løsning.

Ejer - især opgaveansvarlig og systemejer.

Arkitekt/udvikler- især forretningsarkitekt, løsningsarkitekt og enterprise arkitekt.

Governance-aktør - særligt aktører med ansvar for tværgående servicelevering gennem fx portaler (fx Digitaliseringsstyrelsen, Erhvervsstyrelsen, SDS, EU).

Sikkerhedsaktør - især ansvarlig for implementering af sikkerhed i organisationen og dens forretningsprocesser.

Forretning - ledelse, eksperter og medarbejdere.

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.

ArkitekturprodukterOpgavekatalog, Brugerrejser, Procesmodeller, Arbejdsgange

26

Information

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. Mulighed for sammenhængende genbrug og sammenstilling af data. Standarder for data og dokumenter.

PrincipperP6 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 Bruger - især ift. semantik og forståelse (borger, virksomhed, sagsbehandler)

og tryghed ved data (datasubjekt).

Ejer - især systemejer både som dataejer og databehandler.

Arkitekt/udvikler - især informationsarkitekt og applikationsarkitekt ift. udvikling af informationsarkitekturen.

Governance-aktør - ejere af fælles byggeblokke i form af semantiske specifikationer (fx Digitaliseringsstyrelsen, EU med SEMIC, W3C og OASIS).

Sikkerhedsaktør - især DPO ift. klassifikation af data med henblik på håndtering af persondata og følsomme data.

Forretning - især ift. datas forståelighed, egenskaber og kvalitet ift. opgaveløsning.

Dataejer/-behandler – især dataafgrænsning, roller og ansvar.

Leverandør - især krav til datamodel og krav til eksterne snitflader og datastandarder.

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 orden.

ArkitekturprodukterForretningsobjekter, Begreber, Logisk datamodel, Datasæt, Udvekslingsformater.

27

Applikation

Arkitekturperspektiv med fokus på applikationskomponenter og -services, der understøtter forretningsservices.Omfatter applikationers funktioner og brugergrænseflader. Applikationers tekniske snitflader og roller og relationer i tekniske integrationer.

PrincipperP7 It-løsninger samarbejder effektivt.AR 7.1: Design og udstil snitflader efter fælles integrationsmønstre og tekniske standarder.

Interessenter Bruger - især ift. brugergrænseflade (UX og tilgængelighed).

Ejer - især systemejer ift. funktionalitet, kompleksitet, robusthed og fleksibilitet i koden i applikationer, services, snitflader og integrationer.

Arkitekt/udvikler - især løsningsarkitekt, applikationsarkitekt og udviklere (programmører) samt UX-ansvarlige.

Governance-aktør - ejere af fælles byggeblokke i form af tekniske specifikationer og open source komponenter (fx Digitaliseringsstyrelsen, EU med CEF Digital, W3C og IHE).

Sikkerhedsaktør - især DPO og ansvarlig for implementering og drift af sikkerhedsmodel.

Forretning - effektiv understøttelse af opgaveløsning.

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.

Interesser Brugeroplevelse og om brugergrænsefladen er nem at bruge.

Hvilke applikationskomponenter, der indgår i løsningen (i dag og i fremtiden) og deres rollefordeling.

Hvilke eksterne services, interfaces og integrationer, der skal understøttes.

Arkitekturprodukter

28

Kontekstdiagram, Applikationslandskab – med integrationer og evt. mappet til forretningsservices, processer og informationer.

Infrastruktur

Arkitekturperspektiv med fokus på teknologi-services, som leverer den generelle infrastruktur.Omfatter teknologi, platform, hosting, integrationsinfrastruktur, brugerstyring, sikkerhedsinfrastruktur, netværk, protokoller.

PrincipperP8 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,

applikationsarkitekt og teknisk arkitekt. Governance-aktør - ejere af fælles byggeblokke i form af tekniske

specifikationer og infrastrukturkomponenter (fx Digitaliseringsstyrelsen, SDS, EU med CEF Digital, W3C og IHE).

Sikkerhedsaktør - især DPO og ansvarlig for implementering og drift af sikkerhedsmodel 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

økosystem). 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.

ArkitekturprodukterPlatformsvalg, Infrastrukturlandskab.

29

Bilag 3. Liste over anbefalede arkitekturprodukterDette bilag giver en kort beskrivelse af hver type af anbefalede arkitekturprodukt, som er vist i FDA arkitekturreolen, jf. nedenstående figur.

For hvert produkt er der angivet:

Titel på produktet

Placering på hylde i arkitekturreolen

Kort beskrivelse

Kommentarer til produktets indhold eller udarbejdelse

Nummer på arkitekturregler i hvidbogen som produktet kan understøtte

Notationssprog der kan være relevant at anvende til produktet

Relaterede arkitekturprodukter (artefakter) fra TOGAF baseret på TOGAF Core Content Model and Extensions

Relaterede / mest relevante elementer i TOGAF Core Content Model and Extensions.

NB! Alle produkter kan indeholde relevant tekst, formelle diagrammer og supplerende illustrationer ift projektets kommunikationsbehov.

30

Arkitekturprodukt

Hylde i FDA reolen

Beskrivelse (kort) Kommentarer AR nr. Anbefalet notationssprog

Relaterede TOGAF artefakter

Referencer til TOGAF Content model

Governancemodel

Styringsrammer Beskrivelse af de overordnede organisatoriske rammer for at udøve governance - strategi, set-up med centrale aktører/fora ift. ansvar og beslutninger.

Skal sikre, at der etableres en ramme for governance, der kan sikre, at målarkitekturen realiseres ved at arkitekturarbejdets produkter udvikles, vedligeholdes og bringes i anvendelse.

AR 1.1 ArchiMate N/A Stakeholders,Organization units,Actors,Roles,(Implementation Governance),

Interessentanalyse

Styringsrammer Overblik over de vigtigste interessenter og deres vigtigste interesser (mål, gevinster, værdier og udfordringer).

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 kommunikation. Hvor interessentanalysen i en projektmodel har fokus på proces og projektstyring, er fokus her på styring af arkitekturegenskaber.

AR 1.2 ArchiMate Stakeholder Map Matrix

Stakeholders,Organization units,Actors,Roles,Drivers,Goals,Objectives,

Mål Styringsrammer Overblik over de mål projektet og løsningen skal fremme.

Kan relateres til interessentanalyse og anvendes til at udarbejde gevinstmodel. Anvendes til styring og prioritering.

AR 1.2 ArchiMate Driver, Goal, Objective Catalog

Drivers,Goals,Objectives,

Gevinstmodel Fremgangsmåde

Beskrivelse af de vigtigste gevinster, som skal realiseres.

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.

AR 1.2 ArchiMate Value Chain Diagram

Goals,Objectives,Measures,CapabilitiesWork Packages,

Metodeanvendelse

Fremgangsmåde

Beskrivelse af anvendte metoder og notationer, herunder tilpasning til projekt/kontekst

Fx om projektet er underlagt statens program eller it-projektmodel, om der anvendes agile metoder, om der anvendes aftalt arkitekturrammeværk og notation.

AR 1.3AR 1.4AR 1.5

ArchiMate N/A Implementation governance,Guidelines,Standards,Specifications,

Arkitekturbeslutningslog

Projektforløb Log over beslutninger med væsentlig betydning for løsningens egenskaber.

Knyttet til ændringsanmodninger.

AR 1.2 Archimate N/A Requirements catalog,

Vision / målbillede

Vision og mål Dokumentation, der beskriver organisationens vision og

Giver et klart billede af forretningens strategiske

AR 1.2AR 2.1

ArchiMate Solution Concept

Architecture Vision,

31

målbillede af den fremtidige arkitekturs hovedegenskaber på konceptuelt niveau.

vision og mål med løsningen, gerne udtrykt som strategiske kapabiliteter.

Diagram

Kapabilitetsoverblik

Vision og mål Beskriver de strategiske kapabiliteter, der skal realiseres.

Det kan være indenfor forretning, teknik eller arkitektur. Beskriver en forretningsværdi og gerne modenheds / kvalitetsniveauer for denne. Kan mappes til gevinstmodel.

AR 1.2AR 2.1

Archimate N/A Capabilities,Work Packages,

Udfordringer Vision og mål Dokumentation, der opsummerer, hvilke problemer og muligheder, som arkitekturen skal adressere og gerne hvordan.

Scopet for dette kan variere meget. Fra udfordringer, der vedrører én specifikt løsning til udfordringer for mange, fx en organisations portefølje eller tværorganisatorisk.

AR 1.1AR 1.2AR 1.4AR 2.1

ArchiMate N/A

Arkitekturprincipper

Målarkitektur Dokumentation af principper, der understøtter de vigtigste egenskaber ved den fremtidige arkitektur.

Beskriver hvordan projektet forholder sig til hvidbogens og andre overordnede principper og eventuelle egne, supplerende principper.

AR 1.1AR 1.2AR 2.1

ArchiMate Principles Catalog

Architecture Principles,

Målarkitektur Målarkitektur Struktureret overblik over de vigtigste elementer i målbilledet.

Skal give et samlet overblik over de vigtigste elementer og de vigtigste sammenhænge, gerne på tværs af flere grundperspektiver.

AR 2.1AR 2.2AR 2.3

ArchiMate Solution Concept Diagram

Architecture vision,

Migrationsstrategi

Målarkitektur Beskrivelse, der viser, hvordan målarkitektur realiseres over tid, fx med iterationer på givne tidspunkter.

Et overordnet roadmap, der viser eventuelle trinvise plateauer for målarkitekturens realisering. Kan fungere som grundlag for detaljeret planlægning.

AR 2.1AR 2.4

ArchiMate Application Migration Diagram

Capabilities,(Work packages)(Architecture Con-tracts),

Løsningsoverblik

Løsningsarkitektur

Et samlet overblik over løsningen på et givent tidspunkt.

Et dokument der beskriver den konkrete løsning. Udarbejdes typisk af eller i samarbejde med leverandører og vedligeholdes løbende efter aftale.

AR1.1AR 2.1AR 2.3AR 2.4

ArchiMate Solution Concept Diagram

Juridiske bindinger

Juridiske rammer

Overblik over juridiske bindinger, som har væsentlig betydning for arkitektur og anvendelse af hele eller dele af løsning.

Bindinger findes typisk i love, fordringer, direktiver, udbudsbekendtgørelser, kontrakter o.l.

AR 2.5AR 3.1AR 3.2

ArchiMate N/A Constraints,

Aftaleoverblik Juridiske rammer

Overblik over aftaler og kontrakter som skal være på plads for at realisere løsningen

Omfatter udover de grundlæggende leverandørkontrakter fx

AR 3.1AR.2.1AR 2.5

ArchiMate (Contract / Measure Catalog)

Contracts,

32

eller som sætter bindinger på løsningen.

databehandler- aftaler og serviceaftaler (SLA) med tredjeparter ifht tværgående processer og datadeling. Ift arkitekturoverblik er fokus på hvor der skal være aftaler og hvilke væsentlige bindinger disse giver på løsningen og dens anvendelse.

AR 5.2AR 6.1AR 7.1AR 8.1

Krav (overblik, specifikation)

Juridisk fortolkning

Overblik over forhold, der kræves eller ønskes overholdt i løsningen.

Kan omfatte forhold og opgaver af materiel og ikke materiel karakter og omfatter ikke kun den tekniske løsning. Et overblik over væsentlige krav og temaer for krav kan anvendes til arkitekturstyring. Krav indarbejdes i forskellige kontrakter og aftaler.

AR 2.1AR 2.2AR 2.3AR 3.1

ArchiMate Requirements Catalog

Requirements,Assumptions,Constraints,Gaps,

Sikkerhedsbegrænsninger

Sikkerhedsstandard

Overblik over de vigtigste sikkerhedstrusler og risici.

Områder, hvor der skal indgå risikovurdering og sikkerhedsforanstaltninger. Fx ift. processer, aktører, data og snitflader.

AR 4.1AR 4.2

ArchiMate

Sikkerhedsmodel

Sikkerheds-model og -regler

Beskrivelse af hvordan sikkerhed påvirker løsningens egenskaber.

Omfatter hvilken data der gemmes/udveksles, roller ift brugerrettigheder og adgangstyring til applikationer samt anvendt infrastruktur. Kan omfatte styring på tværs af løsninger og sikkerhedsdomæner (føderation), granularitet i rettighedsstyring og roller ift. ansvar. Kan omfatte andre sikkerhedsaspekter.

AR 4.1AR 4.2AR 7.1AR 8.1

ArchiMate Enterprise Security View(Role / Appli-cation Matrix)(Information / application Matrix)(Application Communica-tion Diagram)

Requirements,Constraints,Controls,Actors,Roles,Data entitiesInformation System Services,Logical Applications Components,Logical Technology Components,

Opgavekatalog

Forretningsstruktur

Oversigt over de opgaver, der indgår i projektets løsning.

Dokumentation, der beskriver forretningsservices og modtagere af disse. Termen ”opgaver” anvendes her som samlebegreb for termer, som forretningsservices, forretningstjenester eller (hovedforretnings)funktioner. Oversigten kan relateres til aktører i form af, hvem der udfører og

AR 5.1AR 5.2

ArchiMate Business Service / Function Catalog

Business Service,Functions,

33

modtager.Brugerrejse Processer En beskrivelse af en brugers

oplevelse af et forløb, hvor der løses opgaver.

Kan fx udarbejdes med brug af procesdiagram, tegneserie, mock-ups.

AR 5.1 ArchiMateBPMN

N/A(Business Use case Dia-gram)(Process Flow Diagram)

Business Service,Process,Functions,

Procesmodel Processer Dokumentation af de enkelte processer, som understøtter relevante opgaver.

Kan beskrive aktiviteter i disse og illustrerer ikke mindst flowet af disse.

AR 5.2 BPMN Process Flow Diagram

Processes,Events,Controls,Products,

Arbejdsgang Arbejdsgange En beskrivelse af aktørers udførelse af opgaver i et forløb.

Er en detaljering af processer og Use Cases, hvor man mere detaljeret viser, hvordan opgaverne løses og af hvem.Beskrives typisk som svømmebaner. Beskrives typisk med fokus på forretningshændelser, -objekter og -regler

AR 5.1AR 5.2

BPMN Process Flow DiagramEvent Dia-gram

ProcessesEvents,Controls,Products,

Forretningsobjektoverblik

Forretningsobjekter og begreber

Dokumentation, der beskriver de væsentligste forretningsobjekter, som løsningen skal håndtere.

Anvendes fx til scope projektet og udpege områder for semantisk 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.

AR 6.1 ArchiMate Conceptual Data Diagram

DataData Entities,

Begrebsmodel / -liste

Forretningsobjekter og begreber

Dokumentation, der beskriver begreber med definitioner og eventuelt relationer.

I praksis er det en uddybning af forretningsobjektmodellen. Kan udformes som en UML model eller en liste.

AR 6.2 UML Conceptual Data Diagram

Data entities,

Logisk datamodel

Logiske datamodeller

Model, som beskriver, hvilke informationer, der indgår i en afgrænset kontekst og hvordan de logisk hænger sammen.

Dokumentation, der beskriver attributter, relationer og kardinaliteter for de forretningsobjekter, der skal indgå i en eller flere løsninger.

AR 6.2 UML Logical data Diagram

Logical Data Components,

Datasæt Fysiske datamodeller

Overblik over hvilke datasæt, der er omfattet af løsningen.

Kan omfatte data og dokumenter placeret i forskellige registre og repositorier. Skal bidrage til at identificere behov for semantisk og teknisk interoperabilitet.

AR 6.4 ArchiMate Conceptual Data Diagram

Physical Data Components,

Udvekslingsformat

Fysiske datamodeller

Fastsat struktur for opstilling af data med henblik på

For hver integration skal der aftales

AR 6.2AR 7.1

UML Logical data Diagram

Physical Data Components,

34

udveksling i maskinlæsbar form.

udvekslingsformat.

Kontekstdiagram

Applikationsstruktur og integrationsmønstre

Giver et helt overordnet overblik over konteksten for de applikationskomponenter, der er i spil i løsningen.

Et væsentligt input til målarkitektur. Kan fx sætte applikationskomponenter i relation til hinanden og til de vigtigste aktører og anvendelser.

AR 7.1 ArchiMate TOGAF: Solution Concept Diagram

Information System Services,

Applikationslandskab +/- integrationer

Applikationslandskab og integrationer

Overblik over applikationskomponenter og integrationer.

Skal omfatte integrationer til både andre interne og eksterne løsninger.

AR 7.1 ArchiMate TOGAF:Application Portfolio catalogInterface catalogApplication Communica-tion DiagramApplication Migration Diagram

Information System Services,Logical Application Components,

Applikationer mappet til forretningsservices

Applikationslandskab og integrationer

Overblik over hvilke applikationer, der understøtter hvilke forretningsservices/processer/handlinger.

AR 5.1AR 5.2AR 7.1

ArchiMate TOGAF:Application / organization MatrixProcess / Application Realization Diagram

Information System Services,Logical Application Components,Processes

Applikation mappet til informationer

Applikationslandskab og integrationer

Overblik over hvilke applikationer, der bruger hvilke forretningsobjekter/data.

AR 6.1AR 7.1

ArchiMate Application Data MatrixApplication Communica-tion Diagram

Information System Services,Logical Application Components,Data Entities,

Applikationer mappet til roller

Applikationslandskab og integrationer

Relation mellem forretningsroller og applikationer er et vigtigt element i beskrivelse af sikkerhedsmodellen

AR 4.1AR 4.2AR 6.1AR 7.1

ArchiMate Role / Appli-cation Matrix

Roles,Applications,

Infrastrukturvalg

Infrastrukturvalg

En overordnet beskrivelse af tilgang til de grundlæggende teknologiservices.

Valg af teknologier, platforme og infrastrukturansvar, 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.

AR 8.1 Archimate N/A(Environ-ments and locations Diagram)

Platform Services,

Infrastrukturlandskab

Infrastrukturlandskab

Overblik over de vigtigste teknologiservices og infrastrukturkomponenter som

AR 8.1 ArchiMate Environments and locations Diagram

Platform Services,Logical Technology Components,

35

fx platform og komponenter til drift, integrationer, brugerrettighedsstyring og sikkerhed.

36

Bilag 4: Liste over modelsprog og udvekslingsformaterDette bilag indeholder en oversigt over krævede og anbefalede versioner af modelsprog og tilhørende åbne udvekslingsformater:

Modelsprog Version Udvekslingformat Krav/anbefaling

ArchiMate 3.0.1 ArchiMate Exchange File Format for ArchiMate 3.0

Krav

UML 2.5.1 XML Metadata Interchange / XMI 2.5.1 Krav

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 populært.

Anbefaling

DMN 1.1 1 Object management Group tilbyder XML formater til udvekling af DMN 1.1

Anbefaling

Bilag 5: Ordliste og begreberDette bilag findes som selvstændigt dokument:

Digital arkitektur - Begrebsliste i ISO-format: Digital arkitektur v. 0.4.2 (UDKAST)

1 Version 1.2 ventes snartligt

37

Retningslinjer om dokumentation af arkitektur i digitaliseringsprojekter

arkitektur.Digitaliseringsstyrelsen.dk