Op weg naar de gemeentelijke service bus

Gemeenten worden geconfronteerd met allerlei ontwikkelingen die van invloed zijn op hun informatievoorziening. Belangrijke ontwikkeling in dat kader is de verplichting om bepaalde gegevens nog maar eenmalig uit te vragen en meervoudig te gebruiken. Dit roept allerlei vragen op rondom de noodzakelijke gegevensuitwisseling tussen applicaties en de wijze waarop deze wordt ondersteund door generieke voorzieningen. Kan zoiets als een gemeentelijke service bus hierin ondersteunen en hoe zou een dergelijke voorziening eruit zien? Dit artikel beschrijft het resultaat van een onderzoek in de gemeente Gouda naar een dergelijke voorziening.

Een belangrijke aanleiding voor het onderzoek in de gemeente is het bepalen van de impact van de landelijke basisregistraties op haar informatiehuishouding. Deze basisregistraties zijn een noodzakelijke voorwaarde voor het meervoudig gebruik van gegevens. Hiertoe is een verzameling van basisgegevens gedefinieerd waarvoor dit meervoudige gebruik geldt. Per basisgegeven is een bronhouder aangewezen die hiervoor een basisregistratie dient te voeren die ook landelijk beschikbaar is zodat ook andere organisaties ze kunnen gebruiken (stelsel van basisregistraties). Gemeenten zijn bronhouder van basisgegevens omtrent personen, adressen, gebouwen, WOZ en grootschalige topografie. De gemeentelijke basisregistraties voor deze basisgegevens moeten gegevens aanleveren aan landelijke voorzieningen. Voor andere basisgegevens binnen het stelsel dient de gemeente gegevens af te nemen van landelijke voorzieningen. Verder dient binnen een gemeente de basisregistratie leidend te zijn in de bedrijfsvoering en mag alleen van deze authentieke gegevensbronnen gebruik gemaakt worden. Dat kan door koppelingen tussen applicaties en de gemeentelijke en landelijke basisregistraties te realiseren, maar dat kan ook door de basisgegevens op een andere wijze beschikbaar te stellen aan de medewerkers van de gemeente. Naast de verplichtingen met betrekking tot basisgegevens werkt de gemeente Gouda ook aan administratieve lastenverlichting, betere dienstverlening en een efficiëntere bedrijfsvoering. De intentie is om ook niet-basisgegevens op een beheersbare wijze meervoudig te gebruiken. Dit gebruik beperkt zich niet alleen tot de backoffice; ook ontsluiting richting de frontoffice speelt daarbij een belangrijke rol.

Bij de gemeente Gouda is zowel gekeken naar de impact op het applicatielandschap, als naar de mogelijke ondersteuning door generieke voorzieningen. In het kader van het applicatielandschap heeft er een inventarisatie plaatsgevonden van kernapplicaties, de basisgegevens die zij registreren en de uitwisseling die zij hebben met andere applicaties. Voor dit doel is ondermeer een enquête opgesteld en uitgevoerd, hebben interviews met applicatiebeheerders plaatsgevonden en heeft er een workshop plaatsgevonden. Hierin is inzichtelijk geworden welke geautomatiseerde koppelingen wenselijk zijn om de aansluiting op basisregistraties te realiseren. Daarnaast heeft er een onderzoek plaatsgevonden naar oplossingen voor gegevensuitwisseling die invulling geven aan het concept 'gegevensmakelaar'. In dat kader is documentatie bestudeerd maar is ook gesproken met leveranciers van dergelijke oplossingen en andere gemeenten die hier ervaring mee hebben. Ik zal hier vooral ingaan op het tweede deel van het onderzoek waarin de gewenste invulling van een gegevensmakelaar is onderzocht.

Gegevensmakelaar

