Forklaringer til spørsmålene i undersøkelsen

Her gis bakgrunnsinformasjon og forklaringer til spørsmålene i spørreundersøkelsen til Arkitekturrådet okt. 2020.

Vennligst legg merke til følgende før du starter:

  • Nummereringen her tilsvarer nummereringen i spørreskjemaet.

  • Forklaringene benytter noen steder uthevet skrift for å angi hva som anses som hovedspørsmålet som det skal svares på.

  • Noe av stoffet vil være for spesielt interesserte - ikke alle vil behøve å lese alt for å kunne forstå og svare på spørsmålene.

  • Ta primært utgangspunkt i egen sektor og virksomhet, men utdyp gjerne hvordan dette skiller seg fra nasjonale hensyn.

1. Navn på virksomhet og person

Greit å vite, men feltet er frivillig

2. Nytteverdi av ulike typer referansearkitekturer

2.1. Generiske, løsningsuavhengige, arkitekturmønstre

Momenter å vurdere (til inspirasjon):

  • + Felles språk og felles forståelse

  • + Diskusjonsunderlag på tvers av ulike roller inen forretning og IT

  • + Sammenlikne alternative arkitekturer og løsninger for å finne hva som passer best ut fra aktuelle behov

  • + Rasjonalisere det nasjonale landskapet av fellesløsninger i dagens situasjon

  • + Definere teknologiuavhengige målarkitekturer

  • + Interoperabilitet på tvers av ulike løsninger

  • + Enhetlig formulering av krav til løsninger (f.eks. logging)

  • o Ulike målgrupper – virksomhetsarkitekter vs. løsningsarkitekter

  • - Kan virke unødig abstrakt og fremmedgjørende for noen

2.2. Arkitekturmønstre som viser bruken av nasjonale fellesløsninger

Momenter å vurdere (til inspirasjon):

  • + Hver enkelt løsningsleverandør gjør stort sett en god jobb med å beskrive bruken av deres fellesløsninger, men det kan være nyttig å finne samlede beskrivelser av hvordan ulike felleskomponenter kan inngå og spille sammen for aktuelle formål.

  • - Mange fellesløsninger krever brukerbetaling - det kan være problematisk å beskrive bruken av slike produkter uten at det gis alternativer

2.3. Arkitekturmønstre som løsningsmaler

Momenter å vurdere (til inspirasjon):

  • + Arkitekturmønstre som så langt som mulig beskriver bruken av spesifikke teknologier og løsninger (tjenester, komponenter) gir løsningsarkitekter og utviklere raskere vei til målet

  • - Dersom en utelukkende beskriver veldig løsningsnære arkitekturmønstre, kan det hemme innovasjon

  • - Det kan være problematisk å beskrive bruken av enkelte kommersielle produkter uten at det gis alternativer

2.4. Eksempler til inspirasjon

Momenter å vurdere (også til inspirasjon):

  • + Eksempler på god praksis er utgangspunktet for gode referansearkitekturer

  • + Det er viktig å lære av de som går foran

  • - Risiko for ukritisk spredning av "dårlig" praksis

2.5. Obligatoriske føringer

Momenter å vurdere (til inspirasjon):

  • + Obligatoriske føringer og standarder danner grunnlaget for interoperabilitet og samhandlingsevne

  • - Kan gi unødig byråkrati

  • - Kan hemme innovasjon og konkurranse

2.6. Målbilder

Momenter å vurdere (til inspirasjon):

  • + Referansearkitekturer kan fungere som felles målbilder, slik at alle drar i samme retning

  • - Om målbildene blir for detaljerte, vil det kunne hemme innovasjon

4. Nyttevurdering av dagens referansearkitekturer for datautveksling fra Digdir

Nytten bør ses i forhold til aktuelle målgrupper. Målgrupper så langt er virksomhetsarkitekter, løsningsarkitekter og tech leads.

Gjeldende beskrivelser av mønstre som det spørres om finnes under Referansearkitektur for datautveksling (inntil videre på "gammel" løsning).

6. Forbedringer og utvidelser av referansearkitektur for datautveksling

6.1. Basismønstre for datautveksling

