Voorzieningen voor integrale ontsluiting en integraal gebruik van Basisregistraties

Maak een Begin. Het is Gratis
of registreren met je e-mailadres
Rocket clouds
Voorzieningen voor integrale ontsluiting en integraal gebruik van Basisregistraties Door Mind Map: Voorzieningen voor integrale ontsluiting en integraal gebruik van Basisregistraties

1. Aanleiding en vraagstelling

1.1. Veel overheden maken eigen voorziening, kost geld, beperkt gebruik

1.2. Hoofdvraag: Liggen er mogelijkheden voor realiseren centrale voorziening

1.3. Deelvraag: is hergebruik van bestaande voorziening mogelijk

1.4. Welke bestaande voorzieningen sluiten aan bij criteria opdrachtgever

1.5. Feitelijke weergave van bestaande voorzieningen

1.5.1. Opdrachtgever kiest

2. Afbakening onderzoek & betekenis bevindingen

2.1. Beoordeling geld alleen binnen de specifieke context van dit onderzoek

2.2. Geen analyse kansrijkheid hergebruik

2.3. Geen impactanalyse van opschaling

2.4. Criteria geformuleerd door opdrachtgever

3. Aanpak

3.1. Vragenlijst

3.1.1. Primaire criteria

3.1.1.1. Open Source

3.1.1.2. tenminste 3 basisregistraties

3.1.1.3. In productie

3.1.2. 4 hoofdthema's

3.1.2.1. Functies

3.1.2.1.1. Meer dan 3 BR

3.1.2.1.2. User interface én API

3.1.2.1.3. geografische weergave en selectie

3.1.2.1.4. bestandsleveringen

3.1.2.1.5. zelf leveringen specificeren

3.1.2.1.6. gebeurtenisberichten

3.1.2.1.7. Externe toegang

3.1.2.1.8. betaalfunctie

3.1.2.2. Architectuur

3.1.2.2.1. type koppelvlakken en services

3.1.2.2.2. schaalbaarheid

3.1.2.2.3. componenten en software

3.1.2.2.4. data bij de bron?

3.1.2.2.5. metadata

3.1.2.3. Herbruikbaarheid

3.1.2.3.1. Broncode deelbaar

3.1.2.3.2. Generiek inzetbaar

3.1.2.3.3. Domeinspecifieke functies

3.1.2.3.4. documentatie

3.1.2.4. Privacy en beveiliging

3.1.2.4.1. Authenticatie en autorisatie

3.1.2.4.2. monitoring en logging gebruik

3.1.2.4.3. Beveliging

3.2. Identificeren voorzieningen & Selectie

3.2.1. Longlist

3.2.1.1. opdrachtgever

3.2.1.2. eigen ervaring

3.2.1.3. uitvraag manifestpartijen

3.2.2. stapsgewijs in beeld brengen

3.2.2.1. eerst primaire criteria

3.2.2.2. later vragenlijst en interview

3.2.3. Totaaloverzicht in bijlage

3.3. interviews

3.3.1. Architectuur

3.3.2. Koppelvlakken

4. Resultaten (feiten)

4.1. Het totaaloverzicht

4.1.1. In totaal ... voorzieningen geidentificeerd bij ... overheidsorganisaties.

4.1.1.1. Een volledig overzicht is opgenomen in tabel ..

4.1.2. Meesten vielen af omdat ze niet voldeden aan de primaire criteria.

4.1.2.1. niet 'één voorziening'

4.1.2.1.1. In een aantal gevallen was er geen sprake van één voorziening zoals bedoeld in dit onderzoek, maar van een heterogene verzameling van componenten en mechanismen

4.1.2.2. commercieel/closed source

4.1.2.2.1. Een tweetal (?) voorzieningen viel af omdat deze waren gebaseerd op commerciele/closed source oplossingen

4.1.2.3. niet generiek in opzet

4.1.2.3.1. Enkele voorzieningen werden door de betreffende organisatie zelf niet generiek genoeg of geschikt geacht om te hergebruiken voor een eventueel landelijke voorziening

4.1.2.4. <3 Basisregistraties

