Enterprise Architectuur PDOK

Enterprise Architectuur PDOK (Aanvulling op bestaande PSA)

Auteurs Pieter Meijer (ProgrammamanagerPDOK) Juan Guillen Scholten (Enterprisearchitect PDOK) Stephen Oostenbrink (Enterprisearchitect) Versie 1.0 DEFINITIEF, 22 november 2012 Pagina 1 van 33

Pagina 2 van 33

Inleiding De enterprisearchitectuurschets is een aanvulling op de bestaande PSA. De bestaande PSA stamt uit 2010 en is nog niet officiëelgoedgekeurd (versie 0.9) . Het document is in plateau I van het PDOK programma opgesteld maar niet meer bijgehouden. In plateau II is er een plan van aanpak voor een verdiepingslag opgesteld om de PSA bij te werken. Dit plan is echter, bij gebrek aan tijd, niet uitgevoerd. Deze architectuurschets is een aanvulling op de bestaande PSA waarbij het advies van de verdiepingslag wordt overgenomen om de NORA te gebruiken. Dit document wordt in de tweede helft van plateau III opgesteld.Gezien de korte ti jd worden niet alle punten van de verdiepingslag uitgevoerd maar slechts die punten die noodzakelijk zijn voor een succesvolle afronding van het programma en tevens om een goede basis te geven voor het postprogramma van PDOK.

Enterprise Architectuur PDOK

Pagina 3 van 33

Positionering Nora 9+2 vlaks model

NORA Als basisraamwerk wordt gebruik gemaakt van het NORA architectuurmodel. Dit is een weergave van de verschillende facetten waaraan de oplossing getoetst wordt. Dit model biedt een standaard manier om concepten te verkennen, te beschrijven en in beeld te brengen. Toelichting •Dit zogenaamde 9+2 vlaks model bestaat uit de drie architectuurlagen, te weten: BedrijfsArchitectuur, Informatie Architectuur en Technische Architectuur. •Naast de drie lagen worden drie kolommen onderscheiden: •Wie neemt actie: organisa ties, informatieverwerkers (personen en applicaties) en machines/computers. •Wat wordt geleverd: dienste n, berichten en gegevens. •Hoe gebeurt dit: processen, communicatie, integratie en netwerken. •Daarnaast zijn twee generiek e dimensies: Beveiliging en Beheer. Deze dimensies hebben hun impact op alle drie de lagen. •Dit raamwerk wordt gebruikt om het geheel op een voor ieder herkenbare en standaard manier te ordenen. •Dit model is in te vullen vo or de huidige en toekomstige situatie. Het verschil tussen deze modellen is de verandering. •De verandering wordt ingevuld met en getoetst tegen de architectuurkaders van NORA.


Pagina 4 van 33

Bedrijsarchitectuur Dit onderdeel beschrijft de bedrijfsarchitectuur van PDOK volgens het architectuurmodel van de NORA.

Bedrijfsarchitectuur


Pagina 5 van 33

KerntaakPDOK Kerntaak PDOK (dataset view)


Pagina 6 van 33

KerntaakPDOK Deze plaat geeft de kerntaak van PDOK.



Bronhouder. Een bronhouder is de eigenaar van een dataset of een deel van een landsdekkende dataset. Deze is (juridisch) verantwoordelijk voor de inhoud en kwaliteit van de data. PDOK kent geen bronhouders. Alle relevante zaken lopen via de toeleveranciers, die eventueel ook bronhouders kunnen zijn zoals in de figuur is aangegeven.



Toeleverancier. Een toeleverancier is een organisatie die een dataset aanlevert aan PDOK. Dit kan zowel een overheidspartij als een bedrijf zijn. De inhoud en verantwoordelijkheid van de dataset ligt bij de toeleverancier. PDOK is slechts een “doorgeef luik”.



Dataset. In de context van PDOK is een dataset een databestand dat via PDOK wordt ontsloten. Dit kan middels verschillende kanalen, zoals geografische webservices of download extracten.



Enkelvoudige dataset. Een enkelvoudige dataset bestaat uit een enkele bron. In de plaat is het onderscheid tussen bronhouder en toeleverancier logisch, want het betreft dezelfde partij.


Pagina 7 van 33

Kerntaak PDOK Deze plaat geeft de kerntaak van PDOK.



Geaggregeerde dataset. Een geaggregeerde dataset bestaat uit meerdere brondatasets. Hierbij worden brondatasets van verschillende bronhouders samengevoegd tot één dataset. Iedere brondataset heeft een eigen bronhouder die eigenaar en inhoudelijk verantwoordelijk is. Bronhouder en toeleverancier zijn in dit geval verschillende partijen.