Forslag:

  1. Generell forbedring av foreliggende dokumentasjon.

    Eksempler og momenter:

    • + Tverrgående temaer, slik som f.eks. avtaleforvaltning, tilgangskontroll og dataminimering, er noen steder utelukkende beskrevet i tilknytning til enkelte mønstre.

    • + Det kan legges til ytterligere detaljer og alternativer i løsningsmønstre som viser anvendelser av de generiske arkitekturmønstrene.

    • + Det kan være nyttig å gjøre noen av beskrivelsene lettere tilgjengelige for "ikke-tekniske" målgrupper

    • - Det kan koste mer enn det smaker å flikke på detaljer

  2. Legg til et basismønster for Forespørsel-svar mot flere datakilder uten mellomledd, muliggjort av teknologier som GraphQL og SPARQL/RDF (semantiske teknologier og lenkede data ref. W3C).

    Momenter:

    • - Semantiske teknologier oppfattes av mange som tungt tilgjengelige

    • + Digdir og Brønnøysundregistrene har i 2020 fått innvilget EU-midler til et prosjekt (STIRdata) som blant skal utvikle metoder og løsninger for enkel tilgjengeliggjøring og bruk av RDF-ressurser. Dette prosjektet vil langt på vei kunne definere en nasjonal referansearkitektur for dette mønsteret.

    • + Semantiske teknologier og lenkede data, ref. W3C, understøtter også målbilder om Data Mesh.

  3. Vurder visse tillegg i eksisterende basismønstre

    Figuren nedenfor oppsummerer hva som er tenkt så langt om slike tillegg. Kommentarer til deler av dette her:

    • Meldingsbasert forespørsel-svar (asynkront) kan beskrives som et alternativ til synkront API-oppslag. Merk: Arkitekturen for EU’s Single Digital Gateway foreskriver dette som eneste mulighet, der gjennom bruk av eDelivery (tilsvarer eMelding).

    • Generelle konsepter for dataminimering bør beskrives under "generisk forespørsel-svar" og henvises til fra andre steder.

    • Korrelering av meldinger i prosessinstanser er den grunnleggende mekanismen som skal til for å realisere koreografi og prosessflyt i samhandlingsprosesser. Det behøves spesifikasjoner og avtaler om meldingsformater for at dette skal fungere på tvers av samhandlingspartnere.

    • Det er behov for å arbeide videre med konsepter og praktiske anvendelser rundt eNotifikasjon og publisering av hendelsesstrømmer.

basismønstre status mai2020
Figur 1. Illustrasjon av forslag til utvidelser i basismønstre

6.2. Sammensatte mønstre for datutveksling

Følgende "sammensatte mønstre" foreslås her (noen av disse kan også ses på som anvendelser av basismønstrene, men de presenteres her som egne mønstre fordi de introduserer nye problemstillinger):

  • Forespørsel-svar mot flere datakilder via mellomledd (dataformidler). Selv om "mellomledd" rent teknisk kan oppfattes som datatilbydere og konsumenter i flere ledd, finnes visse problemstillinger som det er vanskelig å diskutere uten at en faktisk beskriver rollen tli mellomleddet. Dette gjelder særlig avtalemessige forhold (hvem inngår avaler med hvem, og hvem er ansvarlig for dataminimering og datakvalitet).

  • Forsendelse fra en avsender til flere kjente mottakere (multicast). Dette er et viktig mønster, men bør være enkelt å beskrive som en anvendelse av basismønsteret for forsendelse til en kjent mottaker. I sin enkleste form dreier det seg om gjentatt bruk av det samme basismønsteret.

  • Parallelle asynkrone forespørsler mot flere datakilder. Eksempel på brukstilfelle: Parallell innhenting av studiebevis fra flere læresteder (dette er et faktisk behov i en av prosedyrene i Single Digital Gateway Regulation). I dette tilfellet introduseres særegne problemstillinger rundt feilhåndtering.

  • Mønstre med menneskelig interaksjon er så langt ikke dekket spesielt av de nasjonale referansearkitekturene og har heller ikke vært etterspurt. Hvilke problemstillinger og behov finnes?

  • Mønstre for innhenting og preparering av data for analyse. Her finnes flere mulige arkitekturer og mønstre som en så langt ikke har dekket inn i arbeidet med nasjonale referansearkitekturer.

6.3. Veiledning til valg mellom aktuelle utvekslingsmønstre

