Het afsprakenstelsel is dynamisch en ontwikkelt verder om ervoor te zorgen dat het DSGO aan de eisen en behoeftes van betrokken partijen blijft voldoen. Indien nodig, kunnen afspraken (generiek en specifiek) worden toegevoegd, gewijzigd, of verwijderd. Om de impact van wijzigingen te minimaliseren, is een gecontroleerde change en release managementproces vastgelegd.
De figuur hieronder geeft een globaal beeld van de stappen in het change en release managementproces, deze wordt verder gedetailleerd onderaan deze pagina.
Het change en release managementproces gaat over wijzigingen van afspraken in het afsprakenstelsel. Het gaat niet over de wijzigingen en releases van datadiensten of voorzieningen. Aanpassingen in het afsprakenstelsel kunnen wel impact hebben op reeds bestaande datadiensten en voorzieningen. Hierdoor is het mogelijk noodzakelijk om een datadienst of voorziening te updaten om conform het afsprakenstelsel te blijven handelen.
Change en release management van het afsprakenstelsel heeft als doelstelling dat het DSGO toekomstbestendig is en meebeweegt met de wensen en eisen van betrokken partijen. Omdat afspraken gelden tussen betrokken partijen, dient een eerlijke, representatieve en inclusieve vertegenwoordiging zeggenschap te hebben over wijzigingen van het afsprakenstelsel. Het change en release managementproces ondersteunt twee doelstellingen:
Op transparante en zorgvuldige wijze besluiten welke wijzigingen wel/niet worden doorgevoerd. Hierbij hebben de betrokken partijen invloed op de wijzigingen, en deelnemers inspraak in de wijzigingen.
Releases van wijzigingen worden op een gestandaardiseerde wijze doorgevoerd met minimale impact en verstoring in de werking van het DSGO.
Verschillende partijen die gebruik maken van of betrokken zijn bij het afsprakenstelsel hebben een verantwoordelijkheid in change en release management.
De Beheerorganisatie DSGO bestaat uit meerdere organen zoals beschreven in de governance. Verschillende organen zijn betrokken bij het change en release managementproces. De Beheerorganisatie DSGO is verantwoordelijk voor het faciliteren van het change en release managementproces volgens de procesbeschrijving. Verder mag de Beheerorganisatie DSGO een verzoek voor wijzigingen indienen.
|
De Deelnemersraad ontvangt van de Change Advisory Board advies. Alle RFCs die succesvol stap 2 doorstaan wordt voorbereid om door de CAB te worden beoordeeld.
De Deelnemersraad is verantwoordelijk voor het schetsen van de strategische kaders voor de inhoudelijke doorontwikkeling van het DSGO. De Deelnemersraad bekrachtigt de afspraken in het DSGO op basis van advies ontvangen over RFCs van de Change Advisory Board. De Deelnemersraad kan een RFC niet wijzigen.
De Change Advisory Board (CAB) is verantwoordelijk voor het adviseren van de Deelnemersraad in de ingediende veranderingen.
|
Elke partij mag een RFC voorstel indienen in dit change en release proces. Iedereen mag een RFC indienen. Enkel partijen die betrokken zijn bij het DSGO (als deelnemers, technisch conform datadienstaanbieders en toekomstige gebruikers) zijn verder (direct/indirect) betrokken bij the change en release proces. Voor meer informatie zie Governance.
|
Het change en release managementproces verloopt als volgt:
Partijen die een RFC mogen indienen zijn:
Beheerorganisatie DSGO
Deelnemers
Betrokken partijen (partijen die in toetreding zijn en relevante stakeholders die namens een achterban mogen handelen). Zij hebben ondersteuning van (bijna) deelnemers nodig om RFCs naar de volgende stap te kunnen laten gaan.
Een RFC kan rechtstreeks wordt ingediend via het GitHub DSGO RFC board, of via een email naar DSGO@digigo.nu. Bij het ontvangen van een RFC voorstel via email stuurt Beheerorganisatie DSGO een bevestiging naar de indienende organisatie. Indien gewenst kan Beheerorganisatie DSGO ondersteuning bieden bij het indienen. |
Beheerorganisatie DSGO borgt dat RFCs worden ingediend volgens de GitHub template en op de BACKLOG terecht komt. De voortgang van RFCs wordt gedocumenteerd in het GitHub DSGO RFC board, dat automatisch alle wijzigingen logt gedurende het change en Release proces. Het RFC board en de RFC template zijn openbaar en in te zien zonder github account. Een Partij die een RFC wil indienen of commentaar op andere RFCs wil geven, heeft daarvoor een Github account nodig.
De Beheerorganisatie DSGO bereidt het RFC voorstel voor zodat deze kan worden beoordeeld door de CAB. Hierbij wordt de haalbaarheid en de impact van de RFC voorstel bepaald en gedetailleerd indien nodig.
O.b.v. de volledigheid van het voorstel en of de RFC binnen de scope en strategische kaders past, zijn zijn twee mogelijke uitkomsten van het voorbereiden van een RFC:
De RFC wordt niet besproken in een meeting met de CAB. De Beheerorganisatie DSGO stelt een schriftelijke reactie op waarom is besloten om de RFC niet voor te leggen aan de CAB. De indienende partij is vrij om op basis hiervan een RFC voorstel te wijzigen en opnieuw in te dienen.
De RFC wordt besproken in een meeting met de CAB. De Beheerorganisatie DSGO informeert vooraf de CAB en de indienende partij(en) over wanneer de RFC ingepland staat ter bespreking.
Als de RFC positief beoordeeld wordt, verrijkt de Beheerorganisatie DSGO deze met de volgende analyses (op basis van alle input van de ingediende RFC):
Een impact analyse op de Beheerorganisatie DSGO en DSGO deelnemers
Een risicoanalyse incl. mitigerende maatregelen
Een (high-level) business rationale voor de wijziging, waarbij zowel de toegevoegde waarde als kosten in kaart worden gebracht
De Beheerorganisatie DSGO deelt de verrijkte RFC vervolgens met de CAB.
Merk Op: Wanneer de Beheerorganisatie DSGO o.b.v. de input geen analyse kan maken omdat dit een bepaalde expertise vereist, dan organiseert zij een extra werkgroep met experts. Indien het RFC voorstel over specifieke afspraken gaat, moet er altijd een werkgroep met experts over het specifieke onderwerp worden georganiseerd. |
De Beheerorganisatie DSGO plant een CAB bijeenkomst in en communiceert deze aan de CAB-leden. Hierbij zorgt zij dat ze de CAB-leden voldoende tijd geeft om de RFC met eigen achterban te valideren en bespreken. Als een CAB-lid niet aanwezig kan zijn, haalt de Beheerorganisatie DSGO eventuele schriftelijke input op bij hem/haar.
In de CAB meeting geeft de CAB advies over de RFC. Dit wordt gedaan op basis van de geanalyseerde RFC, en de geschatte impact van de RFC. Dit advies kan (o.a.) zijn:
Acceptatie van de RFC
Acceptatie van de RFC onder beschreven voorwaarden
Opnieuw behandelen in CAB onder beschreven voorwaarden
Afkeuren van de RFC (met onderbouwing)
Bij acceptie wordt aangegeven wat de prioriteit van de RFC is.
De Beheerorganisatie DSGO is verantwoordelijk voor de voorbereiding van de CAB meeting. De agenda en de te bespreken RFCs deelt zij ten minste een week voorafgaand aan de CAB bijeenkomst.
De agenda en verslaglegging van elke CAB meeting wordt opgeslagen in een gedeelde map op sharepoint. en is opvraagbaar door iedereen.
Daarnaast is de Beheerorganisatie DSGO verantwoordelijk voor het opstellen van een adviesrapport vanuit de CAB voor de Deelnemersraad. De Beheerorganisatie DSGO deelt het adviesrapport met de CAB ter review. Na deze review wordt voor elke beoordeelde RFC het CAB advies als comment toegevoegd op het github issue board en gedeeld met de deelnemersraad.
In het agenda item bekrachtigen van het advies van de CAB behandelt de Deelnemersraad het adviesrapport op strategisch niveau. De voorzitter van de CAB kan hierbij uitgenodigd zijn om vragen te beantwoorden. De Deelnemersraad heeft een controlerende functie en bespreekt RFCs niet inhoudelijk opnieuw. De Deelnemersraad kan een RFC niet wijzigen. Indien een RFC met positief advies van de CAB niet wordt bekrachtigd, moet de Deelnemersraad een verklaring opstellen met uitleg.
De Beheerorganisatie DSGO is verantwoordelijk voor het inplannen van de Deelnemersraad en voorbereiding van de agenda. Deze agenda en het te bespreken adviesrapport deelt de Beheerorganisatie DSGO ten minste een week voorafgaand aan de Deelnemersraad. Indien een Deelnemersraadslid niet aanwezig kan zijn, haalt de Beheerorganisatie DSGO eventuele schriftelijke input op bij hem/haar. De Beheerorganisatie DSGO is tevens verantwoordelijk voor het opstellen van een besluit- en actielijst van de vergadering. Deze deelt zij maximaal twee weken na het plaatsvinden met de Deelnemersraad.
De agenda en verslaglegging van elke CAB meeting wordt opgeslagen in een gedeelde map op sharepoint. en is opvraagbaar door iedereen.
Voor elke bekrachtigde of afgewezen RFC wordt het besluit en eventuele aanvullende verklaring als comment toegevoegd op het github issue board, na review door de deelnemersraad.
Merk Op: Bekrachtigen van het advies van de CAB is slechts een van de agendapunten in de Deelnemersraad, andere agenda items hoeven niet gerelateerd te zijn aan het Change & releasemanagement proces. |
Wanneer (enkele) RFCs en de release geaccepteerd zijn, plant de Beheerorganisatie DSGO de datum en omvang van de release. De Beheerorganisatie DSGO communiceert op de versiebeheer pagina van het afsprakenstelsel dat er een release aankomt, welke onderwerpen daarin gewijzigd worden en welke termijn acceptabel is voor het doorvoeren van de wijzigingen. RFCs kunnen gebundeld worden in 1 release, of verspreid over meerdere releases worden (zie Versie richtlijnen).
Beheerorganisatie DSGO verwerkt de wijzigingen van de RFCs in het afsprakenstelsel en haar stelselvoorzieningen indien nodig. De Beheerorganisatie logt welke wijzigingen er aan elke pagina in het afsprakenstelsel worden aangebracht en maakt dit inzichtelijk in de page history van elke pagina. Mochten de wijzigingen in het afsprakenstelsel leiden tot grote aanpassingen in het DSGO, dan is de Beheerorganisatie DSGO verantwoordelijk om de deelnemers en betrokken partijen tijdig hierover te informeren. Het moet bekend zijn wanneer de release verwacht wordt en per wanneer zij moeten voldoen aan de doorgevoerde release.
De Beheerorganisatie DSGO publiceert een nieuwe versie van het afsprakenstelsel conform de Versie richtlijnen en maakt een update van de release beschrijving. Wanneer er een release heeft plaatsgevonden, dan is de Beheerorganisatie DSGO verantwoordelijk voor het voldoende informeren van alle partijen in het DSGO-ecosysteem.
De Beheerorganisatie DSGO monitort de release en voorziet deelnemers en betrokken partijen van support om te kunnen voldoen aan de afspraken uit de release indien nodig. De mate en hoe dit gebeurt is afhankelijk van de aard van de wijziging en de doorlooptijd om hieraan te voldoen.
Spoedwijzigingen zijn wijzingen die zo snel mogelijke geïmplementeerd moeten worden. Spoedwijzigingen zijn wijzigingen die of betrekking hebben op een prioriteit 1 (hoog) incident die gericht is aan de Beheerorganisatie DSGO, of wanneer dit impact heeft op de werking van het DSGO kan hebben als de spoedwijziging niet doorgevoerd wordt. In dat geval, mag de Beheerorganisatie DSGO het change en release managementproces versnellen. Zij kan kiezen om leden van de CAB en Deelnemeersraad ad-hoc te consulten over de wijzigingen, mits de timing het toelaat en noodzakelijk wordt geacht. Achteraf moet de Beheerorganisatie DSGO de CAB en Deelnemersraad alsnog volledig informeren over de wijziging.
|
Kleine wijzigingen die geen impact hebben op de technische werking of juridische basis van het DSGO mogen ook zonder het doorlopen van het change en release proces plaatsvinden. Dit zijn bijvoorbeeld herstructurering van de inhoud, verbeteren van taalfouten of updates in hyperlinks en labels.
|
Het RFC voorstel template voor generieke afspraken kan hier gedownload worden.
Het RFC voorstel template voor specifieke afspraken kan hier gedownload worden.
Op deze pagina staat een actueel overzicht met de RFCs die het change & release management proces doorlopen en de backlog.