Omnichannel ProductDienstStatus Informatiearchitectuur
Hoofdstuk:
- Ergens in uw zoekopdracht was "" niet afgesloten door een bijbehorende "".
Deze pagina is een onderdeel van compleet: Hele document bekijken - Exporteren - [[|Definitie]] - [[Media:Ergens in uw zoekopdracht was "" niet afgesloten door een bijbehorende "".|PDF versie]] (, "<span class="smw-highlighter" data-type="4" data-state="inline" data-title="Waarschuwing" title="Ergens in uw zoekopdracht was "" niet afgesloten door een bijbehorende ""."><span class="smwtticon warning"></span><span class="smwttcontent">Ergens in uw zoekopdracht was "" niet afgesloten door een bijbehorende "".</span></span>" is geen geldige titel)
Dit hoofdstuk beschrijft de informatiearchitectuur voor PDS. 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. 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 PDS-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 ProductDienstStatus 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 PDS-informatie en de bedrijfsdienst ‘ProductDienstStatus’ (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.
Figuur 8: relatie tussen bedrijfsproces ‘Verstrekken PDS-informatie’ en bedrijfsdienst ‘ ProductDienstStatus’ 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:
- Burger authentiseren 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 authentiseren 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 authentiseren 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 PDS-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 PDS-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 PDS-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 PDS-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 PDS-informatie is te vinden in bijlage 6.1.
Figuur 10: Interactiediagram ‘burger authentiseren en machtigingen toetsen’ (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv
Applicatieproces | Beschrijving |
---|---|
Burger authentiseren en machtigingen toetsen | De identiteit van de burger wordt vastgesteld middels een authenticatiemiddel met een betrouwbaarheid die aansluit bij de gevoeligheid van de als PDS-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 PDS-informatie namens iemand anders op te vragen. |
Figuur 11: Interactiediagram ‘(Vertegenwoordiger van) bedrijf of instelling authentiseren en machtigingen
toetsen’ (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv
Applicatieproces | Beschrijving |
---|---|
(Vertegenwoordiger van) bedrijf of instelling authentiseren en machtigingen toetsen | De gebruiker wordt geauthentiseerd 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 authentiseren en autoriseren’ (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv
Applicatieproces | Beschrijving |
---|---|
Medewerker authentiseren en autoriseren | De identiteit van de medewerker wordt vastgesteld middels een authenticatiemiddel met een betrouwbaarheid die aansluit bij de gevoeligheid van de als PDS-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 PDS-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. |
Productaanvraaggegevens tonen | Op basis van een relatie tussen klanten in het Klantenregister en via het gegevensobject klantproductaanvragen in het Productaanvragenregister worden de door de burger opgevraagde productaanvraaggegevens (o.a. moment van indienen en aangevraagd product) opgehaald en getoond. Op basis van een relatie met productaanvragen via het gegevensobject productaanvraagproducten in het Productaanvragenregister 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 productaanvragen via het gegevensobject zaakproductaanvragen in het Zakenregister worden de zaak- en statusgegevens van de za(a)k(en) die naar aanleiding van de ingediende productaanvraag 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. |