Document D
Ministerie van Infrastructuur en Milieu
Omgevingsloket online 3 - Project Start Architectuur
Versie 1.0
Datum
Status
24 juli 2014
Definitief
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
Colofon
Versie
1.0
Contactpersoon
Paul Leunissen
M 06 - 5250 6691
[email protected]
Ministerie van Infrastructuur en Milieu
Hoofddirectie Financiën, Management en Bedrijfsvoering
Directie Concern Informatievoorziening
Afdeling Architectuur en Informatie Management
Team Architectuur
Koningskade 4
Postbus 20906
2500 EX Den Haag
Auteurs
Paul Leunissen
Peter Visser
Stephen Oostenbrink
Pagina 3 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
Inhoud
1
Inleiding ........................................................................................................... 7
1.1
Identificatie ........................................................................................................................ 7
1.2
Leeswijzer .......................................................................................................................... 7
1.3
Doel van dit document ......................................................................................................... 8
1.4
Referenties ......................................................................................................................... 8
1.5
Afkortingen en begrippen ..................................................................................................... 8
2
Kaders ............................................................................................................. 9
2.1
Ambitie en doelen Olo3 ........................................................................................................ 9
2.2
Gewenste situatie ............................................................................................................... 9
2.3
Architectuurkader ............................................................................................................. 10
2.4
Architectuurkeuzen ........................................................................................................... 10
3
Business architectuur ....................................................................................... 12
3.1
Organisatie ...................................................................................................................... 12
3.2
Diensten en producten ....................................................................................................... 16
3.3
Processen ........................................................................................................................ 18
4
Informatie architectuur ..................................................................................... 22
4.1
Gebruikers en applicaties ................................................................................................... 22
4.2
Berichten en gegevens ...................................................................................................... 30
4.3
Informatie-uitwisseling ...................................................................................................... 33
5
Technische architectuur .................................................................................... 40
5.1
Technische componenten ................................................................................................... 40
5.2
Gegevensopslag ................................................................................................................ 52
5.3
Netwerk ........................................................................................................................... 54
6
Beveiliging en privacy....................................................................................... 56
6.1
Beveiligingsclassificatie ...................................................................................................... 56
6.2
Identity & Access Management (IAM) .................................................................................. 57
6.3
Toegang .......................................................................................................................... 58
6.4
Monitoring, auditing en alerting .......................................................................................... 58
6.5
Compartimentering ........................................................................................................... 59
7
Beheer ........................................................................................................... 62
7.1
Formalisering afspraken ..................................................................................................... 62
7.2
Zelfbediening ................................................................................................................... 63
7.3
Lifecycle management ....................................................................................................... 64
7.4
Zelfbeheer en beheerketen samenwerking ........................................................................... 64
7.5
Service levels ................................................................................................................... 65
7.6
Rapportages ..................................................................................................................... 71
8
Bijlage A: Olo basisplaat ................................................................................... 73
Pagina 5 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
9
Bijlage B: Functioneel componentenmodel Regelbeheer ........................................ 74
10
Bijlage C: Functioneel componentenmodel Loket.................................................. 75
11
Bijlage D: Functioneel componentenmodel Samenwerkingsruimte .......................... 76
12
Bijlage E: Voorbeeld kernbericht opbouw ............................................................ 77
Pagina 6 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
1
Inleiding
1.1
Identificatie
Dit document bevat de Project Start Architectuur (PSA) voor het programma Olo3.
1.2
Leeswijzer
Voor een goed begrip van deze PSA is het noodzakelijk eerst het scope document en
het programma van eisen document te lezen.

In hoofdstuk 2 worden de doelen beschreven waaraan het project Olo3 moet
bijdragen en wordt het gehanteerde architectuurkader kort beschreven.

In hoofdstuk 3 worden de kaders en richtlijnen ten aanzien van de business
architectuur beschreven.

In hoofdstuk 4 worden de kaders en richtlijnen ten aanzien van de informatie
architectuur beschreven.

In hoofdstuk 5 worden de kaders en richtlijnen ten aanzien van de technische
architectuur beschreven.

In hoofdstuk 6 en 7 worden de kaders en richtlijnen ten aanzien van beveiliging
en privacy en beheer beschreven.
Opmerkingen:

Waar in dit document ‘activiteit’ staat mag ‘activiteiten’ worden gelezen en
andersom. Dit geldt ook voor ‘handeling’ en ‘handelingen’. Indien het
noodzakelijk is om specifiek onderscheid te maken tussen activiteit en handeling
wordt dit expliciet vermeld.

In dit document wordt met de afkorting Olo het gehele systeem bedoeld (alle
hoofdfunctionaliteiten).

De voorbeelden in dit document zijn ter verduidelijking en niet limitatief.

In dit document zijn geen architectuurprincipes opgenomen. Vanwege de
leesbaarheid zijn alleen de architectuureisen opgenomen, deze zijn
richtingbepalend voor de realisatie. De architectuureisen zijn een concrete
uitwerking van de architectuurprincipes.

Elke eis is voorzien van een unieke identificatie. De identificatie van de eerste eis
is IA01.1.01. Deze is als volgt opgebouwd ‘IA’: hoofdstuk (IA = informatie
architectuur enz.), ‘01’: volgnummer paragraaf, ‘.1’: volgnummer eisentabel,
‘.01: ‘volgnummer eis.

Achter de identificatie staat een indicatie tussen rechte haken (‘[‘ en ‘]’) die
aangeeft welke partij verantwoordelijk is voor de eis. Dit kunnen één of meerdere
partijen zijn. De volgende indicaties worden gebruikt:


AB = Applicatiebeheer
P
= Project
Pagina 7 van 77

FB RWSL
RWSL
= Functioneel beheer
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
1.3

BG = Bevoegd gezag organisaties

KB = Ketenbeheer

CA = Centraal Aansluitpunt

L = Leverancier

E

SM = Servicemanagement

FB DCI

SP = Standaard Platform

TB = Technisch beheer
= Eigenaar
= Functioneel beheer DCI
Doel van dit document
Het doel van een project start architectuur (PSA) bij het Ministerie van
Infrastructuur en Milieu (IenM) is het project eenduidige, concrete, relevante en
praktisch realiseerbare kaders mee te geven, zodat zeker gesteld wordt dat het
projectresultaat past binnen het grotere geheel van de organisatie.
1.4
Referenties
Dit document is aanvullend op de volgende documenten.
1.5
#
Referentie
Document
1
Scope
Olo3 - Scope - v1.51.docx
2
PvE
Olo3 - Programma van Eisen - v1.0.0.docx
3
Leeswijzer
IenM - Olo3 - Architectuurdocumenten leeswijzer - v1.0.docx
4
Componenten
IenM - Olo3 - Toelichting componenten - v1.0.docx
5
SGA
IMEA - Katern - Service Gerichte Architectuur - v1.0.docx
6
SP
IMEA - Katern - Standaard Platform - v1.0.docx
7
Koppelingen
IenM - ESB Koppelingen - Eisen - v1.0.docx
8
Aansluitvoorwaarden
IenM - Standaard Platform - Aansluitvoorwaarden Applicaties
en Componenten - v1.0.docx
9
Afkortingen en
begrippen
IenM - Standaard Platform - Afkortingen en begrippen v1.0.docx
10
BNB
IenM - Beheerst naar Beheer - v1.0.docx
Afkortingen en begrippen
Zie voor een toelichting van de gehanteerde afkortingen en begrippen het
[Afkortingen en begrippen] document.
Pagina 8 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
2
Kaders
Dit hoofdstuk gaat in op de ambitie en doelen van het programma Olo3 en de
gewenste situatie die met Olo moet worden bereikt. Vervolgens wordt het
gehanteerde architectuurkader kort beschreven.
2.1
Ambitie en doelen Olo3
Zie het [Scope] document.
2.2
Gewenste situatie
In de volgende opsomming worden enkele belangrijke zaken benoemd die met Olo
bereikt moeten worden.

Breed inzetbaar
Door de gekozen opzet is het systeem geschikt voor de Wet algemene bepalingen
omgevingswet (Wabo) en Waterwet en voorbereid op de toekomstige
Omgevingswet.

Laagdrempelig regelbeheer
Dit betreft het analyseren, modelleren en beheren van wet- en regelgeving
teksten en de vertaling daarvan naar beslisbomen en formulieren. Een
functioneel beheerder kan zelf snel en eenvoudig de verschillende regelbeheer
onderdelen toevoegen, aanpassen, testen en publiceren. De beheerfunctionaliteit
voor formulieren maakt gebruik van een webgebaseerde WYSIWYG editor die
door alle gangbare browsers wordt ondersteund en zonder plug-ins te gebruiken
is.

Wendbaarheid en flexibiliteit
De inhoud en de werking van het Loket moet kunnen worden aangepast zonder
dat de software hoeft te worden aangepast. Dit houdt in dat project, projectdefinitie, activiteit, werkzaamheid, beslisbomen en formulieren als configuraties
worden beschouwd. Beheer en uitvoering (executie) van deze configuraties zijn
gescheiden.

Hergebruik reeds bekende informatie
Door te koppelen met registraties en andere e-overheid bouwstenen is het
mogelijk om reeds bekende gegevens voor in te vullen. Dit leidt tot verbetering
van gebruiksgemak en leidt tot verbetering van de datakwaliteit. Hiermee wordt
voldaan aan de wet op eenmalige gegevensuitvraag.

Geauthentiseerd gebruik
DigiD en eHerkenning of eID, de opvolger hiervan, worden gebruikt om
gebruikers te identificeren en authentiseren.

Tijd- en kostenbesparing
Door een beheervriendelijke opzet waarbij beheer snel en eenvoudig uit te
voeren is zonder programmeren, kan beheer uitgevoerd worden door functionele
Pagina 9 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
beheerders. Dit leidt tot een wendbaar en flexibel systeem en het bespaart tijd
en geld.

Herbruikbaar
Geen maatwerk, maar gebaseerd op bestaande componenten of softwareproducten. Hierbij heeft IenM een sterke voorkeur voor open source, zodat inzet
binnen IenM en hergebruik binnen de overheid laagdrempelig is. Daarnaast zijn
investeringen die gedaan worden in het verbeteren van open source producten
voor iedereen zonder licentiekosten beschikbaar.
2.3
Architectuurkader
Uitgangspunt voor de keuzen in deze PSA is het architectuurkader van het ministerie
van Infrastructuur en Milieu, de Infrastructuur en Milieu Enterprise Architectuur
(IMEA). IMEA hanteert het 9+2 vlaks architectuurraamwerk van NORA. De
uitwerking in deze PSA volgt dit raamwerk.
Figuur 1. NORA 9+2 vlaks architectuurraamwerk
2.4
Architectuurkeuzen
De volgende architectuurkeuzen zijn gemaakt:

IenM kiest voor applicaties met een beperkte omvang en complexiteit zodat het
ontwikkelen, beheren en onderhouden overzichtelijker en eenvoudiger wordt.
Pagina 10 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0

IenM kiest voor flexibiliteit door het kunnen aanpassen van de werking van de
applicaties door middel van configuratie zonder de software aan te hoeven
passen, om zo flexibel met huidige en toekomstige wensen om te kunnen gaan.

IenM kiest voor het zoveel mogelijk gebruik maken van herbruikbare
componenten. Olo maakt enerzijds gebruik van beschikbare herbruikbare
componenten en zorgt anderzijds voor het toevoegen van nieuwe herbruikbare
componenten.
Pagina 11 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
3
Business architectuur
In dit hoofdstuk wordt de business architectuur beschreven voor zover die van
belang is voor de positie en rol van Olo. Het is een beschrijving in brede zin, dat wil
zeggen onafhankelijk van de te kiezen oplossing. In de bedrijfsarchitectuur wordt
antwoord gegeven op de vragen:
3.1

Wie zijn betrokken?

Wat zijn de diensten en producten?

Hoe verlopen de processen?
Organisatie
Binnen een beleidsdomein worden zeven taken onderscheiden: wet- en rijksregelgeving, beleidsplanning en decentrale regelgeving, uitvoering, toezicht, handhaving,
vervolging en rechtspraak. In de volgende afbeelding zijn deze taken en hun
samenhang weergegeven.
Wet- en rijksregelgeving
Beleidsplanning
en decentrale
regelgeving
Uitvoering
Toezicht
Handhaving
Vervolging
Rechtspraak
Figuur 2. De zeven taken en hun samenhang
Toelichting op de weergegeven taken:

Wet- en rijksregelgeving: het voorstellen van en besluiten over wijziging van
bestaande en nieuwe wetten, algemene maatregelen van bestuur (AMvB’s) en
ministeriële regelingen.

Beleidsplanning en decentrale regelgeving: het voorstellen van en besluiten over
wijziging van bestaande en nieuwe visies, plannen, programma’s en regelgeving,
zoals verordeningen van provincies, gemeenten en waterschappen.

Uitvoering: het opvolgen van wet- en regelgeving en beleidsplanning
voorafgaand aan en bij het uitvoeren van activiteiten door burgers1, bedrijven2
en overheden3.

Toezicht: het verzamelen van informatie over de vraag of een handeling of zaak
voldoet aan de gestelde eisen.
1. Personen woonachtig in Nederland of in het buitenland.
2. Ondernemingen gevestigd in Nederland of in het buitenland, als ook stichtingen, verenigingen en
overheidsorganisaties (die voor eigen activiteiten aanvragen en meldingen indienen).
3. Overheidsorganisaties die betrokken zijn bij het besluiten over ingediende aanvragen en meldingen.
Pagina 12 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0

Handhaving: de keten van activiteiten gericht op het (alsnog) laten voldoen van
een handeling of zaak aan de gestelde eisen.

Vervolging: het instellen van strafrechtelijk onderzoek en het voor de rechter
brengen van de resultaten van onderzoek.

3.1.1
Rechtspraak: het geven van een oordeel over een rechtszaak.
Wabo en Waterwet
Het beleidsdomein van de fysieke leefomgeving is toebedeeld aan IenM. Daarnaast
is het ook, maar dan voor eigen beleidsruimte en ambtsgebied, toebedeeld aan
andere ministeries, de provincies, gemeenten en waterschappen. Voor het sturen
van activiteiten in de fysieke leefomgeving heeft IenM er in de Wet algemene
bepalingen omgevingsrecht (Wabo) en de Waterwet voor gekozen om voor de
uitvoering gebruik te maken van algemene regels, vergunningen en meldingen.
3.1.2
Betrokken partijen
Figuur 3. Bij Olo betrokken partijen
Pagina 13 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
3.1.2.1
Ministerie van Infrastructuur en Milieu (IenM)
IenM is betrokken omdat in de Wabo en de Waterwet staat dat de minister zorgt
voor een voorziening voor het digitaal indienen van vergunningaanvragen en
meldingen. Ter invulling hiervan heeft IenM Omgevingsloket online (Olo) ontwikkeld.
Met Olo3 wordt de stap gemaakt naar een modulaire opzet, die eenvoudig
aanpasbaar is. Hiermee wordt Olo voorbereid op de toekomstige Omgevingswet.
De minister van IenM is politiek verantwoordelijk voor Olo en dat deze op de juiste
manier is ingericht en werkt.
Binnen IenM is DG Ruimte en Water verantwoordelijk voor de strategische
aansturing van Olo. In overleg met de domeineigenaren worden de doorontwikkeling
en de eisen die dat stelt aan Olo afgestemd.
3.1.2.2
RWS Leefomgeving
De tactische en operationele aansturing van Olo is belegd bij RWS. RWS
Leefomgeving (RWSL) is verantwoordelijk voor de functionele inrichting en werking
van Olo en ondersteuning van gebruikers.
3.1.2.3
Ministerie van Binnenlandse Zaken (BZK)
De minister van BZK is verantwoordelijk voor het Bouwbesluit en Besluit brandveilig
gebruik en betrokken bij Olo omdat deze rijksregelgeving onder de Wabo valt.
3.1.2.4
Ministerie van Economische Zaken (EZ)
De minister van EZ is verantwoordelijk voor de Flora en Faunawet en
Natuurbeschermingswet en betrokken bij Olo omdat deze rijksregelgeving onder de
Wabo valt.
3.1.2.5
Ministerie van Onderwijs, Cultuur en Wetenschap (OCW)
De minister van OCW is verantwoordelijk voor de Monumentenwet en betrokken bij
Olo omdat deze rijksregelgeving onder de Wabo valt.
3.1.2.6
Burgers en bedrijven
Burgers en bedrijven zijn betrokken omdat zij Omgevingsloket online mogen
gebruiken voor het digitaal (laten) indienen van vergunningaanvragen en
meldingen. In de volgende afbeelding is het indienen van aanvragen en meldingen
door burgers en bedrijven weergegeven.
Pagina 14 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
3.1.2.7
Bevoegd gezag
Wet- en rijksregelgeving
Beleidsplanning
en decentrale
regelgeving
Uitvoering
Toezicht
Handhaving
Vervolging
Rechtspraak
Aanvraag
Melding
Figuur 4. Het indienen van aanvragen en meldingen door burgers en bedrijven
Gemeenten, waterschappen, provincies, Rijkswaterstaat en ministeries zijn
betrokken omdat in de Wabo en de Waterwet staat dat zij de voor hen bestemde,
via Omgevingsloket online ingediende, vergunningaanvragen en meldingen moeten
ontvangen en daarover moeten besluiten.
Vergunning- en meldingplichten worden bepaald in de Wabo en Waterwet en kunnen
in bepaalde gevallen ook worden bepaald in decentrale regelgeving. Bevoegd gezag
organisaties die bevoegd zijn vergunning- en meldingplichten in te stellen moeten
de daaruit voortvloeiende beslisbomen en aanvraagformulieren toevoegen aan Olo.
3.1.3
Eisen organisatie
ID
Eis
BA01.1.01
[E]
IenM houdt rekening met de digitale volwassenheid van de overheidsorganisaties die moeten aansluiten op Olo en zorgt dat er meerdere opties zijn
om aan te sluiten op en gebruik te maken van Olo.
BA01.1.02
[BG]
Bevoegd gezag organisaties die vergunning- en meldingplichten instellen
moeten de eigen beslisbomen en formulieren toevoegen aan Olo.
BA01.1.03
[BG]
Bevoegd gezag organisaties kunnen de eigen beslisbomen en formulieren
toevoegen in Olo vanuit een eigen beheerapplicatie. Daarnaast biedt IenM de
optie gebruik te maken van Olo Regelbeheer voor het beheren van lokale
beslisbomen en formulieren.
BA01.1.04
[L]
De beheerfunctionaliteit van de beslisboom en formulier moet eenvoudig in
gebruik zijn.
BA01.1.05
[E]
IenM toetst of beslisbomen en formulieren die bevoegd gezag organisaties
willen (laten) toevoegen in Olo voldoen aan de gemaakte afspraken over stijl,
begrijpelijkheid en consistentie e.d. Daarnaast toetst IenM of de beslisbomen
en formulieren correct werken.
BA01.1.06
[E]
IenM is verantwoordelijk voor het in gebruik nemen, ook wel aangeduid als
publiceren naar productie, van zowel landelijke als decentrale beslisbomen en
formulieren.
Pagina 15 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
3.2
Diensten en producten
3.2.1
Diensten
Om de uitvoering door burgers, bedrijven en overheden te ondersteunen biedt IenM
hen de volgende digitale diensten:
1. Bepalen vergunning- en meldingplicht Wabo en Waterwet.
2. Indienen aanvragen en meldingen Wabo en Waterwet.
3. Samen werken aan besluiten.
4. Beheren beslisbomen en formulieren.
In de volgende afbeelding zijn de diensten en hun positionering in het beleidsdomein
weergegeven.
Figuur 5. De diensten en hun positionering in het beleidsdomein
3.2.1.1
Motivering dienstenaanbod

