Vijf jarenplan GIS

1. Inleiding

Dit document beschrijft de verwachte ontwikkelingen van het GIS platform op een tijdschaal van 5 jaar. Drivers voor deze ontwikkelingen zijn zowel intern, bijvoorbeeld de ICT strategie of de Rijkswaterstaat Enterprise Architectuur (REA2025), als extern, bijvoorbeeld AI, cloud native geospatial, Europese wetgeving zoals INSPIRE of data spaces.

De volgende drivers kunnen worden onderscheiden:

• technologische evolutie (cloud-native, kubernetes, OpenShift)
• vendor lockin & stijgende licentiekosten
• noodzaak van high availability en meer reliability
• soevereiniteit
• vraag naar data science en Artificial Intelligence (AI) waaronder ook machine learning
• strenger wordende security kaders

2. Strategische Doelstellingen (2026 t/m 2030)

Deze lijst is op volgorde van prioritering, dus de bovenste heeft de meeste prioriteit.

• Digitale soevereiniteit & compliance structureel geborgd in het platform
• Adoptie van open standaarden als primaire integratiestrategie (OGC APIs + cloud-native formats + GeoDCAT)
• Volledige transitie van het server landschap naar een cloud‑native geospatial platform op OpenShift
• Een volwassen hybride GIS‑landschap: potentieel ligt dit op 80% open source+ 20% proprietary (enterprise-only use cases) maar in de praktijk kan dit natuurlijk verschillen
• Verminderen van de vendor lock-in
• Integratie met data warehouses en analytics‑platformen.
• Volledig geïntegreerde data science‑ en AI‑omgeving op OpenShift

2.1 Digitale soevereiniteit & compliance structureel geborgd in het platform

RWS behoudt aantoonbaar controle over data, software en operaties, en voldoet structureel, niet incidenteel, aan wet- en regelgeving.  “Structureel” betekent: ingebouwd in architectuur en processen, niet afhankelijk van individuen. Concreet gaat dit om data‑soevereiniteit, operationele soevereiniteit en regelgeving. Het gaat dus vooral om het bewust ontwerpen van systemen. Wat er nodig is in het platform voor deze strategische doelstelling:

• architectuurkeuzes die een fundament leggen (cloud-agnostisch, containerisatie, gitops, data scheiding, open standaarden en open formaten)

• identity, access & autorisatie (IAM) goed op orde

• data management en governance (dit ligt meer bij data architectuur en DMC maar het platform moet dit wel faciliteren, bijvoorbeeld GeoDCAT)
• security by design
• juridisch en contractueel (bijv. dataverwerkingsovereenkomsten, exit clausules)

2.2  Adoptie van open standaarden als primaire integratiestrategie

Alle integraties, intern én extern, lopen primair via open, gestandaardiseerde interfaces en data‑contracten, ongeacht de gebruikte software. Dit is een architectuurstrategie, en betreft: API first, decoupling tussen data, services en clients en integratie met IT, data- en analyticsecosystemen. Voorkomen dat GIS een silo wordt. Wat is er nodig om dit structureel te borgen:

• Architectuur principes: open standaarden zijn default; afwijkingen zijn expliciet en tijdelijk. geen proprietary APIs in ketenintegraties, clients zijn vervangbaar

• OGC APIs als primaire service‑laag

• Cloud‑native dataformats (direct gebruik in data lakes & warehouses)

• GeoDCAT & metadata‑gedreven integratie (GeoDCAT‑AP NL conformiteit)

• Governance & handhaving (PSA, architectuur reviews)

2.3 Volledige transitie van het server landschap naar een cloud‑native geospatial platform op OpenShift

Het GIS‑platform wordt ontworpen, beheerd en doorontwikkeld volgens cloud‑native principes, waarbij OpenShift het standaard uitvoerings‑, beveiligings‑ en governance‑platform is. Concreet houdt dit in:  geen “servers” meer als primair concept, geen handmatig beheer van applicaties, geen platformkennis die alleen in hoofden zit en geen onderscheid meer tussen “GIS” en “IT‑platform”. Wat is er nodig om dit succesvol te doen?

• cloud‑native ontwerpprincipes (stateless services waar mogelijk, externe, schaalbare opslag, immutable deployments (geen hotfixes op prod), horizontaal schaalbaar denken, API‑first ontsluiting)

• OpenShift als platform, niet als cluster (standaard runtime voor GIS‑services, centrale beveiligingslaag, policy‑engine (security, netwerk, resources), CI/CD‑ankerpunt, observability platform)

