KOERS

KOERS staat voor Kadaster Objecten En Rechtenregistratie Systeem en het is het systeem voor de bijhouding van de Basisregistratie Kadaster, de BRK. Dit is het verslag van de ontwikkeling en highlights van de succes ingrediënten van het gelijknamige project waarin dit systeem ontwikkeld is. Daarbij was het doel om het 40 jaar oude mainframe systeem te vervangen en op te ruimen …

Hoe het begon — 1832

Het Kadaster vindt zijn oorsprong in de Franse tijd: in 1811 besloot Napoleon dat Nederland een kadaster en openbare registers moest krijgen, zodat duidelijk was welk stuk grond van welke eigenaar was. Het Kadaster bestaat officieel sinds 1832 en groeide uit tot de organisatie die verantwoordelijk is voor het registreren en ontsluiten van onroerende zaken en de rechten daarop. Het Kadaster is daarom een publieke instantie met een kerntaak in rechtszekerheid. Die taak is later wettelijk vastgelegd in de Kadasterwet, die rechtszekerheid als belangrijkste taak benoemt. Dat maakt modernisering van de registratie meteen ook een maatschappelijke en juridische operatie, niet alleen een technische.

De Basisregistratie Kadaster, oftewel BRK, bevat informatie over percelen, eigendom, hypotheken, beperkte rechten zoals erfpacht, opstal en vruchtgebruik, en leidingnetwerken. Ook de kadastrale kaart hoort erbij, met onder meer perceelgrenzen, perceelnummers, oppervlakte en grenzen van rijk, provincies en gemeenten. De BRK is daarmee de authentieke bron voor dit domein en hangt samen met andere basisregistraties en gegevensuitwisseling met bijvoorbeeld notarissen en overheden. De BRK is niet alleen een databestand, maar het operationele hart van de juridische en geografische werkelijkheid van grond en rechten in Nederland.

De situatie — 1962-2014

Het Kadaster liep in Nederland vaker voorop met technologische ontwikkelingen. Al vroeg werden mechanische hulpmiddelen zoals de mechanische rekenmachine en daarna automatisering ingezet om de kadastrale registratie nauwkeuriger en efficiënter te maken. Al in de jaren ‘60 van de vorige eeuw zette het Kadaster de eerste stappen naar automatisering. Rond ‘70 begon op de eerste locatie de introductie van het geautomatiseerde register, en ca. tien jaar later was ook de laatste vestiging overgezet. Met de gereedkoming van AKR, Automatisering van de Kadastrale Registratie, in 1990 kwam er definitief een einde aan de papieren grondboekhouding.

Na de invoering van AKR ging de vernieuwing bij het Kadaster door. De organisatie kreeg in 1992 haar wettelijke verankering in de Kadasterwet, werd in 1994 zelfstandig bestuursorgaan en zette in de jaren negentig verdere stappen richting digitalisering van kaarten, registraties en gegevensuitwisseling. In de periode tot 2014 zijn er verschillende onderzoeken en ‘ontvlechtingen’ gedaan om AKR te verkleinen en uiteindelijk te vervangen door nieuwere technologieën met meer mogelijkheden om mee te bewegen met de eisen van de veranderende tijd. Toch stokten alle initiatieven op het hart van de BRK: het mainframe systeem AKR. Dat zat te vervlochten ingebeiteld in te veel koppelingen met te veel kennis van het domein.

Zo was de situatie tot er in 2014 iets veranderde …

De nieuwe koers — 2014

Na de nodige onderzoeken en try-outs is gekozen voor een visie en strategie om toch de noeste knoop van AKR te gaan aanpakken. Daarbij is bewust gekozen voor eigen regie en expertise als fundament van de vele mensen die betrokken zouden gaan worden (ook extern) bij deze vernieuwing. De strategie luidde:

Opzetten van vaste teams waarin met een continue stroom een nieuw flexibel en toekomstvast systeem wordt opgebouwd waarbij business en IT samen streven naar geleidelijke transitie zonder synchronisatie

Vaste teams duidt op de agile benadering van het gehele project. Daarbij is ingezet op teams waar het werk naartoe geleid kon worden in plaats van werk waar omheen mensen georganiseerd werden. Deze teams zijn multidisciplinaire teams waarin business expertise en software development expertise gecombineerd aanwezig moest zijn. Daar duidt ook de nadruk op business en IT samen op.