Det er meldt inn behov for veiledning til valg mellom ulike arkitekturmønstre og løsninger for ulike formål. Blant innmeldte behov nevnes her:

  1. Valg mellom basismønstre for datautveksling (eMelding, eOppslag, eNotifikasjon) i ulike samhandlingskontekster. Merk: Her finnes et forslag til en metode som tar utgangspunkt i kartlegging av forretningsprosesser og biletarele avtaler.

  2. Valg mellom løsningsmønstre og alternative fellesløsninger, eventuelt andre løsninger og teknologier, for ulike datautvekslingsformål. Anbefales f.eks. noen spesielle løsninger for overføring av store datamengder uten strenge krav til hastighet vs. mindre datamengder med krav til respons i nær sanntid?

Det synes klart at det finnes behov for slik veiledning, men vi tar gjerne input på prioritering og ambisjonsnivå.

8. Andre refereransearkitekturer og målbilder

8.1. Referansearkitektur for samhandlingsprosesser

Det finnes så langt ingen sammenhengende referansearkitektur for sammenhengende tjenester eller for de samhandlingsprosesser som realiserer de sammenhengende tjenestene.

I Digdirs arbeid med sammenhengende tjenester har det blant annet blitt pekt på behov for veiledning til eksekvering av samhandlingsprosesser etter avtalt koreografi. En har også pekt på behov for å automatisere og bygge inn funksjonalitet i sanntid, integrert med den forretningsmessige prosesseksekveringen, herunder:

  • Innebygd arkiv

  • Automatisert dataproveniens

  • Automatisert dokumentasjon av etterlevelse

  • Deteksjon av tillitsbrudd

  • Innebygd personvern

Kan og bør vi komme opp med en referansearkitektur som hjelper i arbeidet med dette?

Som et foreløpig eksempel - for hva det er verdt - vises her en skisse til verdistrømbeskrivelse som eventuelt kan bearbeides videre og utgjøre en del av en større referansearkitektur som besvarer aktuelle spørsmål:

Utfør steg i samhandlingsprosess
Figur 2. Skisse til referansemodell for steg i samhandlingsprosesser

Noe av det som er interessant med denne modellen, er at den bygger videre på både de verdistrømbeskrivelsene som fra før er gjort for deling og innhenting av data, samt de konkrete referansearkitekturene for datautveksling.

Et overordnet bilde som setter dette i sammenheng, kan være:

Skisse til overordnet bilde for å binde sammen aktuelle referansearkitekturer

Utfør steg i samhandlingsprosess, overordnet

Er videre arbeid med utgangspunkt i "noe slikt" som dette en god ide?

8.2. Referansearkitektur for informasjonssikkerhet, tillit og personvern

Innsiktsarbeid pågår for scoping av dette arbeidet i prosjektet Deling av data, delprosjekt IAM, i regi av Digdir. Flere eksterne er allerede involvert, men medlemmene i Arkitektur- og standardiseringsrådet inviteres til å gi innspill, f.eks. parallelt arbeid, prioriterte behov og aktuelle caser.

8.3. Referansearkitektur for datadeling

Det finnes så langt ingen enhetlig referansearkitektur for datadeling.

Det arbeides blant annet med en verktøykasse for deling av data som har tatt utgangspunkt i en felles referansemodell for datadeling. Det arbeides videre med dette i prosjektet Deling av data.

Den overordnede referansemodellen gjengis her:

Del og innhent data, verdistrøm
Figur 3. Referansemodell for steg i datadeling på tvers av tilbyder og konsument (verdistrøm)

Denne modellen har vist seg nyttig i diskusjoner på tvers av ulike roller og på tvers av alle "EIF-lag" (juridisk, organisatorisk, semantisk, teknisk). Den samme modellen har også vært utgangspunkt for beskrivelse av noen av mønstrene i referansearkitektur for datautveksling (uten at dette er helt konsistent).

Bør en jobbe videre med en enhetlig og helhetlig referansearkitektur for datadeling på tvers av alle "EIF-lag" (herunder f.eks. arbeid med juridiske forhold som nå i sror grad ligger under det nyetablerte Ressurssenteret for deling av data)?

8.4. Referansearkitektur for IoT

Tingenes internett (IoT) er aktuelt for svært mange virksomheter og sektorer.

