Patroon verzoeken om dienst

Inleiding

Bij het verlenen van diensten verzoekt een ketenpartner de andere ketenpartner om iets te doen en verwacht een terugkoppeling op dit verzoek. De modaliteiten van dit verzoek (bijv. eisen aan de geleverde dienst, vorm van de terugkoppeling, reactietermijn, etc.) moeten (niet vrijblijvend) vooraf zijn afgesproken en zijn vastgelegd in een SLA (of soortgelijke bindende en overeengekomen afspraken). Bijvoorbeeld het vragen van een advies aan de IND (Immigratie en Naturalisatie Dienst) over de echtheid van een document of aan het ECID. Het Expertisecentrum Identiteitsfraude en Documenten (ECID) is hét landelijke aanspreekpunt voor identiteitsfraude en documenten een samenwerkingsverband tussen de Koninklijke Marechaussee en politie. Of een verzoek van het COA (Centraal Orgaan opvang asielzoekers) aan DV&O (Dienst Vervoer en Ondersteuning, onderdeel van DJI) voor het vervoeren van een vreemdeling. Of een verzoek om informatie over een bepaald persoon of proces te verzamelen en beschikbaar te stellen (anders dan informatie die rechtstreeks opgevraagd kan worden).

Het patroon 'verlenen van diensten' volgt het patroon uit de bedrijfsarchitectuur, zoals beschreven in Bedrijfsdiensten.

Belangrijke eigenschap van dit patroon is de asynchrone verwerking van het verzoek; met andere woorden: na het verzoek gaat er enige tijd overheen voordat de terugkoppeling volgt. Bij een informatiedienst moet deze informatie bijvoorbeeld eerst worden opgezocht en of verzameld. Kan de informatie direct via een API worden opgevraagd bij een andere ketenpartner, dan is er sprake van een synchrone verwerking en is het patroon van verkrijgen van informatie van toepassing. Dit patroon structureert het verlenen van diensten binnen de keten door het uitwerken van een uniforme en digitale manier van aanvragen en leveren van (of terugkoppelen over) diensten.

De belangrijkste principes uit de MIRA Thema’s en principes die richting geven aan de uitwerking van dit patroon zijn:

2B Het beheersen van de wederzijdse afhankelijkheid is een gezamenlijke plicht

Verzoeken om dienst is één van de type afhankelijkheden waarop in dit principe gedoeld wordt.

4C De ketenvoorzieningen zijn modulair opgebouwd en hun rol en functie is duidelijk

Verzoeken is een duidelijk ander patroon dan informatie verkrijgen of notificeren. De ondersteuning van verschillende patronen niet laten overlappen. Diensten zijn beschikbaar via een catalogus met goed gedefinieerde servicecontracten.

4D De keten hanteert een standaard uitwisselingsmechanisme

Koppepvlakken om diensten aan te vragen en resultaat terug te melden worden gerealiseerd dmv. RESTful API's.

Architectuurplaat patroon verzoeken om dienst

In onderstaande figuur de architectuur voor het patroon verzoeken om dienst getekend.

Selecteer een kleurenweergave :

Toon plaat groter

Algemene beschrijving van dit patroon

De afnemende partij kan in dit geval een Ketenpartner, of Samenwerkingspartner zijn. Het Systeem van afnemer dienst is in dit patroon het systeem van waaruit de ketenpartner een verzoek om een dienst initieert. Het Systeem van aanbieder dienst is het systeem dat het verzoek ontvangt en verder behandelt, al is dit laatste strikt genomen een zaak voor de ketenpartner zelf.

Het systeem van de aanbieder registreert een dienst in de dienstencatalogus.
- Dit kan ofwel via een API-aanroep vanuit het systeem van de aanbieder, ofwel via een gebruikersinterface
Het systeem van de afnemer zoekt in de catalogus naar de juiste dienst en haalt hier de specifieke URI op waar de dienst kan worden aangeroepen.
- Dit hoeft voor frequent aangevraagde diensten wellicht niet elke keer. Maar het doel van de catalogus is wel het ontkoppelen dmv. een verwijzing naar de juiste URI in de catalogus. Hier kan in de verdere uitwerking wel een (technische) oplossing voor gevonden worden.
Het systeem van de afnemer levert een verzoek om een dienst af bij de API van de aanbiedende partner en krijgt een technische ontvangstbevestiging en (obv de afspraken in het servicecontract) een bevestiging van de acceptatie van de opdracht ("ik ga het (niet) doen")
Wanneer de dienst geleverd kan en mag (autorisatie) worden of is geleverd, krijgt het systeem van de afnemer één of enkele/meerdere terugkoppelingen op het verzoek om de dienst terug, voorzien van het identificatienummer van het bijbehorende verzoek.

Centrale Voorzieningen

Componenten