4.1.2.4.1. De meeste voorzieningen vielen af omdat niet tenminste 3 basisregistraties in samenhang ontsloten werden (waarbij de voorziening dit ook niet zou kunnen zonder fundamentele aanpassingen)

4.1.2.5. niet in productie

4.1.2.5.1. Enkele genoemde initiatieven waren nog in het stadium van proof of concept of pilot

4.1.3. 4 voorzieningen benaderden de primiare criteria.

4.1.3.1. Het betreft de volgende voorzieningen, te weten <opsomming> . Deze zijn nader onderzocht door het toezenden van een vragenlijst en een daaraan gekoppeld (telefonisch of live) interview.

4.1.4. HaalCentraal: bijzondere aandacht

4.1.4.1. Dit is geen 'voorziening' zoals de andere en daarnaast is de de functionliteit nog niet in productie

4.1.4.2. Het concept is echter dusdanig onderscheidend dat aandacht voor HaalCentraal bijdraagt aan de resultaten van deze verkenning, en (vooral) aan de (eventuele) toekomstige oplossing

4.2. Feitelijke beschrijving top 4

4.2.1. KDP

4.2.1.1. Scope

4.2.1.2. Functies

4.2.1.3. Aard/Techniek

4.2.2. Datapunt

4.2.2.1. Scope

4.2.2.2. Functies

4.2.2.3. Aard/Techniek

4.2.3. Centraal Aansluitpunt

4.2.3.1. Scope

4.2.3.2. Functies

4.2.3.3. Aard/Techniek

4.2.4. BCS

4.2.4.1. Scope

4.2.4.2. Functies

4.2.4.3. Aard/Techniek

5. Interpretatie top 4 + 1

5.1. Overige bevindingen

5.1.1. De vier onderzochte voorzieningen verschillen aanzienlijk in doelstelling

5.1.1.1. We zien dat de doelstellingen en daarmee de scope en functies van de onderzochte voorzieningen aanzienlijk uiteen lopen. Deze variëren van 'enkel' een 'doorgeefluik' van BR-gegevens tot voorzieningen die verrijkte dataservices bieden

5.1.2. Bronhouderszijde: geen API's maar services BR en maatwerk

5.1.3. Geen van de voorzieningen is plug & play

5.1.4. Combinatie van elementen in architectuur

5.1.4.1. Wat bedoelen we hiermee

5.1.5. Specifieke oplossingen voldoen binnen hun setting en domein en vragen niet om een generieke oplossing

5.1.6. Principes in hergebruik

5.1.6.1. Wat bedoelen we hiermee

5.1.7. Helder doel en governance dragen sterk bij aan succes voorzieningen

5.1.8. Agile (aanpak, tools, besturing, teams) draagt bij aan succes voorzieningen

5.1.9. 'Basisregistraties sluiten fundamenteel onvoldoende op elkaar aan om enkel met API's goede gecombineerde dataservices te kunnen leveren'

5.2. HaalCentraal

5.2.1. concept van de voorziening

5.2.1.1. Enige die bron aanpakt

5.2.2. Huidige status

5.2.2.1. Nog geen productie

5.2.2.2. Nog geen integratie

5.3. Kernpunten van 4 meest geschikte voorzieningen

5.3.1. Kadaster Dataplatform

5.3.1.1. combineren van data uit verschillende bronnen

5.3.1.1.1. Voorziening die in de kern gericht is op het relateren van data uit verschillende bronnen (zowel hard als semantisch). Maakt gebruik van linked data technologie

5.3.1.2. focus op geo-data

5.3.1.3. Nadruk op geo-data

5.3.1.4. Linked data technologie

5.3.1.5. Tijdreizen door de data

5.3.1.6. Tijdrijzen

5.3.1.7. REST API en RDF

5.3.1.8. Geen gebruikersinterface,

5.3.1.9. Inlezen en indexeren van brondata (datakopien)

5.3.1.9.1. KDP kiest bewust voor het inlezen en indexeren van de brondata (redundante opslag),

5.3.2. Basisregistratie Communicatie Service

5.3.2.1. Nadruk op ontzorgen afnemers in berichtenverkeer met BR

5.3.2.2. Aanvullend: mechanisme voor slimme bevragingen

5.3.2.3. eenvoudige gebruikersinterface

