Projectstartarchitectuur Digilevering. Definitief versie 1.2

Transcriptie

1 Projectstartarchitectuur Digilevering Definitief versie 1.2

2 Projectstartarchitectuur Digilevering Auteur Team RENOIR Versie 1.2 Den Haag, 11 maart 2010

3 Projectstartarchitectuur Digilevering 3/112 Versiebeheer Versie Datum Auteur Status maart 2010 Team RENOIR Definitief februari 2010 Team RENOIR Concept t.b.v. vooraankondiging offerteaanvraag Hoofdstuk 6 Informatiebeveiliging nader gedetailleerd Paragraaf bericht-id en OIN afzender uit berichtspecificatie gehaald december 2009 Team RENOIR Definitieve versie november 2009 Team RENOIR Conceptversie ten behoeve van de oplevering aan de Stelsel Stuurgroep (1 december 2009) oktober 2009 Team RENOIR Conceptversie ten behoeve van de oplevering aan de opdrachtgever, Stelseloverleg, Stelselgebruikersoverleg, werkgroep en andere belanghebbenden oktober 2009 Rob Stovers, Roland Wessel 'Bevroren' tussenversie tbv Risicoanalyse. Reviewresultaten werkgroep Digilevering en impactanalyse mgba verwerkt. Review door deelnemers werkgroep Digilevering augustus 2009 Rob Stovers Resultaten werkgroep Autorisatie verwerkt. Hoofdstuk 2 toegevoegd. Versie t.b.v. Review door deelnemers werkgroep Digilevering juli 2009 Rob Stovers Versie ten behoeve van de werkgroep Digilevering m.b.t. autorisatie van 4 augustus juli 2009 Rob Stovers, Roland Wessel 2e versie ter bespreking met de werkgroep Digilevering van 14 juli juni 2009 Rob Stovers, Roland Wessel 1e versie ter bespreking met de werkgroep Digilevering van 30 juni 2009.

4 Projectstartarchitectuur Digilevering 4/112 Inhoud 1 Inleiding Doel en doelgroep Werkwijze Opbouw van dit document 7 2 Project Beschrijving context Huidige situatie Digilevering op hoofdlijnen Uitgangspunten 16 3 Bedrijfsarchitectuur Digilevering Organisatie Registratiehouders, houders landelijke voorziening en afnemers Serviceorganisatie Digilevering Verantwoordelijkheden Relevante NORA-principes Diensten, producten en services Relevante NORA-principes Services Processen Relevante NORA-principes Beschrijving primaire processen Ondersteunende (of secundaire) processen 33 4 Informatie-architectuur Ontwerpbeslissingen Mensen en applicaties Toepassing relevante NORA-principes Interface: mens en/of applicatie? Functionaliteit Digilevering Autorisatie Berichten en gegevens Relevante NORA-principes Objecten Gegevens Berichten Informatie-uitwisseling Relevante NORA-principes Gebruik van OSB

5 Projectstartarchitectuur Digilevering 5/112 5 Technische architectuur Relevante NORA-principes Applicatie architectuur Overzicht Digilevering Portaal Inleiding Overzicht Gebruikersinterface Beveiliging Koppeling met de Stelselcatalogus Digilevering Core Inleiding Overzicht Webservices Berichtvolgorde Beveiliging Koppelingen externe systemen Logische opbouw Technische infrastructuur Overzicht 79 6 Beveiliging NORA Interne oriëntatie Bedrijfsstrategie en doelstellingen Informatieclassificatie Risico's voor de organisatie Externe oriëntatie Wet en regelgeving Contractuele eisen ISO/IEC NORA Algemene beveiligingsprincipes NORA-principes ICT-voorzieningen 91

6 Projectstartarchitectuur Digilevering 6/112 1 Inleiding 1.1 Doel en doelgroep Dit document beschrijft de startarchitectuur van Digilevering (voorheen de GOB Abonnementenvoorziening). De startarchitectuur is bedoeld om de keuzes helder te maken die ten grondslag liggen aan het ontwerp. Daarmee geeft het inzicht in de functionele en technische (on)mogelijkheden. De startarchitectuur beschrijft de op te leveren producten en diensten, bedrijfsprocessen, informatiesystemen en ICT-infrastructuren. Dit document wordt gebruikt: Om de uitgangspunten, principes en ontwerpkeuzes vast te stellen ten behoeve van functioneel en technisch ontwerp en verdere inrichting; De gemaakte keuzes te valideren bij besluitvorming; De ingezette richting en gemaakte keuzes te communiceren met registratiehouders en afnemers van Digilevering. De doelgroep bestaat uit: programmamanagement RENOIR; opdrachtgever; stelseloverleg; gebruikersoverleg stelsel; strategisch stelselberaad; werkgroep Digilevering (voorheen de werkgroep GOB Abonnementenvoorziening); architecten en managers van registratiehouders en overheidsorganisaties die betrokken zijn bij de aansluiting op het stelsel van basisregistraties; functioneel en technisch ontwerpers, betrokken bij de verdere ontwikkeling van Digilevering. 1.2 Werkwijze Tijdens het realiseren van deze projectstartarchitectuur (en ook het functioneel ontwerp) Digilevering heeft regelmatige afstemming plaatsgevonden met de werkgroep Digilevering, met daarin deelname van KvK (NHR), Belastingdienst, Logius (voorheen GBO.Overheid), Justitie, VROM (Kadaster en BAG), RDW, RNI, Waarderingskamer, mgba en de opdrachtgever BZK/DRI. Bij het afronden van de projectstartarchitectuur in concept is een review uitgezet onder de leden van de werkgroep Digilevering, het Stelseloverleg en het Stelselgebruikersoverleg alvorens deze aan te bieden aan het Strategisch Stelselberaad voor advies aan de opdrachtgever BZK/DRI.

