Aan deze wiki wordt momenteel gewerkt. Het kan zijn dat tijdens deze werkzaamheden links niet werken of dat sommige views niet of onvolledig getoond worden.

Katern GEMMA Verbinden


GEMMA Patronen

Bij het ondersteunen van gemeentelijke processen zijn generieke problemen te onderkennen waarvoor standaard oplossingen beschikbaar zijn. Deze standaard oplossingen worden binnen de GEMMA ‘patronen’ genoemd. Deze patronen maken gebruik van de in het voorgaande hoofdstuk beschreven referentiecomponenten en integratiestijlen. Dit hoofdstuk beschrijft deze generieke patronen en beschrijft de standaard wijze waarop de verschillende referentiecomponenten ingezet kunnen worden om de patronen te ondersteunen. Door VNG Realisatie worden overige architectuurproducten en standaarden gebaseerd op deze patronen.

Verbinden binnengemeentelijke componenten


Binnengemeentelijk worden componenten op allerlei vlakken met elkaar verbonden. Denk bijvoorbeeld aan een baliecomponent die voor het opvragen van persoonsgegevens gebruik maakt van een gegevensmagazijncomponent of een informatiesysteem wat documenten opslaat in een documentmanagementsysteem. Dergelijke integratie van systemen kan tot stand worden gebracht door directe integratie tussen de systemen (zogenaamde point-to-point verbindingen) koppelingen of via een verbindend servicebuscomponent. In beide varianten is het mogelijk om de integratie via standaard koppelvlakken of leverancier-specifieke koppelvlakken tot stand te brengen.

Het koppelen via point-to-point verbindingen leidt al snel tot een complex en onoverzichtelijk landschap waarover de gemeente niet meer in-control is. Potentieel leidt dit bij n applicaties tot (n*(n-1))/2 koppelingen. Point-to-point koppelingen zijn kwetsbaar doordat ze vaak niet goed gedocumenteerd zijn, of niet bekend zijn. Bij verstoringen is het oplossen van problemen daardoor vaak ingewikkeld. Om deze redenen wordt deze wijze van binnengemeentelijk integreren van informatiesystemen door VNG Realisatie afgeraden. Ook het integreren via leverancier-specifieke koppelvlakken wordt door VNG Realisatie afgeraden. Reden hiervoor is dat het implementeren van leverancier-specifieke koppelvlakken leidt tot specifieke koppelingen waarmee afhankelijkheid richting een specifieke leverancier in de hand wordt gewerkt. Het inzetten van gestandaardiseerde koppelvlakken heeft te allen tijde de voorkeur. Om redenen van flexibiliteit in de informatiearchitectuur en leveranciersonafhankelijkheid heeft het de voorkeur om te integreren via koppelvlakstandaarden.

Beschrijving GEMMA patroon

Aanbevolen wordt om voor het binnengemeentelijk integreren van informatiesystemen gebruik te maken van webservices, koppelvlakstandaarden en de diensten van een servicebuscomponent. De inzet van deze beide elementen garandeert flexibiliteit en overzicht in de informatiearchitectuur en draagt bij aan het in control zijn van de informatiearchitectuur.

Vanuit de GEMMA architectuur wordt aangeraden om servicekoppelingen tussen informatiesystemen uitsluitend via goed gedefinieerde eindpunten te laten verlopen. Een eindpunt levert een beschrijving die wordt gebruikt om een bericht naar te adresseren en wordt beschreven in een WSDL (Web Services Definition Language). Een WSDL-document is een XML-document dat het uiterlijk van een webservice beschrijft. Het beschrijft het de syntax en structuur van het bericht waarmee de webservice aangesproken kan worden en beschrijft het bericht dat de webservice als antwoord geeft. In het groter geheel wordt het WSDL document meegeleverd met de webservice wanneer deze zich inschrijft in een serviceregistercomponent, zodat de afnemers van de webservice weten hoe de service werkt.

Aanbeveling is om bij dit patroon altijd een servicebuscomponent in te zetten als intermediair tussen Informatiesysteem A en Informatiesysteem B. Inzet van een servicebuscomponent heeft een aantal voordelen:

  • Goede mogelijkheden voor het centraal monitoren van koppelingen;
  • Mogelijkheid voor toepassing van centrale authenticatie en autorisatie;
  • Mogelijkheden tot routering en orkestratie van serviceaanroepen;
  • Transformatie van gegevens.

Onderstaande figuur geeft de integratie van twee informatiesystemen via de gemeentelijke servicebus schematisch weer [1]. De relatie tussen de twee informatiesystemen wordt hierbij gelegd door een service die door de servicebuscomponent wordt geleverd.




Aandachtspunten

