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:
- 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.
- De release op gestructureerde wijze inbrengen in het Afsprakenstelsel en de productieversie van het netwerk.
- volgens de planning;
- 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 op basis van het advies van het Operationeel Beraad en bij een koppelvlakrelease ook op basis van advies van het Leveranciersoverleg. In het geval van een koppelvlakrelease stelt het Leveranciersoverleg een releasemanager/productowner aan ;
- De releasemanager en productowner coördineert de totstandkoming van de release
- Het Operationeel Beraad toetst of een RFC past in de architectuur van het stelsel. Het Operationeel Beraad brengt advies uit over de RFC en samenstelling van een release aan het Tactisch Beraad.
- Het leveranciersoverleg stelt een advies op ten aanzien van de inhoud van een koppelvlakrelease, de daarbij horende prioriteit en de releasemanager/ productowner voor een koppelvlakrelease. Het leveranciersoverleg is verantwoordelijk voor de backlog rond koppelvlak RFC's, de aangestelde product owner beheert deze backlog met input uit het LO
- Beheerorganisatie:
- De changemanager is verantwoordelijk dat het proces change en release wordt uitgevoerd volgens de procesbeschrijving. De changemanager actualiseert de procesbeschrijving en coördineert de verschillende stappen in het proces.
- De changemanager organiseert de validatie aan de hand van een demonstratie van de deelnemers van de goede werking van de interoperabiliteit tussen de deelnemers.
- De jurist, security officer en stelstelarchitect leveren een bijdrage met betrekking tot het uitvoeren van een risico- en impactanalyse op de RFCs.
- Een RFC kan door een stakeholder worden voorbereid en ingebracht worden voor behandeling. De indiener van een RFC zorgt voor een motivatie en draagvlak waarom een RFC nodig is.
Overzicht processtappen
Toelichting processtappen
1a. Opstellen RFC | |
|---|---|
Input | Het verzoek van een RFC kan door een stakeholder worden gemeld. Denk hierbij aan de governance, het leveranciersoverleg en de beheerorganisatie. Een RFC kan verschillende aanleidingen hebben, zoals:
|
Activiteit | De changemanager 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 zogenaamde penvoerder. Hij of zij is het aanspreekpunt voor de RFC en organiseert de activiteiten om de RFC klaar te maken voor behandeling door de governance. Mocht bij het opstellen blijken dat de RFC impact heeft op het koppelvlak dan wordt het Proces realisatie koppelvlak wijzigingen gevolgd. Een RFCs bevat minimaal:
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 changemanager aan wanneer de RFC gereed is voor de behandeling door de Governance. De changemanager organiseert de toetsing op informatiebeveiliging en juridica door de Beheerorganisatie en agendeert de RFC voor behandeling in het Operationeel Beraad. |
Output | Opgestelde RFC |
Wie? |
|
1b. 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 |
|
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. De stelselarchitect bepaalt de impact op de architectuur en de conformiteit ten aanzien van de architectuurprincipes. |
Output |
|
Wie? |
|
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. Het Operationeel Beraad stelt vast of het wel/geen koppelvlakrelease is. |
Output | Advies over de RFC als voorbereiding voor de besluitvorming door het Tactisch Beraad. |
Wie? |
|
4. Besluiten over RFC's | ||
|---|---|---|
Input | RFC's met advies Operationeel Beraad | |
Activiteit | De RFC wordt samen met het advies van het Operationeel Beraad doorgeleid naar het Tactisch Beraad. Indien de verzameling bestaat uit administratieve RFC's dan zal de changemanager die aanbieden in een releasebundel. 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 van een betreffend jaar. De koppelvlak RFC's worden los aangeboden en komen na goedkeuring op de backlog van de leveranciers | |
Output |
| |
Wie? |
| |
5. Plaatsten van koppelvlak RFC op backlog realisatie | |
|---|---|
Input | Positief besluit mbt koppelvlak RFC |
Activiteit | Het leveranciersoverleg bepaalt aan de hand van de eigen capaciteit en behoeft en marktpotentieel welke koppelvlak RFC's wanneer gerealiseerd worden. Ze informeren het Tactisch Beraad hierover wat op de backlog staat en wat daarbij de prioriteit van realisatie is. Zodra het leveranciersoverleg besloten heeft dat een RFC geïmplementeerd wordt wordt dat doorgegeven aan de changemanager in verband met het verwerken van de aanpassingen in het afsprakenstelsel. |
Output | Backlog en prioriteitsstelling en inzicht welke items in een volgende release ingepland zijn. |
Wie? |
|
6. Verwerken release in het Afsprakenstelsel | ||
|---|---|---|
Input | Vastgestelde release door het Tactisch Beraad. | |
Activiteit | De Beheerorganisatie verwerkt de wijzigingen in de het Afsprakenstelsel. Bij administratieve RFC's is het moment na de vaststelling door het Tactisch Beraad. Indien er een implementatietermijn van toepassing is zal die worden aangegeven in het afsprakenstelsel zelf. Bij koppelvlak RFC's is het moment zodra de wijziging is ingepland voor realisatie. De penvoerder of Beheerorganisatie voert een review uit of de wijziging correct is doorgevoerd aan de hand van het 4 ogen principe. Na de review publiceert de Beheerorganisatie een nieuwe versie van het afsprakenstelsel | |
Output | Gepubliceerde nieuwe versie van het afsprakenstelsel | |
Wie? |
| |