Auteursarchief: Paul Jansen

ProductDienstStatus: inzicht in status van aanvragen

Lees het gehele artikel

Burgers en bedrijven die producten of diensten afnemen van gemeenten, kunnen vaak het verloop van de afhandeling daarvan niet volgen. Gemeenten bieden namelijk niet altijd een Persoonlijke Internet Pagina of een MijnGemeente portaal aan. En als die wél aan burgers en bedrijven wordt aangeboden, is de informatie veelal summier en niet altijd toereikend. VNG heeft samen met een aantal gemeenten ProductDienstStatus gelanceerd: de publieke variant van de commerciële Track&Trace. Real-time en kanaalonafhankelijk statusinformatie opvragen over zaken die een burger of bedrijf bij een gemeente heeft lopen.

Vanuit het programma Omnichannel is een referentiearchitectuur opgesteld waarin ProductDienstStatus (PDS) is uitgewerkt. De basis hiervoor betreffen de API-standaarden voor Zaakgericht Werken die het bestuur van de VNG al per 1 april 2021 volgens het principe ‘pas-toe-of-leg-uit’ als standaard heeft verklaard. De referentiearchitectuur is uitgewerkt volgens de 5-lagen van de informatiekundige visie Common Ground en past zo prima in de ontwikkelingen die momenteel binnen de overheid plaatsvinden. Uitgangspunt hierbij is dat zowel burgers en bedrijven als de medewerker van de gemeente over dezelfde informatie beschikken. Gegevens kunnen via verschillende kanalen bij de bron worden opgevraagd. Een burger gebruikt hiervoor bijvoorbeeld een webpagina of een app terwijl een medewerker van de gemeente een procesapplicatie tot zijn of haar beschikking heeft.

Van StUF naar API

Maar gemeenten kunnen toch al statusinformatie over zaken opvragen en beschikbaar stellen? Er is toch al een standaard die hierin voorziet? Dat klopt, maar de StUF-standaard wordt niet meer doorontwikkeld en staat innovatie en snelle aanpassingen aan nieuwe (klant)behoeften in de weg. De API-standaard voor Zaakgericht Werken is eenvoudiger te implementeren en de techniek (gebruik van API’s) wordt over de gehele wereld toegepast.

Hackathon

In de week na Pasen heeft een aantal gemeenten tijdens een 4-daagse hackathon PDS beproefd. Gemeenten hebben samen met hun leveranciers oplossingen bedacht en ontwikkeld om aan te tonen dat het verstrekken van statusinformatie over zaken op een nieuwe en innovatieve manier mogelijk is. Bovendien is aangetoond dat de implementatie van de oplossing relatief snel te realiseren is.

MijnOmgeving Den Haag

De gemeente Den Haag had de focus gelegd op het tonen van statusinformatie in een MijnOmgeving. Via de interface (gebaseerd op NL Design System) van de MijnOmgeving kunnen burgers en bedrijven nu het verloop van hun aanvraag volgen en krijgen ze inzicht in de processtappen die de gemeente nog moet uitvoeren. Met de introductie van substatussen krijgt een burger of bedrijf rijkere informatie aangereikt waardoor (naar verwachting) onnodige telefoontjes naar het KCC worden voorkomen.

Open Webconcept Buren

Dat nieuwe ontwikkelingen gebaseerd op Common Ground makkelijk door andere gemeenten overgenomen kunnen worden, heeft gemeente Buren aangetoond. Door de code van de gemeente Den Haag te (her)gebruiken en aan te passen naar hun eigen ‘couleur locale’ heeft de gemeente Buren in een paar dagen tijd een eigen MijnOmgeving ingericht. Dit is de basis voor verdere uitbreiding van hun digitale dienstverlening en een mooie toevoeging op het Open Webconcept.

Hybride StUF en API OWO-samenwerking

De OWO-samenwerking (gemeenten Ooststellingwerf, Weststellingwerf en Opsterland) wilde aantonen dat hun huidige, StUF-gebaseerd zaaksysteem aangepast kon worden naar de nieuwe API-standaard voor Zaakgericht Werken. Beide standaarden blijven in gebruik (het Common Ground principe Nieuw naast Oud) zodat gefaseerd en in eigen tempo de nieuwe standaard in gebruik genomen kan worden. Bestaande procesapplicaties die nog StUF gebruiken, blijven op die manier functioneren en procesapplicaties die al API-gebaseerd werken, kunnen dan ook de statussen van zaken opvragen.

