Common Ground vijflaagsmodel opbouw en gebruik
Het Common Ground vijflaagsmodel is een hulpmiddel om de informatiearchitectuur te beschrijven die nodig is voor realisatie van de Informatiekundige visie Common Ground. De laagsgewijze presentatie toont hoe partijen met verschillende rollen samenwerken en toont laagsgewijs benoemde generieke functies.
Rollen[bewerken]
Rollen in het Common Ground vijflaagsmodel (uit model: GEMMA 2) - Toon SVG - Download als csv
- Dienstenafnemer (afgekort: afnemer): Levert de gebruikersinterfaces en procesinrichting voor burgers, bedrijven en gemeentelijke medewerkers. Gebruikersinterfaces kunnen bijvoorbeeld de vorm hebben van een mobiele app, website of traditionele procesapplicatie. De dienstenafnemer is verantwoordelijk voor het authenticeren en autoriseren van eindgebruikers zodat zij alleen toegang krijgen tot toegestane functies en data (bijvoorbeeld via authenticatiemiddelen als DigiD en eHerkenning voor inwoners en ondernemers en Policy Based Access Control (PBAC) voor het verlenen van toegang aan personen en systemen tot functies en data). Een dienstenafnemer legt ook vast voor welk doel en met welke doelbindingsclaim de dienstenafnemer diensten zijn gebruikt (bijvoorbeeld met een doelbindingsclaim gebaseerd op een wettelijke grondslag of toestemming van een burger).
- Intermediair: Verzorgt de functionaliteit die nodig is om afnemers en aanbieders met elkaar te verbinden. Dit wordt gerealiseerd via een combinatie van afspraken, standaarden en voorzieningen (bijvoorbeeld door informatie over beschikbare diensten te publiceren en veilige communicatie-netwerken beschikbaar te stellen).
- Dienstenaanbieder (afgekort: aanbieder): Biedt diensten voor afnemers om via gestandaardiseerde interfaces data uit bronregisters te gebruiken. Diensten worden bij voorkeur geleverd in de vorm van gestandaardiseerde (RESTful) API's die zijn ontworpen conform de REST-API Design Rules. Dienstenaanbieders zorgen dat afnemers alleen toegang krijgen tot diensten waartoe zij gerechtigd zijn en leggen het (beoogd) gebruik van diensten vast.
Iedere rol is verantwoordelijk voor het realiseren van een aantal generieke functies. Daarbij kunnen zowel bedrijfsmatige, informatiekundige als technologische aspecten een rol spelen. In de praktijk kan een generieke functie op verschillende manieren worden gerealiseerd.
Lagen[bewerken]
Lagen in het Common Ground vijflaagsmodel (uit model: GEMMA 2) - Toon SVG - Download als csv
Ieder van de 5 lagen kent een bepaald soort generieke functies:
- De bovenste 2 lagen 'Interactie' en 'Procesinrichting' kennen functies voor interactie met burgers, bedrijven en medewerkers en het uitvoeren van gemeentelijke processen.
- De middelste laag 'Connectiviteit' bevat functies om de communicatie tussen functies in de bovenste en onderste lagen van het model te faciliteren.
- De onderste 2 architectuurlagen 'Gegevensbronnen' en 'Diensten' kennen functies die op een verantwoorde manier gestandaardiseerde opslag en ontsluiting van data mogelijk maken.
De laagsgewijze groepering van functies verduidelijkt hoe functionaliteit voor de uitvoering van processen is te scheiden van het vastleggen en verstrekken van data in bronregistraties. Afgebakende functionaliteit vaker in aparte componenten onderbrengen leidt tot een meer modulaire gemeentelijke informatievoorziening.
Rollen en lagen[bewerken]
Rollen en lagen in het Common Ground vijflaagsmodel (uit model: GEMMA 2) - Toon SVG - Download als csv
Bovenstaand model toont hoe van ieder van de 3 rollen wordt verwacht dat ze bepaalde typen generieke functies realiseren. Van dienstenafnemers wordt bijvoorbeeld verwacht dat zij voor interactie slanke gebruikersinterfaces aanbieden die maximaal gebruik maken van data uit bronregistraties. Van dienstenaanbieders wordt verwacht dat zij gestandaardiseerde API's aanbieden die afnemers kunnen gebruiken om brondata te ontsluiten.
In de praktijk zijn er meerdere manieren waarop rollen zijn te vervullen en functies zijn te realiseren. Partijen kunnen bijvoorbeeld 1 of meerdere rollen vervullen en applicaties kunnen 1 of meerdere functies realiseren. Vanuit het streven naar een modulariteit ('de mate waarin de componenten van een systeem kunnen worden gescheiden en gecombineerd') is het wenselijk dat componenten zich beperken tot afgebakende functionaliteit. In de praktijk kunnen er redenen zijn waarom dit niet extreem wordt doorgevoerd en rollen of functies worden gecombineerd. Een voorbeeld hiervan zijn componenten die voor het goed kunnen aanbieden van gebruikersschermen gebruik maken van eigen bedrijfsregels (in plaats van die op te vragen bij een andere component).
Gebruik[bewerken]
Net als andere architectuurmodellen is het Common Ground vijflaagsmodel een vereenvoudigde weergave van de werkelijkheid. Het model is bedoeld om de door Common Ground beoogde informatievoorziening zo goed mogelijk te beschrijven. Het benoemen van rollen en het laagsgewijs groeperen van generieke functies helpt daarbij. Het model is te zien als 'kapstok' om zaken te beschrijven en de communicatie met bij Common Ground betrokkenen te ondersteunen.
Een voorbeeld hiervan is het belangrijke uitgangspunt van de Informatiekundige visie Common Ground dat afnemers maximaal gebruik maken van data uit bronregistraties en data bij voorkeur niet als kopie-data in lokale registraties opslaan. Onderstaande afbeelding illustreert hoe dienstenafnemers, intermediairs en dienstenaanbieders daarbij samenwerken.
Netwerk van dienstenaanbieders en dienstenafnemers (uit model: GEMMA 2) - Toon SVG - Download als csv
Gemeenten, leveranciers en ketenpartijen kunnen het model gebruiken bij het groeien naar een informatievoorziening in lijn met de Informatiekundige visie Common Ground. De generieke functies beschrijven in algemene termen wat er nodig is. Betrokken partijen bepalen hoe zij daar binnen hun specifieke context het beste invulling aan kunnen geven.
Net als bij andere modellen moet het model niet geforceerd worden gebruikt voor andere doelen dan waarvoor het is bedoeld. Het model is primair bedoeld voor transactionele dienstverlening. Voor zaken zoals bijvoorbeeld streaming datadiensten, data-gedreven werken en business intelligence biedt het model weliswaar aanknopingspunten, maar volstaat het niet. Het model is ook niet bedoeld om interactiepatronen tussen aanbieders en afnemers te beschrijven of om te beschrijven hoe bulkbevragingen (bijvoorbeeld voor data-analyse) moeten plaatsvinden.