Enterprise Architectuur PDOK (Aanvulling op bestaande PSA) Auteurs Pieter Meijer (Programmamanager PDOK) Juan Guillen Scholten (Enterprise architect PDOK) Stephen Oostenbrink (Enterprise architect) Versie 1.0 DEFINITIEF, 22 november 2012 Pagina 1 van 33
Inhoud Architectuur is het aanbrengen van overzicht en samenhang evenals het waarborgen en uitdragen hiervan. Dit betreft specifieke oplossingen, systemen, of de organisatie (enterprise) als geheel. JGS 1. Inleiding 2. NORA 3. Bedrijfsarchitectuur 4. Informatie architectuur 5. Technische architectuur 6. Meer informatie 7. Geraadpleegde bronnen Pagina 2 van 33
Inleiding De enterprise architectuurschets is een aanvulling op de bestaande PSA. De bestaande PSA stamt uit 2010 en is nog niet officiëel goedgekeurd (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 tijd 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. Pagina 3 van 33
Positionering Nora 9+2 vlaks model 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. NORA Toelichting Dit zogenaamde 9+2 vlaks model bestaat uit de drie architectuurlagen, te weten: Bedrijfs Architectuur, Informatie Architectuur en Technische Architectuur. Naast de drie lagen worden drie kolommen onderscheiden: Wie neemt actie: organisaties, informatieverwerkers (personen en applicaties) en machines/computers. Wat wordt geleverd: diensten, berichten en gegevens. Hoe gebeurt dit: processen, communicatie, integratie en netwerken. Daarnaast zijn twee generieke 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 voor 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
Kerntaak PDOK Kerntaak PDOK (dataset view) Pagina 6 van 33
Kerntaak PDOK 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
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. 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
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. 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
Informatie architectuur 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
Informatie architectuur 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 programmateam overleg 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
Informatie architectuur Keuzemodel (beveiliging, rapportages, toepassingen) toegangslaag NGR PDOK Kaart toegangslaag / datamanagement PDOK Loket Pagina 19 van 33
Informatie architectuur Keuzemodel (aanleveren, verwerken, aanbieden) services / datamanagement datalab (afspraken) intakes / datamanagement datamanagement Pagina 20 van 33
Informatie architectuur Keuzemodel (afspraken, historie, transport) (afspraken) intakes / toegangslaag (afspraken) intakes / datamanagement datamanagement toegangslaag 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
Technische architectuur 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 architectuur 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. Datum 7 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
Technische architectuur De implementatie van PDOK toepassingen, met name PDOK Loket en het NGR, is logisch opgedeeld in een 3- laag 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
Technische architectuur Common platform Het idee achter het common platform is dat informatie daar wordt gecentraliseerd; dan wel door deze in een CMS te stoppen of door deze op te halen via de services. Dit voorkomt 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
Technische architectuur 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 filtering toepassen. 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 het common platform om zich als PDOK zijnde te authentiseren. Toekomstige beveiligingsuitbreidingen: eherkenning, DigiD, Oauth. Zie het architectuurdocument van de toegangslaag. Pagina 29 van 33
Technische architectuur 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
Meer informatie Programmamanager: Ir. Pieter G. Meijer pieter.meijer@rws.nl, +31 (0)6 51397577 Enterprise architect: Dr. Juan Guillen Scholten juan.guillenscholten@atos.net, +31(0)6 30631947 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 (Aanvulling op bestaande PSA) Pagina 33 van 33