Geleidelijk komen er voor meer domeinen informatie- en berichtenmodellen, binnengemeentelijk maar vooral ook voor een breder toepassingsgebied: ‘een keten’. Regelmatig doemt de vraag op of een nieuw informatiemodel zich moet houden aan het RSGB. Lang niet altijd gaat het om een informatiemodel (of daarvan afgeleid berichtenmodel) dat alleen voor gemeenten bestemd is. Duidelijkheid over het antwoord op deze vraag is dringend gewenst. Dat biedt inzicht in het doel en de afbakening van RSBG en StUF-BG en de positionering van het RSGB en StUF-BG ten opzichte van andere informatiemodellen respectievelijk berichtenmodellen.
Zie verder deze discussienotitie: KING - Informatiemodellen positionering 20120806 in de bijlage.
Arjan, Ellen en Henri,
goed idee om het RSGB (en RGBZ) te gaan beperken tot de aanvullingen op wat al door anderen is gedefinieerd. Je krijgt in je berichten dan wel te maken met een mix van gegevens uit verschillende 'stallen'.
Is het een idee om StUF te 'ontkoppelen' van RSGB en RGBZ door er een metamodel tussen te schuiven, dat definieert wat een objecttype, relatie, attribuuttype etc. is? Op die manier kan je meta-informatie uit andere modellen in je bericht opnemen. Datzelfde metamodel (we moeten het daar dan wel over eens worden) kunnen we ook gebruiken voor uitwisseling van meta-modellen tussen registraties en generieke voorzieningen als Digilevering. Dan is StUF een sectoronafhankelijk model geworden
Complexe problemen heben vaak geen eenduidige oplossing.
Wat is het (bedoelde) toepassingsgebied van RSGB, RGBZ, StUF BG en StUF ZKN aan de ene kant en StUF aan de andere kant?
Uit het begeleidende document bij StUF 03.01 (In Gebruik) leidt ik af dat RSGB, RGBZ, StUF BG en StUF ZKN primair zijn bedoeld voor de binnengemeentelijke gegevensuitwissleing, terwijl StUG een breder (bedoeld) toepassingsgebied heeft binnen de Nederlandse overheid, waaronder de voor een gemeente relevante externe koppelingen met GBA, BRA, BGR, BRK, NHR en WOZ.
Vanuit een oogpunt van beheer en stabiliteit lijkt het me wenselijk scheidingsvlakken aan te brengen tussen die externe systemen en de gemeentelijke systemen, tenzij het informatiemodel en/of de berichten van het externe systeem op een breed vlak gebruikt worden binnen het gemeentelijk domein.
Voorbeeld 1: vanuit dat standpunt zou men dus kunnen kiezen voor integratie/consolidatie van (een groot deel van) het informatiemodel van de BRA in RSGB/StUF BG/RGBZ/StUF ZKN, omdat bijna alle gemeentelijke applicaties wel iets doen met een adres.
Voorbeeld 2: aan de andere hand ligt het voor de hand WOZ niet op te nemen in het RSGB etc, omdat slechts enkele pakketten hiermee te maken hebben en het dus efficienter zal zijn één of een beperkt aantal gemeentelijke applicaties te laten communiceren met de LV-WOZ en dat dit(deze) applicatie(s) eventuele informatie omzet naar desbetreffende modellen/berichten uit het RSGB etc.
Conclusie: conformeren van een model met RSGB/RGBZ of zelfs integreren van een model met RSGB/RGBZ is niet eenduidig te beantwoorden en is (ondermeer) afhankelijk van de reiktwijdte van het model (cq de uit te wisselen informatie) van de externe applicatie in het binnengemeentelijke werkveld.
Ik heb een tijdje terug een blog geschreven over het RSGB. Misschien voedt dit de discussie nog een beetje.
Bijlage
Eens met Elbert: beperk je tot aanvullingen op wat anderen al hebben gedefinieerd.
Hanteer een aantal duidelijke uitgangspunten. Ga onder andere uit van de indeling die reeds gemaakt is in GEMMA 2.0:
Ieder gegeven dat je tegenkomt kun je dan indelen. Van boven naar beneden de volgende vragen stellen:
Deze indeling strikt hanteren. Geen nieuwe termen verzinnen zoals bijvoorbeeld aangehaakte gegevens. Op basis van ervaring en gebruik kan een gegeven in de loop van de tijd wel in de hierachie naar boven (of naar onder) bewegen. Zo kan een kerngegeven bijvoorbeeld worden toegevoegd aan een basisregistratie als wordt erkend dat het niet alleen binnen de gemeente, maar ook in de rest van de overheid wordt gebruikt. Het stelsel is dus niet star, maar gecontroleerd (aan de hand van procedures) in beweging.
Maak ook geen selectie voor gemeenten van de gegevens in een Basisregistratie. Waarom zou je. In het proces pik je de relevante gegevens uit het bericht, de rest laat je voor wat het is. Het is inderdaad wel jammer dat iedere Basisregistratie zijn eigen modelleringswijze heeft, maar dit ongemak weegt niet op tegen het zelf onderhouden van een RSGB en de gevolgen daarvan.
Dan het onderscheid tussen informatie- en berichtmodellen. Beiden dienen een heel ander doel:
Leg niet een te strikte 1:1 koppeling tussen beide. Uiteraard komen wel dezelfde gegevens in beide modellen terug. Laat de structuur/opzet van de berichtmodellen echter niet afhangen van de informatiemodellen maar van de benodigde gegevensuitwisseling (op basis van gebeurtenissen).
Bij de opzet van berichtmodellen ook een aantal handige uitgangspunten hanteren en daar niet vanaf wijken. Zo is een belangrijke vraag hoe om te gaan met verschillende soorten gegevens in één gegevensuitwisseling: daar meerdere berichten van maken of toch combineren tot één bericht. Denk bijvoorbeeld aan het indienen van een aanvraag van een product door een klant via een e-formulier. Voor de afhandeling van de aanvraag zullen alle ingevulde gegevens doorgestuurd moeten worden en deze gegevens kunnen van alle soorten zijn (1) t/m (4).
Verder dienen berichtmodellen niet te veel vrijheden te bevatten. Deze modellen zijn de sleutel tot standaardisatie in het applicatielandschap! Te veel vrijheden leidt weer tot leveranciersafhankelijke invullingen van de standaard.
Op basis van bovenstaande zaken komen we binnen Apeldoorn tot de volgende antwoorden op de gestelde vragen:
(0) Wat is het bestaansrecht van het RSGB en hoe verhouden de modellen zich tot elkaar.
Laat de definiëring van de Basisgegevens en stelselvorming (en stelselcatalogus) over aan de Basisregistraties.
De hiërarchie in de modellen zit niet in de mate van detaillering maar in het gebruik van de gegevens van een (Basis)registratie door een andere (Basis)registratie. De BAG staat dan onderaan. Deze bevat geen (verwijzingen naar) gegevens die in een andere (Basis)registratie zitten. BPR gebruikt de BAG. NHR gebruikt BAG en GBA. BRK gebruikt BAG, GBA en NHR. Je kunt ook het stelsel als geheel beschouwen. Domeinmodellen bouwen hier op.
Digilevering wordt de plek waar je vragen kunt stellen aan het stelsel. Als er straks echt sprake is van een stelsel haalt digilevering voor een antwoord de gegevens op uit één of meerdere Basisregistraties. Voorlopig slaan de Basisregistraties de gegevens redundant op waardoor bevraging van slechts één Basisregistratie voldoende is.
(I) Welke gegevens nemen we op in het RSGB?
Geen, want er is geen RSGB meer. Zoals hierboven reeds is gesteld zien we geen noodzaak tot een eigen gemeentelijk informatiemodel van basisgegevens.
Wel hebben we heel erg behoefte aan een model van gemeentelijke kerngegevens (RSGK). Hierin worden uiteraard ook de aanwezige relaties met basisgegevens beschreven. Het ontbreken van zo'n model (samen met bijbehorende standaarden voor gegevensuitwisseling) is een van de hoofdredenen van het niet van de grond komen van standaardisatie in de gemeentelijke softwaremarkt.
Overigens zijn alle zaakgegevens die worden onderkend in het RGBZ voorbeelden van gemeentelijke kerngegevens, zodat we de eerste gemeentelijke kernregistratie al hebben beschreven. Het RGBZ is de kernregistratie zaken (KRZ).
(II) Waarom doen we dat, wat zijn de regels en richtlijnen?
We maken de switch van Basisgegevens (RSGB) naar Kerngegevens (RSGK). Dus de vraag wordt: wanneer is een gegeven een kerngegeven. Zul je moeten onderzoeken. Regels zoals 'als het binnen de organisatie meervoudig wordt gebruikt', 'afdelingsoverstijgend' of 'gebruikt in meerdere processen' zijn niet waterdicht. Suggestie: aanhaken bij generieke processen (primair, ondersteunend, bestuurlijk) of processtappen, bijvoorbeeld identificatie, intake, legesheffing, facturering, berichtverzending. Wees niet star, gegevenstypen kunnen 'verhuizen'.
(III) Moet het RSGB vertaald worden naar StUF BG?
Er is geen RSGB meer dus ook geen vertaling naar StUF. Stel de inhoud van berichten vast aan de hand van gebeurtenissen en de relevante gegevens daarbij (vereist overleg tussen bronhouders en afnemers). Of kijk naar de informatiebehoefte in een proces(stap), bijvoorbeeld bij een aanvraag parkeervergunning. Wellicht kun je berichten (gegevenssets) definiëren die dekkend zijn voor meerdere behoeftes. Een StUF bericht hoeft zich niet te beperken tot gegevens uit één registratie en kan dus gegevenstypen bevatten uit verschillende informatiemodellen.
Beste Ellen, Henri, Arjan en Frank,
Wij zien het RSGB als een consolidatie van de informatiemodellen van de diverse Basisregistraties, aangevuld met overige (kern)gegevens die door meerdere gemeentelijke taakvelden worden gebruikt. Het RSGB is daarmee geen kader voor de basisregistraties maar een afgeleide daarvan en aanvulling daarop. Voor andere informatiemodellen dan die van de basisregistraties moeten het RSGB en RGBZ wel als kader dienen. Los van het RSGB zouden er kaders en richtlijnen moeten komen vanuit de overheid die ertoe leiden dat de (versies van de) individuele basisregistraties altijd een optimale eenduidigheid en onderlinge samenhang kennen. Het RSGB en RGBZ spelen een belangrijke rol bij het gecontroleerd doorvoeren van wijzigingen binnen de informatiemodellen van de basisregistraties en het zaakgericht werken. Periodiek (periodiciteit nader te bepalen) moeten nieuwe versies (consolidaties) van het RSGB en RGBZ worden opgeleverd waarin wijzigingen in nieuwe versies van de informatiemodellen van de diverse Basisregistraties of nieuwe overige (kern)gegevens zijn verwerkt.
Zoals door KING in haar notitie ook wordt aangegeven, zijn de StUF sectormodellen BG en ZKN afgeleid van de informatiemodellen RSGB en RGBZ. Wij zien geen reden om gegevens die opgenomen zijn in deze informatiemodellen niet op te nemen in deze sectormodellen. Op basis van specifieke koppelvlak definities en/of autorisatiebesluiten kan voorkomen worden dat bepaalde gegevens ongewenst in de gegevensuitwisseling worden opgenomen. Periodiek (periodiciteit conform StUF beheermodel) moeten nieuwe versies van de sectormodellen BG en ZKN worden opgeleverd waarin wijzigingen in nieuwe versies van de informatiemodellen RSGB en RGBZ zijn verwerkt (geconsolideerd). Omdat het implementeren van nieuwe versies van deze sectormodellen binnen (gemeentelijke) informatiesystemen erg veel tijd en geld kost voor zowel leveranciers als gemeenten, moet telkenmale een afweging gemaakt worden betreffende de noodzaak van een nieuwe versie van het sectormodel BG of ZKN. Als gevolg hiervan zal niet iedere nieuwe versie van de informatiemodellen RSGB of RGBZ automatisch leiden tot een nieuwe versie van het sectormodel BG respectievelijk ZKN.
Naar onze mening moeten systemen bij gemeenten bij voorkeur alleen communiceren op basis van de sectormodellen BG en ZKN tenzij deze systemen als bronhouder (of in een andere rol) rechtstreeks met de landelijke basisregistraties moeten communiceren. Uitzondering hierop vormen systemen (van verschillende leveranciers) die binnen hetzelfde domein functioneren en onderling gegevens uitwisseling conform het binnen dat domein gebruikte sectormodel.
Om bovenstaande te illustreren hanteren wij de referentie architecturen in de bijlagen(*). Door het opnemen van alle voor gemeenten relevante basisregistratiegegevens en overige kerngegevens binnen het RSGB en daarmee het sectormodel BG, is het gebruik van de sectormodellen van de landelijke voorzieningen door de gemeentelijke systemen met uitzondering van de bronhouders niet noodzakelijk. De gemeentelijke berichtenbroker moet in staat zijn om berichten uit (een versie van) een sectormodel van een landelijke voorziening te transformeren naar berichten uit (een versie van) het sectormodel BG en vice versa.
De informatiemodellen RSGB en RGBZ en de horizontale sectormodellen BG en ZKN zijn in onze ogen dus randvoorwaardelijk voor een eenduidige en samenhangende informatievoorziening binnen gemeenten en intergemeentelijke samenwerkingsverbanden. Hierbij wordt tevens onderkend dat delen van deze informatievoorziening lokaal bij de gemeente en andere delen vanuit de cloud worden ondersteund.
Groeten,
John Rooijakkers
(*) Bijlagen zijn verstrekt aan KING maar konden door mij niet opgenomen worden bij deze post.
Leuke discussie, maar het lijkt mij wel verstandig om onderscheid te maken tussen wat ons ideaalbeeld is voor de toekomst en waar we nu praktisch behoefte aan hebben.
Voor de toekomst zou het prachtig zijn, wanneer uit het stelsel van basisregistratie een overkoepelend informatiemodel zou voortvloeien, waar niet alleen de inhoud van deze registraties in staat, maar ook de onderlinge relaties, de manier waarop je moet omgaan met de afwijkingen en de gegevens die beheer moeten ondersteunen. Wanneer die situatie is bereikt, kunnen wij wellicht afscheid gaan nemen van "ons eigen RSGB".
Maar de eerste jaren zullen we het RSGB (die 1 op 1 de basis legt onder het StUF bg) hard nodig hebben om op een efficiënte manier de gegevensstromen en daarmee de "gebeurtenisstromen" goed in te richten. Voorlopig is het plezierig dat we dit soort ontwikkelingen zelf in de hand hebben, omdat we zelf met het RSGB kunnen sturen.
Het verder ontwikkelen van RSGB in relatie met StUF bg door daar ook veel meer gebeurtenissen in te definiëren (aparte berichtcatalogi binnen StUF bg) vormt nog een forse uitdaging. Laten we die uitdaging op een pragmatische manier aanpakken.
Natuurlijk kunnen we parallel hieraan best meewerken om de ontwikkelingen van het stelsel in de breedte ook deze kant op te laten gaan (afstemmen registraties, gebeurtenis gericht werken). Gelukkig zijn er daar ook al ontwikkelingen deze kant op.