Ministerie van Infrastructuur en Milieu Omgevingsloket online 3 - Project Start Architectuur

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


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


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


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


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


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 weten 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


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




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


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: weten 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 weten 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




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


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


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 vergunningen 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 vergunningen 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


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 vergunningen 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 vergunningen 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


3.2.2

Producten

3.2.2.1

Bepalen vergunningen meldingplicht Wabo en Waterwet Burgers en bedrijven kunnen met behulp van de dienst ‘bepalen vergunningen 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


Deze dienst levert de volgende digitale producten: 

Toepasbare beslisbomen: bestand met content, relaties en regels voor toepassing als vergunningen 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 vergunningen 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




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 weten 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




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


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


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


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 weten regelgeving in een configuratie die in het Loket toepasbaar is. Business functies De specifieke business functies zijn weten 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


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


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


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


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 weten regelgeving (Wabo en Waterwet). Het toepasbaar maken van deze weten 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 vergunningen 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


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


4.1.5

[L]

kunnen werken en kent een eigen ontwikkelen 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 ontwikkelen 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 ontwikkelen 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


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 ontwikkelen 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


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


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


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


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 weten 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


Figuur 15. Koppelingen met het Loket

Toelichting op de weergegeven koppelingen: 

Aanleverende systemen: koppelingen voor het aanleveren van checken 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




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


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


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


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-, openen 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


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


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


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


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


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 open 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


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


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


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


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


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 (open afschakelen) om met de onvoorspelbaarheid van het gebruik van de voorziening om te gaan.

Pagina 49 van 77


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 (open afgeschakeld kunnen worden) op basis van het werkelijk gebruik.

Pagina 50 van 77


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


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


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


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


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


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


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


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 weten 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


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




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


Pagina 61 van 77


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


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


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 ontwikkelen 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


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


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


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:




 BH05.3.03 [SP]


Doorvoeren van standaard wijzigingen:




 BH05.3.04 [DCI FB, RWSL FB]


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


BH05.4.03 [L]

Regelbeheer voorziening


Pagina 67 van 77


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 weten 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


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


Pagina 69 van 77


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


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


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


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


8

Bijlage A: Olo basisplaat

Pagina 73 van 77


9

Bijlage B: Functioneel componentenmodel Regelbeheer

Pagina 74 van 77


10

Bijlage C: Functioneel componentenmodel Loket

Pagina 75 van 77


11

Bijlage D: Functioneel componentenmodel Samenwerkingsruimte

Pagina 76 van 77


12

Bijlage E: Voorbeeld kernbericht opbouw

Pagina 77 van 77

Ministerie van Infrastructuur en Milieu Omgevingsloket online 3 - Project Start Architectuur

Recommend Documents