5.3.2.4. Geen API's maar Wus en Ebms services

5.3.2.5. Schaalbaarheid (nu nog) punt van aandacht

5.3.2.6. niet GEO-aware

5.3.2.7. Ingericht op justitiedomein

5.3.2.8. geen datakopien

5.3.3. Centraal Aansluitpunt

5.3.3.1. Primaire functie: ontzorgen berichtenverkeer

5.3.3.2. gebruik standaard open source software (WSO2)

5.3.3.3. Ontsluit ook GEO-registraties

5.3.3.4. geen user interface

5.3.3.5. Enkelvoudige services

5.3.3.6. geen datakopien

5.3.3.7. Geen UI, alleen API's

5.3.3.8. Tevens ontsluiting geo data

5.3.3.9. Verwerking gebeurtenis berichten

5.3.3.10. Geen API's maar Wus en Ebms services

5.3.4. Datapunt Amsterdam

5.3.4.1. Ontsluiten groot aantal registraties in samenhang

5.3.4.2. breed pallet aan functies

5.3.4.3. Gebruiksvriendelijke interface, naadloos over bronnen heen

5.3.4.3.1. Alle data integraal doorzoekbaar, gebruik makend van elastic

5.3.4.4. Verstrekking geheel API-gebaseerd

5.3.4.5. Gebruikers interface voor interne medewerkers en externe gebruikers

5.3.4.6. Flexibele en modulaire architectuur

5.3.4.7. Focus op ontsluiting gemeentelijke data (Amsterdam)

5.3.4.8. werken met kopieën van bronnen

5.3.4.9. Modulaire architectuur

5.3.4.10. omgaan met verschillende niveau's van vertrouwelijkheid

6. Conclusie

6.1. Geen van de onderzochte voorzieningen biedt een kant en klaar oplossing

6.1.1. Geen van de voorzieningen vormt een klant en klare 'solution' die zonder aanpassingen landelijk ingezet kan worden. Alle zullen aangepast moeten worden aan de nieuwe situatie; deze aanpassingen vragen een combinatie van aanvullend onwtikkelwerk én configureerwerk

6.2. DataPunt voldoet het meest aan de functionele eisen geformuleerd in deze opdracht

6.2.1. DataPunt onderscheidt zch door het verenigen van een groot aantal functies (die afzonderlijk in de andere voorzieningen ook bestaan, maar niet gecombineerd). In het bijzonder moet daarbij genoemd worden het combineren van data uit meer bronnen, het bieden van en intuitieve gebruikersinterface, het verenigen van GEO en niet-GEO functies en het ontsluiten van data via RESTfull-API's

6.3. HaalCentraal voldeed niet aan de primaire criteria in dit onderzoek, maar verdient desalniettemin bijzondere aandacht

6.3.1. HaalCentraal is op dit moment nog in pilotfase; de visie van HaalCentraal omvat zowel enkelvoudige API's op de BR als een integrerende laag daaroverheen. op dit moment is een van de API's op de bronnen gevorderd tot niveau 'release candidate'

6.3.2. Verbeteren van de de ontsluiting BR aan de bron door het ontwikkelen van goede API's is alleen onderdeel van HaalCentraal

6.3.3. Daarmee is deze ontwikkeling complementair met andere onderzochte voorzieningen.

6.4. Combineren van gebruiksvoorziening met HaalCentraal vormt een te verkennen pad

6.5. (Technische) geschiktheid voor hergebruik vraagt nadere analyse

6.5.1. Alle onderzochte voorzieningen zijn op moderne leest geschoeid

6.5.2. Het gebruik van een 'enterprise servicebus oplossing' maakt her hergebruik van het CA en de BCS minder wenselijk. BCS lijkt vervlochten in en afsgestemd op het justitie domein. KDP maakt in de kern gebruik van linked data technologie. Deze technologie heeft zich nog niet bewezen in grootschalige voorzieningen waarin performance van groot belang is

7. Vervolg en Advies

7.1. Ontwikkel op generieke bouwblokken

7.2. Datapunt als voorbeeld architectuur

7.3. HaalCentraal als oplossing voor ontsluiting

7.4. Vorm van organisatie moet passen bij het maken en hergebruiken van oplossingen