Een gegevensmakelaar (andere termen die wel eens gebruikt worden zijn 'backoffice broker' of 'gegevensbroker') is een generieke voorziening die applicaties in staat stelt gegevens uit te wisselen. Dat doet hij op een zodanige wijze dat applicaties niet van elkaar afhankelijk zijn. Door deze onafhankelijkheid kunnen applicaties los van elkaar evolueren en wordt de impact van wijzigingen in applicaties beperkt. Dit basisidee is niet nieuw; het is niet anders dan wat in het algemeen ook wel een enterprise service bus wordt genoemd. Belangrijk is wel dat de directe aanleiding bij de gemeente Gouda ligt in de aansluiting op de basisregistraties. Dat betekent dat de belangrijkste gegevensuitwisselingen die met de basisregistraties zijn. Verder betreft het vooral gegevensuitwisselingen met backoffice-applicaties die zelf ook (delen van) basisgegevens registreren, alsook gegevensuitwisselingen met de landelijke voorzieningen. Gegeven de overige ambities van de gemeente is het echter belangrijk om ook rekening te houden met toekomstige uitwisseling van niet-basisgegevens en ontsluiting richting de frontoffice.

Een belangrijk bron van inspiratie in de zoektocht naar een gegevensmakelaar is de gemeentelijke referentie-architectuur GEMMA van EGEM. Hierin is ondermeer een basisplaat informatie-architectuur opgenomen [EGEM, 2009a] waarin aantal logische onderdelen in staan die betrekking hebben op een gegevensmakelaar zoals 'Makelaar', 'Gemeentelijke Service Bus' en 'Synchronisatie Basisgegevens' (zie ook Figuur 1). Dit zijn aspecten die allemaal nog kunnen passen bij het algemene concept 'Enterprise Service Bus'. Dat is ook niet zo vreemd gegeven het groeipad naar service-oriëntatie zoals GEMMA dit voorstelt [EGEM, 2009b].

Een ander onderdeel dat een belangrijke relatie heeft met de gegevensmakelaar is het gegevensmagazijn. Het idee achter het gegevensmagazijn is dat hierin gegevens staan uit backoffice-applicaties die zelf niet voldoende beschikbaar zijn. De gegevensmakelaar kan dit gegevensmagazijn vullen waarna de frontoffice deze kan gebruiken voor raadpleegdoeleinden. Het gegevensmagazijn is de plaats waar alle backoffice-gegevens hoog beschikbaar en in samenhang beschikbaar zijn. Het lastige van de GEMMA-basisplaat is dat een verdere verdieping en onderbouwing nog ontbreekt. Dit betekent dat het aan gemeenten zelf is om te bepalen hoe ze de logische onderdelen vertalen naar specifieke oplossingen. Vandaar dat er in Gouda specifiek is gekeken naar de behoeften die bestaan vanuit het perspectief van aansluiten bij landelijke basisregistraties. Het is helder dat het onderdeel 'Synchronisatie Basisgegevens' daarin een prominente rol vervult. De vraag is in hoeverre hiermee ook stappen richting service-oriëntatie worden gezet. Ik verken kort de gewenste functionaliteiten voordat ik de belangrijkste bevindingen met betrekking tot de oplossingen bespreek.

Functionaliteiten

Zoals aangegeven is de synchronisatie van basisgegevens een essentiële functionaliteit. Dit vloeit voort uit het feit dat backoffice-applicaties deels redundant zijn op het gebied van de gegevens die ze administreren en niet in staat zijn om alle gegevens direct uit de bronapplicatie te halen. Door deze gegevens te synchroniseren wordt er wel voor gezorgd dat gegevens maar op één plaats worden beheerd, waarna het naar de afnemende systemen wordt gesynchroniseerd. Per wijziging vanuit een bronapplicatie moet kunnen worden aangegeven naar welke doelapplicaties deze wijziging wordt gedistribueerd.

Direct gerelateerd aan synchronisatie is de noodzaak van een gegevensmakelaar om functionaliteit te bieden voor verticale (functies en gegevensgroepen) en horizontale (specifieke instanties van gegevens in een gegevensgroep) autorisaties van gegevens. De achterliggende reden hiervoor is dat bepaalde gegevens gevoelig zijn en niet zomaar uitgewisseld mogen worden met andere applicaties. Dit geldt met name voor GBA- en WOZ-gegevens, conform wetten GBA en Bescherming Persoonsgegevens. Gegeven dat applicaties zoveel mogelijk onafhankelijk van elkaar zouden moeten zijn en dat niet alle applicaties op een goede manier met autorisaties omgaan, impliceert dit autorisatiefunctionaliteit buiten de applicaties zelf.

