Globale Architectuur Schets (GAS) · Architectuur (PSA) waar het zwaartepunt verschuift naar de...

Deelprogramma DSO

Deelprogramma Digitaal Stelsel Omgevingswet

Globale Architectuur Schets

Toepasbare Regels Uitvoeren Versie 0.52 Concept 22-12-2016

Concept | Globale Architectuur Schets Toepasbare Regels Uitvoeren | 0.52 pagina 2 van 49

Deelprogramma DSO

Colofon

Titel : Globale Architectuur Schets

Toepasbare Regels Uitvoeren

Versie : 0.52 Concept

Datum : 22-12-2016

Opdrachtgever : Programma Implementatie Omgevingswet

Opdrachtnemer : Deelprogramma DSO

Auteurs : Stephen Oostenbrink

Domeinarchitect PDSO

Jeroen Ekkelenkamp

Projectarchitect

Contactpersonen : Stephen Oostenbrink

Domeinarchitect Kernfuncties

+31 6 4211 4863

[email protected]

Gebaseerd op : Visie 0.92

Doelarchitectuur 1.0

Overall GAS 0.97

Templateversie : 1.57

mailto:[email protected]


Deelprogramma DSO

Versiehistorie

Versie Status Datum Auteur(s) Toelichting

0.1 Concept 30-05-2016 J. Ekkelenkamp Initiële versie

0.2 Concept 17-06-2016 J. Ekkelenkamp Opmerkingen VD en AL verwerkt

0.3 Concept 24-06-2016 J. Ekkelenkamp Opmerkingen SO verwerkt

0.4 Concept 08-07-2017 J. Ekkelenkamp Opmerkingen RB, TWM, BM, LvB verwerkt

0.42 Concept 08-08-2016 J. Ekkelenkamp Tussenversie

0.43 Concept 28-09-2016 J. Ekkelenkamp Review SO verwerkt

0.45 Concept 17-11-2016 J. Ekkelenkamp Review provincies, waterschappen en gemeenten

verwerkt

0.5 Concept 05-12-2016 J. Ekkelenkamp Review verwerkt SO

Goedkeuring

Functie Naam Versie Datum Handtekening

Opdrachtgevend Beraad René Kint namens het

Opdrachtgevend Beraad

Programma Directeur Implementatie

Omgevingswet (namens de Programmaraad)

Ineke van der Hee

Programma Manager PDSO Pieter Meijer

Lead architect programma Victorine Binkhorst

Distributie

Functie/Orgaan Versie Opmerkingen

Opdrachtgevend Beraad Omgevingswet

Programma Raad Implementatie Omgevingswet

Programma Team

Architectuur Team Overleg

Project

Review

Naam Versies

Adam Loorbach (AL), business analist 0.1

Vincent van Dijk (VD), business analist 0.1

Stephen Oostenbrink (SO), lead architect 0.2, 0.42, 0.45

Rien Berkhout (RB), architect 0.3

Lennart van Bergen (LvB), architect 0.3

Bart Maessen (BM), Adviseur Tactisch InformatieManagement 0.3

Tsjok Wing Man, Architect 0.3


Deelprogramma DSO

Inhoudsopgave

1 INLEIDING ............................................................................... 1

1.1 Doelgroep ......................................................................... 1

1.2 Doel ................................................................................ 1

1.3 Resultaat .......................................................................... 2

1.4 Positionering ..................................................................... 2

1.5 Samenhang andere documenten .............................................. 3

1.6 Organisatieonafhankelijk ....................................................... 3

1.7 Architectuurkader en principes ............................................... 4

1.8 Archimate-notatie ............................................................... 4

1.9 Afkortingen en begrippen ...................................................... 4

1.10 Leeswijzer ........................................................................ 4

2 BUSINESS ARCHITECTUUR ............................................................. 6

2.1 Overzicht business architectuur .............................................. 6

2.1.1 Toelichting gebruikte terminologie .................................. 8

2.2 Diensten & Producten .......................................................... 9

2.3 Processen ....................................................................... 11

2.3.1 Toelichting toepasbaar model ...................................... 13

3 INFORMATIEARCHITECTUUR ........................................................ 15

3.1 Medewerkers en applicaties ................................................. 15

3.1.1 Registratie toepasbare regels ....................................... 16

3.1.2 Regeluitvoering ........................................................ 17

3.1.3 Transformatie .......................................................... 18

3.1.4 Geo ....................................................................... 18

3.2 Gegevens ....................................................................... 19

3.3 Applicatie services ............................................................ 19

3.4 Informatie-uitwisseling ....................................................... 21

3.4.1 Toelichting bepalen conclusies ...................................... 24

3.5 Herbruikbare bouwblokken .................................................. 25

3.5.1 Gebruiken ............................................................... 25

4 BEHEER ................................................................................ 27

5 BEVEILIGING & PRIVACY ............................................................ 29


Deelprogramma DSO

5.1 Beveiligingsclassificaties ..................................................... 29

5.2 Beschikbaarheid ............................................................... 29

5.3 Integriteit ....................................................................... 30

5.4 Vertrouwelijk .................................................................. 31

5.5 Onweerlegbaarheid ........................................................... 32

5.6 Controleerbaarheid ........................................................... 32

6 PRINCIPES ............................................................................. 33

6.1 Overzicht ....................................................................... 33

6.2 Business architectuur ......................................................... 34

6.2.1 Organisatie ............................................................. 34

6.2.2 Diensten & Producten ................................................. 35

6.3 Informatiearchitectuur ....................................................... 35

6.3.1 Medewerkers en Applicaties ......................................... 35

6.3.2 Gegevens ................................................................ 36

6.3.3 Informatie-uitwisseling ............................................... 36

6.4 Beheer ........................................................................... 37

6.5 Beveiliging & privacy ......................................................... 37

7 STANDAARDEN ........................................................................ 38

8 ROADMAP .............................................................................. 40

8.1 Overzicht transitie ............................................................ 40

8.2 Huidige situatie ................................................................ 40

8.2.1 OLO ...................................................................... 40

8.2.2 AIM ....................................................................... 40

8.2.3 OLO ...................................................................... 41

8.3 Eindsituatie (2018) ............................................................ 42

9 BIJLAGE A: OPENSTAANDE PUNTEN ............................................... 43

10 BIJLAGE B: BRONNEN ................................................................ 44


Deelprogramma DSO

1 Inleiding

Dit document bevat de Globale Architectuur Schets (GAS) voor de component Uitvoeren binnen het project Toepasbare Regels Uitvoeren.

Het doel van een GAS is het beschrijven van de globale architectuur en

de keuzen die daarin voor het project Toepasbare Regels Uitvoeren gemaakt zijn. De GAS beschrijft het eindbeeld van de oplossing en hoe

dit eindbeeld in een aantal realiseerbare stappen bereikt wordt.

Daarnaast zorgt de GAS dat de oplossing aansluit op architectuur van de interbestuurlijke partners (provincies, gemeenten en

waterschappen). Dit geheel zorgt ervoor dat de veranderopgave in

samenhang met andere veranderingen wordt gerealiseerd en past

binnen de gewenste toekomst vaste informatievoorziening van het Digitaal Stelsel Omgevingswet (DSO).

Een GAS stelt de opdrachtgever in staat gedurende het opstellen ervan besluiten te nemen over onderkende architectuurkeuzen. De GAS beperkt zich tot de bedrijfsarchitectuur en informatiearchitectuur. De

GAS vormt het kader voor de verdere uitwerking in een Project Start

Architectuur (PSA) waar het zwaartepunt verschuift naar de technische

architectuur. De PSA is gehouden aan de oplossingsrichting en de

kaders beschreven in deze GAS en kan hiervan niet afwijken zonder akkoord van de lead architect van het DSO.

De Overall GAS (OGAS) is de overkoepelende kapstok met algemene kaders en richtlijnen voor het stelsel waar elke GAS aan moet voldoen om een digitaal stelsel te realiseren dat op een eenduidige en

samenhangende manier werkt.

Voor het project Toepasbare Regels is ervoor gekozen om twee GAS’sen

op te stellen. Eén voor Toepasbare Regels Maken en één voor Toepasbare Regels Uitvoeren.

1.1 Doelgroep

De GAS richt zich op opdrachtgever en opdrachtnemer (programmaraad). Daarnaast zijn ook bestuurders, PSA schrijvers,

projectmanagers en business analisten belangrijke stakeholders.

1.2 Doel

De GAS helpt in het scherp krijgen van:

De context van de oplossing.


Deelprogramma DSO

De belangrijkste requirements van de opdrachtgever.

Criteria waaraan de oplossing wordt getoetst.

1.3 Resultaat

De GAS is samen met de GAS Oplegger het startpunt voor de

uitwerking van de PSA en geeft de opdrachtgever het vertrouwen dat de vraag goed begrepen is en de oplossing passend zal zijn.

Met het resultaat van de GAS: Tonen de domeinarchitect van het programma en de projectarchitect

van de implementatiepartij aan dat zij de architecten van de

opdrachtgever goed begrepen hebben.

Is een gemeenschappelijk beeld over de kaders en de oplossingsrichting.

Is een gemeenschappelijk beeld met aanpalende projecten en zijn

wederzijdse afhankelijkheden inzichtelijk en koppelvlakken bekend. Zijn discussiepunten en onduidelijkheden naar boven gebracht en

gezamenlijk opgelost.

Is een aanzet gegeven tot de belangrijkste onderdelen van de oplossingsrichting.

Beschikt de opdrachtgever over een begrijpelijk resultaat om te

accorderen en op te sturen.

1.4 Positionering

Hieronder wordt de basis architectuurplaat van het DSO weergegeven.

Hierop is de positionering van deze GAS aangegeven.


Deelprogramma DSO

1.5 Samenhang andere documenten

In de laatste versie van het document “DSO - Architectuur - Toelichting

samenhang documenten” wordt toegelicht hoe deze GAS samenhangt

met andere documenten. Dit document hangt samen met de de andere

GAS voor Toepasbare Regels, “DSO – GAS – Toepasbare Regels Maken”.

1.6 Organisatieonafhankelijk

De GAS is neutraal, dat wil zeggen niet ‘gekleurd’ door de strategie van een specifieke organisatie. De GAS is beperkt tot de Bedrijfsarchitectuur

en Informatiearchitectuur lagen, aangevuld met de Beheer en

Beveiliging & Privacy aspecten van deze lagen. Er is bewust gekozen om geen uitspraken te doen over de Technische Architectuur. De GAS

schrijft geen techniek voor en is dus onafhankelijk van de techniek. De

organisatie verantwoordelijk voor de implementatie van een GAS

behoudt zo de vrijheid haar eigen technologiekeuzen te maken, maar met de OGAS en GAS zijn die keuzen nadrukkelijk verbonden aan de

Figuur 1. Positionering GAS op basis architectuurplaat DSO


Deelprogramma DSO

principes en de meegegeven oplossingsrichting. Uitzondering hierop zijn

herbruikbare GDI- en DSO-bouwblokken. De GAS zal hier nadrukkelijk

op sturen.

1.7 Architectuurkader en principes

