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.
Nog niet bevestigd door een mens. Eigenaar: vdo89. Bron in de atlas
De dienstverlening loopt via één dienstbeschrijving per toepassing: het applicatieteam legt vast wat zijn toepassing
nodig heeft, en het platform levert en houdt de inrichting daarmee in overeenstemming, van de eerste levering tot de
beëindiging. Een team combineert uit het aanbod wat het nodig heeft en kiest een dienstprofiel, dat bepaalt welke
voorzieningen voor gebruik en continuïteit erbij horen.
Waarom zo
Een betere aanvraagroute verkort het invullen, niet de overdrachten. Door levering en beheer te sturen vanuit één
goedgekeurde beschrijving, met vooraf afgesproken varianten en geautomatiseerde controles, vervalt de herhaalde
beoordeling per beheerdomein en blijft de omgeving ook na oplevering kloppen. De dienstprofielen maken zichtbaar wat een
continuïteitskeuze vraagt, in plaats van dat ieder team zijn eigen beheerafspraken samenstelt.
De concrete reactietijden per profiel zijn een voorstel; de hersteltijd en het herstelpunt zelf volgen per toepassing
uit de bedrijfsimpactanalyse. Wie het profiel kiest, het team of de proceseigenaar, vraagt nog een besluit.
In de dienstbeschrijving legt het applicatieteam vast wat zijn toepassing nodig heeft, niet hoe: software, capaciteit, gegevensdiensten, verbindingen en continuïteit, en daarnaast eigenaar, kostenplaats, gegevensclassificatie en het gekozen dienstprofiel. Geheimen staan er niet in; die staan in het geheimenbeheer.
Levering en beheer volgen de vier gangbare principes van GitOps. De gewenste inrichting is declaratief beschreven en wordt onveranderbaar bewaard in versiebeheer, op een beschermde hoofdtak die alleen beoordeelde en ondertekende wijzigingen aanneemt. De uitvoerende voorzieningen halen haar automatisch op en vergelijken haar doorlopend met de werkelijke toestand; een afwijking herstellen zij zelf waar dat is toegestaan, anders melden zij haar.
Toelichting
Zo is iedere wijziging herleidbaar tot een goedgekeurde versie; de toetsen Levering via het vaste pad en Wijziging en beëindiging via de dienstbeschrijving tonen dat aan. Afgewezen: een betere aanvraagroute, die het invullen verkort maar niet de overdrachten, en een los opleverscript per team, dat na de levering niet ziet dat de omgeving afwijkt.
Teams leveren en wijzigen binnen de vooraf toegekende ruimte zelf een complete omgeving: via het ontwikkelaarsportaal of, als zij hun levering vanuit software aansturen, via beheerinterfaces of configuratiebestanden. De regels voor toegang, capaciteit en gegevensgebruik gelden bij iedere ingang, ook bij direct gebruik van het versiebeheer.
Afspraken over verbindingen, bijvoorbeeld dat een toepassing onderhoudsgegevens uit een bestaand systeem mag lezen, liggen vast in de dienstbeschrijving. Bij een volgende versie of een verhuizing blijven ze aan de toepassing verbonden en toetst het platform ze opnieuw; alleen het gedeclareerde verkeer slaagt.
Voor veelvoorkomende diensten bepalen de betrokken beheerders en eigenaren vooraf welke keuzes verantwoord zijn. Iedere variant heeft een eigenaar en een versie.
Binnen een vooraf afgesproken variant vraagt een wijziging geen nieuwe beoordeling door ieder beheerdomein afzonderlijk, mits de geautomatiseerde controles slagen op precies de vastlegging van die wijziging in versiebeheer. Een nieuwe verbinding of een afwijking met andere risico’s vraagt wél een inhoudelijke afweging door een ander dan de aanvrager, binnen dezelfde levering.
Via de dienstbeschrijving gelden ook de voorgeschreven beveiligingsinstellingen, als verwijzing naar een gepubliceerde versie van de standaardinrichting. Het platform controleert na oplevering of de omgeving daaraan blijft voldoen.
Iedere uitvoerende voorziening heeft een eigen taak en begrensde rechten, en iedere instelling wordt door precies één voorziening bepaald. De inventaris registreert de feitelijke toestand bij dezelfde dienst, los van de gewenste inrichting.
Toelichting
Dit is de basis voor de invulling van het SAK Technical Compliance Management; de acceptatieproef voor bewijs en naleving toetst het bewijs per maatregel.
Ook de platformstandaard zelf staat onder beheer: iedere versie heeft een eigenaar, controles en een termijn waarbinnen verouderde varianten worden vervangen. Een verbetering wordt eerst beproefd en daarna ook voor bestaande afnemers ingepland.
Een team dat een omgeving met een database afneemt, kan haar ook na de oplevering wijzigen, herstellen en beëindigen. De goedgekeurde dienstbeschrijving verbindt zijn vraag met de uitvoering door de afzonderlijke beheerdomeinen; de uitvoerende voorzieningen behouden ieder hun eigen bevoegdheden, en hun terugmeldingen vormen samen de status van de dienst.
Ontbreekt bij een levering nog een onderdeel, bijvoorbeeld de netwerkverbinding terwijl de database al bestaat, dan krijgt de dienst de status ‘Onvolledig’ en ziet de afnemer welke stap wacht en wie die afhandelt. Waar dat veilig kan, hervat het platform vanaf die stap zonder dubbele onderdelen; anders volgt herstel of een nieuwe beoordeling.
Een storing in het portaal legt alleen die ingang stil. De andere ingangen en de bestaande toepassingen blijven werken zolang hun eigen voorzieningen beschikbaar zijn.
Urgente wijzigingen lopen via een noodroute: een vooraf ingerichte beheerroute buiten de gewone aanvraagroute, met dezelfde begrenzing van rechten. Ieder gebruik ervan wordt opgenomen.
Voor een geregistreerde noodmaatregel schort het platform het automatische herstel naar de vastgelegde inrichting tot een einddatum op, zodat de maatregel niet ongemerkt wordt teruggedraaid. Na het incident neemt beheer de maatregel op in de gewenste inrichting of maakt haar ongedaan.
Bij beëindiging verdwijnen overbodige verbindingen, identiteiten en rechten. Gegevens en back-ups, ook momentopnamen en kopieën, volgen hun bewaartermijnen en worden pas met de vereiste toestemming verwijderd. De dienst wordt pas administratief afgesloten als ook de resterende verplichtingen een eigenaar hebben.
Het aanbod bestaat uit standaarddiensten voor het uitvoeren van toepassingen, rekenkracht, gegevens, koppelingen en ICT-voorzieningen op locatie, en uit gemeenschappelijke diensten die bij iedere afname horen: het ontwikkelaarsportaal, applicatie-identiteit en geheimenbeheer, en gecontroleerde softwarelevering. Een team combineert wat zijn toepassing nodig heeft en kiest daarbij een dienstprofiel.
Bij de start is alleen beschikbaar wat in de eerste levering zit; de overige diensten volgen het groeipad. Tot een dienst is opgeleverd, beschrijft zij het doel en is zij nog niet af te nemen.
Toelichting
De voorbeelden bij de diensten en gebruikssituaties verduidelijken het aanbod en zijn geen vastgestelde RWS-projecten. Zie het verloop van de invoering.
Werkprocessen vragen verschillende beschikbaarheid: een testomgeving is meestal opnieuw op te bouwen, maar een lange onderbreking van een kritieke productietoepassing kan grote gevolgen hebben. Afgewezen: overal de hoogste beschikbaarheid, wat duur is, of overal alleen een back-up, wat kritieke processen te lang kan laten stilliggen. Reguliere en bedrijfskritische productie gelden pas na vrijgave voor het betreffende profiel; zie vrijgave voor productie.
De proceseigenaar bepaalt op basis van de gevolgen voor het werk hoe lang een onderbreking mag duren en welk gegevensverlies aanvaardbaar is; volgens het SAK Disaster Recovery is deze bedrijfsimpactanalyse de basis voor herstel. Platformbeheer vertaalt de behoefte naar inrichting en kosten, en diensturen, ondersteuning, onderhoudsvensters en bewaartermijnen liggen vóór gebruik vast.
Toelichting
Per profiel liggen de kosten, de ondersteuning door het platform en de verantwoordelijkheid van het team vast.
Het applicatieteam kiest het dienstprofiel op grond van de bedrijfsimpactanalyse van de proceseigenaar en legt het vast in de dienstbeschrijving.
Toelichting
Over wie het profiel kiest, bestaan twee lezingen: het applicatieteam kiest het, of de proceseigenaar kiest het naar de gevolgen voor het werk. Beide passen als de proceseigenaar de toegestane onderbreking en het aanvaardbare gegevensverlies bepaalt en het team het profiel kiest dat daarbij hoort; wie beslist als zij het niet eens zijn, ligt nog niet vast.
De afspraken van een profiel gelden voor de volledige toepassing: herstel maakt haar weer bruikbaar met de gegevens en verbindingen die zij nodig heeft. Hangt zij af van een bestaande gegevensdienst, dan moeten ook die verbinding en dienstverlening bij het profiel passen, net als gedeelde voorzieningen die beide cellen kunnen raken, zoals de RWS-bronnen van het identiteitsbeheer, de naam- en tijdvoorziening en het vlootbeheer.
Toelichting
Een tweede applicatieomgeving levert weinig continuïteit op als beide dezelfde onbeschikbare gegevensbron nodig hebben.
Plaatsingsoptie zelfstandig op locatie legt bij een profiel vast welke taken zonder centrale verbinding doorgaan en hoelang. Een meetvoorziening kan bijvoorbeeld lokaal blijven verzamelen en later doorsturen; dat vraagt lokale capaciteit en passende toegang.
Dienstprofielen zijn geen beveiligingsniveaus. De beveiliging volgt de risico’s voor werk en gegevens, in lijn met BIO2, dat geen vaste basisbeveiligingsniveaus meer kent en de nadruk legt op risicomanagement; ook een ontwikkelomgeving krijgt daarom passende bescherming en begrensde toegang.