Integrationsarkitektur og API-strategi: Sådan planlægger du et sammenhængende systemlandskab

Hvorfor et sammenhængende systemlandskab kræver integrationsarkitektur og API-strategi

Den offentlige sektor digitaliseres hurtigt. Data, it-systemer, robotter og apps hjælper borgere, virksomheder og ansatte. Mange tusinde offentlige it-systemer taler ofte ikke et fælles sprog; de samme data indsamles flere gange, og datadeling aftales fra gang til gang.

Kompleksiteten vokser. Når data udveksles mellem europæiske lande, kommer flere sprog i spil – og dermed flere formater, begreber og forretningsregler.

Den fællesoffentlige digitale arkitektur (FDA) skal gennem standarder sikre, at it-systemer fremover kan udveksle data sikkert og effektivt og indgå i sammenhængende processer. FDA består af styrings- og arkitekturprincipper, retningslinjer og standarder og sætter de overordnede rammer for den digitalt sammenhængende offentlige sektor i Danmark.

FDA skal understøtte digital sammenhæng på tværs af stat, kommuner og regioner og fagområder som sundhed, socialområdet, uddannelse og arbejdsmarked. Den skal også understøtte sammenhæng mellem offentlig og privat sektor og på tværs af landegrænser, ikke mindst i forhold til EU og det digitale indre marked.

Integrationsarkitektur og API-strategi er derfor ikke et teknisk detailspørgsmål, men et strategisk valg. Arkitekturen skal understøtte digital sammenhæng på tværs af myndigheder, fagområder, sektorer og landegrænser.

En integrationsarkitektur beskriver sammenhængen mellem snitflader, services, data og ansvar. API-strategien beskriver, hvordan snitflader designes, udstilles, versioneres og genbruges. Tilsammen muliggør de løsninger til genbrug og forandring frem for at genopfinde det samme fra projekt til projekt.

Guiden arbejder trin for trin. Rækkefølgen er: 1) nuværende systemlandskab og integrationer, 2) vision og krav til fremtiden, 3) snitfladebehov, 4) aftalt integrationsmønster, 5) logiske datamodeller, 6) format og protokol, 7) udstilling i fælles katalog, 8) fremtidige integrationsbehov.

Flere af trinnene svarer til elementer i AR 7.1 i Rammearkitekturen, og reglen kan bruges som tjekliste for de dele af planen, den dækker. Alle offentlige it-projekter kan anvende de fællesoffentlige arkitekturprodukter; projekter uden for det offentlige kan også have nytte af dem.

Guiden her er en praktisk planlægningsguide til integrationsarkitektur og API-strategi. Den samler de konkrete valg: integrationsmønstre, API-standarder som RESTful API, SOAP API og GraphQL API, fælles katalog og governance.

Integrationsmønstrene navngives i planen: realtidsintegration, asynkron integration og system-til-system API'er. Til partnere uden direkte API-integration kombineres sikre filoverførsler med API-baserede workflows.

API-standarderne navngives: RESTful API over HTTP med JSON, SOAP API over XML og GraphQL API med ét endpoint. Governance navngives: AR 7.1 i Rammearkitekturen, de fællesoffentlige arkitekturprincipper og -regler i FDA og Hvidbogen om Fællesoffentlig Digital Arkitektur 2017 fra Digitaliseringsstyrelsen.

Artefakterne i planen er bl.a. systemlandskab, krav til informationsindhold og servicemål, logiske datamodeller, snitfladebeskrivelser og en fælles katalogpost.

Før valg af teknologi bør I kende de teknologiske begrænsninger og de platforme, der skal understøttes. Observability og sikkerhed bør integreres i løsningen fra start, ikke tilføjes bagefter.

API-strategien bør navngive stil og format. RESTful API'er bruger HTTP og typisk JSON; SOAP API'er bygger på XML; GraphQL API'er lader klienten hente præcis de data, den har brug for via ét endpoint. Valget er strategisk, ikke tilfældigt.

Private virksomheder forbinder typisk ERP, CRM, webshop, lager og markedspladser via API-integration; system-til-system API'er forbinder ERP, e-handelsplatforme, markedspladser og logistikløsninger. Uden integration opstår manuelle dataoverførsler, datasilos og forsinkelser.

En integrationsplatform kan centralisere API-integrationer og tilbyde API management, data mapping, sikkerhed og monitorering. Den kan forbinde CRM og ERP, så kundedata automatisk synkroniseres.

