De VNG maakt serieus werk van Common Ground. De implementatie van dit architectuurprincipe, dat de datalaag standaardiseert en scheidt van de applicatielaag, zou een grote stap voorwaarts betekenen in de flexibilisering van het IT-landschap van lokale overheden. Maar al te rigide standaardisatie kan innovatie beperken.

Het is een bekend probleem: lokale overheden raken steeds meer verstrikt in het digitale web dat ze, overigens met de beste intenties, samen met hun leveranciers hebben gesponnen. In het IT-landschap zijn silo’s verrezen waarin elke applicatie bouwt op een eigen database en alle data zelf beheren. Talloze koppelingen transporteren data uit de ene silo naar de andere, wat leidt tot een omslachtige, onderhoudsintensieve en fout- en privacygevoelige werkwijze.

In de architectuur van de Common Ground worden data (waaronder het informatiemodel en de opslag) losgetrokken van de applicatie die de data gebruiken. Tussen de applicatie en de data zit een API (Application Programming Interface, zeg maar een verbindingsstuk) waarmee de data worden ontsloten naar de app. Alle applicaties halen hun data bij dezelfde bron, waardoor gegevens slechts eenmaal hoeven te worden opgeslagen. Kortom: haal centraal.

Toch is er ook een reëel risico. Te strenge standaardisatie beperkt de flexibiliteit en daarmee de mogelijkheden tot innovatie. Het is belangrijk om te onderkennen dat elk knopje aan de voorkant (in de applicatie) verbonden is met data aan de achterkant. Iedere (nieuwe) functionaliteit moet worden ondersteund door de API en de databron eronder. Het is een piramide: de onderlaag moet minimaal net zo breed zijn als de bovenlaag. Anders valt ‘ie om.

Rem op innovatie

Innovatie moet mogelijk blijven. Leveranciers moeten zich van elkaar kunnen onderscheiden. Hun applicaties kunnen slechts werken met wat het ‘stekkerblok’ levert. Als dat alleen de standaard is, is aan de voorkant ook alleen de standaardfunctionaliteit mogelijk en leveren alle leveranciers precies dezelfde systemen. Geen concurrentie, geen innovatie.

Als we in de API alleen standaardiseren waar we het over eens zijn (‘de minimale standaard’), zullen leveranciers extensies gaan bouwen buiten de standaard om. Dat is hen niet kwalijk te nemen: ze moeten zich zien te onderscheiden van de rest. Als de standaard die extensies niet toestaat, moeten ze alsnog eigen datastructuren bouwen buiten de Common Ground om. Met als gevolg weer verspreide data, waaraan Common Ground juist een einde had moeten maken.

Deze versturen we 3-4x per jaar.