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 derde artikel: de transitie en migratie van applicaties.

De 5 lagen

Weet u het nog? In mijn artikel van 29 januari beschreef ik de 5 lagen van Common Ground. Daarin heb ik per laag uitgelegd wat ermee bedoeld wordt. Een aantal gemeenten timmert hard aan de weg met het bouwen van nieuwe componenten op deze lagen. Ook leveranciers zijn druk bezig met het implementeren van nieuwe standaarden en oplossingen. En dan hoor ik u hardop afvragen: “Maar hoe passen die nieuwe ontwikkelingen dan in mijn bestaande applicatielandschap? Hoe sluit ik mijn software aan op de nieuwe standaard? Wat moet ik aan mijn leverancier vragen als ik met Common Ground aan de slag wil?” In dit artikel noem ik enkele stappen die u zou kunnen nemen.

Pace Layered Model

Niet elke applicatie verandert op dezelfde manier en op dezelfde snelheid. Gartner plaatst informatiesystemen De eerste categorie applicaties (Systems of Record) hebben een lage verandersnelheid. Dit zijn bijvoorbeeld informatiesystemen die de uitvoering van wettelijke taken ondersteunen waarbij het proces grotendeels hetzelfde blijft. De tweede categorie applicaties (Systems of Differentiation) zijn specifiek voor een organisatie en kennen een middellange levenscyclus. Deze applicaties worden opnieuw bijvoorbeeld met een nieuw proces ingericht om te voldoen aan de veranderende behoefte van de organisatie. De laatste categorie applicaties (Systems of Innovation) spelen in op de onmiddellijke behoefte van een organisatie en hebben vanwege hun vluchtigheid een beperkte levensduur.

Ambitie

Als u een applicatie gaat aanpassen of vervangen en dat in lijn wilt brengen met de informatiekundige visie van Common Ground, is het zeker de moeite waard om te kijken in welke categorie uw applicatie valt. Een applicatie in de categorie Systems of Record zal waarschijnlijk minder eenvoudig aangepast kunnen worden naar de 5-lagen indeling. Een nieuwe app voor burgers die een specifieke informatiebehoefte invult en geen gegevens uit andere systemen nodig heeft zal wel ontwikkeld kunnen worden op basis van verschillende componenten op de 5 lagen. Het is belangrijk dat u daarin (samen met uw leverancier) bepaalt wat uw ambitie hierin is en hoeveel tijd en geld u hiervoor beschikbaar heeft.

Adoptiecurve

In het gesprek met uw leverancier moet u bepalen welke wijzigingen u wilt doorvoeren. Springt u van de kelder gelijk op het dak of gaat u met de trap via elke etage naar boven? Om u hierbij te helpen heeft VNG Realisatie een document[1] gepubliceerd waarin het Globaal Programma van Eisen wordt besproken. In het document staat een adoptiecurve met 6 niveaus vermeld die een groeipad aangeven naar een applicatielandschap volledig gebaseerd op de 5 Common Ground lagen. Ik licht deze niveaus hieronder kort toe.

Ik ga uit van een beginsituatie waarin er sprake is van een silo en er geen scheiding is in 5 lagen. Dit is niveau 0. Een minimale eerste stap is het kunnen opvragen van de gegevens in de silo via een API. Dit is niveau 1. De leverancier moet daarvoor de applicatie wel aanpassen. Op die manier kunnen andere applicaties de gegevens al raadplegen, blijven gegevens bij de bron en hoeven deze niet meer te worden gekopieerd naar andere applicaties. Idealiter is dit gerealiseerd via een gestandaardiseerde API. Mocht er (nog) geen standaard beschikbaar zijn, laat dan de leverancier minimaal de specificaties van de API publiceren.

Als de gegevens niet alleen bij de bron kunnen worden opgevraagd, maar ook kunnen worden gemuteerd via een (gestandaardiseerde) API, dan praten we over niveau 2. Het kunnen muteren van gegevens is een grotere aanpassing omdat allerlei interne checks (t.b.v. consistentie op data) uitgevoerd worden voordat een wijziging (in de database) wordt doorgevoerd. Vanaf dit niveau wordt het al mogelijk om interactie op de opgesloten gegevens te kunnen uitvoeren via andere applicaties.

Een uitgangspunt in het GEMMA Gegevenslandschap[2] is dat een leverancier zelf ook gebruik maakt van zijn aangeboden API’s. Oók als het gaat om de gegevens in zijn eigen applicatie. Als een applicatie de gegevens alleen nog via API’s gaat bevragen, is niveau 3 bereikt.

Vanaf niveau 4 wordt uitgegaan dat er een gestandaardiseerd informatiemodel is waarop de API’s worden ontwikkeld en gebruikt. Dit informatiemodel is zeker ook gewenst bij niveau 1, 2 en 3. De focus bij de eerste 3 niveaus ligt echter op het kunnen ontsluiten van de gegevens en er geen data lock-in meer bestaat, terwijl niveau 4 echt uitgaat van een gestandaardiseerd informatiemodel en gestandaardiseerde API’s die landelijk afgestemd en gebruikt worden.

De volgende stap is het doorvoeren van de scheiding van de processen (laag 4) en de (gebruikers)interface of interactie (laag 5). Processen die eerst in de silo zijn opgeslagen kunnen nu ook via andere gebruikersinterfaces worden toegepast. Een aanpassing aan het proces wordt zo integraal doorgevoerd in alle interactie. Met deze laatste actie is de ‘oude’ silo opgeknipt in 5 lagen gebaseerd op de informatiekundige visie Common Ground.

Een volgende stap is het combineren van de verschillende componenten die op de 5 lagen beschikbaar zijn gesteld. Daarmee kunt u een ‘eigen’ toepassing samenstellen aan de hand van uw behoefte en vraag naar dienstverlening. Dit kan worden gezien als niveau 6.

Meer weten?

De niveaus uit de adoptiecurve geven een groeipad aan waarlangs een applicatie kan evolueren naar een gelaagde toepassing. Afhankelijk van uw gestelde ambitie, beschikbare tijd en geld kunt u een keuze maken naar welk niveau u uw applicatie wilt aanpassen of (laat) ontwikkelen.

Wilt u weten welke mogelijkheden er voor u zijn en hoe u een dergelijk traject zou kunnen aanvliegen, neem dan contact op met Paul Jansen, adviseur bij Telengy, via tel. nr. 06 53 63 93 02, p.jansen@telengy.nl.

[1] https://www.gemmaonline.nl/images/gemmaonline/1/1b/GEMMA_Gegevenslandschap_-_Globaal_Programma_van_Eisen_v1.0.pdf

[2] https://www.gemmaonline.nl/images/gemmaonline/5/56/GEMMA_Gegevenslandschap_-_Beschrijving_informatiearchitectuur.pdf