Medewerkersportaal Tilburg

Gemeente Tilburg heeft een proef gedaan vanuit het perspectief van de medewerker. Vanuit een medewerkersportaal (CRM-systeem) wilde de gemeente Tilburg meerdere zaaksystemen bevragen. Dit zijn niet alleen StUF-gebaseerde zaaksystemen, maar ook API-gebaseerde zaaksystemen. Er is een mechanisme bedacht die het mogelijk maakt om via één API-bevraging meerdere zaaksystemen met verschillende koppelvlakstandaarden te benaderen.

Toekomstig gebruik

Tijdens de demo’s op de laatste dag van de hackathon is gebleken dat er in een relatief korte tijd mooie resultaten door de gemeenten en hun leveranciers zijn behaald. De komende maanden werken de gemeenten samen met hun leveranciers de ideeën en oplossingen verder uit en worden testomgevingen ingericht. In een gecontroleerde pilotomgeving wordt ervaring opgedaan en getoetst of deze nieuwe functionaliteit aansluit bij de behoefte van de burger, bedrijf of medewerker. De verwachting is dat volgend jaar de gemeenten PDS in productie gaan nemen. Het idee is om vanaf 2023 bij veel meer gemeenten de PDS-functionaliteit te implementeren.

Als u als gemeente nu al aan de slag wilt met PDS, hoeft u niet tot volgend jaar te wachten. Veel componenten zijn (in de basis) al beschikbaar. Een aantal leveranciers biedt al zaaksystemen aan die voldoen aan de API-standaard voor Zaakgericht Werken. Ook leveranciers die Persoonlijke Internet Pagina’s of MijnGemeente componenten aanbieden, werken soms al met de nieuwe standaard. En tot slot zijn er genoeg leveranciers die integratiesoftware leveren om alle componenten met elkaar te verbinden.

Meer weten?

Wilt u meer informatie over wat ProductDienstStatus inhoudt en wat het voor uw organisatie kan betekenen, neem dan contact met me op. Ik vertel u er graag meer over: Paul Jansen, adviseur bij Telengy, 06 53 63 93 02, p.jansen@telengy.nl.

Common Ground: instappen of toch nog even wachten?

Lees het gehele artikel

Bij de start van Common Ground werd al gezegd dat de transformatie en transitie van ‘oud’ naar ‘nieuw’ een langere tijd in beslag zou nemen. Minstens 10 jaar. Inmiddels zijn we (bijna) 5 jaar verder en is er veel gebeurd. Gemeenten hebben de handschoen opgepakt en zijn samen met leveranciers software gaan ontwikkelen. Nieuwe leveranciers zagen kansen en zijn vanuit eigen ideeën nieuwe oplossingen gaan ontwikkelen. En vanuit de (landelijke) overheid komen meer standaarden beschikbaar. Dan rijst de vraag: stap ik nu in de trein of kan ik nog rustig op het perron blijven wachten op de volgende trein?

In mijn vorige artikel over Common Ground ben ik ingegaan op het tempoverschil van aanpassingen aan informatiesystemen. Men zou verwachten dat nieuwe, innovatieve software de 5 lagen van Common Ground volledig heeft geïmplementeerd. En dat logge, traditionele systemen nog een eerste stap moeten zetten. Dat lijkt inderdaad zo, maar schijn bedriegt. Ook traditionele software wordt inmiddels aangepast. In dit artikel beschrijf ik een aantal interessante landelijke ontwikkelingen.

ZGW-componenten

Eén van de eerste Common Ground-ontwikkelingen waren de nieuwe componenten voor Zaakgericht Werken. De verouderde StUF-standaard is verlaten en een nieuwe standaard is ontwikkeld conform de landelijke API-strategie. De specificaties van deze standaard zijn al geruime tijd gepubliceerd. Een groeiend aantal leveranciers adopteert de nieuwe standaard inmiddels. En niet alleen leveranciers maar ook gemeenten zijn er al actief mee. Zo bouwt de gemeente Den Haag samen met een aantal andere gemeenten een MijnOmgeving dat gebruik maakt van de ZGW-componenten en nog een aantal Open Source Softwarecomponenten. En de gemeente Súdwest-Fryslân heeft zelf een voorziening gebouwd om nog ‘oude’ systemen te kunnen koppelen aan de nieuwe ZGW-componenten: de Open Zaakbrug.