7 Projectstartarchitectuur Digilevering 7/ Opbouw van dit document De voorliggende startarchitectuur is opgebouwd volgens het architectuurraamwerk uit de NORA en bestaat daarom uit drie lagen, namelijk de bedrijfs-, informatie-, en technische architectuur. Daarnaast zijn er nog twee generieke dimensies binnen de Nederlandse Overheid Referentie Architectuur (NORA) onderkend: beveiliging en beheer. Deze dimensies hebben hun impact op alle drie de lagen. Hoofdstuk 2 beschrijft de positionering van Digilevering ten opzichte van de bouwstenen van de NORA en de onderkende GOB-componenten. Daarnaast wordt Digilevering op hoofdlijnen beschreven en de scope van het project Digilevering aangegeven. Het derde hoofdstuk beschouwt de bedrijfsarchitectuur van Digilevering. In dit hoofdstuk wordt Digilevering in termen als organisatie, diensten, producten, business services en processen beschreven. De informatie-architectuur van Digilevering beschrijft de functionele inrichting van de (geautomatiseerde) informatievoorziening, waarmee de in het voorgaande hoofdstuk beschreven business services en processen worden ondersteund dan wel volledig geautomatiseerd worden uitgevoerd (hoofdstuk 4). In hoofdstuk 5 is de technische architectuur van Digilevering beschreven. Er wordt een overzicht gegeven van de applicatie architectuur en ingezoomd op de onderkende applicaties. Ten slotte wordt de technische infrastructuur beschreven waarbinnen Digilevering geïmplementeerd kan gaan worden. In het laatste hoofdstuk (hoofdstuk 6) worden de risico's binnen de dienst Digilevering inzichtelijk gemaakt, alsmede de maatregelen om de risico's te reduceren tot een acceptabel niveau. De (NORA-)dimensie beheer is niet in deze projectstartarchitectuur opgenomen, maar nader uitgewerkt in de Usecase Model Digilevering en de betreffende Usecase-packages.

8 Projectstartarchitectuur Digilevering 8/112 2 Project 2.1 Beschrijving context Burgers en bedrijven verwachten een goed functionerende, dienstverlenende overheid. Samenwerking tussen overheidsorganisaties is hiervoor een belangrijke voorwaarde. Daarbij stemmen zij processen af en maken gebruik van elkaars informatie. In de NORA [6], de Nederlandse Overheid Referentie Architectuur, zijn diverse bouwstenen benoemd en beschreven, die bij het realiseren van de samenwerking benodigd zijn. In onderstaande figuur zijn de onderkende bouwstenen benoemd. Contactfuncties Webrichtlijnen MijnOverheid.nl Samenwerkende Catalogi Overheid heeft Antwoord Antwoord voor Bedrijven Basisregistraties Identity management DigiD BSN machtigingen PKI overheid Departement Provincie Waterschap Gemeente Uitvoering etc etc Personen GBA RNI Bedrijven NHR Gebouwen BAG Percelen Kadaster etc Informatieuitwisseling Overheids servicebus Terugmeld faciliteit Gemeenschappelijke ontsluiting basisregisters Figuur 1: Overzicht bouwstenen e-overheid (NORA) Het inrichten en gebruiken van basisregistraties (weergegeven aan de rechterkant van het figuur) is een belangrijke voorwaarde om ervoor te zorgen dat alle overheidsinstellingen over de 'kerngegevens' van de Nederlandse overheid kunnen beschikken. Deze gegevens

