Bijlage A - Architectural Decision Records (ADR’s)

ADR‑GIS‑001

Ontsluiten van GIS‑data via services

Status
Genomen

Context
Binnen het GIS‑platform bestaan meerdere manieren om geo‑data te benaderen, waaronder directe database‑connecties en service‑gebaseerde ontsluiting. Directe connecties vergroten beheerlast, security‑risico’s en migratie‑impact.

Beslissing
Alle GIS‑data wordt ontsloten via services; directe database‑toegang voor afnemers is niet toegestaan.

Overwogen opties

1. Directe database‑connecties
2. Service‑gebaseerde ontsluiting ✅

Rationale

• ontlasting van databases;
• performance door request‑bundeling;
• betere beschikbaarheid bij verstoringen;
• eenvoudiger LCM‑migraties;
• voorkomen van verouderde connecties bij gebruikers.

Gevolgen

• service‑endpoint is het technische contract;
• monitoring verschuift naar servicelaag;
• databases zijn uitsluitend intern bereikbaar.

Gerelateerde QA’s
Beschikbaarheid, Beheerbaarheid, Security, Interoperabiliteit

ADR‑GIS‑002

PostgreSQL als Enterprise Geodatabase

Context
De RIVA‑lijst schrijft voorkeursbouwstenen voor relationele databases voor.

Beslissing
PostgreSQL wordt gebruikt als EGDB‑platform.

Rationale

• voorkeur binnen RIVA;
• ondersteund door ArcGIS én GeoServer;
• PostGIS als volwassen ruimtelijke extensie, naast ST_GEOMETRY

Gevolgen

• Oracle wordt alleen bij hogere uitzondering ingezet voor EGDB;
• skillset en tooling richten zich op PostgreSQL.

ADR‑GIS‑003

Gebruik native geometrieformaten bij toekomstige ontwikkelingen

Beslissing
Gebruik PostGIS Geometry (PG_GEOMETRY) en SDO_GEOMETRY, geen ST_GEOMETRY. Bij toekomstige ontwikkelingen heeft gebruik van database-native geometrieformaten (zoals PostGIS Geometry) de voorkeur boven ST_GEOMETRY, mits dit verenigbaar is met de operationele beheerprocessen en de ondersteunde Esri-platformarchitectuur.

Rationale

• minder vendor lock‑in;
• betere interoperabiliteit;
• bredere tool‑ondersteuning.

Randvoorwaarden

• edits buiten ESRI tooling zijn gereguleerd;
• governance nodig op mutatieprocessen.

ADR‑GIS‑004

Enterprise geodatabase alleen indien functioneel noodzakelijk

Beslissing
Enterprise geodatabase wordt alleen ingezet bij expliciete behoefte aan enterprise‑functionaliteit (versioning, concurrent editing).

Rationale

• Enterprise geodatabase verhoogt LCM‑ en beheerlast;
• read‑only en lichte edits kunnen zonder enterprise geodatabase.

Gevolgen

• afwegingskader nodig;
• duidelijke communicatie richting afnemers.

ADR‑GIS‑005

Shared geodatabases als standaard

Beslissing
Shared geodatabases zijn de default; dedicated databases alleen bij onderbouwde noodzaak.

Rationale

• lagere kosten;
• sneller onboarding;
• voldoende voor meeste use‑cases.

Gevolgen

• capaciteitsmanagement cruciaal;
• uitzonderingen expliciet gemotiveerd.

ADR‑GIS‑006

Data en content positioneren in Tier‑3

Context
2‑tier uitzonderingen voldoen niet aan zoneringsrichtlijnen.

Beslissing
GIS‑data en applicatiecontent worden zoveel mogelijk in Tier‑3 geplaatst.

Bewuste uitzonderingen

• ArcGIS Data Store (Tier‑2);
• FME Flow config DB.

Gevolgen

• migratie van bestaande 2‑tier toepassingen;
• expliciete documentatie uitzonderingen.

ADR-GIS‑007

Gebruik federated ArcGIS Services waar mogelijk

Context

ArcGIS Enterprise ondersteunt zowel federated als non‑federated configuraties.
In een federated setup verloopt IAM via Portal for ArcGIS, terwijl bij non‑federated toegang direct op ArcGIS Server plaatsvindt.

Nieuwe platformontwikkelingen (o.a. ArcGIS for Kubernetes) ondersteunen geen non‑federated architecturen meer.

Beslissing

Nieuwe GIS‑diensten en applicaties worden uitsluitend federated ontwikkeld.
Bestaande non‑federated services worden gemigreerd.

Overwogen opties