Aandachtspunt bij dit patroon is het feit dat de servicebuscomponent potentieel een single-point-of-failure in de informatievoorziening kan worden. Gevolg van de uitval van de servicebuscomponent zou uitval van een groot aantal koppelingen veroorzaken, en daarmee een risico vormen voor de continuïteit van de dienstverlening. Maatregelen dienen getroffen te worden om dit te voorkomen. Hierbij kan bijvoorbeeld gedacht worden aan het dubbel uitvoeren van de servicebuscomponent en het beschrijven van procedures die gevolgd moeten worden in geval van uitval van de servicebuscomponent.

Standaarden

Uitgangspunt bij het integreren van binnengemeentelijke informatiesystemen is dat deze integratie zoveel mogelijk gebaseerd is op via StUF gestandaardiseerde koppelvlakstandaarden. Voorbeelden hiervan zijn de GEMMA zaak-document services en e-formulier en RSGB bevragingen services. De servicebuscomponent dient deze verschillende koppelvlakstandaarden te ondersteunen.

  1. Modellering conform de Archimate best practices.

Verbinden met keten- en netwerkpartijen


Gemeenten maken door veranderende wetgeving en decentralisatie van taken deel uit van een groot aantal nieuwe ketens en netwerken. Het aantal publieke, maar ook private, partijen waarmee gemeenten gegevens uitwisselen neemt hierdoor in een rap tempo toe. Voorbeelden hiervan zijn de Werk en Inkomen keten waar de Suwi-partijen een rol spelen, de jeugdketen waarin diverse justitiële partijen en jeugdzorgaanbieders betrokken zijn en de zorgketen waarin onder andere de zorgaanbieders een belangrijke rol hebben.

Beschrijving GEMMA patroon

Het aansluiten van alle individuele gemeenten op de verschillende keten- en netwerkpartners zou leiden tot een onbeheersbare wirwar aan verbindingen tussen organisaties. Aanbevolen wordt om voor het integreren van gemeentelijke systemen met systemen van ketenpartners (zowel private en publieke partijen) zoveel mogelijk gebruik te maken van de diensten van een gemeentelijk knooppunt. Een knooppunt levert als intermediair of ontkoppelpunt de functionaliteit die op het gebied van het koppelen aan sectorale- en stelselvoorzieningen door gemeenten vereist is. Een knooppunt koppelt aan de verschillende ketens en sectorale voorzieningen en biedt gemeenten toegang tot deze ketens en voorzieningen via gestandaardiseerde koppelvlakken en connectiviteit. Een gemeentelijk knooppunt is een organisatie met een ingerichte governance, ketensturing en structurele financiering. Een knooppunt functioneert als intermediair tussen het gemeentelijk domein en andere domeinen en kent als afnemers gemeenten en samenwerkingsverbanden van gemeenten. Een gemeentelijk knooppunt biedt standaard diensten die generiek toepasbaar zijn en specifieke diensten voor een domein of thema.

Gemeenten sluiten aan op gemeentelijke knooppunten en gebruiken diensten van de knooppunten om te verbinden met ketenpartijen uit andere domeinen. Gemeenten worden hierdoor ontzorgd in hun informatievoorziening waardoor ruimte wordt gecreëerd voor lokale autonomie in de uitvoering van hun kerntaken.

Onderstaande figuur geeft schematisch het stelsel voor gegevensuitwisseling gebruik makend van knooppunten weer.

Het generieke stelsel voor gegevensuitwisseling: een samenspel van stelsels
Figuur - Het generieke stelsel voor gegevensuitwisseling


In bovenstaand figuur zijn aan de linkerkant een drietal gemeentelijke knooppunten weergegeven. Elk van deze gemeentelijke knooppunten biedt eigen knooppuntvoorzieningen en op een gemeentelijk knooppunt kunnen meerdere gemeenten aangesloten zijn. Gemeentelijke knooppunten verzorgen:

  • Toegang tot gemeentelijke knooppuntdiensten,
  • Toegang tot de voorzieningen van de GDI,
  • Verbinding met knooppunten van andere sectoren,
  • Vertaling van stelsel of ketenstandaarden naar gemeentelijke standaarden.

Bij de uitwisseling van gegevens met keten- en netwerkpartijen zijn privacy en beveiliging, en verantwoording en transparantie aspecten waar bijzondere aandacht aan gegeven moet worden. De uitwisseling van gegevens en informatie met ketenpartijen moet op een veilige en herleidbare wijze plaatsvinden. Daar waar gevoelige (persoon)gegevens worden uitgewisseld dienen specifieke maatregelen genomen te worden om de vertrouwelijkheid van deze gegevens te borgen. De uitwisseling van gegevens met ketenpartijen moet op een transparante wijze plaatsvinden. Te allen tijde moet duidelijk zijn welke (categorieën van) gegevens zijn uitgewisseld. Deze transparantie is vereist om hierover verantwoording af te kunnen leggen. Gemeentelijke knooppunten geven invulling aan de eisen die vanuit de gemeentelijke organisatie gesteld worden aan beveiliging en transparantie. Vanuit een groot aantal domeinen wordt door gemeenten samengewerkt in ketens en netwerken. Denk bijvoorbeeld aan het sociaal domein waar vanuit de uitvoering van de Wmo 2015, de Jeugdwet en de Wet Werk en Inkomen met een groot aantal private en publieke partijen gegevens worden uitgewisseld.