9 Projectstartarchitectuur Digilevering 9/112 worden slechts eenmalig uitgevraagd bij burgers en bedrijven. Overheidsinstellingen zijn verplicht de authentieke gegevens uit basisregistraties te gebruiken in hun processen. Het afnemen van (authentieke) gegevens uit basisregistraties gebeurt veelal via landelijke voorzieningen, waarin de gegevens van (decentrale) basisregistraties landelijk worden ontsloten. Naast een gebruiksplicht hebben overheidsinstellingen de plicht om bij gerede twijfel over de inhoud van gegevens uit een basisregistratie, dit terug te melden. Aldus ontstaan een proces van leveren van en terugmelden op basisregistratiegegevens. Schematisch is dit als volgt weer te geven: Afnemers Landelijke voorzieningen Basisregistraties Levering Generieke Voorzieningen Diensten Standaarden Terugmelding LV-BAG LV-WOZ BRI NHR LV-xx BAG BAG BAG BAG NHR Figuur 2: Levering en terugmelding van basisregistratiegegevens In het midden van de figuur staan de generieke voorzieningen, diensten en producten die, stapsgewijs, worden ontwikkeld om het gebruik van en terugmelden op gegevens van basisregistraties, te vereenvoudigen. Enkele voorzieningen zijn al operationeel, zoals Digimelding voor terugmeldingen en de Stelselcatalogus voor inzicht in de metagegevens van basisregistraties. De 'generieke bouwsteen' die de ontsluiting van basisregistraties ondersteunt is Gemeenschappelijke Ontsluiting Basisregistraties (GOB). GOB is een stelsel van standaarden, diensten en voorzieningen die de ontsluiting van basisregistraties uniform en eenduidig laat plaatsvinden. In de Startarchitectuur GOB [1] is uiteen gezet uit welke onderdelen de GOB bestaat. In onderstaande figuur (uit de startarchitectuur) zijn de GOBcomponenten benoemd 1 : 1 In de figuur zijn de verschillende GOB-componenten gekoppeld aan een fasemodel voor het bij elkaar brengen van vraag en aanbod. Indien componenten in de figuur meerdere keren zijn genoemd, betekent dit, dat ze voor meerdere fasen relevant zijn. Voor meer informatie over de fasen, zie de Startarchitectuur GOB (Bron [1]).

10 Projectstartarchitectuur Digilevering 10/112 Orientatiefase Autorisatie fase Definitie fase Gebeurtenis fase Productie fase Leverings fase Vraag Verbeteren Stelsel catalogus Afspraken/ leveringsvoorwaarden Granulariteit Hulp bij aansluiten Autorisatie registratie Autorisatieproces GOB Diensten Monitoren markt Ondersteunen/initiëren nieuwe ontwikkelingen GOB Voorzieningen Stelsel catalogus Abonnement specificatie GOB Standaarden Afspraken/ leveringsvoorwaarden Granulariteit Toezien op Enkelvoudige levering Samengestelde levering Abonnement levering Berichtenstructuur Granulariteit BR Aanbod BR BR BR Change procedures Figuur 3: GOB-componenten In de Startarchitectuur GOB zijn twee componenten afgebakend op het gebied van abonnementen: Abonnementspecificatie: voorziening waarin afnemers hun abonnementspecificaties kunnen specificeren en aanpassen; Abonnementenlevering: voorziening die aan afnemers gegevens levert op basis van tussen afnemer en registratiehouder gemaakte abonnementsafspraken. Beide componenten maken onderdeel uit van Digilevering, zoals die in deze startarchitectuur nader is uitgewerkt. Digilevering heeft ook relaties met andere GOB-onderdelen (diensten, voorzieningen en standaarden). De relaties zijn als volgt te duiden: De Stelselcatalogus, sinds april 2009 operationeel, bevat (meta)gegevens die relevant zijn voor Digilevering. Het betreft de door een registratiehouder onderkende gebeurtenissoorten, objecttypen en attribuuttypen. Een koppeling tussen Digilevering en de Stelselcatalogus is voorzien, zodat Digilevering gebruik kan maken van definities van gebeurtenissoorten; De Afspraken/Leveringsvoorwaarden. In het eerste kwartaal van 2009 is een handreiking opgeleverd die door afnemers en registratiehouder kan worden gebruikt om tot afspraken te komen voor het gebruik van gegevens uit basisregistraties. Het leveren van gegevens door middel van abonnementen is één van de onderkende

