Het idee is dat het koppelvlak leidt tot minder maatwerk, lagere aansluitkosten, kortere doorlooptijden, beter versiebeheer en afnemende complexiteit en beveiligingsrisico’s. KING, gemeenten en leveranciers realiseren op deze manier gezamenlijk een betere match tussen de gemeentelijke behoefte en de implementatie van de StUF standaard. Het koppelvlak-gegevensmagazijn komt ook beschikbaar op het StUF Testplatform, waardoor leveranciers kunnen laten zien dat ze deze services juist hebben geïmplementeerd.
Dat mag echter best wat kwantitatiever. Wat zijn de kosten? Wat zijn de opbrengsten? Wat zijn de risico's en wat de kansen? Hoeveel scheelt het dan bij gemeenten? En wat is de toegevoegde waarde voor leveranciers?
We moeten ervoor zorgen dat er op alle niveaus met hetzelfde koppelvlak wordt gewerkt zodat er niet te hoge kosten voor de gemeente zijn en dat er beter tussen de verschillende applicaties kan worden gecommuniceerd.
Dit generieke koppelvlak voor de GegevensMakelaar (want generiek moet het wel zijn, dus incl. geo component!) moet alle maatwerk koppelvlakken per leverancier overbodig maken. Nu betalen we per aan te leggen koppelvlak vaak de kosten aan twee kanten en werkt het vaak nog niet (direct) goed. Ieder koppelvlak loopt behoorlijk in de papieren en in de tijd en energie die het kost om (aan) te leggen. Dat kan goedkoper en efficienter.
Het is interessant om geld en energie te besteden aan dit onderwerp als het alle maatwerkkoppelingen vervangt. Leveranciers mogen alleen nog maar leveren als ze deze 'stekker' gebruiken. Vergelijk het systeem van stroomdistributie. Overal gebruiken we 230V met dezelfde stekkers. Amerikanen moeten een ander verlengsnoer mee leveren, maar zonder dat verlengsnoer koopt niemand het apparaat. Er hoeft niet meer aan iedere leverancier bij ieder product extra te worden betaald voor koppelingen. De eisen horen gelijk ook te gelden voor de gebruikerskant. Wij (alle overheden) gebruiken alleen deze koppeldoos. Niet meer verschillende StUF-versies binnen één ministerie.
Nog een aanvulling. een dergelijk koppelvlak zou er voor moeten zorgen dat je applicaties van verschillende leveranciers naast elkaar kan gebruiken. Niet meer de noodzaak om maar een leverancier te kiezen, omdat het anders niet werkt. Geen extra werk meer door twee leveranciers om elkaars applicatie te koppelen. 'Gewoon' inprikken en het werkt. (Ik blijf dromen!)
Op dit moment zijn de kosten van het implementeren, draaiend houden en migreren (nieuwe nodes) van koppelvlakken aanzienlijk hoger dan de opbrengsten bij de gemeente. Dat maakt het in deze financieel lastige tijden niet aantrekkelijk of onmogelijk om veel e-diensten aan te bieden. Door goede standaarden kunnen de kosten per individueel koppelvlak dalen. Waar nu het nog "toeval" is dat een gemeenteklant een e-dienst aantreft kan hierdoor bovendien het palet aan e-diensten breder worden, waardoor het e-loket vaker het "standaard" kanaal wordt waar een klant als eerste kijkt. Dat bevordert het gebruik van alle e-diensten, en dus het rendement van de - vaak generieke - voorzieningen.
Het uitbreiden van prefill met de benodigde zoekpaden voor bevraging van het gegevensmagazijn binnen de interfacedefinitie leidt tot minder maatwerk, lagere aansluitkosten, kortere doorlooptijden, beter versiebeheer en afnemende complexiteit en beveiligingsrisico’s. We realiseren gezamenlijk een betere match tussen de interfacedefinitie en de praktische implementatie er van.
Zolang we als gemeenten na het in gebruik nemen van de standaard prefill hier toch aan gaan sleutelen heeft het naar mijn idee weinig tot geen zin om hier mee aan de slag te gaan. Het is dus van belang om een manier te vinden om een goede standaard te onwikkelen, misschien binnen een domein een standaard? Het zal veel duidelijheid scheppen indien er een prefill wordt vastgesteld. We zullen deze dan wel als gemeente moeten accepteren.