Change- en releasemanagement proces

Titel

Change- en releasemanagement proces

Versie

0.0.4

Datum

17 Juni 2024

Auteur

Programmateam Edu-V

Acties

Opnieuw voorleggen KBO en BO

Een (kandidaat) deelnemer of een implementatiepartner namens meerdere (kandidaat) deelnemers die in de praktijk tegen een issue is aangelopen of een behoefte heeft aan wijziging of uitbreiding van een bestaande afspraak en een RFC indient bij Stichting Edu-V.

• Opstellen van aanvraagformulier RFC

• Onderbouwen van nut en noodzaak van RFC

• Uitwerken van globale oplossingsrichting voor issue

Een taak van een medewerker van Stichting Edu-V die het proces van intake en behandelen van RFC’s uitvoert en begeleidt.

• Registratie van RFC’s

• Aansturen van behandelen RFC’s

• Communicatie met Indieners

• Voorzitter van Change Advisory Board

Een taak van een medewerker van Stichting Edu-V die het samenstellen, de besluitvorming en het uitvoeren van releases begeleidt.

• Samenstellen releases

• Begeleiden besluitvorming over releases

• Aansturen van oplevering releases

Een taak van een medewerker van Stichting Edu-V die de changemanager en releasemanager ondersteunt bij het change en releasemanagement.

• Analyseren RFC’s

• Afstemmen met Indiener over de inhoud en onderbouwing van een RFC

• Doorvoeren van correctievoorstellen uit RFC’s

• Doorvoeren van wijzigingsvoorstellen uit RFC’s

• Opstellen van Release Notes

• Uitvoeren van releases

• Beheren van documentatie

Een groep van experts die RFC aanvragen, wijzigingsvoorstellen en releasenotities beoordeeld en hier advies over geeft.

De Change Advisory Board bestaat uit de volgende leden:

• Changemanager (Voorzitter)

• Voorzitter Architectenraad Edu-V

• Experts werkgroepen Edu-V

• Afvaardiging implementatiepartners

• Prioriteitstelling RFC’s bepalen

• Wijzigingsvoorstellen in behandeling nemen en hierover adviseren

• Adviseren over releases

Een werkgroep van Edu-V die één of meerdere praktijksituaties inclusief daartoe behorende referentiecomponten en gegevensdiensten onder beheer heeft.

• Inhoudelijk beoordelen van RFC’s

• Verder uitwerken en detailleren van een globale oplossingsrichting naar een concreet wijzigingsvoorstel op de specificatie

• Verzorgen van review op het wijzigingsvoorstel door leden van de werkgroep

De Architectenraad Edu-V borgt de samenhang van alle afspraken en zorgt ervoor dat afspraken blijven voldoen aan de architectuurprincipes en het architectuurkader.

• Beoordelen van RFC’s en wijzigingsvoorstellen op inhoudelijke samenhang, voldoen aan de architectuurprincipes en het architectuurkader.

• Inhoudelijk beoordelen van RFC’s op het architectuurkader

• Verder uitwerken en detailleren van een globale oplossingsrichting op het architectuurkader naar een concreet wijzigingsvoorstel

Verantwoordelijk voor de besluitvorming over nieuwe releases van het afsprakenstelsel.

• Besluiten over releases

• Indien van toepassing hierover advies inwinnen bij de adviesraad

De Adviesraad wordt geconsulteerd door het Bestuur bij releases.

• Adviseren over releases

Een RFC die effect heeft op de beheerprocessen, dienstenniveaus en de gerelateerde juridisch documenten.

Aanpassing beschikbaarheidsvenster in Dienstenniveaus

Proceswijziging in klachten- en geschillenregeling.

Een RFC die effect heeft op de privacy richtlijnen of de model verwerkersovereenkomst.

Tekstuele wijziging van verwerkersovereenkomst

Een RFC die effect heeft op (een) gegevensdienst(en) uit één werkgroep.