11 Projectstartarchitectuur Digilevering 11/112 leveringsvormen. De handreiking gebruiksvoorwaarden kan worden gebruikt bij het afsluiten van contracten; De (standaardisatie van de) berichtstructuur raakt ook het berichtenverkeer rondom abonnementen. In het standaardisatietraject is de inhoudelijke haalbaarheid van de combinatie StUF en NEN3610 als standaard berichtstructuur voor de ontsluiting van basisregistraties onderzocht. De GOB Berichtenstandaard zal niet tijdig beschikbaar zijn voor Digilevering. In overleg met registratiehouders en afnemers zal de structuur van de berichten van en naar Digilevering worden vastgesteld. Daarbij zal, voor zover mogelijk, worden bekeken hoe op de ontwikkeling van een GOB Berichtstructuur kan worden geanticipeerd; Binnen de GOB zijn onderdelen rondom autorisatie (autorisatieregistratie en standaardisatie autorisatieproces) onderkend. Op dit moment zijn er geen lopende initiatieven om te komen tot een generieke autorisatievoorziening. Aangezien Digilevering gerelateerd is aan autorisatie (zie paragraaf 4.2.4) zal, indien de autorisatieonderdelen worden opgepakt, de afstemming worden gezocht. In het kader van het NUP (Nationaal Uitvoeringsprogramma dienstverlening en e-overheid) is afgesproken om voor eind 2010 de volgende stappen te zetten op dit terrein [10]: alle bestuurslagen maken verplicht gebruik per ; alle bestuurslagen maken gebruik van de GOB standaarden en voorzieningen; alle bestuurslagen dragen bij aan de doorontwikkeling van de GOB standaarden en voorzieningen; alle bestuurslagen ondersteunen de brede toepassing van de GOB standaarden en producten. 2.2 Huidige situatie In de vorige fase van het project Digilevering is onderzoek gedaan naar de op dit moment bestaande abonnementsystematieken en voorzieningen bij zowel registratiehouders als afnemers. Daaruit komt naar voren dat het verstrekken van gegevens op basis van abonnementen bij sommige registratiehouders sinds jaar en dag gemeengoed is en bij sommige registratiehouders (nog) niet is ingericht. Tevens zitten er verschillen in de manier van verstrekken en de frequentie waarmee afnemers mutaties geleverd krijgen. Zie [2] voor de resultaten van het onderzoek. Tevens is bij zowel registratiehouders als afnemers geïnventariseerd welke behoefte er is aan (onderdelen van) een generieke abonnementenvoorziening, op basis van de in de voorgaande fase van het project uitgevoerde definitiestudie. Op basis van de uit de inventarisatie gebleken behoefte, is door de opdrachtgever (BZK/DRI) besloten opdracht te geven voor de uitvoering van de fase architectuur en functioneel ontwerp.

12 Projectstartarchitectuur Digilevering 12/ Digilevering op hoofdlijnen Afbakening: gebeurtenisgedreven enkelvoudige abonnementen In de Startarchitectuur GOB [1] zijn verschillende vormen van levering van basisregistraties aan afnemers onderkend. Onderstaande figuur 2 geeft de typologie van leveringen weer. In de typologie staan twee dimensies centraal: de inhoudelijke reikwijdte van de levering (enkelvoudig versus samengesteld) het communicatiepatroon voor de levering (bevraging versus melding). Levering Digilevering Generieke Voorzieningen Diensten Standaarden Digimelding Terugmelding LV-BAG LV-WOZ BRI NHR LV-xx BAG BAG BAG BAG NHR Inhoudelijke reikwijdte Communicatiepatroon A BR A BR Bevraging Melding Enkelvoudig (1 BR nodig) Directe enkelvoudige levering Uitgestelde enkelvoudige levering Enkelvoudig abonnement Periodieke verstrekking Gebeurtenisgedreven Samengesteld (meer BR s nodig) Directe samengestelde levering Uitgestelde samengestelde levering Samengesteld abonnement Figuur 4: Typologie van levering De dimensie 'inhoudelijke reikwijdte' kent als indeling: Enkelvoudige levering: Een gegevenslevering door precies één basisregistratie in antwoord op een vraag van een afnemer 3 ; Samengestelde levering: Een gegevenslevering die wordt gecombineerd uit leveringen vanuit twee of meer basisregistraties in antwoord op een vraag van een afnemer. De dimensie 'communicatiepatroon' kent als indeling: 2 Legenda: A = Afnemer; BR = basisregistratie; pijl bovenlangs is de vraag van de afnemer, pijl onderlangs is het antwoord van de basisregistratie(houder). 3 De omvang (in aantallen objecten of attributen) van de gegevenslevering doet hier niet ter zake. Zolang één basisregistratie de levering kan verzorgen, is er sprake van enkelvoudige levering.