Haal Centraal

Systemen met basisregistraties zijn precies die traditionele systemen die een langzaam verandertempo kennen. Het is daarom goed om te zien dat er veel nieuwe standaarden ontwikkeld worden rondom de basisregistraties. Verschillende softwarecomponenten kunnen op die manier gegevens bij de bron ophalen waardoor het kopiëren van de basisgegevens voorkomen wordt. Vanuit het programma Haal Centraal worden er API’s ontwikkeld voor de ontsluiting van gegevens uit de BRP, BAG, BRK, BGT, WOZ en het Handelsregister. Een aantal grote gemeenten (waaronder Amsterdam en Den Haag) experimenteren intern al met het gebruik van de nieuwe BRP Bevragen API. En de Rijksdienst voor Identiteitsgegevens (RvIG) voert een pilot uit met deze nieuwe manier van persoonsgegevens ontsluiten.

Verwerkingenlogging

Het verwerken van persoonsgegevens moet natuurlijk aan de AVG voldoen. Een gemeente moet kunnen verantwoorden dat persoonsgegevens op een juiste, rechtmatige en transparante wijze zijn verwerkt. Om te voorkomen dat de vastlegging van verwerkingen van persoonsgegevens bij overheidsorganisaties op verschillende wijze wordt uitgevoerd, ontwikkelt VNG Realisatie een nieuwe standaard: de Verwerkingenlogging API-standaard. Leveranciers als Centric en PinkRoccade Local Government hebben al interesse getoond in deze nieuwe standaard. De verwachting is dan ook dat ze de nieuwe standaard in hun systemen gaan implementeren zodra de definitieve, stabiele versie wordt gepubliceerd.

Ontwikkelagenda API-standaarden

“Leuk!” hoor ik u denken. “Maar welke standaarden worden er nu ontwikkeld en vanaf wanneer kan ik die van leveranciers eisen?” De nieuwe standaarden die door VNG Realisatie ontwikkeld worden, volgen een standaardisatieproces. Ook standaarden of API’s die door gemeenten zijn ontwikkeld en zijn aangedragen aan VNG Realisatie volgen deze stappen. Een compleet overzicht van standaarden (die bij VNG Realisatie bekend zijn) is gepubliceerd op GEMMA Online onder het menu Standaarden. Naast een korte omschrijving van de API is ook de status te lezen. Als je meer informatie over een specifieke API wilt, kun je deze inwinnen via de bij de API vermelde contactpersoon.

Demodam

Zoals u kunt lezen is er al veel beschikbaar en wordt er nog veel ontwikkeld. Maar werken de nieuwe softwarecomponenten en de nieuwe API’s wel allemaal met elkaar samen? Doet het wat het moet doen? Die vraag heeft een aantal leveranciers zichzelf ook gesteld. Via de website van de fictieve gemeente Demodam wordt aangetoond dat de dienstverlening daadwerkelijk kan plaatsvinden op basis van verschillende, losse componenten die ontwikkeld zijn vanuit de informatiekundige visie Common Ground. Het is zeker de moeite waard om eens een bezoek te brengen aan de website van deze gemeente en te ontdekken wat er nu al mogelijk is.

Instappen of wachten?

Bovenstaande voorbeelden geven aan dat er de afgelopen jaren veel is ontwikkeld en dat leveranciers de informatiekundige visie Common Ground inmiddels omarmen. Een groot aantal standaarden en bijhorende API’s is al beschikbaar en klaar om geïmplementeerd en toegepast te worden. Enkele gemeenten gebruikt ze al in productie of staat aan de vooravond van implementeren. Common Ground staat niet meer in de kinderschoenen maar is langzaam volwassen aan het worden. En hoewel voor sommige gemeenten de trein wellicht op het punt staat te vertrekken, een volgende trein arriveert zo. Stap in, reis mee en ontdek een nieuwe wereld!

Meer weten?

