Retningslinjer for arkitekturdokumentation i digitaliseringsprojekter Beta-version

Transkript

1 Retningslinjer for arkitekturdokumentation i digitaliseringsprojekter Beta-version September 2017

2 Indhold Introduktion til retningslinjerne... 3 Hvad indeholder retningslinjerne for dokumentation af arkitektur?... 4 Fælles sprog for arkitekturdokumentation... 4 Dokumentationsperspektiver... 6 Højniveau beskrivelser med mulighed for detaljering... 7 Grundelementer (udvalgte fra ArchiMate)... 9 Dokumentationsperspektiver Jura Organisation Semantik (data ) Teknik Governance Sikkerhed Anvendelse af retningslinjerne Rådgivning og yderligere information... 18

3 Introduktion til retningslinjerne Retningslinjer for dokumentation af arkitektur i digitaliseringsprojekter giver itarkitekter et fælles sprog for dokumentation og skal medvirke til at højne kvaliteten af arkitekturen i de fællesoffentlige digitaliseringsprojekter. Hvidbog om fællesoffentlig digital arkitektur fremhæver, at en vigtig del af den fællesoffentlige digitale arkitektur er krav til dokumentation af løsningsarkitektur i de fællesoffentlige digitaliseringsprojekter. Det er væsentligt nemmere at samarbejde og få stikkene til at passe sammen, når arkitektur er beskrevet efter samme metodik. Retningslinjer for dokumentation af arkitektur i digitaliseringsprojekter stiller pragmatiske krav til løsningernes dokumentation på en måde, der kan sikre, at dokumentationen ikke blot giver værdi til fællesskabet, men også giver værdi for design og udvikling af den enkelte løsning i de konkrete projekter. Retningslinjerne skal betragtes som en simpel ramme for dokumentation, der ved at understøtte hvidbogens principper og regler gør det nemmere at arbejde med arkitekturstyring som del af den daglige projektpraksis, gør det nemt at gennemføre reviews og som ydermere bidrager til overblik over løsninger i den fællesoffentlige digitaliseringsstrategi. Retningslinjerne udpeger letforståelige overblik, der dokumenteres. Disse overblik giver nøgleaktører et indblik i, hvordan arkitekturen i en løsning ser ud, og hvordan den hænger sammen med den fællesoffentlige digitale arkitektur. De fælles retningslinjer for dokumentation af arkitektur er baseret på erfaringer med hvilken dokumentation, der giver mest værdi og med udgangspunkt i internationalt forankrede og velafprøvede metoder og arkitekturrammeværker. Arkitekturdokumentationen tager udgangspunkt i, at der er mange forhold, der skal tages højde for i arkitekturarbejdet, når man skal skabe sikker og effektiv tværgående digitalisering og datadeling. Målgruppen for dette dokument er: Arkitekter (primært enterprise arkitekter, forretningsarkitekter, løsningsarkitekter) med ansvar for at udarbejde arkitekturdokumentation i digitaliseringsprojekter Projektledere og projektmedarbejdere med ansvar for projektdokumentation Leverandører med ansvar for udarbejdelse af arkitekturdokumentation i forbindelse med tilbud og dokumentation af leverancer (løsninger).