13 Projectstartarchitectuur Digilevering 13/112 Bevraging: na de vraagstelling wordt het initiatief voor levering van gegevens niet overgedragen, wat inhoudt dat er geen functionele leveringscriteria zijn gesteld die onmiddellijke levering verhinderen; Melding: na de vraagstelling wordt het initiatief voor levering van gegevens overgedragen waarbij het moment van leveren afhangt van vooraf overeengekomen functionele leveringscriteria. De typen leveringsvormen zijn als volgt te omschrijven: Directe enkelvoudige levering: een gegevenslevering door precies één basisregistratie, geleverd direct na de vraagstelling van een afnemer; Directe samengestelde levering: een gegevenslevering die wordt gecombineerd uit leveringen vanuit twee of meer basisregistraties, geleverd direct na de vraagstelling van een afnemer; Uitgestelde enkelvoudige levering: een gegevenslevering door precies één basisregistratie, geleverd op een tussen afnemer en leverancier overeengekomen tijdstip; Uitgestelde samengestelde levering: een gegevenslevering die wordt gecombineerd uit leveringen vanuit twee of meer basisregistraties, geleverd op een tussen afnemer en leverancier overeengekomen tijdstip; Enkelvoudig abonnement: een gegevenslevering door precies één basisregistratie, waarbij het (de) moment(en) van levering afhangt van overeengekomen functionele leveringscriteria. De functionele criteria kunnen tijdgestuurd of gebeurtenisgestuurd zijn; Samengesteld abonnement: een gegevenslevering die wordt gecombineerd uit leveringen vanuit twee of meer basisregistraties, waarbij het (de) moment(en) van levering afhangt van overeengekomen functionele leveringscriteria. De functionele criteria kunnen tijdgestuurd of gebeurtenisgestuurd zijn. Digilevering richt zich alleen op de enkelvoudige, gebeurtenisgestuurde abonnementen. Het inrichten van een voorziening die alle leveringsvormen ondersteund is te complex. Aan ondersteuning van enkelvoudige gebeurtenisgestuurde abonnementen is door zowel registratiehouders als afnemers een hoog belang en een hoge urgentie toegekend. Andere vormen van levering worden dus niet door Digilevering ondersteund. In de komende jaren zullen ook voor de andere leveringsvormen (mogelijk) generieke voorzieningen worden ontwikkeld. Kernfunctionaliteit in vogelvlucht In de volgende hoofdstukken wordt Digilevering uitgebreid beschreven. De belangrijkste concepten en functionaliteiten van Digilevering worden hier alvast beschreven. Dit vormt het begrippenkader voor de verdere uitdieping in de volgende hoofdstukken.

