Vijf jarenplan Integratieplatform

5‑Jarenplan Integratie Platform (2026–2030)

Periode: 2026–2030

Domein Architect: Thomas Commandeur
Product Owner: Michel Koning (RWS CIV), Solution Architect: Mike van Rijn

1. Inleiding

Een API-platform is de komende vijf jaar onmisbaar om de groeiende stroom aan AI-toepassingen veilig en overzichtelijk met bedrijfsdata te verbinden. Het fungeert als een centrale beveiliging laag die bedrijfsgegevens beschermt tegen toenemende cyberdreigingen en voldoet aan strikte privacywetgeving, zoals BIO en NIST. Door API’s als herbruikbare bouwstenen aan te bieden, kan de business sneller nieuwe functies lanceren zonder diepe technische kennis. Het platform voorziet in een flexibele motor voor digitale innovatie.

2. Strategische Doelstellingen (2026–2030)

• Container first en cloud ready; Toekomstbestendig platform op OpenShift.
• Self‑service centraal; vanuit een toegankelijke portaal zijn beschikbaar gestelde API templates voorzien van guardrails en eenvoudig te deployen. Gebruikers kunnen zelf gateway policies en MFT flows aanmaken.
• Open source first, closed supported wanneer nodig; soevereine alternatieven meegewogen.
• Beleidsrichtlijnen voor veilig en verantwoord gebruik; aan gebruikers is duidelijk beschreven hoe men centraal (vanuit het Integratie Platform) en decentraal (via Service Mesh) verantwoord gebruik maakt van de diverse integratie mogelijkheden binnen RWS.
• Infrastructure as code, secure by design; de CI/CD bouwstraat is voorzien van de laatste standaarden op gebied van security testing, waarmee de kwaliteit van gedeployde APIs is geborgd.
• End‑to‑end observability; Dashboards ten behoeve van management tonen near real time logging en leveren een directe bijdrage aan audits.
• Uitgebreid MFT aanbod; Managed File Transfer staat als oplossing op zichzelf en biedt aan vrijwel iedere usecase van RWS de mogelijkheid voor passende en veilige verplaatsing van bestanden.
• Volledige regie op integratieoplossingen; binnen onze invloedsfeer. Afhankelijkheden met Netwerken/Infrastructuur zijn tot een minimum beperkt (verzoek tot sluitende portfolio/NGFW).
• Gedifferentieerde integratie diensten:
• Enterprise Integratie: We zijn in controle voor bedrijfkritische en/of complexe applicaties middels enterprisegrade Integration-Platorm-as-a-Service.
• Basis Integratie: We voorzien in een omgeving voor eenvoudige en/of generieke applicatie koppelingen middels laagdrempelige open source Integration Framework.
• Edge Integratie: We voorzien in veilig, geautoriseerd verkeer tussen internet (noord) en intern (zuid) via een enkele, hoog-beschikbare punt van binnenkomst middels API gateway.

3. Huidige Situatieanalyse

3.1 Functioneel

• Functioneel overzicht & workloads

• Enterprise Integratie (ESB): MuleSoft HA cluster (2 VM’s) als centrale integratielaag.
  API-ontwikkel en deploy mogelijkheid, via een Azure bouwstraat, maar toegankelijk voor platformbeheerders & ontwikkelaars van Team Blauw

• Bestands- en messagingverkeer (uitzonderingspositie op securityrichtlijnen): SFTP verkeer & AMQP verkeer

• RIVA: aansluitvoorwaarden bestaan en beschrijven functionele eisen voor API-koppelingen, maar zijn nog niet vertaald naar concrete self-service processen of technische guardrails.

• Geen OpenShift/container-compatibel platform.

• Geen self-service portaal met templates/guardrails.

• Geen basis integratie (lightweight/open source) of edge integratie als dienst.

• Geen managed MFT als volwaardige standalone oplossing.

• Gebruikspatronen
• Deployments: deels handmatig / beheer-gedreven (beheerder logt in en deployt).
• Bouwstraat (CI/CD): deels geautomatiseerd, maar niet breed beschikbaar; “klanten” (andere teams/domeinen) hebben nog geen werkend self-service concept.
• API beheer en ontsluiting: centraal via platform (zoals bedoeld voor domeinoverstijgende verbindingen), maar in de praktijk beperkt door toegang en proces.
• Decentraal gebruik van integratie tooling is nu mogelijk volgens RIVA beleid (en straks nog meer toegankelijk via Service Mesh): beleidsrichtlijnen zij nog onvoldoende uitgewerkt (conceptueel wel genoemd in RIVA/architectuur, maar niet operationeel of afdwingbaar).
• Knelpunten

• Geen portal; onboarding en deployments vragen beheerinterventie.

• De Azure bouwstraat is niet “productized” voor externe teams/klanten → geen uniforme “klantreis”.