Aandachtpunten

Niet voor alle ketens zijn gemeentelijke knooppunten beschikbaar. Daar waar geen knooppunt beschikbaar is kan door de gemeente direct worden aangesloten op de diensten van keten- en netwerkpartners.

Standaarden

Uitgangspunt bij het integreren van gemeentelijke informatiesystemen met informatiesystemen van keten- of netwerkpartners via knooppunten is dat dit zoveel mogelijk gebaseerd is op standaard koppelvlakken en berichtstandaarden. Indien integratie plaatsvindt over verschillende partijen heen wordt de voorkeur gegeven aan ketenstandaarden. Dergelijke standaarden kunnen gebaseerd zijn op StUF maar ook op andere standaarden. Voorbeelden van ketenstandaarden zijn StUF-CORV in de Jeugdhulp keten, SuwiML in de Werk en Inkomen keten en iWmo en iJw in de Wmo- en Jeugdketen. Vertaling van ketenstandaarden naar gemeentelijke standaarden is gewenst indien de berichten uit de ketenstandaard binnengemeentelijk meervoudig worden gebruikt. Indien verwerking van de berichten beperkt is tot specifieke taak-specifieke applicaties is vertaling niet nodig. Voorbeelden van standaarden die om deze redenen niet naar de gemeentelijke StUF-berichtstandaarden vertaald worden zijn SuwiML in de Werk en Inkomen keten, iWmo in de Maatschappelijke Ondersteuning keten en iJw in de Jeugdzorgketen.

Inwinnen en routeren van notificaties


Informatiesystemen hebben de mogelijkheid om op het moment dat er een bepaalde gebeurtenis plaatsvindt een melding hiervan te maken ten behoeve van andere processen en systemen. Hierbij kan bijvoorbeeld gedacht worden aan een melding dat een burger een bepaalde dienst heeft afgenomen of dat een proces een bepaalde status bereikt heeft. Voorbeelden hiervan zijn de verhuizing van een klant, het overleiden van een persoon of het op naam zetten van een voertuig. Deze gebeurtenissen kunnen er toe leiden dat lopende processen gestopt of aangepast moeten worden of dat nieuwe processen opgestart moeten worden. Een voorbeeld hiervan is een notificatie die vanuit de Basisregistratie voertuigen (BRV) verzonden wordt over het op naam zetten van een voertuig door een persoon. Niet alle systemen en basisregistraties bieden de mogelijkheid om notificaties te verzenden. Met name de basisregistraties zouden dit vanuit het perspectief van de gemeenten eigenlijk wel moeten doen. Deze notificatie kan interessant zijn voor sociale dienst indien de persoon die het voertuig op naam heeft gezet gebruik maakt van gemeentelijke uitkeringen of toeslagen. In dat geval zou de notificatie een aanleiding kunnen zijn op een onderzoek te starten naar het vermogen van de betreffende persoon. Voertuigbezit valt immers onder persoonlijk vermogen en het vermogen kan bepalend zijn voor hoogte van, en op recht op bepaalde toeslagen en uitkeringen.

Beschrijving GEMMA patroon

Het patroon voor implementatie van de inwinning en routering van notificaties maakt gebruik van de servicebuscomponent, de notificatierouteringcomponent en het loggingcomponent.

De notificatierouteringcomponent heeft als taak het inwinnen, loggen en routeren van notificaties. Onderstaande figuur geeft weer hoe het patroon vorm gegeven kan worden. Informatiesystemen die notificaties willen publiceren doen dat door zich als bron van notificaties te registreren bij de notificatierouteringcomponent. Hierbij worden de verschillende soorten notificaties (context) via de notificatierouteringcomponent beschikbaar gesteld aan geabonneerde systemen. De systemen die notificaties willen ontvangen maken zich kenbaar bij de notificatierouteringcomponent als afnemer, en stellen per notificatie die zij willen ontvangen een abonnement in. De notificaties waarop een abonnement is in te stellen zijn de notificaties die door de verschillende aanleverende systemen worden geleverd aan de notificatierouteringcomponent.

De koppeling tussen bronnen van notificaties en de notificatierouteringcomponent wordt gelegd via implementatie van de externe applicatiefunctionaliteit aanroep integratiestijl. Bronnen leveren dus via een service van de servicebuscomponent notificaties aan. De servicebuscomponent routeert de ontvangen notificaties naar de notificatierouteringcomponent. Deze component routeert de ontvangen notificaties op basis van ingestelde abonnementen door naar afnemers. De routering bestaat uit het aanroepen van een service van het afnemende systeem. Het betreft hier dus een push-koppeling vanuit de notificatierouteringcomponent naar de afnemer. Afnemers nemen afhankelijk van eigen bedrijfsregels actie op een ontvangen notificatie.

