Notificeren introductie

Category:Eventorientatie
__NOTOC__
"Notificeren" betekent iemand of iets via een bericht op de hoogte brengen van iets. De term wordt vaak gebruikt om aan te geven dat iemand officieel geïnformeerd wordt over een bepaalde gebeurtenis of verplichting. In digitale context betekent het vaak dat een applicatie een melding stuurt aan een gebruiker of aan een andere applicatie. Bijvoorbeeld wanneer er een nieuw bericht is ontvangen en dit aan een gebruiker of een applicatie wordt meegedeeld. Notificeren is een belangrijk onderdeel van een event-georiënteerde aanpak, waarbij systemen of mensen direct geïnformeerd worden wanneer er iets gebeurt dat relevant is voor hen. Het stelt hen in de gelegenheid om proactief of reactief passende actie te ondernemen. 
Een belangrijke onderdeel van het project Omnichannel is het notificeren van burgers, waarbij op de achtergrond ook notificaties tussen applicaties een rol spelen. Gemeenten sturen notificaties om hun dienstverlening klantvriendelijker te maken. Ontwikkelingen zoals de Wet modernisering elektronisch bestuurlijk verkeer (Wmebv) maken het bovendien steeds vaker verplicht om burgers te informeren. Bijvoorbeeld wanneer er nieuwe formele berichten beschikbaar zijn, zoals een besluit. Daardoor worden effectieve notificatievoorzieningen voor gemeenten steeds belangrijker, wat vraagt om een ondersteunende informatievoorziening die hierop goed is afgestemd. 
== Notificaties==
Met een 'notificatie' bedoelen het bericht met gegevens die bij notificeren worden verstrekt. Een notificatie kan allerlei soorten informatie bevatten. Op basis van de opgenomen informatie is onderscheid te maken in notificaties over een: *'Seintje': er wordt een signaal afgegeven wanneer er iets is gebeurd. Deze vorm van notificatie is gebruikelijk in de wereld van sensoren (IoT), maar komt minder vaak voor binnen administratieve omgevingen.
*Gegevensmutatie: deze notificaties zijn gericht op het doorgeven van oude en nieuwe gegevens na een verandering ('was-wordt'). De aanleiding en context ontbreekt vaak, waardoor de gebruiker zelf moet afleiden welke gebeurtenis er heeft plaatsgevonden. Dit kan leiden tot foute conclusies en onjuiste acties.
*Gegevensmutatie + Aanleiding: naast de gegevensmutatie wordt ook de aanleiding voor de gebeurtenis meegegeven. Gebruikers begrijpen beter wat er precies is gebeurd en kunnen er beter op reageren.
*Gebeurtenis + Gegevens: In plaats van een aantal 'was-wordt gegevens' worden relevante gegevens over de plaatsgevonden gebeurtenis verstrekt. Afnemers weten op basis hiervan precies wat er is gebeurd. Als alle relevante gegevens zijn verstrekt ('informatierijke notificatie') kunnen consumers daarmee passende actie(s) uitvoeren.
*Gebeurtenis + Identificatie: Bij zo'n 'informatiearme notificatie' worden minimaal gebeurtenisgegevens verstrekt. Met behulp van vertrekte identificerende gegevens kan een consumer eventueel aanvullende gegevens gaan opvragen.
Binnen de overheid komen al deze soorten notificaties voor. Bij een gegevensgerichte werkwijze wordt bijvoorbeeld vaak gebruik gemaakt van 'was-wordt gegevens', die de toestand van gegevensobjecten voor en na een plaatsgevonden gebeurtenis beschrijven, terwijl bij meer event georiënteerd werken vaak de gebeurtenis zelf wordt beschreven. De context bepaalt welke vorm van notificeren wanneer het geschiktst is. Daarbij spelen inhoudelijke aspecten een rol (bijvoorbeeld of privacygevoelige gegevens onderdeel van een notificatie mogen zijn) en praktische aspecten (bijvoorbeeld of afnemende applicaties in staat zijn om bepaalde soorten notificaties te verwerken).
Notificaties kunnen verschillende vormen aannemen, zoals een pushmelding op een smartphone, een e-mail of sms-bericht, een melding op een beeldscherm binnen een applicatie, of elektronische berichten die via API-calls worden verstuurd.
==Brongegevens en notificeren==
De afgelopen jaren is binnen de overheid veel energie gestoken in het gemakkelijker kunnen opvragen van brongegevens via moderne Application Programming Interfaces (API's). In lijn met het principe 'Informeer bij de bron' wordt het daarmee beter mogelijk om gebruik te maken van gegevens in bronregistraties. Uitsluitend kunnen opvragen van brongegevens is voor veel processen echter niet genoeg om er optimaal gebruik van te maken. (Ook) notificeren is nodig om proactief te kunnen handelen of om tijdig actie te ondernemen als eerder opgevraagde brongegevens zijn gewijzigd. Voor optimaal gebruik van bronregistraties moeten bronhouders afnemers dus ook via notificaties informeren over relevante plaatsgevonden gebeurtenissen. Bijvoorbeeld als die hebben geleid tot wijziging van bepaalde brongegevens. Afnemers op hun beurt moeten zorgen dat door hen gebruikte applicaties ontvangen notificaties goed kunnen verwerken. 
== Standaardisatie==
Bij notificeren wordt allerlei soorten informatie tussen allerlei soorten partijen en applicaties uitgewisseld. Om te voorkomen dat organisaties te maken krijgen met veel, vaak onnodige, verschillen is standaardisatie op meerdere vlakken nodig. De NL GOV Profile for CloudEvents standaard beschrijft hoe plaatsgevonden gebeurtenissen door middel van een aantal standaard attributen, met een vast formaat en betekenis, zijn te beschrijven. Overheidsbreed gebruik van deze standaard vergemakkelijkt het maken, uitwisselen en verwerken van notificaties. 
Mede omdat notificaties vaak domeingrenzen overschrijden is ook semantische standaardisatie nodig. Het moet voor alle partijen duidelijk zijn wat de precieze betekenis van de gegevens binnen notificatie is. Een belangrijke eerste stap daarvoor is het zorgvuldig definiëren en documenteren van gebeurtenistypes. Gelet op de grote hoeveelheid betrokken partijen en mogelijke soorten notificaties is het wenselijk dat informatie over beschikbare notificaties op een gestandaardiseerde manier wordt gepubliceerd. Al dan niet via een of meer overheidsbreed toegankelijk catalogi. 
==Intern en extern notificeren ==
Er zijn verschillende situaties waarin applicaties elkaar kunnen notificeren over bepaalde plaatsgevonden gebeurtenissen. Notificeren kan bijvoorbeeld plaatsvinden binnen 1 applicatie (bijvoorbeeld om geautomatiseerd de juiste acties in de juiste volgorde te laten uitvoeren), tussen applicaties binnen 1 organisatie (bijvoorbeeld om interne applicaties te informeren als in een Burgerzakenapplicatie wordt geregistreerd dat een inwoner is overleden) of tussen applicaties van verschillende organisaties (bijvoorbeeld als vanuit de RDW externe applicaties worden geïnformeerd dat een voertuig een nieuwe eigenaar heeft gekregen). Gemeenten hebben te maken met alle 3 soorten use cases.