14 Projectstartarchitectuur Digilevering 14/112 De kernfunctionaliteit van Digilevering is het distribueren van door basisregistraties aangeleverde (berichten over) gebeurtenissen aan afnemers die daarop geabonneerd zijn. Gebeurtenissen zijn bijvoorbeeld: 'starten onderneming x', 'geboorte persoon y' of 'nieuwe openbare ruimte z'. Afnemers zijn overheidsinstellingen of private instellingen met een publiekrechtelijke taak, die gebeurtenissen mogen en willen ontvangen in het kader van hun wettelijke taken. Afnemers en registratiehouders/houders landelijk voorziening sluiten een contract (juridische titel), waarin is vastgelegd van welke soorten gebeurtenissen een afnemer gebeurtenissen mag ontvangen en onder welke condities. De soorten gebeurtenissen (bijvoorbeeld: 'starten onderneming'; 'vaststellen inkomen'; 'sloop gekentekend voertuig') worden vastgesteld door de registratiehouder/houder landelijke voorziening. In Digilevering worden de contractuele afspraken dusdanig vastgelegd, dat de voorziening daarmee in staat is eenduidig vast te stellen of een door een registratiehouder/houder landelijke voorziening aangeboden gebeurtenis moet worden verstrekt aan een afnemer. In een abonnement wordt vastgelegd: welke soorten gebeurtenissen (in beginsel) worden geleverd; (indien van toepassing) welke gebeurtenisfiltering wordt toegepast. Indien een afnemer niet alle gebeurtenissen van een bepaalde soort mag of wil ontvangen, kan de levering van gebeurtenissen worden ingeperkt. Dit gebeurt door op één of meer eigenschappen van een gebeurtenis, condities aan te geven. Bijvoorbeeld een conditie op een geografisch gebied ('alleen de provincie Utrecht') of een geboortedatum ('geboortedatum < 01/01/1979'). De mogelijke condities zijn afhankelijk van de soort gebeurtenis; (indien van toepassing) welke objectlijst wordt toegepast. Een afnemer kan een lijst met objecten definiëren waarin hij, gezien de taakuitvoering van de organisatie, geïnteresseerd is. Dit kan bijvoorbeeld een lijst zijn met personen (BSN's), gekentekende voertuigen (Kentekens) of ondernemingen (KvK-nummers). In het abonnement wordt opgenomen wat voor soort objectlijst wordt gebruikt; welke gegevenselementen van een soort gebeurtenis geleverd (mogen) worden. Het gebeurtenisfilter en de objectlijst bepalen of een gebeurtenis wordt geleverd. Dat betekent niet, dat ook alle gegevens van een gebeurtenis geleverd (mogen) worden. In het abonnement is daarom ook opgenomen welke gegevenselementen van een soort gebeurtenis geleverd mogen worden. Dit is afhankelijk van de voor de taak van de afnemer benodigde gebeurtenisgegevens. Nadat het abonnement door zowel afnemer als registratiehouder/houder landelijke voorziening is goedgekeurd en vrijgegeven, kan de daadwerkelijke distributie van gebeurtenissen plaatsvinden. Van een aangeboden gebeurtenis wordt per abonnement vastgesteld of deze moet worden aangeboden aan de afnemer van het abonnement (de

15 Projectstartarchitectuur Digilevering 15/112 abonnementhouder). Slechts indien is voldaan aan alle filtercondities en de toets met de objectlijst positief is, wordt de gebeurtenis geleverd, waarbij alleen de gebeurtenisgegevens waartoe de afnemer gerechtigd is ze te ontvangen, worden doorgestuurd. Gedurende de looptijd van het abonnement kan de objectlijst worden onderhouden. De afnemer kan zelf objecten toevoegen aan of verwijderen van de objectlijst. Daarnaast bestaat de mogelijkheid om bij gebeurtenissoorten waarbij nieuwe objecten ontstaan (bijvoorbeeld 'geboorte persoon'), in het abonnement aan te geven dat in zo'n geval het betreffende object automatisch wordt toegevoegd aan de lijst. Ook het verwijderen van objecten is via deze constructie mogelijk. Projectscope In de definitiestudie GOB Abonnementenvoorziening [3] zijn de volgende onderdelen van de voorziening onderkend: registratie van basisregistraties en afnemers; registratie van een abonnement; verwerking van de gebeurtenissen; initiële leveringen 4 ; verstrekken van informatie. De scope van de fase 'Architectuur en Functioneel ontwerp' (en daarmee van de Project Start Architectuur) is 5 : registratie van basisregistraties en afnemers; registratie van een abonnement; verwerking van de gebeurtenissen; verstrekken van verwerkingsinformatie. Dat betekent dat het onderdeel 'initiële levering' buiten scope van het project valt en dat 'verstrekken van informatie' beperkt is tot het verstrekken van verwerkingsinformatie 6. Het verstrekken en ontsluiten van managementinformatie 7 is daarmee buiten de scope geplaatst. 4 Een initiële levering is het leveren van de gegevens van een object (bijvoorbeeld een persoon) als gevolg van de uitbreiding van de objectlijst een bestaand abonnement door de afnemer. De objectlijst is een lijst van objecten waarin de afnemer, in het kader van een abonnement) is geïnteresseerd (zie paragraaf voor een beschrijving van de werking van een objectlijst). 5 De scope van het project is gebaseerd op de 'Must-haves' zoals die in de definitiestudie [3] zijn opgenomen. 6 Verwerkingsinformatie betreft de informatie voor de serviceorganisatie Digilevering over de werking van het informatiesysteem ten behoeve van het operationeel beheer (monitoring, oplossen problemen, etc.). 7 Managementinformatie betreft de informatie die door basisregistraties, afnemers of de serviceorganisatie Digilevering opgevraagd kan worden ten behoeve van hun bedrijfsvoering (sturing, procesoptimalisatie, etc.).

16 Projectstartarchitectuur Digilevering 16/112 Reden hiervoor is het beperken van de complexiteit van deze versie van Digilevering. De focus ligt op de verwerking van gebeurtenissen en de aanvullende functionaliteit die nodig is om dat te verwezenlijken. Initiële levering en het verstrekken van managementinformatie zijn daaraan aanvullend en zullen in een volgende versie worden geïmplementeerd. 2.4 Uitgangspunten In de definitiestudie GOB Abonnementenvoorziening [3] zijn uitgangspunten gedefinieerd. Deze zijn onverkort van toepassing op de, in deze architectuur, uitgewerkte voorziening. De belangrijkste uitgangspunten zijn: De basisregistratie (en dus niet Digilevering) is verantwoordelijk voor de autorisatie van de afnemer; Voordat een abonnement in Digilevering geregistreerd kan worden, moet er een contract tussen basisregistratie en afnemer zijn. In dit contract is formeel vastgelegd welke gegevens een afnemer geleverd mag krijgen in relatie tot de taken die worden uitgevoerd; Uitwisseling tussen de verschillende organisaties (basisregistratie, afnemer en Digilevering) gaat op basis van elektronische berichten. Er is een betrouwbare levering van berichten (dit wordt gewaarborgd door toepassing van de OSB Koppelvlakstandaard ebms). Daar waar Digilevering berichten verstuurt aan afnemers, is het vereist dat de afnemer hiervoor een (OSB Compliant) webservice implementeert; De basisregistratie (en dus niet Digilevering) bepaalt de gebeurtenissoorten (bijvoorbeeld: life events, administratieve mutaties, etc.); Digilevering levert berichten altijd direct (dat wil zeggen: zo spoedig mogelijk na ontvangst van het bericht) door aan de afnemer(s) die daar volgens hun abonnement recht op hebben. De berichten worden niet opgeslagen in Digilevering; Gebeurtenissen die in de toekomst plaatsvinden, kunnen worden gemeld aan Digilevering 8.. Gebeurtenissen die in de toekomst plaatsvinden worden door Digilevering hetzelfde behandeld als andere gebeurtenissen en derhalve direct na ontvangst doorgestuurd aan de afnemer. De afnemer moet hier in zijn informatievoorziening rekening mee houden. Digilevering kent de relatie tussen gebeurtenissoorten van verschillende basisregistraties niet; De basisregistratie bepaalt op basis van welke criteria (bijvoorbeeld: locatieaanduiding, branchecodering) afnemers kunnen selecteren welke gebeurtenissen van een bepaalde soort aan de afnemer worden geleverd (het zgn. gebeurtenisfilter); Digilevering registreert (logt) veranderingen in de abonnementenspecificatie. 8 Voorbeeld van een gebeurtenis in de toekomst is: onderneming start over 2 weken.

