Katern GEMMA Verbinden compleet
Inhoud
Inleiding
Let op: deze pagina is gearchiveerd
Het katern verbinden beschrijft de GEMMA “verbindingsfunctie”. De verbindingsfunctie is een aspect van de GEMMA architectuur dat van belang is voor alle niveaus van de architectuur. De verbindingsfunctie is een verzameling van richtlijnen, best-practices en normen die gelden bij het onderling verbinden van de gemeentelijke architectuurelementen. De verbindingsfunctie stelt gemeenten in staat om integratie tussen mensen, organisaties, processen en informatiesystemen op een gestandaardiseerde wijze te realiseren.
Bij de totstandkoming van de GEMMA in 2009 is de gemeentelijke verbindingsfunctie met de bijbehorende systeemoplossingen gepositioneerd als generieke verbindende informatiefunctie tussen gemeentelijke systemen, onderling en met de buitenwereld. Doel van deze generieke verbindingsfunctie was het onderling logisch ontkoppelen van informatiesystemen waardoor deze onafhankelijk van elkaar functioneren. Binnen de GEMMA 2 is de positionering van de verbindingsfunctie aangepast. Er is voor gekozen om de verbindingsfunctie net als het beveiligingsaspect te positioneren als een aspect dat alle andere architectuurelementen raakt, niet als één magische functie die alles oplost.
Het katern verbinden beschrijft de generieke verbindende applicatiefuncties maar omvat ook afspraken, richtlijnen voor de inrichting hiervan en is op onderdelen normatief ten aanzien van wijze waarop verbindingen tussen onderdelen van de architectuur gelegd worden. De verbindingsfunctie richt zich op het verbinden op zowel business als informatieniveau, zowel binnengemeentelijk als in de keten van gemeenten met hun (keten)partners.
Burgers, bedrijven en instellingen worden ‘klanten’ genoemd. Daar waar de ambtenaar van de gemeente ook als (interne) klant beschouwd kan worden, wordt deze apart genoemd.
Relatie met NORA katern verbinden
Het NORA katern verbinden beschrijft de principes voor samenwerking tussen overheden bij het bedienen van burgers en bedrijven en beschrijft de verbinding tussen klant en overheid ten aanzien van de publieke dienstverlening aan de hand van drie thema’s:
- Dienstverlening aan klanten;
- Samenhangende informatie voor klanten en overheden als voorwaarde voor een effectieve en efficiënte dienstverlening;
- Samenwerking tussen overheden.
Deze bovenstaande thema’s gelden als leidraad voor de nadere verdieping van de gemeentelijke verbindingsfunctie vanuit gemeentelijk perspectief. De GEMMA verbindingsfunctie heeft echter wel een breder bereik dan het NORA katern. Het richt zich ook op het verbinden van gemeenten intern, onderling en met haar (keten)partners. Binnen het voorliggende katern wordt gebruik gemaakt van de generieke uitgangspunten, principes en richtlijnen van het NORA katern verbinden en wordt daar waar nodig specifieke gemeentelijke verdieping toegevoegd. In de onderstaande paragrafen worden de verschillende elementen uit de NORA thema’s die de verbinding tussen klant en overheid ten aanzien van de publieke dienstverlening schetsen beschreven vanuit gemeentelijk perspectief.
Dienstverlening aan burgers
Gemeenten transformeren zich van een overheid die zaken regelt voor burgers en bedrijven tot een overheid die faciliteert. Gemeenten scheppen de randvoorwaarden waardoor burgers en bedrijven zelf in staat zijn om op eigen kracht dingen voor elkaar te krijgen. De klant wordt centraal gesteld binnen dienstverleningsprocessen vanuit het idee van zelfredzaamheid van de klant. De klant krijgt een actieve rol binnen de processen en wordt in staat gesteld om als regisseur van de eigen zaken te acteren.
De klant wil bij het afnemen van diensten van de gemeente geen last hebben van verschillende gemeentelijke afdelingen en daarmee samenhangende verschillende werkprocessen en verantwoordingssystemen. Klanten verwachten van gemeenten dat de gemeente integrale, geïntegreerde en complementaire dienstverlening biedt. Dit houdt in dat gemeenten de dienstverlening over de grenzen van de gemeentelijke organisatie moeten organiseren. De gedachte achter integrale dienstverlening is dat:
- de klant het meest tevreden is omdat hij de dienstverlening gericht op bepaalde problematiek ervaart als één logisch geheel en niet de nadelen ondervindt van een versplinterde uitvoering
- het beste (maatschappelijke) resultaat wordt bereikt doordat de verschillende oorzaken van het probleem zo veel mogelijk integraal worden aangepakt (holistische benadering)
- de uitvoering zo doelmatig mogelijk plaatsvindt, doordat synergievoordelen optreden en onnodige dubbelingen voorkomen worden.
Het gaat bij integrale dienstverlening dus niet om de feitelijke versmelting van organisaties en werkprocessen, maar om klantgerichte, effectieve en efficiënte inrichting van de publieke dienstverlening. Doelstellingen waaraan integrale dienstverlening bijdraagt zijn klantgerichtheid, efficiency en doelmatigheid. Voor het kunnen bieden van integrale dienstverlening is het van belang dat door de gemeente invulling wordt gegeven aan een aantal elementaire zaken:
- Standaardisatie van procesinrichting: Het leveren van geïntegreerde dienstverlening is enkel mogelijk als de verschillende afdelingen of domeinen die betrokken zijn bij het leveren van de dienstverlening dat wat extern zichtbaar is van een proces standaardiseren. Het standaardiseren van de inrichting van processen is dan ook een GEMMA principe. De GEMMA Procesarchitectuur biedt handvatten voor het implementeren van dit principe.
- Inzicht in klantgegevens: Voor het effectief en efficiënt kunnen leveren van dienstverlening aan klanten is het van belang dat medewerkers van de gemeente inzicht hebben in de gegevens van de klant vanuit de verschillende overheidsdomeinen. Voor het gebruik van de gegevens van een klant moet uiteraard vanuit de uitoefening van de taak van de medewerker wel een noodzaak bestaan (doelbinding). Klantgegevens kunnen richting medewerker worden ontsloten via een informatiesysteem wat zelf een integraal klantbeeld kan opbouwen of het kan tot stand worden gebracht door losse inzagefuncties op de verschillende sectorale informatiesystemen.
Het standaardiseren van de gemeentelijke processen en het efficiënt inrichten van de gemeentelijke informatiearchitectuur ten behoeve van het ontsluiten van de gegevens van een klant zijn aspecten waar het katern Verbinden handvatten biedt.
Informatiepositie van burgers
Om de klant in staat te stellen om regie te pakken op de eigen situatie is het van belang dat klanten kunnen beschikken over een correct en actueel overzicht van de gegevens die de gemeente, en andere overheden, over hen hebben vastgelegd. De informatiepositie van klanten moet op een gelijkwaardig niveau ten opzichte van die van de gemeente gebracht worden om de klant in positie te brengen en minder afhankelijk te maken van de overheid; dit wordt ‘de gedeelde informatiepositie’ of ‘democratisering van de dienstverlening’ genoemd.
Het bieden van een gedeelde informatiepositie aan burgers is enkel mogelijk als de gemeente de informatievoorziening en het gegevensmanagement gedegen ingericht heeft. Het tactisch katern gegevensmanagement biedt handvatten ten aanzien van inrichting van de gegevensintake-, gegevensbeheer- en gegevensverstrekkingfuncties van het gemeentelijk gegevensmanagement.
Naast het invulling geven aan de gegevensmanagement rollen en processen is uiteraard ook een effectieve en efficiënte inrichting van de gemeentelijke informatiearchitectuur van belang. Denk hierbij aan het faciliteren van:
- Eenmalige inwinning en meervoudig gebruik;
- Verstrekken van gegevens aan klanten;
- Gegevensbescherming en bescherming van de privacy van de klant;
- Bieden van transparantie over de verwerking van gegevens.
Het katern verbinden beschrijft de gemeentelijke informatiesystemen en GEMMA patronen waarmee invulling kan worden gegeven aan bovenstaande aspecten.
Kanaalstrategie
Vanuit de overheid is Internet het voorkeurskanaal voor het contact met de klant. Burgers krijgen vanaf 2017 het recht op elektronisch zaken doen met de overheid. Naast het digitale kanaal zal door de gemeente voorklanten die niet in staat zijn om Internet als kanaal te gebruiken, minimaal één ander kanaal geboden worden voor het afnemen van diensten. Dergelijke alternatieve kanalen kunnen bijvoorbeeld een balie of callcenter zijn. De noodzaak van meerdere kanalen komt voort uit het feit dat niet iedereen digitaal vaardig is, fysiek in staat om het digitale kanaal te gebruiken, toegang heeft tot het digitale kanaal of het digitaal kanaal wil gebruiken. Het toegepaste kanaal wordt niet alleen bepaald door de voorkeur van de burger of het bedrijf. Het hangt ook af van het type dienst. Eenvoudige diensten kunnen de burger en bedrijven zelf afnemen en dan vaak digitaal. Ingewikkelde diensten vragen om begeleiding die soms digitaal begint maar vaak eindigt in persoonlijk contact tussen burger of bedrijf en dienstverlener.
Dit katern beschrijft de uitdagingen die er liggen op het gebied van kanaalonafhankelijk aanbieden van dienstverlening aan klanten en het verbinden van deze kanalen aan de informatievoorziening van de gemeente.
Binnengemeentelijk verbinden
Een aantal jaar geleden waren gemeenten veelal georganiseerd in domeinen en sectoren die relatief onafhankelijk van elkaar hun werkzaamheden uitvoerden. Onder invloed van een aantal factoren zoals de vraag vanuit klanten naar samenhangende en geïntegreerde dienstverlening, visie van gemeenten op de dienstverlening en efficiëntie en effectiviteitsdoelen is de ontwikkeling ingezet om bedrijfsprocessen en de informatievoorziening vanuit een meer integrale visie vorm te geven. Het werken vanuit een integrale visie in plaats van een visie vanuit domeinen of sectoren stelt eisen nieuwe aan de gemeentelijke informatievoorziening, informatiearchitectuur en wijze waarop diensten aan klanten geleverd worden. Het frontoffice van de gemeente werd traditioneel gezien als de omgeving waar de interactie tussen klanten en de gemeente plaatsvond, en het backoffice was de omgeving waarin de gemeentelijke professional zijn of haar taken uitvoerde. Een van de maatregelen die door veel gemeenten genomen is, en nog genomen wordt, om de doelstellingen ten aanzien van efficiëntie en effectiviteit en levering van integrale doelstellingen te behalen is het samenvoegen van de van activiteiten uit het front- en backoffice. De uitvoering van deze combinatie van activiteiten wordt vervolgens door sommige gemeenten op afstand gezet in een samenwerkingsverband of coöperatie. Deze herschikking van de gemeentelijke activiteiten stelt nieuwe eisen aan zowel kennis en kunde van medewerkers als aan de inrichting van de informatiearchitectuur en informatievoorziening. Het beschikbaar stellen en uitwisselen van gegevens en informatie, het beheren van (de kwaliteit van) gegevens, het beschermen van de privacy van klanten en het verantwoorden van het gebruik van gegevens is van essentieel belang geworden voor de bedrijfsvoering.
Naast de herschikking van de gemeentelijke activiteiten is, mede door technologische ontwikkelingen en de laagdrempelige toegankelijkheid van deze mogelijkheden de uitvoering van de dienstverlening veelal niet langer tijd- en plaatsgebonden. Denk hierbij aan een medewerker van een wijkteam die op huisbezoek gaat bij een burger en via een tablet of laptop en niet alleen inzage heeft in de gegevens en e-dossiers van de burger maar ook faciliteiten heeft om gegevens tijdens een keukentafelgesprek bij te werken en te creëren. De werkplek van de gemeentelijke medewerker is niet meer strikt beperkt tot de gebouwen van de gemeente maar is in de praktijk bij veel gemeenten plaats onafhankelijk geworden. Dit stelt eisen aan de mogelijkheden van informatiesystemen en het leidt tot nieuwe serviceniveaueisen.
Het ondersteunen van bovenstaande ontwikkelingen stelt nieuwe eisen aan de informatie- en technische architectuur van gemeenten. Informatiesystemen moeten getransformeerd worden van min of meer losstaande systemen naar samenwerkende systemen. Op de gebieden van gegevens- en functionaliteitdeling zullen stappen gezet worden. De belangrijkste eisen die aan informatiesystemen gesteld worden zijn:
- het delen van gegevens en functionaliteit;
- de borging van de kwaliteit van gegevens;
- de beveiliging van gegevens en privacy van klanten;
- het afleggen van verantwoording over de verwerking van gegevens.
De eisen die gesteld worden aan gemeentelijke informatiesystemen vertalen zich ook door naar de technische architectuur. Deze technische architectuur is ondersteunend aan de informatiearchitectuur en vervult een belangrijke rol in het borgen van serviceniveaus en beveiliging van de infrastructuur.
Samenwerking tussen overheden
De afgelopen jaren zijn gemeenten steeds intensiever gaan samenwerken. Denk bijvoorbeeld aan samenwerking op het gebied van automatisering, administratie, afval en groenonderhoud. Als gevolg van ontwikkelingen als de decentralisaties in het sociale domein en de omgevingswet zal het aantal samenwerkingsverbanden de komende jaren naar verwachting alleen nog maar toenemen.
De vraagstukken bij intergemeentelijke samenwerkingen liggen op het vlak van alle lagen van de architectuur. Zowel op bedrijfs-, informatie- als technische architectuur zijn keuzes te maken die de mate van succes van een samenwerking in hoge mate beïnvloeden. Denk hierbij bijvoorbeeld aan keuzes ten aanzien van de harmonisatie van bedrijfs- en werkprocessen en de standaardisatie van informatiesystemen van de verschillende deelnemers van het samenwerkingsverband. Naast de functionele keuzes die gemaakt worden bestaan er ook belemmeringen vanuit administratieve en juridische hoek. Mogen bijvoorbeeld werkprocessen vanuit (privacy)wetgeving geharmoniseerd worden en kunnen ondersteunende informatiesystemen op de gewenste manier ingericht worden?
In de praktijk blijkt dat de administratieve, juridische en technische wereld op een aantal thema’s welke voor samenwerkingen relevant zijn met elkaar botsen. De belangrijkste thema’s hierbij zijn:
- (her)gebruik van gegevens;
- (her)gebruik van technische infrastructuur;
- beleggen van taken en verantwoordelijkheden;
- harmonisatie van werkprocessen en applicaties.
Ten aanzien van de organisatorische en juridische aspecten van gemeentelijke samenwerkingen zijn door de Vereniging Nederlandse Gemeenten (VNG) verschillende handreikingen opgesteld. Deze handreikingen geven handvatten voor gemeenten bij de inrichting van samenwerkingsverbanden. Het katern verbinden wordt zo uitgewerkt dat het de verschillende vormen van intergemeentelijke samenwerking ondersteund.
De decentralisatie van taken naar gemeenten leidt tot een verbreding van het gemeentelijk takenpakket. De nieuwe taken waar de gemeente voor verantwoordelijk wordt zijn meestal niet het exclusieve domein van gemeenten, maar worden veelal uitgevoerd in keten- of netwerkverband. Deze ketens en netwerken kunnen bestaan uit een mix van private en publieke organisaties. Bij de uitvoering van de taken heeft de gemeente vaak de taak van regisseur en is de gemeente altijd verantwoordelijk voor de kosten en baten. Soms voeren organisaties binnen de keten hun specifieke onderdeel van een taak uit onder regie van de gemeente en soms is de gemeente een schakel in een keten waar een andere organisatie de regie over voert. Voor het succesvol kunnen samenwerken binnen een keten- of netwerksamenwerking zijn een aantal van belang. Deze aspecten zijn:
- Standaardisatie van semantiek (betekenis) en syntax (structuur) van gegevens;
- Standaardisatie van de uitwisseling van gegevens (berichten);
- Bieden van een ketenbrede technische infrastructuur voor het uitwisselen van berichten.
Het katern biedt de handvatten voor de standaardisatie van de uitwisseling van gegevens en het hergebruiken van technische infrastructuur.
Principes en richtlijnen
Let op: deze pagina is gearchiveerd
Binnen de GEMMA zijn leidende architectuurprincipes beschreven. Deze architectuurprincipes zijn richtinggevende uitspraken die zorgen voor een samenhangende inrichting van de organisatie. Ze helpen gemeenten om bewust keuzes te maken bij het inrichten van de gemeentelijke processen en bijbehorende informatievoorziening. Een aantal van de leidende architectuurprincipes is richtinggevend voor het beschikbaar stellen van gegevens en informatie en het inrichten van de informatievoorziening. Deze architectuurprincipes zijn daarmee ook richtinggevend voor het katern verbinden. In onderstaande paragrafen worden de GEMMA principes beschreven waarbij de verbindingsfunctie een belangrijke rol speelt.
Onze gemeente denkt vanuit de positie van de klant
Dit principe beschrijft de relatie tussen de gemeente en de klant. Het beschrijft een dienstbare overheid waar de dienstverlening complementair aan elkaar is en richting de klant heeft afgestemd op de wensen van die klant. De klant wordt hierdoor in staat gesteld invulling te geven aan de zelfredzaam die de overheid van de burger verwacht.
Het katern verbinden geeft invulling aan dit principe door:
- Generieke interactiepatronen tussen gemeenten en klant te beschrijven. Deze generieke interactiepatronen beschrijven, vanuit de positie van de klant gedacht, de manier waarop de inrichting van de informatiearchitectuur op een zo efficiënte en effectieve manier vorm gegeven kan worden;
- Sociale media en webcare te positioneren als (volwaardige?) informatiebronnen en kanalen. Dit versterkt de verbinding van de gemeenten met burgers, bedrijven en instellingen en geeft de gemeente de handvatten die nodig zijn om signalen vroegtijdig op te pakken en af te handelen;
- Binnengemeentelijke distributie en gebruik van gegevens te vertalen naar inrichting van de informatiearchitectuur. Hierdoor wordt geborgd dat de gemeente altijd en overal met de juiste gegevens werkt waardoor de klant optimaal bediend wordt;
- Vorm te geven aan patronen voor het integreren van gegevens. Door gegevens slim met elkaar te verbinden kan de gemeente trends vroegtijdig signaleren en kan de gemeente de inrichting van de dienstverlening daarop afstemmen. Dit leidt tot een efficiëntere en effectievere dienstverlening.
Onze gemeente gebruikt generieke processen en functies
Gemeenten worden door de overheid geconfronteerd met bezuinigingsmaatregelen en krijgen tevens extra taken. Door te denken in generieke processen en functies kunnen diensten eenvoudiger worden gedeeld met andere gemeenten en worden kosten bespaard. Ook kan eenvoudiger gebruik worden gemaakt van standaard oplossingen die beschikbaar zijn in de markt en wordt maatwerk voorkomen.
Het katern verbinden beschrijft de verbindingsfuncties generiek en gemeentebreed, en biedt generieke inrichtingspatronen (GEMMA patronen) van de onderdelen van de informatiearchitectuur voor generieke problematiek.
Onze gemeente biedt de klant een goede informatiepositie
Een goede informatiepositie is voor klanten cruciaal om snel en gemakkelijk hun weg te vinden binnen de overheid. Het zorgt er ook voor dat zij de verantwoordelijkheid kunnen nemen die in toenemende mate van hen wordt verwacht vanuit een nieuw evenwicht tussen samenleving en overheid. Dat gaat niet alleen over het ontvangen van informatie; het gaat ook over het aan het stuur zetten van de klant over het gebruik van zijn gegevens. Klanten moeten in staat zijn incorrecte registratie van hun gegevens te signaleren, zodat ze voor zichzelf op kunnen komen.
Een goede informatievoorziening voor klanten stelt ten forse eisen aan de wijze waarop de informatiearchitectuur en gemeentelijke informatievoorziening georganiseerd zijn. De in het katern beschreven GEMMA patronen maken een efficiënte en effectieve inrichting van de gemeentelijke informatievoorziening mogelijk waardoor beschikbaarheid, betrouwbaarheid en beveiliging van gegevens en transparantie over de verwerking van gegevens geborgd zijn waardoor invulling gegeven kan worden aan de informatiepositie van de klant.
Onze gemeente stelt openbare gegevens als open data beschikbaar
De overheid stelt hoge eisen aan de transparantie van overheidsorganisaties. Toegang tot informatie uit overheidsorganisaties is een kernwaarde in de democratie en is wettelijk vastgelegd. Overheidsinformatie is in beginsel vrij beschikbaar, tenzij de WOB, WBP of andere wetgeving bepaalt dat de gevraagde informatie niet geschikt is om openbaar te maken. Het openbaar, vindbaar en herbruikbaar aanbieden van open data heeft positieve maatschappelijke en economische effecten: het voorziet in een behoefte, heeft economische waarde en leidt tot meer transparantie en participatie. Zo kunnen anderen nieuwe toepassingen ontwikkelen en/of deze gegevens via (mobiele) applicaties laagdrempelig ontsluiten richting klanten.
In het katern worden de GEMMA patronen beschreven voor het aanbieden van open data en wordt de verbinding van de gemeente met klanten.
Onze gemeente hergebruikt gegevens
Binnen de Nederlandse overheid is afgesproken dat burgers niet wordt gevraagd om gegevens waar de overheid zelf al over beschikt. Door duidelijke afspraken te maken over waar gegevens worden beheerd en waarvandaan ze worden verstrekt wordt het delen ervan veel eenvoudiger en worden mogelijke inconsistenties voorkomen. Op landelijk niveau zijn er hiertoe basisregistraties gedefinieerd die door alle overheidsorganisaties moeten worden gebruikt. Binnen de gemeente is ook hergebruik van andere breed gebruikte gegevens relevant. Hierbij kan gedacht worden aan een registratie van medewerkers, olietanks of cultuurhistorisch erfgoed. Dergelijke registraties die binnengemeentelijk breed worden gebruikt noemen we kernregistraties. Voor kernregistraties gelden dezelfde principes als bij de basisregistraties, maar dan op gemeentelijk niveau. Dit houdt onder meer in dat op de inhoud van de registratie teruggemeld kan worden bij twijfel aan de juistheid van gegevens. Niet de wet maar een collegebesluit bepaalt het verplicht gebruik. De gegevens van de kernregistraties voorzien in de eerste plaats in een lokale, gemeentelijke informatiebehoefte.
In dit katern worden de verschillende gegevensregistraties gepositioneerd en wordt via een aantal GEMMA patronen beschreven waarmee inwinning, beheer, distributie en het gebruik van basis- en kerngegevens ondersteund wordt.
Onze gemeente gaat op een vertrouwelijke manier met gegevens om
Klanten verwachten dat de gemeente op een zorgvuldige manier met hun gegevens om gaat en dat deze niet in handen komen van onbevoegden. Functies uit de GEMMA gedeelde generieke functionaliteit ondersteunen de borging dat enkel gegevens verwerkt worden die conform doelbinding en de principes van subsidiariteit (ander middel dat minder inbreuk op privacy maakt om het gestelde doel te realiseren, heeft de voorkeur) en proportionaliteit (niet meer privacy inbreuk dan nodig) verwerkt mogen worden. De geboden functionaliteit bestaat uit een combinatie van logging-functies van de referentiecomponenten en autorisatie- en authenticatiefuncties. Via de autorisatie- en authenticatiefuncties kunnen identiteit en autorisaties van een gebruiker vastgesteld worden en kan de toegang tot autorisatie-objecten beperkt worden. Via de logging-functies van de verschillende referentiecomponenten is vast te stellen wie om welke reden gegevens verwerkt heeft.
In het katern worden de verschillende principes en richtlijnen vertaald naar concrete inrichtingen van de gemeentelijke informatiearchitectuur. De principes en richtlijnen gelden daarbij in de uitwerking als het te hanteren kader.
Ontsluiting en actualiteit van gegevens
Let op: deze pagina is gearchiveerd
Gemeenten hebben de beschikking over een grote hoeveelheid gegevens, zowel gestructureerd als ongestructureerd welke gebruikt wordt bij de uitvoering van bedrijfsprocessen, dienstverlening naar de burger, analyses, en rapportages. De processen waarvoor de gegevens worden gebruikt zijn grofweg op te delen in processen waarbij de actualiteit van de gegevens van groot belang en processen waarbij deze actualiteit minder van belang is. Denk bij processen waarbij de actualiteit van gegevens cruciaal bijvoorbeeld aan de behandeling van een omgevingsvergunningaanvraag. Processen waarbij de actualiteit van de gegevens minder van belang is zijn veelal statistische analyse processen of rapportages die op basis van een peildatum werken.
Hier worden de GEMMA-architectuur geadviseerde patronen beschreven ten aanzien van het beschikbaar stellen van de verschillende soorten gegevens.
Informatievoorziening voor dienstverleningsprocessen
Voor veel processen is actualiteit en beschikbaarheid van gegevens van cruciaal belang. Ten aanzien van de actualiteit van gegevens lijkt het voor de hand te liggen om de gegevens bij de bronregistratie op te vragen. Deze bron bevat de meest actuele gegevens en bevraging van de bron lijkt dan ook de meest logische optie qua bevraging. Het is echter zo dat bronsystemen hun oorsprong kunnen hebben buiten de gemeente en qua beschikbaarheid en overige serviceniveaus niet aansluiten bij de eisen vanuit de afnemende processen. Dit kan overigens ook het geval zijn bij binnengemeentelijke bronsystemen. Denk bijvoorbeeld aan een GBA-systeem dat in verband met ingeplande backup-taken een gedeelte van de nacht niet beschikbaar is. Op dat moment kunnen dienstverleningsprocessen die afhankelijk zijn van het GBA-systeem niet uitgevoerd worden. In dit concrete voorbeeld zou de digitale dienstverlening van de gemeenten daarmee stilliggen. Dit kan strijdig zijn met de ambitie van de gemeenten ten aanzien van bijvoorbeeld een 24x7 beschikbaarheid van de digitale dienstverlening. Indien de serviceniveaus van bronsystemen niet overeenkomen met de vanuit de afnemende processen gewenste serviceniveaus dan moeten maatregelen genomen worden. Een maatregel die genomen kan worden is het implementeren van een gegevensmagazijncomponent waarin de gegevens die door de dienstverleningsprocessen gebruikt worden redundant worden opgeslagen. Processen kunnen vervolgens hun gegevens uit het gegevensmagazijncomponent betrekken in plaats van uit de (authentieke) bronsystemen. Het voordeel van deze werkwijze is dat de gemeentelijke dienstverlening niet afhankelijk is van de beschikbaarheid van de (authentieke) bronnen. De gemeente is in control over de beschikbaarheid van de gegevensmagazijncomponent, en kan daardoor de beschikbaarheid en kwaliteit van de dienstverlening aan burgers en bedrijven garanderen. De gegevensmagazijncomponent dient hiermee als buffer tussen de gemeentelijke processen en bronsystemen.
Een voorbeeld van waarbij gegevens betrokken kunnen worden uit de gegevensmagazijn-component in plaats van de authentieke bron is een e-formulier wat voor het voorinvullen van het e-formulier met persoonsgegevens deze gegevens leest uit de gegevensmagazijncomponent in plaats van uit de GBA administratie.
Het gebruiken van gegevens uit een gegevensmagazijncomponent kent een aantal aandachtspunten:
- Actualiteit van de gegevens: De gegevensmagazijncomponent bevat kopieën van gegevens uit bronregistraties. De frequentie van aanlevering van gegevens aan het gegevensmagazijn bepaald de actualiteit van de gegevens in het magazijn. De wijze waarop het gegevensmagazijn voorzien wordt van gegevens door bronregistraties kan per bronregistratie verschillen. Sommige bronregistraties zullen het aanleveren van gegevens via mutatieberichten ondersteunen ne anderen zullen gegevens aanleveren in bijvoorbeeld een bestand of bulkbericht. In verband met de actualiteit van gegevens in het gegevensmagazijn heeft het de uitdrukkelijke voorkeur om de gegevensmagazijncomponent te voeden met kennisgevingen vanuit bronsystemen die direct na mutatie in de bronregistratie verzonden worden;
- Juistheid, betrouwbaarheid en kwaliteit van gegevens: Gegevens kunnen in een bronsysteem zijn vastgelegd met een kwaliteit die voor het oorspronkelijke gebruik voldoende is, maar voor niet voor het beoogde hergebruik. Idealiter is de kwaliteit van een gegeven bij het gegevens vastgelegd;
- Gegevensautorisatie en doelbinding: De gegevens die in de gegevensmagazijncomponent zijn opgeslagen vallen, daar waar ze tot personen herleidbaar zijn, onder wetgeving die de privacy beschermd. Deze wetgeving omvat de nieuwe Europese privacyverordening (Algemene Verordening Gegevensbescherming) welke geldt vanaf 25 mei 2016. Alle organisaties in de publieke en private sector worden geacht om vanaf die datum hun bedrijfsvoering met de AVG in overeenstemming te brengen en krijgen daarvoor tot 25 mei 2018 de tijd. Voor die tijd geldt hetzij de Wet bescherming persoonsgegevens (Wbp) hetzij de Wet BRP. Deze wetten en verordeningen vereisen dat een eindgebruiker doelbinding heeft om gegevens te mogen verwerken. De gegevens uit een gegevensmagazijncomponent mogen dus slechts verstrekt worden aan een eindgebruiker indien deze voor de gegevens geautoriseerd is vanuit de doelbinding van het proces waarvoor werkzaamheden worden uitgevoerd;
- Logging en verantwoording van de verwerking van gegevens: Vanuit de verplichtingen die voortvloeien uit de vigerende wetgeving heeft een gegevensmagazijncomponent de taak om de verwerking van gegevens, waaronder dus ook de verstrekkingen, te loggen. De logbestanden zijn belangrijke bronnen die gebruikt worden bij het verantwoording afleggen aan burger en bestuur over de verwerking van gegevens. Mede via deze logbestanden kan bepaald worden of een verwerking noodzakelijk, proportioneel en subsidiair is geweest.
Het heeft de uitdrukkelijke voorkeur om vanuit gemeentelijke processen de benodigde gegevens direct van de bron te betrekken. Dit borgt het gebruik van de meest actuele gegevens, doet recht aan de autorisatie vereisten van de bron en geeft de beste mogelijkheden ten aanzien van het loggen van het gebruik van de gegevens. Het redundant opslaan van gegevens in een gegevensmagazijncomponent moet gezien worden als een tijdelijke oplossing. Op het moment dat de serviceniveaus van bronsystemen aansluiten bij de eisen vanuit de gemeentelijke dienstverlening is het de aanbeveling om de gegevens te betrekken uit het bronsysteem in plaats van de gegevensmagazijncomponent. Hierbij moet wel aangetekend worden dat er ook andere redenen kunnen zijn om gegevens niet direct uit de bron te betrekken. Denk hierbij bijvoorbeeld aan beschikbaarheid van het bronsysteem voor de gebruikers (als een bronsysteem zwaar bevraagd wordt door een ander systeem dan kan dat de gebruikers van dat bronsysteem hinderen doordat de performance verslechterd). Een gegevensmagazijn kan in dat geval toegevoegde waarde bieden ten opzichte van een bronsysteem.
GEMMA Patronen beschrijft de best-practices die in de informatiearchitectuur gehanteerd worden bij de implementatie van de bovenstaande patronen.
Informatievoorziening voor analytische en statistische processen
Processen die zich richten op analyse, statistiek en rapportages hebben meestal de behoefte aan grote verzamelingen gegevens. De gegevens die gebruikt worden zijn daarbij afkomstig uit meerdere verschillende informatiesystemen uit de gemeente. De processen maken over het algemeen gebruik van een peildatum of een tijdsperiode en hebben daardoor niet de behoefte aan de meest recente gegevens. Voor het ondersteunen van de analytische en statistische processen wordt binnengemeentelijk gebruik gemaakt van een data-warehousecomponent. Een data-warehousecomponent bevat basisgegevens, kerngegevens en overige domeinspecifieke gegevens en is geoptimaliseerd voor het uitvoeren van complexe selecties, analyses en statistiek.
Gegevens worden aan de data-warehousecomponent aangeleverd door basisregistraties, kernregistraties en taakspecifieke informatiesystemen via ETL-processen die periodiek worden uitgevoerd. In tegenstelling tot de gegevensmagazijncomponent bevat het data-warehousecomponent daardoor geen near real-time gegevens. Voor basisgegevens is het binnengemeentelijk mogelijk om de gegevensmagazijncomponent als bron voor de vulling van de data-warehousecomponent te gebruiken. Aangeleverde gegevens worden door het data-warehousecomponent ingelezen, getransformeerd en opgeslagen in het de eigen gegevensopslag. Een data-warehousecomponent is zelf nooit bronsysteem van gegevens.
Gegevens uit een data-warehousecomponent worden beschikbaar gesteld via zogenaamde ‘datamarts’. Een datamart geeft afnemende systemen toegang tot een deelverzameling van de gegevens binnen de data-warehousecomponenten is meestal specifiek voor een bepaald domein of thema.
GEMMA Patronen beschrijft de best-practices die in de informatiearchitectuur gehanteerd worden bij de implementatie van de bovenstaand patroon.
Voetnoten
Verbinden met klanten
Let op: deze pagina is gearchiveerd
Het verbinden van de gemeentelijke informatiearchitectuur met klanten gaat over zowel het ontvangen van gegevens van klanten (bijvoorbeeld meldingen en aanvragen) als het ter beschikking stellen van gegevens en informatie aan klanten. In de GEMMA architectuur zijn verschillende functies opgenomen die deze interactie met klanten faciliteren. Onderstaande figuur geeft weer welke eindgebruikersfuncties dit betreft.
Ten aanzien van gegevens die ter beschikking worden gesteld aan klanten wordt een onderscheid gemaakt in publiek toegankelijke gegevens (open data) en informatie en gegevens die specifiek voor één klant zijn (closed data).
De wet openbaarheid van bestuur biedt het kader om te beoordelen of overheidsinformatie openbaar kan worden gemaakt. Uitgangspunt is dat informatie openbaar kan worden gemaakt, tenzij er een weigeringsgrond is in de Wet openbaarheid van bestuur (Wob) of in wet of regelgeving voor instellingen die niet onder de reikwijdte van de Wob vallen. Gegevens die aan deze eisen voldoen worden, ‘open data’ genoemd. Dergelijke gegevens zijn per definitie gegevens die niet privacygevoelig zijn en worden door de gemeente gepubliceerd via bijvoorbeeld de gemeentelijke website en sociale media.
Publieke gegevens (open data)
Er bestaan verschillende soorten van publieke gegevens; gestructureerde en ongestructureerde. Ongestructureerde gegevens zijn bijvoorbeeld de openingstijden van de gemeente, nieuws- en persberichten en bekendmakingen van vergunningsaanvragen. Gestructureerde publieke gegevens zijn de oplaadpunten elektrisch vervoer, de tariefgebieden parkeren, attracties, winkels et cetera. De GEMMA biedt voor de ontsluiting van publieke gestructureerde gegevens naar afnemers functionaliteit via de gedeelde generieke functionaliteit via de functie ‘Inwinnen en ontsluiten open data’.
De ontsluiting van ongestructureerde publieke gegevens wordt gerealiseerd direct vanuit gemeentelijke referentiecomponenten zoals een raadsinformatiecomponent en producten- en dienstencatalogus. Deze referentiecomponenten bieden een publicatiemechanisme waarmee de ongestructureerde publieke gegevens rechtstreeks naar de gemeentelijke website worden gepubliceerd. Publicatie naar andere kanalen zoals sociale media wordt veelal handmatig uitgevoerd. De gemeente heeft voor publicatie op sociale media één of meerdere medewerkers geautoriseerd die conform vastgestelde beleidsregels en handelingsinstructies berichten op de verschillende sociale media plaatsen.
Privacygevoelige gegevens (closed data)
Privacygevoelige gegevens worden naar klanten ontsloten via een afgeschermd deel van een gemeentelijke website (een zogenaamd mijngemeentecomponent). De klant dient zich bij dit loket aan te melden, bijvoorbeeld gebruik makend van DigiD of eHerkenning, alvorens zijn/haar gegevens in te kunnen zien. Gegevens die via een digitaal loket ontsloten worden zijn bijvoorbeeld de gegevens uit de Basisregistratie Personen (BRP), een overzicht van lopende zaken en gegevens ten aanzien van de WOZ en aanverwante aanslagen. Bij de verstrekking van dergelijke privacygevoelige gegevens is actualiteit van de gegevens van groot belang. Aanbeveling aan gemeenten is om gegevens om actualiteitsredenen op het moment van opvragen van de gegevens door de klant te betrekken uit de bronadministratie waarin de gegevens geadministreerd zijn.
Ontsluiting gegevens naar klanten
Onderstaande figuur illustreert de ontsluiting van gegevens naar klanten via de verschillende kanalen die de gemeente tot haar beschikking heeft (website, persoonlijke internet pagina, sociale media, telefoon, balie, et cetera). Gegevens die privacy gevoelig zijn, en dus een gesloten karakter hebben, worden door de gemeente veelal aangeboden via een digitaal loket van de gemeentelijke website waarop een klant moet inloggen met zijn of haar persoonlijke aanmeldgegevens. Voorbeelden van dergelijke authenticatiemechanismen zijn DigiD en eHerkenning.
GEMMA Patronen beschrijft de best-practices die in de informatiearchitectuur gehanteerd worden bij de ontsluiting van privacygevoelige en publieke gegevens naar klanten.
Verbinden in ketens en netwerken
Let op: deze pagina is gearchiveerd
Gemeenten werken in toenemende mate, en op verschillende manieren samen met partijen uit de ketens en netwerken waarmee zaken worden gedaan. Uitwisseling vindt plaats via geautomatiseerde berichtuitwisseling waarbij geen directe menselijke tussenkomst nodig is en gegevens worden uitgewisseld via portaalomgevingen die door gemeenten aan ketenparters ter beschikking worden gesteld. Onderstaande figuur geeft de functies uit de GEMMA informatiearchitectuur weer die invulling geven aan deze beide manieren van uitwisseling.
Uitwisseling van gegevens tussen gemeenten en ketenpartijen
De wijze waar uitwisseling van gegevens tussen gemeenten en ketenpartijen tot stand komt is afhankelijk van ketenafspraken en onderlinge afspraken partijen. Partijen hebben vanuit de informatiearchitectuur grofweg twee manieren waarop gegevens uitgewisseld kunnen worden; via webservices en via portaalomgevingen. In het geval van het gebruik van webservices zal de gemeente aan ketenpartijen één of meer webservices ter beschikking stellen die door de ketenpartijen gebruikt kunnen worden voor het aanleveren van gegevens. Indien gekozen wordt voor aanlevering van gegevens via een portaalomgeving zal de gemeente aan ketenpartijen een portaalomgeving ter beschikking stellen. Via dit portaal kunnen ketenpartijen bestanden up- en downloaden en vaak ook via e-formulierachtige oplossingen gegevens aanleveren. Zowel bij webservices als bij portalen is er uiteraard sprake van beveiligde verbindingen die alleen door geautoriseerde gebruikers kunnen worden gebruikt. Vanuit de GEMMA informatiearchitectuur wordt voor uitwisseling via webservices de servicebuscomponent gepositioneerd. Voor uitwisseling via portaaldiensten is de beveiligd ketenparterportaalcomponent beschikbaar.
Standaardisatie van gegevens en informatieuitwisseling
Om de uitwisseling van gegevens tussen gemeenten en ketenpartijen efficiënt te laten verlopen is, ongeacht de manier waarop de uitwisseling technische plaat vindt, het nodig om afspraken te maken tussen partijen over gegevensuitwisseling, gegevensbetekenis en overkoepelende werkprocessen. Deze afspraken zijn randvoorwaardelijk voor het tot stand brengen van een goede interoperabiliteit. De afspraken zijn de kaders (architectuur, standaarden, e.d.) waarbinnen nadere, specifieke afspraken (koppelvlakstandaarden) gemaakt worden. Deze afspraken kunnen gelden tussen gemeenten en keten- of netwerkpartners maar kunnen ook worden toegepast bij integratie van binnengemeentelijke processen en systemen.
Door VNG Realisatie wordt in koppelvlakstandaardbeschrijvingen invulling gegeven aan de beschreven aanpak en niveaus van afspraken. De verschillende niveaus van afspraken die in een koppelvlakstandaardbeschrijving opgenomen worden hieronder beschreven.
Procesketens
Onderstaande figuur geeft de samenwerking tussen drie organisaties via een tweetal koppelvlakstandaarden weer. Het samenwerkende totaal aan koppelvlakstandaarden en bedrijfsprocessen in een bepaalde context noemen we een procesketen.
Een procesketen is een geordende reeks bedrijfsprocessen die door verschillende organisaties wordt uitgevoerd met als doel om via meerdere organisatie een (combinatie van) dienst(en) te leveren aan een burger of een bedrijf. In de beschrijving van het procesketen wordt op hoog niveau beschreven welke business actoren een rol spelen binnen het proces, wat hun rol is binnen de keten en wat de interacties zijn die tussen de actoren spelen. Een procesketen is te beschouwen als de context waarbinnen processen in een netwerk van organisaties plaatsvinden. Voorbeeld van een procesketen is het afhandelen van een Wmo-voorziening aanvraag. Ontvangst van de aanvraag, beoordeling van de aanvraag en besluitvorming is de verantwoording van de gemeente. Het leveren van de voorziening is de verantwoordelijkheid zijn van een zorgaanbieder.
Binnen een procesketen spelen koppelvlakstandaarden een belangrijke rol in de uitwisseling van gegevens tussen partijen. Een koppelvlakstandaard bestaat uit een set van procesmatige, semantische, syntactische en technische afspraken die nodig zijn om de communicatie tussen de partijen mogelijk te maken, en goed te laten verlopen. Een koppelvlakstandaard wordt beschreven in een koppelvlakbeschrijving. Koppelvlakstandaardbeschrijvingen beschrijven de afspraken tussen partijen over de bedrijfsprocessen en interactiepatronen, definities van gegevens en berichten en wijze van technische uitwisseling. Een koppelvlakstandaardbeschrijving bevat dus zowel proces-, inhoud- als techniekaspecten.
Onderstaande figuur geeft de verschillende niveaus weer waarop in een koppelvlakstandaardbeschrijving afspraken gemaakt dienen te worden om de interoperabiliteit te borgen.
Hieronder wordt beschreven welke elementen per niveau in een koppelvlakstandaardbeschrijving opgenomen worden.
Bedrijfsprocesniveau
Binnen een koppelvlakstandaardbeschrijving worden op hoog niveau de bedrijfsprocessen van de verschillende actoren beschreven. Alleen de bedrijfsprocessen die relevant zijn voor het koppelvlak worden beschreven. Van bedrijfsprocessen wordt de inrichting op hoofdlijnen beschreven en wordt de samenhang van de bedrijfsprocessen met de interactieprocessen beschreven. Deze beschrijving is van belang voor de verschillende partijen om toepassing van de koppelvlakstandaard te kunnen duiden. Bedrijfsprocessen worden gemodelleerd via BPMN diagrammen.
Interactieprocesniveau
Het interactieproces beschrijft de verschillende gegevensuitwisselingsactiviteiten die de ketenpartners in het kader van hun ketentaak uitvoeren. Het opstellen van een interactieproces helpt om alle uitgewisselde gegevens boven water te krijgen zodat deze vervolgens gestandaardiseerd en beschreven kunnen worden. Het uiteindelijke doel van het beschrijven van het interactieproces is de automatisering van dit interactieproces zodat de gegevens automatisch tussen de bedrijfssystemen van de partijen binnen die participeren in de procesketen uitgewisseld kunnen worden. Het beschreven interactieproces vormt de basis voor deze automatisering. Het beschrijven en modelleren van een interactieproces is optioneel voor koppelvlakstandaarden die binnengemeentelijke koppelvlakken beschrijven. Interactieprocessen worden gemodelleerd via UML collaboration diagrammen.
Inhoudsniveau
Op het niveau van de inhoud wordt onderscheid gemaakt in de gegevens en de applicaties die een rol spelen.
Gegevens
Belangrijk onderdeel van een koppelvlakstandaardbeschrijving is het betekenis geven aan de binnen de interactieprocessen uitgewisselde gegevens en informatie. Het gaat hierbij om het gestructureerd beschrijven van de semantiek, syntax en samenhang van deze gegevens en informatie. Modellering van deze elementen vindt plaats via UML klassen- en objectendiagrammen en XSD’s.
Applicaties
Onderdeel van een koppelvlakbeschrijving kan een beschrijving zijn van de wijze waarop de uit te wisselen gegevens en informatie via (referentie)componenten verzameld en verstuurd, of ontvangen en afgehandeld worden. In deze beschrijving worden de rollen van de verschillende (referentie)systemen geduid en worden verantwoordelijkheden van deze systemen beschreven. Applicatiesamenwerkingen worden beschreven via ArchiMate diagrammen.
Techniekniveau
De techniek beschrijft de wijze waarop gegevens technisch uitgewisseld worden. Onderdeel van de beschrijving zijn berichtuitwisseling scenario’s, de beveiliging van gegevens- en informatie-uitwisseling en gebruikte communicatievoorziening. Modellering van de techniekelementen van een koppelvlakbeschrijving vindt onder andere plaats via UML sequence diagrammen.
Kennismodel
De verschillende architectuurelementen die in een koppelvlakstandaard van belang zijn, en hun onderlinge samenhang worden in onderstaand ArchiMate diagram weergegeven.
Referentiecomponenten voor integratie
Let op: deze pagina is gearchiveerd
Bij het uitvoeren van processen worden services en gebruikersfuncties (diensten) gebruikt die door informatiesystemen worden geboden. Bij de uitvoering van de diensten zijn over het algemeen meerdere informatiesystemen betrokken. Denk hierbij aan een informatiesysteem dat als dienst een gebruikersscherm aanbiedt om personen mee te zoeken op basis van een BSN. Het systeem dat de dienst aanbiedt toont de gebruikersinterface. Voor de uitvoering van de zoekopdracht is waarschijnlijk een aantal componenten verantwoordelijk. Te denken valt aan de servicebuscomponent, de gegevensmagazijncomponent, de landelijke GBA-V en wellicht ook sectorale informatiesystemen. Bij de uitvoering van de dienst is dus een aantal verschillende informatiesystemen betrokken. Het laten samenwerken van verschillende informatiesystemen wordt ook wel het ‘integreren’ van informatiesystemen genoemd.
Bij Integratiestijlen en functies zijn de verschillende uit de literatuur beschreven standaard integratiestijlen en integratiefuncties beschreven. Hier zijn de verschillende referentiecomponenten die in de verbindingsfunctie binnengemeentelijk, met klanten en met ketens een belangrijke rol spelen beschreven. Onderstaande figuur toont deze verschillende referentiecomponenten.
De referentiecomponenten die een rol spelen in de verbindingsfunctie geven allen invulling aan een aantal integratiefuncties [1]. Onderstaande tabel toont dit overzicht.
Orkestreren | Routeren | Transformeren | Abonneren | Monitoren | Loggen | Beveiligen | |
---|---|---|---|---|---|---|---|
Servicebuscomponent | X | X | X | X | X | X | |
Gegevensdistributiecomponent | X | X | X | X | X | ||
Notificatierouteringcomponent | X | X | X | X | X | ||
Gegevensmagazijncomponent | X | X | |||||
Data-warehousecomponent | X | X | X | ||||
Zaakregistratiecomponent | X | X | |||||
Verwerkingenloggingcomponent | X | X | |||||
Open-data-portaalcomponent | X | X | |||||
Ketenpartner-portaalcomponent | X | X | |||||
Mijngemeentecomponent | X | X |
Hieronder worden de bovenstaande referentiecomponenten nader beschreven. Gezien de centrale rol die deze componenten in de informatievoorziening spelen wordt aanbevolen er naar te streven om van deze componenten slechts één voorkomen in de gemeentelijke informatiearchitectuur op te nemen. Meervoudig laten voorkomen van deze componenten leidt tot hogere complexiteit en daarmee hogere (beheer)kosten.
Generieke (integratie)functies voor referentiecomponenten
Zoals in de bovenstaande tabel is te zien zijn de integratiefuncties 'Loggen' en 'Beveiligen' functies waaraan door alle referentiecomponenten die bij verbinden worden gebruikt invulling wordt gegeven. Deze functies zijn niet allen voor de in de tabel genoemde, maar voor alle referentiecomponenten die 'closed data' verwerken van belang. Alle deze componenten dienen immers opslag, toegang en gebruik van de gegevens te beveiligen en zullenin het kader van de transparantie en verantwoording de verwerking hiervan loggen. Deze functies zijn dus niet puur integratiefuncties, maar generieke functies die door alle referentiecomponenten die closed data verwerken verplicht ingevuld moeten worden.
Servicebuscomponent
De gemeentelijke servicebus speelt een actieve rol binnen het merendeel van de integratiestijlen. Deze component routeert berichten, orkestreert afhandeling van berichten, transformeert desgewenst berichten en biedt daarnaast monitoring- en beveiligingsfuncties.
De gemeentelijke servicebus is in de basis een Enterprise Service Bus (ESB) waarmee gemeente specifieke koppelingen worden gerealiseerd. Belangrijkste taak van de servicebus is het bieden van functionaliteit voor het versturen en beheren van elektronische berichten. De servicebuscomponent biedt voor het verbinden aan landelijke voorzieningen en basisregistraties ondersteuning voor de door deze voorzieningen gehanteerde communicatiestandaarden. Een voorbeeld van een dergelijke standaard die door de servicebus wordt ondersteund is de Digikoppeling standaard. De servicebus is de component waarmee koppelingen tussen informatiesystemen gelegd worden, zowel tussen informatiesystemen binnengemeentelijk als buitengemeentelijk. Deze koppeling wordt in de meeste gevallen tot stand gebracht via de externe functionaliteit aanroep integratiestijl[2].
Gegevensdistributiecomponent
De gegevensdistributiecomponent is binnen de gemeentelijke informatiearchitectuur verantwoordelijk voor de distributie van mutaties van basisgegevens naar geabonneerde afnemers. De gegevens die door de gegevensdistributiecomponent gedistribueerd worden zijn de gegevens die via de StUF-BG standaard, gebaseerd op het RSGB, uitgewisseld kunnen worden. Deze gegevens omvatten de gegevens uit basisregistraties aangevuld met een aantal extra gegevens. De gegevensdistributiecomponent kan daarnaast optioneel ook andere gegevens distribueren. Implementatie hiervan is leverancier afhankelijk. De gegevensdistributiecomponent wordt ten aanzien van RSGB-gegevens door bronsystemen gevoed via StUF kennisgevingen. De gegevensdistributiecomponent biedt functionaliteit waarmee afnemers abonnementen kunnen afsluiten op mutaties van deze gegevens. Afnemers kunnen via distributieregels per soort gegeven instellen van welke wijzigingen ze op de hoogte worden gesteld door de gegevensdistributiecomponent.
De gegevensdistributiecomponent wordt gebruikt om de berichtuitwisseling integratiestijl[3] op basis van kennisgevingen mee te implementeren. Dit houdt in dat mutaties (context en inhoudelijke gegevens) van bronsystemen worden gedistribueerd naar geabonneerde afnemers.
Functies van de gegevensdistributiebuscomponent
Gegevensdistributiecomponent versus de servicebuscomponent
De functionaliteit van de gegevensdistributiecomponent wordt vaak verward met de functionaliteit van de servicebuscomponent. De servicebuscomponent is een component die berichten ontvangt, desgewenst transformeert en daarna routeert naar de bestemming. Deze component heeft geen weet van de functionele betekenis van berichten. De gegevensdistributiecomponent echter handelt berichten af op basis van de functionele betekenis en inhoud van berichten. De gegevensdistributiecomponent ontvangt mutaties van bronsystemen (de actuele bronwaarden), slaat deze bronwaarden intern op en distribueert de gegevens naar binnengemeentelijke afnemers op basis van afnemerindicaties en distributieregels. Het opslaan van de actuele bron- en afnemerwaarden binnen de distributiecomponent wordt gedaan voor synchronisatiedoeleinden van de gegevensdistributiecomponent met afnemers en bronhouders. Door de gegevensdistributiecomponent wordt onder andere de timestamp van de laatste mutatie in de bron bijgehouden. Door deze timestamp te vergelijken met de laatste timestamp in de bron is eenvoudig te bepalen of de bron en de door de gegevensdistributiecomponent geregistreerde actuele bronwaarden nog synchroon zijn. Voor het routeren van mutaties vanuit de gegevensdistributiecomponent naar de afnemers kan de gegevensdistributiecomponent gebruik maken van de routeringsfunctie van de servicebuscomponent.
Een leverancier mag in een servicebussysteem zowel een servicebuscomponent als gegevensdistributiecomponent implementeren. Op te merken valt dat vanuit het oogpunt van gegevensbeveiliging het combineren van beide componenten in één systeem is af te raden. Een eventuele kwetsbaarheid in de servicebus zou dan immers potentieel de gegevens die voor de distributiefunctie kunnen lekken aan partijen die aangesloten zijn op de servicebus. Potentieel gaat het dan om alle basisgegevens van de burgers waarmee de gemeente een relatie mee heeft (alle inwoners en ook een aantal buitengemeentelijke personen).
Gegevensdistributiecomponent versus de gegevensmagazijncomponent
De gegevensdistributiecomponent moet niet verward worden met de functionaliteit van een gegevensmagazijncomponent, ofschoon er veel overeenkomsten zijn. Belangrijke verschillen hierbij zijn de wijze van autorisatie van afnemers van de gegevens en koppelvlakken naar afnemers. De gegevensmagazijncomponent autoriseert de toegang tot gegevens op het niveau van eindgebruikers terwijl de gegevensdistributiecomponent deze toegang autoriseert op het niveau van de afnemer. In het geval van een gegevensdistributiecomponent wordt de autorisatie dus op het niveau van informatiesysteem geregeld in plaats van op individu. Ook de ontsluiting van de gegevens naar afnemers is verschillend. Daar waar de gegevensmagazijncomponent gegevens ontsluit volgens de verschillende StUF-bevragingskoppelvlakken wordt de gegevensdistributiecomponent ontsloten via synchronisatie en kennisgevingskoppelvlakken.
Mening van VNG Realisatie over nut en noodzaak van een gegevensdistributiecomponent
Over nut en noodzaak van gegevensdistributiecomponenten is veel discussie bij gemeenten en leveranciers. Leveranciers die geen gegevensdistributiecomponent leveren zijn vaak van mening dat de functionaliteit van een gegevensdistributiecomponent vanuit de implementatie van een servicebuscomponent geleverd kan worden. Leveranciers die wel een gegevensdistributiecomponent in hun softwareportfolio aanbieden hebben delen dat beeld niet. Het standpunt van VNG Realisatie is dat een gegevensdistributiecomponent binnen de gemeentelijke informatiearchitectuur vereist is zolang niet nog niet alle basisregistraties:
- Notificaties van mutaties inclusief de gebeurtenis die geleid heeft tot de mutatie leveren;
- Ad-hoc bevraagbaar zijn;
- Voldoen aan de door gemeenten gestelde serviceniveaus.
Op het moment dat de basisregistraties voldoen aan de bovenstaande eisen is het mogelijk om de gegevensdistributiecomponent uit te faseren. Afnemers kunnen dan op basis van de context van notificaties die door de bronsystemen verstuurd bepalen of de betreffende mutatie van belang is. Indien dat zo is kunnen de afnemers real-time de gegevens bij de bronregistratie ophalen. Zolang dit nog niet kan zullen gemeenten basisgegevens ‘rond moeten pompen’ binnen de gemeentelijke informatiearchitectuur. Het kunnen synchroniseren van gegevens tussen bronnen en afnemers is daarbij van essentieel belang.
Notificatierouteringcomponent
Systemen en processen hebben de mogelijkheid om op het moment dat een bepaalde gebeurtenis plaatsvindt hiervan melding 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. Dergelijke signalen worden binnen de GEMMA ‘notificaties’ genoemd. De notificatierouteringcomponent is de component binnen de gemeentelijke informatiearchitectuur die wordt gebruikt om de berichtuitwisseling integratiestijl op basis van notificaties (ook genoemd: signalen) mee te implementeren. De notificatierouteringcomponent ontvangt notificaties van bronsystemen en routeert deze notificaties naar geabonneerde afnemers.
Functies van de notificatierouteringcomponent
Via notificaties worden de context van een gebeurtenis en relevante sleutelgegevens uitgewisseld. De context geeft aan wat de inhoudelijke duiding van de gebeurtenis is en de sleutelgegevens geven aan op welk object de notificatie van toepassing is. Bij een gebeurtenis die gerelateerd is aan een persoon kan hierbij gedacht worden aan een BSN en bij een bedrijf aan een KvK-nummer. Notificaties kunnen zowel voortkomen uit interne- als externe bronnen. Voorbeelden van externe bronnen zijn basisregistraties, landelijke voorzieningen en sectorale knooppunten. Interne bronnen zijn bijvoorbeeld de zaakregistratiecomponent die statussen van zaken via notificaties publiceert.
Het besluit of op basis van een notificatie actie ondernomen moete worden kan mensenwerk zijn, maar het kan ook op basis van bedrijfsregels worden geautomatiseerd. Input voor deze afweging zijn de context van de notificatie, de sleutelgegevens en gegevens en lopende processen in de eigen applicatie.
Gegevensmagazijncomponent
De gegevensmagazijncomponent slaat gegevens uit verschillende basisregistraties in samenhang met elkaar op. In de gegevensmagazijncomponent worden zowel de gegevens opgeslagen van basisregistraties waar de gemeenten bronhouder van is als diegene waar de gemeente enkel afnemer van is. Implementaties van gegevensmagazijncomponenten volgen inhoudelijk de modellering van gegevens die in het Referentiestelsel Gemeentelijke Basisgegevens (RSGB) gedefinieerd zijn. Aanlevering van gegevens aan de gegevensmagazijncomponent vindt bij voorkeur plaats via StUF-kennisgevingsberichten. Bron van de kennisgevingsberichten kan het bronsysteem of een gegevensdistributiesysteem zijn. Het vullen van het gegevensmagazijn via kennisgevingen heeft de voorkeur aangezien op die manier de gegevensmagazijncomponent near-realtime gegevens bevat.
Het gegevensmagazijncomponent bevat een kopie van brongegevens. De component is zelf nooit bronsysteem van gegevens. De gegevensmagazijncomponent kent geen functionaliteit om gegevens te muteren. Indien gegevens in het gegevensmagazijn gewijzigd moeten worden dient dit plaats te vinden via de bronsystemen van deze gegevens; de basisregistraties. Deze bronsystemen werken vervolgens via StUF-kennisgevingen de gegevensmagazijncomponent bij. Als een gebruiker van het gegevensmagazijn vermoed dat de gegevens in de gegevensmagazijncomponent onjuist zijn dan kan de gebruiker dit via een terugmelding doorgegeven aan de betreffende bronhouder.
De gegevensmagazijncomponent kan technisch beschouwd worden als een Operational Data Store (ODS).
Functies van de gegevensmagazijncomponent
Gebruiksdoelen van gegevensmagazijnsystemen zijn het inzage geven aan geautoriseerde gebruikers in (gecombineerde) gegevens en het via webservices bieden van bevragingsmogelijkheden. De gegevensmagazijncomponent is geoptimaliseerd voor het ontsluiten van gegevens die gerelateerd zijn aan één object. Voor het uitvoeren van selecties, analyses en complexe bevragingen is de gegevensmagazijncomponent minder geschikt. Hiervoor wordt het data-warehousecomponent gebruikt. De gegevensmagazijncomponent speelt een zeer belangrijke rol in de informatievoorziening naar burgers en bedrijven. De gegevensmagazijncomponent wordt gebruikt voor het ontsluiten van de (persoons)gegevens naar burgers en bedrijven. Deze component dient hiermee als buffer tussen de gemeentelijke processen en bronsystemen en de burger. Zie voor een nadere toelichting over deze inzet van het gegevensmagazijncomponent ook Informatievoorziening voor dienstverleningsprocessen
Er kleven nadelen aan de redundante opslag van gegevens van basis- en kerngegevens. De gegevens van de gegevensmagazijncomponent moeten synchroon worden gehouden met de bronregistratie om te voorkomen dat verkeerde gegevens worden gebruikt in processen. Deze synchronisatie moet secuur uitgevoerd en gemonitord worden. Dit kost menskracht en middelen.
Data-warehousecomponent
Net als bij de gegevensmagazijncomponent worden ook in de data-warehousecomponent verschillende actuele gegevens samengebracht. Beide componenten worden gebruikt voor de opslag van gegevens en de ontsluiting van deze gegevens naar afnemers. In tegenstelling tot een gegevensmagazijncomponent wordt de data-warehousecomponent echter niet via mutatieberichten maar via ETL-processen gevoed. Ook bevat de data-warehousecomponent meer gegevens dan enkel de RSGB-gegevens. De data-warehousecomponent bevat naast de basisgegevens ook gegevens uit sectorale informatiesystemen en kernregistraties. Binnen de data-warehousecomponent worden deze gegevens onderling in verband gebracht. De data-warehousecomponent wordt typisch gevuld via ETL processen die met een bepaalde frequentie, bijvoorbeeld één keer per week, uitgevoerd worden. De actualiteit van gegevens in de data-warehousecomponent is daarmee (veel) lager dan die van een gegevensmagazijncomponent. Data-warehousesystemen zijn geoptimaliseerd voor het snel kunnen verwerken van grote hoeveelheden gegevens en bieden toegang tot de gegevens via een ‘datamart’. Een datamart bevat een deel van de gegevens uit het data-warehousecomponent en is meestal geoptimaliseerd op het efficiënt beantwoorden van vragen van een specifiek domein of thema. Data-warehousesystemen worden voornamelijk gebruikt voor het uitvoeren van data analyses en rapportages.
Functies van de data-warehousecomponent
Data-warehousesystemen bieden, net als een gegevensmagazijn, geen functionaliteit voor het muteren van gegevens in de data-warehouse. Indien gegevens gewijzigd moeten worden dan dient dit plaats te vinden via de aanleverende bronsystemen of via de in de verschillende ETL-processen vastgelegde regels. Afnemers van gegevens uit een data-warehousecomponent zijn onder andere managementinformatiecomponenten.
Zaakregistratiecomponent
De zaakregistratiecomponent is de component die gegevens over zaken opslaat en ter beschikking stelt aan geautoriseerde afnemers. De zaakregistratiecomponent krijgt gegevens aangeleverd vanuit één of meer referentiecomponenten die het afhandelen van zaken/processen ondersteunen. Dergelijke componenten zijn bijvoorbeeld de zakenafhandelcomponent en taakspecifieke componenten zoals een Vergunningencomponent of een WOZ-administratiecomponent.
Implementaties van de zaakregistratiecomponent implementeren minimaal de opslag van de gegevens die in het Referentiemodel Gemeentelijke Basisgegevens Zaken (RGBZ) gedefinieerd zijn. De zaakregistratiecomponent wordt via de StUF zaakservices van de meest actuele gegevens voorzien.
Functies van de zaakregistratiecomponent
Loggingcomponent
De loggingcomponent is de component binnen de informatiearchitectuur die centraal de bewerkingen die gebruikers uitvoeren vastgelegd. Hetzelfde geldt voor andere relevante gebeurtenissen, zoals pogingen om ongeautoriseerd toegang te krijgen tot gegevens en verstoringen die kunnen leiden tot verminking of verlies van gegevens. De verschillende gemeentelijke referentiecomponenten maken gebruik van diensten die door de loggingcomponent worden geboden om logentries aan te leveren.
De gegevens die door de loggingcomponent worden bijgehouden kunnen door gemeenten worden gebruikt bij de beantwoording van Wob-verzoeken, beantwoording van inzageverzoeken van burgers, verantwoording van het gebruik van gegevens en ze kunnen door de functionaris voor de gegevensbescherming worden gebruikt bij het toetsen of gegevens conform gemaakte afspraken zijn verwerkt.
De loggingcomponent houdt onder andere de volgende gegevens bij:
- Identificerende sleutel;
- Identificatie van de gebruiker die de gegevens verwerkt heeft;
- Doel van de verwerking door de gebruiker;
- Datum en tijd van verwerking;
- Categorieën van attributen die verwerkt zijn.
Via de logging kan door geautoriseerde gebruikers bepaald worden wie, waarom, welke persoonsgegevens heeft verwerkt. De logging kan gebruikt worden voor het afleggen van over de verwerking van gegevens en kan gebruikt worden bij het bepalen of conform de gemeentelijke protocollen ten aanzien van de verwerking van persoonsgegevens gewerkt is. Het lijkt in het kader van de transparantie naar de burger ten aanzien van de verwerking van persoonsgegevens logisch om de door de loggingcomponent geregistreerde logging te ontsluiten via het MijnGemeente component. Hierbij moet worden opgemerkt dat in de loggingcomponent verwerkingen van (persoons)gegevens worden vastgelegd die niet geschikt zijn voor real-time transparantie. Denk hierbij bijvoorbeeld aan gegevens die in het kader van een fraude- of handhavingsonderzoek worden vastgelegd. Zolang dergelijke onderzoeken lopen is het bieden van transparantie hierover niet in het belang van het onderzoek. Dergelijke gegevens kunnen pas na afloop van het onderzoek met de burger gedeeld worden. De registratie van de loggingcomponent kan dus niet zonder nadere (handmatige) filtering aan de burger worden aangeboden.
Functies van de loggingcomponent
Bepaalde gegevens in de logbestanden zijn gekoppeld aan het BSN als identificerende sleutel en zijn dus herleidbaar tot personen. Er is daarmee sprake van een verwerking van persoonsgegevens in de zin van de Wbp. Een aandachtspunt voor gemeenten hierbij is dat indien de gemeentelijke systemen die personeelsgegevens verwerken gekoppeld zijn aan de loggingcomponent kan er sprake zijn van een personeelsvolgsysteem in de zin van artikel 27 lid 1 van de Wet op de ondernemingsraden (WOR), waarvoor instemming van de ondernemingsraad is vereist.
Het loggingcomponent wordt in 2017 in samenwerking met gemeenten en leveranciers functioneel en technisch uitgewerkt.
Open-data-portaalcomponent
De open-data-portaalcomponent is binnen de GEMMA architectuur de component waarmee gestructureerde publieke gegevens worden verzameld en beschikbaar gesteld aan afnemers. Via deze component wordt zowel aan interne als externe afnemers toegang geboden tot de publieke gegevens (open data) die door de verschillende informatiesystemen van de gemeente worden gegenereerd. Het portaal ordent de gegevens, transformeert deze desgewenst en biedt de gegevens aan op een manier dat deze downloadbaar is voor eindgebruikers en direct bruikbaar is voor gebruik binnen toepassingen. Vanuit (combinaties van) dit soort open gegevens kunnen veel nieuwe soorten diensten en apps ontwikkeld worden. Vaak zal dit in de vorm van apps voor smartphones en tablets zijn, maar ook voor pc-gebruik of andere apparaten zijn toepassingen goed mogelijk.
Functies van de open-data-portaalcomponent
Mijngemeentecomponent
Deze component biedt klanten toegang tot gepersonaliseerde digitale dienstverlening van de gemeente. Om toegang te krijgen tot de diensten van de mijngemeentecomponent authenticeren klanten zich via DigiD of eHerkenning. Na succesvolle authenticatie worden de digitale diensten beschikbaar voor de klant. Deze diensten kunnen bestaan uit het tonen van de over de klant geregistreerde gegevens, het tonen van de status van lopende zaken en mogelijkheden voor de klant om de eigen gegevens bij te houden.
Deze component speelt een belangrijke rol in de stimulering van de zelfredzaamheid van de klant en de bijbehorende verbetering van de informatiepositie van de klant. De component is de verbinding tussen klant en gemeente op het gebied van gepersonaliseerde digitale dienstverlening.
Functies van de mijngemeententecomponent
Via de generieke digitale infrastructuur van de overheid (GDI) wordt het MijnGemeente component aangeboden. Dit component biedt burgers inzage in de gegevens die de verschillende overheidsinstanties bijhouden. Via MijnOverheid wordt onder andere inzage gegeven in de gegevens die in bij de BRP, RDW en WOZ-administratie zijn vastgelegd. MijnOverheid en het MijnGemeentecomponent vertonen overlap van functionaliteit. Als de door MijnOverheid geboden functionaliteit aansluit bij de ambitie van de gemeente ten aanzien van transparantie naar de burger dan kan de gemeente er voor kiezen om het MijnGemeentecomponent lokaal niet in te vullen maar alleen aan te sluiten op MijnOverheid. Indien de gemeente andere, of meer, gegevens naar de burger wil ontsluiten dan door MijnOverheid ondersteund worden dan zal de gemeente dit via een MijnGemeentecomponent kunnen realiseren.
Ketenpartner-portaalcomponent
Via dit component wordt aan geautoriseerde ketenpartners toegang gegeven tot voor hen bestemde diensten. De ketenpartnerportaal-component authenticeert een ketenpartner en geeft daarna aan de ketenpartner toegang tot geautoriseerde diensten. Diensten die door gemeenten aan ketenpartners ter beschikking worden gesteld kunnen variëren in diensten die ketenpartners kunnen gebruiken voor het aanleveren van statistische- of verantwoordingsinformatie of diensten waarmee ketenpartners de voortgang melden van zaken die zij in opdracht, of onder regie van, de gemeente uitvoeren. De manier waarop de ketenpartners gegevens kunnen aanleveren of aangeleverd krijgen kan variëren van up- en downloadportalen tot webservices.
Het staat gemeenten vrij om zelf een authenticatiemiddel te kiezen om de diensten die geboden worden mee te beveiligen. Het meest voor de hand liggende middel bij diensten die via gebruikersschermen van de ketenpartner-portaalcomponent worden aangeboden is eHerkenning. Bij webservice georiënteerde diensten is een PKI(O) certificaat een logische keuze.
Functies van de ketenportaalcomponent
Voetnoten
GEMMA Patronen
Let op: deze pagina is gearchiveerd
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
- Verbinden met keten- en netwerkpartijen
- Inwinnen en routeren van notificaties
- Binnengemeentelijk beschikbaar stellen basis- en kerngegevens
- Beschikbaar stellen managementinformatie
- Dienstverlening naar klanten
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.
- ↑ 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.
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.
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.
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.
- ↑ 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.
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.
- ↑ zie ook Verbinden met klanten.
Voetnoten
Bijlage: Integratiestijlen en functies
Let op: deze pagina is gearchiveerd
Vanuit de literatuur zijn er een aantal standaard patronen beschreven die gebruikt worden bij het integreren van informatiesystemen. Deze patronen worden integratiestijlen genoemd. In dit hoofdstuk worden de uit de literatuur bekende integratiepatronen beschreven en worden de belangrijkste functies beschreven die voor de implementatie van de integratiepatronen van belang zijn.
Integratiestijlen
Bij uitwisseling tussen, en integratie van, informatiesystemen werken één of meer informatiesystemen samen tijdens de uitvoering van hun functies. Deze samenwerking kan bestaan uit de uitwisseling van gegevens, informatie of signalen met andere informatiesystemen of het laten uitvoeren van delen van taken van het ene informatiesysteem door een ander informatiesysteem. Voor het laten samenwerken van informatiesystemen zijn binnen de IT een aantal standaard ‘integratiestijlen’ beschreven. De leidende stijlen zijn (Hophe & Woolf, 2006):
- Gedeelde database (shared database);
- Bestandsuitwisseling;
- Externe applicatiefunctionaliteit aanroep, en
- Berichtuitwisseling.
Elk van de integratiestijlen kent een toepassingsgebied, specifieke voor- en nadelen en functionaliteit die benodigd is voor het realiseren van de integratiestijl. In de praktijk bij gemeenten worden de meeste van deze integratiestijlen toegepast.
Doel van de integratiestijl is het delen van gegevens tussen informatiesystemen. Dit wordt in deze integratiestijl bereikt door meerdere informatiesystemen gebruik te laten maken van één gedeelde gegevensopslag. Toegang tot de gegevensopslag wordt verschaft door aan de informatiesystemen lees- en schrijfrechten op deze gegevensopslag te verlenen. Toegang tot de gegevens wordt geleverd door het database management systeem (DBMS).
Het door meerdere informatiesystemen lezen van gegevens uit een gedeelde database is vanuit het oogpunt van gegevensintegriteit relatief risicoloos. Aan het muteren van gegevens in een gedeelde database kleven op dat vlak wel risico’s. Bij mutaties van gegevens in een gedeelde database borgt het DBMS de referentiële integriteit van de gegevens. Wat het DBMS niet doet is het borgen van de kwaliteit van de gegevens. Deze kwaliteitscontroles liggen immers in bedrijfsregels vast in de bedrijfslogica van informatiesystemen die gebruik maken van de gedeelde opslag. Hierdoor kan het voorkomen dat gegevens die door informatiesysteem A worden opgeslagen volgens de bedrijfsregels van informatiesysteem B van onvoldoende kwaliteit zijn. Denk hierbij aan controles die worden uitgevoerd op de combinatie van postcode, huisnummer en straatnaam. Sommige informatiesystemen zullen deze combinatie afdwingen door gebruik van een postcodetabel terwijl andere informatiesystemen dit niet doen.
De gedeelde database integratiestijl kent verder zeer beperkte mogelijkheden op het gebied van informatiebeveiliging, bescherming van de privacy en verantwoording over de verwerking van gegevens. De oorzaak hiervan ligt in een aantal oorzaken:
- Er is geen mogelijkheid om op het niveau van de gegevensopslag doelbinding van de afnemer af te dwingen bij het verwerken van gegevens. Doelbinding kan slechts afgedwongen worden in de aangesloten informatiesystemen;
- Gegevens kunnen buiten de uitvoering van een proces om gemuteerd worden door een andere applicatie. Dit staat op gespannen voet met de integriteit van gegevens en het achteraf kunnen afleggen van verantwoording over de uitvoering van processen;
- Gegevens kunnen verloren gaan of inconsistent worden doordat de verschillende aangesloten informatiesystemen op verschillende wijze omgaan met het ‘locken’ van gegevens in de database op het moment dat gegevens gemuteerd worden.
Om bovenstaande redenen is toepassing van deze integratiestijl bij de verwerking van privacygevoelige gegevens afgeraden . Indien gegevens van verschillende informatiesystemen opgeslagen moeten worden binnen één gegevensopslag dan is daarvoor het ‘Externe applicatiefunctionaliteit aanroep’ integratiepatroon de aangewezen oplossing. Hierbij moet worden opgemerkt dat deze aanbeveling geldt voor situaties waar meerdere informatiesystemen gegevens delen en niet van toepassing is op één informatiesysteem wat meerdere referentiecomponenten implementeert. Op het moment dat één informatiesysteem invulling geeft aan meerdere referentiecomponenten dan is er geen bezwaar tegen het delen van de opslag door deze referentiecomponenten. De beschreven nadelen treden dan namelijk niet op.
Een gebied waarop deze integratiestijl wel toegepast kan worden is het geo-domein. In dit domein worden gegevens verwerkt die meestal publiek van aard zijn. Hierdoor treden de eerder genoemde risico’s op het gebied van de privacy niet op. Met name in dit domein is het mogelijk om, via een modern databasemanagementsysteem dat ook geografische data kan verwerken (bijvoorbeeld Oracle Spatial), verschillende ruimtelijke objecten binnen één databaseopslag bij te houden. Een dergelijk databasemanagement is tevens in staat om de geografische data via slimme views zo te transformeren, zodat dezelfde geodata voor verschillende GIS-systemen (Geoviewer, BeheerGIS, AnalyseGIS en een GEO-API) begrijpelijk wordt. Belangrijk hierbij is wel dat per objecttype er één eigenaar benoemd is zodat geen dubbel beheer van objecten plaatsvindt met risico’s van het overschrijven van wijzigingen. De eerder beschreven locking problematiek wordt daarmee data beheersbaar en een beperkt risico.
Een bijzondere uitwerking van de ‘gedeelde database’ integratiestijl is geven van leesrechten tot gegevens van een informatiesysteem aan andere informatiesystemen via directe toegang tot de gegevensopslag. Toegang tot de gegevens wordt geleverd door het database management systeem (DBMS). Gegevens worden gelezen uit de database via gegevensservices die aangeroepen worden via een SQL- of soortgelijke interface.