Wil je weten welke mogelijkheden er zijn en hoe je deze nieuwe ontwikkelingen kunt uitvragen bij leveranciers, neem dan contact op met Paul Jansen, adviseur bij Telengy, via tel. nr. 06 53 63 93 02, p.jansen@telengy.nl.

In 2021 op weg naar de Omgevingswet

Lees het gehele artikel

Het jaar 2021 staat in het teken van aansluiten op het DSO-LV, implementeren en testen. Met onderstaande ontwikkelingen kunt u rekening houden.

Gezamenlijke route 2022

Komend jaar staat er veel op de rol voor de inwerkingtreding van de Omgevingswet. Een goede planning voor implementatie helpt daarbij. Alle organisaties die bij de invoering van de Omgevingswet betrokken zijn, hebben samen een roadmap opgesteld: Route 2022.

Twee concrete ontwikkelingen beschrijft Paul Jansen in het kort:

Samenwerkingsfunctionaliteit

Er komt vanuit het DSO-LV meer functionaliteit beschikbaar om vanuit uw eigen VTH-systeem te kunnen gaan samenwerken met andere organisaties. Door hierop (technisch) aan te sluiten, kunt u samen met de organisaties in uw regio beoordelen of er nog afspraken gemaakt moeten worden, of er in de eigen organisatie nog aanpassingen doorgevoerd moeten worden en of de informatievoorziening op orde is.

Register Externe Veiligheid

Het huidige Risicoregister Gevaarlijke Stoffen wordt per 1 januari 2022 vervangen door een nieuw register: Register Externe Veiligheid (REV). Gemeenten zullen via een aanleverportaal of direct via API’s gegevens moeten gaan aanleveren aan dit landelijke register. Verwacht wordt, dat begin 2021 de specificaties van het bestandsformaat wordt opgeleverd. Dan pas is bekend welke gegevens een gemeente exact moet aanleveren en in welke vorm dat moet gebeuren. De gegevens in het REV worden uiteindelijk ook gebruikt in de viewers van de Omgevingswet. Ga in gesprek met uw leverancier om te vragen hoe zij u met hun software kunnen ondersteunen bij het aanleveren van de gegevens aan het REV.

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.

GEMMA Gegevenslandschap en Common Ground in 2021

Lees het gehele artikel

Onderstaande ontwikkelingen zullen beschikbaar worden gesteld aan gemeenten op het gebied van het GEMMA Gegevenslandschap en Common Ground. Een toelichting door Telengy-adviseur Paul Jansen.

Verwerkingsactiviteiten en Verwerkingenlog

Om te kunnen voldoen aan de AVG, wordt gewerkt aan een standaard voor het vastleggen van verwerkingen die zijn uitgevoerd op persoonsgegevens. Inmiddels zijn de eerste uitwerkingen van het Verwerkingenlog op Github gepubliceerd en wordt gemeenten en leveranciers gevraagd een review te geven. Elke applicatie dat persoonsgegevens verwerkt moet uiteindelijk deze Logging API implementeren. Leveranciers en gemeenten kunnen vanaf 2021 de implementatie hiervan gaan starten. Samenhangend hiermee wordt ook gestart met het opstellen van de specificaties voor een gemeentelijk Verwerkingsactiviteiten register. De verwachting is dat ook deze in 2021 beschikbaar gesteld gaat worden door VNG Realisatie.

Zaakgericht Werken

Sinds november 2019 zijn de API-specificaties en bijhorende componenten voor Zaakgericht Werken beschikbaar. Vanaf 2021 komt daar minimaal een Verzoeken register bij. Gemeenten kunnen losse verzoeken die burgers of bedrijven bij een gemeente indienen, als zodanig registeren zonder dat er gelijk een Zaak voor wordt aangemaakt. Aanvullend worden ook de specificaties van een Contactmomenten register en een Klanten register opgeleverd. De Zaakgericht Werken componenten vormen daarmee een goede basis voor Ominchannel dienstverlening waardoor gemeenten vanaf 2021 een nog betere dienstverlening kunnen gaan bieden. Ga in gesprek met uw leverancier om te bepalen wanneer deze functionaliteit voor u beschikbaar komt.

Omnichannel