• Alleen MuleSoft ESB beschikbaar → voor diverse usecases overkill.

• Niet mogelijk om “simpele” workloads te faciliteren (bijv. een eigen Java API of COTS API) zonder dat de klant zelf integratie-tooling moet beheren.

• RIVA beschrijft eisen, maar geen vertaalslag naar concrete guardrails in pipelines/templates, geen duidelijk beleid voor service mesh usecases (wel/niet toegestaan)

• Onzekerheid over domeinscheiding, bijv. wel intradomein, niet tussen domeinen (wens), maar nog niet uitgewerkt of afgedwongen.

• Beperkte security scanning (alleen Postman in beperkte mate).

• Uitzonderingen op verkeerssoorten (SFTP/AMQP), terwijl firewall vooral HTTPS ondersteunt.

• Geen netwerkvoorziening voor inspectie/offloading/scanning → platform moet zelf risico’s mitigeren.

• Analytics/rapportages/dataproducten
• Logging/monitoring over meerdere tools.
• End-to-end realtime analytics ontbreekt.
• Beperkte eenduidige audit-friendly reporting.

3.2 Technisch

• Capaciteit & performance
• VM gebaseerd; monolithisch, niet schaalbaar. Wel hoge beschikbaarheid. Iedere oplossing is geclusterd over twee VMs. Geen API isolatie. Wel cloud-ready/container-ready.
• RabbitMQ is geclusterd over drie VMs. Wel cloud-ready/container-ready.

• Schaalbaarheid en resiliency zijn minder flexibel dan in OpenShift vanwege het containerized karakter.

• Versies & configuratie
• Closed source MuleSoft als primaire integratie-engine.
• Geen “open source first” implementatie/alternatieven in gebruik.
• LCM is geborgd in 8-wekelijkse controle momenten op upgrades. Vendor gedreven. Configuratie management via Ansible. 
• Monitoring

• Monitoring/observability verloopt via CheckMK op VM, splunk voor logging en de Mulesoft built-in monitoring. De monitoring is niet uniform over de keten.

• Centraal overkoepelend observability-concept (metrics/logs/traces) ontbreekt.

• Beperkte mogelijkheid om managementinformatie en audit evidence near real time te leveren.

• Beheerprocessen & incidenthistorie
• Beheerders zijn een bottleneck door handmatige deployments, beperkte self-service, beperkte delegatie van verantwoordelijkheden
• Meer kans op menselijke fouten (handmatige stappen), langere doorlooptijden (wacht op beheer), inconsistenties tussen teams (verschillende werkwijzen)
• Hoge afhankelijkheid van netwerk/infrastructuur voor “secure traffic handling”; ons oplossend vermogen ligt niet (volledig) binnen onze eigen invloedssfeer met risico op lange doorlooptijden.

3.3 Organisatie

• Rollen & bezetting
  • PO, Tech Lead, Solution Architect, Platform Engineers (Gateway/MFT/Integratie).
  • Platformteam opereert primair als beheer- en deployment team. Toegang tot de bouwstraat en platform zijn beperkt tot beheerders en team blauw. Omgevingen zijn nog niet ingericht op self-service enablement.
• Kennisniveau & bijscholing: aanwezig
  • MuleSoft/ESB beheerkennis aanwezig
  • Eerste ervaring met Azure CI/CD aanwezig (team blauw deployments, postman tests).
• Kennisniveau & bijscholing: ontbreekt of beperkt aanwezig
  • OpenShift/container platform beperkt aanwezig
  • Service mesh governance en enforceable policies onduidelijk
  • Security testing in bouwstraat is beperkt
  • Observability is beperkt, niet end-to-end (metrics/logs/traces, audit dashboards).
  • Open source integratie frameworks en beheer daarvan (basis integratie ontbreekt).

4. Doelarchitectuur Platform

• Edge: API Gateway + WebApplication Firewall
• Integratie laag:
• Enterprise Integratie (IPaaS): enterprise grade orkestratie/mediatie voor bedrijfskritische flows.
• Basis Integratie (IF): open source framework voor generieke koppelingen.
• MFT: stand alone product, declaratieve flows, chaining, AV/DLP hooks, DMZ terminatie, audittrails.
• Observability: OTEL traces, exporteerbare audits.
• CI/CD: GitOps, TAP straat leidend, security gates, SBOM publicatie.
• Platform: OpenShift (operators, autoscaling), network/egress policies, policy‑as‑code.
• Raakvlakken: Data/Analytics, IAM, Netwerk/DMZ/DNS, OpenShift/K8s, Monitoring/SOC, CI/CD tooling.

5. 5‑Jaren Roadmap