Met de diensten ’bepalen vergunning- en meldingplicht Wabo en Waterwet’ en
‘indienen aanvragen en meldingen Wabo en Waterwet’ zorgt IenM voor een
voorziening voor het uitvoeren van vergunningchecks en het digitaal indienen
van vergunningaanvragen en meldingen.

Met de dienst ‘samen werken aan besluiten’ zorgt IenM voor een voorziening
voor het ontvangen van digitaal ingediende vergunningaanvragen en meldingen
en voor het gedurende de behandeling uitwisselen van informatie tussen de bij
de behandeling betrokken organisaties.
NB: De digitale ondersteuning van het daadwerkelijk behandelen is een zaak van
de betrokken overheidsorganisaties zelf en vindt in hun eigen systemen plaats.

Met de dienst ‘beheren beslisbomen en formulieren’ zorgt IenM voor een
voorziening voor het beheren van beslisbomen, aanvraag- en meldingformulieren. Bevoegd gezag organisaties kunnen voor het beheren gebruik
maken van deze IenM dienst of van een eigen regelbeheerapplicatie.
Pagina 16 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
3.2.2
Producten
3.2.2.1
Bepalen vergunning- en meldingplicht Wabo en Waterwet
Burgers en bedrijven kunnen met behulp van de dienst ‘bepalen vergunning- en
meldingplicht Wabo en Waterwet’ nagaan (checken) of op basis van de Wabo en de
Waterwet een vergunningaanvraag of melding nodig is en, als dat het geval is,
welke bijlagen bijgevoegd moeten worden.
Deze dienst levert de volgende digitale producten:

Uitkomst vergunningcheck: document met alle tijdens het checken beantwoorde
vragen en de daarop gebaseerde conclusie of en voor welke activiteiten in de
fysieke leefomgeving een vergunningaanvraag of melding nodig is.

Uitkomst bijlagencheck: document met alle in een bijlagencheck beantwoorde
vragen en de daarop gebaseerde conclusie welke bijlagen nodig zijn.
3.2.2.2
Indienen aanvragen en meldingen Wabo en Waterwet
Burgers en bedrijven kunnen met behulp van de dienst ‘indienen aanvragen en
meldingen Wabo en Waterwet’ een vergunningaanvraag en melding digitaal
opstellen en indienen.
Deze dienst levert de volgende digitale producten:

Vergunningaanvraag: verzoek om toestemming om voorgenomen activiteiten in
de fysieke leefomgeving te mogen uitvoeren bestaande uit een ingevuld
aanvraagformulier met bijlagen.

Melding: melding activiteiten in de fysieke leefomgeving te gaan uitvoeren
bestaande uit een ingevuld meldingformulier met bijlagen.
3.2.2.3
Samen werken aan besluiten
Overheden kunnen met behulp van de dienst ‘samen werken aan besluiten’ digitaal
ingediende vergunningaanvragen en meldingen ontvangen en gedurende de
behandeling informatie met elkaar uitwisselen.
Deze dienst levert de volgende digitale producten:

Vergunningaanvraagdossier: ingediende aanvraag bestaande uit een ingevuld
aanvraagformulier met bijlagen en (advies)documenten die tijdens de
behandeling zijn opgesteld.

Meldingdossier: ingediende melding bestaande uit een ingevuld meldingformulier
met bijlagen.
3.2.2.4
Beheren beslisbomen en formulieren
Bevoegd gezagorganisaties kunnen met behulp van de dienst ‘beheren beslisbomen
en formulieren’ de eigen beslisbomen, aanvraag- en meldingformulieren beheren.
Pagina 17 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
Deze dienst levert de volgende digitale producten:

Toepasbare beslisbomen: bestand met content, relaties en regels voor toepassing
als vergunning- en bijlagencheck.

Toepasbare formulieren: bestand met content, relaties en regels voor toepassing
als aanvraag- en meldingformulieren.
3.2.3
Eisen diensten en producten
ID
Eis
BA02.1.01
[E]
Olo ondersteunt de diensten ‘bepalen vergunning- en meldingplicht Wabo en
Waterwet’, ‘indienen aanvragen en meldingen Wabo en Waterwet’, ‘samen
werken aan besluiten’ en ‘beheren beslisbomen en formulieren’.
BA02.1.02
[E]
Olo levert de producten ‘uitkomst vergunningcheck’, ‘uitkomst bijlagencheck’,
‘vergunningaanvraag’, ‘melding’, vergunningaanvraagdossier’, ‘meldingdossier’,
‘toepasbare beslisbomen’ en ‘toepasbare formulieren’.
BA02.1.03
[E]
De dienst ‘samen werken aan besluiten’ is bedoeld voor het ontvangen en
routeren van digitaal ingediende vergunningaanvragen en meldingen, en het
gedurende de behandeling uitwisselen van informatie tussen de bij de
behandeling betrokken organisaties.
BA02.1.04
[E]
De diensten ‘samenwerken aan besluiten’ en ‘beheren beslisbomen en
formulieren’ zijn diensten die overgedragen moeten kunnen worden aan een
derde partij.
3.3
Processen
3.3.1
Processen op hoofdlijnen
Voor het bepalen van de scope is uitgegaan van het proces dat burgers en bedrijven
doorlopen vanaf een idee of initiatief tot aan het daadwerkelijk realiseren en
gebruiken. De stappen aan de kant van burgers en bedrijven zijn: initiatief,
ontwerp, realisatie en gebruik, en aan de kant van de overheid: behandeling,
toezicht en handhaving. In de volgende afbeelding zijn de processen en de stappen
weergegeven.
Figuur 6. De processen en de stappen
Toelichting op de weergegeven stappen:

Initiatief: verkennen en aftasten van mogelijkheden en onmogelijkheden voor
een gewenste of benodigde verandering.
Pagina 18 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0

Ontwerp: uitwerken en regelen van benodigde zaken zoals het invullen van
vergunningaanvraag of melding. Deze stap wordt afgesloten met het indienen
van de aanvraag of melding.

Realisatie: uitvoeren van de gewenste of benodigde veranderingen.

Gebruik: benutten waarvoor iets bedoeld of veranderd is.

Behandeling: beoordelen van een ingediende vergunningaanvraag. Deze stap
wordt afgesloten met een besluit.

Toezicht en handhaving: volgen en beoordelen of de realisatie en het gebruik
volgens de regels en gestelde eisen gebeurt en zo nodig corrigeren.
3.3.2
Te ondersteunen processtappen
Burgers en bedrijven worden ondersteund bij de volgende processtappen:

Initiatief

Ontwerp

Realisatie, echter beperkt tot het gedurende de realisatie kunnen verstrekken
van de vereiste informatie.
Organisaties worden ondersteund bij de volgende processtappen:

Behandeling, echter beperkt tot het ontvangen van digitaal ingediende
vergunningaanvragen en meldingen en het gedurende de behandeling met
andere betrokken organisaties uitwisselen van informatie.

Toezicht en handhaving, echter beperkt tot het gedurende de realisatie kunnen
ontvangen van de vereiste informatie.
3.3.3
Regelbeheer proces
In het regelbeheer proces worden wet- en regelgeving teksten omgezet naar in Olo
toepasbare beslisbomen en formulieren. De stappen zijn: verwerken teksten,
analyseren, modelleren, toepasbaar maken en publiceren.
In de volgende afbeelding zijn het regelbeheer proces en de stappen weergegeven.
Van wet naar loket
Verwerken
teksten
Analyseren
Modelleren
Toepasbaar
maken
Publiceren
Eenduidige tekst
Juridisch model
Logisch model
Toepasbare informatie
Dataset
Processtap
Flow
Loket
Export / import
Resultaat
Figuur 7. Het regelbeheer proces en de stappen
Toelichting op de weergegeven stappen:

Verwerken teksten: importeren van teksten in een eenduidige structuur.

Analyseren: filteren van de logica uit teksten, zoals relevante begrippen, hun
kenmerken, relaties tussen begrippen en restricties (beslis- en rekenregels).

Modelleren: kantelen van de logica van tekst gebaseerd naar objectgericht.
Pagina 19 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0

Toepasbaar maken: omzetten van de logica naar de vorm die nodig is voor de
gewenste toepassing, zoals een beslisboom of formulier.

3.3.4
Publiceren: klaar zetten van een bestand in toepasbare vorm.
Lokale regelgeving
Naast het Rijk hebben ook decentrale overheden zoals gemeenten, waterschappen
en provincies eigen regelgeving (verordeningen) die een plaats moet krijgen in het
Loket. Decentrale beslisbomen en formulieren kunnen door bevoegd gezag
organisaties worden beheerd met een eigen of met de Olo Regelbeheer applicatie.
Het publiceren naar het Olo Loket gaat in beide gevallen via hetzelfde
gestandaardiseerde koppelvlak. In de volgende afbeelding is de keuze tussen
werken met een eigen of met de Olo regelbeheer applicatie weergegeven.
Van wet naar loket
Verwerken
teksten
Analyseren
Modelleren
Toepasbaar
maken
Decentrale
regelgeving
Processtap
Flow
Publiceren
Loket
Toepasbaar
maken
Publiceren
Export / import
Figuur 8. Aanleveren configuraties vanuit verschillende bronnen
3.3.5
Communicatie in de keten
Bij het indienen van een (concept-) vergunningaanvraag of melding wordt een uniek
Olo-nummer gegenereerd. Dit unieke nummer identificeert de vergunningaanvraag
of melding in de keten. Dit nummer wordt door Olo aan de aanvrager doorgegeven.
3.3.6
Eisen processen
ID
Eis
BA03.3.01
[E]
Olo ondersteunt burgers en bedrijven bij de stappen ‘initiatief’, ‘ontwerp’ en
‘realisatie’. De stap ‘realisatie’ is beperkt tot het kunnen verstrekken van de
benodigde informatie.
BA03.3.02
[E]
Olo ondersteunt organisaties bij de stappen ‘behandeling’ en ‘toezicht en
handhaving’. De stap ‘behandeling’ is beperkt tot het kunnen ontvangen en met
elkaar kunnen uitwisselen van informatie. De stap ‘toezicht en handhaving’ is
beperkt tot het gedurende ‘realisatie’ kunnen ontvangen van informatie.
BA03.3.03
[E]
Olo ondersteunt de regelbeheer processtappen ‘verwerken teksten’, ‘analyseren’,
‘modelleren’, ‘toepasbaar maken’ en ‘publiceren’.
BA03.3.04
[E]
Elke vergunningaanvraag en melding heeft een uniek Olo-nummer. Bij
communicatie in de keten wordt dit Olo-nummer gebruikt. Het Olo-nummer
identificeert de vergunningaanvraag en melding in de keten. Het Olo-nummer
wordt door Olo gegenereerd en aan de aanvrager doorgegeven.
Pagina 20 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
BA03.3.05
[BG]
De Bevoegd gezag organisatie is verantwoordelijk voor het communiceren van
de status van de behandeling naar de aanvrager via bestaande e-overheid
voorzieningen. Daarbij wordt het Olo-nummer meegegeven.
Pagina 21 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
4
Informatie architectuur
In dit hoofdstuk wordt de informatiearchitectuur beschreven. Deze is bepalend voor
de te kiezen technische oplossingen. Het is een beschrijving in brede zin, dat wil
zeggen onafhankelijk van de te kiezen technische oplossingen. In de informatiearchitectuur wordt antwoord gegeven op de vragen:

Wie zijn de uitvoerders?

Wat zijn de gegevens en berichten?

Hoe verloopt de informatie-uitwisseling?
4.1
Gebruikers en applicaties
4.1.1
Gebruikers
Onderstaande afbeelding geeft een overzicht van de verschillende gebruikers die Olo
kent. De afbeelding geeft tevens de Olo applicaties en externe systemen in de
omgeving van Olo weer.
Figuur 9. Olo basisplaat (zie hoofdstuk 8 voor een vergrote versie)
Pagina 22 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
Zie voor een toelichting op de weergegeven gebruikers de documenten [PvE] en
[Begrippenlijst].
4.1.2
Applicaties
Ter vervanging van het huidige Olo moeten er drie nieuwe eindgebruiker applicaties
komen, te weten Regelbeheer, Loket en Samenwerkingsruimte. In de volgende
afbeelding zijn de applicaties en hun business functies weergegeven. Een business
functie is een component met een voor de business begrijpelijke naam en
begrijpbare taak. Om deze taak te vervullen wordt gebruik gemaakt van functionele
componenten (zie 4.1.2.5 Functionele componenten).
Figuur 10. De applicaties en hun business functies
Elke applicatie heeft een eigen ‘gebruikersinterface’ voor het presenteren van de
applicatie aan de gebruiker en een eigen ‘beheerinterface’ voor het kunnen doen wat
nodig is voor een goede werking van de applicatie. Hierna volgt een toelichting op
de weergegeven applicaties en hun business functies.
4.1.2.1
Regelbeheer
Regelbeheer is een applicatie voor het omzetten van wet- en regelgeving in een
configuratie die in het Loket toepasbaar is.
Business functies
De specifieke business functies zijn wet- en regelgeving, beslisbomen en
formulieren:

Wet- en regelgeving voor het formatteren van de teksten die toepasbaar moeten
worden gemaakt voor het Loket.

Beslisbomen voor het toepasbaar maken van teksten als beslisbomen. Een
beslisboom levert een beslissing op, ook wel aangeduid als conclusie of indicatie.
Een beslisboom bestaat uit vragen en logica om de antwoorden te interpreteren
en de vervolgvraag of een conclusie of indicatie te bepalen. Antwoorden moeten,
naast eenvoudige meerkeuze antwoorden (ja/nee), om kunnen gaan met
Pagina 23 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
uitgebreide meerkeuze antwoorden en getallen. De logica moet de verschillende
typen antwoorden kunnen interpreteren.

Formulieren voor het toepasbaar maken van teksten als formulieren. Gegevens
met betrekking tot een vergunningaanvraag en melding worden verzameld met
behulp van formulieren. Een formulier is het geheel van vragen en antwoorden
dat door de gebruiker ingevuld moet worden. Afhankelijk van de antwoorden die
gegeven worden bij het invullen van een formulier past het formulier zich aan,
waardoor er meer of minder gegevens ingevuld moeten worden.
4.1.2.2
Loket
Het Loket is een applicatie voor het checken van plichten en bijlagen en voor het
opstellen en indienen van vergunningaanvragen en meldingen. De werking van het
Loket is aan te passen door middel van configuratie. Het Loket voert beslisbomen en
formulieren uit.
Business functies
De specifieke business functies zijn Vergunningcheck, Bijlagencheck, Aanvraag/
Melden en Projectdossier:

Vergunningcheck voor het nagaan of een vergunningaanvraag of melding nodig
is. Hiervoor wordt gebruik gemaakt van beslisbomen.

Bijlagencheck om te bepalen welke bijlagen nodig zijn. Hiervoor wordt gebruik
gemaakt van beslisbomen.

Aanvraag/Melden voor het invullen van formulieren, het bijvoegen van bijlagen
en het indienen van vergunningaanvragen of meldingen. Na het indienen kunnen
aanvullingen op formulieren worden gedaan en documenten worden toegevoegd.

Projectdossier voor het opslaan van checks, vergunningaanvragen en meldingen
en anderen daar toegang toe kunnen geven.
4.1.2.3
Samenwerkingsruimte
De Samenwerkingsruimte is een applicatie voor het ontvangen, opslaan en
uitwisselen van ingediende aanvragen, meldingen en adviesdocumenten en anderen
hier toegang toe kunnen geven.
Business functies
De specifieke business functies zijn Aanvragen/Meldingen en Werkdossier:

Aanvragen/Meldingen voor het opslaan van ingediende vergunningaanvragen en
meldingen.

Werkdossier om anderen toegang te geven tot opgeslagen vergunningaanvragen
en meldingen. Het is ook mogelijk om documenten toe te voegen die voor het
behandelen nodig zijn.
Deze opdeling in business functies is gekozen zodat het in de toekomst mogelijk is
om toezichthouders en handhavers toegang te geven tot ingediende aanvragen en
meldingen.
Pagina 24 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
4.1.2.4
Service gerichte architectuur
Olo en de (herbruikbare) componenten waar Olo gebruik van maakt zijn opgezet op
basis van Service Gerichte Architectuur (SGA) principes en voldoen aan de SGA
zoals IenM die toepast en beschreven is in de documenten:
4.1.2.5

