Omnichannel MijnZaken Informatiearchitectuur

Categorie:Omnichannel
Dit hoofdstuk beschrijft de informatiearchitectuur voor MijnZaken. In de informatiearchitectuur worden interacties tussen relevante referentiecomponenten beschreven. Daarbij wordt ook een relatie gelegd naar de eerder besproken bedrijfsobjecten, -processen en -diensten om aan te geven welke informatie bij een interactie verwerkt wordt.
De informatiearchitectuur volgt het 5-lagen model van het GEMMA Gegevenslandschap en de informatiekundige visie Common Ground . Elementen uit de bedrijfsarchitectuur worden buiten deze 5 lagen geplaatst.
=== Laag 5 – Interactie ===
De componenten in deze laag verzorgen de interactie met de gebruikers. Voor de interactie met burgers kunnen dit websites, apps of chatbots zijn. Een medewerker van een organisatie maakt doorgaans gebruik van een interne (web)applicatie.
=== Laag 4 – Proceslogica ===
Het verloop van interacties waarbij gegevens opgehaald of verwerkt worden in de achterliggende registers wordt vormgegeven in deze laag. Door de logica los te koppelen van de interactie ontstaat een onafhankelijkheid in het gebruik van een interface of kanaal. Bijvoorbeeld, het opvragen van een status via een website verloopt daardoor op dezelfde manier als via een chatkanaal.
=== Laag 3 – Integratie ===
In deze laag bevinden zich de componenten die de dienstenafnemers (laag 4 en 5) verbinden met de dienstenaanbieders (laag 1 en 2). Denk hierbij aan een API-gateway of een Enterprise service bus (ESB). Omwille van de leesbaarheid van onderstaande diagrammen wordt deze laag niet gevuld met de benodigde componenten. De relaties tussen de proceslogica en de gebruikte diensten (API’s) zouden wegvallen waardoor niet duidelijk is welke processtap welke gegevens verwerkt.
=== Laag 2 – Diensten ===
Gegevens die verwerkt worden, worden ontsloten via API’s. Er kunnen meerdere API’s beschikbaar gesteld zijn voor het bewerken van gegevens. Bijvoorbeeld omdat dit vanwege de veiligheid beter te organiseren is. API’s kunnen ook gecombineerd worden, zodat een soort convenience API ontstaat waarbij gegevens uit meerdere bronnen gecombineerd worden teruggegeven aan de afnemer. Op die manier wordt voorkomen dat teveel gegevens opgehaald en getoond worden aan de gebruiker.
=== Laag 1 – Gegevens ===
De componenten bevatten de (bron)gegevens. Deze gegevens worden ontsloten via de bovenliggende API’s.
== Interactiepatronen opvragen status ==
Deze paragraaf beschrijft hoe MijnZaken-informatie uit (bron)registraties wordt opgehaald en hoe voor verschillende doelgroepen en situaties kan worden voldaan aan voorwaarden (authenticatie, autorisatie, controleren machtigingen en toestemmingen) om die te mogen leveren.
=== Verbinding met de bedrijfsarchitectuur ===
In hoofdstuk 3 is de bedrijfsarchitectuur voor MijnZaken beschreven. In deze paragraaf beschrijven we als onderdeel van de informatiearchitectuur interactiepatronen. Deze hangen op twee manieren samen met de bedrijfsarchitectuur:
# De verschillende applicatieprocessen die de hieronder beschreven interactiepatronen ondersteunen samen het in het vorige hoofdstuk beschreven bedrijfsproces ‘Verstrekken MijnZaken-informatie en de bedrijfsdienst ‘MijnZaken’ (Figuur 8).
# Gegevensobjecten die in de hieronder beschreven interactiepatronen worden geraadpleegd of gewijzigd realiseren volgens de in Figuur 9 geïllustreerde structuur de in Figuur 2 beschreven bedrijfsobjecten.
Het hieronder beschreven interactiepatroon illustreert hoe informatie over de status van een aanvraag van een product of dienst aan een burger of medewerker wordt getoond. Zichtbaar wordt welke gegevensobjecten hiervoor nodig zijn, en via welke gegevenscomponenten en API-interfaces die beschikbaar worden gesteld.
Het patroon is beschreven in zes onderdelen:
# Burger authenticeren en machtigingen toetsen – beschrijft op welke manier de identiteit van een burger wordt gecontroleerd en diens machtigingen getoetst. Van de drie in de bijlagen beschreven casussen is dit deel alleen relevant voor de casus ‘MijnGemeente’.
# Bedrijf of instelling authenticeren en machtigingen toetsen – beschrijft op welke manier de identiteit van een vertegenwoordiger van een bedrijf of instelling wordt vastgesteld en diens machtigingen om namens bedrijf of instelling te handelen worden opgehaald en gecontroleerd. Van de drie in de bijlagen beschreven casussen is dit deel alleen relevant voor de casus ‘MijnGemeente’.
# Medewerker authenticeren en autoriseren en klanttoestemmingen controleren – beschrijft op welke manier de identiteit van een medewerker wordt vastgesteld, diens autorisaties worden opgehaald. Van de drie in de bijlagen beschreven casussen is dit deel alleen relevant voor de casus ‘CRM’.
# Klantgegevens ophalen – beschrijft hoe contactgegevens en klantvoorkeuren (bijvoorbeeld een voorkeurskanaal) worden opgehaald.
# Klanttoestemmingen controleren – beschrijft hoe wordt gecontroleerd of een afnemer toestemming heeft gegeven voor verwerking van (persoons)gegevens in het kader van verstrekking van MijnZaken-informatie (dit voor zover het gaat om gegevens die niet op basis van een andere grondslag mogen worden verwerkt).
# Status lopende aanvragen en zaken tonen – beschrijft op welke manier statusinformatie over de aanvraag van een product of dienst aan een burger, medewerker óf andere organisatie worden getoond. Dit deel van het interactiepatroon dus generiek en geldend voor alle casussen waarbinnen MijnZaken-informatie wordt geleverd.
Niet ieder van de bovengenoemde onderdelen is in iedere situatie nodig. Zo hoeft afhankelijk van de doelgroep (burgers, bedrijven en organisaties of medewerkers) waartoe de afnemer behoort maximaal eenmaal een autorisatie- en authenticatieproces doorlopen te worden. Maar in gevallen waar ‘openbare’ gegevens als MijnZaken-informatie worden geleverd (bijvoorbeeld statusinformatie naar aanleiding van een melding over een defecte lantaarnpaal) kunnen authenticatie en autorisatie wellicht überhaupt achterwege blijven.
Een ander voorbeeld is het controleren van toestemmingen. Als een afnemer zelf het initiatief neemt voor het inzien van MijnZaken-informatie hoeft niet door de aanbieder gecontroleerd te worden of hij of zij toestemming heeft gegeven voor het verwerken van persoonlijke gegevens voor dat doel – het initiatief ís dan immers de toestemming. Als een overheidsorganisatie aan de andere kant een afnemer geautomatiseerd van iedere statuswijziging op de hoogte wil stellen is zo’n controle weer wel nodig.
Een overzicht van generieke componenten en API’s die betrokken (kunnen) zijn bij het ontstaan of tonen van MijnZaken-informatie is te vinden in bijlage 6.1.
Applicatieproces 	Beschrijving
Burger authenticeren en machtigingen toetsen	De identiteit van de burger wordt vastgesteld middels een authenticatiemiddel met een betrouwbaarheid die aansluit bij de gevoeligheid van de als MijnZaken-informatie te leveren gegevens. Daarnaast wordt gecontroleerd welke machtigingen de burger heeft om producten aan te vragen namens iemand anders (bijvoorbeeld omdat die burger optreedt als bewindvoerder voor een andere burger) of welke machtigingen diegene heeft om MijnZaken-informatie namens iemand anders op te vragen.
Applicatieproces 	Beschrijving
(Vertegenwoordiger van) bedrijf of instelling authenticeren en machtigingen toetsen	De gebruiker wordt geauthenticeerd om vast te stellen dat die het recht heeft om het bedrijf of de instelling te vertegenwoordigen. Daarnaast wordt gecontroleerd welke machtigingen de gebruiker heeft om namens het bedrijf of de instelling te handelen.
Applicatieproces 	Beschrijving
Medewerker authenticeren en autoriseren	De identiteit van de medewerker wordt vastgesteld middels een authenticatiemiddel met een betrouwbaarheid die aansluit bij de gevoeligheid van de als MijnZaken-informatie te leveren gegevens. Daarnaast worden de rollen waaraan de medewerker is toegewezen opgehaald. Aan de hand van autorisatieprofielen die gekoppeld zijn aan producten of diensten wordt vastgesteld of de medewerker - via de aan hem of haar toegewezen rollen - de juiste autorisaties bezit om toegang te krijgen tot de gevraagde MijnZaken-informatie.
Applicatieproces 	Beschrijving
Basisgegevens ophalen	Basisgegevens van de afnemer worden op basis van een uniek identificerend gegeven (afhankelijk van de doelgroep BSN, OIN of KvK-nummer) opgehaald. Daartoe wordt eerst de GBA-administratiecomponent (burger, BSN) of het Handelsregister (bedrijf of instelling, OIN of KvK-nummer) bevraagd. Deze stap is optioneel.
Klantgegevens ophalen	Op basis van (een combinatie van) (zeer waarschijnlijk) uniek identificerend(e) gegeven(s) worden aanvullende klantgegevens en klantvoorkeuren (zoals voorkeurskanalen) opgehaald uit het Klantenregister. Het uniek identificerende gegeven kan een BSN, OIN of KvK-nummer uit de vorige stap zijn, maar ook bijvoorbeeld een combinatie van zaaknummer en naam of e-mailadres. Op basis van het laatste mogen slechts beperkt gevoelige gegevens worden verstrekt.
Applicatieproces 	Beschrijving
Klanttoestemmingen controleren	Er wordt gecontroleerd of, en zo ja in welke mate de afnemer toestemming heeft gegeven voor verwerking van (persoons)gegevens voor dit doel (dit voor zover het gaat om gegevens die niet op basis van een andere grondslag mogen worden verwerkt).
Applicatieproces 	Beschrijving
Status aanvragen en zaken tonen	Alle beschikbare informatie over de status van levering van een door een afnemer aangevraagd(e) product of dienst wordt opgehaald en getoond.
Verzoekgegevens tonen 	Op basis van een relatie tussen klanten in het Klantenregister en via het gegevensobject klantverzoeken in het Verzoekenregister worden de door de burger opgevraagde verzoekgegevens (o.a. moment van indienen en aangevraagd product) opgehaald en getoond. Op basis van een relatie met verzoeken via het gegevensobject verzoekproducten in het Verzoekenregister worden uit de Producten-en-dienstencataloguscomponent aanvullende gegevens over het aangevraagde product (zoals een beschrijving en behandeltermijnen) opgehaald en getoond.
Zaakgegevens tonen 	Op basis van een relatie met verzoeken via het gegevensobject zaakverzoeken in het Zakenregister worden de zaak- en statusgegevens van de za(a)k(en) die naar aanleiding van de ingediende verzoek zijn gestart opgehaald en getoond. Op basis van de relatie van statussen naar statustypen in de Zaaktypecataloguscomponent worden op basis van het gegevensobject statustypen aanvullende gegevens over statussen (zoals de omschrijving daarvan) opgehaald en getoond.