De roadmap voor het Integratie 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 Integratie
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) – Evaluatie & Onderzoek, OpenShift, MFT, Observability en Gateway
2. Jaar 2 (2027) – Migratie & Levering, OpenShift, MFT, Observability en Gateway
3. Jaar 3 (2028) – Optimalisatie & Integratie, dienstverlening in DC 3.0
4. Jaar 4 (2029) – Innovatie & Automatisering, AI positionering en CD/CD
5. Jaar 5 (2030) – Definitie Integratie Capabilities in Analytics platform

Jaar 1 — Evaluatie & Migratie (2026)

• OpenShift fundament
• Onboarding bestaande toolstack op OpenShift; GitOps‑enablement; basis observability.
• Basis Integratie (IF)
• Verkennend marktonderzoek; Proof‑of‑Concept; keuze van launching customer.
• Edge Integratie (AGW)
• Proof of Concept noord‑zuid verkeer; portal v1; self‑service adoptie ≥ 25%.
• MFT
• Verkennend marktonderzoek (no/low code); PoC met DMZ/scanning.
• Observability
• Marktonderzoek E2E‑dashboarding; PoC OTEL tracing/correlatie.
• Security‑by‑Design
• Basisgates in CI/CD: SAST/SCA/DAST, SBOM generatie, DPIA gates op kritieke stromen; start patchcadans en CVE SLA’s.
• MQ standaarddienst (MKS)
• Oriëntatie toekomstige teaminrichting; planning overdracht.
• Netwerk/NGFW
• Formele verzoeken tot uitbreiding standaard dienstverlening (L4 detectie, pakket scanning, grote bestanden).

Jaar 2 — Opschaling & Stabilisatie (2027)

• Edge Integratie
• In productie; lessons learned en verbeterslag; policy‑as‑code guardrails.
• MFT
• Launching customer live; beleid en templates; budgettering voor volwaardige dienst.
• Observability
• Near‑real‑time dashboards; audit exports; trace coverage ↑.
• SRE operating model
• SLO’s/SLI’s per dienst/tier; DR tabletop + gold keten DR test; error budgets in gebruik.
• Self‑service adoptie
• ≥ 70%; portal hardening; onboarding lead time omlaag.
• MQ standaarddienst
• Kennis‑ en technische overdracht naar dedicated team; SLO’s vastgesteld.
• Netwerk/NGFW
• Doorvoering verzoeken; DDoS/WAF profielen afgestemd.

Jaar 3 — Optimalisatie & Integratie (2028)

• NextGen IPaaS
• RFP + PoC; selectie voorkeursoplossing; contractvoorbereiding (RAPNext).
• Basis Integratie (IF)
• Volwaardige productie; uitfasering oude koppelingen; lessons learned voor doorontwikkeling.
• Edge Integratie
• Volwassen edge diensten; policy coverage ↑; change failure rate ↓.
• MFT
• Procurement afronding (indien nodig); uitfasering oude MFT constructies.
• Security/Compliance
• Patchcompliance op streefniveau; CVE SLA’s aantoonbaar; audit readiness.
• FinOps
• Show/chargeback; usage export/tagging; optimalisatie backlog.

Jaar 4 — Innovatie & Automatisering (2029)

• Automatisering
• IPaaS als automation suite (workflow/RPA); >70% repeterende platformtaken geautomatiseerd (Ansible + GitOps).
• NextGen IPaaS
• Productie name; ingestroomde workloads; exit strategie oude componenten gestart.
• AI‑gedreven orkestratie & governance
• AI assists in ontwerp/operations; geïntegreerde AI/data‑governance monitoring.
• MFT‑vernieuwing
• Declaratieve flows standaard; certificaat lifecycle volledig geautomatiseerd; chaining/DMZ patronen met audittrails.
• Guardrails & PoC’s
• Verdere standaardisatie (golden paths); uitbreiding self‑service templates.

Jaar 5 — Definitie Integratie Capabilities in Analytics platform (2030)

• • Uitfasering & lifecycle
    • Oude omgevingen volledig uit; lifecycle planning geborgd; contracten/exit strategieën getoetst.
  • Security posture
    • Exceptions naar ~0; bedreigingsmodellen geactualiseerd; hercertificeringen; continu audit klaar.
  • Platformdoelbeeld
    • E2E observability maximaal; portal volwassen; continuous improvement via QBR/architectuurboard.

6. Governance, Organisatie & Beheer

• Personele bezetting (indicatief, naar FTE toe te snijden)
• 1× PO, 1× Tech Lead, 2–3× SRE, 3–5× Platform Engineers (Gateway/MFT/Integratie), 1× SecOps liaison, 1× Developer Advocate, 0.5–1× FinOps.
• Sturing & besluitvorming
• Intake/prioritering; PR-/CAB‑gates; exception proces (tijdgebonden); audit evidence verplicht (as built, runbooks, testverslagen).
• QBR’s met leverancier (RAPNext) en maandelijkse KPI rapportages.
• Servicelevels (tiers)
• Beschikbaarheid/MTTR per tier (24×7 voor enterprise kritisch), onboarding lead time, policy coverage, patch SLA’s, audit readiness.