In de laatste versie van het document “DSO - Architectuur - Toelichting architectuurkader en principes” wordt het gehanteerde architectuurkader toegelicht en de manier waarop principes beschreven worden.

1.8 Archimate-notatie

In de laatste versie van het document “DSO - Architectuur - Toelichting ArchiMate-notatie” staat een korte toelichting hoe ArchiMate wordt toegepast en wordt de ArchiMate-notatie kort toegelicht.

1.9 Afkortingen en begrippen

In de laatste versie van het document “DSO - Architectuur - Afkortingen Begrippen” staan de definities van begrippen en afkortingen.

1.10 Leeswijzer

In hoofdstuk 2 wordt de business architectuur beschreven.

In hoofdstuk 3 wordt de informatiearchitectuur beschreven.

In hoofdstuk 4 worden de beheeraspecten beschreven.

In hoofdstuk 5 worden de beveiliging & privacy aspecten beschreven.

In hoofdstuk 6 wordt aangegeven welke principes uit de Overall GAS

(OGAS) van toepassing zijn en hoe deze toegepast worden voor deze GAS.

In hoofdstuk 7 worden de standaarden benoemd die van toepassing zijn

voor deze GAS.

In hoofdstuk 8 wordt de roadmap beschreven hoe het eindbeeld in

controleerbare en haalbare stappen wordt gerealiseerd: van de huidige situatie naar de eindsituatie met eventuele tussenstappen.


Deelprogramma DSO

Bijlage A beschrijft tot slot de openstaande punten, Bijlage B bevat de

lijst met bronnen die voor het opstellen van deze GAS gebruikt.


Deelprogramma DSO

2 Business architectuur

In dit hoofdstuk wordt de bedrijfsarchitectuur beschreven voor zover die van belang is voor de positie en rol van Toepasbare Regels Uitvoeren.

Het is een beschrijving in brede zin, dat wil zeggen de wat en hiermee

onafhankelijk van de te kiezen oplossing.

De bedrijfsarchitectuur omvat de volgende aspecten: Welke wet- en regelgeving zijn van toepassing. Wie zijn betrokken (organisatie). Wat zijn de diensten en producten. Hoe verlopen de processen.

2.1 Overzicht business architectuur

Regels zijn een subset van de tekst in besluiten. Hierin staat wat wel en

niet mag of moet, door wie, wanneer, waar en hoe.

Toepasbare regels zijn juridische teksten (wet- en regelgeving,

verordening en vergunningen) omgezet naar begrijpelijke regels

(vragenbomen). Begrijpelijk betekent dat deze taalkundig voldoen aan

het afgesproken B1 taalniveau1.

Het ketenproces regelbeheer zoals gedefinieerd in de doelarchitectuur is

het maken van nieuwe of gewijzigde besluiten en het geschikt maken

van de tekst om ze doelgericht, begrijpelijk en op maat aan te bieden.

Binnen regelbeheer worden twee processen onderscheiden:

1 80% van de bevolking begrijpt taalniveau B1. Als teksten op dit niveau worden geschreven, dan

kan het grootste deel van de bevolking ze lezen en begrijpen. En tegelijkertijd blijft de essentie van de

boodschap behouden.


Deelprogramma DSO

Regels ontwikkelen (valt binnen domein overstijgend proces

(DOP) “Opstellen of wijzingen plannen en verordeningen”): het

voorbereiden en nemen van nieuwe en wijzigingsbesluiten.

Regels toepassen: een subset van de juridische teksten in

besluiten doelgericht, begrijpelijk en op maat aanbieden (de bulk van de aanvragen en meldingen).

Binnen regels toepassen kunnen weer twee deelprocessen worden onderscheiden:

Maken toepasbare regels: het analyseren en specificeren van

toepasbare regels en publiceren naar “Uitvoeren toepasbare

regels”. Uitvoeren toepasbare regels: het aanbieden van de toepasbare

regels op maat als services. Deze services worden onder andere

gebruikt voor het aansturen van de werking van de gebruikerstoepassingen checken en indienen.

Ten behoeve van het uitvoeren worden de toepasbare regels automatisch vertaald in uitvoerbare regels, dit zijn de regels in de taal

van de applicatie die de regels uitvoert.

Hoe het proces gepositioneerd is in de context van de domein overstijgende processen is in de onderstaande figuur weergegeven.

Dit GAS beperkt zich tot het deelproces “Uitvoeren toepasbare regels”

Figuur 2. Overzicht domein overstijgende processen


Deelprogramma DSO

Hieronder wordt een overzicht gegeven van de business architectuur die

wordt onderkend. Hier is “Uitvoeren Toepasbare Regels” opgesplitst in

twee deelprocessen.

De verschillende onderdelen met betrekking tot de business architectuur worden in de volgende paragrafen toegelicht. De

applicatieservices worden in het volgende hoofdstuk toegelicht.

2.1.1 Toelichting gebruikte terminologie

Wet- en regelgeving teksten kennen een structuur met als belangrijkste

elementen: activiteiten, norm, werkingsgebied, begrippen, grondslag en

waarde.

De norm is de juridische tekst, waarbij het werkingsgebied het

ruimtelijke gebied is waar de norm van toepassing is. Soms wordt voor een norm in verschillende gebieden verschillende waarden gehanteerd.

Daarom is de waarde apart opgenomen. Een voorbeeld kan zijn dat ‘de

maximale hoogte van een dakkapel aan de voorkant van het huis in het centrum van Haarlem is 1.75 meter’. Centrum van Haarlem zal een

werkingsgebied zijn in de vorm van een coördinatenset (geometrieën).

De norm gaat over de activiteit ‘bijhorend bouwwerk bouwen’. Hierbij is

de ‘het centrum van Haarlem' het werkingsgebied en de waarde is ‘1.75

meter’. Maar buiten het centrum (ander werkingsgebied) kan de

maximale hoogte een andere waarde bevatten, bijvoorbeeld 2 meter.

De feiten die de basis vormen van de norm zijn de grondslagen. Dit kan

een waarde zijn ‘1.75 meter’ en het begrip ‘voorkant van het huis’.

Figuur 3. Overzicht business architectuur


Deelprogramma DSO

Afspraken op tekstniveau (waarde ID, semantiek en mogelijke waarden)

zorgen dat waarden uit de tekst (regels) in vragenbomen gebruikt

kunnen worden. Bij het maken van de vragenboom kan naar waarden in

de juridische tekst verwezen worden.

In normen staan begrippen. Een begrip is een gegevensbeschrijving uit

de wet- en regelgeving en wordt gepubliceerd in de Catalogus.

‘Dakkapel’ is een begrip.

Gebruikers denken echter vanuit werkzaamheden (“dakkapel plaatsen”)

en niet vanuit juridische activiteiten. Een activiteit bestaat uit een

werkwoord en een zelfstandig naamwoord, bijvoorbeeld 'bijbehorend bouwwerk bouwen'. Hiervoor geldt: er gebeurt iets in de werkelijkheid,

bijvoorbeeld een nieuwe behoefte om de woonoppervlakte te vergroten

door middel van het plaatsen van een dakkapel, daarvoor gelden regels en moet dus 'iets' (onder andere een vergunning) worden geregeld, waarvan het resultaat wordt vastgelegd en kenbaar wordt gemaakt.

Een werkzaamheid bestaat uit één of meerdere activiteiten. Deze

moeten aan elkaar gerelateerd worden zodat bij het uitvoeren deze gekoppeld kunnen worden. Een gebruiker kiest een werkzaamheid (bv

schuur bouwen), op de achtergrond wordt de juridische activiteit bepaald (bijbehorend bouwwerk bouwen) ten behoeve van het bepalen

van bijvoorbeeld vergunningsplicht.

2.2 Diensten & Producten

Een product is de verzameling van business en/ of applicatieservices, al

dan niet vergezeld van een contract of verzameling overeenkomsten,

die in zijn geheel wordt aangeboden aan (interne of externe) klanten.

Onder dienst in deze context verstaan we de “business service” ofwel

“bedrijfsservice” binnen de ArchiMate-notatie. Een bedrijfsservice is een dienst die voorziet in de behoefte van een klant binnen of buiten de

organisatie. Het stelt functionaliteit van een businessproces beschikbaar

aan externe actoren zoals burgers, bedrijven en overheden of interne actoren zoals andere DSO-onderdelen.

Hierna volgt de beschrijving van de services die door Toepasbare Regels

Uitvoeren ondersteund moeten worden. Het servicemodel (figuur 4) beschrijft welke diensten Toepasbare Regels Uitvoeren levert aan haar

doelgroepen. Hiermee wordt één begrippenkader gecreëerd voor de

diensten en producten die dient als vertrekpunt voor de procesinrichting


Deelprogramma DSO

en de informatievoorziening. Hiermee wordt duidelijk welke (externe en

interne) diensten geleverd moeten worden.

Hierboven in figuur 4 zijn de producten en diensten weergegeven. Hierna volgt een beschrijving van de services in het servicemodel.

# Business service Toelichting

1 Valideren en registreren

toepasbare regels

Deze business service levert grotendeels geautomatiseerd

uitvoerbare regels. Er wordt wel een handmatige controlestap

vereist door het BG. Het systeem kan de technische controles

doen, BG zal moeten controleren of de werking juist is

(bijvoorbeeld technisch correct maar niet de beoogde

werking). De ontvangen berichten met toepasbare regels

worden qua structuur en inhoudelijk gevalideerd en, indien

valide, opgeslagen en getransformeerd tot uitvoerbare regels.

2 Ontsluiten gevalideerde

toepasbare regels

Het ontsluiten van de gevalideerde toepasbare regels ten

behoeve van het DSO aan BG en derden.

3 Leveren conclusie Deze business service levert de hieronder beschreven

conclusies.

Hierboven is in een figuur aangegeven waaruit de producten bestaan.

# Product Toelichting

1 Gevalideerde toepasbare regels Het eerste product bestaat uit toepasbare regels die zijn

gevalideerd in samenhang met overige regels. Gepubliceerd

aan BG en derden.

2 Conclusies Een tweede product dat door Uitvoeren toepasbare regels

geleverd wordt, zijn de conclusies die door het proces

uitvoeren geleverd wordt. Conclusies kunnen verschillende

vormen hebben. Een conclusie kan een indicatie zijn dat de

aanvrager vergunningsplichtig is voor een bepaalde activiteit.

Een conclusie kan ook bestaan uit een lijst met

indieningsvereisten of maatregelen waaraan voldaan moet

worden. Het betreft de conclusie waar de vragenbomen naar

toewerken. Er wordt gesproken van een conclusie en niet een

beslissing omdat aan de conclusie geen rechten ontleend

Figuur 4. Weergave van de producten en diensten


Deelprogramma DSO

kunnen worden door de gebruiker. De beslissing ligt bij het

bevoegd gezag.

De check is niet verplicht. De wetsjuristen willen niet dat er

rechten aan ontleend mogen worden omdat een check niet 1-

op-1 overeenkomt met de juridische regels. Het doel is om in

zo min mogelijk stappen te bepalen of de gebruiker

vergunningplichtig, meldingplichtig, verboden of vergunning

vrij is. Als een gebruiker 100% garantie wil hebben dan zal

