Ga naar inhoud
labs.kadaster.nl

Oplossingen

OK. De probleemstelling is (dus) deze. We zijn in een transitie van papier naar digitaal. In die transitie is het ontstaan van data, de context waarin die ontstaat en waarin die gebruikt wordt relevant en daarmee worden taal en semantiek van belang om in acht te nemen. En dat allemaal in een steeds verdergaande automatisering.

Tot welke oplossingen komen we dan? Zijn er wel oplossingen? Of zijn het meer oplossingsrichtingen en een droombeeld?

Droombeeld

In de transitie van papier naar digitaal nemen we onszelf serieus door een andere richting te nemen dan zoals we al lang gedaan hebben. We durven de stap te maken om digitale processen te ontwerpen en in te richten. Uiteraard hebben we dezelfde zekerheden nodig als in de huidige situatie ... maar dat kunnen we wél anders doen!

Daarvoor ontwerpen we een netwerk van gebeurtenisgedreven registers waarin expliciet is gemaakt hoe datastromen gaan en hoe die overgangen van context zijn. Er verschijnt een netwerk van elkaar beïnvloedende deelnemers, partijen, nodes die samenwerken in een organisme. Autonome onderdelen die zelf beslissingen maken, zelf gebeurtenissen produceren én zorgen voor de traceerbaarheid wat de impact daarvan is. Vergaand geautomatiseerd dmv van open samenwerking en design for change.

Dat biedt de mogelijkheid om expliciet vast te leggen welke data is gebruikt bij een beslissing. Daaruit kan ook worden geanalyseerd welke impact een mogelijk nieuw inzicht heeft op een genomen beslissing. Daarmee worden correcties mogelijk. Daarmee wordt het mogelijk om simulaties te doen van nieuwe regelingen en wetgeving. We kunnen regelingen ontwerpen die exact bereiken wat we voor ogen hebben!

Hoewel deze gehele infrastructuur in open samenwerking tot stand gebracht moet worden, is het vooral het 'onzichtbare deel van de digitale overheid' dat 'gewoon werkt'. Het is er gewoon. Het werkt. En het werkt top! Daar kunnen burgers en bedrijven op rekenen. Het kan gevalideerd worden door toezichthouders. Er kunnen allerlei controlemechanismen ingebouwd worden. En het kan vooral gebruikt worden.

Het gevolg van een subliem werkende digitale overheid is dat er ruimte komt om de mens meer centraal te stellen ipv computer systemen. We kunnen ontwerpen waar mensen een beslissing kunnen sturen en beïnvloeden, zodat de juiste effecten bereikt worden. Het is mogelijk om te ontwerpen dat er ambtenaren zijn die burgers kunnen ondersteunen en helpen bij hun aanvragen, verwerkingen, verantwoordelijkheden en rechten. Een subliem werkende digitale overheid brengt een meer menselijke en persoonlijke overheid! ❤

Gebeurtenisgedreven registers

Om te beginnen moeten we alle data als data gaan respecteren. Ook de documenten die aanleiding voor wijzigingen in de registraties zijn. En vooral die wijzigingen zelf. De data-gebeurtenissen of events. Deze beschrijven in detail met welke intentie een register gewijzigd wordt, wat die wijziging inhoudt, wie dat gedaan heeft, op welk moment, op welke plaats. En als dat gebeurd is, dan is dat gebeurd. Punt.

Dat betekent om te beginnen dat van elk register moet worden ontworpen wat de data-gebeurtenissen/events zijn. Welke wijzigingen zijn er? En als er verschillende aanleidingen zijn, dan zijn dat zeer waarschijnlijk ook verschillende wijzigingen. Alleen al de intentie die daarin ligt.

Vervolgens moet ook ontworpen worden hoe deze wijzigingen tot een projectie leiden. De primaire projectie is hier leidend en het meest belangrijk. Dit behoudt immers dezelfde waarde als de huidige registers. Met de events hebben we vooral beter vastgelegd hoe het register is geworden tot wat het geworden is.