Alle componenten die betrokken zijn in aanmaak, routering en afhandeling van notificaties loggen de verwerkingen ten aanzien van de notificaties via de loggingcomponent.

Component voor ontvangen van notificaties van bronsystemen en het routeren daarvan naar geabonneerde afnemers. (ApplicationComponent) Notificatierouteringcomponent Generieke weergave van de landelijke basisregistraties. Deze generieke weergave wordt gebruikt in de modellering van GEMMA patronen. (ApplicationComponent) Basisregistraties en landelijke voorzieningen Abstract verzamelcomponent voor Specifieke procesafhandelcomponenten. Dit zijn taak-specifieke systemen waarin zaakgericht gewerkt of op zijn minst zaakgericht geregistreerd wordt. Systemen die invulling geven aan deze referentiecomponent moeten zaakinformatie kunnen bijwerken in een Zakenregistratiecomponent (ZRC) via de standaard Zaak-documentservices. (ApplicationComponent) Specifiek Procesafhandelcompo- nent (abstract component) Abstract verzamelcomponent voor Specifieke procesafhandelcomponenten. Dit zijn taak-specifieke systemen waarin zaakgericht gewerkt of op zijn minst zaakgericht geregistreerd wordt. Systemen die invulling geven aan deze referentiecomponent moeten zaakinformatie kunnen bijwerken in een Zakenregistratiecomponent (ZRC) via de standaard Zaak-documentservices. (ApplicationComponent) Specifiek Procesafhandelcompo- nent (abstract component) Component voor het centraal vastleggen van gegevens over de activiteiten die gebruikers uitvoeren met vertrouwelijke gegevens. (ApplicationComponent) Loggingcomponent ApplicationComponent Sectoraal knooppunt FlowRelationship leveren notificatie Generieke weergave van een sectoraal knooppunt. Deze generieke weergave wordt gebruikt in de modellering van GEMMA patronen. (FlowRelationship) leveren notificatie FlowRelationship routeren notificatie naar afnemer FlowRelationship instellen abonnementen FlowRelationship aanmelden als afnemer FlowRelationship logging van ontvangst en afhandeling notificatie FlowRelationship logging van ontvangst en afhandeling notificatie FlowRelationship loggen verzending notificatie FlowRelationship leveren notificatie Deze svg is op 21-12-2018 01:27:23 CET gegenereerd door ArchiMedes © 2016-2018 XL&Knowledge. ArchiMedes 21-12-2018 01:27:23 CET


Aandachtpunten

Ten behoeve van de processen vanuit het Werk en Inkomen domein is vanuit het Inlichtingenbureau een dienst beschikbaar die doorlopend controleert of er omstandigheden zijn te melden die van invloed kunnen zijn op het recht op bijstand van cliënten. Het resultaat van deze controle levert het Inlichtingenbureau in de vorm van samenloopsignalen aan gemeenten. Deze samenloopsignalen zouden gezien kunnen worden als notificaties. Indien de gemeente al gebruik maakt van deze dienst dat is deze naar verwachting direct op de gemeentelijke backoffice aangesloten.

Standaarden

Vanuit de GDI is Digilevering gepositioneerd als voorziening voor het verzenden van, en abonneren op notificaties van basisregistraties. Deze voorziening is niet voor alle basisregistraties operationeel. De BRP kent een eigen voorziening voor het leveren van notificaties, en een aantal basisregistraties kennen het systeem van notificaties niet. Standaardisatie op het gebied van notificaties op landelijk niveau ontbreekt dus vooralsnog. Vanuit de Zaak – Regieservices koppelvlakstandaard zijn notificaties beschreven die uitgewisseld worden tussen zaaksystemen en regiesystemen.

Binnengemeentelijk beschikbaar stellen basis- en kerngegevens


Vanuit diverse processen is er tijdens de uitvoering van de processen behoefte aan gegevens uit basis- en kernregistraties. Deze gegevens kunnen door de processen worden opgehaald bij de bron op het moment dat de gegevens binnen een proces nodig zijn maar er kan ook voor gekozen worden om kopieën van de gegevens bij te houden binnen de administratie van de component die het proces automatiseert. De kopiegegevens worden in dat geval actueel en synchroon gehouden met de bron door een distributiemechanisme [1]. We spreken hierbij over zogenaamde ‘push’ en ‘pull’ mechanismes.

Pullmechanisme – Bij een pullmechanisme haalt een afnemer de gegevens die nodig zijn bij de uitvoering van een proces op bij de bron. De afnemer houdt zelf geen kopieën van deze gegevens bij. De implementatie van een pullmechanisme heeft de voorkeur boven een pushmechanisme aangezien bij een pullmechanisme gegevens niet onnodig door het systeemlandschap gedistribueerd worden. Een pullmechanisme wordt vaak in combinatie met de Inwinnen en routeren van notificaties integratiestijl gebruikt. Gebeurtenissen worden dan door bronnen via notificaties aan afnemers kenbaar gemaakt en de afnemers halen op basis van deze gebeurtenissen de bij de gebeurtenis behorende gegevens op.