Nieuw gegevensveld

Verwijderen gegevensveld

Gegevensveld verplicht in plaats van optioneel

Wijziging in een waardelijst

Nieuwe gegevensdienst

Bug fix in de YAML

Aanvulling van de documentatie

Een RFC die effect heeft op gegevensdiensten uit meerdere werkgroepen, regie op gegevens of het architectuurkader

Aanpassing gegevensveld waar een andere gegevensdienst van afhankelijk is.

Wijziging in een NL GOV standaard waarnaar wordt verwezen. Er wordt een afweging gemaakt of deze wijziging al dan niet direct wordt overgenomen.

Aanvulling van de documentatie

Aangevraagd

De RFC is aangevraagd door de indiener en als nieuw aangemaakt op de RFC overzichtspagina.

De RFC is nieuw en nog niet inhoudelijk beoordeeld.

IA

–

Gekwalificeerd

De RFC is geanalyseerd, de variant is bepaald en de impact is ingeschat.

CM

Ja

TE prioriteren

De RFC wordt besproken in de volgende bijeenkomst van de Change Advisory Board om de prioriteitstelling te bepalen.

CAB

–

TE behandelen

De RFC is toegevoegd aan de backlog en wordt conform de prioriteitstelling in behandeling genomen.

CM

–

in behandeling

De RFC is in behandeling genomen en afhankelijk van de RFC variant belegd bij de werkgroep, werkgroep(en) en/of de Architectenraad Edu-V.

WG en/of AR

Ja

TE corrigeren

De RFC is toegevoegd aan de backlog van de informatieanalist en de correctie wordt uitgevoerd.

IA

-

gecorrigeerd

De RFC heeft geleid tot een correctie in het afsprakenstelsel.

De RFC is afgerond

CM

Ja

wijzigingsvoorstel

De RFC heeft geleid tot een wijzigingsvoorstel dat is uitgewerkt in de werkgroep(en) en/of de Architectenraad Edu-V.

CM

Ja

Te beoordelen

Het wijzigingsvoorstel van de RFC wordt ter beoordeling voorgelegd in de volgende bijeenkomst van de Change Advisory Board

CAB

–

TE wijzigen

Het wijzigingsvoorstel van de RFC is besproken in de Change Advisory Board en kan verwerkt worden in de afspraken.

IA

–

Gewijzigd

Het wijzigingsvoorstel van de RFC is verwerkt door de informatieanalist in een wijziging van het concept afsprakenstelsel.

RM en CM

Ja

pre-release

De wijziging uit de RFC is geselecteerd voor de aankomende release.

IA en CAB

–

released

De wijziging is doorgevoerd in een nieuwe release van het afsprakenstelsel.

De RFC is afgerond.

RM en CM

Ja

afgewezen

De RFC is afgewezen en wordt niet in behandeling genomen of leidt niet tot correcties en/of wijzigingen van het afsprakenstelsel.

De RFC is afgerond. Indien een ander gremium of stakeholder nog een rol kan hebben in het betreffende onderwerp volgt een advies of procesafspraak richting deze belanghebbende.

CM

Ja

Meerdere ketenprocessen kunnen niet functioneren. Het issue is een showstopper voor de digitale infrastructuur.

Issue met identifiers

Issue in OAuth implementatie

Direct opvolging aan geven.

In geval van blocker op een geïmplementeerde gegevensdienst gaat Incident Management in werking.

Een ketenproces kan niet volwaardig functioneren zodra de wijziging niet is doorgevoerd. Het issue is een showstopper voor het ketenproces.

Endpoint ontbreekt

Transactiepatroon is niet werkbaar

Kritiek attribuut ontbreekt

Direct opvolging aan geven.

In de bestaande versie of door een extensie is er een workaround waardoor het issue uit de RFC verholpen is. De workaround is echter niet wenselijk voor de lange termijn.

Optioneel veld verplicht maken

Ontbrekend item voor waardelijst