Vervolgens dient per context overgang ontworpen te worden welke projectie daar passend is. Zeer waarschijnlijk zijn dit projecties die afgeleid kunnen worden van de primaire projectie ... maar vaak vereenvoudigd kunnen worden. Onze inschatting is dat primaire projecties voor het domein, de context, waarin deze gewijzigd wordt, de meest complexe projectie nodig heeft. Er is namelijk vaak ook niet meer data beschikbaar dan in de eigen context en dus primaire projectie nodig is.

Uiteraard kan er uniformiteit aangebracht worden in de secundaire projecties om het aantal transformaties en contextovergangen beperkt te houden. Dat is ook in het voordeel van de bronhouder. Dat is de actor, de organisatie die de wijzigingen doet en dus events produceert. Zij zijn namelijk verantwoordelijk voor de primaire projectie én alle secundaire projecties die formeel vanuit die context worden geleverd aan alle contextovergangen. De bronhouder dient dan ook voorzieningen te leveren en te onderhouden voor het beheer en synchroniseren van alle projecties. Daarover later meer.

Deze inrichting is nodig om te kunnen beantwoorden aan echt digitale processen. Daarin worden contract, processen, afspraken geautomatiseerd uitgevoerd. Dat betekent niet dat er geen menselijke beslissingen meer in zitten, maar die geven alleen richting in de verder geautomatiseerde uitvoering. Deze uitvoering dient duidelijk, traceerbaar en controleerbaar te zijn.

Met events is het mogelijk om de traceerbaarheid te borgen tussen formele beslissingen, bij voorkeur door mensen gemaakte beslissingen, en de verschillende projecties. Doordat events als een 'stroom van events' worden opgeslagen en gepubliceerd, is het ook direct mogelijk om bij elke projectie te laten zien tot hoever deze projectie is bijgewerkt. Het geeft daarmee niet alleen mogelijkheden voor de traceerbaarheid maar ook voor een expliciete actualiteit!

Als de events als kern van de beslissingen en wijzigingen gezien worden, wat in Event Sourcing het geval is, dan is ook de historie waterdicht vastgelegd. Vanuit de stroom van events kan elk historiemodel gevuld worden en kan maximaal herleid worden hoe 'het is gegaan en geweest'.

Van events is expliciet wat de bron is. Van elk event is bekend wie de actor is die het heeft doen ontstaan, op welk tijdstip, locatie en intentie. Door projecties en de traceerbaarheid inclusief actualiteit is het mogelijk om per gebruik te bepalen in welke vorm een projectie het meest passend is. Als een bronhouder een API aanbiedt op de projectie en dat voorziet in de behoefte vanuit de vraag, dan is dat een gemakkelijk beheersbare en betrouwbare manier. Echter, het is met dezelfde kwaliteit mogelijk om een projectie op een andere locatie, dichter bij de vraag te realiseren. Dat is onder dezelfde kwaliteit want projectie, traceerbaarheid en actualiteit worden op exact dezelfde manier gerealiseerd als dat die projectie bij de bronhouder zou staan. Dat betekent wel dat de bronhouder verantwoordelijk is voor die projectie, ook als die niet in zijn data center staat. Daar zijn aanvullende afspraken voor nodig ... maar dat is goed mogelijk.

Dus gebeurtenisgedreven registers bieden:

  • ✅ traceerbaarheid van het register, de primaire projectie
  • ✅ mogelijkheden voor secundaire projecties (en daarmee)
  • ✅ ondersteuning voor context overgangen (transformaties, service voorwaarden, data minimalisatie, etc)
  • ✅ ondersteuning voor actualiteit per projectie
  • ✅ ondersteuning projecties op 'afstand' (in het data center van een andere partij)
  • ✅ absolute duidelijkheid over oorsprong (actor, locatie, tijdstip, intentie)
  • ✅ volledige ondersteuning voor historisch begrip (onderzoek, reconstructie, historiemodellen, etc)
  • ✅ mogelijkheden voor vergaande automatisering