4 Hvad indeholder retningslinjerne for dokumentation af arkitektur? Retningslinjer for dokumentation af arkitektur i digitaliseringsmodeller baserer sig på et fælles sprog for dokumentation samt fire grundlæggende og to tværgående dokumentationsperspektiver. Det er valgt at benytte dokumentations perspektiver for at kunne imødekomme, at man har brug for at se en løsningsarkitektur fra forskellige sider, fx kan der være brug for både at kunne se på de sikkerhedsmæssige udfordringer og det processuelle design i en løsning. Retningslinjerne understøtter et højt niveau i beskrivelserne, der imødegår styring og overordnet design af løsninger samt arkitekturreviews. Dvs. de seks forskellige dokumentationsperspektiver består af beskrivelser af de elementer i arkitekturen, der set i et helikopterperspektiv, er vigtige. For mange løsninger, er der dog forhold der på detailniveau er vigtige for løsningsdesignet og som skal inddrages og udarbejdes, når det er relevant. Retningslinjerne er med andre ord et udgangspunkt, men for mange projekter vil det være relevant at udarbejde mere detaljeret dokumentation, eksempelvis begrebs- og datamodel som også indgår i modelreviews. Fælles sprog for arkitekturdokumentation Når man laver arkitekturdokumentation sker det typisk bedst gennem modeller, der visualiseres som diagrammer. For at understøtte det tværgående samarbejde skal disse beskrives efter en fælles standard, der definerer det grundlæggende indhold, struktur og form. Et modelsprog giver et sæt af elementer, deres relationer og ikoner til den visuelle repræsentation. I den fællesoffentlige arkitekturdokumentation er ArchiMate 1 valgt som fælles modelsprog. Archimate er et modelsprog beregnet til at beskrive arkitektur på højniveau. Tilsvarende lavniveau-modelsprog er UML 2 til detaljeret modellering af begreber og data, BPMN 3 til modellering af processer og fx DMN 4 til regelmodellering. Elementerne i dokumentationsperspektiverne kan opfattes som byggeblokke. En byggeblok repræsenterer en (potentielt genanvendelig) del af en forretnings-, IT- eller 1 Archimate er en standard, der ejes og vedligeholdes af The Open Group og kan anvendes sammen med Opens Groups arkitekturrammeværk TOGAF - The Open Group Architecture Framework. 2 Unified Modeling Language 3 Business Process Modeling Notation 4 Decision Modeling Notation

5 arkitektonisk kapabilitet, der kan kombineres med andre byggeblokke til at levere løsninger. En byggeblok kan kombineres med andre byggeblokke til at definere en del af eller en samlet arkitektur. Byggeblokke kan kategoriseres i to typer: Arkitekturbyggeblokke Løsningsbyggeblokke En delmængde af arkitekturmodellen som beskriver et enkelt aspekt af den overordnede model - forkortes ABB. En ABB er abstrakt og kan beskrive generelle krav til arkitekturen. Er typisk på konceptuelt og logisk niveau. En foreslået løsning, der opfylder en arkitekturbyggebloks (ABB) specifikation, dvs. en del af en løsning som stiller krav til, hvordan løsningen realiseres - forkortes LBB. En LBB er konkret, dvs. noget der indgår i en løsning i virkeligheden. Det 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. Byggeblokbegrebet er hentet fra TOGAF og ArchiMate, hvor der traditionelt har været fokus på forretning og it. I den fællesoffentlige digitale arkitektur (FDA) anvendes byggeblokbegrebet i en bred betydning. Fx kan en lov opfattes som en væsentlig byggeblok i et juridisk dokumentationsperspektiv. Selve idéen om en lov om digital post ses som en juridisk ABB, der kan genbruges af andre lande i mange udformninger. Den konkrete lov i Danmark kan ses som en LBB, der også kan genbruges omend med tilpasning og beslutning i et andet land. Byggeblokke kan være simple eller sammensatte. Fx anvender den fælleskommunale rammearkitektur sammensatte byggeblokke. Nedenstående figur illustrerer byggeblokke på forretningsniveau. Det første diagram viser seks adskilte enkle byggeblokke: Forretningsobjekt, Forretningsfunktion, Forretningsproces, Forretningshændelse, Forretningsservice og Forretningsinterface. Det andet viser en sammensat byggeblok i form af en Forretningsservice, der indkapsler de fem øvrige byggeblokke. Det tredje diagram har forenklet det helt og viser alene en Forretningsservice som en sort boks. Hvor detaljeret beskrivelsen er, afhænger af det konkrete behov, i forhold hvem der skal se og anvende arkitekturdokumentet. Enkelte byggeblokke Sammensat byggeblok Forenklet billede af sammensat byggeblok (black box)

