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.
Beeld: Capturing Life as it happens / Pixabay
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.
Flexibele basis
Om innovatief te kunnen blijven, moeten we kunnen inspelen op wat de gebruiker morgen wil. Omdat we nog niet kunnen weten wat dat is, moet de basis flexibel zijn. De gestandaardiseerde informatiemodellen en API’s moeten eenvoudig kunnen worden aangevuld zonder dat dat als ‘foute’ data wordt gezien. Daarmee veroordeel je leveranciers niet tot eenheidsworst, maar wordt juist de ruimte geboden om, mét alle voordelen van Common Ground, wendbaar te blijven.
Laat binnen Common Ground daarom toe dat de databron de ‘standaard plus meer’ kan verwerken en de API dus ook ‘de standaard plus meer’ kan doorgeven. Zo kan een innovatieve leverancier extra functionaliteit leveren zonder de architectuur aan te tasten. En houden we ook de data bij elkaar. Doe je dat niet, dan zet iedere leverancier er vrolijk een ‘Custom API’ naast om tegemoet te komen aan de wensen en eisen van zijn klanten. Als de databron (en meest relevant de API) de mogelijkheid heeft om meer functionaliteit door te geven dan de standaard dicteert, creëer je die brede basis die je nodig hebt voor een piramide.
Ook de leveranciersonafhankelijkheid heeft er geen last van. Als je de componenten in de datalaag wilt vervangen, kan dat omdat ook de nieuwe leverancier de (voor hem) onbegrijpelijke extensies gewoon verwerkt. Aan de voorkant geldt dat net zo goed: de applicaties van de nieuwe leveranciers zullen niets doen met de extensies van de oude leverancier. Dat is niet erg omdat die extensies kennelijk onvoldoende motivatie opleverden om bij de oude leverancier te blijven.
Aggregatie
Sta daarnaast ook toe dat de applicatielaag met één vraag meerdere databronnen van hetzelfde type kan uitlezen. Dat er bijvoorbeeld meerdere zaak-registratiecomponenten kunnen bestaan die door de applicatielaag als één zaaksysteem worden gezien (aggregatie). Dat maakt migratietrajecten eenvoudiger omdat de applicatielaag dan kan ontwikkelen zonder beperkingen in de toeleverende databronnen.
Tenslotte moet het mogelijk zijn om een extensie te verheffen tot standaard. Als de markt (klanten en leveranciers) de waarde van een extensie inzien, zou de extensie opgenomen moeten worden in de standaard waardoor het aantal afwijkingen afneemt. Als een extensie twee jaar kost om door de projectgroep te komen, ontstaan er meerdere varianten van de extensies. Ik bepleit daarom een doorlooptijd van maximaal één kwartaal.
De Common Ground en de onderliggende architectuur-principes zijn een grote stap voorwaarts en maken het ICT-landschap van lokale overheden flexibeler. Dat is een stap die iedere leverancier moet ondersteunen. Maar het kan beter. Als we bovenstaande voorstellen zouden kunnen realiseren, dan zijn we méér dan common en werken we toch vanuit dezelfde ground…
Frans Dondorp is werkzaam bij Decos en schreef dit artikel op persoonlijke titel
Fraaie oproep. Er zit echter een logische valkuil in. Als je én flexibiliteit in de API /URI structuur wil toestaan én je wil kunnen aggregeren, wordt je aggregator per definitie een maatwerkoplossing. Immers, ik moet dan als bouwer de afwijkingen van de collega’s oplossen.
Maar wat denk ik een grotere vraag is, waarom innovatie afhankelijk zal moeten zijn van aanvullende data. Als CG goed in de steigers staat, zullen alle gemeentelijke databronnen vanzelf CG gebaseerd zijn, en hebben we slechts rekening te houden met privacykaders en aanverwanten om het nu nog onmogelijke te gaan combineren. ik betwijfel dus heel erg of er wel gegevens zijn die we nog niet vastleggen…. wellicht sensor/iot, maar daar komt de AVG strak om de hoek als je dat wil gaan combineren met andere gegevens. Dat gezegd hebbende, ook sensor/iot is weer te standaardiseren met API/URI.