Pushmechanisme - Bij een pushmechanisme worden kopieën van gegevens in een administratie actueel gehouden via een distributiemechanisme en bij een pullmechanisme worden gegevens uit de bron gelezen op het moment dat ze nodig zijn. De keuze voor implementatie van een pull- of een push-mechanisme is mede afhankelijk van de beschikbaarheid van bronnen. Op het moment dat de serviceniveaus van bronnen niet aansluiten bij de gewenste serviceniveaus vanuit processen wordt veelal een push-mechanisme gebruikt. De reden hiervoor is dat bij gebruik van een push-mechanisme de afnemer altijd beschikt over near-realtime gegevens en bevraging van de bron daardoor onnodig is. Dit systeem wordt ook wel datareplicatie genoemd. Bij datareplicatie worden gegevens van een bronsysteem door andere informatiesystemen opgeslagen binnen hun eigen opslag en near real-time bijgehouden.

In dit patroon wordt beschreven op welke manier basis- en kerngegevens via een pushmechanisme beschikbaar kunnen worden worden gesteld gebruik makend van de GEMMA referentiecomponenten.

Beschrijving GEMMA patroon

In dit patroon zijn een aantal keuzes gemaakt ten aanzien van de wijze waarop gegevens beschikbaar worden gesteld aan afnemers en de manier waarop afnemers gerede twijfel aan de juistheid van gegevens kunnen melden.

  • Basisgegevens - De keuze is gemaakt om voor het binnengemeentelijk beschikbaar stellen van basisgegevens gebruik te maken van een pushmechanisme via de berichtuitwisseling integratiestijl. Er wordt ten aanzien van de gegevens uit basisregistraties dus gekozen voor datareplicatie. De reden voor deze keuze is het feit dat niet alle basisregistraties op een efficiënte en effectieve wijze bevraagbaar zijn via een pull-mechanisme en niet de serviceniveaus bieden die door gemeenten gewenst zijn. De keuze voor datareplicatie betekent dat basisregistraties mutaties van basisgegevens doorgeven aan gemeenten en gemeenten de verdere distributie van deze mutaties regelen via een gegevensdistributie-component;
  • Kernregistratiegegevens - De keuze is gemaakt om voor het binnengemeentelijk beschikbaar stellen van gegevens uit kernregistraties, zoals de kernregistratie medewerkers, via een pull-mechanisme te verlopen. De reden voor deze keuze is dat de gemeente zelf in-control is van serviceniveaus die geboden worden door kernregistraties. Het intern afstemmen van deze serviceniveaus op de door processen gewenste serviceniveaus is daardoor mogelijk en replicatie van de kerngegevens binnen taakspecifieke componenten is hiermee overbodig. De kerngegevens kunnen immers door processen direct uit de bron betrokken worden. Dit doet recht aan de principes van eenmalige vastlegging en meervoudig gebruik;
  • Terugmelding van gerede twijfel aan de juistheid van gegevens wordt door taakspecifieke componenten gemeld via de terugmeldingenregistratiecomponent. Deze component biedt functionaliteit om terugmeldingen van gerede twijfel te ontvangen en te routeren naar hetzij een basis- hetzij een kernregistratie.

Onderstaande figuur geeft schematisch de binnengemeentelijke levering en gebruik van gegevens uit basis- en kernregistraties weer.

Generieke weergave van de gemeentelijke kernregistraties. Deze generieke weergave wordt gebruikt in de modellering van GEMMA patronen. (ApplicationComponent) Kernregistratiecomponent Generieke weergave van de landelijke basisregistraties. Deze generieke weergave wordt gebruikt in de modellering van GEMMA patronen. (ApplicationComponent) Basisregistratie Component voor het doen van terugmeldingen over gegevens bij twijfel aan de juistheid daarvan. (ApplicationComponent) Terugmeldingen-registratiecomponent Abstract verzamelcomponent voor Specifieke procesafhandelcomponenten. Dit zijn taak-specifieke systemen waarin zaakgericht gewerkt of op zijn minst zaakgericht geregistreerd wordt. Systemen die invulling geven aan deze referentiecomponent moeten zaakinformatie kunnen bijwerken in een Zakenregistratiecomponent (ZRC) via de standaard Zaak-documentservices. (ApplicationComponent) Specifiek Procesafhandelcomponent (abstract component) Component voor distributie van gemeentelijke basis-, en optioneel, kerngegevens naar afnemende applicaties binnen de gemeente. Het gegevensdistributiesysteem wordt gevoed vanuit applicaties die basis- en kerngegevens onderhouden. (ApplicationComponent) Gegevensdistributiecomponent Component voor opslag en ontsluiting van basis- en aangehaakte gegevens. (ApplicationComponent) Gegevensmagazijncomponent FlowRelationship afnemen kerngegevens FlowRelationship aanleveren kerngegevens FlowRelationship Melding gerede twijfel FlowRelationship Melding gerede twijfel FlowRelationship terugmelden- gerede twijfel FlowRelationship instelllen distributiereg- els FlowRelationship instellen abonnement- en FlowRelationship leveren kennisgeving- en FlowRelationship synchroniser- en gegevens FlowRelationship FlowRelationship levering kennisgevingen van mutatie van gegevens FlowRelationship leveren kennisgeving- en FlowRelationship instellen abonnement- en FlowRelationship instellen distributiereg- els FlowRelationship synchroniser- en gegevens FlowRelationship plaatsen afnemerindic- aties Deze svg is op 21-12-2018 01:27:24 CET gegenereerd door ArchiMedes © 2016-2018 XL&Knowledge. ArchiMedes 21-12-2018 01:27:24 CET


