Omnichannel MijnZaken Informatiearchitectuur

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:

1. 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).
2. 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.

Figuur 8: relatie tussen bedrijfsproces ‘Verstrekken MijnZaken-informatie’ en bedrijfsdienst ‘MijnZaken’ en applicatieprocessen uit interactiediagrammen (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv

Figuur 9: relatie tussen bedrijfsobjecten en in interactiediagrammen geraadpleegde of gewijzigde gegevensobjecten (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv

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:

1. 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’.
2. 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’.
3. 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’.
4. Klantgegevens ophalen – beschrijft hoe contactgegevens en klantvoorkeuren (bijvoorbeeld een voorkeurskanaal) worden opgehaald.
5. 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).
6. 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.

Figuur 10: Interactiediagram ‘burger authenticeren en machtigingen toetsen’ (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv

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.

Figuur 11: Interactiediagram ‘(Vertegenwoordiger van) bedrijf of instelling authenticeren en machtigingen

toetsen’ (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv

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.

Figuur 12: Interactiediagram ‘Medewerker authenticeren en autoriseren’ (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv

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.

Figuur 13: Interactiediagram ‘Klantgegevens ophalen’ (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv

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.

Figuur 14: Interactiediagram ‘Klanttoestemmingen controleren’ (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv

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).

Figuur 15:Interactiediagram ‘Status lopende aanvragen en zaken tonen’ (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv

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.

Betekenisvolle gegevens.

Interactie in de context van overheidsdienstverlening betreft de (digitale) gegevensuitwisseling en wisselwerking tussen burgers en bedrijven en de overheid(sorganisaties).

De GEMeentelijke ModelArchitectuur met een verzameling samenhangende kaders, richtlijnen, referentiemodellen en standaarden die gemeenten helpt bij het inrichten van hun IT-omgeving en processen.

De inrichting van organisatie, producten en processen binnen een organisatie.

Interactie in de context van overheidsdienstverlening betreft de (digitale) gegevensuitwisseling en wisselwerking tussen burgers en bedrijven en de overheid(sorganisaties).

Een computerprogramma om een specifieke taak uit te voeren die geen betrekking heeft op de werking van de computer zelf.

In de informatica is een interface een gedeelde grens waarover twee of meer afzonderlijke componenten van een computersysteem informatie uitwisselen. De uitwisseling kan plaatsvinden tussen software, computerhardware, randapparatuur, mensen en combinaties hiervan.

Communicatiekanaal dat bij de dienstverlening wordt gebruikt. Elk kanaal kent verschillende vormen waarin informatie kan worden gedeeld.

Een door een applicatie geleverde dienst (te gebruiken via applicatieinterfaces).

Afkorting van 'application programming interface': een manier om twee of meer computerprogramma's met elkaar te laten communiceren. Het is een soort software-interface die een dienst aanbiedt aan andere stukjes software.

Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat. (Synoniem van: Data )

De actor of applicatie die iets afneemt dat door een aanbieder wordt aangeboden.

Iedere persoon, organisatie of functionele eenheid die gebruik maakt van een informatiesysteem.

Systematische en meestal in een informatiesysteem opgeslagen beschrijvingen van instanties van concepten.

Het aantonen dat degene die zich identificeert ook daadwerkelijk degene is die zich als zodanig voorgeeft: ben je het ook echt? Authenticatie noemt men ook wel verificatie van de identiteit.

Het proces van het toekennen van rechten voor de toegang tot geautomatiseerde functies en/of gegevens in ICT voorzieningen.

Reeks opeenvolgend uit te voeren activiteiten die bijdraagt aan een specifiek resultaat, zoals de levering van een Product of Dienst.

Een samenhangende set Diensten, Bedrijfsobjecten en/of Representaties die onder in een Overeenkomst beschreven voorwaarden kan worden afgenomen.

Een afgebakende prestatie van een persoon of organisatie (de dienstverlener), die voorziet in een behoefte van haar omgeving (de dienstafnemer(s)).

De herbruikbare vorm van een oplossing voor een ontwerpprobleem

De eenheid van wezen, volkomen overeenstemming en gelijkheid. Dat wat uniek of eigen is aan iets of iemand. Het kan daarbij gaan om zowel personen als organisaties of landen.

Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat.

Voor alle gevallen geldend, niet specifiek.

De actor of applicatie die iets aanbiedt dat door een afnemer is af te nemen.

Met het begrip 'overheidsorganisaties' wordt zowel gedoeld op overheden als op semi-overheid- en private organisaties met een publieke taak.

De mate waarin de organisatie zich voor de informatievoorziening kan verlaten op een informatiesysteem. De betrouwbaarheid van een informatiesysteem is daarmee de verzamelterm voor de begrippen beschikbaarheid, integriteit en vertrouwelijkheid.

Samenhangende set gegevens die geautomatiseerd kan worden verwerkt.

Een samenhangende hoeveelheid werk met een welgedefinieerde aanleiding en een welgedefinieerd eindresultaat, waarvan kwaliteit en doorlooptijd bewaakt moeten worden.