Datafordelerens ændringshåndteringsproces skal rumme ændringer, der skal implementeres på Datafordeleren fra datafordelermyndigheden, en anvender eller en registermyndighed indmelder et ændringsønske og til denne ændring releases af leverandøren på Datafordelerens produktionsmiljø. Derfor er det vigtigt at processen ikke kun griber de forretningsbehov, som ændringen er et udtryk for, men at den også fungerer sammen med leverandørens ændringshåndteringsproces.
Ændringer beskrives på en række akser, som formuleret nedenfor:
- Prioritering: Er ændringens prioritet 1 (lav E), 2 (middel) eller 3 (høj)?
- Risiko: Er ændringen relativt risikofri eller er der en høj grad af risiko forbundet med den?
- Økonomi: Er ændringen meget bekostelig eller er den ikke, og er der fundet finansiering til den?
- Urgency: Haster ændringen eller haster den ikke?
- Impact: Rammer ændringen ikke rigtig nogen eller mange (eller få, men vigtige) anvendere?
- Bagudkompatabilitet: Er ændringen bagudkompatibel (non-breaking ændring) eller kræver den at anvenderne tilpasser deres systemer før de kan bruge systemet efter en ændring (breaking ændring)
Endvidere benytter Datafordeleren semantisk versionering i forhold til datafordelerplatformen og dennes tjenester. Det betyder, at alle ændringer vil forårsage et nyt versionsnummer, efter nedenstående skema.
Releases navngives derfor MAJOR.MINOR.PATCH, således at version 1.0.0 er første egentlige release.
Typer af ændringer
For at lette arbejdet med ændringer deles de op i tre typer, afhængig af hvordan de placerer sig på ovenstående akser.
Standardændring
En standardændring er en ændring hvor økonomiske forhold, impact og risici ved ændringen er kendte og lave. Følgende gør sig i øvrigt gældende for standardændringer:
- Der er allerede defineret en række standardændringer i aftalehåndbogen med leverandøren, der fx omfatter patching af webservere og lignende.
- Det er et mål for ændringshåndteringsprocessen, at så mange ændringer som muligt defineres som standardændringer, da dette gør driften af Datafordeleren mere smidig og letter Change Managerens og CAB’ens arbejde.
- I det øjeblik en ændring har et direkte impact på den service som en anvender oplever eller de data som andre registre trækker på, så kan der ikke længere være tale om en standardændring.
- Leverandøren skal altid informere Change Manageren, når der foretages standardændringer på Datafordeleren.
- Change Manager kan gå i dialog med leverandøren om at opgradere en standardændring til en hasteændring, hvis dette skønnes nødvendigt.
- Hvis der er flere standardændringer i pipeline, så prioriteres disse, så de ændringer der har højest prioritet som udgangspunkt implementeres først på Datafordeleren.
- Anvendere informeres altid om ændringer af denne type.
Normal ændring
En normal ændring er en ændring, hvor økonomiske forhold, impact og/eller risici ved ændringen er ukendte eller så høje, at ændringen ikke kan behandles som en standardændring. Følgende gør sig i øvrigt gældende for standardændringer:
- For denne ændringstype gælder det, at CAB’en eller et andet forum skal behandle ændringen og godkende at denne kan gennemføres.
- Hvis ændringen berører ejendoms- og/eller adressedata (GD1/GD2), så er der en særlig høringsproces blandt de involverede registermyndigheder, som skal følges.
- Der skal defineres objektive rammer og kriterier for, hvornår CAB’en selv kan håndtere ændringer af denne type og hvornår de skal eskaleres til andre fora. Målet er, at ændringen behandles på lavest mulige niveau i grunddataprogrammet.
- Anvendere høres ofte om ændringer af denne type, og alternativt informeres de.
Versionering af modelregler
Den direkte effekt af ændringer i modelreglerne vil i sagens natur være på datamodellerne, der evt. vil kunne eller skulle ændres på baggrund af en given regelændring. Det kan så igen have effekter på de tjenester, der baserer sig på modellerne.
Modelreglerne versioneres atomart og bitemporalt. Da modelreglerne principielt er enkeltstående og udgivet individuelt, er der ikke noget modelregel-dokument at versionere.
Datamodeller deklarerer deres regel-compliance som en dato:
”Overholder modelregler gældende pr 1. december 2016”
Versionering af datamodeller
Hvis en datamodel ændres, vil effekten være på de tjenester, der anvender data i modellen. Nogle af disse tjenester kan være tværgående.
Versionering af tjenester
Tjenesterne er den direkte snitflade til dataanvendernes applikationer, og derfor vil ændringer i tjenesterne direkte kunne påvirke dataanvendernes systemer og deres forretningsmuligheder.
Hasteændring
En ændring hvor der ikke er tid til at gå igennem de normale kanaler i forhold til godkendelse. Dette kan eksempelvis skyldes en lovændring, eller der kan være tale om en rettelse af et incident, hvor impact og/eller urgency betinger dette (Typisk A-fejl / major incidents). Det er særligt vigtigt, at denne type ændringer dokumenteres, så godkendelser m.v. kan indhentes efterfølgende.
Det markeres ved indmeldelse af ændringsønsket, om indmelderen mener at implementering af ændringen haster, men Change Manageren har ansvar for at vurdere, om der reelt er tale om en hasteændring.
Varsling af ændringer
Der vil i udgangspunktet ikke være et forretningsmæssigt behov for at varsle ændringer på minor- eller patchniveau, da disse ikke nødvendigvis kræver ændringer i andre produkter.
Da major ændringer i modelreglerne vil afføde ændringer i datamodeller og forventeligt også i tjenester, skal disse nødvendigvis varsles tidligere end ændringer i datamodeller og tjenester, så der også er tid til at varsle de afledte ændringer på en rimelig vis overfor dataanvenderne.
Ændringer til tjenester er styret af specificerende registermyndighed, men dataanvendere kan have forventninger til generelle regler. Derfor fastsættes en generel regel om, at major ændringer i tjenester skal varsles mindst 3 måneder før de får effekt på datafordeleren.
Der fastsættes derfor disse mindstekrav til varsling af major ændringer:
