Wat is de scope? Wat maakt dat je een service/bericht wel of niet opneemt in dit koppelvlak?
Het zijn die services op het gegevensmagazijn die door veel andere processen gebruikt worden. Door deze te definiëren een aan te bieden voorkom je wildgroei. In feite definieer je een portfolio van vragen die gesteld kunnen worden aan het GM waarmee je de meeste afnemers en de meeste vragen kunt afhandelen.
De vraag is dus welke services er bij jouw gegevensmagazijn het meest worden gebruikt. Daar kunnen uiteraard ook zoekvragen bij zitten op basis van geo-gegevens.
Welke shortlist zou jij aan willen bevelen?
Als we de lijstjes van de diverse partijen bij elkaar hebben, dan lijkt het me niet zo moeilijk om degenen die bij meer partijen voorkomen daar uit te selecteren.
Een eerste lijst:
Jan, Het lijkt me goed om vooraf te bepalen welke services momenteel reeds door de diverse leveranciers geboden worden. Dit kan bijvoorbeeld door de WSDL's en de koppelvlak beschrijvingen op te vragen. PinkRoccade kan je indien gewenst een uitgebreide koppelvlak beschrijving aanleveren. Hierin staan alle berichten die door Makelaarsuite ondersteunde worden inclusief vraag berichten aan het (gegevens en zaken) magazijn. Hierbij kunnen alle gegevens opgevraagd worden met willekeurige selectie en scope. Wij hebben er dus niet voor gekozen om een beperking te leggen op de selecties of de scope die een service requester kan opnemen. Afhankelijk van de keuzen en opties van andere leveranciers, kan bepaald worden of en op welke vlakken specifieke koppelvlakken nodig zijn. Omdat in veel toepassingen specifieke selecties en gegevens gewenst zijn (selectie en scope), kan ik me voorstellen dat de bestaande vraag- en antwoordservices binnen StUF BG en StUF ZKN uiteindelijk (impliciet) het koppelvlak zullen vormen. Groeten, John.
In een ideale wereld is het een totaal-oplossing voor alle koppelingen. Geo juist meenemen, omdat steeds meer voordelen gehaald kunnen worden door gegevens op de kaart te plotten en te laten zien. Bij de aanpak moet inderdaad eerst gekeken worden naar de meest gebruikte/gevraagde koppelingen/gegevens. Als we iets nieuws opzetten, moeten we echter wel uitgaan van wat wij nodig hebben en niet vanuit wat een leverancier kan/wil leveren. We moeten nu serieus werk maken van leveranciersmanagement.
Als beheerder van het nieuwe koppelvlak stel ik me VNG of KING voor. Door een portfolio van vraagcombinaties vast te stellen leg je een set van zoek- of vraag-producten vast. Naar mijn idee moet zo'n portfolio gebonden zijn aan de wettelijke taak die ermee moet worden uitgevoerd. Er zijn dus meerdere portfolio's. Daarnaast kun je je voorstellen dat er geaggregeerde informatie is op te vragen voor de uitoefening van bepaalde taken. Een rampenbestrijder bijvoorbeeld wil weten hoeveel mensen er in een bepaald gebied of pand (BAG en BRP) wonen maar hoeft in eerste instantie niet hun namen te weten maar slechts het geslacht en de leeftijdsopbouw. Softwareleveranciers vormen een aparte groep en krijgen van de beheerder een sleutel voor de tekenset waarmee ze het koppelvlak kunnen gebruiken.
Aansluitend op voorstel van John om tot een scope bepaling te komen. Lijkt me prima om te beginnen met het inventariseren wat er al is bij de softwareleveranciers. Wij (GouwIT) kunnen hier ook aan bijdragen. Vervolgens de werkelijke business waarde gaan bepalen per bestaande prefill dienst en aanvullen welke pre fill dienst er nog gemist wordt. Een productowner - de beheerder die Leo bedoeld - moet dit werk uitvoeren (inventariseren en prioriteiten bepalen). Hierbij het criterium gebruiken - zoals Leo aangeeft - "hebben we te maken met wettelijke taak of niet?" en "wat is deadline van deze wettelijke taak?". Probleem is echter dat 1 productowner die alle wettelijke taken van voor tot achter kent, niet bestaat, ook niet bij de VNG. Er zullen meerdere productowners nodig zijn die gezamenlijk het gehele stelsel afdekken en de wettelijke taken kennen. Iedere productowner dekt dan - zoals Leo aangeeft - een bepaald portfolio af. Deze productowner moet een persoon zijn met gezag en inzicht in de praktijk, en komt dus niet uit hoek van leveranciers, dienstverleners of architecten, maar moet in mijn ogen uit de hoek van de stelselbeheerders komen. In de WOZ wereld is dat de Waarderingskamer, bij BRP is dat iemand van BPR, bij BAG iemand van Kadaster, etc. KING faciliteert hierbij met bijvoorbeeld een leveranciersoverleg met alle productowners erbij, maar zou niet de formele beheerder moeten zijn van het koppelvlak.
Functionele scope: zoeken en raadplegen
Domeinscope: voor nu eerst BRP, BAG en NHR
Wat is de scope is de vraag, ik kan mij van alles voorstellen bij de eerdere reacties echter kom ik ook een crib functionaliteit tegen. Deze is naar binnen gericht. Zelf had ik het idee bij de vraag dat het ging om dienstverlening naar de burger toe? Een selectie kunnen maken is dan naar mijn idee niet van toepassing? Als ik een antwoord geef zoals ik de vraag heb begrepen zou voor mij de scope van prefill moeten zijn het inloggen met DigiD of eHerkenning, daarop de gegevens van persoon of bedrijf met in het laatste geval gemachtigde wordt teruggegeven. Afhankelijk van het proces wat wordt opgestart dient dan aanvullende informatie mee terug gegeven te worden. Als voorbeeld, ik wil een invalide parkeerkaart aanvragen. Zodra ik dit proces opstart is het wenselijk om in het formulier mee terug te geven dat ik al een parkeerkaart heb. Dit geeft een ander soort aanvraag dan een eerste aanvraag. De vraag van mijn kant af is dan ook of de prefill zich alleen tot externe processen moet beperken of dat het hier ook over interne processen gaat?
Gilbert, inloggen met DigiD of eHerkenning gaat vooraf aan het prefillen van formulieren. Dit overigens terzijde voor het bevragen van een gegevensmagazijn, waar het in dit topic over gaat. Het gaat hier nu om welke services een gegevensmagazijn zou moeten bieden voor het ontsluiten van RSGB gegevens. RSGB is dus de eerste scope afbakening. Voor verdere toelichting zal ik een bijlage toevoegen met de presentatie en de bijbehorende notulen van de bijeenkomst op 22 augustus.
Bijlage
In de werkgroepsessie op 22 augustus hebben we afgesproken dat we beginnen met een inventarisatie: welke bevragingen worden nu in de praktijk gebruikt en wat zijn daarbij de processen waarin die bevragingen worden gebruikt. In de 'bibliotheek' is een template opgenomen waarmee die inventarisatie kan gebeuren. Wij zullen die integreren en weer zichtbaar maken. Zo komen we er 'vanzelf' achter waar het meest behoefte aan is. Door clusters van bevragingen te onderkennen kunnen we: - het koppelvlak beheerst ontwikkelen - straks ook gedifferentieerd aangeven met welk deel je compliant bent. Het vraagstuk dat we op te lossen hebben is: wat zijn deze clusters? Wat zijn de clustercriteria?