Een continue stroom en een flexibel en toekomstvast systeem duidt op DevOps en Continuous Delivery als methodieken en gebruik voor de voortbrenging van het nieuwe systeem. Dat was in 2014 absoluut geen norm en voor een groot deel heeft het Kadaster dat ook zelf moeten uitvinden. Toch is er destijds voor gekozen om te starten met een Continuous Delivery pipeline naar een Platform-as-a-Service (PaaS). Nadat deze technisch ingericht was, is pas begonnen met de eerste functionaliteit ontwikkelen.

De geleidelijke transitie en ‘zonder synchronisatie’ slaan op de introductie van het nieuwe systeem en de synchronisatie van het nieuwe systeem naast het oude systeem, oftewel parallel draaien inclusief uitwisseling van gegevens tussen beide systemen. Daar waren eerder proeven mee gedaan, maar het AKR systeem is dusdanig een eenheid en het hart in een landschap van systemen, dat dit als onhaalbaar werd beschouwd. De strategie was dus expliciet geen synchronisatie.

Projectfase — 2014-2018

Agile wordt vaak als chaotisch ervaren … en zo is ook het project ’niet saai’ geweest! Zoals het eigenlijk hoort in een project, zijn er verschillende fases en zijn er veel veranderingen. Door de organisatie van het project flexibel en wendbaar op te zetten, was het mogelijk om telkens bij te sturen. Zo zijn we begonnen met één ontwikkelteam waar ook de key business analisten direct bij betrokken waren. In de eerste fase is veel beproefd, gezocht, veranderd, aangepast en neergezet. Op een gegeven moment was het logisch om naar meerdere teams op te schalen en deze te organiseren rondom componenten met specifieke functionaliteiten: een frontend team, een registratieteam, een informatieverstrekkingsteam en een integratieteam. De business was overal nodig en werd het werkvoorbereidingsteam genoemd. Later waren de componenten voldoende robuust en stevig en konden we meer gaan sturen op functionaliteiten over het geheel. De teams werden meer fluïde en volgde meer de business functionaliteiten dan de structuren van het systeem. Agile. Flexibel en wendbaar. Top!

Ontkoppelen, scheiden van verantwoordelijkheden en concerns zijn architectuur vraagstukken die ook impact hebben op de schaalbaarheid van teams bijvoorbeeld. Niet helemaal vanaf het begin is CQRS, scheiding van de command-kant en de query-kant toegepast, maar dat gaf ook veel afhankelijkheden. Na de eerste maanden van onderzoeken en proberen zijn we deze scheiding wel duidelijk gaan toepassen aangevuld met Event Sourcing. Hierbij worden wijzigingen in het systeem als events vastgelegd aan de command-kant en vervolgens (pas) verwerkt aan de query-kant. Dit gaf een hele robuuste scheiding in systeem functionaliteit en ook in team focus. Het registratieteam deed de moeilijke business functionaliteiten in het verwerken van nieuwe opdrachten, de command-kant. Het informatieverstrekkingsteam deed de vertaling en verwerking daarvan naar de (vele!) verschillende koppelvlakken die het systeem moest voorzien van informatiestromen.

Bovendien bleken events zeer goed aan te sluiten bij de business wijze van verwerking! De Kadastrale Registratie is de verwerking van notariële akten. Daarin staan rechtshandelingen, ook wel rechtsfeiten genoemd. Vervolgens is de registratie gebaseerd op een informatiemodel waarin diverse entiteiten worden gewijzigd door deze rechtsfeiten. En de business regels waren al ontworpen naar herbruikbare eenheden die door meerdere rechtsfeiten dezelfde of vergelijkbare verwerking teweeg brachten op die entiteiten. Concreet: een leveringsakte - een ’normale overdracht van eigendom’ - en een ‘schenking om niet’ doen eigenlijk voornamelijk hetzelfde onder dezelfde voorwaarden (business constraints) op enkele kleine verschillen na. En dit bleek voor een heel scala aan rechtsfeiten te zijn, die juridisch echt wel verschillende achtergronden en werking betekenen en tegelijk min of meer hetzelfde effect hebben op de Kadastrale Registratie. Events in business termen uitgedrukt, beschrijven zeer precies en effectief de effecten van rechtsfeiten op de business entiteiten. Geweldig!