deze toch moeten indienen. Deze aanpak heeft zich bij OLO2

in de praktijk bewezen en heeft nooit tot een rechtszaak

geleid.

2.3 Processen

Het processenmodel visualiseert en beschrijft de processen die

Toepasbare Regels Uitvoeren levert aan haar doelgroepen. Hierin staan alle processen die van belang zijn voor Toepasbare Regels Uitvoeren. In

eerste instantie de primaire processen. Daarnaast de (be)sturende en

ondersteunende processen. Hiermee wordt in één oogopslag duidelijk wat de omvang van Toepasbare Regels Uitvoeren is: welke processen

zijn er nodig om de producten en diensten te leveren en op welke manier komen die tot stand.

In het overzicht in paragraaf 2 Overzicht business architectuur zijn de

processen weergegeven. De genoemde processen hebben de granulariteit van een bedrijfsproces. In de laatste versie van het

document “DSO - Architectuur - Toelichting procesgranulariteiten” worden de procesgranulariteiten toegelicht.

Hierna volgt een beschrijving van de processen.

# Proces Toelichting

1 Valideren en verifiëren

toepasbare regels

In dit proces worden de ontvangen berichten syntactisch en

semantisch gevalideerd. De syntax validatie kan volledig

geautomatiseerd. De semantische validatie is deels

geautomatiseerd. Een deel zal handmatig gebeuren door het

bevoegd gezag zelf. Automatische controle van de semantiek

zal bijvoorbeeld de aspecten consistentie en volledigheid

omvatten. Eventuele handmatige controles worden uitgevoerd

door het verwerken van testcases (met bekende,

onderscheidende uitkomsten).

BG is zelf verantwoordelijk voor het testen van de eigen

regels in samenhang met de reeds bestaande regels. Er is een

gemeenschappelijk belang om te borgen dat alle regels aan

een samen nader te specificeren kwaliteitsniveau voldoen en

op een eenduidige manier opgezet zijn. Dit kan het beste

uitgevoerd worden door een onafhankelijke organisatie zoals

een centrale beheerorganisatie.

Wat precies automatisch kan en wat handmatig wordt in het

project nader uitgewerkt.

2 Publiceren toepasbare regels Het ontsluiten van de toepasbare regels aan de bevoegd

gezagen en derden.


Deelprogramma DSO

3 Transformatie De toepasbare regels worden getransformeerd naar de taal

van de rule engine. Dit zal volledig geautomatiseerd

gebeuren.

4 Executeren uitvoerbare regels Getransformeerde toepasbare regels worden als service

ontsloten. De services zullen de vorm hebben van het leveren

van een conclusie ten aanzien van een bepaalde vraag.

Voorbeelden hiervan zijn:

Ben ik vergunningsplichtig?

Welke indieningsvereisten zijn van toepassing

Welke voorschriften en maatregelen zijn van

toepassing?

Aan de hand van de samengevoegde regels van de

verschillende bevoegd gezagen worden de conclusies van de

vragen van de burgers en bedrijven afgehandeld.

Proces buiten scope:

# Proces Toelichting

1 Maken toepasbare regels

(aanliggend proces)

Verantwoordelijk voor het vertalen van wet- en regelgeving in

bedrijfsregels en uitvoeringsregels (samen toepasbare

regels).

2 Uitvoeren check (aanliggend

proces)

Aanliggend proces dat gebruik maakt van de uitvoerbaar

gemaakte regels. Bijvoorbeeld door het opvragen van de

verplichtingen die een initiatiefnemer heeft ten aanzien van

het uitvoeren van een bepaalde werkzaamheid op een

bepaalde locatie.

3 Opstellen of aanvullen

aanvragen en meldingen

(aanliggend proces)

Dit aanliggende proces maakt gebruik van de uitvoerbaar

gemaakte regels. Aan de hand van de vraag uit dit proces

worden de regels uitgevoerd.

De actoren welke betrokken zijn bij de hierboven beschreven processen

worden hieronder beschreven.

# Actoren Toelichting

1 Bevoegd gezag Leveren toepasbare regels aan en testen de regels in

samenhang met overige regels.

2 Centrale beheerder Onderhoud namens de bevoegd gezagen lijsten van aan

toepasbare regels gerelateerde concepten zoals activiteiten en

werkzaamheden inclusief de relaties ertussen.

3 Derden Burgers en bedrijven anders dan bevoegd gezag.

De business objecten welke in de processen gebruikt worden door de

actoren worden hieronder toegelicht.

# Object Toelichting

1 Toepasbaar model De toepasbare regels worden opgesteld volgens het

toepasbaar model. Dit model kent 4 typen regels.

1. Bedrijfsregels: Dit zijn de indicaties (conclusies) die

gebaseerd zijn op wet en regelgeving;

2. Conversieregels: Dit zijn vertalingen van uitvoerings-

regels naar de bedrijfsregels (logica);


Deelprogramma DSO

3. Uitvoeringsregels: In een uitvoeringsregel wordt

vastgelegd op welke wijze de gegevens ten behoeve van

de logica worden verzameld. Dat kan bijvoorbeeld een

vraag aan de gebruiker zijn of het ophalen van gegevens

uit een register.

4. Gedragsregels: Deze laag zal gedrag bepalen van de

userinterface. Hierbij worden de volgorde, groepering

etc. van de vragen gespecificeerd.

Op elke laag is het mogelijk om content te definiëren.

2 Uitvoerbaar model Het uitvoerbaar model bestaat uit uitvoerbaar gemaakte

regels op basis van de toepasbare regels. De toepasbare

regels worden (geautomatiseerd) vertaald naar de taal die de

rule engine begrijpt.

2.3.1 Toelichting toepasbaar model

Het toepasbaar model bestaat uit vier typen regels. Hieronder is een

overzicht van deze typen.

1. Bedrijfsregels: De bedrijfsregels laag bevat de conclusies die worden

gemaakt op basis van de wet- en regelgeving. Deze bedrijfsregels

zijn opeenvolgende vragen in een vragenboom die leiden tot een

indicatie of conclusie. Dit kunnen regels zijn omtrent een

Wet- enregel-geving

Indicatieof

conclusie

GrondslagWaarde/Grondslag

AlsX>YdanJa

Als..Dan..

Watisdehoogtevan…

1.

2.

groep

1.Bedrijfsregels

2.Conversieregels

3.Uitvoerings-regels

4.Gedragsregels

Content

Content

Content

Content

Figuur 5. Weergave van de lagen van toepasbare regels


Deelprogramma DSO

toestemming (“mag ik hier een steiger bouwen?”), een set aan

voorschriften waaraan je moet voldoen of een set aan maatregelen

die je moet nemen als je een bepaalde activiteit uit gaat voeren.

2. Conversieregels: De conversieregels geven een vertaling van de uitvoeringsregels die verschillende verschijningsvormen kunnen

hebben (zoals bijvoorbeeld waardenlijsten, getallen en ja/nee

vragen) naar de bedrijfsregels (die booleaanse logica gebruiken).

3. Uitvoeringsregels: De uitvoeringsregels bepalen hoe de grondslagen

worden uitgevraagd. Dit kan op verschillende manier gebeuren zoals

een vraag aan een gebruiker of een bevragen van een registratie. Bij de uitvoeringsregels wordt ook de volgorde van de uitvoeringsregels

vastgelegd.

Een voorbeeld van het gebruik van uitvoeringsregel is de vraag of gebouw een monument is. Als de locatie bekend is kunnen de

gegevens worden opgehaald uit de registratie monumenten. Indien de registratie niet beschikbaar is wordt er een vraag gesteld aan de

gebruiker.

4. Gedragsregels: Om aan de gebruiker een logische set met vragen aan te bieden zal er ook sturing moeten zijn op de volgorde en

groepering van de vragen aan de gebruiker. Dit gebeurt in de gedragsregels laag. Daarnaast bevatten de gedragsregels de vereiste

formaten (bijvoorbeeld datumformaat) en eenvoudige controles. Het gaat hierbij om de volgorde waarin de regelsets worden uitgevraagd

(functionele orkestratie). Met de gedragsregels wordt de

userinterface aangestuurd.

Op al de bovenliggende lagen kan content gekoppeld worden. Het kan

bijvoorbeeld gaan over de vraag en helpteksten bij de uitvoeringsregels, of een toelichtende tekst bij een conclusie (bedrijfsregel).


Deelprogramma DSO

3 Informatiearchitectuur

In dit hoofdstuk wordt de informatiearchitectuur beschreven van Toepasbare Regels Uitvoeren, deze is bepalend voor de te kiezen

oplossingen.

De informatiearchitectuur omvat de volgende aspecten: Wie voeren uit (medewerkers en applicaties). Wat zijn de gegevens en berichten. Hoe verloopt de informatie-uitwisseling.

3.1 Medewerkers en applicaties

In deze paragraaf wordt de werking van de componenten en de functies

nader toegelicht. Er wordt tevens inzicht gegeven in de gebruikte dataobjecten.


Deelprogramma DSO

3.1.1 Registratie toepasbare regels

De component registratie toepasbare regels levert een koppelvlak voor

alle bevoegd gezagen om toepasbare regels aan te leveren. De aangeleverde toepasbare regels worden uitvoerbaar gemaakt. De

specifieke functies worden hieronder toegelicht.

# Functie Toelichting

1 Valideren/verifiëren ontvangen

regels

De ontvangen toepasbare regels worden gecontroleerd op

structuur en inhoud.

De structuurcontroles zijn de technische controles waarmee

bepaald wordt of het bericht voldoet aan het afgesproken

informatiemodel toepasbare regels. Er wordt bijvoorbeeld

gekeken naar datatypes en of verplichte attributen zijn

aangeleverd.

De inhoudelijke controles zullen uit verschillende typen

bestaan zoals valideren of de aangegeven data correct is

(bijvoorbeeld niet in het verleden als dat niet is toegestaan).

Wat ook gevalideerd wordt is of de aangeleverde regels een

toegestaan patroon volgen wat betreft het “aanhaken” aan de

landelijke regels. Indien in de uitvoeringsregels verwijzingen

opgevoerd zijn naar attributen van een registratie wordt

gevalideerd of de verwijzing naar de service in het algemeen

en de attribuut in het bijzonder correct is.

Indien niet valide wordt de verzender geattendeerd dat er

fouten zaten in het bericht. Om pingpongen te voorkomen

wordt de validatie zo volledig mogelijk uitgevoerd. Er wordt

niet na de eerst gevonden fout gestopt. De verzender

Figuur 6. Componenten, functies en data objecten


Deelprogramma DSO

ontvangt een begrijpelijke melding per fout zodat helder is

hoe het bericht verbeterd moet worden.

2 Publiceren regels Indien het bericht door de validatie heen is gekomen ontsluit

deze functie de toepasbare regels aan derden.

De toepasbare regels worden tevens aan het regeluitvoering

component geleverd.

3 Beheren concepten Functionaliteit ten behoeve van het onderhouden van aan

toepasbare regels gerelateerde lijsten van concepten zoals

activiteiten en werkzaamheden inclusief de relaties ertussen.

De werkzaamheden en activiteiten zijn volgens besluit van