Naam	Omschrijving	Toelichting
Dienstencatalogus	Een centrale voorziening in de keten waarin de diensten die aangeboden worden door de keten- of samenwerkingspartners binnen de Migratieketen worden beschreven en gepubliceerd.	De dienstencatalogus bevat gegevens over een dienst, de aanbiedende ketenpartner, de toegestane afnemende ketenpartners, de contactgegevens bij de aanbieder, de URL voor het aanvragen van de dienst, en de minimale vereiste gegevens voor het ‘bestellen’ van de dienst en een verwijzing naar de bij de dienst behorende SLA Er moet, niet vrijblijvend, altijd een contract, convenant of andersoortige afspraak tussen afnemer en aanbieder aan het leveren van een dienst ten grondslag liggen. Deze en eventuele bijbehorende DPIA of andersoortige afspraken kunnen eventueel ook via de Dienstencatalogus ontsloten worden Nut en noodzaak van een centrale dienstencatalogus in de keten (dwz. van een centraal overzicht van onderling geleverde diensten) moet na de quick-scan of PoC worden bepaald.

Api's en andere Interfaces op centrale voorzieningen

Naam	Omschrijving	Toelichting
Beheer functionaliteit	Gebruikersinterface waarmee de Dienstencatalogus kan worden doorzocht en waarmee nieuwe diensten en bijbehorende informatie geregistreerd en gewijzigd kan worden	Doordat o.a. de onderliggende afspraken en contactgegevens geregistreerd dienen te worden, is een gebruikersinterface hiervoor wellicht de meest gebruikte optie Het volume en de veranderfrequentie van diensten is naar verwachting niet zo hoog als bv. Bij de gebeurtenissen of gegevenscatalogus.
Registreer-dienst api	API waarmee dienst geregistreerd kan worden in de ketenbrede dienstencatalogus	-
Zoekdienst api	API waarmee dienst gezocht kan worden in de ketenbrede dienstencatalogus	Deze API geeft de specifieke URL terug waar de dienst kan worden aangeroepen.

Eisen aan Ketenpartners

Systemen van Ketenpartners

Naam	Omschrijving	Toelichting
Systeem van aanbieder dienst	Systeem van de partij die diensten aanbiedt.	Voor het patroon verzoeken kunnen het ketenpartners of samenwerkingspartners zijn die diensten aanbieden . Partijen buiten de keten maken geen gebruik van onze voorzieningen en zullen wellicht eigen standaarden hanteren. Het bronsysteem is het systeem dat de verzoeken ontvangt. Voor een vervoersdienst kan het een rittenplanningssysteem zijn. Maar evengoed een simpele webapplicatie waar iemand achter zit die de levering van een dienst in gang zet.
Systeem van afnemer dienst	Systeem van partij die diensten afneemt	Afnemers van de dienst zijn in dit patroon beperkt tot Ketenpartners en Samenwerkingspartners. Het staat ketenpartners echtr vrij om ook verzoeken om een dienst van andere overheidspartijen te accepteren volgens deze standaard. Toegang tot de dienstencatalogus is echter beperkt tot de eerder genoemde groepen.

API's te realiseren door Ketenpartners