Door het gebruik van Continuous Delivery, oftewel een continue stroom van wijzigingen vanuit de ontwikkelteams naar de productieomgeving, was het mogelijk om snel en continu (what’s in a name) nieuwe functionaliteiten naar de testteams uit te rollen. Ook verbeteringen van bestaande functionaliteit konden we zo snel ‘in the hands of users’ brengen. Al vroeg in het project werden medewerkers uit de akteverwerkingsteams gevraagd om dezelfde akte naast de normale verwerking in AKR óók in KOERS te verwerken. Vervolgens werden uitkomsten en resultaten vergeleken. Dit werd schaduwdraaien genoemd.

Een voorwaarde voor het schaduwdraaien is dat de uitgangssituaties in beide systemen, zowel AKR als KOERS, gelijk moeten zijn. Daarvoor was synchronisatie expliciet uitgesloten. We hebben ervoor gekozen om in AKR 2-wekelijks - uiteraard in het weekend - een export te produceren van de data. Vervolgens hebben we migratiesoftware ontwikkeld die vanuit deze export (dump) events te destileren die de basis vormden van het startpunt van het nieuwe systeem. Dit gaf dus een 2-wekelijks ritme waarin gegevens op de eerste maandag volledig gelijk waren en steeds verder verouderden. Toch was dit voldoende bruikbaar om steeds meer gebruikers van AKR al te laten proefdraaien, schaduwdraaien dus, met KOERS. Dit was niet alleen een test van het nieuwe systeem, maar ook een opleidingsmechanisme voor onze productiemedewerkers!

Wat extra bijzonder is, is dat we zoveel ervaring en vertrouwen met elkaar hebben opgebouwd, dat we meer risico’s durfden te nemen. Al vier jaar hebben we ervaring opgedaan met Continuous Delivery. Uitrollen naar de productieomgeving is echt niet spannend meer. Het is meer een gegeven. Daarnaast hebben we ervaring opgedaan en vertrouwen ontwikkeld in onze analyse, ontwerp, ontwikkel en test expertise. We weten dat we een bepaalde snelheid aan kunnen om een nieuw rechtsfeit gedegen en concreet op te pakken en te verwerken. In combinatie met Continuous Delivery is dat inclusief uitrol en echte verwerking in de productieomgeving. Bovendien hebben we mogelijkheden voor herstel ontwikkeld en beschikbaar gemaakt én mensen in getraind, dat we ook zonder nieuwe ontwikkelingen al heel veel variëteit aan kunnen. Dit gaf de achtergrond en context om live te gaan zonder 100% van de rechtsfeit typen te hebben ontwikkeld in het systeem! 😳 Er was al eerder een analyse gedaan van de variëteit aan rechtsfeiten en sommige rechtsfeiten uit het verleden komen naar de toekomst toe nooit meer voor, sommige zouden mogelijk nog wel kunnen, maar zijn onwaarschijnlijk en een aardige reeks rechtsfeiten die eens in de 10 jaar voorkomt. Tja … als je een nieuw systeem ontwikkelt, moet je ondersteuning hebben voor alles, toch? Nee dus!! 😎

Live — okt 2018

Toen kwam het moment dichterbij dat we compleet genoeg waren in functionaliteiten, de migratie voldoende was beproefd en uitval was opgelost. In oktober 2018 kwam het bewuste weekend. Op vrijdag werd er vroeg gestopt met de verwerking van notariële akten, uiteraard binnen de wettelijk beschikbare bepalingen. In het weekend werd de normale procedure doorlopen waar we al ruim twee jaar elke twee weken mee hadden gewerkt om de migratie van AKR naar KOERS uit te voeren. Dat verliep zoals verwacht en gepland … met de normale kleine puntjes en controles. Na de export uit AKR konden we, zoals gebruikelijk, het nieuwe systeem voorzien van de nieuwe events, wat dit keer écht de basis van het nieuwe tijdperk zou gaan worden. Spannend! En tegelijk … het meest spannende was dat we het 2-wekelijkse patroon moesten gaan ontwennen en stoppen. Ruim 2 jaar … en dan daarmee stoppen. Dat was nog het meest onwennige 😄