het SAT onderdeel van de gegevensvoorziening Toepasbare

regels. De activiteiten leveren de kapstok waar de regel-

beheerobjecten (vragenbomen) aan hangen.

3.1.2 Regeluitvoering

Dit component omvat de rule engine verantwoordelijk voor het

uitvoeren van de uitvoerbaar gemaakte regels.


1 Regels uitvoeren Op basis van aangeleverde informatie probeert de functie tot een

conclusie te komen. Een conclusie kan bijvoorbeeld zijn het afleiden van

de toestemmingen ten aanzien van een vergunning check van een

bepaalde werkzaamheid. Als de functie nog niet tot een conclusie kan

komen zal deze om de nog missende informatie vragen. Dit kan leiden

tot een “dialoog” met de gebruiker. Dit wordt als dynamisch formulier

gevisualiseerd door gebruikerstoepassingen in het loket.

In deze functie vindt ook de functionele orkestratie plaats. Functionele

orkestratie zijn de ‘regels over de regels’. Om tot een conclusie te komen

kan het nodig zijn om meerdere deelconclusies te trekken. Ook kan het

zijn dat een regel van de provincie voorrang heeft boven een regel van

een gemeente. Daarnaast wordt de wereld van de gebruiker

(werkzaamheden, bijvoorbeeld “een schuur bouwen”) gekoppeld aan de

juridische wereld (activiteiten, “bijbehorend bouwwerk bouwen”).

2 Technische

orkestratie

De toepasbare regels geven aan welke uitvoeringsscenario’s relevant zijn

voor het bepalen van grondslagen. Deze functie zorgt ervoor dat het

juiste uitvoeringsscenario wordt uitgevoerd zoals het ophalen van een

gegeven uit een registratie of het uitvragen bij de gebruiker.

De verschillende services aan het loket kunnen een dialoog vereisen

voordat er tot een conclusie gekomen kan worden. Deze functie

orkestreert tevens de dialoog.

Indien van toepassing worden antwoorden hergebruikt, bijvoorbeeld als

twee dakkappelen tegelijkertijd worden aangevraagd, dan hoeft een

initiatiefnemer dezelfde vraag maar 1 keer te beantwoorden. Dit geldt

ook voor vragen die hergebruikt worden over verschillende checks heen.

Bijvoorbeeld plichtencheck, bijlagencheck en indienen.

Indien van toepassing kan er door een bevoegd gezag verwezen worden

naar de de uitvoeringsregels van andere bevoegd gezagen. Hiermee

kunnen de vragen/antwoorden onderling hergebruikt worden. De

benodigde informatie staat in de registratie toepasbare regels. Als

dezelfde vraag gesteld wordt en de vragenbomen zijn gekoppeld, kan het

antwoord hergebruikt worden.

Noot: Het verschil tussen functionele orkestratie en technische

orkestratie is dat de functionele orkestratie in de regeluitvoering zorgt

voor de orkestratie tussen regelsets en de technische orkestratie


Deelprogramma DSO

orkestreert de relatie met de buitenwereld zoals de gebruiker en

bijvoorbeeld gegevens ophalen uit een basisregistraties.

3.1.3 Transformatie

Het transformatie component is het onderdeel welke functionaliteit biedt

ten aanzien van het transformeren van de aangeleverde toepasbare regels.


1 Transformeren regels De transformeren regels functie vertaalt toepasbare regels in

de meer specifieke taal van de rule engine. Dit zal volledig

geautomatiseerd gebeuren.

Onderdeel hiervan is het extraheren van de content

(toelichtende teksten, plaatjes etc.) en het invoeren hiervan

in het CMS. De verwijzing naar de content wordt onderdeel

van de uitvoerbare regel.

3.1.4 Geo

Het Geo component is het onderdeel welke functionaliteit biedt ten aanzien van ruimtelijke analyses.


1 Geo analyse Alle regels kennen een werkingsgebied. Een vergunningcheck

of vergunningaanvraag is altijd locatiegebonden. De geo

analyse functie geeft antwoord op de vraag welke regels van

toepassing zijn door te bepalen of de locatie van de uit te

voeren activiteit binnen een werkingsgebied van een regel

valt.

Tevens ondersteunt de functie de validatie van de toepasbare

regels door aangeleverde werkingsgebieden te valideren.


Deelprogramma DSO

3.2 Gegevens

In deze paragraaf worden de dataobjecten beschreven.

# Dataobject Toelichting

1 Toepasbare regels Het toepasbare regels object bestaat uit de bedrijfsregels en

de uitvoeringsregels. De toepasbare regels zullen worden

aangeleverd aan de component Toepasbare regels uitvoeren

conform het nog nader te bepalen toepasbare regels

informatie- en uitwisselingsmodel (standaard). Dit model zal

worden gebaseerd op de Decision Modeling Notation (DMN.)

Dit bestaat uit de beschrijving van de vragenbomen op basis

van beslistabellen en de bijbehorende content. Onder content

vallen bijvoorbeeld de vraagteksten, toelichtingen bij vragen

en figuren ter illustratie. De specificatie is verder aangevuld

met specificaties om de uitvoeringsregels te kunnen vatten.

DMN voorziet niet volledig in de behoefte om content aan te

geven zoals toelichtingen op (tussen)resultaten. De

uitvoeringsregels kunnen ook niet in DMN worden uitgedrukt.

Daarom hebben we het over DMN+. Lokaal bevoegd gezag

moet ook kunnen uitdrukken hoe ze inhaken op de landelijke

regels. Er is geen standaard beschikbaar die alle benodigde

rijkheid heeft om de toepasbare regels uit te drukken en

daarom is gekozen om een eigen standaard te ontwikkelen

gebaseerd op DMN en andere standaarden.

Het moet mogelijk zijn voor BG om zelf bronnen te definiëren

waarmee vragen voor ingevuld kunnen worden. Hoe dat

mechanisme eruit moet zien is nog een open vraag.

2 Uitvoerbare regels De toepasbare regels getransformeerd in de taal van de rule

engine. De vertaling wordt 1-op-1 doorgevoerd. Er is alleen

sprake van transformatie.

3 Feiten Om tot een conclusie te kunnen komen moeten gegevens

verzameld worden. Een feit kan uitgevraagd worden aan een

gebruiker of aan een registratie. Registraties (bijv. BR)

kunnen een bron zijn, maar ook elk ander bron dat bij het

beoordelen van een aanvraag wordt gebruikt zoals een

informatieproduct.

Bij het uitvragen aan een register zijn verschillende varianten

mogelijk zijn: register verplicht (waarde kan niet gewijzigd

worden, register niet beschikbaar dan stopt het proces),

register is leidend (waarde kan niet gewijzigd worden, als

register niet beschikbaar is mag de waarde door gebruiker

ingevuld worden), register is indicatief (waarde kan door de

gebruiker gewijzigd worden, als register niet beschikbaar is

mag de waarde door gebruiker ingevuld worden). De feiten

zijn die gegevens die nodig zijn voor de rule engine om tot

een conclusie te komen. De feiten worden gekoppeld aan de

grondslagen via de uitvoeringsregels.

3.3 Applicatie services

In deze paragraaf worden de belangrijkste applicatieservices toegelicht

die relevant zijn voor het ondersteunen van de bedrijfsprocessen zoals

aangegeven in figuur 2.


Deelprogramma DSO

# Service Toelichting

1 Controle service Wordt gebruikt door het validatie en verificatie proces. Ontsluit

functionaliteit voor het controleren van de door de bevoegd gezagen

aangeleverde toepasbare regels. Het ondersteunen van de handmatige

controle is onderdeel van de controle functionaliteit. Hier hoort ook een

functie bij voor het vrijgeven voor productie.

2 Publicatie service Wordt gebruikt door het publicatieproces. De service ontsluit functionaliteit

waarmee de toepasbare regels worden ontsloten.

3 Transformatie

service

Wordt gebruikt in het transformatieproces. Ontsluit functionaliteit voor het

transformeren van toepasbare regels naar uitvoerbare regels.

4 Regel uitvoer

service

Wordt gebruikt door het regels uitvoeren proces. De service ontsluit de

functionaliteit waarmee de conclusies worden afgeleid.

5 Opvragen/

bewerken

concepten service

De service ontsluit functionaliteit voor het onderhouden van lijsten van aan

toepasbare regels gerelateerde concepten zoals activiteiten en

werkzaamheden inclusief de relaties ertussen.


Deelprogramma DSO

3.4 Informatie-uitwisseling

In deze paragraaf wordt beschreven met welke componenten uit de

omgeving er interactie plaatsvindt en wat de relevante services hierbij

zijn. Technisch zullen alle services via het Knooppunt lopen.

In de tabel hieronder wordt een overzicht gegeven van de componenten waarmee interactie plaatsvindt.

# Componenten Toelichting

1 Omgevingsloket Het Digitaal Loket Omgevingswet (DLO), is een

webgebaseerde gebruikersinterface die zorgt voor interactie

met de gebruiker. Er wordt onderscheid gemaakt tussen een

loket voor publiek (Extern DLO) en een loket voor bevoegd

gezagen en haar adviseurs (Intern DLO).

2 Apps derden Het digitaal stelsel is servicegericht en open. Externe partijen

kunnen slimme toepassingen ontwikkelen die gebruik maken

van dezelfde services als het DLO.

3 Landelijke voorziening

Bekendmaken en Beschikbaar

stellen (LVBB)

Levert functionaliteit rond het bekendmaken en consolideren

van besluiten. Levert tevens de functie Register

Omgevingsdocumenten (ROD). De ROD-functie ontsluit alle

omgevingsdocumenten (en andere juridische instrumenten)

ten behoeve van het DSO.

4 Regelbeheersystemen LBGen Lokaal Bevoegd Gezag (LBG) hebben de keuze om eigen

processen en systemen te gebruiken voor de voortbrenging

Figuur 7. Overzicht componenten en hun interactie


Deelprogramma DSO

van hun regels. Deze systemen kunnen toepasbare regels uit

de Registratie toepasbare regels halen voor het gebruik

binnen hun processen.

5 Toepasbare regels maken De component Toepasbare regels maken levert de landelijke

toepasbare regels.

6 CMS Alle content die door vragenbomen wordt gebruikt, wordt

beheerd in het Content Management Systeem (CMS).

Voorbeelden zijn toelichtingen op vragen, plaatjes ter

ondersteuning, filmpjes etc.

Het CMS bevat daarnaast toelichtende (help)teksten, uitleg

etc. voor gebruik in de gebruikerstoepassing. Hiermee is het

beheer centraal geregeld en losgetrokken van de applicatie.

Dit is een nieuwe component die door het DSO-programma

wordt gerealiseerd.

7 Externe bronnen Conceptuele verzameling van bronnen zoals

(basis)registraties en informatieproducten. Het is nog niet

bekend welke bronnen geraadpleegd moeten worden. De te

raadplegen bronnen moeten eenvoudig uit te breiden zijn

voor een BG. Er moet een mechanisme komen om dit te

ondersteunen. Of dit onderdeel wordt van het toepasbare

regels informatiemodel (DMN+) of een apart koppelvlak

wordt, is nog een open vraag.