Aandachtspunten

De keuze voor datareplicatie bij basisgegevens via een gegevensmagazijncomponent is ingegeven door het feit dat er geen alternatieven zijn. Redenen hiervoor zijn de door basisregistraties geboden serviceniveaus en restricties op de afname van gegevens door afnemers bij basisregistraties. Datareplicatie is in de visie van VNG Realisatie een tijdelijke oplossing. Zodra de basisregistraties geschikt zijn voor directe bevraging kan worden overgestapt op een pull-mechanisme.

Standaarden

Ten aanzien van de distributie van basisgegevens dient binnengemeentelijk gebruik gemaakt te worden van StUF-BG berichten. Aanlevering van mutaties door basisregistraties verloopt via diverse (StUF) berichtsoorten. De BRP levert mutaties via StUF-BG, de NHR levert StUF-HR, de BRK levert BRK-Leveringen en de BAG levert StUF-BAG.

  1. zie ook Integratiestijlen en functies.

Beschikbaar stellen managementinformatie


Managementinformatie bestaat uit de gegevens die nodig zijn voor de besturing en beheersing van de organisatie alsmede de gegevens die nodig zijn om horizontale en verticale verantwoording over het functioneren van de organisatie af te leggen. In het kort gaat het dus om stuur- en verantwoordingsinformatie. In dit patroon wordt beschreven op welke manier het beschikbaar stellen van managementinformatie ingericht kan worden gebruik makend van de GEMMA referentiecomponenten.

Beschrijving GEMMA patroon

Aan het patroon voor het beschikbaar stellen van managementinformatie wordt invulling gegeven door de data-warehousecomponent en de managementinformatiecomponent. Gegevens worden aan de data-warehousecomponent aangeleverd door basisregistraties, kernregistraties, taakspecifieke informatiesystemen en eventuele andere bronnen. Deze aanleverende bronnen gebruiken hiervoor meestal een techniek die op de bestandsuitwisseling integratiestijl gebaseerd is. Denk hierbij aan ETL-processen die periodiek worden uitgevoerd. Aangeleverde gegevens worden door de data-warehousecomponent ingelezen, getransformeerd en opgeslagen in het de eigen gegevensopslag. Via datamarts geeft de managementinformatiecomponent toegang tot een deelverzameling van de gegevens binnen de data-warehousecomponent. Datamarts zijn meestal specifiek voor een bepaald domein of thema.

Het is het uitdrukkelijke advies om nooit managementrapportages te genereren vanuit bronsystemen gezien de potentiële impact die deze rapportages heeft op performance en beveiligingsproblemen van die bronsystemen.




Aandachtpunten

Gegevens worden in de regel via ETL-processen aan een data-warehousecomponent aangeleverd door de verschillende bronnen. Deze processen worden periodiek uitgevoerd. De gegevens in de data-warehousecomponent kunnen daardoor gedateerd zijn. Per managementinformatierapportage moet bepaald worden of de gegevens in de data-warehousecomponent voldoen aan de kwaliteitseisen die vanuit de rapportage vereist zijn. Indien niet aan de gestelde eisen voldaan kan worden zullen de aanleverprocessen, of de periodiciteit waarmee gegevens aangeleverd worden aangepast moeten worden. De data-warehousecomponent bevat enkel kopieën van gegevens. Eventuele inhoudelijke aanpassing van gegevens dient plaats te vinden in de broncomponent en niet in de data-warehousecomponent.

Standaarden

Op het gebied van de inrichting van een data-warehousecomponenten, en wijze waarop gegevens aangeleverd worden aan data-warehousecomponenten, zijn geen gemeentelijke standaarden gedefinieerd.

Dienstverlening naar klanten


