Een of meer zaakregisters

Auteur: Joeri Bekker | Status: Review

Aanleiding

Is één enkel centraal ZGW-register binnen de gemeente gewenst? Of meerdere? Wat betekent de keuze voor het één of het ander voor andere componenten? Zijn situaties tijdelijk toegestaan of echt als doel architectuur?

Zienswijze Common Ground

Common Ground geeft geen eenduidig antwoord op bovenstaande vragen. Common Ground kent wel een aantal relevante principes (andere principes laten we even buiten beschouwing, zoals “open source”):

1. Component gebaseerd: We gebruiken ontkoppelde componenten met afgebakende functionaliteit en gestandaardiseerde interfaces.

2. Eenmalige vastlegging: We leggen gegevens eenmalig vast en vragen op bij de bron.

3. Regie op gegevens: De burger kan gegevens inzien, aanpassen, heeft inzicht in en invloed op het gebruik ervan.

4. Lagen-architectuur: We gebruiken een gelaagd architectuurmodel waarbij een bovenliggende laag alleen functionaliteit aanroept uit de direct onderliggende laag.

Het groeipact verwoord de basisgedachte van Common Ground als de transformatie van de informatievoorziening door:

1. Gegevens te scheiden van de applicaties en processen waarin zij gebruikt worden.

2. Gegevens meervoudig te gebruiken bij de bron.

Common Ground is niet de meest eenvoudige of voor de hand liggende technische architectuur van een ICT-landschap. Common Ground gaat er juist om dat het huidige ICT-landschap voor niet-technische problemen zorgt, zoals vendor lock-in.

Gevolgtrekking

Common Ground zegt dus niets over het aantal bronnen dat dezelfde soort gegevens opslaat. De zienswijze staat dus toe dat je ZGW-register A hebt voor afdeling A en ZGW-register B hebt voor afdeling B.

Er zijn wel een aantal voorwaarden:

1. Het is expliciet niet de bedoeling dat je zaak X opslaat in ZGW-register A en B. Dit gaat in tegen “eenmalige vastlegging”.

2. Het is ook niet de bedoeling dat je één ZGW-register hebt voor afdeling A, die daarop weer een eigen applicatie heeft. Eigenlijk is dit een klassieke silo-oplossing, die toevallig de ZGW APIs aanbiedt. Dit gaat in tegen “component gebaseerd” en “lagen-architectuur”, alsmede het groeipact.

3. Het principe “regie op gegevens” zegt eigenlijk dat een applicatie toegang moet hebben tot alle ZGW-registers, zodat je je eigen gegevens kan inzien. Dit mogen ook meerdere applicaties zijn maar ook weer niet een silo-oplossing (zie punt 2).

Met deze gevolgtrekking bekijken we enkele scenario’s.

Scenario’s

Hieronder worden enkele scenario’s geschetst. Hoewel de discussie eigenlijk over scenario 1 en 2 gaat, is er een glijdende schaal naar scenario 3, 4 en 5. Vandaar dat deze expliciet worden benoemd.

De vijf mogelijke scenario's, waarbij gefocused wordt op scenario 1 en 2

We onderscheiden 5 scenario’s:

1. Één bron: Meerdere apps bevragen 1 bron

2. Meerdere bronnen: Elke app kan 1 of meerdere bronnen bevragen

3. Verkapte silo: Elke app bevraagt enkel zijn eigen bron waardoor risico bestaat dat het niet werkt met andere bronnen (zeker als ze van dezelfde leverancier zijn)

4. Silo met ZGW API’s: Meerdere apps bevragen 1 bron maar App A is eigenlijk een silo

5. Silo: Een app met zijn eigen register zonder gestandaardiseerde API

Van hoog naar laag

Scenario 5

Een silo wordt hier bedoeld als een applicatie en een register in 1. Iets wat tegen de Common Ground principes en het groeipact in gaat. Hierdoor is scenario 5 te zien als “niet gewenst”.

Scenario 4

Is populair onder leveranciers. Zij realiseren als ware de nieuwe API’s bovenop hun bestaande silo. Het nadeel is vaak dat hun applicatie enkel met hun eigen bron kan communiceren, vaak omdat dit niet via de API’s gaat. Bij een eventuele wisseling van leverancier gaat het register dus mee. Hier is dus hetzelfde argument als bij scenario 5 van toepassing. Scenario 4 is daarom “niet gewenst”.

Scenario 3