• Transitie van “serverdenken” naar “platformdenken” (self‑service omgevingen, CI/CD als standaard, automatisch testen & deployen, tijdelijke omgevingen (ephemeral))

• Data‑architectuur los van applicaties (object storage, databases, meerdere ontsluitingen bovenop dezelfde data, backup & restore als platformdienst, duidelijke lifecycle van data vs. services)

• Beheer, operatie & betrouwbaarheid: cloud‑native betekent niet minder beheer, maar ander beheer (FinOps, betere SLA's)

2.4 Een volwassen hybride GIS‑landschap

RWS kiest per use‑case bewust voor open source of proprietary GIS‑componenten, binnen één samenhangend platform en architectuur, zonder lock‑in of fragmentatie. Belangrijk hierbij is: hybride is een ontwerpkeuze, geen tussenfase, 80/20 is een richtlijn, geen target en proprietary blijft toegestaan waar het toegevoegde waarde heeft die open source niet (efficiënt) levert. Dit is dus een governance‑ en afwegingsstrategie, geen technologiebesluit. Wat is er nodig?

• Heldere afwegingscriteria (duidelijke beslisregels, open source tenzij, transparantie over waarom proprietary gekozen wordt)

• Eén platform, meerdere implementaties (hybride werkt alleen als open source en proprietary gelijk behandeld worden)

• Open standaarden als scheidingslaag

• Capability‑gedreven landschap (volwassen hybride GIS‑landschappen denken in capabilities, niet in producten)

• Kennis, support & verantwoordelijkheid (open source is geen “gratis software”; het is een ander supportmodel)

2.5 Verminderen van de vendor lock-in

RWS behoudt structureel de vrijheid om leveranciers, technologieën en hostingmodellen te wisselen, zonder ontwrichtende herbouw van het GIS‑landschap. Lock-in is niet binair, het gaat om beheersbaarheid van afhankelijkheden. Sommige lock‑ins zijn bewust en tijdelijk acceptabel.  Vendor lock‑in verminderen is dus géén technische maatregel, maar een architecturale en governance‑strategie. Wat is er nodig om vendor lock-in echt te verminderen?

• Acceptatie: lock‑in zit vooral in architectuur, niet in tools (proprietary dataformats, niet‑gestandaardiseerde APIs, tight coupling tussen client, service en data, embedded business logic in producten)

  • Architectuurkeuzes die ontkoppeling afdwingen

  • Expliciete keuzes over waar lock‑in acceptabel is en waar niet

• Open standaarden als scheidingslaag (tools zijn vervangbaar, data is duurzaam, integraties overleven productwissels)

• Cloud‑native & portable runtime (OpenShift) (infrastructurele lock‑in is vaak harder dan applicatie‑lock‑in)

• Data‑eigenaarschap en datamobiliteit (data opgeslagen in niet‑proprietary formaten, regelmatig getest export‑/migratiepad)

• Contractuele & organisatorische maatregelen

2.6 Integratie met data warehouses en analytics‑platformen

Geografische data is een volwaardig onderdeel van het organisatiebrede data‑ en analytics‑ecosysteem, en kan direct worden gebruikt door BI‑, data science‑ en AI‑teams zonder kopiëren, maatwerk of GIS‑specifische tooling. GIS‑data is querybaar, combineerbaar en herbruikbaar, analyse gebeurt waar de data al is (warehouse / lake) en locatie wordt een dimensie, geen niche. Wat is er nodig voor deze strategische doelstelling?

• Datamodel‑integratie (spatial is not special)

• Cloud‑native dataformats

• Ontkoppeling van data, services en visualisatie

• Open APIs & query‑toegang

• Metadata & semantiek

2.7 Volledig geïntegreerde data science‑ en AI‑omgeving op OpenShift

Data science en AI zijn volwaardige, beheerste capabilities binnen hetzelfde cloud‑native platform als GIS, data en analytics, met herbruikbare pipelines, reproduceerbare modellen en aantoonbare governance. Wat is er nodig om dit te laten slagen?

• OpenShift als ML‑platform, niet alleen als cluster (zonder duidelijke platformrol wordt AI snel chaotisch, notebooks, model training, model serving, GPU ondersteuning)

• Data‑toegang zonder kopiëren (data‑architectuur, cloud‑native geo‑dataformats)

• MLOps & lifecycle‑management (versiebeheer van data, features en modellen, geautomatiseerde training pipelines)

• Integratie met GIS & analytics

• Governance, ethiek & compliance

• MCP zodat agents gebruik kunnen maken van het GIS Platform

Data lake en platform-overkoepelende storage

Zoals hierboven al aangegeven (2.6, 2.7), is de verwachting dat de cloud-native storage laag toe zal gaan naar: S3 storage met daarop Apache Iceberg (metadata & table layer) en Apache Parquet (file storage) voor de opslag. Geo is niet meer apart, maar gewoon standaard in deze formaten. Dit betekent dat GIS, BI, Data Suite etc. gebruik kunnen maken van 1 opslag laag. Middels engines zoals DuckDB, maar er zijn ook verschillende andere open source en proprietary analyse mogelijkheden bovenop deze gestandaardiseerde data laag (gebaseerd op open formaten), kunnen deze formaten efficiënt geanalyseerd worden. En ook dienen als de bron voor AI agents.

3. Huidige Situatieanalyse

3.1 Functioneel

Het huidige GIS platform is een mix van proprietary en open source componenten. Niet op elke ABB (Architecture Building Block) is ook een open source SBB (Solution Building Block) beschikbaar momenteel, waarbij de grootste omissie een open source component om Web GIS applicaties te kunnen bouwen is. Sinds de inzet van GeoWeb Modules, gebaseerd op Vertigis Studio, als vervanger van GeoWeb HTML5 is er een nog sterkere integratie tussen GeoWeb en het ArcGIS Enterprise platform, en kunnen deze componenten eigenlijk niet meer los van elkaar gezien worden. Dit betekent ook dat er druk ontstaat op het kunnen gebruiken van hybride architecturen, waarbij een mix van open source en proprietary componenten middels open standaarden met elkaar kunnen samenwerken. Naast GeoWeb Modules is er ook de mogelijkheid om applicaties te bouwen middels bijvoorbeeld ArcGIS Experience Builder of Instant Apps. Eigenlijk moet er duidelijk beleid komen wanneer je welke tool inzet, al ligt er ook veel vrijheid bij de ontwikkelstraten om hierin keuzes te maken. Maar je zou in zijn algemeenheid kunnen zeggen dat je de afhankelijkheid van Vertigis Studio wil minimaliseren en vooral gebruiken bij toepassingen die niet eenvoudig met de standaard Esri tooling te realiseren zijn. Aan de andere kant hoor je vaak ook de roep om uniforme applicaties / GUIs en verschillende soorten tooling maakt dit moeilijker realiseerbaar.

Het GIS platform is momenteel een mix van:

• self service, dus gebruikers die hun geodata kunnen publiceren en analyses kunnen uitvoeren op het GIS platform
• bouwblokken voor ontwikkelstraten zoals tab-geohub en tab-geostenen.

Het huidige GIS platform is momenteel niet goed/eenvoudig geschikt voor MKO (Missie Kritieke Ondersteuning)/MKS (Missie Kritieke Systemen), machine learning en data science (geen notebook server). Met betrekking tot MKO wordt nu soms ArcGIS Online gebruikt maar zonder dat IVP hierop de 24/7 ondersteuning levert, dit ligt dan direct bij TAB teams zoals TAB-GEOHUB. Maar met de nieuwe REA is in principe cloud (en dus ook SaaS, ArcGIS Online houdt een beetje het midden tussen SaaS en cloud) niet toegestaan voor MKO/MKS, maar ten tijde van het ontstaan van applicaties als Berger Select bestond deze regel nog niet. Met de overstap naar kubernetes zouden deze hiaten beter ingevuld kunnen gaan worden. Het kubernetes product van Esri is standaard geschikt voor high availability en dus beter geschikt voor MKO/MKS. Ook is er een product genaamd ArcGIS Raster Analytics on Kubernetes wat beter geschikt zou moeten zijn voor machine learning. In de huidige omgeving (VMs) konden we geen Notebook server installeren maar dit kan wel onder kubernetes/OpenShift met ArcGIS Notebook Services Advanced on Kubernetes.

De volgende knelpunten kunnen onderscheiden worden:

• data opslag is momenteel in een proprietary Esri binair formaat, maar is ook erg lastig oplosbaar (beheerteam ziet veel beren op de weg)
• veel FME workflows maken gebruik van enterprise geodatabases (ArcGIS server licentie nodig onder FME Flow Engine nodes, nog niet op Linux/k8s mogelijk). Eventueel aansturen op zoveel mogelijk ontkoppeling (minder tight coupling) via services zie ook hier voor meer achtergrond info
• zowel Vertigis (Studio Analytics) als ArcGIS (ArcGIS Monitoring) hebben hun eigen dure analytics platform beschikbaar, terwijl we eigenlijk willen aansluiten op RWS standaarden zoals splunk (maar nabouwen is veel maatwerk inspanning)
• Portal voor ArcGIS krijgt een steeds centralere rol in het ArcGIS platform. Kan leiden tot dubbele catalogi. Direct aansluiten via CS-W op GeoNetwork vaak geen optie helaas.
• Het blijkt lastig om onze metadata standaarden toe te passen in het ArcGIS platform, en we moeten vaak werken met workarounds zoals verwijzingen naar GeoNetwork
• Het is op dit moment onduidelijk waar de business heen wil m.b.t. GeoNetwork. Kan zijn dat het een steeds beperktere rol krijgt in het kader van het CTD (centraal toeganspunt data), maar momenteel nog wel vaak een spin in het web
• Niet altijd de beste, meest uitgebreide of tijdige ondersteuning voor open standaarden in ArcGIS Enterprise / GeoWeb Modules, zie bijv ook hier

3.2 Technisch

Technisch gezien is het GIS platform momenteel een mix van:

• Windows Server Virtual Machines (FME, ArcGIS Enterprise, GeoWeb Modules)
• CloudFoundry (GeoServer, GeoNetwork)
• CloudBoostr (Elastic Search voor GeoNetwork)
• PostgreSQL databases ArcSDE
• Oracle databases met ArcSDE

De volgende technieken/tooling worden/wordt ingezet door het technisch beheer team:

• CheckMK
• Splunk
• Grafana
• GitLab
• Ansible
• mRemoteNG
• KeePass
• Azure DevOps
• Robot Framework

• Capaciteit & performance
  • Veelal VM gebaseerd dus beperkt schaalbaar (alleen verticaal). FME is wel fault-tolerant ingericht maar is de uitzondering. Open source is gebaseerd op CloudFoundry en staat er dus beter voor.
  • In de aansluitvoorwaaden staan geen performance afspraken / garanties met afnemers. Veel van de verantwoordelijkheid wordt ook bij de afnemers gelegd middels de aansluitvoorwaarden.
• Versies & configuratie
  • Middels IPUs wordt ervoor gezorgd dat we goed bijlopen met de laatste versies.
  • Ansible wordt ingezet voor configuratie management bij de bouwstenen van open source (deels), FME en GeoWeb.
• Monitoring
  • Splunk (logs/SIEM) en CheckMK (self-hosted).
• Beheerprocessen & incidenthistorie
  • Beheerprocessen zijn nu al duidelijk gedocumenteerd op de gitlab Wiki.
  • Incidenten lopen allemaal via topdesk en op die manier is de historie geborgd.

3.3 Organisatie

Rollen: DBA (ligt buiten IVP), functioneel beheer (ligt buiten IVP), product owner, technisch beheer, architectuur, security.

Kennisniveau en benodigde bijscholing: op het gebied van OpenShift en gitops/devops moet het team vermoedelijk bijgeschoold worden

Invloed van de verservicing op het technisch beheer team brengt ook risico's met zich mee.

(4. Doelarchitectuur Platform)

Moet nog opgesteld worden samen met Wim Blanken zie Geo-ICT Doelarchitectuur - EA RWS - Confluence

5. 5‑Jaren Roadmap

De roadmap voor het GIS platform is er in 2 vormen:

1. een gedetailleerde versie in de vorm van de bekende gekleurd slang voor de komende 2 jaar, zie Roadmap GIS
2. een algemenere voor de komende 5 jaar, zie hieronder.

Beide roadmaps geven invulling aan de manier waarop het platform de strategische doelstellingen wil realiseren.

1. Jaar 1 (2026) – Doorgaan met IPUs, voorbereidingen treffen voor OpenShift, POCs
2. Jaar 2 (2027) – Migratie CloudFoundry naar CloudBoostr, onderzoek naar meer open source alternatieven voor bestaande componenten
3. Jaar 3 (2028) – Migratie naar OpenShift, IAM integratie
4. Jaar 4 (2029) – Integratie met on premise AI en data science
5. Jaar 5 (2030) – GIS platform is gereed voor cloud native geo formaten, alle relevante OGC APIs worden ondersteund

2026

Doorgaan met IPU's voor de verschillende bouwstenen, details in roadmap PO

GeoServer Cloud (gebaseerd op GeoServer versie 3) werkend op Cloudboostr k8s 9

PoC ArcGIS for Kubernetes op OpenShift (afhankelijk van beschikbaarheid OpenShift, eventueel doorschuiven naar 2027)1

PoC GeoServer Cloud op OpenShift (afhankelijk van beschikbaarheid OpenShift, eventueel doorschuiven naar 2027) 1 9

2027

GeoNetwork naar CloudBoostr k8s 9

Open Source Web GIS geselecteerd en operationeel (eventueel met slechts best effort dienstverlening intern)

POC ArcGIS for Kubernetes op OpenShift1

POC Vertigis Modules op OpenShift1

POC FME Flow op OpenShift1

POC GeoServer Cloud op OpenShift1 9

2028

ArcGIS for Kubernetes op OpenShift operationeel in productie 2 3 5

FME Flow op OpenShift 2

GeoServer Cloud op OpenShift operationeel in productie 2 3 9

2029-2030

Cloud-native opslag voor geo formaten, 1 gedeelde datalaag tussen alle platformen. 4

Ondersteuning voor AI in de data laag. 4

Overzicht afhankelijkheden:

1.  Leveringen Datacenter voor standaard dienstverlening
2.  Levering POC Open Shift clusters, IRN Datacenter
3.  Realisatie datacenter 3.0(DC 3.0), IRN Datacenter
4.  Beschikbaarheid BIO-compliant DMZ omgeving in DC 3.0
5.  Inrichting dienstverlening S3 storage, IRN Datacenter
6.  Volledigheid ArcGIS Server deployement op K8s, ESRI
7.  Alle Vertigis Modules beschikbaar als containers
8.  Zonder launching customers krijg je te trage vernieuwing en gaan domeinen dit zelf doen voor hun eigen domein met diversificatie van oplossingen tot gevolg 
9.  Realisatie ACME & IAM (inclusief e-herkenning)
10.  Ondersteuning vanuit leveranciers voor kubernetes deployment
11.  Beschikbaarheid voldoende budgetten
12.  Beschikbaarheid handjes, realisatie van RAP Next
13.  Beschikbaarheid voldoende licenties voor migratie
14.  Continuïteit en verbetering kennisborging en opbouw vaste medewerkers

6. Governance, Organisatie & Beheer

• Personele bezetting
• Servicelevels

Input van de PO's nodig hier.

7. Security & Compliance

• BIO: voldoen aan NIS2 en BIO 2.0
• Exceptions: sturen op zo min mogelijk excepties
• Certificaten: afstappen van self-signed certificaten, dit heeft wel invloed op de Ansible automations. Gebruik maken van ACME zodra dit operationeel is.

8. Risicoanalyse, Afhankelijkheden & Mitigatie

• Software niet volledig geschikt voor OpenShift → terugval naar VMs in OpenShift of zelfs VMWare VMs
• Open source zonder ingekochte ondersteuning (afbreukrisico) → best effort support is het maximum. Proberen toch budget te realiseren voor training en support.
• Weerstand binnen functioneel beheer en/of ontwikkelstraten → partijen tijdig erbij betrekken en meenemen in het proces
• Weerstand binnen DMC voor nieuwe data formaten → partijen vroegtijdig betrekken, ook GDR zodat e.e.a. geautomatiseerd kan worden uitgeleverd
• Vendor lock‑in → voorkeur open‑source, open formaten, periodieke markttoets
• Kennisveroudering → structurele training, opensource community betrokkenheid
• Complexiteit toename → standaarden & governance
• Security risico’s → hardening, patchbeleid, bedreigingsanalyse
• Veroudering van hardware → lifecycle planning
• Mogen we producten als GeoNovation KaartViewer wel inzetten? → GeoNovation KaartViewer lijkt momenteel het beste product, maar maakt alleen gebruik van open source en is zelf geen open source. Volgens REA is dit dan geen optie maar het kan wel de licentiekosten aan de Esri kant verminderen
• Na aflopen ELA gaan licentiekosten mogelijk sterk omhoog → op tijd nadenken over exit strategie en zorgen dat een alternatief product al in beeld is
• ELA (o.a. GeoCat) bevat niet alle nieuwe producten → lijkt erop dat ze toewerken naar kubernetes ondersteuning als een extra buiten de ELA

9. KPI’s & Succesfactoren

• Platform uptime ≥ 98%
• Performance: verbeteren
• Aantal (grote) incidenten per jaar naar beneden
• Datakwaliteit: % geslaagde validatieregels
• Governance: auditbevindingen (BIO/AVG) ≤ 2 per jaar
• Reductie vendor‑afhankelijkheden
• Verminderen licentie kosten
• Meer soevereiniteit: ArcGIS Online alleen inzetten als het echt niet anders kan, en zorgen voor regelmatige backup van data op een RWS medium

10. Evaluatie & Bijstelling

• Halfjaarlijkse technische review.
• Jaarlijkse gebruikersenquête (dit wordt uitgevoerd door de PO's)
• Tweejaarlijkse marktverkenning en actualisatie advies.

Roadmap update in overleg met architectuurboard en stuurgroep