7. Bewaarpatronen

Tijdens de sprints van 10 maart en 30 april 2020, heeft het scrumteam zich bezig gehouden met de volgende user story:

'Als ontwerper van een werksysteem wil ik een overzicht van de verschillende ontwerppatronen om de informatie in het systeem langer te bewaren dan de levensduur van het systeem zodat ik bij het ontwerpen van het systeem al een keuze kan maken hoe de informatie voor langere tijd te bewaren.'

Er is een tiental ontwerppatronen beschreven over hoe informatie langer bewaard en toegankelijk kan blijven dan de levensduur van een applicatie (dat wil zeggen: de tijd dat een applicatie gebruikt wordt waarvoor die ooit is aangeschaft/ontwikkeld/ingericht).

Deze ontwerppatronen bieden de informatiebeheerspecialist die zich bezighoudt met 'archiving by design' inzicht in welke keuzemogelijkheden er zijn om in het ontwerp op te nemen. De eisen die bij dat scenario horen, kunnen dan meteen worden opgesteld en meegenomen bij de aanbesteding, ontwikkeling en/of inrichting van een applicatie.
Welk scenario het meest geschikt is, hangt af van de specifieke omstandigheden, infrastructuur en het lokale beleid. Het kan ook voorkomen dat er combinaties van bewaarpatronen worden toegepast.

Hoewel de ontwerppatronen primair gericht zijn op de inrichting, zijn de ontwerppatronen ook toepasbaar bij het afsluiten en opruimen van oude applicaties.

De volgende scenario's zijn uitgewerkt:
1. Inkijkfunctie
2. Bronregisters
3. E-depot als bron
4. DMS-koppeling
5. Migratie naar opvolgend systeem
6. Migratie naar archiefsysteem
7. Export naar een archiefomgeving
8. Export naar losse bestanden
9. Ontsluiting met BI-tooling
10. Emulatie

De afbeeldingen bij de verschillende scenario’s geven een indicatie van voordelen en nadelen, maar deze zijn zeker niet uitputtend.

Scenario 1: Inkijkfunctie
Veel leveranciers bieden aan het eind van de contractduur van een applicatie de optie om, tegen lager tarief, een inkijklicentie af te nemen. De gegevens kunnen dan niet meer worden gewijzigd, enkel geraadpleegd.

Scenario 2: Bronregisters
In dit scenario worden de gegevens al vanaf het begin buiten de applicatie opgeslagen in applicatieonafhankelijke bronregisters. Als de applicatie later wordt vervangen, blijven de bronregisters in tact. Dit sluit bijvoorbeeld aan bij de principes van Common Ground.

Scenario 3: E-depot als bron
In dit scenario worden de gegevens al vanaf het begin buiten de applicatie opgeslagen in een e-depot. Dit scenario lijkt sterk op scenario 2, met dit verschil dat het bronregister in een e-depot staat. Dit is een vorm van uitplaatsing bij creatie en dit vergemakkelijkt vervroegde overbrenging.

Scenario 4: DMS-koppeling
Een veelvoorkomende strategie, is een koppeling met een DMS, waardoor documenten vanaf het moment van creatie direct in het DMS worden opgeslagen. Dit heeft als nadeel dat dit enkel voor documenten (inclusief metadata) een oplossing biedt en niet voor gestructureerde informatie.

Scenario 5: Migratie naar opvolgend systeem
Als een applicatie in de toekomst vervangen gaat worden, dan is het een optie om de informatie te migreren naar het nieuwe systeem dat het oude vervangt. Bij migratie bestaat altijd een risico op informatieverlies.

Scenario 6: Migratie naar een archiefsysteem
In dit scenario wordt de informatie bij het uitfaseren en/of vervangen van een systeem naar een derde systeem gemigreerd en daar bewaard zo lang als noodzakelijk. Dit kan bijvoorbeeld een DMS of een e-depot zijn.

Scenario 7: Export naar archiefomgeving
Sommige organisaties hebben een aparte omgeving voor het archiveren van gestructureerde informatie. Bijvoorbeeld een applicatie die een datastructuur kan inlezen en ontsluiten of een datawarehouse waaraan bepaalde beheertools zijn gekoppeld. Een scenario is dan om informatie naar die gespecialiseerde omgeving te verplaatsen.

Het verschil met scenario 6 is dat het hier niet gaat om documenten maar om gestructureerde data. De aard van de verschijningsvorm vraagt hier om een ander soort applicatie.

Scenario 8: Export naar losse bestanden
Een laagdrempelige oplossing is om een datadump te maken. Gestructureerde gegevens kunnen bijvoorbeeld worden geëxporteerd naar een doorzoekbaar Excel-document. Deze oplossing brengt het risico op het verlies van context (metadata) en samenhang (relaties in de database) met zich mee.

Scenario 9: Ontsluiten met BI-tooling
In dit scenario wordt enkel de database bewaard en ontsloten met Business Intelligence (BI)-tooling. Met BI-tooling kan op basis van een query een rapport worden gemaakt. Deze oplossing is geschikt voor gestructureerde data en niet voor documenten.

Scenario 10: Emulatie
De laatste strategie uit het rijtje is emulatie. Een manier om middels virtualisatie informatie in combinatie met de applicatie zelf te bewaren, inclusief de aldaar aanwezige functionaliteit.