Als je beseft dat de kwaliteit van gegevens in bronapplicaties niet altijd goed is dan is het belangrijk dat een gegevensmakelaar ook controles uitvoert op de gegevens die worden uitgewisseld. Hierdoor wordt geborgd dat alleen kwalitatief hoogwaardige gegevens worden overgebracht van bron- naar doelapplicaties. Een specifieke vorm van controle is een consistentiecontrole die controleert of gegevens in een bronapplicatie (basisregistratie) overeenkomen met gegevens in de doelapplicatie en een rapport genereert met alle verschillen. Dit is een belangrijke input om de initiële opschoning van gegevens uit te voeren en dit mogelijk ook periodiek te herhalen. Hierin zal veel energie gaan zitten bij het aansluiten van een nieuwe applicatie. Een probleem met applicaties is dat ze niet altijd beschikbaar zijn. Om hiermee goed om te kunnen gaan zal een gegevensmakelaar wijzigingen ook tijdelijk moeten kunnen bewaren (queueing) totdat de doelapplicatie wel beschikbaar is. Dit voorkomt dat gegevens verloren gaan en dat er als gevolg daarvan inconsistenties in gegevens ontstaan.

Een belangrijke standaard voor gegevensuitwisseling binnen gemeenten is de StUF-standaard [EGEM, 2006]. Deze standaard beschrijft zowel het gegevensmodel voor gegevensuitwisselingen als de technische wijze waarop dit plaats vindt. StUF is gericht op de uitwisseling van basisgegevens; niet-basisgegevens (oftewel taakspecifieke gegevens) worden standaard niet ondersteund. Het is duidelijk dat een gegevensmakelaar in de context van gemeenten in ieder geval StUF als uitwisselingsformaat zal moeten ondersteunen. Dit maakt het ook een heel specifiek component voor de gemeentemarkt dat standaard al veel kennis heeft van specifieke gegevens. Hierdoor is het ook mogelijk om hele standaard koppelingen tussen applicaties te realiseren die zonder maatwerk kunnen worden gerealiseerd. Gegeven het beperkte budget van veel gemeenten is dat erg belangrijk.

Een interessante uitdaging is dat een gegevensmakelaar ook goed om moet gaan met evolutie van de StuF-standaard. Dit betekent dat het ook vertalingen moet kunnen uitvoeren tussen verschillende versies van StUF. Een andere uitdaging is dat er inmiddels behoefte is aan meer gegevens dan wat StUF momenteel ondersteunt. Dit vloeit ondermeer voort uit de algemene ambities van de gemeente zoals beschreven in de inleiding. Daarnaast dekt de StUF op dit moment ook niet de geometrische gegevens die kunnen worden gebruikt om gegevens op kaarten te presenteren zoals groen, weg en topografische kaartgegevens. Daar is wel veel behoefte aan. Dit betekent dat leveranciers hiervoor eigen oplossingen moeten maken.

Een laatste belangrijke functionaliteit is de koppeling van applicaties en/of basisregistraties met de landelijke voorzieningen. Hierin speelt de overheids service bus (OSB) een belangrijke rol; dit is een verzameling standaarden en richtlijnen voor uitwisselen van gegevens tussen overheidsorganisaties. De intentie is om op termijn de landelijke voorzieningen beschikbaar te stellen via de OSB; op dit moment is dat nog niet het geval (voor zover landelijke voorzieningen al beschikbaar zijn).

Inzichten