PDOK. De PDOK-voorziening faciliteert de samenwerking en de gezamenlijke ontsluiting van geoinformatie tussen de partners (intern) en aan maatschappelijke partijen (extern). Haar doelen zijn: (a) Het realiseren van een nationale voorziening voor het centraal ontsluiten van plaatsgebonden informatie met services en extracten om het uitwisselen en gebruik van plaatsgebonden informatie in Nederland te bevorderen. (b) Centraal aan de verplichting voldoen om services, metadata en data conform de INSPIRE standaarden aan te bieden.



Afnemer. Een afnemer is een burger, bedrijf of overheidspartij. Een afnemer maakt gebruik van producten en diensten van PDOK.


Pagina 8 van 33

Globale architectuur PDOK


Pagina 9 van 33


Deze plaat betreft de Globale architectuur van PDOK (ook wel de context architectuur genoemd). Het beschrijft alle PDOK producten en hun context.



Eindgebruikers. Dit zijn de gebruikers van PDOK afnemers.



Afnemers. Een afnemer is een burger, bedrijf of overheidspartij. Een afnemer maakt gebruik van producten en diensten van PDOK. Afnemers ontwikkelen eindgebruiker toepassingen die gebruik maken van PDOK services of componenten. Afnemers zijn overheidsinstanties en bedrijven. In het kader van open data zijn ook burgers potentiële afnemers.



Externe toepassingen. PDOK kan kleine applicaties ontwikkelen om het gebruik van PDOK te bevorderen of vergemakkelijken. Op dit moment is dat de PDOK Esri ArcGIS Extensie die gebruik maakt van het NGR.



Toepassingen. Op dit moment zijn het voornamelijk: het NGR en het PDOK Loket. Deze twee hebben een aantal integratie punten met elkaar en gebruiken andere onderdelen van PDOK zoals de services en Kaart.


Pagina 10 van 33

Globale architectuur PDOK Deze plaat betreft de Globale architectuur van PDOK (ook wel de context architectuur genoemd). Het beschrijft alle PDOK producten en hun context.



Componenten. PDOK Kaart is een component dat zowel door de toepassingen als rechtstreeks door afnemers gebruikt kan worden. De API en source code wordt vanuit PDOK beschikbaar gesteld via het PDOK Loket.



PDOK Webservices. De toepassingen en componenten maken gebruik of zijn gerelateerd aan de webservices van PDOK. PDOK biedt o.a. datasets aan via webservices. Een webservice is een communicatie methode tussen twee applicaties (apparaten, systemen, etc.)



PDOK Motor. De motor is de core van de voorziening ook wel aangeduid als de fabriek. Deze is gericht op repeteerbaar en automatiseerbaar productiewerk. Kern is het ontvangen, verwerken en verstrekken van (grote hoeveelheden) plaatsgebonden informatie.



PDOK Voorportaal. Transformaties zijn hoofdzakelijk nodig om te voldoen aan de INSPIRE richtlijnen. Het opzetten, testen en stabiel krijgen (uittrillen) van transformaties zijn werkzaamheden die plaatsvinden in het voorportaal (ook wel datalab genoemd).


Pagina 11 van 33


Deze plaat betreft de Globale architectuur van PDOK (ook wel de context architectuur genoemd). Het beschrijft alle PDOK producten en hun context.



Toeleveranciers. Een toeleverancier is een organisatie die een dataset (inclusief metadata) aanlevert aan PDOK. Dit kan zowel een overheidspartij als een bedrijf zijn. De inhoud en verantwoordelijkheid van de dataset ligt bij de toeleverancier. PDOK is slechts een “doorgeef luik”.


Pagina 12 van 33

Informatie architectuur Dit onderdeel beschrijft de informatie architectuur van PDOK volgens het architectuurmodel van de NORA.

Informatie architectuur


Pagina 13 van 33

Keuzemodel PDOK


Pagina 14 van 33

Informatie architectuur Het keuzemodel is een “alles in één plaat”overzicht van PDOK op het gebied van de informatiearchitectuur. Het beschrijft de gebruikte middelen, standaarden en de functionele voorzieningen van PDOK over de gehele keten.

De verschillende onderdelen van het keuzemodel worden nader uitgewerkt en uitgebreid beschreven in de afzonderlijke deelproject architectuurdocumenten en functionele specificaties, o.a.:      

