Proces change en releasemanagement

Inhoudsopgave

Het Afsprakenstelsel Elektronische Toegangsdiensten is dynamisch. Het proces Change- en releasemanagement beschrijft het proces van het ontstaan van een wijziging, de toetsing en de besluitvorming en het implementeren door betrokken partijen in het Netwerk (voor Elektronische Toegangsdiensten)als verwerken van de wijziging in het Afsprakenstelsel (AS).

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.
1. volgens de planning;
2. zonder verstoring of waar dit niet mogelijk is met minimale verstoringen voor Elektronische Toegangsdiensten.

Taken en 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 voorgestelde RFC's op basis van advies van het Operationeel Beraad. Dit betreffen zowel administratieve wijzigingen als wijzigingen met implementatie-impact. Daarnaast besluit het Tactisch Beraad over een voorgestelde release, bestaande uit reeds goedgekeurde RFC’s met implementatie-impact, die door de releasemanager wordt voorbereid.
Het Operationeel Beraad toetst of een RFC kwalitatief van het juiste niveau is, past in de architectuurprincipes van het Afsprakenstelsel en brengt advies hierover uit aan het Tactisch Beraad.
Het Leveranciersoverleg beheert de backlog implementatie. Op deze backlog staan alle reeds goedgekeurde RFC's met implementatie-impact. Het Leveranciersoverleg stelt een advies voor het Tactisch Beraad op, op basis van de voorgestelde release die door de releasemanager is voorbereid. Verder faciliteert het Leveranciersoverleg het Afsprakenstelsel door een releasemanager en testmanager ter beschikking te stellen.
- De releasemanager coördineert de uitvoering van het onderdeel releasemanagement, in samenspraak met de testmanager en de changemanager. Hij bereidt de release voor, stelt een planning op en stemt af met betrokkenen.
- De testmanager coördineert de uitvoering van het onderdeel testen tijdens de implementatie door testcases beschikbaar te stellen. Hij bewaakt dat de testcases worden ingevuld en ingeleverd. Samen met de releasemanager, testmanager en changemanager worden de uitgevoerde testen gecontroleerd op volledigheid.
  Interoperabiliteit wordt getest door de betrokken Deelnemers door met de andere de betrokken Deelnemers, en waar nodig met andere ketenpartners en/of stakeholders (zoals Dienstverleners) te testen. Daarbij dienen de testen met het te verwachten resultaat positief te voltooien, waarbij het functioneren van niet gewijzigde functionaliteit waarborgen. De testresultaten worden centraal opgeslagen.
De Beheerorganisatie faciliteert het Afsprakenstelsel door een changemanager, een jurist, een security officer, een stelselarchitect en een product owner van het DevOps-team ter beschikking te stellen.
- De changemanager is verantwoordelijk voor het actueel houden van de procesbeschrijving Change- en Releasemanagement en coördineert de uitvoering van het onderdeel changemanagement.
- De jurist, security officer, stelstelarchitect, ketenbeheer en product owner van het DevOps-team beoordelen de RFC’s en voeren een risico- en impactanalyse uit, elk vanuit hun vakgebied.

1. Proces Changemanagement en bijbehorende processtappen

Eerste beoordeling wijzigingsverzoek
Input	Het wijzigingsverzoek kan door een stakeholder worden gemeld en 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. Een stakeholder kan bijv. een Dienstverlener en Deelnemer zijn.
Activiteit	Indien het een wijzigingsverzoek betreft met implementatie-impact neemt het Intake team contact op voor nadere informatie om een goede inschatting te maken voor een eerste beoordeling. Deze informatie wordt vastgelegd in een dossier waarin o.a. het volgende wordt opgenomen: 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 (business value). Deze business value moet gedragen zijn door de betrokken partijen. Het Intake team maakt eerste analyse rondom technisch impact / oplossingsrichting en weegt o.a. de business value en of er aansluiting is met de prioriteiten in het jaarplan eH. Wijzigingsverzoeken die administratief van aard zijn worden gemeld bij de Changemanager en volgen een verkorte route in het proces (zie stap 5a).
Output	Eerste beoordeling wijzigingsverzoek
Wie?	Indiener RFC Intake team Changemanager

Opstellen advies voor Leveranciersoverleg
Input	De eerste beoordeling wijzigingsverzoek door het Intake team.
Activiteit	De voorzitter van het Intake team stelt een advies op voor het Leveranciersoverleg en bespreekt het advies voor met de productmanager eHerkenning.
Output	Voorgesteld advies t.a.v. wijzigingsverzoek
Wie?	Voorzitter Intake team Product manager eHerkenning

Prioritering
Input	Advies t.a.v. wijzigingsverzoek
Activiteit	In het Leveranciersoverleg wordt het advies t.a.v. wijzigingsverzoek besproken waarbij gekeken wordt naar o.a. de business value, urgentie, beschikbare capaciteit en de vastgestelde prioriteiten in het jaarplan eH.
Output	Terugkoppeling (positief of negatief) op wijzigingsverzoek
Wie?	Betrokken Deelnemers Voorzitter Intake team Product manager eHerkenning

Terugkoppeling indiener
Input	Terugkoppeling op wijzigingsverzoek door Leveranciersoverleg
Activiteit	Wanneer het Leveranciersoverleg geen consensus bereikt over het ingediende wijzigingsverzoek bijv. onvoldoende business value of geen prioriteiten o.b.v. het jaarplan eH, zal er geen opvolging aan de RFC worden gegeven. Dit kan betekenen dat wijzigingsverzoek wordt afgewezen of geparkeerd of het dossier wordt aangehouden in analysefase tot een nader moment. De voorzitter van het Intake team neemt met de indiener hierover contact op. Wanneer er wel consensus is, wordt de indiener hierover ook geïnformeerd en wordt het wijzigingsverzoek verder uitgewerkt.
Output	Terugmelding naar indiener
Wie?	Voorzitter Intake team Indiener RFC

Uitwerken oplossingsrichting en/of RFC
Input	Eerste beoordeling op wijziging (administratief) of Positieve terugkoppeling op wijzigingsverzoek met implementatie-impact door Leveranciersoverleg
Activiteit	Wanneer het LO instemt met het advies wordt een schrijversteam opgesteld om het wijzigingsverzoek verder te analyseren en/of uit te werken (zie stap 5b. een RFC implementatie-impact). De RFC moet alle benodigde onderdelen bevatten zoals de beschrijving voor de benodigde veranderingen voor aanpalende systemen zoals de aggregator, simulator etc. en inclusief de beschrijving van testcases om de uiteindelijke implementatie soepel te laten verlopen. Dit gebeurt in nauw overleg met de indiener. Wanneer het wijzigingsverzoek een administratieve aard heeft, stelt de indiener zoveel mogelijk de RFC op voorzien van een tekstuele voorstel. De Changemanager zorgt voor het verdere vervolg van de RFC in het proces (zie stap 5a. een administratieve RFC). Zodra een RFC uitgewerkt is, reviewen verschillende experts van de Beheerorganisatie waarbij zij de risico’s en impact voor hun vakgebied bepalen. De RFC met de uitgewerkte oplossingsrichting wordt vervolgens door de Changemanager aangeboden aan het Operationeel Beraad. Noot: Raadpleeg de instructies Hoe maak ik een nieuwe RFC? en Hoe review ik een RFC?
Output	Verbetervoorstellen Impact bepaald op het vlak van security en privacy, Eventueel impact bepaald door stelselarchitect Agendering voor behandeling door OB
Wie?	Leden Intake team en Refinement werkgroep Indiener RFC Experts Beheerorganisatie zoals Security officer / Jurist / Stelselarchitect / Ketenbeheer / Product owner DevOps / Voorzitter expertgroep Changemanager

RFC voordragen aan OB
Input	RFC met uitgewerkte oplossingsrichting
Activiteit	De RFC wordt besproken in het Operationeel Beraad. De aard van de RFC kan: administratief zijn (de juridische of technische strekking van het Afsprakenstelsel niet aantast) en MAG direct worden doorgevoerd in het Afsprakenstelsel. implementatie-impact hebben waarbij het gewenst is dat geeft de indiener toelichting geeft op de gekozen oplossingsrichting met als doel deze te toetsen en te bediscussiëren.
Output	Draagvlak voor de RFC bij leden OB
Wie?	Indiener RFC Changemanager