Private virksomheder, der integrerer med offentlige systemer, bør kende de samme principper og standarder. Rammen er ikke forbeholdt offentlige projekter.

FDA præsenterer også fælles rammer for projekternes arkitekturarbejde, herunder governance med fora, mandater og processer for det fælles arkitektursamarbejde.

AR 7.1 kræver, at oplysninger om snitflader udstilles efter fælles standarder, så de er tilgængelige for relevante parter, fx i et fælles katalog. Reglen anvender standardiserede integrationsmønstre og dataudveksling baseret på aftalte protokoller.

Afklar behov og krav til snitflader, før du vælger teknologi

Trin 1 og 2: Start med at dokumentere nuværende systemlandskab og eksisterende integrationer. Definer derefter vision og krav til fremtiden, så planen bygger på den faktiske platform og de reelle begrænsninger.

Trin 1 leverer et dokumenteret systemlandskab med de eksisterende integrationer. Trin 2 leverer vision og krav til fremtiden. Trin 3 leverer en liste over konkrete snitfladebehov, som planen kan bygges videre på.

AR 7.1 kan læses som den samme planlægningsrækkefølge: først behov, så mønster, datamodel, format, udstilling og til sidst fremtidige integrationsbehov. Brug reglen som tjekliste gennem hele planen.

Trin 3: Beskriv eksplicit de konkrete snitfladebehov, som offentlige myndigheder eller virksomheder efterspørger. Integration bør begynde med behovet, ikke teknologien.

For hvert snitfladebehov bør I kunne svare på, hvem der udveksler, hvem der ejer data, hvilket informationsindhold, hvilke servicemål, hvilke sikkerheds- og persondatakrav og hvilken livscyklus snitfladen har.

Trin 4: Identificér og aftal det mest hensigtsmæssige integrationsmønster på grundlag af de afklarede indholdskrav og servicemål. Først derefter bygges integrationen.

Kravene til, hvad der udveksles, i hvilken kvalitet, med hvilken oppetid og svartid, styrer valget af integration og API – ikke omvendt.

Valget af integrationsmønster er ikke kun teknisk. Vurder hvert mønster mod behovet: fejlhåndtering, hvor tæt parterne kobles, og hvordan ændringer i den ene ende påvirker den anden.

AR 7.1 er optaget i Rammearkitekturen. Området er tværgående, og typen er arkitekturmål, -principper og regler.

Trin 5 og 6: Integrationerne designes med fælles aftalte integrationsmønstre og udarbejdes med udgangspunkt i aftalte logiske datamodeller. Snitflader og services overholder aftalte tekniske formater og protokoller.

Trin 7 og 8: Oplysninger om snitflader udstilles efter fælles standarder, fx i et fælles katalog. Projektet sikrer samtidig, at fremtidige integrationsbehov i videst muligt omfang kan imødekommes.

Når behov og krav er ekspliciterede, vælger man den løsning, der bedst opfylder kravene. Man skal også kunne forklare og begrunde valget over for leverandører, kolleger og tilsyn.

API-integration er måden, hvorpå forskellige IT-systemer automatisk udveksler data. Et API er et sæt tekniske regler, der gør kommunikationen ensartet og kontrolleret. Data kan dermed oprettes ét sted og genbruges på tværs af systemer.

API-integration har både sikkerhedsmæssige og driftsmæssige områder. De bør afklares sammen med informationsindhold, servicemål og snitfladens livscyklus.

Når behovet er kendt, skal API-stilen navngives: RESTful API, SOAP API eller GraphQL API. Valget følger krav til informationsindhold, servicemål og eksisterende systemlandskab.

AR 7.1 kræver, at integrationer udarbejdes med udgangspunkt i aftalte logiske datamodeller. To punkter – logiske datamodeller og imødekommelse af fremtidige integrationsbehov – er kommunale tilføjelser til de fællesoffentlige arkitekturprincipper og -regler fra Hvidbogen om Fællesoffentlig Digital Arkitektur 2017, Digitaliseringsstyrelsen.

En integrationsplatform er en samlet løsning, der forenkler og administrerer integrationen af forskellige applikationer og systemer. Den kan centralisere API-integrationer i en samlet platform, så du administrerer én platform frem for flere enkeltintegrationer.

