Retningslinjer for dokumentation og formidling af arkitektur i digitaliseringsprojekter. Juni - udkast version 0.9 til ekstern kommentering,

Transkript

1 Retningslinjer for dokumentation og formidling af arkitektur i digitaliseringsprojekter Juni - udkast version 0.9 til ekstern kommentering,

2 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 Arkitekturprodukter Prioriterede og anbefalede arkitekturprodukter Modellering Notations- og modelsprog Modelleringsniveau Sammenhæng på tværs af modeller Byggeblokke Værktøjer og formater Bilag 1: Tjekliste vedrørende arkitekturdokumentation Bilag 2: Definition af grundperspektiver Bilag 3. Liste over anbefalede arkitekturprodukter Bilag 4: Liste over modelsprog og udvekslingsformater Bilag 5: Ordliste og begreber

3 Indledning Dette 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ål Formå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ålgruppe Målgruppen er forretnings- og it-arkitekter, projektledere og leverandører med ansvar for at udarbejde dokumentation i digitaliseringsprojekter. Anvendelse Retningslinjerne 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

4 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. 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 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 Fællesoffentlig Rammearkitektur, som understøtter anvendelse af FDA Rammearkitektur. 4

5 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 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 begreber I 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 projekterne Arkitekturregel 1.3 Anvend fælles ramme for beskrivelse af arkitekturen stiller krav om, at projekter udarbejder relevant arkitekturdokumentation efter nærværende retningslinjer og deler denne, således at andre kan anvende denne til indsigt og genbrug. 5

6 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

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

8 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 information Formå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? FIGUR 2 EN INTERESSENT MED ET PERSPEKTIV SER EN VISNING DER MODSVARER INTERESSEN 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

9 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 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 Behov for formidlet dokumentation i form af tekst, billeder, video, mundtligt Bruger Ejer Governance-aktør Sikkerhedsaktør Juraansvarlig Forretning Sikkerhedsaktør Arkitekturperspektiver og -visninger I 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 Systems and software engineering Architecture description. 9

10 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. FIGUR 4 FIRE TVÆRGÅENDE PERSPEK- TIVER PÅ FORRETNINGS- OG IT- ARKITEKTUREN 10

11 Arkitekturreol Dette 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

12 Arkitekturprodukter I 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

13 Prioriterede og anbefalede arkitekturprodukter Dette 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

14 Modellering En 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 modelsprog Et 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

15 FIGUR 8 FDA ARKITEKTURREOLEN MED ANBEFALEDE MODELSPROG Modelleringsniveau Modellering 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

16 FIGUR 9 ILLUSTRATION AF MODELSPROGS ANVENDELSE PÅ FORSKELLIGE NIVEAUER Sammenhæng på tværs af modeller Hvis 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. Byggeblokke I 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

17 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 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øs- 17

18 ningsbyggeblok (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 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 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

19 Bilag 1: Tjekliste vedrørende arkitekturdokumentation Denne 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 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 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. 10. Udarbejd projektets overordnede arkitekturmodel i ArchiMate med brug af arkitekturbyggeblokke fra FDA byggeblokkataloget. Udarbejd relevante detaljerede modeller i relevant notationssprog. 19

20 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

21 Bilag 2: Definition af grundperspektiver Dette 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

22 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. 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. 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. Arkitekturprodukter Governancemodel, Interessentanalyse, Mål, Gevinstmodel, Metodeanvendelse, Arkitekturbeslutningslog. 22

23 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). 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ø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. Arkitekturprodukter Vision/Målbillede, Kapabilitetsoverblik, Udfordringer, Arkitekturprincipper, Målarkitektur, Migrationsstrategi, Løsningsoverblik. 23

24 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. Principper P3 Arkitektur og regulering understøtter hinanden. AR 3.1: Tag højde for juridiske bindinger ift. deling og genbrug af data og itsystemer. 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. Arkitekturprodukter Juridiske bindinger, Krav. 24

