Skip to end of metadata
Go to start of metadata

Het Afsprakenstelsel Elektronische Toegangsdiensten is dynamisch. Het change en releaseproces beschrijft het proces van het ontstaan van een wijziging, de toetsing en de besluitvorming en het verwerken van de wijziging in het Afsprakenstelsel (AS). Het Proces implementatie koppelvlakrelease beschrijft de implementatie van een change in het  Netwerk (voor Elektronische Toegangsdiensten) door een betrokken partij.

Indien een wijziging de juridische of technische strekking van het Afsprakenstelsel niet aantast, dan MAG de wijziging direct worden doorgevoerd in het Afsprakenstelsel. Waaronder begrepen, maar niet beperkt tot herstructureren van content, corrigeren van taal- en stijlfouten, onderhoud aan hyperlinks en labels. 

Doelstelling

De doelstelling van het change- en releaseproces is tweeledig:

  1. Op transparante en zorgvuldig wijze besluiten over welke wijzigingen wel en niet worden doorgevoerd. Alle belanghebbenden moeten invloed kunnen hebben op de wijziging van het Afsprakenstelsel.
  2. De release op gestructureerde wijze inbrengen in het Afsprakenstelsel en de productieversie van het netwerk.
    1. volgens de planning;
    2. met minimale verstoringen voor Elektronische Toegangsdiensten.

Verantwoordelijkheden

In het change- en releaseproces worden de volgende verantwoordelijkheden onderscheiden:

  • Het Strategisch Beraad is verantwoordelijk voor het schetsen van strategische kaders voor de inhoudelijke doorontwikkeling van het Afsprakenstelsel Elektronische Toegangsdiensten in het meerjarenplan;
  • Het  Tactisch Beraad besluit over de inhoud van de releases en de implementatie aan de hand van de business case en het advies vanuit het Operationeel Beraad. In het geval van een koppelvlakrelease stelt het Tactisch Beraad stelt een releasemanager aan; 
    • De releasemanager coördineert de totstandkoming van de releaseplanning en bewaakt de voortgang. De releasemanager is verantwoordelijk voor het uitvoeren van de compensatieregeling. 
  • Het  Operationeel Beraad toetst of een RFC implementeerbaar is en/of het past het in de architectuur en AS. Het Operationeel Beraad brengt advies uit over de RFC en samenstelling van een release aan het Tactisch Beraad. 
  • Beheerorganisatie: 
    • De change manager is verantwoordelijk dat het proces change en release wordt uitgevoerd volgens de procesbeschrijving. De change manager actualiseert de procesbeschrijving en coördineert de verschillende stappen in het proces.
    • De technisch beheerder heeft de verantwoordelijkheid om de testresultaten bij een release te valideren;
    • De jurist, security officer en stelstelarchitect zijn verantwoordelijk voor het uitvoeren van een risico- en impactanalyse op de RFCs.
     
  •  Een RFC kan door een betrokken partij worden voorbereid en ingebracht worden voor behandeling.  Dit zijn de volgende partijen: Deelnemer, BSNk, Beheerorganisatie en Governance (eventueel via een werkgroep). De indiener van een RFC zorgt voor een motivatie en draagvlak waarom een RFC nodig is. Bij een aanpassing of uitbreiding  die een implementatie vergen en/of zwaardere eisen stellen aan een deelnemer bevat de motivatie een businesscase.  Daarnaast moet een RFC die ontstaat door een behoefte vanuit de markt of overheid moet een sponsor hebben. De sponsor is verantwoordelijk voor het creëren van draagvlak binnen de Governance.
  • Een betrokken partij is verantwoordelijk voor het uitvoeren van een impactanalyse op de RFC's en het implementeren van vastgestelde releases.

Overzicht processtappen


Toelichting processtappen

1a. Opstellen RFC

Input

Het verzoek van een RFC kan door een betrokken partij in het Afsprakenstelsel worden gemeld. Dat zijn deelnemers, BSNk, Beheerorganisatie en de Governance (via een ingestelde werkgroep). Een RFC kan verschillende aanleidingen hebben, zoals:

  • Correcties: denk aan tekstuele correcties en patches. Het doorvoeren van correcties heeft geen impact op de inhoud/werking van het Afsprakenstelsel.
  • Issues: denk aan een (deel van een) functionaliteit die in de praktijk niet goed toepasbaar blijkt. Het oplossen van issues heeft impact op de inhoud/werking van het Afsprakenstelsel.
  • Nieuwe functionaliteit: het accepteren van nieuwe functionaliteiten heeft impact op de inhoud/werking van het Afsprakenstelsel.
  • Regelgeving: zorgen dat het AS in lijn blijft met nationale en Europese regelgeving.

Activiteit

De change manager maakt naar aanleiding van het verzoek een dossier voor de RFC aan en deze krijgt een uniek kenmerk. De eigenaar van de RFC is de persoon die het verzoek heeft gedaan. Deze persoon is ook verantwoordelijk voor het uitwerken van de RFC (penvoerder)  en het verzorgen van voldoende draagvlak om de RFC door deze door de Governance te geleiden.  