Architectuurschets Datamanagement. Versie 1.0. Datum 9 februari 2012. Auteur: Stephen Oostenbrink. Functionele Specificaties Datamanagement. Versie 1.0. Datum 9 mei 2012. Auteur: Joris van der Horst. Architectuurdocument PDOK Toegangslaag. Versie 1.0. Datum 27 april 2012. Auteurs: Juan Guillen Scholten, Stephen Oostenbrink. Functionele Specificaties Toegangslaag. Versie 1.0. Datum 28 april 2012. Auteur: Albert van Kempen Architectuurschets PDOK Loket. Versie 1.0. Datum 13 augustus 2012. Auteurs: Juan Guillen Scholten, Kees de Jong. Architectuurschets PDOK Kaart. Versie 1.0. Datum 13 augustus 2012. Auteurs: Kees de Jong, Juan Guillen Scholten.


Pagina 15 van 33


Het keuzemodel is een “alles in één plaat”overzicht van PDOK.

De verschillende onderdelen van het keuzemodel worden nader uitgewerkt en uitgebreid beschreven in de afzonderlijke deelproject architectuurdocumenten en functionele specificaties, o.a.:   

Architectuurschets NGR. Versie 1.0. Datum 13 augustus 2012. Auteur: Juan Guillen Scholten. Solution Architectuur PDOK Motor, Datum: te verwachten in december 2012. Auteurs: Michael Haulussy et al. Project Start Architectuur PDOK Motor Plateau I. Versie 0.9. Datum 16 juni 2010. Auteur: Michel Grothe.


Pagina 16 van 33

Keuzemodel PDOK met Roadmap


Pagina 17 van 33


Keuzemodel PDOK met Roadmap

De roadmap voor het keuzemodel geeft aan wat er op dit moment geïmplementeerd is en wat nog gerealiseerd gaat worden in 2013 en 2014. De roadmap is gebaseerd op de volgende input:   

Datamanagement Functies door OBE uit Functionele Specificatie Datamanagement Document. Datum 13 november 2012. Auteur: team OBE. (bijlage programmateamoverle g van 13 november). Stand van zaken PDOK Motor. Datum november 2012. Team OBE. Gerard van der Hoorn. Stand van zaken PDOK Loket, Kaart, NGR. Datum november 2012. Team V&V. Willem Steenis.


Pagina 18 van 33


Pagina 19 van 33



Pagina 20 van 33



Pagina 21 van 33


Technische architectuur Dit onderdeel beschrijft de technische architectuur van PDOK volgens het architectuurmodel van de NORA.

Technische architectuur


Pagina 22 van 33

Technische architectuur De technische realisatie van PDOK


Pagina 23 van 33


Implementatie cellen

De implementatie van PDOK wordt gesplitst in cellen. Voordeel:  minder afhankelijkheden met betrekking tot changes; lokale wijzigingen en optimalisaties binnen een cel heeft geen gevolgen voor andere cellen.  op basis van karakteristieken (zoals bv beschikbaarheideisen of beveiliging) per cel specifieke inrichtingkeuzes kunnen maken. For meer informatie en verdere uitwerking:  Solution Architectuur PDOK Motor, Datum: te verwachten in december 2012. Auteurs: Michael Haulussy et al.


Pagina 24 van 33


Technische realisatie

Technische aspecten:  Infrastructuur  Virtuele servers op basis van VMWare.  Operating system 64 bit RedHat Enterprise Linux 

Software stack  Open source  Maatwerk op basis van Java J2E technologie

Netwerk & Beveliging  SecureSpan van Layer7 (beveiligingsproduct)  Load balancer  Proxy server Voor een uitgebreidere lijst :  Technische architectuur software ontwikkeling. Versie 1.0. Datum7 augustus 2012 . Auteur: Patrick Schiks. En de technische specificaties van PDOK Loket, PDOK Kaart en NGR 2.0. 


Pagina 25 van 33

Technische architectuur 3-Laags structuur voor PDOK toepassingen


Pagina 26 van 33


De implementatie van PDOK toepassingen, met name PDOK Loket en het NGR , is logisch opgedeeld in een 3laag structuur: frontend, common platform en backend.



De frontend betreft de grafische interfaces van PDOK toepassingen; dat wat de gebruikers zien en waar zij interactie mee hebben.



Het common platform dient als centrale informatie laag waarin de informatie wordt gecentraliseerd om vervolgens deze eenvoudig aan te kunnen bieden aan PDOK toepassingen zoals het NGR en het Loket (als content). Een CMS zal zich in deze laag bevinden. Een CMS (content management system); is een softwaretoepassing die het mogelijk maakt dat mensen eenvoudig, zonder veel technische kennis, documenten en gegevens op internet kunnen publiceren (contentmanagement) [Wikipedia]. In principe kunnen er meerdere CMS-en voorkomen in het common platform, maar dan wel op basis van dezelfde technologie.