Opstellen advies voor TB
Input	RFC met positief advies van Operationeel Beraad
Activiteit	Wanneer de RFC draagvlak heeft bij het Operationeel Beraad en daarmee een positief advies, bereidt de changemanager een advies voor namens het Operationeel Beraad voor het Tactisch Beraad. De changemanager heeft ruggenspraak met de releasemanager wanneer het RFC’s met implementatie-impact betreft. Het advies bestaat uit een verzameling administratieve RFC’s en/of RFC’s met implementatie-impact waarvoor goedkeuring wordt gevraagd.
Output	Advies over de RFC als voorbereiding voor de besluitvorming door het Tactisch Beraad.
Wie?	Changemanager Releasemanager Operationeel Beraad Tactisch Beraad

Besluit uitvoeren RFC
Input	Advies voor goedkeuren RFC's van Operationeel Beraad
Activiteit	Een samenvatting van de RFC wordt samen met het advies van het Operationeel Beraad doorgestuurd naar het Tactisch Beraad. Indien gewenst geeft de changemanager en/of indiener RFC nadere toelichting in het Tactisch Beraad. Wanneer het Tactisch Beraad instemt met het voorgelegde advies, zorgt de changemanager dat de administratieve RFC’s worden verwerkt in het Afsprakenstelsel. De changemanager informeert de releasemanager over het besluit t.a.v. de RFC’s met implementatie-impact.
Output	Een formeel vastgestelde RFC’s
Wie?	Changemanager Releasemanager Tactisch Beraad

Afronding RFC
Input	Formeel vastgestelde RFC’s
Activiteit	9a. Administratieve RFC’s worden verwerkt door de Beheerorganisatie in de het Afsprakenstelsel waarbij voor publicatie van een nieuwe versie van het Afsprakenstelsel een controle op een correct verwerking aan de hand van het 4-ogenprincipe wordt uitgevoerd. 9b. RFC’s met implementatie-impact worden geplaatst op de Backlog Implementatie. Dit is het startpunt voor het proces Releasemanagement.
Output	Gepubliceerde nieuwe versie van het afsprakenstelsel op afsprakenstelsel.etoegang.nl E-mail naar betrokkenen verstuurd over nieuwe versie Afsprakenstelsel Start Proces Releasemanagement
Wie?	Changemanager Releasemanager

2. Proces Releasemanagement en bijbehorende processtappen

Beoordeling backlog Implementatie
Input	Formeel vastgestelde RFC’s met implementatie-impact
Activiteit	De releasemanager beoordeelt de Backlog Implementatie. Voor de RFCs wordt bepaald of er impact is voor dienstverleners, gebruikers en ketenpartners (o.a. BSNk en EB) en of er afhankelijk van urgentie en impact voor deze partijen. Een bundeling van RFC's vormt een release. Bestaand of nieuw koppelvlak Het uitbrengen van functionaliteit kan soms binnen de bestaande koppelvlakversie waarbij de functionaliteit direct beschikbaar komt. Soms is voor wijzigingen een release nodig voor een nieuw koppelvlak waarbij de functionaliteiten alleen beschikbaar zijn voor Dienstverleners die vervolgens ook overstappen op het nieuwe koppelvlak.
Output	Een geprioriteerde backlog implementatie Inzicht in beschikbare capaciteit Concept release en planning
Wie?	Releasemanager Product manager eHerkenning

Concept release en planning
Input	Concept release en planning
Activiteit	De releasemanager bespreekt de concept release en planning met alle betrokkenen (Dienstverleners en/of Deelnemers) en verwerkt de feedback. De aangepaste versie van de release en planning vormen de basis voor het advies aan het Leveranciersoverleg.
Output	Bijgestelde release en planning
Wie?	Releasemanager Changemanager Betrokken Deelnemers Betrokken Dienstverlener(s) Product owner DevOps