1. Federated ArcGIS Server ✅
2. Federated en non‑federated naast elkaar blijven ondersteunen

Rationale

• Alleen federated ondersteunt eHerkenning en moderne IAM‑protocollen
• Non‑federated is niet toekomstvast
• Eén sub‑architectuur verlaagt beheerlast
• Voorkomt extra migratiestappen later

Gevolgen

• Migratie van bestaande non‑federated services
• IAM via Portal wordt leidend

QA’s

Beveiliging, Aanpasbaarheid, Beheerbaarheid, Continuïteit

ADR-GIS‑008

Volledig geautomatiseerde deployment

Context

Handmatige deployments en losse scripts vergroten:

• configuratiedrift,
• foutkans,
• afhankelijkheid van personen.

Beslissing

Deployments worden volledig geautomatiseerd uitgevoerd via pipelines/task‑runners.

Overwogen opties

1. Handmatige deployment
2. Volledig geautomatiseerde deployment ✅

Rationale

• Herhaalbaarheid en voorspelbaarheid
• Betere security en auditability
• Vereist voor korte LCM‑cycli

Gevolgen

• Scripts opgenomen in CI/CD‑achtige pipelines
• TAB moet tooling beschikbaar hebben

QA’s

Beheerbaarheid, Testbaarheid, Betrouwbaarheid, Security

ADR-GIS‑009

Externe samenwerking via ArcGIS Online (SaaS tenzij)

Context

Externe samenwerking werd gerealiseerd via een tweede on‑prem ArcGIS Enterprise, wat leidt tot dubbele beheerlast.

Deze ontwerpbeslissing wordt uiterlijk herijkt bij wijziging van het RWS‑cloudbeleid of bij realisatie van een volwaardig Portal in de DMZ.

Beslissing

Externe samenwerking wordt gerealiseerd via ArcGIS Online.

Overwogen opties

1. On‑prem extern portaal behouden
2. ArcGIS Online ✅

Rationale

• Lagere beheerlast
• Uniformering samenwerking
• Sluit aan op SaaS‑tenzij‑principe

Gevolgen

• Minder intern beheer
• Afhankelijkheid van SaaS

Statusopmerking

Deze beslissing wordt herijkt i.v.m.:

• soevereiniteit,
• Portal in DMZ,
• licentie‑aspecten.

QA’s

Beheerbaarheid, Kosten‑efficiëntie, Aanpasbaarheid

ADR-GIS‑010

GeoWeb modules intern hosten

Context

GeoWeb Enterprise kan als SaaS of on‑prem worden ingezet.
Integratie met intern ArcGIS Enterprise is complex bij SaaS.

Beslissing

GeoWeb modules worden intern gehost.

Overwogen opties

1. GeoWeb SaaS
2. GeoWeb on‑prem ✅

Rationale

• Minder integratierisico
• ArcGIS Enterprise staat ook on‑prem
• Volledige configuratiecontrole

Gevolgen

• Hogere beheerlast dan SaaS

QA’s

Interoperabiliteit, Betrouwbaarheid, Beheerbaarheid (−)

ADR-GIS‑011

Nieuwe (mature) releases als LCM‑driver

Context

LCM werd gestuurd door EoL/EoS, wat leidt tot:

• late updates,
• security‑risico’s,
• grote migraties.

Beslissing

LCM wordt gestuurd op actuele, stabiele releases.

Overwogen opties

1. EoL/EoS als trigger
2. Mature releases ✅

Rationale

• Sneller nieuwe functionaliteit
• Lagere security‑exposure
• Kleinere, beheersbare updates

Gevolgen

• Hogere update‑frequentie
• Vereist automation (zie OB‑GIS‑008)

QA’s

Security, Aanpasbaarheid, Beschikbaarheid

ADR-GIS‑012

OTA‑functionaliteit via RWS Data Center

Context

Afnemers verlangen OTA‑voorzieningen voor ontwikkeling en testen.

Beslissing

OTA wordt geleverd via het RWS Data Center.

Overwogen opties

1. ODC
2. RWS DC ✅
3. RWS VDC

Rationale

• Beperkte ervaring met ODC
• Cloudbeleid sluit VDC uit
• DC is stabiel en bekend

Gevolgen

• Beperkte flexibiliteit
• Minder elasticiteit dan cloud

QA’s

Beheerbaarheid, Stabiliteit (↑), Flexibiliteit (↓)

ADR-GIS‑013

Gescheiden OTA en PRODUCTIE automation

Context

Security‑richtlijnen verbieden vanuit PROD toegang tot andere omgevingen.

Beslissing

Twee automation‑omgevingen:

• één voor OTA,
• één voor PRODUCTIE.

Overwogen opties

1. Eén centrale automation
2. Gescheiden OTA/P ✅

Rationale

• Security‑conform
• OTAP‑discipline
• Minder risico in PROD

Gevolgen

• Dubbele pipelines
• Complexer scriptbeheer

QA’s

Security, Betrouwbaarheid, Testbaarheid

ADR‑GIS‑014 (volledig uitgewerkt, status in behandeling)

URL‑strategie bij LCM‑migraties

Context
LCM vereist parallelle infrastructuren terwijl URL’s eenduidig zijn.

De voorlopige architecturale voorkeursrichting is het hanteren van stabiele logische URL’s met routering via een gatewaylaag, zodat LCM‑migraties zonder wijziging van publieke endpoints kunnen plaatsvinden.

Beslissingsrichting

• stabiele logische URL’s;
• scheiding publiek / intern;
• routering via gateway/reverse proxy.

Open besluiten

• Portal in DMZ vs ArcGIS Online;
• versiebeheer in URL’s;
• routinglaag positionering.

Impact

• cruciaal voor continuïteit dienstverlening;
• randvoorwaardelijk voor LCM‑snelheid.

ADR‑GIS‑015

Context

Bij platformuitval is herstel primair georganiseerd via operationele procedures binnen afgesproken hersteltijd (RTO), niet via technische failover.

FME Flow fault‑tolerant volgens example 2

Beslissing

• 2× Engines
• 2× Core/Web

Rationale

• balans tussen beschikbaarheid en complexiteit.

ADR‑GIS‑016

Klantsegmentatie i.p.v. HA‑setup

Beslissing Geen platform‑brede HA, maar klantsegmentatie.

Rationale

• SLA haalbaar zonder HA;
• minder kosten en complexiteit;
• betere performance‑isolatie.

ADR‑GIS‑016

Klantsegmentatie i.p.v. HA‑setup

Beslissing Geen platform‑brede HA, maar klantsegmentatie.

Rationale

• SLA haalbaar zonder HA;
• minder kosten en complexiteit;
• betere performance‑isolatie.

ADR‑GIS‑017

Gebruik branch versioning in plaats van traditional versioning

Context

Binnen de Esri ArcGIS Enterprise-omgeving wordt gebruikgemaakt van enterprise geodatabases voor het beheren en bewerken van geografische data. Voor versiebeheer van deze data zijn meerdere opties beschikbaar, waaronder traditional versioning en branch versioning.

Historisch is traditional versioning veel toegepast, onder andere vanwege brede ondersteuning in ArcMap en bestaande werkprocessen. Echter, de organisatie gaat steeds meer gebruik maken van:

• ArcGIS Pro
• Webgebaseerde editing (Feature Services)
• Service-georiënteerde architectuur
• Meerdere gelijktijdige bewerkers
• CI/CD-achtige straat voor GEO-data en services

Traditional versioning kent in deze context beperkingen, zoals complex versiebeheer, beperkte ondersteuning bij web editing en hogere beheeroverhead.

De architectuurkeuze is daarom nodig: welke versioning-strategie past het beste bij de huidige en toekomstige Esri-architectuur?

Beslissing

Wij kiezen voor branch versioning als standaardmechanisme voor versiebeheer binnen de Esri geodatabases, en stappen waar mogelijk af van traditional versioning.

Branch versioning wordt toegepast in combinatie met:

• Feature services (web-enabled editing)
• ArcGIS Pro als primaire desktopclient
• Een service- en API-gedreven GIS-architectuur

Motivatie

Waarom branch versioning?

1. Betere ondersteuning voor web en services

   • Branch versioning is specifiek ontworpen voor gebruik via feature services.
   • Noodzakelijk voor web editing, portals en moderne Esri workflows.

2. Betere schaalbaarheid en prestaties

   • Geen delta-tabellen per versie zoals bij traditional versioning.
   • Minder database-locking en betere performance bij veel gelijktijdige editors.

3. Eenvoudiger versiebeheer

   • Minder complexe versiehiërarchieën.
   • Geen directe gebruikersversies meer in de database.
   • Duidelijk onderscheid tussen default en bewerkingsversies.

4. Toekomstvast

   • Esri investeert primair in branch versioning.
   • Nieuwe functionaliteiten verschijnen eerst (of uitsluitend) voor branch versioned data.
   • ArcMap-compatibiliteit (vereist voor traditional versioning) wordt uitgefaseerd.

5. Betere aansluiting op governance en auditing

   • Expliciete reconcile & post-processen via services.
   • Duidelijkere verantwoordelijkheden voor datakwaliteit.