De backend betreft het deel van de toepassing dat de gebruikers niet te zien krijgen en waar alle intensieve PDOK processen plaatsvinden en grotendeels van de data opgeslagen wordt. De backend stelt zijn informatie beschikbaar uitsluitend via Webservices.


Pagina 27 van 33


Common platform

 Het idee achter het common platform is dat informatie daar wordtgece ntraliseerd; dan wel door deze in een CMS te stoppen of door deze op te halen via de services. Ditvoorko mt dubbeling van informatie (op meerdere plekken invoeren en bewaren) en maakt het beheer hiervan een stuk eenvoudiger. Eenmaal gecentraliseerd kan de informatie eenvoudig aan de frontend van het NGR en het Loket aangeboden worden (en andere toekomstige PDOK toepassingen) als content. Dezelfde inhoud kan dan aan verschillende toepassingen aangeboden worden terwijl de bron hiervan één is; een aanpassing aan de informatie in de bron leidt meteen tot een update van de content op alle plekken waar het gebruikt wordt i.p.v. één voor één moeten aanpassen.


Pagina 28 van 33


Beveiliging / toegangslaag

 Beveiliging  SecureSpan: Er wordt gebruik gemaakt van het product SecureSpan van Layer7 voor de toegangslaag. Voor het benaderen van PDOK toepassingen geldt: Het http verkeer aan de voorkant gaat altijd via Layer7. Deze kan bijvoorbeeld filteringtoepassen. Het verkeer naar de backend gaat ook altijd via Layer7; die eventueel het PKIoverheid certificaat raadpleegt indien het verzoek van een andere domain komt dan intern.  PKIoverheid certificaat: voor toegang tot de services van de backend, waarvoor authenticatie verplicht is, is een geldig PKIoverheid certificaat nodig. Indien een PDOK toepassing in dezelfde domain netwerk omgeving binnen PDOK wordt ondergebracht is een certificaat niet nodig. In alle andere gevallen is dat de enigste manier voor de frontend en hetcommon platform om zich als PDOK zijnde te authentiseren.  Toekomstige beveiligingsuitbreidingen:  eHerkenning, DigiD, Oauth. Zie het architectuurdocument van de toegangslaag.


Pagina 29 van 33


Specifieke implementatie PDOK Loket, PDOK Kaart en NGR.

 Het common platform concept en de 3-laags structuur is geïmplementeerd bij de realisatie van het PDOK Loket, PDOK Kaart en het NGR.  Voor details over de specifieke implementaties bij de PDOK toepassingen, welke delen er geïmplementeerd zijn en welke onder de Roadmap vallen, zie de bijhorende architectuurdocumenten.  Architectuurschets PDOK Loket. Versie 1.0. Datum 13 augustus 2012. Auteurs: Juan Guillen Scholten, Kees de Jong.  Architectuurschets PDOK Kaart. Versie 1.0. Datum 13 augustus 2012. Auteurs: Kees de Jong, Juan Guillen Scholten.  Architectuurschets NGR. Versie 1.0. Datum 13 augustus 2012. Auteur: Juan Guillen Scholten.


Pagina 30 van 33

Pagina 31 van 33

Geraadpleegde bronnen Geraadpleegde bronnen • Project Start Architectuur PDOK Motor Plateau I. Versie 0.9. Datum 16 juni 2010. Auteur: Michel Grothe. • Verdiepingsslag en formele vaststelling PSA - Plan van Aanpak. Versie 0.5. Datum 26 mei 2011. Auteurs: Michel Grothe, Stephen Oostenbrink. • Architectuurdocument PDOK Toegangslaag. Versie 1.0. Datum 27 april 2012. Auteurs: Juan Guillen Scholten, Stephen Oostenbrink. • Architectuurschets Datamanagement. Versie 1.0. Datum 9 februari 2012. Auteur: Stephen Oostenbrink. • Solution architectuur PDOK Motor, Michael Haulussy, per email + presentatie, november 2012. Document te verwachten in december 2012. • Technische architectuur software ontwikkeling. Versie 1.0. Datum 7 augustus 2012. Auteur: Patrick Schiks. • Datamanagement Functies door OBE uit Functionele Specificatie Datamanagement Document. 13 november 2012. Auteur: team OBE. (bijlage programmateam overleg van 13 november).


Pagina 32 van 33

Einde Enterprise ArchitectuurPDOK (Aanvulling op bestaande PSA)

Pagina 33 van 33

Enterprise Architectuur PDOK

Recommend Documents