Het gemeentelijke digitale kanaal is in de dienstverlening een steeds belangrijker kanaal voor gemeenten. Klanten kunnen via het digitale kanaal worden voorzien van informatie en klanten kunnen dit kanaal gebruiken om diensten en producten mee af te nemen. Gemeenten bieden klanten hiertoe publiek beschikbare informatie via de gemeentelijke website en gepersonaliseerde gegevens en diensten via een beveiligde persoonlijke internet pagina. Via de gemeentelijke website publiceert de gemeente openingstijden, geplande evenementen, bouwprojecten, beschikbare producten en diensten, et cetera. Via een persoonlijke internet pagina kunnen klanten hun persoonlijke gegevens mee in te zien en gemeentelijke producten en diensten aanvragen. Het is ook mogelijk om de klant zijn eigen gegevens te laten muteren. Door de burger directe controle te geven over zijn gegevens zal de burger in toenemende mate zelfredzaam worden. Het muteren van de gegevens door de klant is uiteraard alleen mogelijk daar waar de wettelijke kaders daar ruimte toe bieden.

Het operationaliseren van de informatievoorziening voor het digitale loket is geen sinecure. Klanten hebben verwachtingen en eisen ten aanzien van beschikbaarheid van de diensten, beveiliging van gegevens en bescherming van de privacy. Daarnaast is de betrouwbaarheid, correctheid en accuraatheid van de gegevens die in het digitale kanaal gebruikt worden voor de kwaliteit van de dienstverlening van cruciaal belang. Dit alles stelt eisen aan de inrichting van de ondersteunende gemeentelijke informatievoorziening.

Beschrijving GEMMA patroon

Dit patroon gaat uit van een inrichting van de informatiearchitectuur waarmee de beschikbaarheid van gegevens ten behoeve van de digitale dienstverlening aan de klanten geborgd kan worden. In dit patroon zijn de volgende uitgangspunten gehanteerd:

  • Gebruik van de servicebuscomponent voor het verbinden van componenten conform het ‘Verbinden binnengemeentelijke componenten’ patroon;
  • Ontsluiting van publieke ongestructureerde gegevens via de websitecomponent. Deze component heeft hierbij een dubbelfunctie. Enerzijds is dit component de ontsluiting naar de klanten (de website) en anderzijds heeft deze component de verantwoordelijkheid om content van verschillende systemen te combineren en te publiceren. Voorbeeld van een content aanleverende component is de Bestuur- en Raadsinformatiecomponent;
  • Ontsluiting van publieke gestructureerde gegevens via opendataportaalcomponent. Deze component ontvangt de publieke gestructureerde gegevens van taakspecifieke componenten. Het is de verantwoordelijkheid van aanleverende componenten om te bepalen welke gegevens in aanmerking komen om gepubliceerd te worden als publieke gegevens (open data);
  • Toegang tot privacygevoelige gegevens via de per klantsoort (burger/bedrijf/instelling) beschikbare authenticatiemiddelen[1].;
  • Gebruik van de gegevensmagazijncomponent en landelijke voorzieningen als bronnen voor het voorinvullen van e-formulieren en product specifieke aanvragen. Uitgangspunt hierbij is toepassing van het ‘Binnengemeentelijk beschikbaar stellen basis- en kerngegevens’ patroon voor het vullen, en actueel houden van de gegevensmagazijncomponent. Of voor de voorinvulling van formulieren ten behoeve van product of dienstaanvragen de gegevensmagazijncomponent of een landelijke voorziening wordt gebruikt is een gemeentelijke keuze. Deze keuze is mede afhankelijk van de eisen die de gemeente vanuit het oogpunt van dienstverlening stelt aan de beschikbaarheid van systemen waar de dienstverlening van afhankelijk is. De gemeente heeft invloed op de beschikbaarheid van een gegevensmagazijncomponent terwijl dat bij de landelijke voorzieningen niet zo is. Het kan voor gemeenten in verband met de vereiste serviceniveaus een valide keuze zijn om de voorinvulling van e-formulieren via de gegevensmagazijncomponent te laten verlopen. Op die manier kan geborgd worden dat klanten producten en diensten aan kunnen vragen ook als de landelijke voorzieningen niet beschikbaar zijn;
  • Aanvraag van producten en diensten via een e-Formulierencomponent of een Product aanvraagcomponent. Deze componenten verzorgen het voorinvullen van al bekende (basis)gegevens en stellen klanten in staat om producten en diensten aan te vragen. Afhandeling van aanvragen wordt gedaan door hetzij de zaakbeheercomponent hetzij een taakspecifieke component;
  • Aanlevering van statusgegevens ten aanzien van de voortgang van de afhandeling van zaken door Taakspecifieke componenten en de Zaakbeheercomponent aan de Zaakregistratiecomponent;
  • Toegang van de burger tot persoonlijke gegevens via een Mijngemeentecomponent. Via deze component wordt inzage gegeven in de gegevens die de gemeente van de klant vastgelegd heeft en tevens wordt een overzicht gegeven van de zaken die er rondom deze klant spelen. Het overzicht van lopende zaken wordt geleverd door de Zaakregistratiecomponent. Inzage in persoonlijke gegevens worden geleverd door de Gegevensmagazijncomponent en Taakspecifieke componenten.