Vælg fælles integrationsmønstre og tekniske standarder

Gentagen udvikling af allerede løste problemer fører til højere udviklings- og vedligeholdelsesomkostninger, længere udviklingstid og større fejlrisiko. Integration af it-løsninger sker derfor ved brug af standardiserede integrationsmønstre, og data udveksles i henhold til aftalte protokoller.

AR 7.1 anvender standardiserede integrationsmønstre og dataudveksling baseret på aftalte protokoller. Det er regeltekstens krav, ikke en anbefaling.

De mønstre, planen navngiver, er realtidsintegration, asynkron integration og system-til-system API'er. Til partnere uden direkte API-integration kombineres sikre filoverførsler med API-baserede workflows.

System-til-system API'er forbinder ERP, e-handelsplatforme, markedspladser og logistikløsninger. API-integration sker typisk i realtid, er automatiseret og struktureret.

For hvert integrationsmønster følger en række egenskaber, som skal vurderes mod behovet: fejlhåndtering, koblingsgrad og hvordan ændringer i den ene ende påvirker den anden.

Fælles integrationsmønstre er ikke en teknisk detalje, men et middel mod gentagen udvikling. Genbrugte mønstre og protokoller gør integrationer nemmere at genkende, teste, drifte og videreudvikle, uanset parterne.

Projekter bør undersøge, om der findes et aftalt mønster og en aftalt protokol, der dækker behovet – frem for at bygge fra bunden. Det mest hensigtsmæssige mønster identificeres og aftales på grundlag af afklarede indholdskrav og servicemål.

Ifølge AR 7.1 skal projekter fremme åbne snitflader for data og services. De skal også fremme integration af selvbetjeningsløsninger, fagsystemer og infrastrukturservices for digital sammenhæng og tværgående processer. Formålet er at understøtte den sammenhængende service og den tværgående proces digitalt.

Integrationer skal designes på aftalte logiske datamodeller. Så beskriver snitfladerne de samme begreber på samme måde på tværs af systemer og myndigheder.

I API-baserede integrationer står valget ofte mellem RESTful API, SOAP API og GraphQL API. RESTful API'er er mest udbredte og bruger HTTP og typisk JSON. SOAP bygger på XML og bruges ofte i ældre eller komplekse enterprise-systemer.

GraphQL giver klienten præcis de data, der efterspørges, via ét endpoint. Dermed dækker de tre stile forskellige integrationsbehov i samme plan.

Til partnere uden direkte API-integration kan en løsning som TrueCommerce Exchange API kombinere sikre filoverførsler med API-baserede workflows. Den forbinder systemer som ERP, WMS og markedspladser og gør det muligt at integrere med partnere, der ikke understøtter direkte API-integration.

AR 7.1 kræver, at integrationer designes ved brug af fælles aftalte integrationsmønstre og udarbejdes med udgangspunkt i aftalte logiske datamodeller. Snitflader og services skal overholde aftalte tekniske formater og protokoller, der understøtter sikker og effektiv transport af data.

Dataudveksling kan ske både i realtid og via asynkrone processer. Det gør det muligt at vælge mønster efter behov og servicemål.

Sammenligning af integrationsmønstre

Design API'er og integrationer på aftalte logiske datamodeller

Snitflader og services skal overholde aftalte tekniske formater og protokoller, der understøtter sikker og effektiv transport af data. API-design handler derfor ikke kun om, hvilke data der kan hentes, men også om hvordan de transporteres, beskyttes og forstås af modtageren.

API-strategien bør navngive, hvilke standarder og formater der er tilladte: RESTful API, SOAP API og GraphQL API samt JSON og XML. Den bør også beskrive versionering, når behov og datamodeller ændrer sig.

Konkret betyder det, at API-stilen navngives: RESTful API over HTTP med JSON, SOAP API over XML eller GraphQL API med ét endpoint, hvor klienten henter præcis de data, den har brug for.

Trin 5: Ifølge AR 7.1 skal integrationer udarbejdes efter aftalte logiske datamodeller. Den logiske model beskriver faglige begreber og deres indbyrdes sammenhæng uafhængigt af den tekniske udmøntning.

Det gør data genbrugelige på tværs af løsninger og leverandører. I praksis betyder det, at man tager stilling til identifikation og autorisation, fejl og afvisninger, validering mod den logiske model og versionering, når behov og datamodeller ændrer sig.