8 Stelselcatalogus DSO In de Catalogus worden voor de fysieke leefomgeving

relevante begrippen beschreven en gekoppeld aan de

desbetreffende wetgeving, standaarden en de

gegevensverzamelingen. De Catalogus geeft eenduidig aan

welke gegevens waar te vinden zijn en de relatie hiertussen.

Hieronder wordt aangegeven van welke services de componenten

gebruik maken.

# Service gebruiken Toelichting

1 Ophalen gegevens service Haalt de relevante gegevens op uit de desbetreffende bron.

2 Ontsluiten besluiten Het ontsluiten van bekendgemaakte besluiten of delen

hiervan ten behoeve van het DSO.

De granulariteit van wat opgevraagd kan worden is groot.

Deze applicatieservice biedt de mogelijkheid om precies die

eigenschappen met bijbehorende waarden op te vragen die

nodig zijn om vragenbomen uit te voeren. Een voorbeeld

hiervan zou een specifieke grondslag kunnen zijn zoals de

maximale bouwhoogte binnen een bepaald werkingsgebied.

3 Content service Via de content service wordt de uit de toepasbare regels

geëxtraheerde content opgeslagen in het CMS.

4 Vastleggen metadata De activiteiten en werkzaamheden worden in de registratie

toepasbare regels beheerd. Het is wel wenselijk dat deze

begrippen ontsloten kunnen worden via de Catalogus. Via

deze service wordt de relevante verwijzing vastgelegd in de

Catalogus zodat de Catalogus weet waar de informatie staat

en een samenhangend beeld kan vormen.

Referenties naar werkzaamheden en activiteiten staan dus in

de Catalogus. De content zelf staat in de registratie

toepasbare regels. Er is hierover een besluit genomen door

het stelsel architectuur team.

Hieronder wordt aangegeven welke services de componenten

realiseren.


Deelprogramma DSO

# Applicatie service realiseren Toelichting

1 Regels ontvangen service

Bevoegd gezagen maken van gebruik deze service voor het

aanleveren van hun toepasbare regels. Het koppelvlak is

gebaseerd op het nog nader te specificeren informatiemodel

toepasbare regels. De basis van het koppelvlak is de

standaard DMN voor de bedrijfsregels. Deze wordt aangevuld

zodat ook uitvoeringsregels uitgedrukt kunnen worden.

Gezien het feit dat gebruikerstoepassingen “domme”

applicaties zijn, zal een deel van de front-end aansturing

zoals vraagvolgorde, waardelijsten, etc. ook via dit koppelvlak

in de regels aangegeven moeten worden.

2 Geo analyse service Elke regel heeft een werkingsgebied. Bij een check of

indiening moet er gekeken worden welke regels van

toepassing zijn gegeven onder andere de locatie. Deze

service geeft antwoord of een locatie (de locatie wordt geduid

door een coördinaat of een polygoon) binnen een

werkingsgebied valt.

De service wordt tevens gebruikt voor geo validaties van de

aangeleverde toepasbare regels. Bijvoorbeeld om te checken

of de door een gemeente aangeleverde werkingsgebieden ook

daadwerkelijk binnen de gemeentegrenzen vallen. Een andere

validatie zou kunnen zijn dat een polygoon een gesloten vorm

is die zichzelf niet overlapt.

3 Bepalen conclusie service

Koppelvlak met gebruikerstoepassingen dat een conclusie

geeft ten aanzien van een bepaalde vraag. Er kunnen

verschillende conclusies worden gevraagd:

Welke toestemmingen zijn van toepassing

(vergunningsplicht, meldingsplicht, etc)

Welke voorschriften en maatregelen zijn van

toepassing

Welke indieningsvereisten zijn van toepassing

De conclusies worden via vragenbomen afgeleid.

Voor het bepalen van de conclusie wordt er gewerkt met

activiteiten. In de interactie met de gebruiker wordt door de

gebruikerstoepassing de werkzaamheid bepaald. Op basis

hiervan wordt de activiteit afgeleid.

4 Bepalen werkzaamheden

service

Service die alle beschikbare werkzaamheden inclusief

synoniemen beschikbaar stelt.

De service kan ook alle gerelateerde werkzaamheden van een

bepaalde werkzaamheid beschikbaar stellen.

Bepalen werkzaamheden is niet regelgestuurd en wordt

daarom niet geleverd door de regeluitvoering. In essentie is

het een lijst met kenmerken. Op basis van linked data wordt

de lijst ontsloten vergelijkbaar aan de Catalogus.

5 Opvragen/ bewerken concepten

service

Indien vanuit de Catalogus een gebruiker in een activiteit of

werkzaamheid wil inzien zal de Catalogus via deze service de

relevante data ophalen.

6 Ontsluiten Toepasbare Regels

service

Open service die toepasbare regels ontsluit aan bevoegd

gezagen en derden. Via deze service kunnen regels van

andere bevoegd gezagen hergebruikt worden.

7 Toepasbare regels ontvangen

service

Service gerealiseerd door het transformatie component. Via

deze service worden de toepasbare regels ontvangen.

8 Uitvoerbare regels ontvangen

service

Service gerealiseerd door het regeluitvoering component. Via

deze service worden de uitvoerbare regels ontvangen.


Deelprogramma DSO

3.4.1 Toelichting bepalen conclusies

Deze service ontsluit de uitvoerbare regels middels een generiek

mechanisme van vraagbomen: een vraagboom richt zich op een

conclusie. Een vraagboom bestaat uit een verzameling van één of meer vragen. Hij ontstaat door de dialoog tussen de rule engine en de

gebruiker. Om tot een conclusie te komen zijn feiten nodig. Deze

worden (onder andere) verzameld door vragen te stellen aan een gebruiker. Welke vragenreeks moet worden gesteld is steeds

afhankelijk van de antwoorden op de voorgaande vraag of vragen. Er

wordt daarmee een dynamisch opgebouwde boom van vragen

doorlopen die leidt tot een conclusie. Het kan ook zijn dat meerdere conclusies samen een eindconclusie vormen.

Op elk moment kan de check of een aanvraag op aangeven van de gebruiker als herbruikbaar product worden bewaard om later te kunnen raadplegen of om later af te maken. Dit kan anoniem in een eigen

omgeving of na zichzelf bekendgemaakt te hebben in een projectdossier. Dit wordt geregeld door de gebruikerstoepassing.

Als een check later wordt afgemaakt kunnen vragen en antwoorden in

de opgevraagde vragenboom wijzigen als er sprake is van gewijzigde regelgeving of van wijzigingen in gebruikte bronnen (registraties,

basisadministraties e.d.). Zo een wijziging wordt door de conclusieservice gesignaleerd en gemeld aan de initiatiefnemer.

Bekende gegevens worden opgevraagd via bronnen. Een bron is een

webservice.

Indien dit niet mogelijk is wordt het bij de gebruiker uitgevraagd. Dit is

geregeld in de uitvoeringsregels.

Er kan samenhang zitten tussen vragen en antwoorden en deze zullen hergebruikt worden indien ze in 1 keer uitgevraagd worden,

bijvoorbeeld als er twee dakkappelen aangevraagd worden, dan wordt

de eerder opgevoerde informatie vooraf ingevuld voor de gebruiker ter verificatie. Dit geldt ook voor hergebruik over verschillende typen

conclusies heen, bijvoorbeeld het bepalen van een toestemming en het

bepalen van de indieningsvereisten.

Het is een eis dat tijdreizen binnen het digitale stelsel mogelijk moet

zijn. Een service ten aanzien van een conclusie kan worden

aangeroepen met een peildatum. In de basis zal dat de systeemdatum zijn maar kan ook in het verleden liggen. Theoretisch is het ook

mogelijk om een datum in de toekomst te gebruiken maar de conclusie


Deelprogramma DSO

zou dan zeer onbetrouwbaar zijn. Dit gezien het feit dat het niet

gegarandeerd kan worden dat de conclusie gebaseerd is op een

complete set aan regels. Regels hebben een datum van

inwerkingtreding en een datum van uitwerkingtreding. Op basis hiervan

worden de services in staat gesteld om de vragenbomen met een peildatum aan te bieden.

Indien BG eigen bronnen wil gebruiken zullen deze aan nader te

bepalen aansluitvoorwaarden moeten voldoen. Een mogelijke eis in dit kader zou kunnen zijn dat ze met een peildatum bevraagbaar moeten

zijn.

Een gebruiker van de conclusieservice kan een tussentijdse bewerking opslaan om later af te ronden. Indien de relevante vragenboom

gewijzigd is in de tussentijd moet dit aan de gebruiker gemeld worden.

Tijdens de overgangsperiode kan de situatie zich voordoen dat nog niet alle toepasbare regels voor het bijbehorende werkingsgebied en de

bijbehorende activiteiten zijn gepubliceerd. Bij de Landelijke Voorziening Bekendmaken en Beschikbaar stellen wordt gecheckt of er

relevante ruimtelijke plannen zijn. Zie [BRON 7] voor verdere toelichting.

3.5 Herbruikbare bouwblokken

3.5.1 Gebruiken

De volgende bouwblokken zullen worden afgenomen:

# Bouwblok Type Toelichting

1 Auditing DSO Auditing is het vastleggen van gebeurtenissen en bijbehorende

informatie. Auditing is zowel van belang voor operationele

veiligheid als het voldoen aan wet- en regelgeving door

achteraf te kunnen vaststellen of een bepaalde gebeurtenis

heeft plaatsgevonden. Applicaties en componenten sturen

auditinformatie voor traceerbaarheid naar deze component. De

component biedt een webgebaseerde gebruikersinterface die

toegang geeft tot de auditinformatie en deze doorzoekbaar

maakt. Auditinformatie wordt ook gebruikt om

berichtenverkeer in de keten te volgen. Hierdoor zijn

beheerders in staat om zelfstandig berichten in de keten te

volgen en de oorzaak van problemen te herleiden in de keten.

2 Berichtarchivering DSO Indien onweerlegbaarheid van het berichtenverkeer vereist is,

dient een verstuurd of ontvangen bericht gearchiveerd te

worden. Hiermee wordt het bericht zelf vastgelegd, zodat later

bij vragen aangetoond kan worden dat een bericht is

ontvangen van of verzonden naar een bepaalde organisatie en

wat de inhoud van het bericht was. Deze component biedt een

webgebaseerde gebruikersinterface die toegang geeft tot de

gearchiveerde berichten.


Deelprogramma DSO

3 Logging DSO Applicaties loggen informatie naar deze component om fouten

te kunnen identificeren en op te lossen. Het logniveau van

componenten en applicaties is in de applicaties zelf dynamisch

instelbaar, zodat dit kan worden verhoogd bij problemen en

weer worden verlaagd als de problemen zijn opgelost. Deze

component biedt een webgebaseerde interface die toegang

geeft tot de logging informatie en maakt deze doorzoekbaar.

4 Rapportage DSO Component waar analyses mee gedaan worden (zoals aantal

raadplegingen van een informatiebron, aantal log-ins op een

applicatie). De rapportagetool is bedoeld voor gebruikers, zoals

business analisten en functioneel beheerders. Ook voor het

