Er wordt veel gesproken en gediscussieerd over de Common Ground (CG). Decos maakt sinds het begin actief onderdeel uit van de CG bijeenkomsten. In discussies merken we dat er op verschillende manieren naar de CG ontwikkeling wordt gekeken. Is CG een gaspedaal of een rem voor de innovatie binnen de overheid? Wij leggen u graag uit wat onze visie is. In dit artikel is Business Developer Frans Dondorp aan het woord. Dondorp praat mee met de Vereniging Nederlandse Gemeenten(VNG) die allerlei richtlijnen uitdenkt over privacy.
Eén van de centrale uitgangspunten in de Common Ground is dat de applicatielaag gescheiden wordt van de datalaag. Door de data te scheiden kunnen gegevens worden gedeeld tussen verschillende applicaties zonder dat deze meerdere keren moeten worden opgeslagen. Alle applicaties halen data bij dezelfde bron. Een sterk concept dat veel nieuwe mogelijkheden kan brengen en een ontwikkeling die ook voor leveranciers aantrekkelijk is. Het risico van standaardisatie van de datalaag is echter dat innovatie moeilijker wordt en leveranciers eigen extensies gaan bouwen. Bij deze de oproep voor een ‘flexibele standaard’ – hoe vreemd dat ook klinkt.
De Common Ground als architectuur
Het architectuurprincipe van de Common Ground is dat de data (waaronder ook de datastructuur, het informatiemodel en de feitelijke opslag) wordt losgetrokken van de applicatie die die data gebruikt. Tussen de applicatie en de data zit een “API” (een Application Programming Interface, een stekkerblok) waarmee de data wordt ontsloten naar de applicatie. Door deze API te standaardiseren kunnen verschillende databronnen op dezelfde wijze worden gebruikt door afnemende applicaties. Als die applicaties de standaard stekker gebruiken, passen ze in de gestandaardiseerde stekkerblokken.
Het is heel goed mogelijk dat een applicatie meerdere databronnen gebruikt en dus meerdere API’s aanspreekt om de gegevens die de applicatie nodig heeft bij elkaar te zoeken. Het is ook mogelijk dat meerdere databronnen feitelijk door één oplossing worden geïmplementeerd. Die oplossing kan dan via meerdere standaard API’s worden aangesproken. Voor de applicatie maakt het niet uit wie er ‘achter’ de API zit – dat is het concept van een API. Om in de metafoor te blijven: het apparaat heeft te maken met het stekkerblok en het maakt niet uit waar die de spanning vandaan haalt.
''Voor Decos als leverancier van een Zaaksysteem met DMS/RMA zou het logisch zijn om de zaaktypen, de zaken, de documenten en besluiten te leveren. In termen van Common Ground: de registratiecomponenten voor zaaktypen (ZTC), zaken (ZRC), documenten (DRC) en besluiten (BRC). Mogelijk als een oplossing.''
Kunnen er meerdere databronnen zijn?
De vraag ontstaat dan in hoeverre er meerdere databronnen kunnen zijn voor vergelijkbare data. In de GEMMA architectuur is het al jarenlang de bedoeling om één zaaksysteem te hanteren, terwijl het in de praktijk voorkomt dat zaken in verschillende applicaties worden geadministreerd. In de architectuur van de Common Ground zou het denkbaar zijn dat je meerdere ZRC’s hebt die allemaal via de Zaken-API worden ontsloten aan de applicatie. Of meerdere DRC’s. Dat zou heel interessant zijn voor de overgangssituatie van de bestaande architectuur naar de Common Ground.
Stel je voor: het bestaande zaaksysteem implementeert vier ZGW-API’s (de Zaaktypen-API, de Zaken-API, de Documenten-API en de Besluiten-API). Het nieuwe zaaksysteem doet dat ook. Als de zaakbehandel-applicatie beide systemen zou bevragen, en het dus mogelijk is om 2 of een willekeurig aantal te benaderen, moet oud naast nieuw kunnen bestaan zonder dat dat zichtbaar is voor de eindgebruiker.
Zonder conversie. Sluit gewoon allebei de zaaksystemen aan, bevraag allebei en combineer de resultaten.
Zo zou het ook mogelijk zijn om op de applicatielaag een generieke, leveranciers-onafhankelijke convertor te bouwen die API-1 uitleest en dat terugstopt in API-2. Conversie as a Service. Die zou iedere leverancier, of u zelf, of VNG-R kunnen maken. Leveranciersonafhankelijkheid.
De standaard versus extensies
Is het nog te volgen? Zo ja: houd die gedachte vast. In hoeverre kan zo’n ‘generieke conversie’ zonder data en functionaliteit kwijt te raken? Dat kan alleen als iedere leverancier alle data die hij heeft (en daarmee alle functionaliteit die hij aanbiedt) kwijt kan in de datalaag. En dat is niet het geval.
Het is belangrijk om te onderkennen dat ieder knopje aan de voorkant leidt tot data aan de achterkant. Iedere functionaliteit die de applicatie biedt moet dus ondersteund worden door de API en de databron daaronder. Het is een piramide: de onderlaag moet minimaal net zo breed zijn als de bovenlaag. Anders valt ‘ie om.
Het is ook belangrijk om te onderkennen dat innovatie mogelijk moet blijven. Leveranciers moeten zich van elkaar kunnen onderscheiden. In de metafoor: het apparaat kan alleen 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.
Een innovatief bedrijf bouwt niet wat de gebruiker nu wil, maar wat de gebruiker morgen wil. Omdat we dat nog niet kunnen weten, moet de basis flexibel zijn.
Deze inzichten stellen eisen aan de standaardisatie. 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 wel om zich te onderscheiden en ze moeten wel om te laten zien dat hun productvisie verder gaat dan wat de klant nu wil. Als de standaard die extensies niet toestaat, zullen er varianten van de standaard ontstaan en dat is het begin van het eind.
Voor de ICT industrie is dit een volstrekt normaal proces. Waarom? Omdat de ICT industrie leeft van innovatie. Iedere standaard kent dit probleem. Hoeveel extensies zijn er niet op bijvoorbeeld HTML en hoe lang heeft het wel niet geduurd voordat een pagina er hetzelfde uitzag in iedere browser? Een standaard is gevangen in een tijdsbeeld. In dit geval het beste dat wij in 2019 konden verzinnen, zonder kennis van 2020.
Een flexibele standaard
De truc is om de standaard flexibel te laten zijn. Laat toe dat de databron de “standaard plus meer” implementeert en de API dus ook “de standaard plus meer” kan doorgeven. Op die manier kan een innovatieve leverancier extra functionaliteit aanbieden zonder de architectuur aan te tasten.
Doe je dat niet, dan zet iedere leverancier er vrolijk een “Custom API” naast om tegemoet te komen aan de wensen en/of 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. De applicatie bevraagt de API en negeert alles dat hij niet begrijpt. Hij bevraagt de Zaken-API en krijgt alles dat de ZGW-API voorschrijft plus alles dat de leverancier van de databron zinvol vindt. Doe ermee wat je wilt en negeer wat je niet begrijpt. Heb je de front-end van dezelfde leverancier of die van een leverancier die de extensie erkent, dan heb je er baat bij. Anders niet en merk je ook niet dat die extensie in de datalaag wordt aangeboden.
Andersom ook: als de leverancier van de applicatie extra data aan de API geeft, slaat de datalaag die gewoon op als ‘extra eigenschappen’, ook al snapt de datalaag niet waar dat over gaat. Dat is niet alleen relevant voor innovatieve leveranciers die de ‘common’ willen ontstijgen: het is ook nodig voor situaties de eigenschap weldegelijk in de standaard zit, maar de datalaag nog een versie achterloopt op de applicatielaag. Die situatie gaat gegarandeerd plaatsvinden.
Dus “de standaard plus meer” in de databron en de API die zich gedraagt als een rietje. Dat geeft flexibiliteit voor applicaties (juist ook die leuke kleine apps) om meer te zijn dan ‘common’. Terwijl de architectuur er geen last van heeft.
Ook de leveranciersonafhankelijkheid heeft er geen last van. Als je de componenten in de datalaag wilt vervangen, kan dat gewoon omdat ook de nieuwe leverancier de (voor hem) onbegrijpelijke extensies gewoon verwerkt. Aan de voorkant kan het ook: de applicaties van de nieuwe leveranciers zullen niets doen met de extensies van de oude leverancier – maar dat is niet erg omdat die extensies kennelijk onvoldoende motivatie opleverden om bij de oude leverancier te blijven.
Oké, hoe nu verder?
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. Voor leveranciers biedt de Common Ground vele mogelijkheden om functionaliteit te verrijken met data die nu in andere applicaties zit.
De standaard moet echter niet innovatie beperken. Daarom bevelen wij drie strategieën aan:
-
Aggregatie
Sta 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. Voor de kenners: aggregatie.
Dat maakt migratietrajecten eenvoudiger, omdat de applicatielaag dan kan ontwikkelen zonder beperkingen in de toeleverende databronnen. Het maakt ook mogelijk dat er meerdere (processpecifieke) zaaksystemen of documentsystemen zijn, zonder dat de applicatielaag dat ‘ziet’. -
Flexibele extensies op de standaard
Sta een flexibel systeem toe in de API’s en de datamodellen om “de standaard plus meer” te kunnen leveren. Dat maakt het mogelijk voor leveranciers om de Common Ground (en in casu de ZGW API’s) volledig te omarmen zonder beperkt te worden in mogelijkheden. Met name: om de Common Ground te omarmen zonder in te leveren op huidig beschikbare functionaliteit.
-
Standaardisatie van extensies
Het moet mogelijk zijn om een extensie te verheffen tot standaard. Het moet dus mogelijk zijn om, als de markt (klanten en leveranciers) de waarde van een extensie inzien, de extensie op te nemen in de standaard waardoor het aantal afwijkingen afneemt. Dat beheerproces moet bestaan en dat beheerproces moet snel zijn. Als een extensie twee jaar kost om door de projectgroep te komen, ontstaan er meerdere varianten van de extensies. Het advies hier is dus om binnen het standaardisatie-comité de snelheid te hanteren die leveranciers hanteren. Doorlooptijd van een kwartaal is het maximum.
Tot slot
De visie achter Common Ground is een moderne micro-service architectuur. Voor ons als leverancier is dat iets dat wij herkennen en volledig omarmen. Voor ons en onze klanten gaat de Common Ground veel brengen, mits de standaard niet beperkend gaat zijn. Als de standaard leveranciers gaat dwingen tot eenheidsworst zijn wij, en u als klant, immers allemaal veroordeeld tot eenheidsworst.
Leveranciers hebben samen met hun klanten in de afgelopen jaren aangetoond dat zij dan olifantenpaadjes gaan bewandelen rond de erkende standaard. De uitdaging voor de Common Ground is om te standaardiseren met het oog op innovatie. Een standaard die ruimte laat en zich niet beperkt tot de consensus anno 2019. Een standaard die zich niet richt op het minimum, maar op het maximum. Door leveranciers te laten innoveren. Laat het een gaspedaal zijn en geen rem.