Det finnes en rekke referansemodeller og standarder for dette internasjonalt, både sektorspesifikke og generiske.

Finnes det noe internasjonalt eller nasjonalt som egner seg som utgangspunkt for en nasjonal referansearkitektur?

Som eksempel vises til https://www.iiconsortium.org/ og https://www.iiconsortium.org/IIC_PUB_G1_V1.80_2017-01-31.pdf (tidligere vurdert i kommunal sektor).

Hvilke ambisjoner skal vi ha og hvem kan drive fram et slikt arbeid?

8.5. Referansearkitektur for API management

Arbeid med API Management foregår i flere sammenhenger, både i EU og Norge. Det pekes her spesielt på en aktivitet i regi av UNIT hvor ambisjonen er å komme opp med noe som kan fungere som en nasjonal referansearkitektur, samtidig som det dekker sektorens behov. Det er tatt initiativ til samarbeid med eHelse og Digdir.

Digdir vil forøvrig kontinuerlig dele kunnskapsgrunnlag fra EU om dette. API management inngår som en del av omfanget i en pågående aktivitet for å utvide dagens CEF eDelivery med referansearkitekturer og fellesløsninger for REST API-er og Blockchain.

8.6. Referansearkitektur for fagsystemer

Bergen kommune og KS har utarbeidet Mønstermodell for fagsystemer, en modell som det kan være interessant å heve til nasjonalt nivå. Følgede figur viser denne:

Mønstermodell fagsystem
Figur 4. Mønstermodell for fagsystemer

Modellen tjener flere formål, blant annet ved anskaffelser. KS opererer også med em metamodell for Archimate-modellering av arkitekturlandskapet i en kommune som spiller sammen med denne mønstermodellen og gir grunnlag for innsikt og styring av utviklingen.

Er dette interessant på nasjonalt nivå?

8.7. Referansearkitektur for integrasjon med EU-s Single Digital Gateway

Norge vil trolig forpliktes av EU-s Single Digital Gateway Regulation (SDGR), som allerede forplikter medlemslandene til å støtte 7 grenseoverskridende livshendelser med 21 definerte prosedyrer innen utgangen av 2023. Et antall norske virksomheter og løsninger vil måtte integreres med den europeiske infrastrukturen for dette.

Digdir følger med i arbeidet og er i tidlig fase av arbeid med en nasjonal referansearkitektur.

Innspill til pilotprosjekter og involvering av flere i arkitekturarbeidet "nå" kan være en god ide?

Her følger en "teaser" om konsept og arkitektur.

TOOP konsept
Figur 5. Konsept for utveksling av data (evidence exchange) i SDG-sammenheng
SDG OOP HLA
Figur 6. Gjeldende arkitektur for utveksling av data (evidence exchange) i SDG-sammenheng

8.8. Målbilde for nasjonal samhandlingsinfrastruktur

Vi har kommet langt med utvikling av fellesløsninger og et økosystem for dette i Norge, men det finnes per i dag ikke en felles arkitektur eller et samlet målbilde som binder sammen "øyene" av kommunikasjonsinfrastrukturer og annet på tvers av sektorene i Norge. Det gir ekstrakostnader for systemleverandører og det blir av mange sett som et hinder for digitalisering og innovasjon.

Bør det utvikles en form for referansearkitektur som kan fungere som felles målbilde? Kan dette gjøres slik at vi ikke behøver å kaste alt vi har?

I EU-sammenheng vurderes nå blant annet en målarkitektur som kommer fra et tysk-fransk samarbeidsprosjekt ved navn GAIA-X. Dette bygger igjen på en referansearkitektur fra Internasjonal Data Spaces Association.

Det er her snakk om en føderert arkitektur med nodes og connectors, datakataloger, selvbeskrivende tjenester og stor vekt på informasjonssikkerhet, tillit og personvern. En ønsker med dette å gjøre seg uavhengig av f.eks. amerikanske eller kinesiske løsninger og etablere et økosystem for innovasjon med utgangspunkt i europeiske verdier.

Det finnes foreløpig ikke noen offisiell strategi rundt dette fra EU-kommisjonen, men det er interessant å føle med på utviklingen.