6 FDA rammearkitekturen leverer et fælles sprog i form af en taksonomi for klassifikation af de byggeblokke, der indgår i en løsning i et holistisk perspektiv med fokus på det, der er vigtigt for interoperabilitet og digital sammenhæng. Taksonomien udvikles med udgangspunkt EIRA 5, der har til formål at understøtte interoperabilitet med fælles europæiske løsninger. FDA rammearkitekturen er således en dansk profilering af EIRA og et fælles sprog for de elementer, som skal anvendes i arkitekturdokumentationen for at sikre genbrug af både arkitektur- og løsningsbyggeblokke. Dokumentationsperspektiver Der er med inspiration fra det europæiske arbejde, herunder EIF 6 og EIRA, valgt fire basale og to tværgående perspektiver for dokumentation. De seks dokumentationsperspektiver skal tilsammen understøtte de informationsbehov, der er relevante i forhold til at vurdere en løsningsarkitektur. De basale dokumentationsperspektiver dækker niveauerne jura, organisation, semantik (data) og teknik. Desuden anvendes to tværgående dokumentationsperspektiver i arkitekturdokumentationen: Governance og sikkerhed. Dokumentationsperspektiverne indeholder: 1. Jura beskriver de forhold, som er rammesættende for løsningen, fx lovgivning og kontrakter i forhold til it-løsningers udbud, drift og anvendelse. Dette dokumentationsperspektiv modsvarer hvidbogens princip og arkitekturregler om jura. 2. Organisation beskriver de forhold, som indgår i den forretningsmæssige opgaveløsning, herunder håndtering af forretningsinformation i processer udført i forretningsfunktioner efter forretningsregler og leveret eksternt som forretningsservices via en ekstern grænseflade. Dette dokumentationsperspektiv modsvarer hvidbogens princip og arkitekturregler om opgaver. 3. Semantik (data)beskriver de informationer, der skal håndteres af såvel forretningen som af teknikken i form af begreber, data og repræsentationer af data. Dette dokumentationsperspektiv modsvarer hvidbogens princip og arkitekturregler om information. 4. Teknik beskriver komponenter, der understøtter it-services som tilbyder funktioner via tekniske snitflader samt de underliggende teknologi-services, som leveres fra den generelle infrastruktur. Dette dokumentationsperspektiv modsvarer hvidbogens principper og arkitekturregler om applikation og infrastruktur. 5 European Interoperability Reference Architecture 6 European Interoperability Framework

7 5. Governance beskriver de aktører, mål, kapabiliteter og principper, som er styrende for løsningen det omfatter den politiske kontekst som løsningen bygges i. Dette er et tværgående dokumentationsperspektiv, der modsvarer hvidbogens principper og arkitekturregler om styring og strategi. 6. Sikkerhed beskriver de elementer, som på tværs af de øvrige dokumentationsperspektiver, er vigtige i forhold til sikkerhed og beskyttelse af privatlivet. Det omfatter fx juridiske krav, organisatoriske informationer og processer (fx sikkerhedspolitikker og kontroller), data (fx datapolitik og sikkerhedsklassifikation) samt relevante tekniske services (fx adgangs- og rettighedsstyring). Dette tværgående dokumentationsperspektiv modsvarer hvidbogens principper og arkitekturregler om sikkerhed. Udover disse seks dokumentationsperspektiver kan man frit lave andre dokumentationsperspektiver i forhold til de konkrete behov der måtte være i et projekt. Retningslinjer for dokumentation af arkitektur i digitaliseringsprojekter anbefaler at udarbejde diagrammer for de seks dokumentationsperspektiver med brug af ArchiMate ikoner suppleret med en tekstuel beskrivelse, der giver læseren en kort og klar forklaring på, de væsentligste forhold, som beskrives. Det skal understreges, at man derudover også kan beskrive et dokumentationsperspektiv på andre måder, fx visuelt som en tegneserie eller med mere pædagogiske ikoner, som en fortælling, i tabelform osv. Højniveau beskrivelser med mulighed for detaljering Retningslinjerne stiller krav om, at der udarbejdes dokumentation på et højt niveau, der imødekommer styring og overordnet design af løsninger samt arkitekturreviews. Dvs. som udgangspunkt stilles krav om beskrivelser af de elementer i arkitekturen, der set i et helikopterperspektiv, er vigtige. Nedenstående figur illustrerer den overordnede sammenhæng for arkitekturdokumentation og notation mellem hhv. det europæiske lag (EIRA), det fællesoffentlige lag (FDA rammearkitektur) og retningslinjerne for arkitekturdokumentation forhold til projektdokumentation.