API'er skal bygges som aftaler mellem parter – ikke som tilfældige tekniske adgange til et systems interne databaser. Det er forudsætningen for, at integrationen holder, når systemer, leverandører og organisationer skifter.

API-standarder omfatter RESTful API, SOAP API og GraphQL API. JSON er velegnet til web- og mobilapplikationer og understøttes af de fleste moderne programmeringssprog. XML bruges især i SOAP-baserede integrationer med streng datavalidering.

Sikkerhed og drift er egne områder i API-integration og bør have krav, ejere og processer. En integrationsplatform kan levere API management, data mapping, sikkerhed og monitorering.

En integrationsplatform gør det muligt at administrere én platform frem for flere enkeltintegrationer. Den kan forbinde CRM og ERP, så kundedata automatisk synkroniseres.

Data kan oprettes ét sted og derefter genbruges på tværs af organisationens systemer. Det reducerer manuelle dataoverførsler og risikoen for fejl og inkonsistente data.

Sikkerhedsmæssige områder (Security) og driftsmæssige områder (Operations) er centrale områder inden for API-integration. De bør afklares sammen med informationsindhold, servicemål og snitfladens livscyklus.

Versionering er en del af strategien, ikke et tillæg: når behov og datamodeller ændrer sig, skal snitfladen kunne versioneres, så eksisterende parter ikke brækker.

API-stilarternes anvendelse i danske offentlige myndigheder

Udstil snitflader i et fælles katalog, så de kan genbruges

En snitflade, som ingen kender, bliver ikke genbrugt. AR 7.1 kræver derfor, at projekter udstiller oplysninger om snitflader efter fælles standarder, så de er tilgængelige for relevante parter, fx i et fælles katalog.

Trin 7 i planen er udstillingen. En katalogpost bør beskrive indhold, datagrundlag, ejer og vedligeholder, gældende version, sikkerheds- og adgangskrav samt hvordan man kommer i gang.

Kataloget bør dække RESTful API'er, SOAP-tjenester og GraphQL-endpoints, så genbrug kan vurderes på tværs af teknologier.

AR 7.1 omtaler udstillingen som “fx i et fælles katalog”. Det er her, oplysninger om snitflader gøres tilgængelige efter fælles standarder.

Kataloget gør allerede løst arbejde synligt. Når snitflader, services og datamodeller er beskrevet efter fælles standarder, kan andre projekter og myndigheder finde dem og genbruge dem frem for at udvikle en ny, tilsvarende løsning.

Kataloget har kun værdi, hvis den enkelte snitflade beskrives med modtagerens behov for øje. Udstilling bør tænkes ind fra projektets start – som en del af leverancen – ikke som efterfølgende dokumentation, når løsningen er i drift.

Reglen peger fremad: Projekter skal sikre, at fremtidige integrationsbehov i videst muligt omfang kan imødekommes. Udstilling og beskrivelse er derfor ikke kun dokumentation af det byggede, men en investering i næste opgave.

Det fælles katalog er det sted, hvor oplysninger om snitflader gøres tilgængelige efter fælles standarder. Udstillingen er et krav i AR 7.1, ikke en eftertanke.

Vælg mellem monolit, modulær monolit og mikrotjenester ud fra organisationen

Mikrotjenester opstod som svar på reelle problemer: store, tunge kodebaser, langsomme releases og teams, der blokerede hinanden. Opdeling i mindre, selvstændige services kunne i teorien give hurtigere udvikling, bedre skalerbarhed og mere autonome teams. I mange organisationer virkede det, i hvert fald i starten.

Debatten om monolit eller mikrotjenester er ikke død. I dag handler arkitekturvalget mindre om trends og mere om organisatorisk modenhed, teamstruktur og evnen til at håndtere kompleksitet.

Mikrotjenester blev ofte adopteret som arkitektonisk standard i stedet for som situationsbestemt valg. Erfaringerne viser, at resultatet kan blive teknisk avancerede, men organisatorisk skrøbelige systemer.

Det velkendte antipattern er den distribuerede monolit: et system, der på papiret består af mange services, men i praksis opfører sig som én stor klump.

Typiske symptomer: ændringer kræver deploy af flere services samtidigt, og services deler databaser eller har tætte synkrone afhængigheder. Andre tegn er centralt koordinerede releases, og at fejl ét sted hurtigt forplanter sig. Man får al kompleksiteten fra et distribueret system – men uden fleksibiliteten.