Has target element	Omschrijving	Toelichting
Verzoek specifiek api	Een API waarmee een verzoek om een specifieke dienst ontvangen kan worden.	De dienstencatalogus bevat een verwijzing naar de URI waar die specifieke dienst aangevraagd kan worden. Omdat alle diensten een andere gegevensset verwachten, zijn dit verschillende API’s De exacte uitwerking hiervan laten we over aan de onderliggende oplossingsarchitectuur
Ontvangantwoord api	Een API waarop het antwoord van een eerder gedaan verzoek om een dienst ontvangen kan worden.	Diensten zijn bijna bij definitie asynchroon, dus het antwoord op het verzoek (bv. een bevestiging van de levering van de dienst of een informatieproduct igv een informatiedienst zal op een later tijdstip bezorgd worden. De ontvangantwoord APi moet ook geschikt zijn om tussentijdse statusupdates te kunnen geven voor diensten met een lange levertijd.

Aanvullende Afspraken en Standaarden

Naast het gezamenlijk ontwerp van de dienstencatalogus en de benodigde APIs en interfaces hierop, moeten er aanvullende afspraken gemaakt wordenn over hoe gegevens behorend bij een te leveren dienst, best gemodelleerd kunnen worden. Ook over de gegevenskwaliteit in de gegevenscatalogus zullen de ketenpartners nog afspraken moeten maken en deze expliciteren.

Er is een Gegevensmodel verzoeken nodig waarin informatie die nodig is voor het uitwisselen van verzoeken kan worden gemodelleerd. Hierin moet ook aandacht zijn voor een manier om specifieke informatie per soort verzoek hieraan te kunnen relateren of meesturen.

Privacy by Design

Afhankelijk van welke soort dienst wordt aangevraagd, kunnen er individuele persoonsgegevens over de lijn gaan bij het ‘bestellen’ van een dienst. Anders is het niet mogelijk om uit te drukken op welke persoon de gevraagde dienst betrekking heeft. De ketenpartners (aanbieders) gaan maximaal uit van ‘niet tot op de persoon herleidbare gegevens’. Data-minimalisatie is een uitgangspunt om de privacy by design te maximaliseren. De diensten zullen hiertoe zo moeten worden gedefinieerd dat enkel de minimale benodigde set gegevens wordt meegestuurd. Zo is het bijvoorbeeld niet nodig voor een chauffeur om de volledige persoonsgegevens van een vreemdeling te hebben om deze van locatie A naar locatie B te vervoeren. Eventuele gegevens die aanvullend nodig zijn voor het leveren van de dienst, kunnen via het ‘informatie verkrijgen’ patroon worden opgevraagd bij de keten. Het is dus niet de bedoeling dat hele gegevenssets of dossiers meegestuurd worden bij het verzoek om een dienst. Ook hier geldt data minimalisatie. Dit is ook voordelig voor de datakwaliteit. Meegestuurde gegevens kunnen verouderen, maar gegevens die op het moment dat een dienst geleverd wordt worden opgehaald bij de bron zijn altijd actueel. Het is de verantwoordelijkheid van de dienst aanbieder om de gegevens uit zijn bron actueel te houden. Diensten kunnen enkel worden afgenomen als er een onderliggende overeenkomst is en deze in de dienstencatalogus is geregistreerd. Zo kan er bewaakt worden dat enkel geautoriseerde ketenpartners, eventuele gevoelige, gegevens kunnen inzien. Uiteraard wordt er aan aanbiedende en afnemende kant gelogd, zodat er een audittrail kan ontstaan.

Europese Context

Er bestaat ook onderlinge dienstverlening tussen NL en Europese ketenpartners. Zie Bedrijfsdiensten. Dit zal naar verwachting in de toekomst in belang toenemen. Bij de meeste van deze dienstverlening horen specifieke Europese afspraken en protocollen, zoals bijvoorbeeld de ‘communication tools’ ikv. oplossen ‘gele linkjes’; ‘VISmail’ en ‘SISmail’,....

Op termijn zouden we ketenpartners kunnen ontzorgen door dit soort diensten ook op te nemen in de dienstencatalogus in de keten en deze uitwisselingen via de dezelfde koppelvlakken op het Europaloket aan te bieden. Het Europaloket zou deze verzoeken en de bijbehorende terugkoppelingen dan kunnen vertalen naar de Europese formaten. Momenteel lijkt dit echter nog niet direct aan de orde. Het Europaloket is daarom niet getekend in de bovenstaande plaat.

Transitie en globale planning

Dit hoofdstuk beschrijft hoe de transitie van de huidige situatie naar de in deze architectuur geschetste stip (SOLL) zou kunnen verlopen. Hierdoor kan de impact en de betekenis van hetgeen hierboven geschetst wordt beter ingeschat worden. Deze uitwerking is enkel indicatief. Na goedkeuring van deze architectuur moet dit verder worden uitgewerkt in een meer gedetailleerde en integrale planning.

Voorgestelde stappen zijn:

Quickscan bestaande diensten
- Dit is een eerste inventarisatie, die niet volledig hoeft te zijn. Mogelijke bronnen zijn bestaande dienstverlening via procesverwijzingen, de backlog van de adviesgroep en eventuele overige bilaterale dienstverleningen.
Opstellen ketenbrede solution architectuur dienstencatalogus en koppelvlakken
- In de solution architectuur worden meegenomen de centrale voorzieningen (dienstencatalogus en koppelvlakken) en de koppelvlakken bij de ketenpartners.
Realiseren PoC met enkele ketenpartners
- Op basis van de eerste solution architectuur wordt een proof-of-concept gerealiseerd voor de dienstencatalogus en de koppelvlakken (centraal en bij ketenpartners). Doel is te leren voor de definitieve realisatie.
Raming en Planning Realisatie
- Op basis van de solution architectuur en de lessons learned ramen, prioriteren en plannen van de realisatie van dit patroon.
Herijken/definitief maken solution architectuur en koppelvlakken
Realiseren dienstencatalogus en koppelvlakken
Diensten realiseren volgens nieuw patroon

Openstaande vraagstukken voor dit patroon

Hierbij is telkens aangegeven of deze vraagstukken in een volgende versie van deze architectuur of in de onderliggende solutions moeten worden uitgewerkt.

Onderwerp	Toelichting	Wanneer uitwerken	Uitwerking
Interactiepatroon	Interactiepatroon heeft focus op digitale - system 2 system uitwisseling. Ervaring leert dat parallel 'multichannel' communicatie van invloed kan zijn op de ketenpartij informatie toestand (Bellen, email, digital systems). Zijn multi-channel communicatie afspraken nodig om wisselwerking op informatie te voorkomen bij digitale diensten afname?	een volgende versie
Europa	De context van Europa moet nog verder uitgewerkt worden. Ik mis JustID bijvoorbeeld als dienstleveraar van een nationale GLOS - met koppelvlak naar EU dienst. Idem voor nationale VIS mailbox, SIS mailbox.	een volgende versie	positionering GLOS als ketensysteem op de patronen is nog zeker een openstaand punt