Op 8 december 2020 heeft VNG Realisatie tijdens een inspiratiedag de handreiking voor de Omnichannel dienstverlening gepresenteerd. Het geeft gemeenten een praktische invulling in de aanpak naar een goede Omnichannel strategie. Er is ook een referentiearchitectuur opgesteld die gemeenten kunnen gebruiken in het inrichten van hun informatievoorziening. In 2021 wordt de referentiearchitectuur verder uitgebreid met verschillende implementatievoorbeelden, specifiek voor kleine tot grote gemeenten en van een geringe tot uitgebreide strategie implementatie.

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.

Samenwerken onder de Omgevingswet. Waar moet je op letten?

Lees het gehele artikel

Er komt een aanvraag voor een reguliere vergunning bij je organisatie binnen en je constateert dat je tijdens het behandelen van de aanvraag nog adviezen van twee andere organisaties nodig hebt. Omdat de twee andere organisaties bijdragen aan het behandelen van je aanvraag, ontstaat een tijdelijke samenwerking. Welke mogelijkheden worden er vanuit de landelijke voorzieningen en leveranciers geboden om tussen organisaties te kunnen samenwerken?

Paul Jansen, expert KennisCentrumOmgevingswet.nl en Telengy-adviseur beschrijft Samenwerken over de Omgevingswet. Waar moet je op letten?

Ontwikkelingen van Common Ground (3 van 3)

Bewegend Common Ground migratie applicaties
Lees het gehele artikel

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.

Bewegend Common Ground migratie 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

Ontwikkelingen van Common Ground (2 van 3)

functioneel beheer common ground
Lees het gehele artikel

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 gaat veranderen. Vergeet tot slot niet het beheer hiervan.

In een serie van drie artikelen bespreekt Telengy-adviseur Paul Jansen de ontwikkelingen van Common Ground. Paul legt uit wat de vijf lagen van Common Ground nu eigenlijk echt inhouden, gaat in op de transitie en verschillende migratievarianten die mogelijk kunnen worden doorgevoerd. Ook wordt het effect van Common Ground op de rol van de beheerder besproken. In dit tweede artikel: de rol van de functioneel beheerder.

Losse componenten

In het vorige artikel heb ik de vijf lagen van Common Ground besproken. Daarin heb ik aangegeven dat wanneer men een ‘silo’ splitst in vijf lagen, meerdere componenten ontstaan. Dit is in eerste instantie een horizontale opdeling. Echter kan ook iedere laag verticaal verder worden uitgesplitst.

Door deze verticale splitsing vormen er nog meer componenten. Zo ontstaat een soort matrix met verschillende componenten die allemaal een eigen functionaliteit bevatten. Hoe groter de opdeling, hoe meer losse componenten er zullen ontstaan. Meer componenten geeft een gemeente meer flexibiliteit om sneller aanpassingen door te voeren aan de informatievoorziening. Echter, meer componenten maken het totale landschap ook complexer. Dit vraagt om meer inzicht en overzicht van de gebruikte componenten. Er ontstaan vragen als:

  • Voldoet een component nog wel aan de gewenste functionaliteit, of missen we bepaalde functionaliteit?
  • Past een vervangend component wel goed in het bestaande geheel?
  • Aan welke eisen en wensen moet een component voldoen?
  • Met welke componenten kan een vraag vanuit de business worden beantwoord?

Vragen die verschillende expertises binnen een ICT-organisatie kunnen beantwoorden.

BiSL en Common Ground

Mijn collega Arno van Waesberghe heeft in november 2019 een artikel geschreven over een aanpak bij de transitie van functioneel beheer. Arno ging vooral in op de ondersteuning bij de verandering van de Functioneel Beheerder. Ik bespreek in dit artikel de meer inhoudelijke verandering van de taken, natuurlijk in de relatie tot Common Ground.

Over de rol van de functioneel beheerder is al veel geschreven. Het meest bekende raamwerk hiervoor is Business Information Services Library (BiSL). Hierin staan beschrijvingen van de taken, verantwoordelijkheden en bevoegdheden die bij de rol van de functioneel beheerder horen. In dit artikel bespreek ik enkele taken die door het toepassen van Common Ground naar mijn mening zullen worden geraakt.

functioneel beheer common ground

Het artikel gaat door onder de afbeelding.

Gebruikersbeheer