ADR-GIS-018

Prefereer werken via ArcGIS Services in FME boven directe database toegang en ArcPy

Binnen de GIS- en dataverwerkingsarchitectuur wordt FME ingezet voor conversies, validaties en integraties van geografische data. Historisch gebeurt dit regelmatig via:

• Directe database connecties vanuit FME naar enterprise geodatabases
• ArcPy-scripts, waarvoor FME gekoppeld moet zijn aan een ArcGIS Server-installatie

Deze aanpak leidt tot sterke technologische koppeling tussen:

• FME
• ArcGIS Server
• De onderliggende enterprise geodatabases

In de huidige en toekomstige architectuur is echter de wens om:

• GIS-functionaliteit zoveel mogelijk als services aan te bieden
• Componenten via loose coupling te implementeren
• Beveiliging, governance en lifecycle management centraal te organiseren
• De afhankelijkheid van ArcPy te verminderen

De architecturale vraag is: hoe laten we FME samenwerken met ArcGIS, zonder directe afhankelijkheden van databases en ArcPy?

Beslissing

Wij prefereren het gebruik van ArcGIS Services vanuit FME, in het bijzonder:

• Feature Services voor lezen en schrijven van GIS-data
• Geoprocessing Services voor het uitvoeren van GIS-bewerkingen

Daarbij geldt bij voorkeur:

• Geen directe database‑toegang vanuit FME tot enterprise geodatabases
• Geen ArcPy-gebruik in FME-workflows
• FME communiceert uitsluitend via goed gedefinieerde services (HTTP/REST)

Motivatie

Waarom werken via ArcGIS Services?

1. Ontkoppeling van FME en ArcGIS Server

   • FME hoeft geen ArcGIS Server-installatie te hebben.
   • Geen afhankelijkheid van ArcPy-runtime, Python-versies of Esri-licenties.
   • Duidelijke scheiding van verantwoordelijkheden.

2. Service-georiënteerde architectuur

   • Feature Services en GP Services vormen de contracten tussen systemen.
   • ArcGIS Server encapsuleert GIS-logica en datatoegang.
   • Consistent met SOA- en API-first principes.

3. Verbeterde beveiliging en governance

   • Geen databaseaccounts meer in FME.
   • Autorisatie en authenticatie via Portal / ArcGIS Enterprise.
   • Centraal te beheren via rollen, tokens en service-rechten.

4. Betere beheersbaarheid en onderhoud

   • Wijzigingen in datamodellen blijven binnen ArcGIS Server.
   • FME-workflows zijn robuuster tegen schemawijzigingen.
   • Minder operationele complexiteit bij upgrades.

5. Cloud- en schaalbaarheidsvriendelijk

   • Services zijn geschikt voor schaalvergroting en load balancing.
   • FME kan onafhankelijk worden geschaald of verplaatst.
   • Past bij containerisatie en platform-onafhankelijke inzet.

ADR-GIS-019

Beheer FME Flow centraal bij IVP Platformen, FME Form bij beherende partij van de omgeving

Context

Binnen het GIS-platform wordt FME gebruikt:

• FME Form voor ontwikkeling en technisch applicatiebeheer
• FME Flow als centrale uitvoerings- en orkestratievoorziening

TAB‑teams (Geostenen en GeoHub) ontwikkelen en beheren applicaties op het platform en gebruiken hiervoor FME Form.
IVP Platformen is verantwoordelijk voor het beheer van het platform en de centrale infrastructuur.

FME Form installaties bevinden zich deels op beheermachines van TAB-teams en deels op beheermachines van IVP.
Er is behoefte aan een duidelijke afbakening van beheer en verantwoordelijkheden, inclusief security en BIO-compliance.

Beslissing

• FME Flow

  • Is volledig in beheer bij IVP Platformen

• FME Form

  • Installaties bij TAB-teams → in beheer bij TAB-teams
  • Installaties op IVP-beheermachines → in beheer bij IVP Platformen

• Verantwoordelijkheden

  • IVP Platformen → platformbeheer (infrastructuur, hosting, security, lifecycle)
  • TAB-teams → ontwikkeling en technisch applicatiebeheer, inclusief beheer van FME workspaces en naleving van BIO binnen hun scope

Motivatie

De scheiding volgt het principe dat beheer wordt belegd bij de partij met feitelijke controle over de omgeving.

Centralisatie van FME Form bij IVP Platformen is niet uitvoerbaar, omdat:

• installaties zich bevinden op beheermachines van TAB-teams
• IVP Platformen geen toegang heeft tot deze omgevingen
• dit zou leiden tot verantwoordelijkheid zonder daadwerkelijke beheermogelijkheden

