Bijlage A - Architectural Decision Records (ADR’s) IP

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.

Gevolgen

• Oracle wordt niet ingezet voor EGDB;
• skillset en tooling richten zich op PostgreSQL.

ADR‑GIS‑003

Gebruik native geometrieformaten

Beslissing
Gebruik PostGIS Geometry (PG_GEOMETRY) en SDO_GEOMETRY, geen ST_GEOMETRY.

Rationale

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

Randvoorwaarden

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

ADR‑GIS‑004

ArcSDE alleen indien functioneel noodzakelijk

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

Rationale

• ArcSDE verhoogt LCM‑ en beheerlast;
• read‑only en lichte edits kunnen zonder ArcSDE.

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.