8 Retningslinjerne giver dog samtidig mulighed for og ansporer projekterne til at uddybe de seks dokumentationsperspektiver med yderligere detaildokumentation, når det er relevant. Til arkitekturreviews kan det være et krav også at udarbejde enkelte artefakter på mere detaljeret niveau, fx et modelreview, hvor der skal udarbejdes en begrebsmodel som materialegrundlag. Efterfølgende er givet eksempler på detaljerede arkitekturartefakter, som også er anbefalet at udarbejde i mange projekter, og som kan forespørges til arkitekturreviews. Konceptuelt Jura Organisation Logisk (eksempler på arkitekturprodukter) Lovkrav og juridiske rammer Målarkitektur Kravspecifikation Udbudsbekendtgørelse Serviceaftale Aktør- og rollemodel Brugerrejse Servicekatalog Procesmodel Proces/begrebs-mapning Opgaveunderstøttelse Semantik (Data) Teknik Begrebsliste Begrebsmodel Datamodel Datasætkatalog Metadata Løsningsarkitektur It-løsningslandskab m. integrationer Applikations/proces-mapning Integrationsstrategi og mønstre Teknologireferencemodel It-infrastrukturlandskab

9 Governance Målbillede Vision, mål og strategier Interessentanalyse Governancemodel Sikkerhed og privacy Sikkerhedsstrategi Sikkerhedsmodel Arkitekturproblemstillinger Databehandleraftale Data management model Af ovenstående figurer og beskrivelser følger, at det anbefales, at projekterne begrænser anvendelsen af ArchiMate til dokumentation på det konceptuelle niveau og den overordnede del af det logiske niveau. Den detaljerede arkitekturdokumentation for it-løsninger foregår bedst i de modelleringssprog, som anbefales i de fællesoffentlige begrebs- og modelregler. Til detailmodellering af forretningsprocesser anbefales BPMN. Opdelingen giver mulighed for, at ArchiMate anvendes som metamodel for løsningen, der via links henviser til detailmodeller med det niveau af informationer, der muliggøres gennem anvendelsen af de dertil egnede modelleringssprog. Grundelementer (udvalgte fra ArchiMate) Dette afsnit indeholder en liste over de vigtigste elementer i ArchiMate, som er udvalgt som dem projekterne især skal have for øje i dokumentationen. Disse elementer er centrale i FDA rammearkitekturen. Hvis et projekt ønsker at anvende de øvrige elementer i Archimate er der intet til hinder for dette, men man skal dog være opmærksom på, at man anvender elementerne konsistent med den måde de anvendes på i rammearkitekturen. For hvert element er der en visualisering i form af et ArchiMate-ikon, en dansk term og definition oversat fra ArchiMate, den engelske term, samt et eksempel på indholdet. Med hensyn til farver bemærkes det, at farverne ikke tillægges en særlig betydning, men at der anvendes standard ArchiMate notation for at lette anvendelsen af standardværktøjer og udvekslingsformater.

10 ArchiMate element Definition [Dansk] Term [English] Eksempel En Kapabilitet er en formåen en organisation, person, eller et system har Capability Sende uafviselig digital post Et Mål repræsenterer en formel intention, retning eller et ønsket end-state på højt niveau Goal Tryghed og tillid skal i centrum Et Princip er en formelt besluttet hensigt, der skal realiseres via arkitekturen Et Krav repræsenterer et behov, der er udtrykt og forventes opfyldt af arkitekturen Note: Anvendes også til at beskrive væsentlige bindinger givet af lovgivning. En Aktør er en entitet, der er i stand til at handle Principle Requirement Business Actor Arkitektur styres på rette niveau efter fælles rammer NemID skal anvendes til sikker identifikation af brugere Borger En Forretningsfunktion er en samling af handlemåder baseret på et specifikt sæt af kriterier, i tæt forbindelse til en organisation, men ikke nødvendigvis eksplicit underlagt styring fra denne organisation Et Forretningsinterface er et adgangspunkt til en Forretningsservice, der gør den tilgængelig for omgivelserne Business Function Business Interface Beregning af løn Borger.dk Et Forretningsobjekt repræsenterer et objekt, der anvendes i et specifikt forretningsdomæne Business Object Recept