Er dette, eller eventuelt tilsvarende som andre kjenner til, noe vi bør vurdere å ta utgangspunkt i for helhetlig norsk målbilde? Bør vi komme i gang med det nå, eller skal vi sitte på sidelinjen og se an hva som skjer en stund til?

Merk: Når statsbudsjettet snart legges fram, vil vi trolig vite mer om vår rolle overfor DEP-programmet i EU - en viktig faktor i utviklingen videre.

Et par figurer fra GAIA-X og IDS-arkitekturen følger her som en "teaser".

GAIA X målarkitektur
Figur 7. Et bilde på GAIA-X målarkitektur
IDSA referansearkitektur
Figur 8. En figur fra IDS referansearkitektur
Data usage control
Figur 9. Konsept for "Data usage control" ref. IDS referansearkitektur

9. Eventuell utdyping av svar under foregående spørsmål

Noe å legge til?

Merk: Forslag til andre referansearkitekturer kan gis under eget pkt. nedenfor.

10. Kartleggingsarbeid

10.1. Kartlegging av god praksis fra sektorer og virksomheter

De fleste av oss har i dag stort sett tilfeldig kjennskap til hva som finnes av god praksis ute i ulike sektorer og virksomheter. Det skjer mye, og det er ikke lett å følge med og se forskjell på kråkesølv og gull.

Noen spørsmål og ideer (hovedspørsmål er uthevet):

  1. Bør vi prioritere arbeid med å finne fram til og løfte opp god praksis innen prioriterte områder?

  2. Bør vi tilrettelegge for dette i form av utstillingsvinduer hvor de som har noe interessant å dele, lettere får gjort dette? F.eks. i kombinasjon med anmeldelser og "rating" fra andre?

  3. Bør vi som et ledd i dette tilby et minimum av dokumentasjonsmaler og modelleringskonvensjoner for å tilrettelegge for enhetlig dokumentasjon, slik at det blir enklere å sammenlikne og gjenbruke "byggeklossene"?

10.2. Mapping av sektorvise referansearkitekturer til nasjonale referansearkitekturer

De nasjonale referansearkitekturene for datautveksling er først beskrevet på et konseptuelt nivå, før det vises mapping til nasjonale fellesløsninger.

Det har hele tiden vært tenkt at tilsvarende mapping til sektorvise eller virksomhetsspesifikke arkitekturer og løsninger skal kunne gjøres, eventuelt med justering av de nasjonale modellene for å dem til å passe bredere. Noen mulige fordeler med dette er:

  • muligheter for sammenlikning og harmonisering av løsningslandskapet

  • gjenbruk av arkitektur mellom arkitekter

  • interoperabilitet og samhandlingsevne

Vi har så langt ikke jobbet hardt for å få dette til å skje, men er i dialog med særlig UNIT, eHelse og KS.

Er dette en gode ide?

10.3. Kartlegging av internasjonalt arbeid

Gjør vi hjemmelagd av uvitenhet om hva som finnes internasjonalt?

Tilbakemeldinger tyder på at det er et udekket behov når det gjelder å følge med i hva som skjer og finnes internasjonalt.

Digdir har et særlig ansvar i å følge med i det som skjer i EU. Vi har også en viss mulighet til påvirkning i EU-s arkitekturarbeid.

  1. Er det viktig at Digdir prioriterer arbeidet med å tilrettelegge og formidle informasjon fra EU?

  2. Bør vi også involvere bredere og trekke inn (gratis) eksterne ressurser i dette arbeidet (der det lar seg gjøre)?

12. Felles nasjonale kataloger og datamodeller

12.1. Nasjonal tjenestekatalog for sluttbrukertjenester

Det har blitt argumentert for å etablere en felles definisjon og oversikt over viktige sluttbrukertjenester sett fra borgere og virksomheter, som bør kunne se Én digital offentlig sektor uten å måtte forholde seg til hvilke sektorer som gjør hva - for den saks skyld om tjenestene kommer fra privat sektor.

En har i EU definert felles datamodell for beskrivelse av sluttbrukertjenester (CPSV-AP, som tilsvarer DCAT-AP for beskrivelse av datasett), og det er planer om å etablere en tjenestekatalog i sammenheng med Felles datakatalog der tjenester kan registreres fortløpende.

  1. Bør det etableres en felles taksonomi for sluttbrukertjenester?

  2. Forslag: Ta utgangspunkt i regjeringens liste over samfunnskritiske funksjoner. Se også følgende figur for en oversikt.