Ik beschrijf de meest relevante inzichten die in de gemeente Gouda zijn ontstaan na het uitvoeren van het onderzoek naar beschikbare oplossingen voor een gegevensmakelaar. Het belangrijkste is dat de onderzochte oplossingen de meest belangrijke functionaliteiten bevatten van een gegevensmakelaar zoals geïdentificeerd vanuit het perspectief van het aansluiten bij basisregistraties. Waar de producten te kort schieten is in de aansluiting op de landelijke voorzieningen; hiervoor wordt door leveranciers nog gewerkt aan specifieke oplossingen. Het advies op dit moment is om aansluiting op landelijke voorzieningen vooral nog vanuit de basisregistratie zelf te realiseren. Daarnaast bieden de producten in de meeste gevallen alleen StUF gebaseerde uitwisselingen waardoor uitwisseling van niet-basisgegevens niet mogelijk is.

Een belangrijk inzicht is dat leveranciers een sterk onderscheid maken tussen de functionaliteit voor de synchronisatie van basisgegevens tussen backoffice-applicaties (backoffice broker) en het ontsluiten van gegevens richting de frontoffice (frontoffice broker). De eerste past op de behoefte vanuit de aansluiting op basisregistraties en kan worden gezien als een broker specifiek gericht op StUF-uitwisseling. De tweede wordt door leveranciers gezien als de oplossing voor de Gemeentelijke Service Bus. Belangrijke functionaliteiten van deze Gemeentelijke Service Bus zijn de routering en logging van berichten, alsook de verbinding met de OSB en daarmee de landelijke voorzieningen. Belangrijk is ook de ondersteuning voor niet-StUF-berichten, gebaseerd op webservices-standaarden. Tenslotte is er ook enige ondersteuning voor processturing en bedrijfsregels, alhoewel ook duidelijk is dat deze functionaliteit eigenlijk in een separaat BPM-component zou moeten liggen. Overigens is het onderscheid tussen een back-office broker en een frontoffice broker niet per definitie noodzakelijk; zo heeft de gemeente Rotterdam een oplossing gerealiseerd die beide functionaliteiten ondersteunt.

Als gevolg van voorgaand inzicht is helder dat de primaire behoefte van de gemeente Gouda kan worden ingevuld door een product dat is gericht op synchronisatie van basisgegevens (back-office broker). Dit roept wel vragen op over de implementatie van een (volwaardige) gemeentelijke service bus. Het is helder dat dit een concept is met toegevoegde waarde zoals de uitwisseling van niet-basisgegevens, de koppeling met de landelijke voorzieningen en de koppeling richting BPM. Of deze toegevoegde waarde ook te vertalen is naar een concrete business case vraagt echter nader onderzoek. In het bijzonder zou deze business case vooral moeten komen vanuit een integrale visie op front- en mid-office waarin ook andere onderdelen als een KCC, zakensysteem, zakenmagazijn en gegevensmagazijn een duidelijke rol vervullen. Ook dient deze visie vertaald te worden naar een realistische architectuur. Uitdaging daarbij is dat onderdelen grotendeels met pakketapplicaties moeten worden ingevuld aangezien veel gemeenten zich geen maatwerk kunnen veroorloven.

Conclusies

Het is door het onderzoek helder geworden wat de impact van de basisregistraties is op de informatiehuishouding van de gemeente. Ook is duidelijk dat een oplossing gebaseerd op synchronisatie van basisgegevens op dit moment voldoende is om de wettelijke eisen rondom eenmalige uitvraging en meervoudig gebruik in te vullen. Daarnaast is het inzicht ontstaan dat de inzet van een gemeentelijke service bus een bredere visie en architectuur vraagt. Vooralsnog lijkt de inzet van een backoffice broker nog niet bij te dragen aan het groeipad naar service-oriëntatie. Het is vooral gericht op het compenseren van het gebrek aan service-oriëntatie in de huidige backoffice-applicaties. Het onderzoek is erg gericht geweest op de informatievoorziening. Er is wel onderkend dat de implementatie van basisregistraties ook consequenties heeft voor organisatie en procesinrichting. De functies gegevens- en procesbeheer zullen in de toekomst een centrale rol krijgen. Gemeenten zullen dan ook de komende jaren nog druk bezig zijn met de verdere implementatie van basisregistraties.