genereren van standaard rapportages.


Deelprogramma DSO

4 Beheer

In dit hoofdstuk worden de relevante beheeraspecten beschreven als een van de pijlers van een betrouwbare dienstverlening.

Het stelsel moet ervanuit kunnen gaan dat de beheerder van de

voorziening zorgdraagt voor de voorziening als dienst. Het moet zo ingericht zijn dat de dienst als geheel voldoet aan de afgesproken

dienstniveau.

Het principe uit de Overall GAS dat in ieder geval van toepassing is dat

de beheerorganisatie van een component opereert in samenwerking

met de stelselpartners (DSO.BEH.10.001). Voor meer informatie over

principes en de eisen die daaraan gesteld worden hoofdstuk 6. Bij het inrichten van beheer zal aandacht worden gegeven aan alle

relevante onderdelen van het ITIL/BISL/ASL raamwerk met speciale aandacht voor de volgende aandachtspunten op deelaspecten:

Incident en probleem beheer. Tijdens het gebruik van de primaire

diensten ontstaan problemen en vragen. Deze worden gemeld als

“incident”. Dit proces zorgt ervoor dat deze incidenten en/of

problemen adequaat worden afgehandeld. Het betreft hier tweedelijns support. De servicedesk van het DSO vormt de eerste

lijn. Operationele IT aansturing. Dit proces zorgt voor de operationele

aansturing van IT t.b.v. de primaire processen. Het gaat hierbij bijvoorbeeld om bewaking, herstarten of het draaien van

specifieke rapportages.

Transitie. Dit proces zorgt voor het in gebruik nemen van nieuwe releases of functionaliteit. Het gaat bijvoorbeeld om communicatie

(richting opdrachtgever en gebruiker) m.b.t. een nieuwe release, de opdracht voor het uitrollen van een release of het bijwerken

van documentatie.

Wijzigingenbeheer. Het proces wijzigingenbeheer zorgt voor de juiste besluitvorming met betrekking tot wijzigingen in de

primaire diensten. Dit gebeurt met name vanuit perspectief

opdrachtgever.

Gebruikersondersteuning. Dit proces verzorgt alle communicatie tussen functioneel beheer en opdrachtgever. Het kan hierbij gaan om FAQ’s,

incidenten, handleidingen, rapportages, etc. Het kan hier ook gaan om

eventuele tweedelijns ondersteuning bij aanleveringen door

bronhouders.


Deelprogramma DSO

Specifiek aandachtspunt is de inrichting van centrale beheer. De

volgende taken moeten belegd worden:

Beheren centrale gegevensverzamelingen

Gegevens omtrent activiteiten en werkzaamheden horen niet thuis bij een specifiek BG. Het is wel essentieel dat er een

eenduidige set komt. Dit kan alleen bewerkstelligd worden als

het beheer van de gegevens centraal uitgevoerd wordt. Check op samenhang en kwaliteit van aangeleverde toepasbare

regels

De kwaliteit en samenhang tussen regels kan niet in zijn geheel

geautomatiseerd getest worden. BG is zelf verantwoordelijk voor het testen van eigen regels, echter er is een gemeenschappelijk

belang om te borgen dat alle regels aan een samen nader te

specificeren maatstaf voldoen. Dit kan het beste uitgevoerd worden door een onafhankelijke organisatie.

In het project wordt de standaard voor toepasbare regels

ontwikkeld (DMN+) op basis waarvan toepasbare regels door de bevoegd gezagen aan de Registratie toepasbare regels

aangeleverd. De standaard moet ook in beheer genomen worden voor verdere ontwikkeling.


Deelprogramma DSO

5 Beveiliging & privacy

In dit hoofdstuk worden de relevante beveiligings- en privacyaspecten beschreven als een pijler voor een betrouwbare serviceverlening.

Betrouwbaarheid is in de context van beveiliging en privacy het

inbouwen van die mechanismen die bescherming van informatie tot

doel hebben.

5.1 Beveiligingsclassificaties

Informatiebeveiliging wordt in drie beveiligingsclassificaties

onderverdeeld: beschikbaarheid, integriteit, en vertrouwelijkheid.

Classificatie Toelichting

Beschikbaarheid Hoe vaak en wanneer een component toegankelijk is en kan worden gebruikt.

Integriteit

Het in overeenstemming zijn van informatie met het afgebeelde deel van de

werkelijkheid en dat niets ten onrechte is achtergehouden of verdwenen

(juistheid, volledigheid en tijdigheid). Het gaat hier om de integriteit van

gegevens waarop en waarmee een component werkt.

Vertrouwelijkheid Het beperken van de bevoegdheden en de mogelijkheden tot muteren, kopiëren,

toevoegen, vernietigen of kennisnemen van informatie tot een gedefinieerde

groep van gerechtigden.

Onweerlegbaarheid Begrip dat gebruikt wordt bij elektronische berichtuitwisseling en dat inhoudt dat

de zender van een bericht niet kan ontkennen een bepaald bericht te hebben

verstuurd en dat de ontvanger van een bericht niet kan ontkennen het bericht van

de zender in de oorspronkelijke staat te hebben ontvangen.

Controleerbaarheid Er wordt voor gezorgd dat de beoogde toegang tot gegevens en de juiste werking

van zijn systemen continu alsook achteraf te controleren is.

Waarde Niet voldoen leidt tot

Zeer Hoog Vragen in de Tweede Kamer; maatschappelijke onrust; levensbedreigende

situaties; grote financiële gevolgen voor de Nederlandse overheid.

Hoog Financiële consequenties (op den duur); vragen/klachten bij het management;

vragen in de Raad van Toezicht of door de Minister; negatieve publiciteit.

Midden Vragen/klachten bij gebruikers/klanten; vragen/klachten bij het management.

Laag Geen gevolgen (alleen vervelend).

Zeer Laag Niet relevant/niet van toepassing.

5.2 Beschikbaarheid

De beschikbaarheid van Toepasbare Regels Uitvoeren moet worden

geclassificeerd als hoog. Als de beschikbaarheid het laat afweten zal dit

snel tot vragen/ klachten bij het management. Een deel van de services bepalen de werking van het loket. Het niet beschikbaar zijn van deze


Deelprogramma DSO

services zal zeker leiden tot negatieve publiciteit en vragen in de Raad

van Toezicht of door de Minister.

In de volgende tabel wordt per bedrijfsservices de classificatie geduid

waarbij afgeweken kan worden bovenstaande algemene insteek.

Bedrijfsservice Classificatie Toelichting

Valideren en

registreren

toepasbare regels

Midden Het niet werken van deze service zal op zijn hoogst leiden tot

klachten van gebruikers en vragen aan het management.

Ontsluiten

toepasbare regels

Hoog Het niet werken van deze service zal leiden tot een negatieve

publiciteit doordat een breed scala aan afnemers niet in staat

is zijn werk te doen.

Leveren conclusie Hoog Het niet werken van deze service heeft als resultaat dat de

werking van het digitale loket en third party apps niet meer

naar behoren werken. Dit brengt negatieve publiciteit met

zich mee.

De oplossing moet 7 dagen per week, 24 uur per dag met een hoog

beschikbaarheidspercentage beschikbaar zijn.

5.3 Integriteit

De Integriteit van Toepasbare Regels Uitvoeren moet worden geclassificeerd als hoog. Er worden disclaimers afgegeven ten aanzien

van de conclusies echter als de integriteit het laat afweten zal dit al snel tot negatieve publiciteit leiden.

In de volgende tabel wordt per bedrijfsservices de classificatie geduid

waarbij afgeweken kan worden bovenstaande algemene insteek.


Valideren en

registreren

toepasbare regels

Midden Het incorrect werken van deze service zal op zijn hoogst

leiden tot klachten van gebruikers en vragen aan het

management.

Ontsluiten

toepasbare regels

Hoog De toepasbare regels die ontsloten worden vormen veelal de

basis voor de toepasbare regels van de afnemers. Niet

integere gegevens zullen dan ook potentieel een

olievlekwerking zien. Dit zal snel leiden tot negatieve

publiciteit en vragen aan het management.

Leveren conclusie Hoog Als gebruikers niet meer uit kunnen gaan van de conclusies

die geleverd worden haalt dat de werking van het digitale

loket en de 3rd party apps onderuit. Dit zal leiden tot

negatieve publiciteit en vragen aan het management.


Deelprogramma DSO

Complexiteit is dat voortbrenging van regels gedistribueerd is over de

processen van 400+ BG. Optimaliseren tbv integriteit op procesniveau

is onvoldoende. Dit levert een requirement voor centrale

beheerorganisatie die testen uitvoert op samenhang/ totaal.

5.4 Vertrouwelijk

De gegevens gebruikt in de regelbeheerprocessen kennen een lage

vertrouwelijkheidsgraad. De gebruikte wet- en regelgeving is openbaar.

De toegevoegde informatie tijdens de processen ten aanzien van de uitvoer zijn ten behoeve van publieke diensten. Er hoeven hiervoor

geen speciale maatregelen te worden ingericht. Beveiliging is vanuit dit

gezichtspunt voor een belangrijk deel gericht op het bewaken van de

integriteit en minder op de vertrouwelijkheid.

Voor het aanleveren van gegevens zoals de toepasbare regels moet

toegang wel geregeld worden. Dit mag alleen gedaan worden door bevoegd gezag. Specifieker, er moet ook worden gecontroleerd dat de aangeleverde Toepasbare Regels voor het ambtsgebied van het BG zijn.


Valideren en

registreren

toepasbare regels

Midden Voor het aanleveren van gegevens zoals de toepasbare regels

moet toegang wel geregeld worden. Dit mag alleen gedaan

worden door bevoegd gezag. Er moet ook worden

gecontroleerd dat de aangeleverde Toepasbare Regels voor

het ambtsgebied van het BG zijn.

Een algemenere vraag is of een BG wel bevoegd is bepaalde

regels te stellen. Dit is iets breder dan de geografische

afbakening via een ambsgebied. In de rijks amvb's staat

nadrukkelijk of er maatwerkregels mogelijk zijn op decentraal

gebied. Soms staat dit "aan" en soms staat dit "uit" (bijv

technische bouwregels).

Ontsluiten

toepasbare regels

Zeer laag De toepasbare regels kunnen gezien worden als open data.

Eenieder mag de data afnemen.

Leveren conclusie Zeer laag De conclusies kunnen gezien worden als open data. Eenieder

mag de service afnemen.


Deelprogramma DSO

5.5 Onweerlegbaarheid

Ten aanzien van het ontvangen van de toepasbare regels is

onweerlegbaarheid van belang. Er mag geen twijfel bestaan of een BG

daadwerkelijk bepaalde regels verstuurd heeft of dat deze ontvangen

zijn.


Valideren en

registreren

toepasbare regels

Midden Onduidelijkheid ten aanzien van het ontvangen of verzenden

van toepasbare regels zal leiden tot leiden tot klachten van

gebruikers en vragen aan het management.

Ontsluiten

toepasbare regels

Laag Problemen voor deze service ten aanzien van

weerlegbaarheid zijn op zijn hoogst irritant.

Leveren conclusie Laag Problemen voor deze service ten aanzien van