De gekozen oplossing:

• sluit aan bij de rol van TAB-teams als technisch applicatiebeheerder en ontwikkelaar
• borgt centrale controle op de platformcomponent (FME Flow)
• voorkomt onduidelijke verantwoordelijkheden en beheerconstructies

Aandachtspunt is dat TAB-teams zelf verantwoordelijk zijn voor security en BIO-compliance binnen hun applicaties en tooling.

ADR-GIS-020

Een ArcGIS Server in de DMZ mag onder voorwaarden verbinding maken met een interne geodatabase

Context

De ArcGIS Server is geplaatst in de DMZ om GIS-diensten beschikbaar te stellen aan externe afnemers. Voor een aantal diensten is toegang nodig tot gegevens die zijn opgeslagen in een interne geodatabase.

Het uitgangspunt binnen de architectuur is dat systemen in de DMZ geen directe toegang hebben tot interne databronnen. In specifieke situaties is het echter niet wenselijk of doelmatig om de benodigde datasets volledig te repliceren naar een aparte database in de DMZ. Daarom is beoordeeld onder welke voorwaarden een gecontroleerde verbinding tussen de ArcGIS Server in de DMZ en een interne geodatabase acceptabel is.

Voor bestanden geldt hetzelfde uitgangspunt. Bestanden die in de DMZ beschikbaar moeten zijn, worden niet rechtstreeks benaderd vanuit het interne netwerk, maar via een gecontroleerd synchronisatieproces tussen een interne fileshare en een fileshare in de DMZ.

Beslissing

Een ArcGIS Server in de DMZ mag verbinding maken met een interne geodatabase, mits:

1. de firewall zodanig is ingericht dat uitsluitend het noodzakelijke verkeer tussen de betreffende ArcGIS Server en geodatabase wordt toegestaan;
2. gebruik wordt gemaakt van een databaseaccount met de minimaal noodzakelijke rechten voor de beoogde functionaliteit;
3. de ontsloten datasets uitsluitend bestaan uit kopieën van brongegevens en niet uit primaire registraties of andere brondata waarvan de integriteit direct afhankelijk is van de DMZ-omgeving;
4. de securityarchitectuur van de oplossing expliciet is uitgewerkt, beoordeeld en goedgekeurd.

Voor de uitwerking en beoordeling van de securityarchitectuur kan gebruik worden gemaakt van het Security architectuur template (DMZ) zoals beschikbaar op Confluence.

Indien gegevens middels bestanden beschikbaar worden gesteld aan de DMZ, dient gebruik te worden gemaakt van een fileshare in de DMZ die wordt gesynchroniseerd met een interne fileshare. Deze synchronisatie dient plaats te vinden via een beveiligde verbinding met SSL/TLS. Rechtstreekse toegang vanuit de DMZ naar een interne fileshare is niet toegestaan.

Motivatie

Het uitgangspunt blijft dat systemen in de DMZ geen directe toegang hebben tot interne databronnen of bestandssystemen. Voor GIS-diensten kan een gecontroleerde verbinding naar een interne geodatabase echter noodzakelijk zijn om actuele gegevens beschikbaar te stellen zonder aanvullende replicatie- of beheercomplexiteit.

De risico's van een dergelijke verbinding zijn acceptabel wanneer passende beveiligingsmaatregelen zijn getroffen. Daarbij zijn met name van belang:

• beperking van netwerkverkeer tot uitsluitend de noodzakelijke verbindingen;
• toepassing van het least privilege-principe voor databaseautorisaties;
• gebruik van kopieën van gegevens zodat primaire brondata niet afhankelijk worden van een systeem in de DMZ;
• expliciete vastlegging en beoordeling van de securitymaatregelen in een securityarchitectuur.

Voor bestanden wordt hetzelfde principe gevolgd. Door gebruik te maken van een gesynchroniseerde fileshare in de DMZ wordt voorkomen dat systemen in de DMZ rechtstreeks toegang hebben tot interne opslagvoorzieningen. De synchronisatie via SSL/TLS waarborgt de vertrouwelijkheid en integriteit van de gegevens tijdens transport.

Door de securityarchitectuur vooraf te laten toetsen, kan per situatie worden beoordeeld of aanvullende maatregelen nodig zijn, bijvoorbeeld ten aanzien van authenticatie, autorisaties, encryptie, monitoring, logging of eventuele schrijfrechten. Hiermee ontstaat een gecontroleerde en verdedigbare uitzondering op het principe dat DMZ-componenten geen directe toegang hebben tot interne databronnen.