Ontwerpkeuze
Open standaarden en overdraagbare configuratie
Rust op Twaalf dragende ontwerpkeuzes. Bevestigd door vdo89 op 26 september 2026. Bron in de atlas
- Vraag
- Hoe blijft een latere overstap mogelijk?
- Leidend
- nee
Principes
Open source, tenzij; sluit aan op externe standaarden; bouw gelaagd op open standaarden; formuleer eisen onafhankelijk van de implementatie.
Waarom niet eenvoudiger
Eigen formaten en maatwerkkoppelingen zijn soms sneller gemaakt, maar maken koppelen, controleren en later overstappen duurder.
Wat het oplevert
Configuratie, applicatie-identiteit, koppelingen en softwareherkomst gebruiken open standaarden. Het daadwerkelijk overzetten naar een andere invulling wordt beproefd.
Wat het vraagt
Een standaardnaam alleen is geen bewijs van uitwisselbaarheid. Configuratie, gedrag en overstap moeten voor de gekozen oplossing worden getest.
- Lost op
- Uitgewerkt in
Onderwerpen die eruit volgen
Opbouw en beheer van de werkervirtualisatie
Het platformcluster met OpenShift Virtualization dat per cel de virtuele werkers en virtuele servers draagt: opbouw, softwarestapel en basislijn, inrichting vanuit code, beheer, naleving en taken.
Signalering en meldingen
Ieder cluster bewaakt zichzelf en meldt rechtstreeks aan de verantwoordelijke; het vlootbeheer meldt alleen wat van buitenaf moet worden vastgesteld. Drempels, normtijden en reactietijden per dienstprofiel bepalen wanneer en bij wie een melding aankomt.
Aanmelding en sessies
Hoe personen zich bij clusters, platformdiensten en apparatuur aanmelden: via de toegangsvoorziening van de eigen cel, met twee factoren, en met sessies en toegangsbewijzen die kort gelden.
Architectuurprincipes
De architectuurprincipes van RWS en de overheid waaraan het platform is getoetst, per bron en met hoe het platform ieder principe verwerkt, en de afwegingen waar principes met elkaar schuren.
Back-up per laag
Ieder onderdeel heeft een eigen back-up, zodat het consistent terug te zetten is: clusterobjecten en volumes, configuratiedatabases van besturingen, databases, geheimenbeheer, containerregistry en versiebeheer. Schema’s, buckets, meldingen en de softwarestapel liggen daarvoor vast.
De basisdiensten en hun plaatsing
Welke tien basisdiensten op het basisdienstencluster draaien, met welk product, hoe ze zijn ingericht en welke cel per dienst schrijft. Iedere cel heeft eigen exemplaren; alleen het versiebeheer is één voorziening voor de vloot.
Dienstbeschrijving en toetsing
De dienstbeschrijving is de enige invoer van een team. Een toetspijplijn in de opslagplaats Afnemers toetst ieder voorstel, langs iedere ingang, aan de geldende regels: rol, velden, capaciteit, zones en instemming.
Het datacenternetwerk van een cel
Iedere cel krijgt een eigen fabric op EVPN en VXLAN, met Cisco Nexus 9000-switches in NX-OS-modus en Nexus Dashboard als fabriccontroller. De fabric is dubbel uitgevoerd, wordt als code beheerd en met een vaste testset beproefd.
Uitrol van de gewenste inrichting
Het vlootbeheer rolt alleen ondertekende, beoordeelde inrichting uit Platform en Beleid uit, met één Argo CD in het pushmodel, begrensde projecten en identiteiten, en zet afwijkingen terug.
Ondertekening en herkomst
Een onafhankelijke besturing van het platform tekent resultaat, onderdelenlijst en herkomst, nooit de bouwtaak; iedere handtekening staat in een eigen transparantielogboek op het vlootcluster. Tot groeipadstap 2 met een bouwsleutel, daarna zonder langlevende sleutel.
Segmenten, adressen en aansluitingen
Hoe de fabric verkeer scheidt in segmenten, welke VLAN’s, VNI’s en adresreeksen daarbij horen, hoe servers en clusters aansluiten, en waar adressen en namen worden toegewezen en geregistreerd.
Wat de samenhang oplevert
Het aanbod is gericht op gedeelde behoeften van teams; de winst zit in de samenhang tussen de voorzieningen, van minder overdrachten tot gezamenlijk onderhoud.
Organisatie en middelen
Hoe het aanbod wordt gestuurd en wie waarvoor verantwoordelijk is, welke beheerafspraken de diensten dragen, hoe kosten en keuzeruimte zichtbaar worden en onder welke voorwaarden RWS SaaS afneemt.
De externe verkeersverdeling
De paren van NetScaler BLX per cel op het basisdienstencluster: hoe ze zijn opgesteld, beheerd, bijgewerkt en hersteld, welke capaciteit ze hebben en hoe ze worden bewaakt en beproefd.
Versies, onderhoud en levenscyclus
Welke versies de dienst gebruikt, hoe nieuwe versies via de toelatingsroute en uitrolgolven binnenkomen, hoe een nieuwe hoofdversie overgaat, en wat er gebeurt als de leverancier de stapel niet ondersteunt.
De eigen bewakingsvoorziening
Het eindbeeld is per cel een eigen bewakingsvoorziening buiten het platform en buiten het vlootbeheer, met vergrendelde logopslag, verkeersstromen, metingen van apparatuur en een langere historie. Zij komt in groeipadstap 2, vóór de vrijgave voor reguliere productie; tot dan geldt een uitzondering.
Productversies
De gekozen versie per product, met de ondersteuningsstatus en de technische grenzen waar het ontwerp rekening mee houdt. Versies zijn ondersteunde combinaties die de leverancier bevestigt.
Wat voor ieder onderdeel geldt
De regels die ieder onderdeel van het platform volgt: inrichting uit code, zelfstandig per cel, toegang op identiteit, alleen vrijgegeven software, logboeken naar het SOC, ondersteunde versies, beproefde draaiboeken en één eindverantwoordelijke.
Bestaande databases, koppeling en overgang
Het databasehotel van RWS blijft de voorziening voor bestaande toepassingen tot hun migratie. Een toepassing op het platform kan er een koppeling mee krijgen, en een bestaande database gaat pas over na controle, met de bron als terugvalpad.
Open standaarden
Welke open standaarden het platform per onderwerp volgt, zodat inrichting, gegevens en bewijs leesbaar blijven buiten het huidige product, en hoe het de standaarden van de lijst ‘pas toe of leg uit’ toepast.