In bovenstaande worden events, data-gebeurtenissen en wijzigingen door elkaar gebruikt. Elke keer wordt hetzelfde bedoeld: data-gebeurtenissen zíjn events wat de wijzigingen ín een register zijn.

Open samenwerken

In Nederland wordt al langer aan een 'open overheid' gewerkt, maar er is méér nodig. Om vertrouwen in projecties te hebben in een gebeurtenisgedreven register is het noodzakelijk dat anderen kunnen controleren en inzien hoe die projectie tot stand komt. Data en open data zijn 'slechts' één deel van de puzzel. Software is ook een puzzelstuk dat in ogenschouw genomen moet worden. Dat volgt ook uit de drive van automatisering.

In de overgang van de ene context naar de andere betreft dat altijd meerdere partijen. Dat kunnen al afdelingen binnen een organisatie zijn, maar nog vaker zijn dat verschillende organisaties. Ook en vooral juist dáár is vertrouwen van belang. Door open samen te werken aan dezelfde software die voor die overgang verantwoordelijk is, wordt vertrouwen en kwaliteit tussen de partijen haalbaar.

Open samenwerken is in Open Source Software al jaren ontwikkeld en toegepast. We kunnen daar veel van leren in hoe dat werkt. Open samenwerken zou daarom ook 'open source werken' genoemd kunnen worden. 'source' is in deze vaak software, maar zou ook heel goed 'documenten', contracten of iets dergelijks kunnen zijn. Zie ook Achtergrond: Open Source.

  • ✅ gebeurtenisgedreven registers kunnen niet bestaan zonder open samenwerken!
  • ✅ open samenwerken draagt bij aan de controleerbaarheid en daarmee het vertrouwen in de digitale infrastructuur

Netwerken & Datastromen

Geen enkel proces of bedrijf staat nog volledig op zichzelf. De wereld is verbonden en dat groeit alleen nog maar verder! Hoe kunnen we daar anders 'antwoord' op geven dan de netwerken recht doen die zich aandienen? Welke verbindingen zijn er tussen de punten, nodes, onderdelen van het netwerk? Kunnen we dat inzichtelijk maken? Kunnen we de inzicht geven hoe de data stroomt?

In een netwerk van gebeurtenisgedreven registers stromen events van het ene proces en organisatie naar het andere. Telkens zijn daar expliciete contextovergangen die in open samenwerking worden onderhouden. Op deze manier vertoont zich het netwerk van deelnemers dat verbonden is ... maar ook in welke richting welke data stroomt en hoe deze getransformeerd wordt in de overgangen van context. En dit kunnen we ontwerpen. We kunnen actief sturen op de netwerken en de datastromen om richting te geven aan hoe deze de maatschappij kunnen dienen.

  • ✅ ontwerpen en inzichtelijk maken van netwerken ondersteunt het inzicht en overzicht van gebeurtenisgedreven registers
  • ✅ datastromen maken inzichtelijk hoe data van waar naar waar stroomt ... en hoe daarop de sturen is

Design for change

“The Only Constant in Life Is Change.” - Heraclitus

Ook in een wereld van software, zie ook automatisering, is er slechts één zekerheid: 'change', verandering. In een digitale overheid dienen we daarom gericht te zijn op het ondersteunen van verandering: Design for Change.

Dat was wat agile destijds ook adresseerde. Mensen en hun interactie zijn belangrijker dan procedures en tools. Voor een digitale overheid betekent dit dat we vergaande automatisering doen met volledig digitale processen. En dat we ín die processen mogelijkheden ontwerpen om menselijke interventie mogelijk te maken. Dat vraagt een mindset van automatiseren. Kennis van automatiseren. De drive om alles te automatiseren. En tegelijk, juist functies ontwerpen, inverentie mogelijkheden om bijsturing te kunnen doen als menselijk optreden vereist is. Hierin liggen ook mogelijkheden om 'de menselijke maat' en 'publieke waarden' toe te kunnen passen op individuele casuïstiek.

  • ✅ geautomatiseerde digitale processen
  • ✅ publieke waarden en menselijke interventie mogelijkheden ingebouwd