IMEA Katern Service Gerichte Architectuur [SGA]

IenM ESB Koppelingen Eisen [Koppelingen]
Functionele componenten
Olo bestaat uit specifieke en herbruikbare functionaliteiten. De business functies zijn
specifiek en functionele componenten zijn herbruikbaar.
Figuur 11. Functionele componenten realiseren business functies
In bovenstaande afbeelding zijn alle functionele componenten, ook wel herbruikbare
bouwstenen genoemd, weergegeven die nodig zijn voor het realiseren van de drie
applicaties. In het bovenste gedeelte van de afbeelding zijn de interactiekanalen
Pagina 25 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
weergegeven waarmee interactie is met de applicaties. In het middelste deel worden
de applicaties met al hun business functies weergegeven. In het onderste deel zijn
de functionele componenten weergegeven. Zie voor een toelichting op de functionele
componenten het [Componenten] document. In hoofdstuk 5 Technische architectuur
wordt dezelfde afbeelding gebruikt voor de doorvertaling van functionele naar
technische componenten. In het technische componentenmodel is aangegeven
welke componenten (reeds) beschikbaar zijn (Herbruikbaar en Herbruikbaar DCI) en
welke componenten door de leverancier van Olo3 als onderdeel van Olo opgeleverd
dienen te worden (Herbruikbaar Olo3).
NB: Figuur 11 is een weergave van de Olo3 specifieke functies en het herbruikbare
IenM componentenmodel. In de bijlagen B, C en D is dit herbruikbare
componentenmodel specifiek gemaakt voor de Olo applicaties (Regelbeheer, Loket
en Samenwerkingsruimte). Per Olo applicatie is expliciet gemaakt van welke
functionele componenten het gebruik verplicht is.
Een interactiekanaal is een manier waarop gebruikers kunnen werken met Olo
applicaties. Olo biedt zelf applicaties aan die via de verschillende interactiekanalen
te gebruiken zijn. Daarnaast kunnen andere partijen eigen applicaties ontwikkelen
(systeem derden) die functionaliteit van Olo ontsluit door gebruik te maken van Olo
services. Ongeacht of een gebruiker werkt met Olo via Olo applicaties of via Olo
services is het resultaat hetzelfde. Een consequentie hiervan is dat het niet toegestaan is om Olo business logica in de presentatielaag op te nemen. Olo applicaties
maken gebruik van dezelfde Olo services als organisaties die hun systemen
koppelen aan Olo.
Een groot deel van de voor Olo vereiste functionaliteit is niet Olo specifiek, maar
bestaat uit functionaliteiten die in andere IenM oplossingen te herkennen zijn. Deze
functionaliteiten worden gerealiseerd met herbruikbare functionele componenten
(bouwstenen). IenM is de beweging aan het maken naar herbruikbare functionele
componenten die IenM breed inzetbaar zijn. Dit betekent dat Olo enerzijds
beschikbare herbruikbare functionele componenten kan hergebruiken en anderzijds
nieuwe functionele componenten als herbruikbare componenten oplevert, die weer
ingezet kunnen worden voor andere applicaties.
Een business functie maakt gebruik van een of meer functionele componenten
(bouwblokken). De business functies zijn gespecialiseerd in een bepaalde taak of
functie en afgestemd op het proces waar ze toegepast worden. Functionele
componenten bepalen de afbakening van componenten en zijn herbruikbaar. Voor
herbruikbare componenten hanteert IenM het principe: ‘hergebruiken voor kopen
voor bouwen’. Waar componenten nog niet beschikbaar zijn (zie paragraaf 5.1),
wordt zowel binnen als buiten de IenM organisatie gekeken naar mogelijk te
hergebruiken componenten. Eventuele benodigde nieuwe functionaliteit wordt
opgenomen in een bestaande functionele component. Als dat niet mogelijk of
wenselijk is, moet de extra functionaliteit met een nieuwe herbruikbare component
gerealiseerd worden.
Pagina 26 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
De afbeelding geeft de functionele componenten weer zoals die nu voorzien worden.
In de offerte of specificatiefase kan blijken dat er andere functionele componenten
nodig zijn of een andere indeling van functionele componenten. Deze wijzigingen
worden uiteraard alleen na overleg en akkoord van de IenM architecten
doorgevoerd.
4.1.3
Flexibiliteit en wendbaarheid
De basis van Regelbeheer en Loket is de wet- en regelgeving (Wabo en Waterwet).
Het toepasbaar maken van deze wet- en regelgeving en de flexibiliteit en wendbaarheid die nodig is om dit in te richten en deze inrichting snel aan te kunnen passen
aan gewijzigde en nieuwe situaties is bepalend voor het succes van Olo. Voor de
begrijpelijkheid en gebruiksvriendelijkheid van het Loket is het belangrijk dat het
systeem zich aanpast aan de situatie (context) van de aanvrager. Dit betekent o.a.
dat vragen die niet relevant zijn niet gesteld worden en vragen die meerdere keren
voorkomen maar één keer gesteld worden.
Om deze flexibiliteit te bereiken wordt een aantal belangrijke mechanismen ingezet:
beslisbomen, formulieren en ordeningsmechanismen. Deze ordeningsmechanismen
maken op hun beurt gebruik van beslisbomen en formulieren:

Beslisbomen worden gebruikt voor het bepalen van de vergunning- en
meldingsplicht en het bepalen van vereiste bijlagen.

Formulieren worden gebruikt voor het verzamelen van gegevens voor de
aanvraag en/of melding.

Ordeningsmechanismen:

Project

Projectdefinitie

Activiteit

Werkzaamheid

Bericht
In de volgende afbeelding komen alle bovengenoemde elementen samen.
Pagina 27 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
Figuur 12. Mechanismen om flexibiliteit en wendbaarheid te bereiken
Deze elementen zijn in verschillende fasen inzetbaar. Er worden twee fases onderscheiden. Een initiatieffase waarin de aanvrager (anoniem) kan toetsen of er een
vergunning- of meldingsplicht is. Een ontwerpfase waarin de aanvrager aanvragen
opstelt en indient. In de initiatieffase ingevulde gegevens kunnen overgenomen
worden naar de ontwerpfase. De initiatieffase is optioneel en kan overgeslagen
worden.
Door gebruik te maken van de ordeningsmechanismen (ofwel logische eenheden),
formulieren en beslisbomen is de werking van het systeem eenvoudig aan te
passen.
4.1.4
Eisen applicaties
De volgende eisen gelden voor de drie applicaties.
ID
Eis
IA01.1.01
Elke applicatie is geheel zelfstandig, moet onafhankelijk van andere applicaties
Pagina 28 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
4.1.5
[L]
kunnen werken en kent een eigen ontwikkel- en beheercyclus.
IA01.1.02
[L]
Elke applicatie heeft een eigen gebruikersinterface waarmee de functionaliteit
wordt aangeboden aan eindgebruikers.
IA01.1.03
[L]
Elke applicatie controleert of alle verplichte informatie ingevuld en geldig is,
voordat deze wordt aangeboden aan een component. Dit zorgt voor een optimale
gebruikerservaring en voorkomt heen en weer pingpongen met de gebruikte
componenten.
IA01.1.04
[L]
Elke applicatie heeft een eigen beheerinterface waarin de beheerder alles kan
doen en instellen wat voor de werking van de applicatie nodig is.
IA01.1.05
[L]
Elke applicatie moet in zijn geheel kunnen worden overgedragen aan een andere
eigenaar, kunnen worden overgezet naar een andere omgeving of kunnen
worden vervangen zonder dat de werking van de functionaliteit voor afnemende
applicaties daardoor wijzigt.
IA01.1.06
[L]
Hetzelfde product en leverancier neutraal koppelvlak dat de applicatie gebruikt,
wordt ook aangeboden aan andere systemen. Hiermee is de functionaliteit van
de applicatie beschikbaar voor andere applicaties.
Aanvullende eisen service gerichte architectuur
De volgende eisen zijn aanvullend op de eisen in de twee in paragraaf 4.1.2.4
genoemde documenten.
4.1.6
ID
Eis
IA01.2.01
[L]
Een applicatie is samengesteld uit services van een of meer business functies
en een business functie is samengesteld uit services van een of meer
functionele componenten.
IA01.2.02
[L]
Services kennen een eigen ontwikkel- en beheercyclus. Ze worden zelfstandig
ontwikkeld en kunnen onafhankelijk van elkaar en de applicaties uitgerold en
getest worden.
IA01.2.03
[L]
Business functies en functionele componenten hebben voor beheer een eigen
gebruikersinterface en webservices waarmee deze beheerfunctionaliteit naar
afnemende applicaties wordt ontsloten. Afnemende applicaties kunnen via de
beheer webservices direct interacteren met deze componenten. Hierbij hebben
afnemende applicaties alleen toegang tot de eigen data en instellingen.
IA01.2.04
[L]
Functionele componenten zijn per afnemende applicatie of component
instelbaar, zodat gegevens gescheiden zijn en alleen toegankelijk voor de
afnemer (eigenaar) zelf.
IA01.2.05
[L]
Business functies en functionele componenten communiceren met elkaar op
basis van webservices. Zie hiervoor de documenten IMEA – Katern – Service
Gerichte Architectuur en IenM – ESB Koppelingen – Eisen.
Eisen business functies
ID
Eis
IA01.3.01
[L]
Elke business functie is geheel zelfstandig, moet onafhankelijk van andere
business functies kunnen werken en kent een eigen ontwikkel- en beheercyclus.
Business functies kunnen onafhankelijk van elkaar en de applicaties uitgerold en
getest worden.
IA01.3.02
[L]
De business functie binnen een applicatie moet functioneren als één samenhangend geheel.
Pagina 29 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
IA01.3.03
[L]
4.1.7
4.1.8
Een business functie moet in zijn geheel kunnen worden overgedragen aan een
andere eigenaar, naar een andere omgeving kunnen worden overgezet of
kunnen worden vervangen zonder dat de werking van de business functie voor
afnemende applicaties daardoor wijzigt.
Eisen functionele componenten
ID
Eis
IA01.4.01
[L]
De functionele componenten bepalen de afbakening van herbruikbare
componenten.
IA01.4.02
[L]
Het gebruik van deze functionele componenten is verplicht.
IA01.4.03
[L]
In het functionele componentenmodel zijn de functionele componenten benoemd
zoals die nu voorzien worden. In de offerte en specificatiefase kan blijken dat er
andere functionele componenten nodig zijn of een andere indeling van
functionele componenten nodig is. Deze wijzigingen worden alleen na overleg en
akkoord van de IenM architecten doorgevoerd.
IA01.4.04
[L]
Elke functionele component is geheel zelfstandig, moet onafhankelijk van andere
functionele componenten kunnen werken en kent een eigen ontwikkel- en
beheercyclus. Functionele componenten kunnen onafhankelijk van elkaar en de
applicaties uitgerold en getest worden.
IA01.4.05
[L]
De functionele componenten binnen een business functie moeten functioneren
als één samenhangend geheel.
IA01.4.06
[L]
Een functionele component is verantwoordelijk voor de integriteit van de
gegevens die het levert en verwerkt. Een component controleert of informatie
geldig is voordat deze verwerkt wordt. Hiervoor bevat elke component controles
om te zorgen dat informatie voldoet aan eisen ten aanzien van juistheid,
volledigheid en tijdigheid.
IA01.4.07
[L]
Een functionele component moet in zijn geheel kunnen worden overgedragen
aan een andere eigenaar, naar een andere omgeving kunnen worden overgezet
of kunnen worden vervangen zonder dat de werking van de functionele
component voor afnemende applicaties en business functies daardoor wijzigt.
Eisen laagdrempelig beheer
De volgende eisen gelden voor Regelbeheer en het Loket.
ID
Eis
IA01.5.01
[L]
De inhoud en de werking van het Loket moet kunnen worden aangepast zonder
dat de software hoeft te worden aangepast. Dit houdt in dat minimaal project,
projectdefinitie, activiteit, werkzaamheid, beslisbomen en formulieren als
configuraties worden beschouwd. Beheer en uitvoering (executie) van deze
configuraties zijn gescheiden.
IA01.5.02
[L]
De beheerfunctionaliteit voor formulieren maakt gebruik van een webgebaseerde
WYSIWYG editor die door alle gangbare browsers wordt ondersteund en zonder
plug-ins te gebruiken is.
4.2
Berichten en gegevens
4.2.1
Berichten
Geautomatiseerde informatie-uitwisseling gebeurt via webservices. Systemen
kunnen elkaar elektronische berichten toesturen, die lezen en beantwoorden.
Pagina 30 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
4.2.2
Aanvraag/melding berichten
Een belangrijke functie in Olo is het versturen van ingediende vergunningaanvraagen meldinggegevens naar het bevoegd gezag. Hiervoor wordt een kernbericht
gebruikt, zijnde het aanvraag- en meldingbericht. De termen die in dit bericht
worden gehanteerd zijn gegeneraliseerd, zodat deze voor zowel de Wet algemene
bepalingen omgevingswet (Wabo) als de Waterwet alsook de toekomstige
Omgevingswet en eventuele andere wetten bruikbaar zijn.
Zie bijlage Bijlage E voor een voorbeeld van de opzet van het kernbericht.
Een aanvraag- en meldingbericht bestaat uit een aantal elementen:

Gegevens van het Bevoegd gezag dat verantwoordelijk is voor het behandelen
van de aanvraag of melding.

Optioneel: gegevens van de gemandateerde behandeldienst die namens het
bevoegd gezag de aanvraag of melding afhandelt.

Olo specifieke gegevens zoals Olo-nummer en projectnummer.

Een deel met algemene gegevens van de aanvraag of melding bestaande uit de
Locatie, Objecten, Aanvrager, Gemachtigde aanvrager en Ondertekening. De
gemachtigde aanvrager is optioneel.

Eén of meerdere Activiteiten die vallen onder de Wabo of Waterwet. Een Activiteit
bestaat uit:

Algemene gegevens behorend bij de activiteit. Deze gegevens gelden voor alle
werkzaamheden die vallen onder de activiteit.

Geen, één of meerdere werkzaamheden. Iedere werkzaamheid bevat specifieke
gegevens behorend bij die werkzaamheid.
Gegevens bestaan uit gestructureerde gegevens en optioneel ongestructureerde
gegevens (bijlagen). Of gegevens als bijlage mogen worden toegevoegd is door
beheer in te stellen.
4.2.3
Overige berichttypen
Naast het kernbericht kent Olo de volgende berichttypen:
4.2.4

Aanvraag aanvullen

Aanvraag/melding intrekken

Concept aanvraag/melding indienen

Andere aanvragen/meldingen
Dynamisch berichtinhoud
Bij berichten wordt onderscheid gemaakt tussen een statisch deel en een dynamisch
deel. Een wijziging in het statisch deel van een bericht vereist een nieuwe versie van
het koppelvlak. Het dynamisch deel kan wijzigen zonder dat een nieuwe versie van
het koppelvlak nodig is.
Pagina 31 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
De inhoud van berichten wordt bepaald door formulieren. Een wijziging in een
formulier kan leiden tot een wijziging in het bericht. Dit betekent dat de inhoud van
berichten zich aan moet kunnen passen zonder dat de software aangepast moet
worden.
Een wijziging in een formulier leidt altijd tot het publiceren van een nieuwe versie
van de relevante berichtdefinities (koppelvlak). Dit koppelvlak is van toepassing op
zowel aanbiedende als afnemende systemen. Zowel Olo als de applicaties en
systemen van ontvangende partijen moeten met deze dynamiek om kunnen gaan.
Een wijziging in een bericht heeft ook impact op systemen van leverende partijen
die zelf aanvragen en meldingen opstellen en indienen.
4.2.5
Berichtdefinitie
Het moet mogelijk zijn om nieuwe berichttypen te definiëren en bestaande berichten
te wijzigen zonder de software aan te hoeven passen. Met deze functionaliteit wordt
de berichtopbouw gedefinieerd op basis van berichtonderdelen. Deze
berichtonderdelen zijn gekoppeld aan formulieren.
Figuur 13. Voorbeeld vertaling activiteit/handeling naar aanvraagbericht
Pagina 32 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
Een berichtdefinitie bepaalt:

Uit welke berichtonderdelen een bericht bestaat.

Welk formulier aan welk berichtonderdeel gekoppeld is.

Of in een bericht aanvragen en meldingen gecombineerd mogen worden.

Of aanvragen en meldingen van verschillende wetten (initieel Wabo of
Waterwet) gecombineerd mogen worden.