11 En Forretningsservice repræsenterer en eksplicit defineret og udstillet forretningsmæssig adfærd Business Service Anmeld flytning En Hændelse angiver et skift i en (organisatorisk) tilstand. Årsag og konsekvenser kan være interne, eksterne eller en kombination En Kontrakt repræsenterer en formel eller uformel specifikation af en aftale Business Event organization Contract Patient udskrevet Service Level Agreement En Proces repræsenterer en sekvens af handlinger En Rolle er det ansvar for at gennemføre en specifik handling, som en aktør kan tildeles, eller den del af en bestemt handling eller hændelse som en aktør spiller En Repræsentation udgør en forståelig form af den information som et forretningsobjekt eller dataobjekt indeholder Data er information lagret med henblik på (gen)anvendelse, dvs.data repræsenterer et dataobjekt, der er struktureret, så det kan processeres automatisk Et Applikationsinterface repræsenterer et adgangspunkt, hvor applikationsservices er tilgængelige En Applikationsservice repræsenterer en explicit defineret og udstillet applikationstjeneste Business Process Business Role Representation Data Object Application Interface Application Service Ændring af folkeregisterad resse Bruger af offentlig service Dokument, SMS Personnummer Personbrugerv endt HTML5 eller maskinvendt API Digital postkasse En Komponent repræsenterer en samling af applikationsfunktionaliteter koblet til en implementeringsstruktur, der er modulopbygget og udskiftelig En Teknisk service repræsenterer en explicit defineret og udstillet teknisk tjeneste Application Component Technical Component ESDH Beskedfordeler

12 Dokumentationsperspektiver Dette afsnit gennemgår de seks dokumentationsperspektiver, retningslinjerne udpeger. Hvis et projekt ønsker at anvende andre dokumentationsperspektiver, herunder ArchiMates eksempler på perspektiver (kaldet views/viewpoints), er der intet til hinder for dette. Hvilke dokumentationsperspektiver, der udarbejdes på et givent tidspunkt i projektet, og hvor detaljeret det enkelte dokumentationsperspektiv udformes på et givent tidspunkt, afhænger af projektets karakter, scope, fokus og hvor langt det er kommet i arbejdet. Som tommelfingerregel, skal et dokumentationsperspektiv indeholde de informationer, der er relevante for den givne målgruppe på et givent tidspunkt. De fire basale dokumentationsperspektiver jura, organisation, semantik (data) og teknik udgør de centrale dele af dokumentationen af en løsning i et digitaliseringsprojekt. Herudover vises dokumentation for projektets governance, samt sikkerhed og privacy i specialiserede tværgående dokumentationsperspektiver. Baggrundsfarverne i de seks dokumentationsperspektiver følger regnbue-metaforens aspekter i en rækkefølge så de kan foldes ind og ud som en harmonika startende i bunden med rød for infrastruktur.

13 Jura Det juridiske dokumentationsperspektiv omhandler de juridiske rammer, som projekter og deres løsninger opererer i. Det omfatter primært lovgivning o.l. lovmæssige rammer og bindinger samt kontrakter og aftaler, der ligeledes sætter rammer og bindinger. Her anvendes to ArchiMate elementer: Krav (fx i lov eller kontrakt) og kontrakt. Skal selve det politisk-juridiske dokument med i modellen (fx en lov, forordning eller direktiv) beskrives det med anvendelse af Archimate-elementet Forretningsobjekt. Ved at få dokumenteret de juridiske rammer, der stammer fra lovgivning, forlig, strategier og handleplaner opnås en bedre forståelse for muligheder og begrænsninger i løsningen.

14 Organisation Det organisatoriske dokumentationsperspektiv viser de organisatoriske og forretningsmæssige forhold, der understøttes i løsningen. Dokumentationsperspektivet omfatter de nødvendige elementer fra EIRA til at opnå en overordnet forståelse af denne kontekst. Derudover er der medtaget ArchiMate-elementerne proces og hændelse. De leverancer, der omhandler brugerrejse og sammenhængende brugeroplevelse, kan modelleres overordnet i dokumentationsperspektivet. Er der behov for større detailgrad anvendes BPMN. Ved at dokumentere det organisatoriske dokumentationsperspektiv kan man identificere behov for fx deling af data herunder fx om forretningshændelser i tværgående processer - og krav til hvordan data, data-anvendelse og distribution af data bindes sammen med forvaltnings- og forretningsmæssige behov i den opgaveløsning, som den tekniske løsning skal understøtte. Semantik (data) Det semantiske dokumentationsperspektiv giver et overblik over data og præsentationen af data i løsningen. Dette dokumentationsperspektiv kan anvendes til at identificere og beskrive krav til sammenhæng i forhold til begreber, klassifikationer, datas egenskaber og kvalitet samt dataformater. Dette kan bl.a. være med til at sikre sammenhæng mellem dokumentationen af applikationer og brugernes anvendelse.

