In mijn vorige artikel schreef ik over de verbreding van MijnZaken naar MijnServices. De ontwikkelingen rondom MijnServices hebben het afgelopen jaar niet stil gestaan. Afgelopen 25 maart vond het jaarlijkse Omnichannel event van de VNG plaats. Via verschillende presentaties zijn gemeenten en leveranciers weer op de hoogte gebracht van de laatste ontwikkelingen van deze moderne vorm van dienstverlening. Mijn collega’s Karlijn van Dam en Thor Berns hebben hierover een artikel geschreven. Ik bespreek kort eén van die presentaties: de architectuur van MijnServices.

Common Ground

Het fundament van de MijnServices is gebaseerd op de visie Common Ground. Dit betekent onder andere dat gegevens worden verwerkt bij de bron. Het voordeel hiervan is, dat gegevens niet meer gekopieerd worden. Toegang tot die gegevens is beter te beheren, er is maar één waarheid van de gegevens én de gegevens zijn via meerdere applicaties te benaderen.

Figuur 1: Meerdere applicaties bevragen één bron (bron: VNG)

Dat gegevens via meerdere applicaties verwerkt kunnen worden, past naadloos in de gedachte van Omnichannel. Via meerdere kanalen worden dezelfde gegevens getoond. Of dat kanaal nu een back-office applicatie voor een medewerker is of een MijnOmgeving voor een inwoner of ondernemer. De gegevens kunnen zelfs buiten de eigen organisatie worden getoond, zoals bij MijnOverheid.

Gestandaardiseerde API’s

Om gegevens aan verschillende applicaties van de eigen organisatie of andere organisaties beschikbaar te stellen, moeten wel afspraken gemaakt worden over het benaderen van die gegevens. Dat is gedaan door gebruik te maken van gestandaardiseerde API’s. De basis ligt in het gebruik van de API Standaarden voor Zaakgericht Werken. Zowel de software waarin de gegevens zijn opgeslagen als de software die gebruikt wordt door de inwoner/ondernemer of medewerker maken gebruik van deze standaard. Er wordt nu verder ontwikkeld aan een uitbreiding in de vorm van een standaard voor Klantinteractie. Niet alleen de standaarden voor het werken met zaken, maar ook voor taken, berichten, contactmomenten, profielen, producten en mogelijk ook al dossiers worden nu standaarden ontworpen, ontwikkeld en beproefd.

Het zijn dan ook deze standaarden die de basis vormen voor het gebruik en het toepassen van de MijnServices.

Event Driven Architecture

Met de introductie van de MijnServices wordt ook een (voor gemeenten) nieuw architectuurconcept gebruikt: Event Driven Architecture of in het Nederlands Gebeurtenis Gedreven Architectuur. Elke actie (of CRUD-operatie) levert een gebeurtenis op. Bijvoorbeeld dat er een zaak is gecreëerd. Of dat een status van een zaak is gewijzigd. Of een document is opgeslagen. Het feit dát er iets is gebeurd, wordt een event genoemd. En elke registratie waarin een dergelijke gebeurtenis optreedt, stuurt een signaaltje naar een andere softwarecomponent. Die signaaltjes zijn gegroepeerd naar een bepaald onderwerp (topics).

Nu zijn er ook softwarecomponenten die mogelijk geïnteresseerd zijn in die signaaltjes. Daarvoor nemen ze een abonnement op één of meer van die onderwerpen. En zodra er een signaaltje op een onderwerp wordt geplaatst, worden de geabonneerde softwarecomponenten daarvan op de hoogte gesteld. Op basis hiervan kan de ontvangende softwarecomponent bepalen of het iets met de gebeurtenis in die ene registratie wil doen.

Figuur 2: Publiceren en ontvangen van events

Dit mechanisme wordt ook wel publish-subscribe mechanisme genoemd. Het ene softwarecomponent publiceert (publish) een event en andere softwarecomponenten worden geïnformeerd als ze een abonnement (subscribe) hebben. De registratie waarin de gebeurtenis plaatsvindt, heeft geen idee wie allemaal geïnteresseerd is in die gebeurtenis. Dat register ‘vertelt’ gewoon dat er iets is gebeurd. Deze architectuur maakt het dan ook mogelijk om meer onafhankelijke softwaresystemen te ontwikkelen. Zodra er een nieuw softwarecomponent in het landschap wordt toegevoegd, hoeft er geen aanpassing aan de bron (lees: de registratie) doorgevoerd te worden. Ook kunnen bronnen eenvoudiger worden opgenomen in het landschap. Implementaties en vervanging van software worden zo een stuk flexibeler.

Outputmanagement

Eén component in de MijnServices architectuur maakt als geabonneerde gebruik van deze events. Dat is de Outputmanagementcomponent. Deze softwarecomponent heeft een abonnement op een aantal onderwerpen. Bijvoorbeeld op het onderwerp dat er zaken zijn aangemaakt. Of op het onderwerp dat er een status van een zaak is gewijzigd. Of dat er een taak voor een inwoner of ondernemer is aangemaakt.

Op basis van het signaaltje dat de Outputmanagementcomponent ontvangt, bepaalt het aan de hand van bedrijfsregels wat het moet gaan doen: onderneemt het actie of wordt het signaaltje genegeerd? Een actie kan bijvoorbeeld zijn dat er gecontroleerd wordt of de inwoner op de hoogte gebracht wil worden van het feit dat de status van zijn zaak is veranderd. Of dat er een taak voor de inwoner klaarstaat die uitgevoerd moet worden.

Centrale functionaliteiten

Door gebruik te maken van de Event Driven Architecture kunnen bepaalde functionaliteiten centraal worden geregeld. Zoals bijvoorbeeld het sturen van een ontvangstbevestiging. Of het sturen van een herinneringsmail als de taak niet voor een bepaalde datum is uitgevoerd. Die functionaliteit hoeft dan niet meer in elke zaakafhandelcomponent (of procesapplicatie) ingebouwd te worden. Ook de koppelingen tussen de verschillende softwaresystemen kunnen minder afhankelijk van elkaar worden. Als bijvoorbeeld een taak door een inwoner is uitgevoerd, wordt de procesapplicatie via een event daarvan op de hoogte gesteld. De medewerker kan dan weer verder met het behandelen van de zaak. Maar een andere softwarecomponent kan ook bepalen om verdere actie te ondernemen. De registratie waarin de taak is verwerkt, hoeft van de achterliggende processen niet op de hoogte te zijn.

Meer weten?

Wilt u meer weten hoe de architectuur van MijnServices in uw organisatie kan passen? Neem dan contact op Paul Jansen via de contactpagina.