17 Projectstartarchitectuur Digilevering 17/112 3 Bedrijfsarchitectuur 3.1 Digilevering Digilevering is een generieke voorziening, bestaande uit een geautomatiseerde voorziening en de daarbij behorende serviceorganisatie. Digilevering ondersteunt gebeurtenisgedreven verstrekkingen, waarbij de registratiehouder (of, indien van toepassing, de houder van de landelijke voorziening), via Digilevering gegevens over gebeurtenissen aan haar afnemers verstrekt. Dit kan als volgt schematisch worden gemodelleerd (waarbij de verstrekking van één gebeurtenis is weergegeven). Afnemers Landelijke voorzieningen Basisregistraties Digimelding Levering Digilevering Digilevering abonnementen Generieke Voorzieningen Diensten Standaarden Terugmelding Starten onderneming xyz LV-BAG LV-WOZ BRI NHR LV-xx BAG BAG BAG BAG NHR Figuur 5: Digilevering en haar context Alvorens Digilevering de, door registratiehouders/houders landelijke voorziening aangeleverde gebeurtenissen, kan leveren aan afnemers, moeten de organisaties (registratiehouder/houder landelijke voorziening, afnemer) en hun onderlinge contractuele afspraken geregistreerd worden. Het abonnement (die de contractuele afspraken representeert in Digilevering) is de basis waarop Digilevering vaststelt welke afnemers welke gebeurtenissen geleverd krijgen. De registratiehouder/houder landelijke voorziening stuurt zijn gebeurtenissen 9 in een bericht naar Digilevering. Digilevering bepaalt, op basis van de abonnementenregistratie, welke 9 Voorbeeld: Gebeurtenissoort is 'overlijden persoon'; gebeurtenis is 'overlijden van persoon X'.

18 Projectstartarchitectuur Digilevering 18/112 afnemers geabonneerd zijn de betreffende gebeurtenissoort en stuurt deze gebeurtenis door naar de afnemers (de abonnementhouders). Daarnaast verstrekt Digilevering gegevens over de verwerking aan de beheerorganisatie (serviceorganisatie Digilevering). 3.2 Organisatie In keten van gebeurtenisgedreven verstrekkingen worden dus vier organisaties onderkend: Registratiehouders; Houders landelijke voorziening; Afnemers; Serviceorganisatie Digilevering Registratiehouders, houders landelijke voorziening en afnemers Registratiehouders, houders van landelijke voorziening en afnemers hebben taken en verantwoordelijkheden in de verstrekking van gebeurtenissen. Zij vormen de 'leveranciers' en 'klanten' van Digilevering. De rollen registratiehouder, houder landelijke voorziening en afnemer zijn als volgt te omschrijven: Een registratiehouder is de bij wet aangewezen overheidsinstelling of groep van overheidsinstellingen, die houder en beheerder is van de basisregistratie. Een basisregistratie is een verzameling gegevens waarvan bij wet is bepaald dat deze een basisregistratie vormen. Voorbeeld: burgemeester en wethouders zijn registratiehouder van de basisregistratie adressen. Een houder landelijke voorziening is een overheidsorganisatie die een landelijke voorziening beheert. Een landelijke voorziening is een voorziening waarin de gegevens uit één of meerdere basisregistraties zijn opgenomen, ten behoeve van het gebruik door afnemers. Voorbeeld: de dienst Kadaster is houder van de landelijke voorziening BAG. Een afnemer is een publieke organisatie of private organisatie die voor het uitoefenen van een publieke taak gebruik maakt van gegevens uit een basisregistratie. Voorbeeld: het Ministerie van Justitie is afnemer van gegevens uit het Nieuw Handelsregister. Digilevering communiceert met de houder landelijke voorziening (op organisatieniveau) en de landelijke voorziening (op systeemniveau). Hoewel formeel niet iedere basisregistratie een landelijke voorziening kent, is er de facto wel sprake van een voorziening die op landelijk niveau het gebruik van de basisregistratie verzorgt. In het vervolg spreken we