Scenario 3 is een twijfelgeval. In principe voldoet dit scenario aan de Common Ground principes, echter is het lastiger om regie op je gegevens te faciliteren omdat er meerdere bronnen geraadpleegd moeten worden. Ook zou het mogelijk kunnen zijn om van scenario 3 naar scenario 2 te gaan, mits App A natuurlijk niet gebruik maakt van een net iets aangepaste standaard van ZGW-register A.

Scenario 2

Voldoet aan alle principes van Common Ground. Rest de vraag of het wenselijk is en wat de gevolgen zijn voor applicaties. Immers, App C moet blijkbaar al meerdere ZGW-registers kunnen bevragen.

Scenario 1

Is het meest eenvoudige scenario dat voldoet aan alle principes van Common Ground. Juist omdat dit het meest eenvoudige scenario is in een toch best wel complex ICT-landschap, geniet dit scenario de voorkeur.

Scenario 4 en 5 zijn gemarkeerd als “niet gewenst” binnen het kader van Common Ground en het groeipact. Je kunt hier als gemeente echter nog steeds voor kiezen, maar het moet duidelijk zijn dat dit niet voldoet aan de Common Ground principes.

Praktijk

Hoewel scenario 4 en 5 afvallen, is zeker scenario 4 populair onder leveranciers. Zij realiseren als ware de nieuwe API’s bovenop hun bestaande software. Het nadeel is vaak dat hun applicatie enkel met hun eigen bron kan communiceren, vaak omdat dit niet via de API’s gaat.

Main course

Dus, scenario 1 en 2.

Verdere uitwerking van scenario 1 en 2

Scenario 1: Éen bron

Common Ground pleit voor één enkel zaakregister per organisatie. Dat betekent dat de organisatie actief streeft om leveranciers aan te laten sluiten op de centrale voorziening.

Voordelen

• Centraal beheer van zaaktypen en haar eigenschappen, bevordert uniformiteit

• Duidelijke bron per organisatie, bevordert samenwerking

• Een enkele versie, dus minder conflicten met ondersteuning van versies

• Minder beheerlast

Nadelen

• Een enkele bron is organisatorisch mogelijk lastiger (verschillende afdelingen met verschillende wensen)

Single point of failure is geen nadeel specifiek voor dit scenario. Je moet je infrastructuur natuurlijk goed inrichten. Met twee instanties heb je voor bepaalde afdeling nog steeds een single point of failure.

Scenario 2: Meerdere bronnen

Bijvoorbeeld door per afdeling of domein een ZGW-register te hebben. Let op: Dit scenario gaat expliciet niet over meerdere ZGW-registers in de keten. Die zijn er, punt. Dit scenario gaat over meerdere ZGW-registers binnen de gemeente.

Voordelen

• Meerdere instanties is het scheiden van data waardoor de attack-vector kleiner is.

• Meer autonomie per afdeling.

Nadelen

• Integratie: Je moet data combineren in de applicatie, en eventueel op applicatie laag sorteren en/of pagineren (2 varianten):

  • Sommige applicaties moeten met meerdere ZGW-registers kunnen omgaan (en kan uitdagend zijn door data te combineren, sorteren, filteren, pagineren over meerdere bronnen)

  • Er moet iets boven ZGW-register komen die dit regelt, een meta-bron

  • Versies van de ZGW-registers kunnen onderling verschillen (in standaard en/of versie)

• Beheer op meerdere plekken

• Dit is niet hoe Open Zaak bedoeld is, zie inzet “Uitgangspunten bij de ontwikkeling van Open Zaak”

Uitgangspunten bij de ontwikkeling van Open Zaak

Er is één database binnen één organisatie waarin alle (meta-gegevens van) Zaken vastligt. Op deze wijze kan op één centrale plaats de status van alle zaken worden opgevraagd. Denk daarbij aan kanalen als een klantcontact-applicatie of een self service Mijn Omgeving.

Er had ook gekozen kunnen worden voor het distribueren van Zaken over meerdere systemen. In deze opzet had een protocol afgesproken moeten worden waarmee op een uniforme wijze zaakgegevens uit de systemen opgevraagd moet worden. Het nadeel van deze aanpak is:

• Performance: er moet realtime bij (mogelijk tientallen componenten) zaken worden opgevraagd.

• Sortering: bij zaken uit vele bronnen kan niet (eenvoudig) een lijst worden gemaakt op nummer / ouderdom etc. Je krijgt vele losse lijsten.

• Standaardisatie: het zal lastiger zijn om af te dwingen dat alle endpoints voldoen aan een bepaalde versie van de standaard.