Ontbrekend attribuut

Wijziging in regelgeving

Het issue beschreven in de RFC is geen showstopper maar dermate belangrijk of van toegevoegde waarde dat de wijziging voorrang dient te krijgen.

De RFC betreft een uitbreiding, wijziging of verbetering van een gegevensdienst.

Wijziging in standaard waarnaar verwezen wordt

NIeuw object

Nieuwe API

Opvolging zodra de RFC’s met een hogere prioriteit verwerkt zijn.

De impact is nihil en de wijziging zal niet leiden tot nieuwe of gewijzigde functionaliteit.

Typefout

YAML bug

Periodiek of wanneer er tijd over is.

De nieuwe gegevensdienst is in ontwikkeling.

Er is nog geen sprake van change- en releasemanagement.

In het ontwikkelproces wordt met iteraties gewerkt en komt een afspraak stapsgewijs tot stand.

Reviews worden besproken in de werkgroep en leiden volgende iteraties van de documentatie.

0.0.X waarbij de X bij iedere iteratie wordt opgehoogd.

De nieuwe gegevensdienst is in eerste implementatie tijdens een voorjaars- of najaarsrelease.

Change en releasemanagement proces is gedeeltelijk van toepassing.

Alleen RFC’s van de variant Stelsel en Gegevensdienst met de prioriteiten blocker en critical worden opgepakt als nieuwe release.

Geen nieuwe functionaliteit (major en minor) wordt toegevoegd.

Uiteraard worden trivial RFC’s verwerkt en de correcties doorgevoerd.

0.9.Y waarbij de Y bij iedere versie wordt opgehoogd.

De gegevensdienst is succesvol geïmplementeerd tijdens een voorjaars- of najaarsrelease door leveranciers.

Deze leverancier bieden de gegevensdienst in een productieomgeving aan.

In de fase van beheer is er sprake van doorontwikkeling van de gegevensdienst.

Het volledige Change en Releasemanagement is van toepassing inclusief alle RFC varianten en prioriteitslabels.

Semantic versioning conform versiebeheer.

Stelsel

Gegevensdienst

blocker

critical

Deze release kan ieder moment uitgevoerd worden aangezien er een issue is met de continuïteit van een ketenproces.

Stelsel

Gegevensdienst

Beheersing

Privacy

major

minor

Deze release wordt periodiek doorgevoerd.

Het streven is om releases die niet backwards compatible zijn maximaal 1 keer per jaar door te voeren.

Allen

trivial

Deze release wordt periodiek en in hogere frequentie dan de feature release doorgevoerd.

Aanvragen

1.

De Indiener dient een RFC in en stelt hiervoor een aanvraagformulier op. Dit aanvraagformulier bestaat uit de volgende onderdelen:

• De indiener(s) van de RFC

• Contactpersoon

• Op welke afspraak heeft de RFC betrekking

• Verwijzing naar de betreffende Confluence pagina

• Voorgestelde wijziging

• Rationale voor de voorgestelde wijziging

• Gewenste invoeringstijdstip van de RFC

–

2.

De CM registreert de aanvraag van de RFC en meldt aan de Indiener dat de RFC in goede orde is ontvangen.

AANGEVRAAGD

Prioriteren

3.

De IA analyseert de RFC en consulteert de Indiener en indien van toepassing een expert uit de werkgroep of de Architectenraad Edu-V en voorziet de RFC van aanvullende informatie:

• De RFC variant

• Het statuslabel

• Het prioriteitslabel

• Een inhoudelijk advies aan de CM en de CAB voor verdere opvolging. Uit dit advies blijkt:

  • De rationale voor toekennen van de RFC variant en het prioriteitslabel.

  • Of de RFC in behandeling zou moeten worden genomen of afgewezen kan worden.

  • Indien het advies is om de RFC af te wijzen dan bevat het advies hier een onderbouwing voor