4.2.6
4.2.7
4.3
Of een bericht uit één of meerdere aanvragen/meldingen mag bestaan.
Eisen berichten
ID
Eis
IA02.1.01
[L]
De berichten die verstuurd en ontvangen worden, worden per applicatie
beschreven in een berichtencatalogus. Dit is een functionele beschrijving.
Daarnaast zijn WSDL’s en XSD’s beschikbaar.
IA02.1.02
[L]
De termen in berichten zijn gegeneraliseerd zodat deze voor zowel de Wet
algemene bepalingen omgevingswet (Wabo) als de Waterwet alsook de
toekomstige Omgevingswet en eventuele andere wetten bruikbaar zijn.
IA02.1.03
[L]
Met berichtdefinities kunnen nieuwe berichttypes, die met het bevoegd gezag
worden uitgewisseld, worden gedefinieerd en bestaande beheerd.
IA02.1.04
[L]
Het wijzigen van een formulier leidt altijd tot het publiceren van een nieuwe
versie van een koppelvlak. Dit betreft nieuwe versie van de berichtencatalogus,
WSDL’s en XSD’s.
IA02.1.05
[L]
Het dynamisch deel van berichten kan wijzigen zonder dat een nieuwe versie van
het koppelvlak nodig is. Olo applicaties moeten met deze dynamiek van
berichten om kunnen gaan.
IA02.1.06
[BG]
Het dynamisch deel van berichten kan wijzigen zonder dat een nieuwe versie van
het koppelvlak nodig is. Systemen van aanleverende en ontvangende partijen
moeten met deze dynamiek van berichten om kunnen gaan.
IA02.1.07
[L]
De inhoud van een bericht wordt bepaald door de combinatie berichtdefinitie en
formulieren. Een berichtdefinitie bepaalt uit welke berichtonderdelen een bericht
bestaat en welk formulier aan welk berichtonderdeel gekoppeld is. Een formulier
bepaalt de inhoud van het berichtonderdeel.
IA02.1.08
[L]
Inhoud van berichten moet aangepast kunnen worden zonder dat de software
hoeft te worden aangepast.
Eisen gegevens
ID
Eis
IA02.2.01
[L]
De definities en modellering van de gegevens uit het Referentiemodel Stelsel
van Gemeentelijke BasisGegevens (RSGB), het referentiemodel gemeentelijke
basisgegevens zaken (RGBZ), het referentie informatiemodel handhaving
(RIHa), de Aquo-standaard worden als basis voor het Olo3 informatiemodel
gebruikt.
IA02.2.02
[L]
De definities en modellering van de gegevens worden per applicatie beschreven
in een gegevenscatalogus. Een gegevenscatalogus is een document dat door de
business gelezen en begrepen kan worden.
Informatie-uitwisseling
De informatie-uitwisseling betreft de mogelijkheid om koppelingen te leggen vanuit
én naar het Regelbeheer, het Loket en de Samenwerkingsruimte. Vanuit het Loket
Pagina 33 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
en de Samenwerkingsruimte naar andere, externe systemen en vice versa moeten
veel koppelingen mogelijk zijn.
4.3.1
Regelbeheer
Regelbeheer is een applicatie voor het omzetten van wet- en regelgeving in
configuraties die in het Loket toepasbaar is. In de volgende afbeelding zijn de
koppelingen met Regelbeheer weergegeven.
Figuur 14. Koppelingen Regelbeheer
Toelichting op de weergegeven koppelingen:

Loket: koppeling waarmee vanuit Regelbeheer regelgeving (beslisbomen en
formulieren) naar het Loket gepubliceerd kan worden.

Regelbeheer: koppelingen waarmee de regelbeheersystemen van bevoegd
gezag organisaties informatie kunnen opvragen aan welke werkzaamheden
lokale regelgeving (beslisbomen en formulieren) gekoppeld kan worden.
4.3.2
Loket
Het Loket is een applicatie voor het checken van plichten en bijlagen, en voor het
opstellen en indienen vergunningaanvragen en meldingen.
Pagina 34 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
Figuur 15. Koppelingen met het Loket
Toelichting op de weergegeven koppelingen:

Aanleverende systemen: koppelingen voor het aanleveren van check- en
formulierinformatie door andere externe systemen zoals Activiteitenbesluit
Internet Module (AIM) en Landelijk Asbestvolgsysteem (LAVS).

Aanvragen/Meldingen: voor het opslaan en ophalen van aanvragen en
meldingen, concept en ingediend.

Algemene regels: koppeling naar een extern systeem, zoals Activiteitenbesluit,
Bouwbesluit en Brandveilig gebruik, waarin de uitkomst van een doorlopen check
of ingevuld formulier wordt omgezet in een ‘overzicht op maat’ van de regels die
van toepassing zijn.

Antwoord voor bedrijven: ‘Berichtenbox’ voor bedrijfsgebonden informatie over
bijvoorbeeld de afhandeling van aanvragen en meldingen.

(Basis)registraties: koppelingen naar (basis)registraties voor het ophalen van
informatie. Gemeentelijke Basisadministratie persoonsgegevens (GBA) en
Handelsregister (NHR).

Bronnen: koppelingen naar andere, externe registraties voor het ophalen van
informatie.

Geoservices: koppeling naar Publieke Dienstverlening op de Kaart (PDOK) voor
het ophalen van geografische informatie, onder andere uit de geografische
basisregistraties zoals Basisregistraties zoals Basisregistratie Adressen en
Gebouwen (BAG), Grootschalige topografie (BGT) en Kleinschalige topografie
(BRT).

MijnOverheid: ‘Berichtenbox’ en ‘Lopende zaken’ voor persoonsgebonden
informatie over bijvoorbeeld de afhandeling van aanvragen en meldingen.
Pagina 35 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0

Overheid.nl: ‘Bekendmakingen’ en ‘Vergunningen’ voor publieke informatie over
bijvoorbeeld ontvangen aanvragen en verleende vergunningen.

Regelbeheer: koppeling waarmee bevoegd gezag organisaties lokale regelgeving
(beslisbomen en formulieren) kunnen publiceren naar het Loket. Daarnaast
gebruikt de landelijk beheer organisatie deze koppeling om regelgeving
(beslisbomen en formulieren) te publiceren naar het Loket.

Statusinformatie: vanuit het Loket moeten er ook koppelingen kunnen worden
gelegd naar voorzieningen waar burgers en bedrijven statusinformatie over een
aanvraag kunnen opvragen:

Toegang: koppelingen naar DigiD en eHerkenning voor identificatie en authenticatie van gebruikers.
4.3.3
Samenwerkingsruimte
Via de Samenwerkingsruimte kunnen behandelende overheden digitaal ingediende
vergunningaanvragen en meldingen gedurende de behandeling uitwisselen met
elkaar. In onderstaande afbeelding zijn de koppelingen met de Samenwerkingsruimte
weergegeven.
Figuur 16. Koppelingen met de Samenwerkingsruimte
Pagina 36 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
De Samenwerkingsruimte verzorgt alle koppelingen met systemen van informatie
afnemende en leverende organisaties zoals:

Aanleverende systemen: koppelingen vanuit externe systemen voor het
ontvangen van compleet ingevulde aanvragen en meldingen met bijlagen.

Aanvraag/Meldingen: koppeling waarmee aanvragen en meldingen worden
ingediend. Aanvraag/Meldingen dient als register voor aanvragen en meldingen
en zorgt voor distributie naar de juiste behandelorganisatie.

Behandelsysteem: Koppeling met behandelsystemen van bevoegd gezag
organisaties, behandeldiensten en adviesorganisaties.

Statusinformatie: koppeling met toepassingen zoals MijnOverheid Lopende Zaken
en andere externe systemen waarin statusinformatie wordt bijgehouden.

Toegang: koppeling naar eHerkenning voor identificatie en authenticatie van
gebruikers.
4.3.4
StUF
Voor geautomatiseerde informatie-uitwisseling tussen systemen zijn afspraken nodig
over het verpakken van de informatie in elektronische berichten ten behoeve van
het versturen ervan: over de envelop en de inhoud (document). Voor die afspraken
is binnen de overheid het Standaard Uitwisseling Formaat (StUF) beschikbaar. StUF
zorgt er voor dat systemen de ontvangen berichten goed kunnen verwerken. StUF
draagt bij aan robuust en gestandaardiseerd berichtenverkeer. Het College van
Standaardisatie heeft StUF geplaatst op de ‘pas toe of leg uit’-lijst. StUF is verplicht
voor alle ketens waarin informatie-uitwisseling met gemeenten plaatsvindt.
4.3.5
Versies
Bij informatie-uitwisseling wordt gebruik gemaakt van gestandaardiseerde koppelvlakken. Een koppelvlak definieert hoe de gegevens worden uitgewisseld. Er is een
groot aantal bevoegd gezag organisaties waarmee gegevens worden uitgewisseld
via deze koppelvlakken. Bij het wijzigen van een koppelvlak moet het mogelijk zijn
om een voorgaande versie voor een beperkte periode te blijven gebruiken. Hierdoor
wordt het beschikbaar komen van een koppelvlak ontkoppeld van het gebruik ervan.
Dit voorkomt wederzijdse afhankelijkheden bij het introduceren van nieuwe koppelvlakken. Bevoegd gezag organisaties migreren in hun eigen tempo.
4.3.6
Digikoppeling, Diginetwerk en Digipoort
Voor de informatie-uitwisseling met systemen van overheidsorganisaties moet
gebruik worden gemaakt van Digikoppeling en Diginetwerk en in aanvulling daarop
van Digipoort voor de informatie-uitwisseling met systemen van organisaties buiten
de overheid.
4.3.7
(Basis)registraties
Er worden gegevens uit een groot aantal externe (basis) registraties gebruikt in Olo.
Deze gegevens worden alleen in de bron gemuteerd. Indien er eigen kopieën van
deze gegevens in Olo worden vastgelegd, dienen deze actueel gehouden te worden.
Pagina 37 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
Voor het Olo aanvraagproces is het cruciaal dat het proces door kan gaan ook als de
(basis)registratie niet beschikbaar is of als de gegevens niet correct zijn.
Als een (basis)registratie niet beschikbaar is moet de gebruiker de gegevens zelf in
kunnen vullen zodat het aanvraagproces door kan gaan:

Het systeem zet een indicatie op het gegeven in het Centraal Aansluitpunt.

Door deze indicatie te zetten geeft het systeem aan dat het geïnformeerd wil
worden als de bron beschikbaar is.

In het berichtenverkeer wordt een indicatie meegegeven dat de gegevens door
de gebruiker zelf ingevuld zijn, zodat de ontvanger weet dat deze gegevens
(kunnen) afwijken van de gegevens in de (basis)registratie zelf.
Indien de gegevens in de (basis)registratie niet correct zijn, moet Olo de gebruiker
de mogelijkheid bieden om deze gegevens te corrigeren4:

Dit heeft consequenties voor het uitgangspunt dat gegevens alleen in de bron
gemuteerd worden.

Gegevens uit de (basis)registratie zijn “readonly” en mogen niet door een
gebruiker gewijzigd worden.

Een gebruiker geeft aan dat de gegevens niet correct zijn.

Hiermee krijgt de gebruiker de mogelijkheid om “readonly” gegevens te wijzigen.

Het systeem moet melden dat de gebruiker zelf verantwoordelijk is om bij de
bronhouder te melden welke gegevens niet correct zijn om te zorgen dat de
gegevens in de bron worden gecorrigeerd.

Het systeem zet een indicatie op het gegeven in het Centraal Aansluitpunt.

Door deze indicatie te zetten geeft het systeem aan dat het geïnformeerd wil
worden als het gegeven gemuteerd is.