Kritiske og viktige samfunnfunksjoner
Figur 10. Oversikt over samfunnskritiske funksjoner

Til orientering: Det foreligger allerede en felles tjenestekatalog/kapabilitetskart for kommunal sektor som viser hva en kommune må kunne gjøre og levere. Dette ser slik ut:

Kapabilitetskart nivå 1 og 2
Figur 11. Kapabilitetskart nivå 1 og 2 fra KS

12.2. Nasjonale kjernemodeller

Felles begreper og kjernemodeller vil understøtte semantisk samhandlingsevne.

Bør det arbeides mer proaktivt med identifisering og definisjon av felles begreper, taksonomier og kjernemodeller?

Status:

  • Norge har så langt definert felles begreper for Adresse og Person basert på Skattedirektoratets definisjoner.

  • EU har definert et sett av Core Vocabularies som bør danne grunnlag for tilsvarende norske begreper og datamodeller

  • Felles Datakatalog (nasjonal fellesløsning) gir mulighet for å utpeke autoritative datasett og en er i gang med å harmonisere begreper og datasett med utgangspunkt i hva som er lagt inn i katalogene.

14. Samarbeidsplattform

14.1. Konvensjon for bruk av engelsk språk og oversettelser

I arbeidet med nasjonal arkitektur er norsk så langt stort sett eneste språk. Dette er et hinder for å diskutere norske arkitekturer og løsninger med ressurser fra andre land. Det er også et hinder for å adoptere og integrere engelske tekster og figurer i vår dokumentasjon.

Vi ser at det finnes ulik praksis på dette i ulike miljøer i Norge. Det er også en utbredt oppfatning at norske arkitekter forstår teknisk engelsk (selv om det også finnes mange som ser annerledes på det).

  1. Bør vi endre på dagens praksis, slik at engelsk blir gangbart?

  2. Bør vi gjøre det ved å la engelsk være normen for arkitekturdokumentasjon, eller skal vi rett og slett la det være helt fritt å velge det som passer best ut fra sammenhengen - dvs. et tredje skriftspråk, på linje med bokmål og nynorsk?

Til orientering: Det er lagt opp til å kunne vedlikeholde alle tekster på norsk (bokmål eller nynorsk) og engelsk i parallell i Nasjonalt arkitekturverksted (her og i Archimate-modeller), samt å kunne svitsje fra det ene til det andre i visninger.

14.2. Felles modelleringskonvensjoner

Det tenkes her primært på modelleringskonvensjoner for Archimate, fordi det har etablert seg som en utbredt standard for arkitekturmodellering i Norge og EU, og fordi det er her frihetsgraden er størst.

Et minimum av slike modelleringskonvensjoner er en forutsetning for utveksling og gjenbruk av modeller.

Oppfattes dette som riktig og viktig?

Til orientering:

Digdir har så langt tatt fram foreløpige modelleringskonvensjoner for Archimate i tilknytning til arbeidet med referansearkitekturer.

Videreutvikling av disse modelleringskonvensjonene, gjerne også med tips om implementering i ulike verktøy og med støtte for eksport/import mellom ulike verktøy, har vært etterspurt av noen. En større kartlegging av behovene har ikke så langt vært gjort. Det antas inntil videre en gradvis videreutvikling ut fra aktuelle behov.

En arbeidsgruppe med deltakere fra ulike etater har gjennom 2019 og 2020 tat fram en en felles spesifikasjon for informasjonsmodeller for offentlig forvaltning. Det er også utviklet en løsning i Felles datakatalog for å høste og framvise modeller basert på denne spesifikasjonen, og det har nylig vært en høring (høst 2020). Videre arbeid med veileder m.m. er igangsatt.

14.3. Dokumentmaler

Bruk av felles dokumentmaler har fordeler og ulemper. Noen momenter:

  • + Dokumentmaler kan fungere som sjekklister

  • + Felles dokumentmaler kan bidra til enhetlig dokumentasjon som blir lettere å forstå og samarbeide om for flere.

  • + Dokumentmaler kan legge opp til strukturert informasjon som kan prosesseres, konverteres og transporteres mellom ulike verktøy og formater.

  • - Felles dokumentmaler kan bli tunge å vedlikeholde

  • - Felles dokumentmaler kan gi byråkrati og hemme innovasjon

