Eén Rijksdienst kan werken. Maar begin bij de basis.

Ik zou hem toch wat aanscherpen, want 12+ datalandschappen kan wel degelijk en dat moeten we ook vooral houden. De essentie van de digitale transformatie is NIET het digitale, maar de TRANSformatie: het is geen technisch, maar een socio-cultureel vraagstuk. Natuurlijk faalt elke poging tot centraliseren, standaardiseren en harmoniseren (de bekende Ijzeren Wet van de Oligarchie), want dat botst keihard op combinatorische effecten. Je praat over allerlei suborganisaties met allemaal organisch gegroeide landschappen en die hangen weer aan niet zomaar te breken bedrijfsculturen en leveringscontracten. Dat moet je niet eens WILLEN centraliseren. Dat komt OOK door gebrek aan kennis, want de missen de benodigde kennis hoe je wel degelijk van die legacy een hypermoderne organisatie kunt maken. Laten we dan ook eindelijk afscheid nemen van al die achterhaalde top-down managementmethoden en de vergadercultuur.
Diepe inhoudelijke kennis van moderne datavoortbrenging en data ecosysteembouw is cruciaal om de digitale transformatie effectief te sturen. Zonder goed begrip van de bestaande systemen, definities en datastromen, mislukt anders ook datacentrisch werken. Om te beginnen zouden wij afscheid moeten nemen van document en proces gebaseerd Output denken en eindelijk eens moeten gaan denken in reality pull datacontext centrisch Outcome denken. Wat is er af als het af is? Wie levert welke data onder welke voorwaarden in welk format aan welke entiteit, hoe gaan we die entiteit herkennen en wat spreken we onderling af in termen van wederzijdse authorisatie?
We moeten technologie gebruiken voor wat het is: een middel om antwoord te geven op concrete behoeften en problemen; technologie is geen doel op zich en 'de Basis op Orde' is absolute onzin want er is nu ook geen Basis en er zit een schatkamer aan datarrelaties verborgen in de legacy zoals die nu is. Daar zijn uitstekende middelen voor.
Data space referentie architectuur is essentieel. Dit is virtuele architectuur, geen tastbare legacy en het biedt een blueprint voor het beheren van data-uitwisseling tussen verschillende organisaties en systemen. Door open standaarden en federatieve data-architecturen te implementeren, kun je razendsnel zorgen voor consistente en betrouwbare datastromen, wat een basis creëert voor effectieve AI-toepassingen en je legacy een fris nieuw economisch leven geeft. Hoef je niets voor bij te kopen.
Zet er dan wel een paar man op die het snappen, want het traditionele top-down controle paradigma is echt niet effectief in complexe dynamische digitale omgevingen. Als de Oekraïners nog op die manier hun projecten zouden doen, was de vijand allang overleden van ouderdom. Bounded rationality beperkt nou eenmaal de besluitvormings capaciteit doordat het veel te weinig rekening houdt met de volledige complexiteit van de situatie. Evolueren naar veel sneller adaptieve en lerende organisatiestructuren is noodzakelijk om de combinatorische effecten tussen strategische, tactische en operationele niveaus te beheersen. Daar ga je niet mee komen met een wekelijkse 'vergadering' waarbij je de meest basale elementen van zo'n architectuur moet uitleggen aan een manager die nog op zoek is naar 'draagvlak' en 'wie gaat er over'. Daar heb je namelijk niets aan als je een context broker de data relaties onder Policy by Default laat aftikken in real time met verslaglegging op een ledger, 24/7. Waarom zo wel?
Data stroomt tegenwoordig veel meer TUSSEN dan BINNEN onze organisaties, wat disruptie in de datavoortbrengingsketen veroorzaakt. Een datavoorbrengingsketen die de facto doorgaans domein overschrijdend is en daarmee in het 'oude Systeem' ook mandaat overschrijdend is. Zonder gestandaardiseerd kader voor data-uitwisseling leidt dit tot inefficiënties en fouten, maar een gestandaardiseerd uitwisselingskader (zoals www.ngsi-ld.org) is iets heel anders dan een gelijkschakeling op data format. Kun je gewoon contextueel mappen. Aangezien iedereen altijd bang is voor sociale weerstand tegen verandering, vooral als dit inhoudt dat bestaande systemen en processen moeten worden aangepast, is het ook minstens zo belangrijk om ons te realiseren dat grote delen van de overheid nog vooral bestaat uit lokale gilden, met veelal handmatig werk en losse applicatie. Dus ALLES is een verbetering en op je beeldscherm hoeft de eindgebruiker daar vrijwel niets van te merken anders dan dat het eigen werk ineens een stuk soepeler gaat.
Eens dus met de geïdentificeerde drie stappen, maar met een nuance:
Stap één: weet welke data je hebt. Ja, maar weet vooral waar die data staan (asset management), zodat je een NGSI-LD API ernaar kunt laten verwijzen onder de juiste Policy Enforcement regels. (org A zegt 123, waar org B abc zegt). Er kan vreselijk veel met context brokers en https://github.com/smart-data-models, maar ook weer niet zonder strak modelleren. Welke gegevens bestaan er, waar staan ze, wie is er verantwoordelijk voor en wat betekenen ze precies zijn vragen die je niet op kunt lossen als CIO, CDO, CISO en CTO niet van hetzelfde blad muziek lezen.
Stap twee: zorg voor gedeelde definities, ja en nee. Ja, je ontkomt niet aan beleidsafspraken, maar nee, er bestaan echt prima technische raamwerken die zorgen dat het grotendeels weg te automatiseren is. Denk aan Smart Data Models (SDM) en de oude www.fiware.org/catalogue, waarmee je prima JSON Schema-definities voor duizenden entiteiten (Person, Building, Request, Decision, enz.) zo kun gebruiken. De semantische laag die via JSON-LD @context betekenis toevoegt aan ruwe data, zorgt dat elk attribuut een URI krijgt die verwijst naar gedefinieerde betekenissen. Scheelt bakken tijd en geld en je komt ook op een prima cross-domein consistentie. Zo heeft een "Person"-entiteit in parkeerbeheer bijvoorbeeld - in theorie - dezelfde structuur als in sociale diensten en de EU wetgeving dwingt toch al tot harmonisatie, dus het was sowieso al tijd om van al die zelfbedachte definities af te stappen, maar doe het dan op basis van internationale standaarden. Dan is er het levenscyclusbeheer van die harmonisatie modellen. Dat is in uitstekende handen bij de stuurgroep (FIWARE Foundation, TMForum, OASC, IUDX) die de consistentie en evolutie van die modellen bewaakt.
Laten we dat nou alsjeblieft niet overlaten aan ad-hoc werkgroepjes van externen en schoolverlaters. Externe mapping van bestaande standaarden (schema.org, GTFS, DCAT-AP) zorgt dat ook nieuwe modellen meteen kunnen aansluiten bij wat er al is.
Data context broker code fungeert als (de)centrale hub waar data uit verschillende systemen convergeert en het NGSI-LD-protocol zorgt voor uniforme API-interoperabiliteit, zodat we eindelijk af kunnen stappen van vaak slecht opgebouwde REST API.
We ontkomen alleen niet aan het onderling afstemmen tussen domeinen.
Smart Data Models zijn georganiseerd per "Vertical/Subject" (Parking, Weather, Mobility, etc.). Er is geen verplichte cross-departementale afstemming. Als Burgerzaken een "Aanvraag" definieert in één subject en Belastingdienst een andere in een ander subject, bestaat er dus geen automatisch conflictoplossingsmechanisme. Daarom punt 1: modelleren, want dit past ook in de soevereiniteitsdiscussie: governance is decentraal en vrijwillig, maar je moet data wel naar elkaar kunnen laten verwijzen onder voorwaarden. Elke community beheert zijn eigen modellen. Er IS geen centrale autoriteit die verplichte harmonisatie afdwingt tussen departementen binnen één organisatie.
Daarom kun je prima 12 data ecosystemen hebben die al dan niet naar elkaar verwijzen en zo behoudt je ook het Huys van Thorbecke, maar nu met dubbelglas en airco.
Stap drie: ontsluiting via een API-first strategie of Model Context Protocol (MCP)
Honderd punten, maar dan graag wel www.ngsi-ld.org en conform het International Data Space Reference Architecture Model ;-)