Eén van de taken bij gebruikersbeheer, is het aan de ene kant contact onderhouden met de verschillende leveranciers en specialisten, en aan de andere kant de gebruikers. Storingen die door een component optreden worden vaak door gebruikers gemeld. Leveranciers zullen deze storingen verhelpen. Vanwege de vele (verschillende) componenten kunnen er bij deze storingen veel leveranciers betrokken zijn. De functioneel beheerder moet goed weten welk component door welke leveranciers geleverd wordt, zodat snel en adequaat een oplossing kan worden gezocht.

Wijzigingenbeheer

Wijzigingsverzoeken die vanuit de organisatie worden aangedragen, moeten worden beoordeeld op de impact daarvan. Enkele belangrijke vragen die de functioneel beheerder zichzelf stelt:

  • Op welk component heeft de wijziging betrekking?
  • Hoe groot is die wijziging?
  • Verandert het proces niet of juist heel ingrijpend?

Doordat meerdere losse componenten worden gebruikt, moet per component waarop de wijziging betrekking heeft een impactanalyse komen. Omdat de wijziging vaak gerelateerd is aan een bepaalde functionaliteit, blijft het aantal componenten dat bekeken moet worden beperkt. Een impactanalyse op het volledige informatiesysteem is niet meer nodig.

Functionaliteitenbeheer

Bij het gebruik van een silo worden functionele specificaties voor de gehele applicatie opgesteld. Met het toepassen van Common Ground worden meerdere specifieke componenten gebruikt die hun eigen specificatie kennen. De functioneel beheerder moet goed weten welke specificaties er geëist worden aan een component, passend bij de functie waarvoor het component wordt ingezet. Het totaal aan componenten geeft dan een overzicht van de functionaliteiten die nodig zijn om een bepaalde business vraag te kunnen beantwoorden. Het onderhouden van dit overzicht en inzicht is een groeiende taak van de functioneel beheerder.

Met het beschikbaar komen van verschillende componenten, wordt het eenvoudiger om nieuwe samenstellingen te vormen. Hierdoor kan sneller ingespeeld worden op de behoefte van de business. De nieuwe samenstelling kan leiden tot een andere werking van het geheel of wordt nieuwe functionaliteit toegevoegd. Door het vluchtige karakter van samenstellingen moeten handleidingen sneller aangepast worden zodat deze weer aansluiten bij de werking van de (nieuwe) componenten.

Arno geeft in zijn artikel aan dat voor een functioneel beheerder de rol van adviseur meer aandacht gaat vragen. Dit zie je vooral terug in het beschrijven van de processen. De gewenste functionaliteit wordt immers aangestuurd vanuit processen. De relatie tussen (deel)processen en functionaliteiten krijgt bij het toepassen van Common Ground veel meer aandacht. Procesmodellen kunnen lezen en maken op basis van een standaard modelleertaal (zoals BPMN) wordt steeds belangrijker. Op basis van zijn of haar kennis van de beschikbare (losse) functionaliteiten, kan de functioneel beheerder aangeven hoe en welke (deel)processen het beste met welke functionaliteit ondersteund kunnen worden. Hierbij treedt de functioneel beheerder als adviseur op naar zijn collega’s.

Behoeftemanagement

De veranderende behoeften van dienstverlening richting burgers, bedrijven en instellingen zorgen ervoor dat organisaties in beweging blijven met hun dienstverlening. De ondersteunende middelen moeten hierin ook meebewegen. Common Ground maakt het mogelijk dat de beweging ook sneller gemaakt kan worden. Functioneel beheerders zullen daarom meer dan eerst de behoeften van de organisatie in kaart moeten brengen en afstemmen met de mogelijkheden die beschikbaar zijn of komen. Hierin ligt ook een relatie naar het functionaliteitenbeheer waarin bekeken wordt welke eisen en wensen gesteld worden aan bepaalde functionaliteit. Dit moet aansluiten bij de behoeften die een organisatie stelt. De functioneel beheerder heeft hier een belangrijke rol in.

Uitdaging

Zoals uit bovenstaande blijkt, ligt er voor de functioneel beheerder een mooie uitdaging om de nieuwe ontwikkelingen van Common Ground te ondersteunen. De functioneel beheerder van de toekomst krijgt een belangrijke rol in de afstemming tussen wat een organisatie aan veranderende behoeften heeft en hoe daarop snel kan worden ingespeeld. Dit met de beschikbare functionaliteiten die door losse componenten wordt geboden. Waar in het verleden de nadruk lag op het beheren van één pakket, verschuift de aandacht naar meerdere componenten. Is uw functioneel beheerder al op de hoogte van zijn veranderende rol?