In het berichtenverkeer wordt een indicatie meegegeven dat de gegevens door
de gebruiker gecorrigeerd zijn, zodat de ontvanger weet dat deze gegevens
(kunnen) afwijken van de gegevens in de (basis)registratie zelf.
Het indicatiemechanisme is een generiek mechanisme van het Centraal
Aansluitpunt. Door het zetten van een indicatie op een gegeven wordt een systeem
genotificeerd als het gegeven gemuteerd wordt of als de bron beschikbaar is. Elk
systeem is zelf verantwoordelijk om te bepalen voor welke gegevens deze
genotificeerd wil worden en het afhandelingsproces. Het afhandelingsproces bepaalt
als er een notificatie ontvangen wordt of er actie nodig is en welke.
Het indicatiemechanisme kan naast fouten ook gebruikt worden om gegevens
actueel te houden. Bij (basis)registraties die Digilevering ondersteunen maakt het
mechanisme hier gebruik van. Voor (Basis)registraties die Digilevering niet
4. In het geval van Olo is het mogelijk om deze escape te bieden. Elke applicatie bepaalt zelf of deze mogelijkheid
wordt geboden en hoe dat procesmatig wordt opgelost.
Pagina 38 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
ondersteunen dient een polling mechanisme opgezet te worden. Dit polling
mechanisme controleert na een instelbare periode of het gegeven gewijzigd is.
4.3.8
Eisen informatie-uitwisseling
ID
Eis
IA03.1.01
[L]
Bij het ontwikkelen van Olo worden de overheidsstandaarden aangehouden zoals
vastgesteld door het Forum Standaardisatie
(http://www.forumstandaardisatie.nl).
IA03.1.02
[L]
Als er geen relevante standaard is vastgesteld door het Forum Standaardisatie
dan wordt een standaard in overleg met en na goedkeuring van de IenM
architecten gekozen. Hierbij wordt, in de aangegeven volgorde, gekeken naar
overheids-, open- en defacto standaarden.
IA03.1.03
[L]
Voor de informatie-uitwisseling in ketens met daarin ook gemeenten moet
gebruik worden gemaakt van het Standaard Uitwisseling Formaat (StUF).
IA03.1.04
[L]
Voor de informatie-uitwisseling met externe systemen wordt gebruik gemaakt
van het Centraal Aansluitpunt (CA) van IenM. Het CA zorgt dat berichtenverkeer
voldoet aan de overheids interoperabiliteit standaarden (Digikoppeling).
IA03.1.05
[BG]
Een bevoegd gezag bepaalt zelf welke versie van een koppelvlak zij gebruikt.
IA03.1.06
[L]
Kennis over de koppelvlakversie is ontkoppeld van de applicatie en wordt
opgelost met de Berichtenkanaal component.
IA03.1.07
[L]
De in 4.3.1, 4.3.2 en 4.3.3 genoemde koppelingen zijn onderdeel van de
oplossing en dienen gerealiseerd te worden.
IA03.1.08
[L]
Voor geografische visualisatie en interactie wordt gebruik gemaakt van PDOK
Kaart.
IA03.1.09
[L]
Voor het vertalen van bijvoorbeeld adressen naar geografische coördinaten en
visa versa wordt gebruik gemaakt van PDOK Geocodeerdienst.
IA03.1.10
[P]
Voor geografische functionaliteit wordt gebruik gemaakt van bestaande diensten
van PDOK. Bestaat de dienst niet of voldoet deze niet dan wordt samengewerkt
met PDOK om deze te realiseren.
IA03.1.11
[L]
(Basis)registraties zijn en blijven de bron en gegevens worden alleen in de bron
gemuteerd.
IA03.1.12
[L]
Indien er eigen kopieën van gegevens uit deze (basis)registraties worden
vastgelegd, dan dienen deze actueel gehouden te worden.
IA03.1.13
[L]
Olo biedt de gebruiker de mogelijkheid om gegevens uit (basis)registraties te
corrigeren.
IA03.1.14
[L]
Olo moet een indicatie op gecorrigeerde gegevens zetten bij het Centraal
Aansluitpunt. Door deze indicatie te zetten geeft Olo aan dat deze geïnformeerd
wil worden als het gegeven gemuteerd is.
IA03.1.15
[L]
In het berichtenverkeer wordt een indicatie meegegeven dat de gegevens door
de gebruiker gecorrigeerd zijn, zodat de ontvanger weet dat deze gegevens
(kunnen) afwijken van de gegevens in de (basis)registratie zelf.
IA03.1.16
[L]
Olo is zelf verantwoordelijk voor het inrichten van het afhandelingsproces van
notificaties. Dit proces bepaalt per notificatie of er actie nodig is en welke.
Pagina 39 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
5
Technische architectuur
In dit hoofdstuk worden de kaders en richtlijnen ten aanzien van de technische
architectuur beschreven, dit is bepalend voor de te kiezen oplossing. De technische
architectuur omvat de volgende aspecten:
5.1

Wie leveren de functionaliteit?

Wat is nodig voor opslag?

Hoe verloopt de communicatie?
Technische componenten
De afbeelding op de volgende pagina geeft een overzicht van de technische
componenten die nodig zijn voor het realiseren van de Olo applicaties. Dit overzicht
is een doorvertaling van de functionele componenten zoals beschreven in paragraaf
4.1.2.5 ‘Functionele componenten’. Beide platen hanteren dezelfde opbouw en
categorisering, waardoor de componenten aan elkaar te relateren zijn. Een
functioneel component kan bestaan uit meerdere technische componenten. Zie het
[Componenten] document voor een toelichting van het componentenmodel.
De componenten zijn onder te verdelen in de volgende categorieën:

Componenten die beschikbaar zijn. Deze componenten inclusief documentatie
zijn 1 januari 2015 beschikbaar;

Componenten die door DCI geleverd worden als onderdeel van het Standaard
Platform (SP). Deze componenten inclusief documentatie zijn 1 januari 2015
beschikbaar;

Componenten die geleverd worden door de leverancier van Olo3;
Herbruikbare componenten kunnen afkomstig zijn van andere partijen zoals eoverheid bouwstenen. IenM kiest er voor om de interne en externe wereld te
ontkoppelen. Dit doet zij door in bijna alle gevallen via eigen herbruikbare
componenten te koppelen met externe componenten. Doel van deze herbruikbare
componenten is de interne systemen en de ontwikkelaars af te schermen van de
complexiteit van het koppelen met de externe componenten en/of afschermen van
specifieke kennis die nodig is om deze externe componenten te gebruiken.
Pagina 40 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
Figuur 17. Technisch componentenmodel
5.1.1
Eisen technische componenten
ID
Eis
TA01.1.01
[DCI FB]
De componenten in de categorieën “Herbruikbaar beschikbaar” en “Herbruikbaar
DCI” worden door DCI beschikbaar gesteld voor aanvang van de specificatiefase.
Het gebruik van deze componenten is verplicht. Er wordt documentatie
aangeleverd hoe de componenten te gebruiken.
Pagina 41 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
5.1.2
TA01.1.02
[L]
De componenten in de categorieën “Applicatie” en “Herbruikbaar Olo3” worden
door de leverancier opgeleverd tijdens de bouwfase, inclusief alle documentatie
zoals beschreven in [Beheerst naar beheer].
TA01.1.03
[L]
Alle user interfaces ondersteunen minimaal het interactiekanaal Webbrowser en
het Loket ondersteunt daarnaast het interactiekanaal Mobiel.
TA01.1.04
[L]
De specifieke eisen voor de herbuikbare componenten worden in de
specificatiefase uitgewerkt. Algemene richtlijnen ten aanzien van herbruikbare
componenten, zoals in dit document en de referentiedocumenten zijn benoemd,
zijn hierbij leidend.
Herbruikbaarheid
Om eindgebruikers te ondersteunen bieden applicaties een passende verzameling
functionaliteiten aan zoals formulieren, toegang (authenticatie en autorisatie) en
gebruik van (basis)registraties. Deze functionaliteiten worden vaak voor elke
applicatie opnieuw ontwikkeld, terwijl veel functionaliteiten hetzelfde en daarmee in
feite herbruikbaar zijn. In de volgende afbeelding is een applicatie weergegeven die
bestaat uit de applicatie specifieke inrichting plus een verzameling herbruikbare
componenten c.q. bouwstenen. De specifieke inrichting is als het ware de lijm
tussen de herbruikbare bouwstenen en maakt dat de applicatie geschikt is voor de
‘eigen’ rol en taak.
Figuur 18. Applicaties bestaan uit een herkenbare verzameling functionaliteiten
Herbruikbare bouwstenen zijn componenten die door meerdere systemen worden
gebruikt. Met deze herbruikbare bouwstenen kan fors bespaard worden op kosten en
tijd bij het ontwikkelen en implementeren van systemen. IenM streeft naar het
maximaliseren van het aantal herbruikbare bouwstenen. Dit betekent dat het aantal
herbruikbare bouwstenen groeiende is. Een deel van deze herbruikbare bouwstenen
is reeds beschikbaar. Een aantal andere bouwstenen dienen door Olo3 opgeleverd te
Pagina 42 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
worden. Aan bouwstenen worden aanvullende eisen gesteld zodat ze herbruikbaar
zijn.
In de volgende afbeelding zijn de Olo applicaties weergegeven, gebruikmakend van
de infrastructuur, middleware en herbruikbare bouwstenen van het Standaard
Platform.
Figuur 19. Olo applicaties in relatie tot het Standaard Platform
Pagina 43 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
5.1.3
5.1.4
Eisen herbruikbaarheid
ID
Eis
TA01.2.01
[L]
Een bouwsteen is toegankelijk via een webbrowser.
TA01.2.02
[L]
Om een bouwsteen te gebruiken is geen specifieke software vereist in de
webbrowser.
TA01.2.03
[L]
Een bouwsteen is ontsloten via goed gedefinieerde leverancier en product
neutraal koppelvlak. Dit koppelvlak ofwel Application Programming Interface
(API) zorgt ervoor dat integratie tussen afnemers (systemen) en de bouwsteen
mogelijk is. De API geeft toegang tot zowel functionaliteit, gegevens als
instellingen (configuratie).
TA01.2.04
[L]
Een bouwsteen is eenvoudig te configureren, waardoor afnemers de werking
eenvoudig met behulp van een webgebaseerde interface kunnen configureren
en aan de eigen behoeften aan kunnen passen. De configuratie blijft behouden
bij nieuwe releases.
TA01.2.05
[L]
Een bouwsteen biedt zelfbediening via een webgebaseerde beheerinterface
waardoor een afnemer zijn eigen instellingen en gegevens kan configureren en
inzien.
TA01.2.06
[L]
Een bouwsteen biedt een gedeeld model5 ofwel multitenancy waardoor een
enkele instantie door meerdere afnemers gebruikt kan worden.
TA01.2.07
[L]
Gegevens van verschillende afnemers zijn (virtueel) van elkaar gescheiden. De
verschillende afnemers zijn voor elkaar afgeschermd, zij kunnen elkaars
gegevens en instellingen niet zien of wijzigen.
TA01.2.08
[L]
Een bouwsteen kan naar behoefte op- en afschalen.
TA01.2.09
[L]
Het gebruik van een bouwsteen is meetbaar zodat het mogelijk is om op basis
van gebruik af te rekenen.
OTAP+ en staging straat
Software en content kennen een eigen releasecyclus en worden onafhankelijk van
elkaar ontwikkeld en naar productie gebracht. Tot content worden zaken gerekend
als teksten, afbeeldingen, video, regels, inregelgegevens bevoegd gezag en
documenttemplates.
Een staging omgeving is noodzakelijk om productie niet te verstoren en te belasten
tijdens het actualiseren van content. Staging is een logische omgeving die in de
productie omgeving staat, een productiestatus heeft en draait op eigen servers of
eigen instantie van de applicatie. Hierdoor kan deze content onafhankelijk van de
software op een gecontroleerde wijze worden voorbereid, getest en na goedkeuring
naar productie worden gebracht. Dit zorgt er voor dat het productiesysteem en de
componenten bereikbaar blijven en correct blijven functioneren tijdens het beheer-
5. Een gedeeld model betekent dat er gebruik wordt gemaakt van een gemeenschappelijke infrastructuur en
codebase versie die centraal wordt beheerd. Hierdoor is het mogelijk om sneller en efficiënter nieuwe versies uit
te rollen. De voorkeur gaat uit naar een gedeeld model. Het kan zijn dat een herbruikbare bouwsteen gebaseerd
is op standaard software waar dit model niet mogelijk is. In dat geval wordt een model gehanteerd waarbij iedere
afnemer een eigen instantie krijgt, maar wel gebaseerd op een cartridge en hetzelfde koppelvlak en versie van de
standaard software. Toegang tot de verschillende instanties wordt eenduidig geregeld door de ESB.
Pagina 44 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
proces en software en content releases onafhankelijk van elkaar naar productie
gebracht kunnen worden.
De OTAP+ straat is gericht op het gecontroleerd naar productie brengen van nieuwe
versies van software en het toevoegen, wijzigen en uitfaseren van bijbehorende
services. De staging omgeving is gericht op het gecontroleerd bewerken van content
en het uitrollen hiervan naar productie. Het uitrolmechanisme van staging naar
preproductie naar productie is volledig geautomatiseerd en wordt door een functioneel beheerder vanuit een beheerconsole aangestuurd en gecontroleerd. Dit proces
moet ook het teruggaan naar een voorgaande versie ondersteunen als er na het
uitrollen problemen zijn. Functioneel beheer bepaalt of er, in geval van problemen,
wordt teruggegaan naar een voorgaande versie, of dat het probleem met een
nieuwe versie moet worden opgelost. Het al dan niet accepteren van dataverlies is
hierbij een van de afwegingen.
Figuur 20. OTAP+ en staging straat
De componenten in de staging omgeving hebben een productiestatus. Bij wijziging
van de software van componenten in de staging omgeving worden altijd het OTAP+
proces en alle bijbehorende procedures doorlopen.
5.1.5
Eisen uitrollen
Pagina 45 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
5.1.6
5.1.7
ID
Eis
TA01.3.01
[L]
Niet software release gerelateerde data zoals content, regels en templates
worden via de staging omgeving naar productie gebracht.
TA01.3.02
[L]
Niet software release gerelateerde data worden onafhankelijk van de release
cyclus van de software naar productie gebracht en in gebruik genomen.
TA01.3.03
[L]
Het uitrolmechanisme van staging naar preproductie naar productie is volledig
geautomatiseerd en moet door een functioneel beheerder vanuit een
beheerconsole aangestuurd en gecontroleerd kunnen worden.
TA01.3.04
[L]
Het uitrolmechanisme moet het volledig automatisch teruggaan naar de
voorgaande versie mogelijk maken als er na het uitrollen problemen optreden.
Eisen webinterface
ID
Eis
TA01.4.01
[L]
De webinterface van Olo en de herbruikbare componenten kunnen met een
standaard webbrowser bediend worden zonder het installeren van add-ons ofwel
plugins.
TA01.4.02
[L]
Alle standaard webbrowsers en versies die een marktaandeel van meer dan 5%
hebben moeten ondersteund worden. Zie de volgende website voor de
gebruiksstatistieken per browser type http://www.netmarketshare.com/. Bij
aanvang van de bouw wordt op basis van deze informatie bepaald welke
browsers en versies ondersteund moeten worden. Daarna wordt dit jaarlijks
herijkt.
TA01.4.03
[L]
De webinterface moet voor het Loket ook correct werken op elke mobiele OS
versie (Android, iOS en Windows Phone) met een marktaandeel van meer dan
5%. Zie de volgende website voor de gebruiksstatistieken per OS type
http://www.netmarketshare.com/. Bij aanvang van de bouw wordt op basis van
deze informatie bepaald welke mobiele OS versies ondersteund moeten worden.
Daarna wordt dit jaarlijks herijkt.
TA01.4.04
[L]
Het publieke deel van Olo dat extern toegankelijk is, zowel gebruiker- als
beheerfunctionaliteit, moet voldoen aan de Rijkshuisstijl voor Internet van het
Ministerie van Infrastructuur en Milieu
(http://www.rijkshuisstijl.nl/index.cfm/ministerie-van-infrastructuur-enmilieu/middelen/digitaal-en-online/internet/).
TA01.4.05
[L]
De interne beheerfunctionaliteit is onafhankelijk van het publieksdeel en alleen
beschikbaar voor een geselecteerde groep beheerders en moet voldoen aan de
Rijkshuisstijl voor Intranet van het Ministerie van Infrastructuur en Milieu
(http://www.rijkshuisstijl.nl/index.cfm/ministerie-van-infrastructuur-enmilieu/middelen/digitaal-en-online/intranet/).
TA01.4.06
[L]
Het publieke deel van Olo voldoet aan de Webrichtlijnen 2.0
(http://www.webrichtlijnen.nl/ en http://versie2.webrichtlijnen.nl/) en is
getoetst op Waarmerk drempelvrij niveau 3 (www.drempelvrij.nl). Dit geldt waar
mogelijk ook voor geografische viewerfunctionaliteit.
TA01.4.07
[L]
Het publieke deel van Olo, voor zowel gebruikers als beheerders, is in het
Nederlands.
Eisen responsiveness
Om een optimale gebruikerservaring te bereiken dient een webpagina zo snel
mogelijk opgebouwd te worden. Om dit te bereiken is de webpagina direct zichtbaar
en bruikbaar en wordt dynamische content in de achtergrond opgehaald en
toegevoegd.
Pagina 46 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
5.1.8
5.1.9
ID
Eis
TA01.5.01
[L]
Om een optimale gebruikers ervaring te bereiken wordt gewerkt met asynchrone
achtergrond calls.
TA01.5.02
[L]
De gebruikersinterface is voor het Loket geschikt voor verschillende type devices
(touch, no touch, desktop, mobile, tablet).
TA01.5.03
[L]
Het systeem ondersteunt het uploaden van grote bestanden (> 1 GB). Er wordt
gebruik gemaakt van een browser based upload oplossing die resume upload en
chunking ondersteund, zoals Pluload.
Eisen datacenter
ID
Eis
TA01.6.01
[SP]
Er wordt gebruik gemaakt van een rijksdatacenter. Het Standaard Platform (SP)
draait in dit rijksdatacenter (zie TC02).
TA01.6.02
[SP]
Componenten worden centraal geplaatst, tenzij deze een decentrale plaatsing
vragen.
Standaard Platform
Olo en (herbruikbare) componenten maken gebruik van het Standaard Platform. Het
Standaard Platform draait in een Rijksdatacenter. Het Standaard Platform levert
gestandaardiseerde middleware producten en componenten waar software gebruik
van maakt.
Zie voor een uitgebreide beschrijving van het Standaard Platform en de eisen waar
systemen, applicaties, business functies en componenten aan moeten voldoen de
volgende documenten:

IMEA Katern Standaard Platform [SP]

IenM Standaard Platform Aansluitvoorwaarden Applicaties en Componenten
[Aansluitvoorwaarden]
Het Standaard Platform biedt cartridges aan voor standaard software ofwel
Commercial Off The Shelf (COTS) die niet geschikt is of geschikt te maken is voor de
middleware componenten van het Standaard Platform. Deze bouwsteen integreert
wel met het Standaard Platform. Een cartridge draait op een virtuele server die
rekencapaciteit, opslagruimte, netwerk connectiviteit en Operating Systeem (OS)
biedt die voldoet aan de beveiligingseisen en standaard back-up functionaliteit. Een
cartridge kan net als andere Standaard Platform componenten volledig
geautomatiseerd uitgerold worden.
Een cartridge brengt hogere inrichtings- en exploitatielasten met zich mee in
vergelijking met het gebruik van de overige componenten van het Standaard
Platform. Voor het gebruik van cartridges is een business case en een intake nodig
van architectuur en technisch beheer. Het uitgangspunt is dat standaard software
volledig geautomatiseerd op een cartridge geïnstalleerd, gepatcht en geupgrade
wordt met behulp van OpsCode Chef. Dit is de verantwoordelijkheid van de
leverancier van de oplossing.
Pagina 47 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
Communicatie tussen componenten, ongeacht of het maatwerk of standaard
component betreft, is altijd op basis van een leverancier- en technologieneutraal
koppelvlak. Deze zogenaamde proces- en business services draaien altijd op het
Standaard Platform (ESB of BPS component).
Figuur 21. Maatwerk en standaard software maken gebruik van Standaard Platform aspecten
De volgende tabel geeft een overzicht van de verschillende aspecten van het
Standaard Platform in relatie tot maatwerk en standaard software en de eisen waar
beiden aan moeten voldoen.
Aspect
Maatwerk
software
Standaard
software
Applicatie en beveiliging (authenticatie en autorisatie) zijn
ontkoppeld.
Verplicht
Verplicht
Automatische installatie, configuratie, patchen en upgraden
van software.
Verplicht
Verplicht
Gebruik van het Standaard Platform ESB en BPS component
voor proces- en business webservices.
Verplicht
Verplicht
Gebruik van overige Standaard Platform componenten.
Verplicht
Gewenst
Dynamisch horizontaal schalen.
Verplicht
Gewenst
Dynamisch verticaal schalen.
Verplicht
Verplicht
Automatisch uitrollen van releases van software, applicaties
en componenten.
Verplicht
Gewenst
Automatische installatie en configuratie van
databaseschema.
Verplicht
Gewenst
Applicaties en componenten maken gebruik van een
gedeelde infrastructuur.
Verplicht
Verplicht
Proces en business services maken gebruik van het
Standaard Platform.
Verplicht
Verplicht
Applicaties en componenten maken gebruik van
gecentraliseerde connectiviteit.
Verplicht
Verplicht
Pagina 48 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
Componenten werken op een gevirtualiseerde omgeving.
5.1.10
5.1.11
5.1.12
5.1.13
Verplicht
Verplicht
Eisen Standaard Platform
ID
Eis
TA01.7.01
[L]
Maatwerk en standaard componenten maken gebruik van het Standaard
Platform (SP).
TA01.7.02
[L]
Voor elke component die gebruik wil maken van cartridges is goedkeuring nodig
van IenM architectuur.
TA01.7.03
[L]
Om herhaalbaarheid, voorspelbaarheid en snelheid te garanderen wordt de
installatie, configuratie, patchen en upgraden van Standaard software ofwel
Commercial of the Shelf (COTS) uitgevoerd met behulp van OpsCode Chef. De
leverancier is er zelf verantwoordelijk voor dat standaard software volledig
geautomatiseerd in de cartridge geïnstalleerd kan worden met OpsCode Chef.
Dit betekent dat installatie, configuratie, patchen en upgraden van software
zonder handmatige handelingen mogelijk is.
Eisen componenten
ID
Eis
TA01.8.01
[L]
Voor de keuze van componenten geldt: hergebruiken voor kopen voor bouwen.
Bij hergebruik geldt dat er expliciet zowel binnen als buiten de IenM organisatie
wordt gekeken of er een geschikte component beschikbaar is. De keuze dient
voor elke component te worden goedgekeurd door IenM architectuur.
TA01.8.02
[L]
Indien een component wordt gerealiseerd met standaard software, dan moet
deze software ook gebruikt worden zoals geleverd, zonder aanpassingen aan de
code. Aanpassingen aan de code zijn wel toegestaan als gegarandeerd wordt dat
deze worden opgenomen in de eerst volgende officiële release en wel binnen een
termijn van 3 maanden.
TA01.8.03
[L]
Configuratie van een component moet zonder aanpassingen kunnen werken na
installatie van een nieuwe versie. Dit geldt voor zowel open source als standaard
componenten.
TA01.8.04
[L]
De door architectuur in dit document geïdentificeerde (herbruikbare) componenten zijn als zelfstandige component te gebruiken en zonder verdere
aanpassingen in te zetten voor andere systemen.
TA01.8.05
[L]
Voor het bevragen van de (basis)registraties wordt gebruik gemaakt van het
Centraal Aansluitpunt.
Eisen open source
ID
Eis
TA01.9.01
[L]
Bij voorkeur wordt gebruik gemaakt van open source producten.
TA01.9.02
[L]
Bij het ontwikkelen en selecteren van standaard software is men gehouden aan
de standaarden zoals genoemd in de verschillende documenten en op de website
van het Forum Standaardisatie (http://www.forumstandaardisatie.nl).
Schaalbaarheid en robuustheid
Systemen en componenten zijn dynamisch schaalbaar (op- en afschakelen) om met
de onvoorspelbaarheid van het gebruik van de voorziening om te gaan.
Pagina 49 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
Om de voorspelbaarheid van de performance van Olo te garanderen is het vereist
dat Olo en de (herbruikbare) componenten onafhankelijk van elkaar schaalbaar en
robuust zijn. Dit wordt bereikt door elk onderdeel als een zelfstandige eenheid ofwel
service te laten functioneren en expliciet rekening te houden met de mogelijkheid
dat componenten tijdelijk niet beschikbaar kunnen zijn.
Bij het uitwerken van een schaalbare architectuur moet rekening gehouden worden
met de volgende variabelen:

Schaalbaarheid: Aantal gelijktijdige gebruikers, sessies, transacties of operaties
dat een systeem als geheel kan uitvoeren.

Prestaties: Optimaal gebruik van beschikbare middelen (resources).

Reactietijd: Tijd die nodig is om een operatie uit te voeren.

Beschikbaarheid: Bepaalt of een applicatie of een deel van een applicatie
beschikbaar is op een moment in de tijd.

Downtime impact: De impact van het niet-beschikbaar zijn van een server,
service, component of applicatie. Aantal gebruikers of systemen dat hier nadeel
van ondervindt en de consequenties.

Kosten: Welke kosten zijn acceptabel om een schaalbare architectuur te
realiseren in verhouding tot de impact van het niet beschikbaar zijn of niet goed
presteren van een systeem.

Beheerbaarheid: Zijn fouten eenvoudig te herleiden en op te lossen door beheer.
Schalen
Bij het schalen zijn verschillende opties mogelijk:

Verticaal schalen: Verwerkingscapaciteit uitbreiden door het toevoegen van
geheugen en of CPU’s aan een server. Dit wordt geregeld door de virtualisatie
software. Het uitbreiden van geheugen en CPU’s kent grenzen.

Horizontaal schalen: Verwerkingscapaciteit uitbreiden door extra servers toe te
voegen en een component, over verschillende servers te verdelen. Een load
balancer zorgt ervoor dat de requests voor een component over de verschillende
servers verdeeld worden. Door services en componenten over meerdere servers
te verdelen neemt de verwerkingscapaciteit, robuustheid en beschikbaarheid
toe. Dit wordt geregeld door het Standaard Platform.

Partitioneren: Het fysiek van elkaar scheiden van verschillende componenten
door deze op aparte servers te plaatsen. Bijvoorbeeld front-end, backend en
database op verschillende servers plaatsen. Hierdoor is het mogelijk om een
server optimaal te tunen voor de component die er gebruik van maakt.
Schalen kan effectiever en efficiënter toegepast worden als de applicatie of
componenten ontworpen zijn met schaalbaarheid als uitgangspunt. Capaciteit moet
dynamisch schaalbaar zijn (op- en afgeschakeld kunnen worden) op basis van het
werkelijk gebruik.
Pagina 50 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
5.1.14
Eisen applicaties en componenten
De keten is zo sterk als de zwakste schakel: Olo bestaat uit een groot aantal
(herbruikbare) componenten en deze componenten kunnen en zullen uitvallen. De
architectuur houdt expliciet rekening met het uitvallen van componenten en kan
hiermee omgaan.
5.1.15
5.1.16
ID
Eis
TA01.10.01
[SP]
Olo, de (herbruikbare) componenten en standaard software maken gebruik van
hardware virtualisatie.
TA01.10.02
[L]
Olo en (herbruikbare) componenten zijn onafhankelijk van elkaar schaalbaar.
TA01.10.03
[L]
Olo en de (herbruikbare) componenten houden expliciet rekening met de
mogelijkheid dat componenten tijdelijk niet beschikbaar kunnen zijn en kunnen
hiermee omgaan. Dit is het uitgangspunt, maar kan niet altijd afgedwongen
worden. Als een component kritisch is voor het proces dan zal het niet
beschikbaar zijn daarvan het proces stoppen. Als dit het geval is moet het
proces, als de component hersteld is, weer verder gaan vanaf het punt waar het,
tot het moment van niet beschikbaar zijn, gevorderd was.
TA01.10.04
[L]
Componenten zijn onafhankelijk van elkaar en kunnen uitgevoerd worden
zonder kennis te hebben van andere componenten.
TA01.10.05
[L]
Een component kan over meerdere servers verdeeld worden.
TA01.10.06
[L]
Een component kan over meerdere Java Virtual Machines (JVM) op een enkele
server verdeeld worden.
TA01.10.07
[L]
Componenten passen caching toe om te voorkomen dat dezelfde gegevens
continu opgehaald worden. Cache periode is door beheer per type cache object
instelbaar.
Eisen webservices
ID
Eis
TA01.11.01
[L]
Asynchrone communicatie wordt toegepast bij alle berichten die niet direct
verwerkt hoeven te worden.
TA01.11.02
[L]
Samengestelde services hebben een compensatie mechanisme. Bij een
samengestelde service wordt een aantal services gebruikt om de benodigde
applicatielogica te realiseren. Bij een compensatie mechanisme kan een service
een eerder aangebrachte wijziging zelf terugdraaien.
Database
Voor performance doeleinden moet bij gegevensopslag onderscheid gemaakt worden
tussen gegevensopslag voor mutatie en raadpleeg doeleinden. Hierdoor wordt het
mogelijk om dataopslag te optimaliseren voor de toepassing o.a. door het
partitioneren van gegevens en geoptimaliseerde indexstructuren. Hiermee kan
voorkomen worden dat verschillende soorten gebruik elkaar beïnvloeden. Het maken
van een grote selectie mag bijvoorbeeld geen merkbare gevolgen hebben voor het
muteren van gegevens. Het moet mogelijk zijn om de fysieke databases voor
muteren en raadplegen op aparte servers te plaatsen.
Het is mogelijk om datasets verticaal te partitioneren. Bij verticaal partitioneren
worden de tabellen van specifieke datasets toegewezen aan een specifieke
Pagina 51 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
database. Hierdoor wordt het mogelijk om gegevens met een grootschalig gebruik af
te schermen van gegevens met kleinschalig gebruik. Hiermee worden de prestaties
gemaximaliseerd, zonder dat dit ten koste gaat van gegevens met kleinschalig of
beperkt gebruik.
5.1.17
5.2
Eisen database
ID
Eis
TA01.12.01
[L]
Er wordt onderscheid gemaakt tussen mutatie en raadpleeg databases.
TA01.12.02
[L]
Het is mogelijk om de fysieke databases voor muteren en raadplegen op aparte
servers te plaatsen.
TA01.12.03
[L]
Het is mogelijk om datasets verticaal te partitioneren.
TA01.12.04
[L]
De in de gegevenscatalogus per applicatie vastgelegde gegevensdefinities en
formaten worden consistent door het hele systeem doorgevoerd.
Gegevensopslag
Bij Olo is sprake van het ontvangen en verwerken van grote hoeveelheden data.
Gegevensopslag is hierdoor een belangrijk onderdeel en is verantwoordelijk voor het
op de juiste manier opslaan en ophalen van gegevens. Het zorgt ook voor
plausibiliteits- en consistentiecontroles. Het gaat om zowel gestructureerde als
ongestructureerde gegevens.
5.2.1
Eisen datastores
Ingevoerde gegevens of berichten zijn gestructureerde gegevens. Documenten
worden gezien als ongestructureerde gegevens.
ID
Eis
TA02.1.01
[L]
Ongestructureerde gegevens worden in de herbruikbare documentbeheer
component opgeslagen, inclusief metadata zoals wie het document heeft
toegevoegd en versiebeheer hiervan. Het gaat om een beperkt aantal
elementen.
TA02.1.02
[L]
Gestructureerde gegevens worden in een database opgeslagen.
TA02.1.03
[L]
Voor relationele databases wordt gebruik gemaakt van een van de door het
Standaard Platform aangeboden database opties: PostgreSQL, SQL Server of
Oracle. Hierbij geldt dat PostgreSQL de voorkeur heeft.
TA02.1.04
[L]
Als alternatief voor de aangeboden relationele databases mag in overleg met
architectuur gebruik worden gemaakt van een NoSQL database. De uiteindelijke
keuze is aan IenM architectuur.
TA02.1.05
[SP]
Databaseservers maken gebruik van een eigen databasestorage op een SAN,
waarbij replicatie plaatsvindt (master slaves). Replicatie kan op applicatieniveau
of databaseniveau opgelost worden op basis van synchrone of asynchrone
replicatie. Asynchrone replicatie op databaseniveau, transparant voor de
applicatie, heeft de voorkeur.
TA02.1.06
[L]
Bij een relationele datastore dient technische en functionele referentiële
integriteit tussen records afgedwongen te worden.
Pagina 52 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
5.2.2
Eisen importeren en exporteren
ETL tooling biedt de meest efficiënte en onderhoudbare oplossing voor het in bulk
importeren en exporteren van gegevens. ETL tools zijn bewezen oplossingen voor
bulk gegevensuitwisseling.
5.2.3
5.2.4
ID
Eis
TA02.2.01
[L]
Voor het importeren en exporteren van gegevens wordt gebruik gemaakt van
ETL tooling.
TA02.2.02
[L]
Regelmatig voorkomende bulk import of export acties moeten via een
webgebaseerde beheerinterface uitgevoerd worden. Incidentele bulk import of
export acties mogen handmatig uitgevoerd worden.
Eisen onderhoudbaarheid
ID
Eis
TA02.3.01
[L]
Data voldoen aan de Nederlandse standaarden voor getallen en data.
TA02.3.02
[L]
Sleutels ofwel ID’s zijn betekenisloos.
Eisen Integriteit
Gegevens moeten aantoonbaar origineel en onveranderd zijn.
ID
Eis
TA02.4.01
[L]
De database is alleen toegankelijk voor de broncomponent, de component die
verantwoordelijk is voor het bewerken en opvragen van de gegevens. Het is niet
toegestaan om gegevens direct, al of niet handmatig, in de database te
manipuleren. Het muteren en opvragen van gegevens wordt altijd via de
broncomponent uitgevoerd.
TA02.4.02
[L]
Van gegevens wordt de mutatiehistorie bijgehouden. Van elke record is bekend
wanneer deze toegevoegd, gewijzigd en verwijderd is en door wie.
TA02.4.03
[L]
Gegevens die niet meer gewijzigd mogen worden dienen omgezet te worden
naar een archiefwaardig bestandformaat (XML en PDF) en gearchiveerd te
worden. Metadata wordt in het genereren meegenomen, zoals wie, wat en
wanneer. Voor archivering wordt gebruik gemaakt van de herbruikbare
archiveringscomponent.
TA20.4.04
[L]
Bestanden die door Olo in een archiefwaardig formaat worden gegenereerd,
worden voorzien van een elektronische handtekening op basis van het
PKIoverheid certificaat van IenM. Daarmee is zeker dat de gegevens afkomstig
zijn van Olo en wordt iedere bewerking of wijziging onmiddellijk gesignaleerd.
TA02.4.05
[L]
Gegevens worden niet verwijderd maar gemarkeerd als verwijderd. Olo en
(herbruikbare) componenten bieden opschoonfunctionaliteit om gegevens na
een bepaalde periode permanent uit de database te verwijderen met behoud van
consistentie. Dit gebeurt op basis van verschillende criteria (bijvoorbeeld leeftijd
of status) of combinaties hiervan. De criteria zijn door beheer instelbaar.
Daarnaast moet bij het schonen van gegevens bewaakt worden dat de
resterende gegevens wel functioneel betekenisvol zijn. Voor gearchiveerde
gegevens gelden bij het opschonen de archiefeisen.
Pagina 53 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
5.2.5
Eisen continuïteit
Gegevens mogen niet verloren gaan.
5.2.6
5.2.7
5.3
ID
Eis
TA02.5.01
[L]
Bij (her)installatie van (een deel van) het systeem of de component mogen geen
gegevens verloren gaan.
Eisen (basis)registraties
ID
Eis
TA02.6.01
[L]
Bij gegevens uit (basis)registraties wordt de bronsleutel vastgelegd, zodat deze
altijd herleidbaar zijn naar de originele brongegevens.
TA02.6.02
[L]
Een kopie van gegevens uit (basis)registraties mag alleen lokaal bewaard
worden als deze nodig is voor bulkverwerkingen, zoals rapportages of analyses,
of als de historische gegevens in de toekomst bekend moeten zijn. In alle
andere gevallen worden (basis)registratie gegevens realtime opgehaald.
Eisen back-up
ID
Eis
TA02.7.01
[SP]
Er wordt gebruik gemaakt van de standaard back-up functionaliteit en processen
van de hosting partij.
Netwerk
De netwerk infrastructuur van de hosting omgeving is onderverdeeld in
verschillende zones (compartimenten) bestaande uit een niet vertrouwd deel,
Demilitarized Zone (DMZ) en vertrouwde delen.
Bij communicatie van en naar andere overheidsorganisaties wordt gebruik gemaakt
van Diginetwerk. Diginetwerk is een besloten overheidsnetwerk (VPN) dat verschillende fysieke overheidsnetwerken verbindt, zoals GEMnet, SURFnet, Haagse Ring,
Suwinet, etc. De communicatie over Diginetwerk is niet afgeschermd. Om te zorgen
dat de communicatie afgeschermd is moet het transport tussen domeinen beveiligd
worden. Bij communicatie tussen de browser en Olo wordt eenzijdige SSL toegepast.
Bij berichtenverkeer met zowel bedrijven als overheden wordt tweezijdige SSL
toegepast.
Olo communiceert met bedrijven via Digipoort. Deze bedrijven koppelen met
Digipoort en bieden hier hun berichten aan. Digipoort zorgt dat deze berichten bij
Olo worden bezorgd. Antwoorden van Olo worden naar Digipoort gestuurd. Digipoort
zorgt er voor dat deze bij de juiste partij worden afgeleverd.
Pagina 54 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
5.3.1
5.3.2
Eisen koppelvlak
ID
Eis
TA03.1.01
[CA]
Olo maakt gebruik van een centraal koppelvlak voor Diginetwerk en internet.
TA03.1.02
[CA]
Communicatie van en naar andere overheidsorganisaties gebeurt via
Diginetwerk.
TA03.1.03
[CA]
Communicatie van en naar bedrijven gebeurt via internet en Digipoort.
TA03.1.04
[SP]
Directe toegang tot applicaties en databases is op netwerkniveau afgeschermd.
Eisen compartimentering
ID
Eis
TA03.2.01
[L]
Olo en componenten waar deze gebruik van maakt, dienen te voldoen aan de
compartimenteringseisen zoals beschreven in paragraaf 6.5 Compartimentering.
Pagina 55 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
6
Beveiliging en privacy
In dit hoofdstuk wordt ingegaan op beveiliging en privacy als pijlers voor een
betrouwbare dienstverlening. Betrouwbaarheid is in dit verband het inbouwen van
mechanismen die bescherming van informatie ten doel hebben.
6.1
Beveiligingsclassificatie
Voor de beveiligingsclassificatie wordt gebruik gemaakt van de BIV classificatie:

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.
Voor de behandeling van vertrouwelijke informatie bij de Rijksoverheid is een
aanvullende set van maatregelen van toepassing: Het Voorschrift Informatiebeveiliging – Bijzondere Informatie (VIR-BI). In dit voorschrift worden voor 4
categorieën van informatie extra eisen gesteld. Het betreft de volgende
beveiligingsniveaus:
1. Departementaal Vertrouwelijk
2. Staatsgeheim Confidentieel
3. Staatsgeheim Geheim
4. Staatsgeheim Zeer geheim
Het VIR-BI legt per beveiligingsniveau beveiligingseisen op aan de “beheerder” van
vertrouwelijke informatie.
6.1.1
Eisen beveiligingsclassificatie
ID
Eis
BV01.1.01
[L]
Gegevens zijn voorzien van een beveiligingsclassificatie op basis van de VIR-BI
en de Wet bescherming persoonsgegevens (Wbp). De persoonsgegevens in Olo
zijn geclassificeerd als vallend binnen risicoklasse 1 van de Wet bescherming
persoonsgegevens. De informatie wordt daarom versleuteld getransporteerd en
is alleen toegankelijk voor geautoriseerde gebruikers.
BV01.1.02
[L]
Gevoelige gegevens worden versleuteld als ze worden getransporteerd over het
netwerk. Bij communicatie tussen de browser en Olo wordt eenzijdige SSL
toegepast. Bij berichtenverkeer met bedrijven en overheden wordt tweezijdige
SSL toegepast.
BV01.1.03
De zender en ontvanger van gegevens authentiseren elkaar voordat gevoelige
Pagina 56 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
6.2
[CA]
gegevens worden uitgewisseld.
BV01.1.04
[L]
Gebruikersnamen, wachtwoorden of beveiligingssleutels, bijvoorbeeld OAuth
sleutels, worden versleuteld opgeslagen en uitgewisseld.
BV01.1.05
[L]
Productiedata die in een testsysteem worden ingelezen, dienen te worden
geanonimiseerd. Personen en organisaties mogen niet herleidbaar zijn.
Identity & Access Management (IAM)
Beveiliging is een belangrijk aspect. Vanuit onderhoudbaarheid en consistentie wordt
dit op één plek en éénmalig gedefinieerd. Beveiliging mag niet afhankelijk zijn van
de discipline van ontwikkelaars. Applicaties en beveiliging zijn daarom ontkoppeld.
6.2.1
Eisen identificatie en authenticatie
Bij berichtenverkeer met zowel bedrijven als overheden wordt tweezijdige SSL
toegepast. Bij tweezijdige SSL moet naast de server ook de client zich middels een
PKIoverheid certificaat identificeren. Hiermee wordt de identiteit van beide organisaties vastgesteld, zodat het vaststaat dat zij met elkaar mogen communiceren.
Autorisatie wordt gedaan door te controleren of de combinatie OIN uit het
PKIoverheid certificaat en de endpoint geautoriseerd is.
ID
Eis
BV02.1.01
[L]
Voor identificatie en authenticatie van burgers die inloggen in Olo, wordt
gebruik gemaakt van DigiD niveau basis of hoger.
BV02.1.02
[L]
Voor identificatie en authenticatie van bedrijven en overheden die inloggen in
Olo, wordt gebruik gemaakt van eHerkenning niveau 2 of hoger.
BV02.1.03
[L]
Voor identificatie en authenticatie van lokale beheerders van organisaties die
aangesloten zijn op Olo, wordt gebruik gemaakt van eHerkenning op basis van
niveau 2 of hoger.
BV02.1.04
[L]
Voor identificatie en authenticatie van landelijke beheerders wordt gebruik
gemaakt van Rijks Identity Provider.
BV02.1.05
[L]
eHerkenning ketenmachtiging wordt ondersteund. De Olo dienst is
geregistreerd als dienst “voor derden”. De aanvullende eHerkenning informatie
over de tussenliggende partij, gemachtigde ofwel intermediair, wordt
geregistreerd.
BV02.1.06
[L]
Het systeem ondersteunt inloggen middels gebruikersnaam en wachtwoord
voor buitenlandse gebruikers die geen DigiD of eHerkenning kunnen krijgen.
BV02.1.07
[L]
eHerkenning en DigiD zijn gekoppeld aan interne accounts. Interne accounts
hebben een eigen sleutel en kunnen aangevuld worden met aanvullende
gegevens. Hierdoor is het voor bijvoorbeeld ZZP’ers die over beide middelen
kunnen beschikken, mogelijk om te wisselen tussen beide middelen. Beide
middelen zijn aan hetzelfde interne account te koppelen door landelijk beheer.
BV02.1.08
[KB]
Voor elke applicatie van Olo (Regelbeheer, Loket en Samenwerkingsruimte)
zijn aparte eHerkenning diensten geregistreerd, waardoor autorisatie voor deze
onderdelen door de machtigende partij bij eHerkenning geregeld moet worden.
BV02.1.09
[CA]
Voor identificatie en authenticatie bij berichtuitwisseling (systemen) wordt bij
zowel bedrijven als overheden gebruik gemaakt van PKIoverheid certificaten.
BV02.1.10
[SP]
Bij authenticatie wordt gebruik gemaakt van Single Sign On (SSO) op basis
van SAML.
Pagina 57 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
6.2.2
BV02.1.11
[L]
Er is een herbruikbare beveiligingscomponent t.b.v. authenticatie en
autorisatie. Alle toegang tot applicaties verloopt via deze
beveiligingscomponent. Applicaties voeren zelf geen authenticatie en
autorisatie uit maar delegeren dit naar de beveiligingscomponent.
BV02.1.12
[L]
Bij DigiD geldt een maximum inactiviteit van 15 minuten voor de lokale sessie.
Het systeem zorgt dat de sessiegegevens van ingelogde gebruikers tussentijds
worden bewaard, zodat bij het verlopen van de sessie de gebruiker na het
opnieuw inloggen verder kan gaan waar deze gebleven was.
Eisen autorisatie
Ontkoppeling van applicatie en beveiliging zorgt dat autorisatie eenduidig en op de
juiste manier wordt afgedwongen ongeacht de ingang, interactiekanaal of laag.
ID
Eis
BV02.2.01
[L]
Toegang tot vertrouwelijke gegevens is geautoriseerd. Beveiligingsfunctionaliteit
is niet hard gecodeerd in programmacode. Er wordt gebruik gemaakt van de
Identity Server voor het vastleggen van autorisatie policies en het afdwingen
hiervan. Broncomponenten filteren gegevens op basis van aanwijzingen van de
autorisatiecomponent.
BV02.2.02
[L]
Autorisaties worden op basis van RBAC of XACML opgevraagd van de Identity
Server.
6.3
Toegang
6.3.1
Eisen toegang
6.4
ID
Eis
BV03.1.01
[L]
Applicaties en componenten voeren altijd een authenticatie en autorisatie check
uit van gebruikers, systemen of componenten die toegang willen krijgen tot
functionaliteiten of gegevens.
Monitoring, auditing en alerting
Monitoring omvat het vastleggen van gebeurtenissen en bijbehorende informatie
van acties die authenticatie en autorisatie vereisen. Bijvoorbeeld wie wanneer heeft
ingelogd en het operationeel monitoren en waarschuwen op basis van indicatoren in
bepaalde –voornamelijk verdachte– situaties. Monitoring is zowel van belang voor
operationele veiligheid als voor het voldoen aan wet- en regelgeving en de controle
daarvan achteraf, bijvoorbeeld via audits.
Om fouten op te sporen en om achteraf te kunnen zien of er ongeoorloofd gebruik
van de informatie heeft plaats gevonden wordt auditinformatie bijgehouden.
Hiermee is na te gaan wie, wanneer wat heeft gedaan.
Vanuit integriteits- en beveiligingsperspectief is het niet gewenst dat berichten
buiten het broncomponent worden gemanipuleerd. Hierdoor kan de herleidbaarheid
van handelingen en de betrouwbaarheid van de communicatie niet worden
gegarandeerd. Het introduceert het risico dat beheerders het berichtverkeer
Pagina 58 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
manipuleren. Daarnaast worden gegevens gecommuniceerd die niet (meer)
consistent zijn met de broncomponent.
Hetzelfde geldt voor gegevens. Als buiten de broncomponent gegevens worden
gemanipuleerd in de database, dan kan de herleidbaarheid van handelingen, de
betrouwbaarheid en consistentie niet worden gegarandeerd.
6.4.1
6.5
Eisen monitoring, auditing en alerting
ID
Eis
BV04.1.01
[L]
Alle handelingen van systemen, componenten en gebruikers zijn traceerbaar en
reproduceerbaar.
BV04.1.02
[L]
Berichten worden niet handmatig aangemaakt, gewijzigd of verwijderd buiten de
broncomponent. Componenten moeten functionaliteit bieden om berichten
indien nodig opnieuw aan te bieden.
BV04.1.03
[FB/KB/TB]
Gegevens in databases worden niet handmatig aangemaakt, gewijzigd of
verwijderd buiten de broncomponent.
BV04.1.04
[L]
Alle gebeurtenissen in het netwerk, platform en applicaties die authenticatie en
autorisatie vergen, worden (ook) vastgelegd in een centrale auditlog.
Uitgevoerde handelingen zijn herleidbaar tot op initiërend organisatie-,
persoons- of systeemniveau.
BV04.1.05
[SP]
Voor de centrale auditlog wordt gebruik gemaakt van een herbruikbare auditing
component die niet door reguliere beheerders te wijzigen is. Deze component
stelt een webinterface beschikbaar, waarmee beheerders auditinformatie kunnen
raadplegen en doorzoeken.
BV04.1.06
[SP]
De integriteit van auditinformatie is gewaarborgd.
BV04.1.07
[SP]
Auditinformatie wordt na een bepaalde periode automatisch verwijderd. De duur
van deze periode is per component instelbaar.
Compartimentering
Er wordt compartimentering toegepast. Tussen compartimenten wordt alleen noodzakelijke communicatie toegestaan. Het compromitteren van een server of applicatie
heeft hierdoor geen direct gevolgen voor componenten in andere compartimenten.
Door de gelaagde opbouw van applicaties (front-end, koppelingen, backend
ontsloten via webservices en gegevens) is compartimentering mogelijk. Het
beveiligingsniveau neemt per laag toe door communicatie tussen lagen te beperken
tot de aangrenzende laag. De interactielaag (front-end) communiceert met de
servicelaag (koppelingen), de servicelaag met de applicatielaag (backend ontsloten
via webservices) en de applicatielaag met de datalaag (gegevens). De front-ends,
hebben databasefunctionaliteit nodig. Hiervoor wordt een apart compartiment
ingericht dat wel vanuit de DMZ toegankelijk is.
De volgende zones (compartimenten) worden onderscheiden:

Red zone extern (DMZ): Front-ends en berichtengateway.

Red zone intern (DMZ): Gegevens van front-ends.
Pagina 59 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0

Orange zone: Koppelingen en backends.

Green zone: Backend gegevens.

Blue zone: Beheer componenten. Deze zone maakt gebruik van de databases in
de green zone.
Front-ends die alleen via het Rijksweb6 toegankelijk zijn, mogen in de Orange zone
geplaatst worden. Als een front-end via internet toegankelijk is, dan staat deze altijd
in de Red zone extern.
6.5.1
6.5.2
6.5.3
Eisen compartimentering
ID
Eis
BV05.1.01
[L]
Olo en de (herbruikbare) componenten kennen een gelaagde opbouw en
ondersteunen hiermee de voorgeschreven compartimentering zoals beschreven
in het document IMEA Katern Standaard Platform [SP].
Eisen toegang
ID
Eis
BTV05.2.01
[L]
Autorisaties worden geregeld op basis van rollen en niet op basis van personen.
Een gebruiker heeft één of meerdere rollen.
BV05.2.02
[L]
Olo en (herbruikbare) componenten moeten voldoen aan de eisen uit de
Baseline Informatiebeveiliging Rijksoverheid (BIR).
Eisen patchen en updates
Een solide updatemechanisme is essentieel om voldoende beschermd te zijn tegen
bekende beveiligingsproblemen in software. Naast een technische implementatie
van een dergelijk mechanisme is het ook van belang om een goede procedure in te
richten waarin beschreven staat hoe om te gaan met updates: hoe snel de
organisatie een kritieke patch implementeert, welke procedure de patch moet
doorlopen en wie de verantwoordelijkheid draagt.
ID
Eis
BV05.3.01
[L/AB/TB]
Leverancier, applicatiebeheerder en technisch beheer zijn verantwoordelijk voor
het monitoren van security waarschuwingen en patches op de door hun
beheerde software, componenten en libraries.
BV05.3.02
[L/AB/TB]
Een security patch dient binnen 30 dagen na beschikbaar komen door de
leverancier, applicatiebeheerder en technisch beheer te zijn getest en aan IenM
beschikbaar te worden gesteld als nieuwe release.
BV05.3.03
[L]
Applicaties moeten minimaal voldoen aan de Open Web Application Security
Project (OWASP) top 10. Er moet voldaan worden aan de top 10 voor
webapplicaties en mobiele applicaties.
BV05.3.04
[L]
Applicaties moeten voldoen aan de ICT beveiligingsrichtlijnen voor
webapplicaties van het Nationaal Cyber Security Centrum (NCSC).
6. VPN op de Haagse ring met vertrouwelijkheidsniveau Departementaal Vertrouwelijk (Dep V). Zie begrippenlijst
VIR-BI.
Pagina 60 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
Pagina 61 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
7
Beheer
In dit hoofdstuk wordt ingegaan op beheer als een van de pijlers van een betrouwbare serviceverlening.
Voor IenM is beheer een zeer belangrijk aspect bij het realiseren van systemen en
componenten. Er dient veel aandacht besteed te worden aan het realiseren van een
beheerbare en beheersbare oplossing. Daarbij geldt dat alleen technische beheerders toegang hebben op systeemniveau. Voor beheerhandelingen die door andere
beheerders uitgevoerd dienen te worden, moet een webgebaseerde beheerfunctionaliteit beschikbaar zijn.
7.1
Formalisering afspraken
Olo maakt gebruik van een groot aantal (herbruikbare) componenten. Gebruik van
herbruikbare componenten betekent dat het eigenaarschap niet bij één systeemeigenaar ligt. Dit biedt voordelen: afnemende systemen liften mee op doorontwikkelingen van herbruikbare componenten. Maar ook nadelen: er is een
afhankelijkheid en er is onderlinge afstemming (afnemersoverleg) nodig als een
afnemer een wijziging wil in de functionaliteit van een herbruikbare component.
Afhankelijkheden worden beperkt door bij de communicatie met herbruikbare
componenten gebruik te maken van een gestandaardiseerd product en technologie
neutraal koppelvlak. Hierdoor kunnen herbruikbare componenten onafhankelijk van
afnemers doorontwikkelen door een nieuw koppelvlak aan te bieden. Afnemers
moeten binnen de afgesproken periode migreren naar het nieuwe koppelvlak.
Standaard is deze periode een jaar.
Figuur 22. Beheermodel
Pagina 62 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
In bovenstaande afbeelding zijn de verschillende beheerverantwoordelijkheden voor
de diverse component types weergegeven. Olo is qua beheer complexer omdat dit
bij verschillende organisaties belegd is (IenM, RWS en DICTU). Om het geheel
beheersbaar en beheerbaar te houden, dient voor alle partijen helder te zijn hoe het
beheer van Olo en de herbruikbare componenten belegd is en wie waarvoor
verantwoordelijk is.
7.1.1
7.2
Eisen formalisering afspraken
ID
Eis
BH01.1.01
[SM]
Beheer van Olo en de (herbruikbare) componenten is duidelijk belegd en
geborgd in een DAP en SLA’s.
BH01.1.02
[SM]
SLA en QoS van de systemen, componenten en services zijn gedefinieerd en
geborgd.
BH01.1.03
[L]
(Herbruikbare) componenten kennen een eigen ontwikkel en release cyclus en
een eigen goed gedefinieerd leverancier en technologie neutraal koppelvlak.
BH01.1.04
[SM/FB/KB]
Standaard worden 2 voorgaande versies van een koppelvlak ondersteund na het
beschikbaar komen van een nieuwe versie van het koppelvlak, voor de periode
van maximaal 1 jaar voor elke afzonderlijke versie. Afnemers van services van
een (herbruikbare) component bepalen zelf het moment waarop ze binnen deze
periode migreren naar een nieuwe versie.
BH01.1.05
[L]
Olo en (herbruikbare) componenten zijn overdraagbaar. Dit betekent dat deze
opgeleverd worden met documentatie die voldoet aan de kwaliteitseisen en
voldoende diepgang hebben zodat een andere partij met minimale overdracht
het applicatiebeheer over kan nemen. Zie hiervoor het document [Beheerst naar
beheer].
Zelfbediening
Om de beheerlast te beperken en te zorgen dat organisaties snel en adequaat
wijzigingen kunnen doorvoeren in hun eigen gegevens, wordt gestreefd naar
maximale zelfbediening. Hierdoor zijn organisaties zelf ‘in control’ en worden de
afhankelijkheden tussen organisaties onderling beperkt.
7.2.1
Eisen zelfbediening
ID
Eis
BH02.1.01
[L]
Er wordt gebruik gemaakt van een decentraal beheermodel. Landelijk
beheerders van Olo koppelen beheeraccounts aan een organisatie.
BH02.1.02
[L]
Elke organisatie heeft eigen beheeraccounts waarmee zij zelf hun
organisatie specifieke zaken inrichten, zoals: toekennen van rollen aan
gebruikers, aanmaken van contactpersonen, beheren contactgegevens, de
wijze waarop aanvragen uitgewisseld worden, koppelen van services et
cetera.
BH02.1.03
[L]
Een gebruiker die eigenaar is van een projectdossier of werkdossier kan
andere gebruikers hiervoor machtigen.
BH02.1.04
[SP]
Gebruikers met een specifieke Olo inlogaccount kunnen hun eigen
wachtwoord resetten. DigiD, eHerkenning en Rijks IdP hebben hier eigen
procedures voor.
Pagina 63 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
7.3
Lifecycle management
7.3.1
Eisen lifecycle management
7.4
ID
Eis
BH03.1.01
[SM]
Voor elke omgeving dient een goed gedefinieerd acceptatieproces te bestaan.
Daarin is o.a. beschreven welke documenten aanwezig moeten zijn, waar
documenten aan moeten voldoen, wie akkoord geeft om door te gaan naar de
volgende omgeving, et cetera.
BH03.1.02
[SM]
Om het ontwikkel- en releaseproces te ondersteunen en te allen tijde over
betrouwbare en beheersbare systemen te beschikken, wordt het OTAPprincipe toegepast.
BH03.1.03
[SM]
OTAP+ omgevingen zijn gescheiden. Een release of change doorloopt altijd
alle OTAP+ omgevingen voordat deze in productie gaat. Verantwoordelijkheid
voor acceptatie en goedkeuring voor de overgang naar de volgende omgeving
is per omgeving gescheiden.
BH03.1.04
[L]
Software en configuratie zijn gescheiden. Het systeem en de componenten
zijn parametriseerbaar en bevatten geen hard gecodeerde verwijzingen.
Zelfbeheer en beheerketen samenwerking
De centrale monitoring functionaliteit van het Standaard Platform controleert continu
de gezondheid van applicaties, systemen en componenten. Beheerders krijgen
notificaties bij verstoringen van componenten of bij overschrijding van
drempelwaarden van responsetijden.
7.4.1
Eisen zelfbeheer en beheerketen samenwerking
ID
Eis
BH04.1.01
[L]
Ontwikkelaars en beheerders hebben geen toegang op systeemniveau (OS en
middleware componenten). Het uitvoeren van bijvoorbeeld scripts op systeemniveau door andere partijen dan technisch beheer is niet mogelijk. Beheerhandelingen dienen vanuit een webgebaseerde beheerconsole uitgevoerd te
worden.
BH04.1.02
[L]
Componenten loggen naar een centrale logging component. Deze component
biedt een webgebaseerde UI die toegang geeft tot de logging data en maakt
deze doorzoekbaar. Logging informatie stelt beheerders in staat om zelfstandig
de oorzaak van problemen te herleiden. Deze component stelt een webinterface
beschikbaar waarmee beheerders loginformatie kunnen raadplegen en
doorzoeken. Elk component in de keten logt van een verzoek het bericht ID en
andere relevante informatie, zodat een verzoek in de keten te volgen is.
BH04.1.03
[L]
Van een component is bekend op welke aspecten de monitoring dient plaats te
vinden, zodat de monitoringtool hierop ingericht kan worden. De leverancier is
verantwoordelijk voor het aanleveren van deze informatie.
BH04.1.04
[L]
Elke component stelt voor de standaard monitoring een health REST service met
JSON response beschikbaar, waarmee de status van de component opgevraagd
kan worden. Deze status informatie geeft de operationele status weer van de
component zelf en componenten waar deze gebruik van maakt. Dit betreft
informatie zoals versienummer, status (OK of NOK), gemiddelde responsetijd,
etc. Zie het document IenM – Standaard Platform – Aansluitvoorwaarden
Applicaties en Componenten.
Pagina 64 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
BH04.1.05
[SP]
7.5
Beheerders worden genotificeerd bij verstoringen van componenten of bij
overschrijding van drempelwaarden van responsetijden.
Service levels
In de onderstaande paragrafen zijn de gewenste service levels ten aanzien van de
aspecten beschikbaarheid, incident afhandeling en performance opgenomen.
7.5.1
Beschikbaarheid
De volgende term wordt gebruikt:

Calamiteit: Een gebeurtenis die haar oorzaak heeft buiten Olo en die de
dienstverlening aanzienlijk of totaal ontregelt. Voorbeelden van calamiteiten zijn:
(regionale) stroomstoring, uitval van externe datacommunicatielijnen, brand in
gebouwen, explosie, evacuatie.
7.5.2
Eisen productie
Voor de productieomgeving gelden de volgende beschikbaarheidseisen.
ID
Onderdeel
Eis
BH05.1.01
[L/SP]
Loket
Het Loket is 7 dagen per week, 24 uur per dag
beschikbaar.
Gegarandeerde beschikbaarheid:
Elke dag van het jaar tussen 6:00 en 0:00 uur: 99,8%,
met uitzondering van calamiteiten, zie ‘calamiteiten’.
De percentages worden op maandbasis berekend.
BH05.1.02
[L/SP]
Samenwerkingsruimte
De Samenwerkingsruimte is 7 dagen per week, 24 uur
per dag beschikbaar.
Gegarandeerde beschikbaarheid:
Op werkdagen tussen 8:00 en 18:00 uur: 99,8%, met
uitzondering van calamiteiten, zie ‘calamiteiten’.
De percentages worden op maandbasis berekend.
BH05.1.03
[L/SP]
Regelbeheer
voorziening
De Regelbeheer voorziening is 7 dagen per week, 24 uur
per dag beschikbaar.
Gegarandeerde beschikbaarheid:
Op werkdagen tussen 8:00 en 18:00 uur: 99,8%, met
uitzondering van calamiteiten, zie ‘calamiteiten’.
De percentages worden op maandbasis berekend.
7.5.3
Eisen overige omgevingen
Voor de overige omgevingen gelden de volgende beschikbaarheidseisen.
ID
Onderdeel
Eis
BH05.2.01
[SP]
Staging
Gelijk aan productieomgeving.
Pagina 65 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
BH05.2.02
[SP]
Acceptatie
De Acceptatie omgeving is 7 dagen per week, 24 uur per
dag beschikbaar.
Gegarandeerde beschikbaarheid op werkdagen tussen
8:00 en 18:00 uur: 99,8%, met uitzondering van
calamiteiten, zie ‘calamiteiten’.
Voor de periode dat acceptatietesten plaatsvinden worden
afspraken gemaakt voor een gegarandeerde
beschikbaarheid buiten bovengenoemde dagen en
tijdstippen.
De percentages worden op maandbasis berekend.
BH05.2.03
[SP]
Preproductie
De Preproductie omgeving is 7 dagen per week, 24 uur
per dag beschikbaar.
Gegarandeerde beschikbaarheid in de periode dat
implementaties van nieuwe releases plaatsvinden:
Op werkdagen tussen 8:00 en 18:00 uur: 99,8%, met
uitzondering van calamiteiten, zie ‘calamiteiten’.
Voor bepaalde perioden waarin de preproductie omgeving
van belang is, bijvoorbeeld bij het inregelen van lokale
instellingen n.a.v. een nieuwe release, worden afspraken
gemaakt voor een gegarandeerde beschikbaarheid buiten
bovengenoemde dagen en tijdstippen.
De percentages worden op maandbasis berekend.
7.5.4
Gepland onderhoud
Gepland onderhoud is van invloed op de beschikbaarheid. De volgende vormen van
gepland onderhoud worden onderscheiden:

Onderhoud van de infrastructuur: Doorvoeren van benodigde wijzigingen in
hardware én (systeem)software componenten als gevolg van externe
ontwikkelingen (buiten het ondersteunde bedrijfsproces), bijvoorbeeld het
vervangen van hardware of het implementeren van een nieuwe versie van een
(systeem)software component.

Correctief onderhoud: Verbetering van ontdekte fouten.

Doorvoeren van standaard wijzigingen: Hieronder vallen in ieder geval handelingen die moeten worden uitgevoerd om wijzigingen in productiegegevens door
te voeren, voor zover deze niet door de functioneel beheerder van Olo zelf
kunnen worden doorgevoerd. DCI en RWS-Leefomgeving spreken in een later
stadium (als de Olo oplossing duidelijk is) af welke standaard wijzigingen worden
onderkend.

Implementatie van nieuwe versies: Release van een of meerdere voorzieningen
binnen Olo.
Voor deze vormen van onderhoud gelden de onderstaande afspraken c.q. normen.
Pagina 66 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
7.5.5
Eisen gepland onderhoud
ID
Eis
BH05.3.01
[SP]
Onderhoud van de infrastructuur:

Maximaal 6 keer per jaar.

Vindt plaats buiten de gegarandeerde beschikbaarheid tijden van de
genoemde voorzieningen, zie ‘beschikbaarheid’.

Wordt minimaal 15 werkdagen van te voren aangekondigd aan
RWS-Leefomgeving.

BH05.3.02
[SP]
Wordt gepland in overleg met RWS-Leefomgeving.
Correctief onderhoud:

Vindt plaats buiten de gegarandeerde beschikbaarheid tijden van de
genoemde voorzieningen, zie ‘beschikbaarheid’.

BH05.3.03
[SP]
Wordt gepland in overleg met RWS-Leefomgeving.
Doorvoeren van standaard wijzigingen:

Vindt plaats buiten de gegarandeerde beschikbaarheid tijden van de
genoemde voorzieningen, zie ‘beschikbaarheid’.

BH05.3.04
[DCI FB,
RWSL FB]
Wordt gepland in overleg met RWS-Leefomgeving.
Release software:
Het SP biedt automatische uitrol, waardoor Olo de flexibiliteit heeft om elk
moment een nieuwe release van een applicatie of component uit te rollen (uitrollen van nieuwe versies). Er worden hierbij geen beperkingen opgelegd.
Bij herbruikbare componenten is de DCI beheerder verantwoordelijk voor de
uitrol. Het is de keuze van de DCI beheerder op welk moment het uitrollen
plaatsvindt. Hierbij wordt overleg gevoerd met de afnemers van de component.
Voor Olo applicaties is de RWSL beheerder verantwoordelijk voor de uitrol. Het is
de keuze van de RWSL beheerder op welk moment het uitrollen plaatsvindt.
RWSL kiest er voor om dit buiten de gegarandeerde beschikbaarheid tijden van
de genoemde voorzieningen uit te voeren, zie ‘beschikbaarheid’. Uitrollen binnen
de gegarandeerde beschikbaarheid tijden mag alleen na goedkeuring van RWSL,
waarbij het Loket maximaal 24 uur (per keer) niet beschikbaar mag zijn. De tijd
om uit te rollen die binnen de gegarandeerde beschikbaarheid tijden valt, telt
niet mee in de berekening van de beschikbaarheid percentages (heeft dus geen
negatief effect hierop).
7.5.6
Eisen gegevensverlies
Mocht als gevolg van een incident gegevens verloren gaan, dan gelden hiervoor de
volgende normen.
ID
Onderdeel
Eis
BH05.4.01
[L]
Loket
De maximaal toelaatbare gegevensverlies periode is 0,5
uur per incident met een maximum van 4 keer per jaar.
BH05.4.02
[L]
Samenwerkingsruimte
behandelaars
De maximaal toelaatbare gegevensverlies periode is 0,5
uur per incident met een maximum van 4 keer per jaar.
BH05.4.03
[L]
Regelbeheer
voorziening
De maximaal toelaatbare gegevensverlies periode is 1,0
uur per incident met een maximum van 4 keer per jaar.
Pagina 67 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
7.5.7
Incident afhandeling
De impact en urgentie van een incident zijn leidend bij de bepaling van de prioriteit
waarmee een incident wordt verholpen. Hiertoe wordt bij aanmelding van het
incident de urgentie en impact in overleg met de aanmelder vastgesteld volgens de
onderstaande normering.
7.5.7.1
Urgentie
De mate waarin oplossing van de verstoring uitstel kan verdragen.
7.5.7.2
Urgentie
Toelichting
Hoog
Oplossing incident kan geen uitstel verdragen als de uitkomsten van het loket
niet overeenstemmen met de wet- en regelgeving. Voorbeeld: de
vergunningcheck geeft een onjuiste uitkomst over het niet nodig hebben van een
vergunning terwijl deze wel nodig is.
Hoog
Oplossing incident kan geen uitstel verdragen omdat betrokkenen de
functionaliteit in zijn geheel niet meer kunnen gebruiken. Voorbeelden: het is
voor een aanvrager onmogelijk om een vergunningaanvraag/melding te doen,
het is voor behandelende organisatie onmogelijk de aanvraag/melding te
ontvangen en in behandeling te nemen, RWS-Leefomgeving kan de Regelbeheer
voorziening niet gebruiken.
Midden
Oplossing incident kan enig uitstel verdragen bijvoorbeeld omdat er binnen de
applicatie een workaround aanwezig is of betrokkenen nog deels gebruik kunnen
maken van de functionaliteit, waardoor de processen doorgang kunnen vinden.
Laag
Oplossing incident kan uitstel verdragen bijvoorbeeld omdat betrokkenen de
functionaliteit wel kunnen gebruiken maar de werking enigszins verstoord is
(bijvoorbeeld slechte performance).
Impact
De impact wordt bepaald door de omvang van de verstoring, zijnde het aantal
gebruikers dat getroffen is.
7.5.7.3
Impact
Toelichting
Hoog
Alle of een zeer groot aantal gebruikers en/of behandelende overheden en/of
medewerkers van RWS-Leefomgeving zijn getroffen door de verstoring.
Midden
Een substantieel aantal gebruikers en/of behandelende overheden en/of
medewerkers van RWS-Leefomgeving is getroffen door de verstoring.
Laag
Eén of enkele gebruikers zijn getroffen door de verstoring.
Prioriteit
De prioriteit wordt op basis van urgentie en impact aan de hand van volgende tabel
bepaald.
Prioriteit
Impact
Urgentie
Hoog
Midden
Laag
Hoog
M
1
2
Midden
1
2
3
Laag
2
3
3
Prioriteit: M = Major, 1 = Hoog, 2 = Midden, 3 = Laag
Pagina 68 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
7.5.7.4
Normen oplostijden
De oplostijd van een incident wordt bepaald door de toegekende prioriteit en kent de
volgende normen.
Prioriteit
Oplostijd
90% binnen
Oplostijd
100% binnen
Status
updates
Gereed melden
na oplossen
binnen
Major( M)
2 uren
4 uren
Ieder uur
15 minuten
Hoog (1)
4 werkdaguren
8 werkdaguren
Ieder uur
15 minuten
Midden (2)
3 werkdagen
5 werkdagen
15 minuten
Laag (3)
10 werkdagen
15 werkdagen
15 minuten
7.5.8
Performance
7.5.9
Eisen performance loket
ID
Eis
Norm
BH05.5.01
[L]
Tonen van de homepagina
98% binnen 5 sec
BH05.5.02
[L]
Inloggen en tonen van het hoofdscherm
98% binnen 8 sec
BH05.5.03
[L]
Opvragen van een overzicht met projectdossiers
98% binnen 5 sec
BH05.5.04
[L]
Aanmaken projectdossier na invoeren gegevens
98% binnen 8 sec
BH05.5.05
[L]
Nieuwe aanvraag aanmaken binnen een bestaand
projectdossier na invoeren gegevens
98% binnen 8 sec
BH05.5.06
[L]
Openen van een projectdefinitie
98% binnen 5 sec
BH05.5.07
[L]
Openen van een aanvraag
98% binnen 5 sec
BH05.5.08
[L]
Zoeken naar een aanvraag
98% binnen 5 sec
BH05.5.09
[L]
Zoeken naar documenten in een aanvraag
98% binnen 5 sec
BH05.5.10
[L]
Downloaden van een document (ordergrootte 1 MB) in
een dossier of een aanvraag
98% binnen 8 sec
BH05.5.11
[L]
Het aantal gelijktijdige gebruikers
4000 gebruikers
BH05.5.12
[L]
Het aantal aan te maken projectdossiers per dag
1000, met een piek
van 2000
BH05.5.13
[L]
Het aantal in te dienen aanvragen per dag
750, met een piek
van 1500
Pagina 69 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
7.5.10
7.5.11
Eisen Samenwerkingsruimte
ID
Eis
Norm
BH05.6.01
[L]
Tonen van de homepagina
98% binnen 5 sec
BH05.6.02
[L]
Inloggen en tonen van het hoofdscherm
98% binnen 8 sec
BH05.6.03
[L]
Opvragen van een overzicht met werkdossiers
98% binnen 5 sec
BH05.6.04
[L]
Aanmaken van een werkdossier na invoeren gegevens
98% binnen 8 sec
BH05.6.05
[L]
Openen van een werkdossier
98% binnen 5 sec
BH05.6.06
[L]
Opvragen van een overzicht met aanvragen
98% binnen 5 sec
BH05.6.07
[L]
Openen van een aanvraag
98% binnen 5 sec
BH05.6.08
[L]
Zoeken naar een aanvraag
98% binnen 5 sec
BH05.6.09
[L]
Zoeken naar documenten in een aanvraag
98% binnen 5 sec
BH05.6.10
[L]
Downloaden van een document (ordergrootte 1 MB) in
een dossier of een aanvraag
98% binnen 8 sec
BH05.6.11
[L]
Het aantal gelijktijdige gebruikers
4000 gebruikers
BH05.6.12
[L]
Het aantal aan te maken werkdossiers per dag
750, met een piek
van 1500
Eisen Centraal Aansluitpunt
De beschreven eisen aan het Centraal Aansluitpunt (CA) gelden alleen wanneer de
Basisregistraties (BR) hun SLA afspraken nakomen. Het CA biedt waar mogelijk een
failover mechanisme waarop teruggevallen kan worden bij niet beschikbaar zijn van
of niet voldoen aan de responsetijden door de BR’s.
ID
Eis
BH05.7.01
[CA]
Het opvragen van gegevens uit de Gemeentelijke Basisadministratie (GBA) /
Basisregistratie Personen (BRP): in normale uren in 90% een responsetijd
binnen 5 sec, in piekuren in 98% een piekresponstijd binnen 10 sec.
BH05.7.02
[CA]
Het opvragen van gegevens uit de Nieuw Handelsregister (NHR): in normale
uren in 90% een responsetijd binnen 5 sec, in piekuren in 98% een piekresponstijd binnen 10 sec.
BH05.7.03
[CA]
Het opvragen van gegevens uit de Basisregistratie Adressen en Gebouwen
(BAG): in normale uren in 90% een responsetijd binnen 5 sec, in piekuren in
98% een piekresponstijd binnen 10 sec.
BH05.7.04
[CA]
Het opvragen van gegevens uit de Basisregistratie Kadaster (BRK): in normale
uren 90% een responsetijd binnen van 5 sec, in piekuren 98% een piekresponstijd binnen 10 sec.
Pagina 70 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
7.6
Rapportages
Er wordt over de kwaliteit van de dienstverlening gerapporteerd. Dit betekent dat er
gemonitord en gerapporteerd wordt over hoe de verschillende Olo onderdelen en
(herbruikbare) componenten presteren.
7.6.1
7.6.2
Eisen rapportages
ID
Eis
BH06.1.01
[SP]
Voor het rapporteren wordt aangesloten op de monitorings- en rapportagefunctionaliteit van het Standaard Platform.
BH06.1.02
[SM]
Er wordt maandelijks gerapporteerd over de hiervoor benoemde service levels.
BH06.1.03
[SM]
Er wordt gerapporteerd op componentniveau en geaggregeerd op Olo niveau.
BH06.1.04
[SM]
Er wordt gerapporteerd over de beschikbare capaciteit en de belasting hiervan.
BH06.1.05
[TB]
Er wordt gerapporteerd over incidenten.
BH06.1.06
[SM]
Er wordt gerapporteerd over deployments.
BH06.1.07
[SM]
Er wordt gerapporteerd over gebruiksstatistieken van webservices.
Eisen testen en accepteren
Het testen en accepteren van wijzigingen wordt releasematig aangepakt volgens een
gestructureerde methodiek. Een load en stress test toont aan dat applicaties en
(herbruikbare) componenten voldoen aan de prestatie-eisen en dat zij schaalbaar en
robuust zijn. Om gebruik te maken van het Standaard Platform moeten Olo en de
(herbruikbare) componenten voldoen aan de volgende eisen.
ID
Eis
BH06.2.01
[L]
Elke release van een applicatie en (herbruikbare) component wordt opgeleverd
met geautomatiseerde testscripts om zowel de UI alsook de webservices
functioneel te testen. Deze geautomatiseerde tests worden gebruikt om een
geautomatiseerde regressietest uit te voeren. De UI wordt automatisch getest
met behulp van Selenium. Koppelingen en webservices worden automatisch
getest met behulp van SoapUI.
BH06.2.02
[L]
Elke release van een applicatie en (herbruikbare) component wordt opgeleverd
inclusief source code en build scripts van alle maatwerk ontwikkelingen. De
source code moet succesvol gecompileerd kunnen worden en wordt
doorgemeten op de technische kwaliteit op basis van Sonar. Alleen als de source
code door deze controles komt wordt een release geaccepteerd.
BH06.2.03
[L]
De leverancier levert de load en stress tests aan als onderdeel van de release.
Dit wordt gedaan op basis van JMeter voor de UI en LoadUI voor webservices.
BH06.2.04
[L]
Afhankelijk van de grootte of impact (bepaalt door FB) van een release behoort
een load en stress test tot het acceptatieproces om van de acceptatie- naar
productieomgeving te gaan.
BH06.2.05
[L]
Elke release van een applicatie en (herbruikbare) component wordt opgeleverd
met alle documenten die nodig zijn om de release in beheer te nemen en te
Pagina 71 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
zorgen dat deze overdraagbaar is. Zie het document [Beheerst naar Beheer].
7.6.3
Eisen aansluitvoorwaarden
ID
Eis
BH06.3.01
[L]
Voorzieningen (platform, applicatie, services, componenten) moeten voldoen
aan de Aansluitvoorwaarden om te worden geplaatst in of aangesloten te
worden op de IenM infrastructuur. Onderdeel van het acceptatieproces is het
toetsen aan de Aansluitvoorwaarden. Alleen als hieraan voldaan is, mag een
systeem in productie genomen worden.
Pagina 72 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
8
Bijlage A: Olo basisplaat
Pagina 73 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
9
Bijlage B: Functioneel componentenmodel Regelbeheer
Pagina 74 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
10
Bijlage C: Functioneel componentenmodel Loket
Pagina 75 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
11
Bijlage D: Functioneel componentenmodel
Samenwerkingsruimte
Pagina 76 van 77
Definitief | Omgevingsloket online 3 - Project Start Architectuur | Versie 1.0
12
Bijlage E: Voorbeeld kernbericht opbouw
Pagina 77 van 77

Financieel kompas.

* Ml 20Ï3 - Over Fred en Zo

.Net Web Developer

Hoofdklasse poule 1

De droom van De Atleetfabriek is om mensen een geluksgevoel te

Algemeen directeur Kwaliteitscoördinator Preventieadviseur

Financieel administratief medewerker

2014Lokaal04 - Klantvriendelijk, dat omgevingsloket

Lees de nieuwsbrief 2014-02

Het verhaal van de EA