De informatiekundige visie ‘Common Ground’ is bij menig gemeente inmiddels wel bekend. Veel gemeenten en leveranciers zijn al een tijd actief in het ontwikkelen van nieuwe oplossingen en het implementeren van nieuwe standaarden. Bij zowel gemeenten als leveranciers is het duidelijk dat deze beweging niet meer te stoppen is. Langzaam wordt duidelijk wat deze nieuwe opzet van de informatiehuishouding voor een organisatie gaat betekenen. Niet alleen de manier van ontwikkelen is nieuw voor een organisatie, ook de implementatie van de nieuwe componenten en het beheer hiervan gaat veranderen.
In een serie van 3 artikelen bespreekt Telengy-adviseur Paul Jansen de ontwikkelingen van Common Ground. Hij legt uit wat de 5 lagen van Common Ground nu eigenlijk echt inhouden, gaat in op de transitie en verschillende migratievarianten die mogelijk kunnen worden doorgevoerd en ook wordt het effect van Common Ground op de rol van de beheerder besproken. In dit eerste artikel: de 5 lagen van Common Ground.
De 5 lagen van Common Ground
Lange tijd werden informatiesystemen gebouwd waarin de gebruikersinterface, de proceslogica en de gegevens bij elkaar in één applicatie werden opgesloten; de bekende ‘silo‘. Tussen al die systemen werden gegevens uitgewisseld, gekopieerd en in de eigen systemen opgeslagen. Hierdoor is een complex systeem ontstaan van moeilijke koppelingen en meerdere waarheden van gegevens. Common Ground wil dit mechanisme doorbreken door de silo’s uit elkaar te trekken: gebruikersinterface en proceslogica worden gescheiden van de gegevens die maar op één plek bewaard en beschikbaar gesteld worden. Ik herhaal dat nog maar eens: de gegevens worden bij de bron bewaard, bewerkt en geraadpleegd. Er worden geen kopieën van de gegevens meer gemaakt naar andere systemen. Door gegevens bij de bron te laten en daar op te vragen, wordt voorkomen dat fouten optreden door het mogelijk verkeerd kopiëren. Bovendien kan sneller worden ingespeeld op (maatschappelijke) veranderingen omdat gegevens nu ook via andere gebruikersinterfaces en processen ontsloten kunnen worden. Hiermee kan een organisatie sneller en betere dienstverlening leveren aan burgers, bedrijven, instellingen en ketenpartners.
In laag 1 ‘Gegevensopslag’ – we tellen van beneden naar boven – worden de gegevens volgens een gestandaardiseerd informatiemodel opgeslagen. Laag 2 bevat de gestandaardiseerde ‘Services’ (of API’s) die toegang geven tot de Gegevensopslag in laag 1. Via een ‘Integratie’ die zich in laag 3 bevindt, worden de Services ontsloten naar de ‘Proceslogica’ in laag 4. Uiteindelijk maakt de eindgebruiker gebruik van de ‘Gebruikers Interface’ in laag 5.
De eerste Common Ground projecten hadden de focus op de onderste 2 lagen: laag 1 (Gegevensopslag) en laag 2 (Services). Brongegevens worden in aparte registers (‘losse bakjes’) opgeslagen en ontsloten via gestandaardiseerde API’s. Het bekendste voorbeeld hiervan zijn de Zaakgericht Werken API’s en de losse registers. Inmiddels zijn er stabiele versies (1.0.x) van de verschillende API’s beschikbaar die door leveranciers gebruikt en ingebouwd kunnen worden in hun eigen informatiesysteem.
Voor de Integratie (laag 3) wordt hard gewerkt aan NLx. Als organisaties hun API’s aan elkaar beschikbaar gaan stellen, kunnen de gegevens echt bij de bron blijven. Om deze organisaties op een veilige manier aan elkaar te koppelen, is NLx bedacht. Het is een soort servicebus over organisaties heen.
Nu voor de onderste drie lagen allerlei toepassingen worden ontwikkeld verschuift de focus langzaam naar de processen (laag 4) en de gebruikersinteractie (laag 5). Want het zou toch mooi zijn wanneer verschillende gebruikersinterfaces (zoals websites, apps, chatsbots) gebruik kunnen maken van gestandaardiseerde ‘procesblokjes’? Op die manier worden processen op dezelfde manier uitgevoerd, ongeacht met welk kanaal of interface je deze aanroept.
Een puzzel
Eén van de kenmerken van Common Ground is dat diverse componenten in de 5 lagen met elkaar samenwerken tot een werkende oplossing. Deze losse componenten hebben een afgebakende functionaliteit en worden ontsloten via gestandaardiseerde interfaces.
We kunnen dit visualiseren met puzzelstukjes die een vierkant vormen als ze aan elkaar zijn gelegd. Als twee puzzelstukjes met dezelfde functionaliteit met elkaar worden verwisseld, blijven we een vierkant houden. Ook als we een puzzelstukje vervangen door een geheel ander puzzelstukje (wellicht uit een andere puzzel) is de vorm niet veranderd. Maar dit werkt alleen als we een stukje vervangen dat exact dezelfde vorm heeft. Als dat niet het geval is, past het stukje niet op de oude plek of we krijgen een andere vorm. Het is daarmee niet meer een samenhangend geheel.
Dit geldt zo ook voor de losse functionele componenten die samen een toepassing vormen. We kunnen alleen componenten met elkaar verwisselen als ze aan dezelfde functionaliteit voldoen en op dezelfde manier met elkaar verbonden kunnen worden.
Eenvoudig of complex?
Door een applicatie helemaal uit elkaar te trekken in 5 lagen, ontstaan veel componenten die elk een eigen functionaliteit bevatten. Daarmee wordt het mogelijk om met gestandaardiseerde ‘blokjes’ veel verschillende samenstellingen te maken. Daarmee lijkt het geheel juist complexer te worden in plaats van eenvoudiger. Beide is waar. Het wordt eenvoudiger om gewenste functionaliteit te vervangen of een wijziging in het proces aan te brengen. Een gemeente kan zo sneller inspelen op de wensen van hun klanten. Maar door een veelvoud aan verschillende componenten wordt het complexer om hierin overzicht te houden, losse componenten te beheren en te onderhouden. Het is dan ook verstandig dat een gemeente hiervoor een Common Ground strategie opstelt.
Waarmee zou een gemeente kunnen starten en wat zijn de consequenties voor een beheerder die deze losse componenten moet gaan beheren? In het volgende artikel ga ik in op welke mogelijke manieren een gemeente een transitie of migratie zou kunnen inzetten.
Meer weten?
Voor meer informatie kunt u contact opnemen met Paul Jansen, adviseur bij Telengy, via tel. nr. 06 53 63 93 02, p.jansen@telengy.nl.