Ook alle koppelingen naar alle omliggende systemen hadden we al meerdere keren in verschillende stadia getest en beproefd. Maar ja, nu was het toch echt het moment dat het echt goed moest gaan en blijven gaan. Dat was wel erg spannend en ging ook niet vanzelf goed. Zondagmiddag waren we voorbij het punt ‘of no return’; we konden alleen maar vooruit. Helaas was maandag een dag vol stress waarin ook, met name het notariaat, de externe wereld last ondervond van onze live gang. Maar toch, maandag einde van de dag konden we inhalen wat we overdag aan vertraging waren opgelopen. En in de rest van de week hebben we nog veel kleine brandjes moeten blussen, maar is uiteindelijk - voor de buitenwereld - het vrij geruisloos verlopen. Eén artikel in Computable en verder: silence. Zo zou het moeten zijn. En wél een ‘open hart transplantatie’ gedaan in het applicatie landschap van het Kadaster, waarin een belangrijke en oude, vertrouwde kern, AKR, met een ‘big bang’ is vervangen. Hoppa! Wat een prestatie!!

Project afronding

Wow, wat een reis. Vier jaar lang gebouwd. Vier jaar lang ontdekken hoe we konden samenwerken, hoe we konden bijsturen, hoe we grip moesten krijgen op het totaal van het werk … Maar we hebben het gefixt. En hoe! Wat een mooi en intens traject hebben we afgelegd. Met veel mensen die betrokken zijn geweest, zowel intern Kadaster als extern d.m.v. inhuur, maar ook audits, adviezen, controles, extra ingevlogen expertise …

En wat een prestatie! Een open hart transplantatie met een big bang introductie in één weekend - OK, plus één maandag, maar dan nog! Een mainframe systeem vervangen dat omringd werd door zo’n 100 koppelingen … én al jaren het kloppende hart was van de rechtszekerheid rondom vastgoed in Nederland. Om dat stabiel en kwalitatief voort te kunnen zetten, moest er een keer een gedegen opvolger komen van AKR. En dat is gelukt: KOERS!

Succes ingrediënten

Dit project was niet mogelijk geweest zonder een agile aanpak. Dat is misschien een wat algemene verwoording en er zijn 100 manieren van ‘agile’. Maar de primaire gerichtheid op mensen - agile manifesto rule #1 - en de samenwerking, wat zijn de verschillende behoeftes en hoe kunnen daar zo goed mogelijk ondersteuning aan leveren, heeft ons echt maximale resultaten opgeleverd 💪

Ook de andere rules van het agile manifesto hebben we onder andere concreet gemaakt door middel van Continuous Delivery. Vanaf dag 1 zijn we hiermee begonnen en we zijn nooit meer gestopt. Op een gegeven moment kostte het 30 minuten voordat een geaccepteerde feature door de hele pipeline van testen en stappen was gelopen en de functionaliteit in productie bruikbaar was. En dat werd op een gegeven moment een bottleneck! Vanuit de verschillende teams en later feature teams werden zoveel kleine wijzigingen opgeleverd, dat er een queue kwam voor wijzigingen naar productie. Ook daar hebben we wat op bedacht om zaken sneller, vloeiender en gemakkelijker naar productie te krijgen. Wat werkte dat top!! 😎

De interne architectuur is met name gebaseerd op CQRS en Event Sourcing en heeft legio mogelijkheden gegeven:

• Business en IT (developers) ontwikkelden dezelfde taal. Business analisten gingen zelfs meehelpen bij het ontwikkelen van functionele testen want er was wederzijds begrip van de functionaliteit, de naamgeving van de dingen, de commands, events en business constraints. Wauw, dit is écht business en IT samen! Als developers artikelen van de wet gaan uitpluizen en vragen stellen aan de analisten die zij niet direct kunnen beantwoorden en, vice versa, business analisten gaan functionele tests schrijven … 💯
• De ontkoppeling van command-kant en query-kant met de events in het midden, als de core API (interface), waren machtig! Dit gaf volgens business ontworpen scheidingen in de technische componenten. Dat gaf volgens business ontworpen scheidingen tussen teams, samenwerkingen en koppelvlakken. Dit gaf enorme robuustheid in traceerbaarheid, herhaalbaarheid, testbaarheid, integratie en evaluatie. Love it! 🚀
• Door het vastleggen van de events als primair resultaat van de verwerking van wijzigingen, is het mogelijk om meerdere, verschillende en ook nog achteraf mét behoud van historie, projecties toe te voegen. Uiteraard was de eerste aandacht in het project het verwerken van rechtsfeiten ten behoeve van het bijwerken van de Kadastrale Registratie. Later in het project kwamen er ook bedrijfsmatige eisen om de hoek kijken, bijvoorbeeld facturatie. Aan de verwerkingskant, de command-kant, hoefde er NIETS te wijzigen! We konden ‘gewoon’ een nieuwe projectie toevoegen die op basis van bestaande events tot een verzameling gegevens kwam die nodig was voor de facturatie!! BAM! 🤘

Leerpunten

Ging alles goed? Nee, natuurlijk niet. En zonder de vuile was helemaal buiten te hangen, zijn er wel een aantal leerpunten te benoemen:

• Agile is moeilijk. Agile is … ook nog onbekend. Echt?!? Ja, helaas wel. Ondanks dat de IT industrie al heel wat jaren met agile aan de slag is, is bijvoorbeeld de audit wereld hier nog helemaal niet aan gewend. Dit was een groot project, dus werd er kritisch meegekeken en waren er audits. Maar ja, welke antwoorden geef je op ‘waterval vragen’ als je een agile project doet? 💥
• CQRS en Event Sourcing zijn nog steeds onbekend. Echt?!? Ja, helaas wel. Ondanks dat het eigenlijk best oude patronen zijn - in de jaren ‘70 en ‘80 werden al vergelijkbare patronen benoemd - zijn asynchroniteit, scheiding van ‘mutatie-kant’ en ‘informatie-kant’ en helemaal de synchronisatie door middel van events nog weinig in de ervaring van velen aanwezig. Niet bij architecten. Niet bij ontwerpers. Niet bij developers. 🥲
• Automatisering, Continuous Delivery, Platform-as-a-Service zijn allemaal goeie dingen van deze tijd. In 2014 was dat er nog niet op het niveau dat het nu is. Daar hebben we dus ook fouten in gemaakt en hebben we ook zelf veel dingen moeten uitzoeken en tegenaan lopen. Maar … vandaag de dag hoeft dat niet meer! De tools en infrastructuur is echt vele malen beter geworden. Gek genoeg zijn de methodieken nog steeds onvoldoende bekend buiten de developers die deze delen opzetten en onderhouden. Vreemd … 🤷‍♂️

En verder?

Wel, in oktober 2018 is KOERS live gegaan … en is niet meer uitgeweest. Na al die jaren doen we nog steeds Continuous Delivery en ontwikkelen we het systeem elke dag een beetje verder door. Niet meer zo hard als tijdens het project. Ook wat betreft teams en mensen zijn we afgeschaald. En we hebben ook de nodige issues gevonden en technologische verbeteringen doorgevoerd. En tegelijk is dat business as usual, elke uitdaging, vraag, behoefte wordt ontworpen, gebouwd en naar productie gebracht. Het onderliggende platform is gewijzigd. De tools van de voortbrenging zijn gewijzigd. Het mechanisme niet. Net zoals event sourcing niet. Upgrades, ja, natuurlijk. Maar vooral: steady business 😊

Mijn rol in het project was die van solution architect voor de interne software architectuur van KOERS. De introductie van CQRS en Event Sourcing komen uit mijn koker. Ook de grondlegging van Continuous Delivery en de eerste pipelines komen van mijn hand. De opzet van componenten, de koppelvlakken daartussen en samenwerking van de teams daar omheen heb ik veel invloed in gehad.

Op basis van mijn ervaringen in het project en met het systeem KOERS, ben ik wel op ideeën gekomen van hoe de toekomst er mogelijk uit zou kunnen zien. Dat heb ik uitgewerkt - samen met collega’s - in bijvoorbeeld protocol denken. Daarnaast ben ik mijn ervaring aan het vastleggen in de “Handreiking Betrouwbaar Register” die wordt opgeleverd in het project Uit betrouwbare bron.