Modstykket er den modulære monolit: systemer, der stadig deployes samlet, men internt er opdelt i klare domæner og moduler. Den er nem at debugge, teste og få overblik over; for mange teams giver det færre overraskelser i produktion.

Monolitten er ikke den forældede arkitektur, den nogle gange fremstilles som. Modulære monolitter har også praktiske fordele: når alt er på ét sted, er applikationen nemmere at udvikle, teste og implementere. Ydeevnen kan samtidig være effektiv.

Conway's Law er et af de vigtigste og mest oversete principper: Systemers struktur afspejler organisationens kommunikationsmønstre. Arkitektur kan ikke adskilles fra organisationen; systemer ender med at afspejle, hvordan teams kommunikerer, træffer beslutninger og tager ansvar.

Mikrotjenester fungerer derfor bedst i organisationer, hvor teams har reelt ejerskab, kan deploye selv og tager ansvar, når noget går i stykker.

Anbefalingen er ikke at vælge arkitektur efter trend, men efter teamstruktur, ejerskab og deploy-ansvar. Det er ikke et enten-eller mellem monolit og mikrotjenester, men et spørgsmål om, hvilken opdeling organisationen reelt kan drive.

Et praktisk beslutningskriterium er derfor: Vælg modulær monolit, når systemet fortsat deployes samlet med klare domæner. Vælg mikrotjenester, når teams reelt kan eje, deploye og drifte deres services selv.

Uanset valg skal snitfladerne designes efter fælles aftalte integrationsmønstre og udstilles efter fælles standarder, jf. AR 7.1. Det ændrer ikke kravet om, at snitflader og services overholder aftalte tekniske formater og protokoller.

Moderne integrationsarbejde handler ikke kun om at sammenkoble systemer. Det handler om at etablere en digital serviceplatform, der gør data, processer og tjenester tilgængelige på tværs af organisationen.

En integrationsplatform kan forbinde CRM og ERP, så kundedata automatisk synkroniseres. Den kan centralisere API-integrationer og understøtte API management, data mapping, sikkerhed og monitorering.

Til containeriseret infrastruktur kan Docker og Kubernetes bruges. Fibia har med Docker-containere og Kubernetes fået en robust og fleksibel infrastruktur og service-integration til OpenNets platform, så Waoo-produkter kan leveres til nye markeder.

Monolit vs. mikrotjenester – organisatoriske implikationer

Fastlæg governance og arkitekturprincipper for integrationer og API'er

Den fællesoffentlige digitale arkitektur præsenterer fælles rammer for projekternes arkitekturarbejde, herunder governance med fora, mandater og processer for det fælles arkitektursamarbejde. FDA består af styrings- og arkitekturprincipper, retningslinjer og standarder, som projekter kan anvende.

Baggrunden er en politisk aftale. Regeringen, kommunerne og regionerne har aftalt et fællesoffentligt arkitektursamarbejde for at fremme sikker og effektiv datadeling og øge sammenhængen på tværs af den offentlige sektor.

Borgerne og virksomhederne skal opleve, at behandling og service på tværs af flere myndigheder hænger bedre sammen. Myndighederne skal kunne trække på hinandens viden.

De fællesoffentlige arkitekturprincipper og -regler stammer fra Hvidbogen om Fællesoffentlig Digital Arkitektur 2017, som Digitaliseringsstyrelsen stod bag.

Rammearkitekturen hos KL bygger videre på de fællesoffentlige arkitekturprincipper og -regler og tilføjer kommunale regler. Arkitekturreglen AR 7.1 er optaget i Rammearkitekturen og gælder for kommunale projekter.

AR 7.1 har status: Optaget i Rammearkitekturen RA. Område: Tværgående. Type: Arkitekturmål, -principper og regler.

Governance i dansk offentlig sektor har dermed navngivne lag: de fællesoffentlige arkitekturprincipper og -regler i FDA, Hvidbogen om Fællesoffentlig Digital Arkitektur 2017 fra Digitaliseringsstyrelsen og Rammearkitekturen hos KL med AR 7.1 og kommunale tilføjelser.

Governance på integrationsområdet handler om at beslutte og fastholde fælles spilleregler. Det gælder principper for snitflader og dataudveksling, hvilke standarder der følges, hvem der træffer arkitekturvalg, og hvordan man håndterer afvigelser fra standarden.