Uitgaande van de uitgangspunten ontstaat de onderstaande referentie inrichting van componenten ten behoeve van de digitale dienstverlening aan klanten.


ArchiMateNote Besloten kanaal voor klanten Component voor het ontwikkelen, publiceren, laten invullen, indienen en bevestigen van elektronische formulieren. (ApplicationComponent) E-formulieren publicatie-en beheercomponent Component die via webtechnologie veilig toegang biedt tot persoonlijke informatie en gepersonaliseerde digitale dienstverlening. (ApplicationComponent) Mijngemeentecomponent ArchiMateNote Publiek kanaal voor klanten Component waarmee open data gestructureerd beschikbaar wordt gesteld aan geïnteresseerde afnemers. (ApplicationComponent) Open-data-portaalcomponent Component voor het publiceren van informatie op de gemeentelijke website en het integreren van gespecialiseerde systemen. (ApplicationComponent) Webcontentpublicatie- en beheercomponent ArchiMateNote Gemeentelijke Informatievoorziening Component voor het afhandelen van zaken van alle typen. (ApplicationComponent) Generiek Zaakafhandelcomponent Abstract verzamelcomponent voor Specifieke procesafhandelcomponenten. Dit zijn taak-specifieke systemen waarin zaakgericht gewerkt of op zijn minst zaakgericht geregistreerd wordt. Systemen die invulling geven aan deze referentiecomponent moeten zaakinformatie kunnen bijwerken in een Zakenregistratiecomponent (ZRC) via de standaard Zaak-documentservices. (ApplicationComponent) Specifiek Procesafhandelcomponent (abstract component) Component voor het routeren, transformeren en eventueel orchestreren van berichten tussen applicaties. (ApplicationComponent) Servicebuscomponent Component voor het routeren, transformeren en eventueel orchestreren van berichten tussen applicaties. (ApplicationComponent) Servicebuscomponent Component voor het routeren, transformeren en eventueel orchestreren van berichten tussen applicaties. (ApplicationComponent) Servicebuscomponent Component voor het publiceren van informatie op de gemeentelijke website en het integreren van gespecialiseerde systemen. (ApplicationComponent) Webcontentpublicatie- en beheercomponent Component voor opslag en ontsluiting van basis- en aangehaakte gegevens. (ApplicationComponent) Gegevensmagazijncomponent Component voor opslag en ontsluiting van zaakgegevens. (ApplicationComponent) Zaakregistratiecomponent Component voor het ondersteunen en openbaar maken van het politieke proces binnen een gemeente. (ApplicationComponent) Bestuur- en Raadsinformatiecomponent Component voor het routeren, transformeren en eventueel orchestreren van berichten tussen applicaties. (ApplicationComponent) Servicebuscomponent Generieke weergave van de landelijke basisregistraties. Deze generieke weergave wordt gebruikt in de modellering van GEMMA patronen. (ApplicationComponent) Basisregistraties en landelijke voorzieningen FlowRelationship inzien en bijwerke- n van zaken FlowRelationship registrati- e aanvraag- product of dienst FlowRelationship FlowRelationship inzage en bijwerke- n van gegevens FlowRelationship Levering basisgegevens FlowRelationship inzage in gegev- ens FlowRelationship registratie aanvraag product of dienst FlowRelationship inzage in lopende zaken en aanvragen FlowRelationship inzien en bijwe- rken van zake- n FlowRelationship aanleveren publieke content FlowRelationship publicatie- van open data FlowRelationship registratie aanvraag product of dienst FlowRelationship registratie aanvraag product of dienst FlowRelationship publicatie van publieke gestructureerde content FlowRelationship pre-fill gegevens FlowRelationship aanvragen producten en diensten FlowRelationship inzage en bijwerken gegevens FlowRelationship inzage in lopende zaken en aanvragen FlowRelationship pre-fill gegevens FlowRelationship publicatie van publlieke ongestructureerde content Deze svg is op 20-12-2018 08:17:50 CET gegenereerd door ArchiMedes © 2016-2018 XL&Knowledge. ArchiMedes 20-12-2018 08:17:50 CET


In bovenstaande plaat wordt onder andere weergegeven op welke wijze de klant via een besloten kanaal diensten en producten kan aanvragen. Diensten en producten die worden aangevraagd via hetzij een generiek e-formulierencomponent of een specifiek productaanvraagcomponent worden via de servicebuscomponent ontvangen en worden doorgeleid naar het zakenregistratiecomponent. Door dit component wordt de aanvraag als een zaak geregistreerd en wordt een notificatie verzonden naar het afhandelende informatiesysteem. De wijze waarop deze notificatie wordt verzonden is beschreven in het 'Inwinnen en routeren van notificaties' patroon. Het informatiesysteem wat de notificatie ontvangt zal vervolgens de aangemaakte zaak afhandelen.

  1. zie ook Verbinden met klanten.

Voetnoten