Opstellen advies release voor LO
Input	Bijgestelde release en planning
Activiteit	De releasemanager stelt advies op voor de voorgestelde release en planning voor het Leveranciersoverleg en bespreekt dit advies voor met de voorzitter Leveranciersoverleg en Product manager eHerkenning.
Output	Advies voorgestelde release
Wie?	Releasemanager Voorzitter Leveranciersoverleg Product manager eHerkenning

Akkoord op release door LO
Input	Voorgesteld advies t.a.v. release en planning
Activiteit	In het LO wordt het advies t.a.v. release en planning besproken waarbij nogmaals gekeken wordt naar de business value, urgentie en beschikbare capaciteit. Hierbij wordt aan het LO gevraagd om commitment te geven op de gevraagde capaciteit en planning.
Output	Terugkoppeling (positief of negatief) op advies voorgestelde release
Wie?	Betrokken Deelnemers Voorzitter Leveranciersoverleg Product manager eHerkenning Releasemanager

Opstellen definitieve release en planning
Input	Terugkoppeling (positief of negatief) op advies voorgestelde release
Activiteit	Wanneer het LO instemt met het advies en commitment afgeeft, past de releasemanager indien afgesproken de voorgestelde release en planning aan tot een definitieve release en planning.
Output	Definitieve release en planning
Wie?	Releasemanager

Opstellen advies voor TB
Input	Definitieve release en planning
Activiteit	Wanneer de release en planning draagvlak heeft bij het Leveranciersoverleg, bereidt de releasemanager een advies voor het Tactisch Beraad. Hiervoor is ook ruggenspraak met de product manager eHerkenning en changemanager. Het advies bestaat uit een release met reeds goedgekeurde RFC’s met implementatie-impact, aangevuld met een planning waarvoor goedkeuring wordt gevraagd om te implementeren.
Output	Advies over de release en planning als voorbereiding voor de besluitvorming door het Tactisch Beraad.
Wie?	Releasemanager

Besluit uitvoeren release
Input	Release met planning met advies Leveranciersoverleg
Activiteit	De release en planning wordt samen met het advies van het Leveranciersoverleg doorgestuurd naar het Tactisch Beraad. Indien gewenst geeft de releasemanager en/of voorzitter van het Leveranciersoverleg nadere toelichting in het Tactisch Beraad.
Output	Een formeel vastgestelde release en planning
Wie?	Changemanager Releasemanager Voorzitter Leveranciersoverleg Tactisch Beraad

Kick off start implementatie
Input	Formeel vastgestelde release en planning
Activiteit	Wanneer het Tactisch Beraad heeft ingestemd met het voorgelegde advies, plant de releasemanager een kick off met de betrokkenen inclusief de changemanager waarin de release en de planning worden besproken. Daarna gaan de implementerende partij van start met de implementatie van de RFC’s. Tijdens de implementatie coördineert de testmanager de uitvoering van het onderdeel testen door zo tijdig de testcases/-scenario’s beschikbaar te stellen. Hij bewaakt de voortgang en de op te leveren bewijsstukken die gearchiveerd worden bij de release. Samen met de releasemanager en changemanager worden de uitgevoerde testen doorgenomen waarbij gekeken wordt naar een goede werking van de interoperabiliteit tussen de betrokken Deelnemers. De testresultaten worden centraal opgeslagen. Wanneer het wijzigingsverzoek van (een) specifieke Dienstverlener(s) kom(t)(en), kunnen deze betrokken worden voor het uitvoeren van E2E-testen tijdens de testperiode. De changemanager zorgt dat de geïmplementeerde RFC’s voor livegang ook verwerkt zijn in het Afsprakenstelsel en een nieuwe versie van het Afsprakenstelsel is gepubliceerd. De releasemanager regelt met de product manager eHerkenning en de beheerorganisatie de communicatie over de release.
Output	Nieuwe versie van het Afsprakenstelsel Positief uitgevoerde testen waarmee de interoperabiliteit wordt aangetoond en kwalitatief goede functionaliteit is opgeleverd nieuwe/aangepast functionaliteit in productie communicatie op over nieuwe functionaliteit nieuwe versie koppelvlak (indien van toepassing)
Wie?	Changemanager Releasemanager Testmanager Product manager eHerkenning Betrokken Deelnemers Betrokken Dienstverlener(s) Product owner DevOps