Ontwerpkeuze
Zelfservice binnen vooraf afgesproken kaders
Rust op Twaalf dragende ontwerpkeuzes. Bevestigd door vdo89 op 26 september 2026. Bron in de atlas
- Vraag
- Hoe krijgt een team snelheid zonder onbeheersbare verschillen?
- Leidend
- ja
Principes
Delegeer handelingsruimte onder voorwaarden; organiseer eerst, automatiseer daarna; standaardiseer waar het kan.
Waarom niet eenvoudiger
Alles centraal beoordelen houdt de wachttijd in stand; teams volledig vrijlaten geeft varianten en onbeheerste risico’s.
Wat het oplevert
Beheerders keuren herhaalbare varianten vooraf goed. Een team kiest binnen die grenzen; de controles blijven gelden bij het portaal, de beheerinterface en versiebeheer.
Wat het vraagt
Het aanbod blijft bewust beperkt. Een nieuwe verbinding of afwijking met andere risico’s vraagt een inhoudelijke beoordeling door een ander dan de aanvrager.
- Lost op
- Uitgewerkt in
Onderwerpen die eruit volgen
De beheerde database als dienst
PostgreSQL met CloudNativePG als dienst in het applicatiecluster van het team, in een afgeschermd deel dat het platform beheert: waar de database staat, hoe zij uit sjabloon en dienstbeschrijving ontstaat, wie wat doet en hoe de dienst groeit.
Het vaste leverpad
Iedere levering doorloopt dezelfde acht stappen, van beschrijven tot overdragen, met een normtijd per stap en één leverstatus in versiebeheer. Een stap is pas gereed als het onderdeel werkt; een onvolledige levering blijft zichtbaar en wordt zonder dubbele onderdelen hervat.
Zonering en verkeersstromen
Het netwerk van een cel is verdeeld in zones met elk een eigen vertrouwensniveau. Verkeer tussen zones gaat alleen via de firewall en alleen langs vooraf vastgelegde, getoetste verkeersstromen; een team declareert zijn verbindingen en de zonecontrole toetst ze.
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.
De clusterdefinitie
Hoe een applicatiecluster uit de dienstbeschrijving ontstaat: het sjabloon met weinig keuzes, de onveranderbare velden, de koppeling met de werkervirtualisatie, de werkernetwerken en de route naar de opslag.
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.
Beoordelen en samenvoegen in versiebeheer
Versiebeheer is beschermd met ondertekende vastleggingen, een beschermde hoofdtak en twee beoordelaars naast de auteur. Binnen de vastgestelde varianten voegt alleen een samenvoegidentiteit automatisch samen; sjablonen en beleid nooit.
Rollen, groepen en rechten
Welke rollen er zijn, hoe rollen via groepen rechten worden, welke combinaties van rollen zijn uitgesloten, en hoe technische identiteiten en applicatie-identiteiten hun rechten krijgen.
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.
Catalogus en dienstsjablonen
De catalogus biedt teams gepubliceerde diensten met varianten, afspraken per profiel en documentatie. Iedere dienst en ieder sjabloon heeft een eigenaar en een versie; het aanbod groeit langs het groeipad.
De standaardinrichting
Het beleid dat het vlootbeheer op ieder applicatiecluster afdwingt en dat een team niet kan wijzigen: beleidspakketten, teamnaamruimten, beveiliging van werklasten, naleving en bewaking.
Dienstverlening
Eén dienstbeschrijving stuurt levering en beheer over de hele levensduur van een dienst; een team combineert uit het aanbod wat het nodig heeft en kiest een dienstprofiel voor gebruik en continuïteit.
Verhoging en intrekking
Het gewone werk vraagt geen verhoging. Bevoorrechte rechten zijn tijdelijk, per taak en door een ander goedgekeurd, en een ingetrokken toegang werkt binnen een vaste tijd nergens meer, ook niet in lopende sessies.
Herstel naar verstoring en dienstprofiel
Welke herstelbron en welk herstelpad bij welke verstoring horen, welke hersteldoelen per dienstprofiel gelden, en waarom overname door de andere cel iets anders is dan herstel uit een kopie.
Het portaal en de ontwikkelomgeving
Het portaal, Red Hat Developer Hub, dient voorstellen in en toont de voortgang, maar voert niets uit. Het draait met de ontwikkelomgeving op een eigen gehost portaalcluster, met rechten per team en begrensd verkeer.
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.