15 Arkitekturdokumentationens semantiske dokumentationsperspektiv indeholder dataobjekt- og repræsentations-elementet fra ArchiMate. Teknik Det tekniske dokumentationsperspektiv anvender fire ArchiMate-elementer i beskrivelsen af applikationer og infrastruktur. I dette dokumentationsperspektiv beskrives fx hvilke applikationskomponenter, der indgår i løsningen, hvilke integrationer der er behov for mellem applikationer og hvilke interfaces i form af integrationsmønstre og protokoller, der skal anvendes, samt eventuelt beskrivelse af den underliggende infrastruktur, som fx særligt væsentlige krav til platform, hosting, netværk o.l. mhp sikker og effektiv infrastruktur for sammenhængende løsninger. Governance Dette tværgående dokumentationsperspektiv viser strategisk forankring af løsningen, styring af udvikling, vedligeholdelse og drift af løsningen, samt aktører og roller, der indgår i løsningsbeskrivelsen. Dette dokumentationsperspektiv anvendes især til at tydeliggøre de centrale interessenters mål og de forretningsmæssige kapabiliteter og udfordringer der skal håndteres i projektet samt de principper der er styrende for projektet..

16 Sikkerhed Dette tværgående dokumentationsperspektiv dokumenterer sikkerheds- og privacyaspekter af løsningen. Sikkerhed og privacy er et konstant fokuspunkt for arkitekturen igennem sikkerhedsaspektets centrale rolle i arkitekturprincipperne. Dokumentationsperspektivet anvendes til at vise de byggeblokke, der håndterer sikkerheden uden en beskrivelse af relationerne, idet fokus er på overblikket over, hvad der udgør kernen i sikkerheden. Dokumentationsperspektivet kan udbygges i dybden og detaljeringen, men behovet for væsentligt højere detaljeringsniveauer løses bedre ved modellering i standarder som tilgodeser modellering med høj kompleksitet, granularitet og detaljerigdom, f. eks UML. Der kan henvises til sådanne modeller fra byggeblokkene. Se FDA modelregler.

17 Anvendelse af retningslinjerne Nærværende beta-version af retningslinjerne er under afprøvning i konkrete projekter frem til primo Herefter revideres retningslinjerne og der udgives en endelig version. Retningslinjerne er tænkt som praktisk guide i arbejdet med dokumentation: I det værktøj, der anvendes vælges byggeblokkene, og der udfyldes metainformationer om de enkelte instanser af blokke i værktøjet. En instans af en byggeblok aktør kan i dette tilfælde eksempelvis være KL og SKAT. En detaljeret vejledning til arbejdet med arkitekturdokumentation i Enterprise ArchiMate inkl. eksempler er under udarbejdelse. Der udarbejdes endvidere på værktøjsunderstøttelse til udarbejdelse af arkitekturdokumentation samt modellering efter de fællesoffentlige begrebs- og datamodelregler. For nuværende pågår et arbejde med Enterprise Architect, men ønsket er understøttelse af flere værktøjer samt et stort fokus på muligheder for udveksling mellem relevante værktøjer.

18 Rådgivning og yderligere information Arkitekturdokumentation er en væsentlig hjørnesten i digitaliseringsstrategiens arbejde med at sikre en sammenhængende digital offentlig sektor, herunder anvendelse af den fællesoffentlige arkitektur og derigennem kvalitetssikre og bidrage til bedre digitale løsninger. Arkitekturdokumentation skal ses i sammenhæng med den øvrige arkitekturstyring, der igangsættes i regi af digitaliseringsstrategiens initiativ 8.1. Et centralt element er den rådgivning, der af sekretariatet for initiativ 8.1 tilbydes til projekter, der er en del af initiativer med et væsentligt indhold af data og arkitektur. Sekretariatet forsøger i samarbejdet med de øvrige initiativer proaktivt at identificere og tilbyde sparring til relevante projekter, men alle projekter er velkomne til at kontakte sekretariatet på arkitektur@digst.dk med spørgsmål og ønsker til sparring.

19 Retningslinjer for arkitekturdokumentation i digitaliseringsprojekter arkitektur.digst.dk