25 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). 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 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. Arkitekturprodukter Sikkerhedsbegrænsninger, Sikkerhedsmodel. 25

26 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. 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 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. Arkitekturprodukter Opgavekatalog, Brugerrejser, Procesmodeller, Arbejdsgange 26

27 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. 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 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. Arkitekturprodukter Forretningsobjekter, Begreber, Logisk datamodel, Datasæt, Udvekslingsformater. 27

28 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. Principper P7 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 Kontekstdiagram, Applikationslandskab med integrationer og evt. mappet til forretningsservices, processer og informationer. 28

29 Infrastruktur Arkitekturperspektiv med fokus på teknologi-services, som leverer den generelle 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, 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. Arkitekturprodukter Platformsvalg, Infrastrukturlandskab. 29

30 Bilag 3. Liste over anbefalede arkitekturprodukter Dette 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

31 Hylde i FDA reolen Beskrivelse (kort) Kommentarer AR nr. Anbefalet Arkitekturprodukt 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. Interessentanalyse Styringsrammer Overblik over de vigtigste interessenter og deres vigtigste interesser (mål, gevinster, værdier og udfordringer). Mål Styringsrammer Overblik over de mål projektet og løsningen skal fremme. Gevinstmodel Fremgangsmåde Beskrivelse af de vigtigste gevinster, som skal realiseres. Metodeanvendelsdder Fremgangsmå- Beskrivelse af anvendte meto- og notationer, herunder tilpasning til projekt/kontekst Arkitekturbeslutningslog Projektforløb Log over beslutninger med væsentlig betydning for løsnin- gens egenskaber. Vision / Vision og mål Dokumentation, der beskriver målbillede organisationens vision og målbillede af den fremtidige arkitekturs hovedegenskaber 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. 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. Kan relateres til interessentanalyse og anvendes til at udarbejde gevinstmodel. Anvendes til styring og prioritering. 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. Fx om projektet er underlagt statens program eller it-projektmodel, om der anvendes agile metoder, om der anvendes aftalt arkitekturrammeværk og notation. Knyttet til ændringsanmodninger. Giver et klart billede af forretningens strategiske vision og mål med løsningen, gerne udtrykt som AR 1.1 ArchiMate N/A Stakeholders, Organization units, Actors, Roles, (Implementation Governance), AR 1.2 ArchiMate Stakeholder Stakeholders, Map Matrix Organization units, Actors, Roles, Drivers, Goals, Objectives, AR 1.2 ArchiMate Driver, Goal, Drivers, Objective Goals, Catalog Objectives, AR 1.2 ArchiMate Value Chain Goals, Diagram Objectives, Measures, Capabilities Work Packages, AR 1.3 ArchiMate N/A Implementation AR 1.4 governance, AR 1.5 Guidelines, Standards, Specifications, AR 1.2 Archimate N/A Requirements catalog, AR 1.2 ArchiMate Solution Architecture Vision, AR 2.1 Concept Diagram 31

32 på konceptuelt niveau. strategiske kapabiliteter. 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.2 AR 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.1 AR 1.2 AR 1.4 AR 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.1 AR 1.2 AR 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.1 AR 2.2 AR 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.1 AR 2.4 ArchiMate Application Migration Diagram Capabilities, (Work packages) (Architecture Contracts), 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.1 AR 2.1 AR 2.3 AR 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.5 AR 3.1 AR 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 eller som sætter bindinger på løsningen. Omfatter udover de grundlæggende leverandørkontrakter fx databehandleraftaler og serviceaftaler (SLA) med tredjeparter ifht tværgående processer og datadeling. Ift arkitekturoverblik er fokus på hvor der skal være aftaler og AR 3.1 AR.2.1 AR 2.5 AR 5.2 AR 6.1 AR 7.1 AR 8.1 ArchiMate (Contract/ Measure Catalog) Contracts, 32