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 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:
|
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 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? |
|
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 |
|
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 |
|
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. |
Output | Advies over de RFC als voorbereiding voor de besluitvorming door het Tactisch Beraad. |
Wie? |
|
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 |
| |
Wie? |
| |
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.
| |
Output |
| |
Wie? |
| |
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? |
| |