19 Projectstartarchitectuur Digilevering 19/112 daarom van 'houder landelijke voorziening' en 'landelijke voorziening' om de organisatie respectievelijk het informatiesysteem aan te duiden waarmee Digilevering communiceert 10. Op dit moment (oktober 2009) worden, bovenstaande interpretatie volgend, de volgende houders van landelijke voorzieningen onderscheiden: Houder landelijke voorziening Kadaster BPR Belastingdienst RDW KvK NL Waarderingskamer Basisregistratie(s) BR Kadaster BR Topografie BR Adressen BR Gebouwen BR GBA Persoonsgegevens, RNI BR Inkomen BR Voertuigen Nieuw Handelsregister BR WOZ Serviceorganisatie Digilevering Digilevering bestaat naast de geautomatiseerde (technische) systemen ook uit een serviceorganisatie (de Serviceorganisatie Digilevering) die nodig is om de systemen operationeel te houden en ondersteuning te bieden bij vragen of klachten vanuit de gebruikers (registratiehouders, houders landelijke voorziening en afnemers). Om deze taken te kunnen uitvoeren zijn twee organisatieonderdelen te onderkennen met elk hun eigen specifieke doelstelling: een organisatieonderdeel dat verantwoordelijk is voor het afhandelen van vragen en klachten vanuit de gebruikers van de voorziening; een organisatieonderdeel dat verantwoordelijk is om het operationele en tactische beheer uit te voeren, waaronder het functioneel beheer, technische beheer, applicatieontwikkeling, releasemanagement, etc. Dit beeld sluit aan bij de huidige indeling binnen de beoogde beheerpartij: Logius. 10 Zo kent bijvoorbeeld het NHR formeel geen landelijke voorziening, maar er is wel sprake van een voorziening voor het landelijk ontsluiten van de gegevens uit de basisregistratie en beschouwen we de NHR als landelijke voorziening en KvK NL als houder van deze landelijke voorziening.

20 Projectstartarchitectuur Digilevering 20/ Verantwoordelijkheden Het leveren van gegevens op basis van enkelvoudige, gebeurtenisgestuurde abonnementen gaat over alle hierboven onderkende organisaties heen. Dit vergt een goede afstemming en een duidelijke scheiding van verantwoordelijkheden tussen deze organisaties. Serviceorganisatie Digilevering De serviceorganisatie Digilevering is verantwoordelijk voor de (juiste en tijdige) distributie van de (gebeurtenis)berichten en voor de traceerbaarheid van deze (gebeurtenis)berichten. Dit betreft de verantwoordelijkheden met betrekking tot operationeel en/of tactisch beheer van de voorziening, zoals het functioneel beheer, technisch beheer, applicatieontwikkeling, releasemanagement, etc. Deze beheerrollen worden ingevuld door Logius en hun uitvoerende partners. Binnen Logius vervult het onderdeel Serviceorganisatie de eerstelijns ondersteuning voor zowel houders landelijke voorziening als afnemers. Aangezien één van de uitgangspunten is om de inhoudelijke kennis bij de serviceorganisatie Digilevering te beperken, betekent dit dat er (inhoudelijke) aanspreekpunten bij houders landelijke voorziening en afnemers moeten zijn waarmee afspraken over de kennislevering gemaakt worden. Daarnaast ondersteunen zij het aansluittraject voor nieuwe gebruikers. Registratiehouders, houders landelijke voorzieningen en afnemers Naast de serviceorganisatie Digilevering hebben ook registratiehouders, houders landelijke voorzieningen en afnemers hun taken en verantwoordelijkheden. De registratiehouders, houders landelijke voorzieningen en afnemers zijn geen organisaties waar Digilevering verantwoordelijk voor is, maar wel organisaties die een integraal onderdeel uitmaken van de keten waarbinnen Digilevering opereert. De registratiehouders en houders landelijke voorzieningen zijn (in juridische zin) verantwoordelijk voor de levering van gegevens aan afnemers. Daarnaast zijn de houders landelijke voorziening en afnemers verantwoordelijk voor de registratie en het beheer van de abonnementspecificaties. De houder landelijke voorziening is de partij die bepaalt op welke gebeurtenissoorten een abonnement genomen kan worden. De afnemer is de partij die zich op één of meer gebeurtenissoorten abonneert en de partij die de gebeurtenissen van Digilevering afneemt. Samenvattend zijn de (eind)verantwoordelijkheden als volgt belegd: Organisatie Registratiehouders en houders landelijke voorziening (Eind)verantwoordelijk voor de volgende taken Verstrekken van de gebeurtenis; Beheren gebeurtenissoorten (definities), inclusief