Een RFCs bevat minimaal:  

  • de beschrijving van de concrete gewenste wijziging
  • een beschrijving van de aanleiding/context,
  • de oplossingsrichting,
  • de globale impact per rol in het Afsprakenstelsel
  • de rechtvaardiging hiervan (toegevoegde waarde, business case). Deze business case moet gedragen zijn door de betrokken partijen. De penvoerder moet hiermee in staat zijn om deze in het Tactisch Beraad te motiveren.

De eigenaar van de RFC geeft zelf aan of de inhoud besloten of inzichtelijk is voor de betrokken partijen in de initiële fase. Zodra de RFC gereed is voor toetsing door de governance is deze inzichtelijk voor de betrokken partijen. Deze partijen hebben dan ook de mogelijkheid om voorafgaand aan de behandeling door de governance commentaar te leveren. De penvoerder geeft aan de change manager aan wanneer de RFC gereed is voor de behandeling door de Governance. De change manager organiseert de toetsing op informatiebeveiliging en juridica door de Beheerorganisatie en agendeert de RFC voor behandeling in het Operationeel Beraad.

Voor de wijzigingswensen die in behandeling worden genomen wordt een penvoerder benoemd welke verantwoordelijk is voor de totstandkoming van de bijbehorende RFC's. Eventueel kan het Tactisch Beraad hiervoor een werkgroep instellen.

Output

Opgestelde RFC

Wie?

  • Penvoerder RFC
  • Change manager

1b.  Optioneel: presentatie oplossingsrichting RFC van werkgroep door penvoerder

Input

Oplossingsrichting RFC vanuit een werkgroep

Activiteit

De penvoerder en/of sponsor presenteert de gekozen oplossingsrichting aan de leden van het OB met als doel deze te toetsen en te bediscussiëren.

Output

  • Verbeterde RFC
  • Draagvlak voor de RFC bij leden OB

Wie?

Penvoerder en/of sponsor

2.  Bepalen impact RFC door BO

Input

RFC

Activiteit

Vanuit de beheerorganisatie bepaalt de security officer en de jurist de RFCs op het gebied van security en privacy risico's. Bij complexe RFC's voert de stelselarchitect een review uit.

Output

  • Verbetervoorstellen gericht aan de penvoerder
  • Impact bepaald op het vlak van security en privacy (Actuele risicomatrix)
  • Eventueel impact bepaald door stelselarchitect
  • Agendering voor behandeling door OB

Wie?

  • Security officer
  • Jurist
  • Stelselarchitect

3.  Behandeling RFC door het Operationeel Beraad

Input

RFC getoetst door BO

Activiteit

Het Operationeel beraad stelt een advies op voor het Tactisch Beraad of een RFC implementeerbaar is en/of het past het in de architectuur en AS.

Output

Advies over de RFC als voorbereiding voor de besluitvorming door het Tactisch Beraad.

Wie?

  • Operationeel Beraad

4. Samenstellen release

Input

RFCs, Releasekalender, Jaarplan Tactisch Beraad

Activiteit

De changemanager maakt een voorstel voor een release aan de hand van een logische bundeling van RFC's en aan de hand van het jaarplan en de releasekalender.  Het einddoel is om met een inhoud van een release te komen die breed gedragen is door de leden van het Tactisch Beraad en de betrokkenen die de daadwerkelijke implementatie gaan doen.

Als de inhoud bekend is wordt de inhoud van de release gepresenteerd aan de leden van het Operationeel Beraad voor advies. Na het advies gaat het voorstel van de samenstelling van de release naar het Tactisch Beraad voor het vaststellen van de release.

Voor de RFC's in een koppelvlakrelease is de data genoemd in de implementatieplanning leidend.  Voor RFC's buiten een koppelvlakrelease kunnen er implementatietermijnen van toepassing zijn. In principe zijn er dan twee vaste momenten in het jaar om een RFC's geïmplementeerd te hebben: 1 juni en 1 december.

Output

  • Samengestelde release
  • Geactualiseerde releasekalender

Wie?

  • Change manager
  • Operationeel Beraad

5. Besluiten over release 

Input

Release met advies Operationeel Beraad

Activiteit

De release wordt samen met het advies van het Operationeel Beraad doorgeleid naar het Tactisch Beraad. Het Tactisch Beraad neemt een formeel besluit over de inhoud van de release en stelt een release manager aan.

Indien het Tactisch Beraad één of meer goedgekeurde RFCs eerder wil laten implementeren dan in de releaseplanning mogelijk is, dan kan er besloten worden tot invoering middels een spoedprocedure.

  • Bij toepassing van de spoedprocedure wordt een tussentijdse release gecreëerd die los staat van de releaseplanning.
  • Deze spoedprocedure wordt gebruikt wanneer het een zeer dringende wens in de markt betreft of een dreiging/kans in de omgeving van Elektronische Toegangsdiensten waarop gereageerd moet worden.

Output

Wie?

  • Change manager
  • Tactisch Beraad 

6. Verwerken release in het Afsprakenstelsel

Input

Vastgestelde release door het Tactisch Beraad. 

Activiteit

De Beheerorganisatie verwerkt de wijzigingen in de het Afsprakenstelsel . De penvoerder voert een review uit of de wijziging correct is doorgevoerd.

Na de review publiceert de Beheerorganisatie een nieuwe versie van het afsprakenstelsel

Output

Gepubliceerde nieuwe versie van het afsprakenstelsel

Wie?

  • Change manager
  • Penvoerder