weerlegbaarheid zijn op zijn hoogst irritant.

5.6 Controleerbaarheid

Het moet inzichtelijk zijn welk bevoegd gezag, wanneer, welke toepas-

bare regels heeft ingediend. Het is minder van belang wie welke

conclusie opgevraagd heeft.


Valideren en

registreren

toepasbare regels

Midden Indien het niet achterhaald kan worden welk bevoegd gezag

op welk moment bepaalde toepasbare regels heeft ingediend

zal dat leiden tot klachten van gebruikers en vragen aan het

management.

Ontsluiten

toepasbare regels

Laag Problemen voor deze service ten aanzien van weerlegbaar-

heid zijn op zijn hoogst irritant.

Leveren conclusie Laag Problemen voor deze service ten aanzien van weerlegbaar-

heid zijn op zijn hoogst irritant.


Deelprogramma DSO

6 Principes

Kaders- en richtlijnen waaraan de realisatie en beheer van het Digitaal Stelsel Omgevingswet gehouden is worden als principes geformuleerd.

Afwijken van de principes is alleen toegestaan na akkoord van de lead

architect PDSO. Dit hoofdstuk beschrijft de principes.

De principes volgen het NORA 9+2 vlaksmodel, een raamwerk dat ook

gehanteerd wordt in de Nederlandse Overheid Referentie Architectuur

(NORA) en afgeleide architecturen. Zie de laatste versie van het document “DSO - Architectuur - Toelichting principes” voor een

toelichting hoe principes beschreven zijn.

6.1 Overzicht

Hieronder worden de principes opgesomd die in het DSO worden

gehanteerd. In deze lijst is aangegeven welke van toepassing zijn voor deze GAS.

Identificatie Statement Van toepassing

DSO.BA.01.001 Er wordt rekening gehouden met de digitale volwassenheid van

ketenpartijen.

DSO.BA.01.002 Afnemers en toeleveranciers hebben één aanspreekpunt bij vragen

en problemen.

X

DSO.BA.01.003 Gebruikers hebben interactie met stelselonderdelen via

gebruikerstoepassingen en systemen en apps van bevoegd

gezagen en derden.

X

DSO.BA.01.004 Terugmeldingen worden afgehandeld door de bronhouder.

DSO.BA.02.001 Services moeten voldoen aan de gestelde kwaliteitseisen. X

DSO.BA.03.001 Processen worden verbonden met services.

DSO.BA.03.002 De status van processen zijn bekend. X

DSO.IA.04.001 Componenten richten zich op één functionele taak. X

DSO.IA.04.002 Scheiding van data, functionaliteit en presentatie. X

DSO.IA.04.003 Eigenaarschap van componenten is overdraagbaar.

DSO.IA.04.004 Componenten gebruiken Herbruikbare Functies. X

DSO.IA.04.005 Software en content zijn onafhankelijk van elkaar. X

DSO.IA.05.001 Acties zijn herleidbaar tot een persoon of systeem. X

DSO.IA.06.001 Koppelvlakken worden gedefinieerd op basis van het informatie-

uitwisseling lagenmodel.

X

DSO.IA.06.002 Koppelvlakken ondersteunen versies. X


Deelprogramma DSO

DSO.IA.06.003 In- en uitgaande berichten zijn onweerlegbaar. X

DSO.BEH.10.001 De beheerorganisatie van een component opereert in

samenwerking met de stelselpartners

X

DSO.HEV.11.001 Componenten kennen een gelaagde opbouw en voldoen aan de

voorgeschreven compartimentering.

X

DSO.HEV.11.002 Componenten kennen een solide updatemechanisme. X

DSO.HEV.11.003 De bron van een transactie is altijd herleidbaar. X

Hierna wordt voor elke principe dat van toepassing is, aangegeven hoe

deze ingevuld wordt voor deze GAS. Om duplicatie van teksten in de

OGAS te voorkomen worden op de identificatie, statement en eisen na

de andere standaard onderdelen van een principe weggelaten. Hiervoor

kan de OGAS geraadpleegd worden.

6.2 Business architectuur

6.2.1 Organisatie

Identificatie DSO.BA.01.002

Statement Afnemers en toeleveranciers hebben één aanspreekpunt bij vragen en problemen.

Eisen Er is een centrale stelsel serviceorganisatie waar alle vragen en problemen

binnenkomen (1e lijn support).

De serviceorganisatie Toepasbare Regels ondersteunt als het inhoudelijke vragen

(werking) van het Toepasbare betreft (2e en 3e lijn support).

De serviceorganisatie van het knooppunt ondersteunt bij het aansluiten op

knooppunt en bij connectiviteitsproblemen met het knooppunt (2e en 3e lijn

support).

Identificatie TPR.BA.01.003

Statement Gebruikers hebben interactie met stelselonderdelen via gebruikerstoepassingen en

systemen en apps van bevoegd gezagen en derden.

Eisen De handmatige validatiestap heeft een gebruikerstoepassing. Het kan zijn dat technisch

en semantisch alles klopt maar dat het resultaat toch niet gewenst is. De handmatige

validatie is niet strikt noodzakelijk maar zal wel worden mogelijk gemaakt.

Identificatie BLU.BA.03.002

Statement De status van processen zijn bekend.

Eisen Bevoegd gezag moet de (voortgang)status van de aangeleverde toepasbare regels

kunnen opvragen.

Procesgegevens worden vastgelegd.


Deelprogramma DSO

6.2.2 Diensten & Producten

Identificatie DSO.BA.01.004

Statement Services moeten voldoen aan de gestelde kwaliteitseisen.

Eisen Informatie over kwaliteit en telbaarheid van alle stappen worden geregistreerd.

6.3 Informatiearchitectuur

6.3.1 Medewerkers en Applicaties

Identificatie DSO.IA.04.001

Statement Componenten richten zich op één functionele taak.

Eisen De componenten Toepasbare Regels Maken en Toepasbare Regels Uitvoeren zijn

opgedeeld om hieraan te voldoen.


Statement Scheiding van data, functionaliteit en presentatie.

Eisen Business logica en data wordt gerealiseerd in een backend en ontsloten via services.

Het is niet toegestaan om business logica in de presentatielaag onder te brengen.

De gebruikerstoepassingen ten aanzien van checken en indienen kennen geen

business logica. Dit wordt door Toepasbare Regels Uitvoeren geleverd via de

loketservices.


Statement Componenten gebruiken Herbruikbare Functies.

Eisen Functionaliteiten die niet business specifiek zijn worden als aparte herbruikbare

componenten gerealiseerd.

Toepasbare Regels Uitvoeren maakt zoveel mogelijk gebruik van herbruikbare

componenten.

Alle functionaliteit van een Herbruikbare Functie is ontsloten via goed gedefinieerde

leverancier en product neutrale koppelvlakken zoals het informatiemodel toepasbare

regels.


Statement Software en content zijn onafhankelijk van elkaar.


Deelprogramma DSO

Eisen Vraagbomen en werkzaamheden worden als content behandeld en onafhankelijk

van de release cyclus van de software naar productie gebracht en in gebruik

genomen.

Content wordt via de staging omgeving naar productie gebracht.

Het uitrolmechanisme van staging naar preproductie naar productie is volledig

geautomatiseerd en wordt door een functioneel beheerder vanuit een beheerconsole

aangestuurd en gecontroleerd.

Het uitrolmechanisme moet het volledig automatisch terugrollen naar de

voorgaande versie mogelijk maken, voor het geval dat er na het uitrollen problemen

optreden.

6.3.2 Gegevens


Statement Acties zijn herleidbaar tot een persoon of systeem.

Eisen Er wordt auditing informatie op recordniveau bijgehouden van gegevensmutaties.

Gegevens worden niet verwijderd, maar gemarkeerd als verwijderd.

6.3.3 Informatie-uitwisseling


Statement Koppelvlakken worden gedefinieerd op basis van het informatie-uitwisseling lagenmodel.

Eisen Koppelvlakken worden gedefinieerd op basis van het informatie-uitwisseling lagenmodel.


Statement Koppelvlakken ondersteunen versies.

Eisen Koppelvlakken ondersteunen versies.

Een afnemer bepaalt zelf welke versie van een koppelvlak zij gebruikt.

Er worden maximaal 3 versies van een koppelvlak ondersteund.

Een oude versie van een koppelvlak wordt nog maximaal 1 jaar na introductie van

een nieuwe versie ondersteund.


Statement In- en uitgaande berichten zijn onweerlegbaar.

Eisen Auditing en berichtarchivering is per koppelvlak in en uit te schakelen.

Auditing en berichtarchivering gebeurt automatisch.


Deelprogramma DSO

6.4 Beheer

Identificatie DSO.BEH.10.001

Statement De beheerorganisatie van een component opereert in samenwerking met de

stelselpartners

Eisen Stelselsamenwerking is onderdeel van de stelselafspraken.

Vanuit onderdelen wordt tweede- en derdelijns ondersteuning geleverd.

Incidenten met onderdelen worden gemeld bij de centrale serviceorganisatie van het

DSO.

6.5 Beveiliging & privacy

Identificatie DSO.HEV.11.001

Statement Componenten kennen een gelaagde opbouw en voldoen aan de voorgeschreven

compartimentering.

Eisen De interactielaag (front-end) communiceert met de servicelaag (koppelingen).

De servicelaag met de applicatielaag (backend ontsloten via webservices).

De applicatielaag met de datalaag (gegevens).


Statement Componenten kennen een solide updatemechanisme.

Eisen Kritische beveiligingspatches worden binnen 1 week geïnstalleerd.

Beveiligingspatches worden binnen 4 weken geïnstalleerd.


Statement De bron van een transactie is altijd herleidbaar.

Eisen Berichten zijn voorzien van een transactie ID.

Alle organisaties loggen dit ID met andere relevante informatie.

Bij services betekent dit dat de afnemer naast de transactie ID ook de medewerker

registreert die de transactie initieert.


Deelprogramma DSO

7 Standaarden

In deze bijlage worden de standaarden benoemd die van toepassing zijn bij het ontwikkelen van Toepasbare Regels Uitvoeren. Veel van deze

standaarden zijn afkomstig van het Forum Standaardisatie