Meer weten?

Voor meer informatie kunt u contact opnemen met Paul Jansen, adviseur bij Telengy, via tel. nr. 06 53 63 93 02, of e-mail: p.jansen@telengy.nl.

Ontwikkelingen van Common Ground (1 van 3)

Ontwikkelingen van Common Ground Telengy
Lees het gehele artikel

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

SILO Common Ground - Telengy

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.

Puzzelstukjes Common Ground - Telengy

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.

 

Marktverkenning Omgevingswet Software

Lees het gehele artikel

Op 29 mei 2019 is er een artikel gepubliceerd op KenniscentrumOmgevingswet.nl waarin gesproken wordt over een Marktverkenning Omgevingswet Software, uit te voeren door de VNG. Inmiddels heeft deze plaats gevonden, heeft daarnaast de IMG 100.000+ ook een Marktverkenning gehouden en is er ook nog een Markttoets uitgevoerd. In dit artikel bespreek ik ze alle drie.

Paul Jansen, expert KennisCentrumOmgevingswet.nl en Telengy-adviseur beschrijft de marktverkenning Omgevingswet Software.

Is uw vergunningensysteem al klaar voor de Omgevingswet?

Lees het gehele artikel

Op 1 januari 2021 treedt de Omgevingswet inwerking. Hierdoor wordt een aantal oude landelijke voorzieningen, zoals het Omgevingsloket Online, Ruimtelijkeplannen.nl en Activiteitenbesluit Internet Module (AIM), vervangen door de nieuwe landelijke voorziening Omgevingsloket. Initiatiefnemers kunnen via dit nieuwe, centrale loket eenvoudig vergunningaanvragen of meldingen indienen.

Paul Jansen, expert KennisCentrumOmgevingswet.nl en Telengy-adviseur beschrijft wat je nu al kunt doen, want de tijd dringt.

Even voorstellen… Paul Jansen

Lees het gehele artikel

Per 1 januari 2019 ben ik gestart bij Telengy als adviseur. Ik ben een ervaren Informatie Architect die al sinds 2001 bij de gemeentelijke overheid werkzaam is. In het begin van mijn carrière ben ik als Oracle database beheerder en Unix systeembeheerder begonnen, waarna ik nog enkele jaren projectleiding heb gedaan. Sinds 2011 ligt mijn focus op de informatie- en businessarchitectuur.  

De afgelopen jaren heb ik vanuit een grote gemeente meegewerkt aan de laatste ontwikkelingen op het gebied van het Digitaal Stelsel Omgevingswet, Common Ground, +1 Gemeenten, Regie op Gegevens en de Digitale Dienstverlening. Daarnaast heb ik in diverse landelijke werk- en klankbordgroepen samen met andere gemeenten, VNG-Realisatie en het Ministerie van BZK gewerkt aan nieuwe architectuurlandschappen en standaarden en heb ik deelgenomen aan verschillende pilots. 

De dienstverlening aan inwoners, bedrijven en instellingen is in een rap tempo aan het digitaliseren. Een gemeente heeft de taak om dit zo optimaal, effectief en efficiënt mogelijk uit te voeren. En dat ook nog eens in samenwerking met andere overheden, waarbij nieuwe technologie ingezet wordt voor de ondersteuning daarvan. In dit complexe landschap is het belangrijk inzicht te krijgen in de samenhang van de gehele informatievoorziening en te duiden waar afhankelijkheden en uitdagingen zitten. In combinatie met een gedegen toekomstvisie kan een gemeente daarmee een weloverwogen keuze maken in de stappen die ze moet gaan zetten. En het geven van dit inzicht, overzicht en visie is juist waar ik als Informatiearchitect veel energie uit haal. Dit enthousiasme straal ik graag uit naar mijn omgeving en zet ik in bij mijn werk als adviseur. 

Meer weten?

Voor meer informatie kunt u contact opnemen met Paul Jansen, adviseur bij Telengy, via tel. nr. 06 53 63 93 02 of via e-mail: p.jansen@telengy.nl.