Bij het bepalen van het prioriteitslabel en het formuleren van het advies kan de IA gebruik maken van het afwegingskader wijzigingen.

Indien de prioriteit van de RFC is ingeschaald als blocker, critical of trivial dan wordt de status gewijzigd naar In behandeling. Voor de andere prioriteiten wordt de status aangepast naar gekwalificeerd.

Op deze manier zorgen we ervoor dat de RFC’s die de continuïteit van de digitale infrastructuur in het geding brengen direct opgevolgd worden. De stap van prioriteitstelling door de CAB wordt overgeslagen.

gekwalificeerd

In behandeling

4.

De CM bereidt de CAB meeting voor en verzamelt alle gekwalificeerde RFC’s en bepaalt welke RFC’s in de volgende CAB meeting besproken gaan worden.

te prioriteren

5.

In de CAB meeting worden de RFC’s met het statuslabel te prioriteren besproken en wordt bepaald welke RFC’s in de komende periode worden behandeld.

Tijdens de bijeenkomst wordt bepaald of de RFC:

• Nog niet behandeld gaat worden (status blijft te prioriteren)

• Behandeld gaat worden (status wijzigt naar te behandelen)

• Niet in behandeling wordt genomen (status wijzigt naar Afgewezen)

–

6.

De CM verwerkt de uitkomsten van de CAB meeting en zorgt voor de statuswijzigingen.

te prioriteren

te behandelen

Afgewezen

Behandelen

7.

De CM neemt alle RFC’s initieert het proces van behandelen voor alle RFC’s met de status te behandelen. Afhankelijk van de RFC variant en/of de prioriteitstelling wordt de behandeling uitgevoerd door:

• De IA voor RFC’s met een prioriteit trivial.

• De werkgroep Beheersing voor de RFC variant Beheersing.

• De Keten Adviesgroep Privacy voor de RFC variant Privacy.

• De relevante werkgroepen voor de RFC variant Gegevensdienst.

• De Architectenraad Edu-V voor de RFC variant Stelsel en alle RFC’s met de prioriteitstelling blocking, critical en major.

Voor RFC’s met een prioriteit van blocker of critical organiseert de CM het versnelde proces. Dit betekent:

• Inplannen van een aanvullende CAB meeting.

• Voorbereiden van een hot fix release en dit beleggen bij de Informatieanalist.

• Informeren van het Bestuur en in overleg bepalen op welke wijze de besluitvorming wordt gedaan op de hot fix release.

in behandeling

8.

Na het in behandeling nemen informeert de CM de indiener over de volgende stap.

9.

De RFC wordt behandelt conform de op de RFC van toepassing zijnde behandelroute:

• De RFC leidt tot een correctie die doorgevoerd wordt door de IA.

• De RFC wordt besproken, geanalyseerd en geadresseerd in de relevante werkgroep(en) en/of de Architectenraad Edu-V en leidt tot een wijzigingsvoorstel.

  • Bij het behandelen van de RFC kan advies worden ingewonnen bij experts en adviseurs. Een voorbeeld is juridisch advies over een wetswijziging of technisch advies over een wijziging in een standaard waar naar wordt verwezen.

wijzigingsvoorstel

Gecorrigeerd

10.

De CM bereidt de CAB meeting voor en verzamelt alle RFC’s met de status wijzigingsvoorstel en agendeert deze voor het overleg.

te beoordelen

11.

In de CAB meeting worden alle wijzigingsvoorstellen besproken en wordt de vervolgstap bepaald:

• Het wijzigingsvoorstel is akkoord en kan worden verwerkt (te wijzigen).

• Het wijzigingsvoorstel is niet akkoord en dient opnieuw in behandeling te worden genomen (te behandelen).

• In het wijzigingsvoorstel is onderbouwd dat geen wijziging noodzakelijk is en de RFC wordt alsnog afgewezen (Afgewezen).

12.

De CM verwerkt de uitkomsten van de CAB meeting en zorgt voor de statuswijzigingen.