14.4. Felles samarbeidsverktøy

Det tenkes her primært på verktøy for samarbeid om innholdsproduksjon og publisering, både for tekst og arkitekturmodeller.

Verktøyvalg må selvsagt følge av funksjonelle behov. Noen "ønsker" er:

  • Dokumentasjon som kan utvikles løpende, med ivaretakelse av sammenheng på tvers av organisasjonsgrenser

  • Alt refererbart på web, ikke innelåst i tradisjonelle dokumenter

  • Åpen deling av innhold for lesing

  • Enkelt å gi skriverettigheter

  • Gratis og åpen kildekode

  • Unngå lenkeråte

  • Versjonsstyring av innhold

  • Fleksibel komponering av samme innholdselementer i ulike samlinger

  • Gjenbruk av innhold fra andre

  • Arbeidsflyt for godkjenning og livssyklus

  • Samtidig redigering av dokumenter

  • Problemrapportering og -oppfølging

  • …​

Gir dette mening?

Det finnes neppe noe enkeltprodukt som alene tilfredsstiller alt dette. Produkter som f.eks. MS Sharepoint/Teams og Office-produktene fungerer bra internt i virksomheter, men legger ikke opp til åpen deling og koster penger. F.eks. Google Docs fungerer veldig bra for samtidig redigering og åpen deling, men handler fremdeles om enkeltdokumenter.

I arbeidet med tekstbasert dokumentasjon og arkitekturmodeller i tilknytning til de nasjonale referansearkitekturene har en så langt valgt å benytte gratisverktøy som lagrer og versjonsstyrer innhold på Github eller tilsvarende; se f.eks. Praktiske tips om bruk av Asciidoc og Antora, i kombinasjon med andre samarbeidsverktøy.

Her er forøvrig en sammenstilling av "ønsker" for spesielt interesserte:

Krav til plattform for innholdsproduksjon og publisering
Figur 12. Ønsket funksjonalitet i plattform for innholdsproduksjon og publisering

14.5. Organisering av parallelt arbeid i arbeidsgrupper

Digdir har begrenset med arkitektressurser og er avhengig av å trekke på ressurser fra forvaltningen forøvrig for å levere opp mot behov og forventninger.

En måte å gjøre dette på er gjennom arbeidsgrupper, der Digdir fokuserer på struktur, samordning og helhet, mens andre tar hovedansvar og er utførende i gjennomføringen.

Eksempel: UNIT kan ta en rolle som "hovedansvarlig" og prosessdriver i arbeidet med en nasjonal referansearkitektur for API Management, i sammenheng med at dette skal tas fram for sektoren.

Er dette en god ide?

For å få dette til å skalere og fungere i praksis, kreves et minimum av struktur, felles konvensjoner og felles verktøy (uten å komme i veien for innovasjon).

16. Bidrag til kartlegging av eksisterende god praksis

Hvilke løsninger eller referansearkitekturer finnes dokumentert i din sektor eller virksomhet som kan være av interesse for andre?

Her kan det angis alt fra eksempler til inspirasjon til formelt dokumenterte referansearkitekturer, også sektor- eller virksomhetsspesifikke løsninger som utgangspunkt for generalisering på nasjonalt nivå.

17. Andre forslag til nasjonale referansearkitekturer eller målbilder

Her kan det gjerne tenkes fritt, uavhengig av hva som finnes i dag, og utover egen sektor eller virksomhet.

18. Innspill til organisering av arbeidet

Hvilke produkter og aktiviteter ønsker din virksomhet å bidra inn i, ut fra punktene over (inkl. egne forslag)?

Hvilke referansearkitekturer eller aktiviteter ønsker din virksomhet å bidra inn i, ut fra punktene over (inkl. egne forslag)? Hvilken rolle kan dere ta (ledende, deltaker, referansegruppe, annen rolle)? Gjerne antyd mulig ressursbidrag og kalendertid (ikke bindende). Forslag til arbeidsgrupper og bemanning av arbeidsgrupper med andre virksomheter og eventuelt persongalleri?

19. Annet

Andre forslag, kommentarer eller spørsmål?