(http://www.forumstandaardisatie.nl)

Naam Omschrijving Bron Beherende

organisatie

Versie Informatie

HyperText

Markup

Language

(HTML)

HTML is een taal waarmee

vastgelegd kan worden hoe

webpagina's opgemaakt moeten

worden. HTML maakt het mogelijk

om de structuur van een tekst

gebaseerd document te beschrijven

door links, hoofdstukken,

paragrafen, lijsten enz. aan te

geven.

Forum

standaar

disatie

W3C 4.01 http://www.w3.org/T

R/html401/

XML Extensible Markup Language (XML)

is een standaard voor de syntaxis

van formele markuptalen. Hiermee

kunnen gestructureerde gegevens

worden gerepresenteerd in de vorm

van tekst, die zowel door mensen als

machines leesbaar is. XML wordt

gebruikt voor de ontwikkeling van

domein- en toepassingsspecifieke

markuptalen.

Forum

standaar

disatie

W3C 1.0 http://www.w3.org/T

R/REC-xml/

DMN Decision Modelling Notation is een

standaard voor het beschrijven en

modelleren van herhaalbare

beslissingen in organisaties.

OMG OMG 1.1 http://www.omg.org/

spec/DMN/

Digikoppeling De standaard om

systeemkoppelingen tussen

overheden te realiseren.

Het gaat hier om de logistieke

afspraken en niet om

inhoudelijke afspraken.

Forum

Standaa

rdisatie

Logius 2.0 Versie 3.0 is

vastgesteld, maar

nog niet

opgenomen in de

PTOLU lijst van

Forum

Standaardisatie.

Content

Management

Interoperability

Services (CMIS)

Content Management

Interoperability Services (CMIS) is

een open standaard die een

scheiding mogelijk maakt tussen

zogenaamde ‘content repositories’

en content applicaties. Hierdoor

kunnen content (ongestructureerde

data, zoals documenten en e-mails)

en bijbehorende metadata

(beschrijvende data) gemakkelijker

worden uitgewisseld.

Forum

Standaa

rdisatie

OASIS 1.0 http://docs.oasis-

open.org/cmis/CMIS/

v1.0/os/cmis-spec-

v1.0.html

http://www.forumstandaardisatie.nl/

http://www.w3.org/TR/html401/

http://www.w3.org/TR/html401/

http://www.w3.org/TR/REC-xml/

http://www.w3.org/TR/REC-xml/

http://www.omg.org/spec/DMN/

http://www.omg.org/spec/DMN/


Deelprogramma DSO

BWB JC-BWB biedt een eenduidige manier

van verwijzen naar (onderdelen van)

wet- en regelgeving. Hiermee wordt

de interoperabiliteit van juridische

documenten en systemen die veel

verwijzingen kennen naar wet- en

regelgeving bevorderd.

Forum

standaa

rdisatie

Juriconnect 1.3.1 http://standaarden.ov

erheid.nl/bwb

Juriconnect

Decentrale

Regelgeving

(JCDR)

De standaard biedt een eenduidige

manier van verwijzen naar

(onderdelen van) decentrale

regelgeving waarmee de

interoperabiliteit van juridische

documenten en systemen die veel

verwijzingen kennen naar decentrale

regelgeving wordt bevorderd.

Forum

standaa

rdisatie

Juriconnect 1.0 http://juriconnect.nl/i

mplementatie.asp?su

bpagina=documentati

e

European Case

Law Identifier

(ECLI)

Met de ECLI standaard kunnen:

1) alle rechterlijke uitspraken in de

Europese Unie (zowel van nationale

als van Europese gerechten) worden

voorzien van een gelijkaardige,

unieke en persistente identifier. Deze

identifier kan worden gebruikt voor

identificatie en citatie van

rechterlijke uitspraken en derhalve

om deze te vinden in binnenlandse

of, buitenlandse, Europese of

internationale

jurisprudentiedatabanken.

2) alle rechterlijke uitspraken

worden voorzien van uniforme

metadata, gebaseerd op de Dublin

Core standaard. Het zoeken van

uitspraken in allerlei databanken

worden daardoor gefaciliteerd.

Forum

standaa

rdisatie

Juriconnect 1.0 http://www.juriconne

ct.nl/implementatie.as

p?subpagina=docume

ntatie

http://juriconnect.nl/implementatie.asp?subpagina=documentatie





Deelprogramma DSO

8 Roadmap

In dit hoofdstuk wordt de roadmap beschreven om het eindbeeld in controleerbare en haalbare stappen te realiseren: van IST naar SOLL

met de tussenstappen. Per situatie wordt kort beschreven wat het

verschil is met de voorgaande stap en toegelicht waarom deze stap

nodig is. Tussenstappen zijn expliciet gemaakt en er wordt aangegeven of het een logische tussenstap is of een afwijking. Indien het een

afwijking is, wordt aangegeven wanneer deze afwijking weer in lijn

gebracht moet worden met het eindbeeld.

8.1 Overzicht transitie

8.2 Huidige situatie

8.2.1 OLO

Omgevingsloket Online (OLO) en Activiteit Internet Module (AIM) zijn

twee aparte voorzieningen waar toepasbare regels gebruikt worden. De vraagbomen en werkzaamheden zijn in OLO voor inwoners en bedrijven

te weinig herkenbaar.

8.2.2 AIM

De Activiteitenbesluit Internet Module (AIM) is bedoeld voor milieurelevante activiteiten. Het Activiteitenbesluit bevat algemene

milieuregels voor bedrijven. Bedrijven die onder het Activiteitenbesluit

Figuur 8. Transitie


Deelprogramma DSO

vallen hebben vaak geen vergunning voor het oprichten of veranderen

nodig.

Met AIM kan een bedrijf:

Controleren of een vergunning of melding nodig is, inzicht krijgen in milieuregels en maatregelen, en

online een melding Activiteitenbesluit indienen.

In AIM wordt regelbeheer voor het grootste deel opgelost met behulp

van Excel. In Excel worden de juridische regels geanalyseerd, de

verschillende norm en condities binnen deze regels uiteen gerafeld

(inclusief onderlinge verbanden) en omgevormd tot vragenbomen (met vragen, antwoorden en toelichtingen). Het beheren van voorschriften en

maatregelen wordt gedaan met beheerschermen. Er zit veel overlap in

de functionaliteit van AIM en OLO. Alleen wordt deze functionaliteit anders opgelost. In AIM zijn bijvoorbeeld check en indienen vervlochten, waardoor het niet mogelijk is om in te dienen zonder eerst

een check uit te voeren. AIM heeft daarnaast functionaliteit voor voorschriften op maat, maatregelen op maat en bedrijfsprofielen. Om

aan alle vormen van huidige functionaliteit te voldoen zal ook deze AIM specifieke functionaliteit ondersteund moeten worden in het nieuwe

systeem. Daarnaast moeten checken en indienen ontvlochten worden.

Als de conclusie van de check is dat een vergunning aangevraagd moet worden, dan wordt de gebruiker doorgestuurd naar het Omgevingsloket

online (OLO). Hier moet de gebruiker alle gegevens opnieuw invoeren.

AIM kent geen lokale regelgeving.

8.2.3 OLO

Met Omgevingsloket online (OLO) kan digitaal een aanvraag of melding

gedaan worden voor omgevingsvergunningen en watervergunningen.

Met OLO kan ook een vergunningcheck worden gedaan om te zien of een vergunning of melding nodig is. De doelgroepen van OLO zijn

burgers, bedrijven en overheden.

Regelbeheer in OLO 2 bestaat uit vragenbomen. Deze vragenbomen zijn

onderdeel van de software. Om de vragenbomen te wijzigen is een

technische aanpassing van de software nodig. Dit betekent een nieuwe

release van het systeem. Het uitrollen van een release kost veel tijd en

inspanning en wordt om deze redenen beperkt tot maximaal 2 maal per

jaar. Dit zorgt ervoor dat het regelbeheerproces zeer rigide is, waardoor

OLO als geheel niet wendbaar is.


Deelprogramma DSO

OLO 2 biedt geen inzicht in de impact van wijzigingen in de regelgeving

op het systeem. Hierdoor is het doorvoeren van wijzigingen complex.

8.3 Eindsituatie (2018)

Met de inwerkingtreding van de Omgevingswet is de basis van Toepasbare Regels gerealiseerd. Dit betekent dat landelijke en lokale

vragenbomen ondersteund worden die locatiegericht zijn en gebruik

maken van waarden in (lokale) besluiten. De gebruikerstoepassingen Toepasbare regels beheren, Check en Indienen draaien geïntegreerd in

het Digitaal Loket Omgevingswet. De onderdelen werken met elkaar

samen middels goed gedefinieerde koppelvlakken, maar zijn

ontkoppeld. Er worden geen onnodige vragen gesteld, indien mogelijk wordt de benodigde informatie uit een registratie gehaald.


Deelprogramma DSO

9 Bijlage A: Openstaande punten

In deze bijlage worden de nog openstaande punten opgesomd.

Referentie Openstaand Punt Maatregel

1 Onduidelijk is in welke mate wat precies automatisch kan en wat handmatig getest moet worden.

2 Wat de geo analyse functie moet doen is helder. Het is nog niet duidelijk of het een centraal of decentraal component gaat worden.

3 Indien een opgeslagen check of indiening opnieuw gestart wordt moet er aangegeven worden of de onderliggende wet- en regelgeving veranderd is. Het is nog niet duidelijk hoe dat moet werken.

4 Het moet mogelijk worden gemaakt voor BG om zelf bronnen te definiëren waarmee vragen vooringevuld kunnen worden. Het is nog niet duidelijk wat hier precies de grenzen van zijn wat betreft implementatie. Het is ook nog niet duidelijk of dit onderdeel wordt van het toepasbare regels informatiemodel of dat dit een apart koppelvlak wordt.

5 BG is zelf verantwoordelijk voor het testen van eigen regels, echter er is een gemeenschappelijk belang om te borgen dat alle regels aan een samen nader te specificeren maatstaf voldoen. Dit kan het beste uitgevoerd worden door een onafhankelijke organisatie. Hoe dit in te richten is nog een open punt.


Deelprogramma DSO

10 Bijlage B: Bronnen

In deze bijlage worden de voor dit document gebruikte bronnen beschreven.

Referentie Document Omschrijving

1 Peter Visser et al, (2015). Project Digitale Agenda

Omgevingswet. Versie:1.0. Den Haag: Ministerie

van IenM.

Document dat de ‘de Rol van ICT voor

de Omgevingswet’ beschrijft.

2 Jeroen Ekkelenkamp, JE, (2016). DSO – GAS –

Toepasbare Regels Maken. Versie:0.2. Den Haag:

RWS.

DSO – GAS – Toepasbare Regels

Maken

3 Stephen Oostenbrink, SO, (2015). DSO –

Blueprint – Overall GAS. Versie:0.97. Den Haag:

RWS.

Overall GAS

4 Visiedocument Digitalisering Omgevingswet.

Versie 0.9. Den Haag: Ministerie van IenM.

Visiedocument Digitalisering

Omgevingswet

5 Peter Visser, (2015). Doelarchitectuur van het

digitaal stelsel ter ondersteuning van de uitvoering

van de Omgevingswet in 2018. Versie:1.0. Den

Haag: Ministerie van IenM.

Doelarchitectuur van het digitaal

stelsel ter ondersteuning van de

uitvoering van de Omgevingswet in

2018

6 Stephen Oostenbrink, (2015). Globale

Architectuurschets Toepasbare Regels. Versie

0.63. Den Haag: RWS.

Eerste GAS Toepasbare Regels voor

opsplitsing in Maken en Uitvoeren

7 DSO - Architectuur - Notitie - PR12 PR13 -

Ontbreken toepasbare regels. Versie:0.6. Den

Haag: RWS

Notitie die het risico van het ontbreken

van toepasbare regels toelicht.

Globale Architectuur Schets (GAS) · Architectuur (PSA) waar het zwaartepunt verschuift naar de...

Documents

Transcript of Globale Architectuur Schets (GAS) · Architectuur (PSA) waar het zwaartepunt verschuift naar de...