7. Security & Compliance

• BIO: voldoen aan NIS2 en BIO 2.0
• Exceptions: sturen op zo min mogelijk excepties
• Certificaten: Gebruik maken van ACME zodra dit operationeel is.

8. Risicoanalyse, afhankelijkheden & Mitigatie

• Openshift fundament: Afhankelijkheid met Infra. Bij uitblijven van beschikbaarheid vanuit Infra ontstaat het risico dat de ELA van de huidige leverancier moet worden verlengd. Potentieel hogere kosten ten gevolg bij ontbreken van passend alternatief. Mitigatie door te sturen op prioritering van oplevering van Productie omgeving.
• NextGen IPaaS: Afhankelijkheid met afdeling Netwerken. Beschikbaarheid van afdeling Inkoop voor NextGen IPaaS bouwblok. Bij uitblijven van beschikbaarheid ontstaat het risico dat de ELA van de huidige leverancier moet worden verlengd. Potentieel hogere kosten ten gevolg bij ontbreken van passend alternatief. Mitigatie door te sturen op prioritering van Inkoop analyse voor nieuwe IPaaS.
• Basis- & Edge integratie: Afhankelijkheid met OSR. Vinden van OSR launching customer voor Proof of concepts van de basis- en edge integratie. Bij uitblijven van launching customer ontstaat risico dat toegezegde oplossingen later in de tijd worden opgeleverd, wat ten koste kan gaan van de geloofwaardigheid om te kunnen innoveren. Het niet hebben van basis- en edge integratie kan ten gevolg hebben dat OSRs hun eigen plan trekken en eigen oplossingen decentraal deployen (SVM als recent voorbeeld). Mitigatie is tijdig het gesprek aangaan met OSRs bij ontwikkeling van nieuwe projecten van de OSRs, om in samenwerking de basis- en edge integratie diensten op te zetten.
• MFT: Afhankelijkheid met IVP management. Budgetruimte voor beter passende MFT binnen afdeling IVP. Risico is dat OSRs dure maatwerk oplossingen inkopen om hun specifieke usecase te kunnen realiseren (LOL als recente voorbeeld). Mitigatie door geïnformeerd te blijven over lopende projectbehoeften en diens budget mogelijkheden, zodat samen gekeken kan worden naar een passende oplossing. 
• MQ Standaarddienst: Afhankelijkheid met IVP management. Managementbesluit rondom borging van MQ en overdrachtsmogelijkheden voor het doel-team. Risico is een groeiende, half-beheerde, gesegmenteerde MQ omgeving door groei complexer wordt zonder kennisopbouw van een dedicated team. Mitigatie is z.s.m. een plaatsvervangend (ad interim) team of samenwerking te starten tussen de bestaande MQ gebuikers (DataSuite, Integratie Platform en WM).
• Netwerk:  Afhankelijkheid met afdeling Netwerken. Vindbaarheid, responsiviteit en budgetmogelijkheden van beslissingsbevoegde binnen afdeling Netwerken leidt tot langere doorlooptijden in het vinden van een passende oplossing. Risico is continuering van de huidige, relatief onveilige en "permanente" workaround voor ontsluiting van TCP verkeer. Mitigatie is escalatie naar de juiste beslissingsbevoegde. 
• Contract/leverancier (RAPNext) → KPI’s en QBR’s, boetes/incentives, exit strategie en overdraagbaarheid geborgd.

9. KPI’s & Succesfactoren

• Self‑service adoptie: ≥25% (2026), ≥70% (2027), daarna continu stijgend.
• Platform uptime: ≥99,9%.
• Security: patching loopt gelijk met organisatie en hooguit n-2; afwijkingen op RWS security beleid worden in excepties tot een minimum beperkt.
• Governance: auditbevindingen (BIO/AVG) ≤ 2 per jaar.
• Klant tevredenheid: subjectieve beoordeling vanuit klanten tonen een stijgende lijn in diensttevredenheid over de door Integratie platform geleverde diensten (en producten).

10. Evaluatie & Bijstelling

• Halfjaarlijkse technische review: vaststellen in hoeverre documentatie up-to-date is.
• Jaarlijkse gebruikersenquête: klanttevredenheid enquête bij bestaande klanten van het Integratie Platform, om daarmee feedback te verzamelen ter verbetering van de dienstverlening.
• Tweejaarlijkse marktverkenning: herijking IPaaS/IF/AGW (incl. soevereine producten), met een update advies als input voor de roadmap.
• Roadmap‑update: Roadmap met input van marktverkenning is afgestemd met Architectuurboard en Stuurgroep.
• DR & audit: jaarlijkse backup/restore oefening; 2027 volledige DR test keten.