De RFC’s met de status te wijzigen worden gecommuniceerd naar de IA zodat deze de wijzigingen kan verwerken.

te behandelen

te wijzigen

Afgewezen

13.

De IA verwerkt de wijzigingen in de ontwikkelomgeving van het Afsprakenstelsel.

Gewijzigd

14.

De CM informeert de indiener over de voortgang van de RFC. Dit kan een melding zijn dat de RFC opnieuw in behandeling wordt genomen, verwerkt gaat worden of dat deze alsnog is afgewezen.

Releasen

15.

De RM selecteert de RFC’s met de status Gewijzigden stelt hier een release voor samen.

pre-release

16.

De IA werkt de concept release notes uit. In de release notes worden de wijzigingen samengevat. De IA maakt hiervoor gebruik van de registratie van de RFC’s die zijn opgenomen in de release.

17.

De RM bereidt de CAB voor waarin de aankomende release wordt besproken. De RM stelt een releasenotitie op waarin de selectie van RFC’s wordt onderbouwd, de concept release notes zijn opgenomen en de belangrijkste wijzigingen worden toegelicht.

18.

Het CAB bespreekt de releasenotitie en gaat al dan niet akkoord met de samenstelling van de release.

Het CAB kan adviseren om de selectie van RFC’s te wijzigen of verbetersuggesties doen voor de releasenotes en de onderbouwing van de keuzes.

19.

De RM verwerkt de adviezen van het CAB in de Releasenotitie en legt deze ter besluitvorming voor aan het Bestuur.

20.

Het Bestuur bespreekt en besluit over de Release. Er kan besloten worden om akkoord te gaan met de release, akkoord te gaan met een gedeelte van de release of niet akkoord te gaan met de release.

Het Bestuur consulteert bij een majeure release de Adviesraad. Dit betreft de Feature release in de fase van beheer. De Hot fix en de patch release worden niet voorgelegd aan de Adviesraad.

In aanvulling hierop worden ook de faseovergang van ontwikkeling naar implementatie (van versie 0.0.X naar 0.9.0) en de faseovergang van implementatie naar beheer (van versie 0.9.Y naar 1.0.0) voorgelegd aan de Adviesraad.

21.

De RM start het releasen en geeft opdracht aan de IA om de release door te voeren.

22.

De IA voert de release door naar de productieomgeving van het afsprakenstelsel. Een nieuwe versie van de documentatie komt online. De release notes worden gepubliceerd en de RFC’s wijzigingen naar de status Released.

RFC’s die na besluitvorming toch geen onderdeel worden van de release worden van status gewijzigd naar Gewijzigd of te behandelen.

Released

Gewijzigd

te behandelen

23.

De CM (Let op: dit is dus niet de RM) informeert de indiener over de voortgang van de RFC. Dit kan een melding zijn dat de RFC opnieuw in behandeling wordt genomen of gereleased wordt. Indien een wijziging toch niet gereleased wordt verandert de status feitelijk niet (deze blijft Gewijzigd) en wordt er niets gecommuniceerd.

Maximale reactietermijn door CM na indienen aanvraagformulier RFC

3 werkdagen

1 werkdag

5 werkdagen

1 werkdag

maandelijks

n.v.t.

Maximale reactietermijn en verwerkingstermijn voor behandelen van RFC’s met prioriteit trivial door IA.

2 weken

n.v.t.

2 maanden

n.v.t.

4 maanden

n.v.t.

n.v.t.

1 week

Iedere maand

Op afroep, gepland zodra RFC in behandeling wordt genomen.

2 weken

2 werkdagen

2 werkdagen

n.v.t.

2 werkdagen

n.v.t.

2 werkdagen

n.v.t.

7 werkdagen

n.v.t.

7 werkdagen

n.v.t.

1 werkdag

n.v.t.

Doorlooptijd van samenstellingen tot besluitvorming over een Hot fix release

n.v.t.

3 werkdagen