Principper og regler kan være fællesoffentligt aftalt og suppleret lokalt. Arkitekturreglerne i Rammearkitekturen henviser til de fællesoffentlige arkitekturprincipper og -regler og indeholder kommunale tilføjelser. Det viser, hvordan fælles rammer og lokale behov kan sameksistere.

For den enkelte myndighed eller projekt betyder det, at governance ikke bør være en formalitet, der tilføjes til sidst. Fora, mandater og processer bør kobles til planlægningen fra start.

Governance er en forudsætning for, at integrationer kan genbruges, vedligeholdes og videreudvikles på tværs af fagområder og organisatoriske grænser.

Governance bør navngive, hvilke API-standarder der er tilladte: RESTful API, SOAP API eller GraphQL API, og hvilke formater der følger, fx JSON og XML. Det gør afvigelser og dispensationer konkrete at håndtere.

Fremtidssikr med åbne standarder og mindsk leverandørafhængighed

Åbne standarder fremmer konkurrence på softwaremarkedet. De medvirker til, at offentlige it-systemer kan udveksle informationer på tværs, uanset valg af software. De er det fælles sprog, systemerne bruger til at tale med og forstå hinanden.

Af samme grund undgår offentlige myndigheder så vidt muligt løsninger, der skaber afhængighed af specifikke leverandører og teknologier. Hvor relevant kan de anvende bæredygtige open source-komponenter. Det holder systemlandskabet åbent for fremtidige valg.

Open source-software er udgivet under en licens, der giver enhver ret til frit og til ethvert formål at bruge, undersøge, ændre og dele softwaren og dens kildekode.

Open source handler ikke om it-afdelingens teknologiske præferencer. Det er en strategisk forretningsmodel og nogle udviklingsmetoder, der fremmer offentlige myndigheders medejerskab til deres løsninger og skaber bedre muligheder for at dele, videreudvikle og genbruge digitale løsninger.

Vejledningen om brug af open source i den offentlige sektor henvender sig til it-projektledere, it-jurister og it-arkitekter, indkøbere og contract managers. Den henvender sig også til it-chefer og andre strategiske beslutningstagere i offentlige myndigheder, der skal tage stilling til anskaffelse af software.

Åbne og cirkulære forretningsmodeller og open source-software rummer et stort potentiale. Brugt på de rigtige områder kan de understøtte bæredygtig udvikling, innovation og kvalitet og styrke danske virksomheders omstillingsparathed og konkurrenceevne samt øge vækst og eksport af digitale løsninger.

Det er dog ikke et enten-eller. I valget mellem open source-software og proprietære løsninger handler det om at vælge den løsning, der skaber værdi ud fra de udfordringer og behov, der er relevante for den enkelte myndighed.

Der findes mange udbredte open source-produkter. Linux-distributioner understøtter omkring 70 % af internettets 10 mio. mest besøgte hjemmesider, ofte på Nginx (33 %) eller Apache HTTP Server (24 %). 42 % af hjemmesiderne er udviklet med Wordpress, og Drupal og Umbraco er også open source.

Omkring 65 % browser med Google Chrome, og 84 % kører Android på deres smartphone. Danske offentlige myndigheder bruger eksempelvis LibreOffice til tekstbehandling og QGIS til geodatabehandling, og 82 kommuner bruger OS2kitos – ofte sammen med et af de andre 21 OS2-produkter.

Ved anskaffelse af software kan offentlige myndigheder stille krav til teknisk dokumentation og kildekode. Offentlige myndigheder kan kræve, at dokumentationen og kildekoden overholder krav og standarder tilhørende den valgte open source. Dermed bliver kravene en del af aftalen med leverandøren, ikke en eftertanke.

Krav om åbne snitflader, aftalte standarder og velbeskrevne datamodeller sikrer, at systemerne kan udskiftes eller videreudvikles, uden at hele landskabet bygges om. Det gælder RESTful API'er, SOAP-tjenester og GraphQL-endpoints.

For integrationsarkitekturen betyder det, at åbne standarder og genbrugelige komponenter ikke er et mål i sig selv, men en forudsætning for den fleksibilitet og sammenhæng, den offentlige sektor har brug for på langt sigt.

Anvendelse af open source i den danske offentlige sektor