Thema Architectuur Mobiel compleet


Inhoud




Inleiding

Totstandkoming

Dit katern is tot stand gekomen in het kader van de Digitale Agenda 2020 door een werkgroep van KING en de gemeente Woerden. Het katern bouwt voort op de GEMeentelijke Model Architectuur (GEMMA) en sluit daarbij zoveel mogelijk aan op bestaande architecturen binnen de overheid en in het bijzonder de gemeenten.

Onze dank gaat in het bijzonder ook uit aan de gemeente Woerden die heeft geholpen bij het formuleren van de opdracht, de Inwonercloud als voorbeeld heeft aangedragen en actief heeft meegedacht over de uitgagingen in het mobiele domein. Ook gaat onze dank uit aan de gemeente Delft die een substantiële bijdrage heeft geleverd bij de review en daarmee het afronden van het katern.

Opdracht

Vanuit het Gemeentelijk Portfolio Overleg (GPO) is onder meer vanuit het project Inwonercloud (gemeente Woerden) gevraagd de ontwikkelingen rondom apps te verkennen; het gaat hierbij in het bijzonder om:

  1. Kwaliteitsborging van bestaande en toekomstige apps. Denk hierbij aan bundeling van bestaande appstores en/óf certificering van gemeentelijke apps;
  2. Vergroten van de bruikbaarheid en interoperabiliteit van gemeentelijke apps door opstellen/aanpassen/toepassen van koppelvlakstandaarden met backoffice systemen bij gemeenten en/of zorgaanbieders;
  3. Vergroten van de bruikbaarheid en interoperabiliteit van gemeentelijke informatiebronnen en transactiemogelijkheden voor toepassingen van anderen;
  4. Positionering van het fenomeen “apps” in op het softwarelandschap/architectuurmodellen van gemeenten.

Dit heeft geleid tot een project dat als resultaat een referentiearchitectuur/katern binnen de GEMMA oplevert met een verbijzondering van de GEMMA voor mobiele applicaties. Het resultaat kan worden samenvat als:


Een referentiearchitectuur binnen de GEMMA voor het gebruik van het mobiele kanaal en het beschikbaar stellen en standaardiseren van de gemeentelijke informatievoorziening ten behoeve van het mobiele kanaal.

Binnen deze architectuur is specifiek gevraagd naar aanvullende richtinggevende principes, kaders, richtlijnen en standaarden.

Scope

De architectuur in dit katern bouwt voor op de bestaande referentiearchitectuur van de GEMMA en sluit maximaal aan op andere bestaande architecturen binnen de overheid. De scope is echter breder dan de meeste bestaande architecturen die zich of op een specifieke doelgroep richten, of bijvoorbeeld een zware focus op de techniek leggen. De basis van voor de mobiele informatievoorziening wordt gevormd door de gemeentelijke informatiearchitectuur, deze is reeds beschreven (zie 11). In dit katern wordt er daarom alleen gerefereerd naar, en de aangesloten op deze informatiearchitectuur. Daarmee is de scope van deze architectuur:


De verbinding tussen de gemeentelijke informatievoorziening, de informatievoorziening buiten het gemeentelijk domein (zorg, sociaal, etc.) en de gebruikers van de gemeentelijke informatie. Dit omvat het mobiele kanaal, de mobiele apparaten, mobiele applicaties en de gebruikersgroepen


In scope:

  • Inwoners, ondernemers, medewerkers, ketenpartners en bestuurders als doelgroepen van mobiele toepassingen;
  • Het mobiele kanaal;
  • Mobiele applicaties;
  • Mobiele apparaten – zoals tablets en smartphones;
  • De aansluiting van mobiele applicaties op de gemeentelijke informatie (a.h.v. de gegevensarchitectuur);
  • Informatiebeveiligingsaspecten op het (mobiele) kanaal, mobiele applicaties en mobiele apparaten;

Buiten scope:

  • Overige kanalen (web, balie, telefoon, etc.) en het kiezen of implementeren van een kanaalstrategie;
  • Het beschikbaar stellen van gemeentelijke informatie via digitale diensten – dit wordt beschreven in het gemeentelijke applicatielandschap 11;
  • Het verzamelen van informatie uit het gebruik van mobiele apparaten. Denk hierbij aan customer journeys maar ook sensor data;
  • Laptops als mobiel apparaten (dit valt onder ‘reguliere’ webapplicaties en eventueel onder responsive apps);
  • App ontwikkeling en de software architectuur mobiele applicaties – waar mogelijk worden hier wel referenties gelegd naar bestaande software architecturen voor mobiele applicaties. KING zal de ontwikkeling niet zelf doen, maar zal dit overlaten aan de markt. In dit katern wordt er daarom volstaan met richtlijnen voor de te ontwikkelen mobiele applicaties (die bijvoorbeeld in aanbestedingen gebruikt kunnen worden).
  • Beleid en keuzes voor mobiele apparaten;
  • Internet of Things (IoT) en embedded devices;
  • Social media.

Figuur 2: Context van de mobiele architectuur op bladzijde 10 visualiseert deze scope.

De architectuur dekt alle gemeentelijke domeinen af. In de voorbeelden worden in het bijzonder de sociale, ruimtelijke, bestuurlijke en veiligheidsdomeinen gebruikt.

Deelnemers

Vaste werkgroep KING

  • André Plat, projectleider en product owner
  • Arwin van den Bos, KING-architect en penvoerder van de werkgroep
  • Toine Schijvenaars, KING-architect
  • Arnoud Quanjer, KING-architect

Deelnemers

  • Karolijn van den Heuvel, gemeente Woerden
  • Eric van Eijk, gemeente Woerden
  • Hans Harskamp, gemeente Woerden
  • Edwin Coster, gemeente Delft

Leeswijzer

Het katern begint met het definiëren van het beschouwingsgebied, de visie en de relatie met de GEMMA en NORA. De onderdelen mobiele keten beschrijft de verschillende schakels in de mobiele keten waar het katern dieper op in gaat. In de hieropvolgende paragrafen worden deze schakels in context geplaatst en wordt de architectuur hiervan in samenhang beschreven.

De hieropvolgende hoofdstukken geven de achtergrond waar de mobiele architectuur op gebaseerd is. Als eerst worden de bestaande architecturen besproken. Vervolgens worden de principes uit de NORA en GEMMA gerelateerd aan het mobiele domein en zijn specifieke principes voor de mobiele architectuur uitgewerkt. Tenslotte worden in de bijlagen enkele (actuele) voorbeelden genoemd, is er een template gemaakt voor de registratie van mobiele toepassingen binnen de gemeente en is er een uitgebreide referentielijst opgenomen.

Samenvatting

Deze versie van dit katern is een eerste beschrijving van het mobiele domein binnen gemeenten naar aanleiding van een verkenning van architecturen en keuzes voor het gemeentelijk domein hierin. Er is een startbijeenkomst belegd in de gemeente Woerden en gemeenten zijn via de nieuwsbrief uitgenodigd deel te nemen. Vooralsnog is vooral door de gemeenten Woerden en de Delft meegedacht op deze versie, die door KING de komende 6 maanden getoetst wordt als start om te laten gebruiken door informatie-managers en –architecten bij de lokale overheid.

Inhoudelijk is geïnventariseerd welke beschrijvingen voor mobiele overheid al aanwezig waren en is verbinding gelegd binnen KING met lopende ‘trajecten’, waaronder het gegevenslandschap en API-strategie. Geboden worden architectuurprincipes, een beschrijving van de ‘lagen’ in de mobiele keten en een afwegingskader voor de inzet van het kanaal mobiel, i.c. mobiele applicaties.

Informatie-managers en –architecten worden uitgenodigd deze versie te gebruiken en hun bevindingen, verzoeken om nadere uitwerking e.d. te delen met het projectteam. Hiervoor zijn GEMMA Online, Pleio en e-mail beschikbaar.

Dit katern geeft gemeenten en leveranciers een handvat voor het ontwikkelen van toepassingen in het mobiele kanaal. Kennis over mobiele toepassingen en aansluiting bij de gemeentelijke architectuur en standaarden staan hiervoor in dit katern beschreven.




Mobiele architectuur gemeenten

Beschouwingsgebied

Door KING wordt ‘mobiel’ gezien als een kanaal via welke (gemeentelijke) informatie (ook) ter beschikking gesteld kan worden aan inwoners, ondernemers, medewerkers en keten en netwerkpartijen. De gehele keten van gebruikers, mobiele apparaten, besturingssysteem, mobiele applicaties, netwerk, het mobiele kanaal en de gemeentelijke informatiediensten wordt beschouwd. Deze architectuur zal hier zoveel mogelijk op aansluiten en de ontbrekende aspecten en verbindingen nader beschrijven.

Ter verduidelijking van het beschouwingsbied worden er verder in de bijlage enkele voorbeelden gegeven van actuele mobiele initiatieven in het gemeentelijk domein en voorbeelden uit het publieke domein.

Visie


De markt heeft maximale vrijheid voor het ontwikkelen van innovatieve, nuttige en flexibele mobiele applicaties in een dynamische omgeving die (mede) gebruik maken van gemeentelijke informatie. Gemeenten ondersteunen dit door het beschikbaar stellen van robuuste, landelijk gestaardiseerde informatie- en beheerdiensten op hun gemeente-specifieke inrichting van het IT landschap.


Een uitgangspunt in deze visie is dat gemeenten de ontwikkeling van mobiele applicaties zoveel mogelijk aan de markt overlaten. Hiervoor moeten de gemeenten landelijk gestandaardiseerde informatiediensten ter beschikking stellen ontkoppeld van de gemeente specifieke inrichting van het IT-landschap. Dit gaat verder dan het beschikbaar stellen van informatie en het kunnen muteren van deze informatie. Het gaat ook om beheerdiensten die voor de beveiliging zorgen en die de eigenaar van de gegevens (waaronder de burger) de mogelijkheid geven zelf te bepalen wie toegang krijgt tot diens informatie.

Relatie NORA en GEMMA

Dit katern geeft een speciale view op de GEMMA – en daarmee ook de NORA - vanuit het oogpunt van het mobiele kanaal. Hierbij raakt het katern impliciet of expliciet diverse aspecten die in de GEMMA beschreven staan. In hoofdstuk 4 staan de van toepassing zijnde principes beschreven. Verder bouwt dit katern voort op de informatiearchitectuur van de GEMMA. Er worden in dit katern niet expliciet bedrijfsfuncties, applicatiefuncties en applicatiecomponenten beschreven aangezien deze niet anders zijn dan in de algemene GEMMA-architectuur. Het enige verschil is dat deze via het mobiele kanaal ontsloten worden.

De NORA stelt dat internet het voorkeurskanaal is voor het leveren van diensten (NORA AP09), echter de NORA stelt ook dat de dienst ook minimaal via één ander kanaal geleverd moet kunnen worden (NORA AP10). Bij het leveren van formele gemeentelijke diensten dient hier expliciet rekening mee gehouden te worden. Voor het leveren van informele, toegevoegde diensten en innovaties is dit minder belangrijk.

Onderdelen mobiele keten

De essentie van het vraagstuk waar deze architectuur zich op richt is het toegankelijk maken van de gemeentelijke informatie en dienstverlening via het mobiele kanaal. De scope is nadrukkelijk breder dan alleen een verlengstuk van de huidige gemeentelijke dienstverlening over het mobiele kanaal. Enerzijds biedt dit kanaal mogelijkheden voor het ontwikkelen van innovatieve concepten die toegevoegde waarde bieden aan de afnemers, anderzijds kan de kracht en creativiteit van de markt gebruikt worden door het beschikbaar stellen van (generieke) informatieservices.

De mobiele architectuur kent de onderstaande deelgebieden:

Schakels in de architectuur van mobiele toepassingen.png

Figuur 1: Schakels in de architectuur van mobiele toepassingen

Elk deelgebied zal in dit hoofdstuk nader beschreven worden:

  1. Gebruikers en doelgroepen;
  2. Mobiele applicaties;
  3. Mobiele apparaten;
  4. Het mobiele kanaal en kanaalstrategie;
  5. Generieke informatiediensten;
  6. De bronsystemen;
  7. Informatiebeveiliging

Context

Context van de mobiele architectuur.png

Figuur 2: Context van de mobiele architectuur

Gebruikers en Doelgroepen

De gebruikers van het mobiele kanaal kunnen worden samengevat in inwoners, ondernemers, (gemeente)medewerkers, ketenpartners en bestuurders. Hoewel er voor de technische implementatie niet veel verschillen zijn tussen doelgroepen zijn er op het vlak van bijvoorbeeld informatiebeveiliging en kosten/baten wel de nodige aandachtspunten. Zo liggen er kansen om inwoners meer te betrekken bij de processen die de gemeenten voor haar uitvoert en helpt de digitalisering om een deel van de administratieve werkzaamheden richting de inwoner te verplaatsen. Aan de kant van de gemeentelijk medewerkers liggen er kansen op het vlak van tijd en plaatsonafhankelijk werken, maar er liggen zeker ook kansen voor (bijvoorbeeld) buitendiensten om laagdrempelig, ter plaatse administratieve werkzaamheden te kunnen verrichten. Denk bij dit laatste bijvoorbeeld aan het melden van constateringen of toetsen van registraties aan de hand van deze constateringen.

Mobiele applicaties


Onder mobiele applicaties – of apps - wordt in deze context verstaan software die specifiek gemaakt is voor het gebruik op mobiele apparaten (als tablets, smartphones, wearables, etc.) en responsive webapps.


Een mobiele applicatie is dus een ‘gewone’ applicatie met een aantal bijzondere kenmerken en uitgangspunten. Ook zijn niet alle mobiele applicaties te relateren een het gemeentelijke bedrijfsfunctie domein.

Kenmerken

  • Mobiele applicaties zijn laagdrempelig en veel gebruikt;
  • Autorisatie en authenticatie via mobiele apparaten is in opkomst (denk aan betalingen);
  • Mobiele apparaten hebben vaak rijke functionaliteit als een camera, GPS, etc.
  • Mobiele apparaten hebben een andere gebruikersinterface als desktopsystemen (in omvang, toetsenbord, swiping, etc.);
  • Uitgangspunt is dat de beveiliging van mobiele apparaten vaak slecht is (principe MA5);
  • Uitgangspunt is dat de gebruikte internetverbinding vaak slecht is (principe MA5);
  • Er is een grote diversiteit aan platforms en soorten apparaten;
  • Informatie is vluchtig en wordt normaliter niet opgeslagen.


Soorten mobiele applicaties
In de referentiearchitectuur voor mobiele applicaties voor EZ [06] worden de onderstaande soorten mobiele applicaties onderscheiden en is er een beslisboom opgesteld die helpt op de hierin de juiste keuze te maken. Een hierop gebaseerde beslisboom wordt in paragraaf 2.6 besproken.

  1. Desktop virtualisatie op mobiele clients. De werkplekomgeving met desktopapplicaties wordt gepresenteerd op de mobiele client; bijvoorbeeld door middel van een VPN-verbinding met een Citrix client. Enerzijds is dit een bijzonder eenvoudige oplossing, anderzijds is de gebruikersgroep (voornamelijk de gemeentelijk buitendienst medewerkers) en de beschikbare mobiele apparaten (de grotere tablets) beperkt.
  2. Native apps. Native apps zijn mobiele applicaties die voor een specifiek besturingssysteem en vaak ook voor een specifiek soort mobiel apparaat ontwikkeld zijn (Android, IOS, Windows 10, smartwatch of tablet, etc.). Het voordeel is dat ze geoptimaliseerd voor een specifieke omgeving gemaakt kunnen worden en dat ze gebruik kunnen maken van specifieke hardware (camera, GPS, etc.) van het mobiele apparaat. Het nadeel is dat er een keuze gemaakt moet worden voor een specifiek platform, of dat er verschillende versies voor de verschillende platforms ontwikkeld gaat worden.
  3. Mobiele Webapps. In tegenstelling tot native apps werken deze applicaties in de context van een browser. Data en business logica staat grotendeels op de server. De applicatie is minder afhankelijk van het specifieke besturingssysteem of de afmetingen van het scherm. In principe werkt een webapp op elk mobiel apparaat (met een gangbare browser en bibliotheken) waardoor er niet voor elk type mobiel apparaat een aparte versie gemaakt hoeft te worden. De keerzijde is dat er niet of nauwelijks support is voor specifieke functies van het mobiele apparaten zoals de camera en de GPS.
  4. Hybride apps. Dit zijn native apps waarvan een groter of kleine gedeelte in de vorm van een webapp bestaat.


App ontwikkeling
Dit katern gaat niet expliciet in op de ontwikkeling van applicaties – dit valt ook buiten de scope van de GEMMA. Wel zijn hiervoor reeds leidraden opgesteld:

  • Enterprise Mobility Rijks - Handreiking app ontwikkeling en beheer (15)
  • Het CIP geeft een aantal expliciete beveiligingseisen voor mobiele applicaties, zie (16)

Mobiele apparaten

Er zijn allerlei soorten mobiele apparaten – de apparaten. Enerzijds hebben deze apparaten beperkingen qua gebruikersinterface, opslag etc. Anderzijds hebben ze vaak specifieke functies (zoals camera’s en GPS) die ze bijzonder geschikt maken voor bepaalde taken. De volgende soorten worden onderscheiden:

  1. Smartphones; op dit moment is dit verreweg de meest gebruikte groep mobiele apparaten. Ook is er een grote mate van standaardisatie bij deze groep. Kenmerken zijn de relatieve geringe afmeting - wat visuele en invoerbeperkingen met zich meeneemt – en de rijke uitrusting aan functionaliteiten (GPS, camera, near field communication (NFC), Wifi/Bluetooth, etc.). Ook worden mobiele apparaten erg veel gebruikt (medio 2016 had 86% van de Nederlanders en smartphone). Uitgangspunt is dat de beveiliging van deze apparaten slecht is geregeld (door de gebruiker).
  2. Tablets; qua functionaliteit zijn tablets vergelijkbaar ‘grote smartphones’ – meestal zonder telefoonvoorzieningen. Ze onderscheiden zich echter door grote schermen, betere specificaties (opslag, processor) en betere invoermogelijkheden. Tablets nemen vaker de plek van laptops in – en (grotere) smartphones nemen vaker de plek in van tablets.
  3. Wearables; apparaten die op het lichaam gedragen kunnen worden. Kenmerken is dat dit een relatief nieuwe groep is en dat er nog een grote diversiteit is. Sommige apparaten hebben geen of zeer kleine schermen (smartwatches) en andere weer zeer uitgebreide visuele mogelijkheden (google glass). Deze diversiteit inachtnemend vallen ze binnen deze architectuur.
  4. Internet of things; het IoT is een infrastructuur die fysieke apparaten aan elkaar verbindt. Gaat om bijvoorbeeld auto’s, sensoren, pompen, etc. Aangezien deze apparaten niet worden gebruikt om de doelgroepen van deze architectuur te benaderen valt deze categorie buiten beschouwing.
  5. Embedded mobiele devices; kort door de bocht zijn dit dezelfde apparaten als in het IoT maar dan niet (expliciet) verbonden via een netwerk. Deze categorie valt om dezelfde reden buiten beschouwing.
  6. Desktops en laptops; deze apparaten vallen formeel niet onder onze noemer mobiele apparaten maar er is wel een duidelijke trend dat het onderscheid tussen mobiel en niet mobiel vervaagt. Bij laptops is dat al evident maar ook op desktops worden steeds vaker mobiele applicaties gebruikt (denk aan windows apps of webapplicaties). De verwachting is dan ook dat het onderscheid tussen mobiel en niet mobiel vervaagt.

Kanaalstrategie

De inzet van het mobiele kanaal moet aansluiten bij de gekozen kanaalstrategie (principe MA3). Dit verschilt per gemeente. Een cross- of OMNI-channel benadering is innovatief en klantvriendelijk maar is ook complex.

  • Multi-channel benadering. De afnemer kan het kanaal van zijn/haar voorkeur kiezen. De kanalen zijn echter afzonderlijk ingericht, niet aan elkaar verbonden en tussentijds van kanaal wisselen is niet mogelijk;
  • Cross-channel benadering. De afnemer kan het kanaal van zijn/haar voorkeur kiezen en tussentijds aanpassen;
  • OMNI channel benadering. De afnemer kan op elk moment het kanaal van zijn/haar voorkeur gebruiken zonder dat er een expliciet kanaalovergang merkbaar is.

De keuze voor een specifieke kanaalstrategie of de implementatie hiervan valt buiten de scope van deze architectuur en zal per gemeente verschillen. Een expliciete keuze voor een kanaalstrategie is echter wel randvoorwaardelijk voor een goede implementatie van het mobiele kanaal.

Generieke informatiediensten

Een kenmerk van mobiele applicaties is dat ze veelal zwaar steunen op online informatiediensten. Het uitgangspunt is dat een mobiele applicatie zelf geen data lokaal (of in de cloud) opslaat. Indien er toch informatie wordt opgeslagen wordt deze op basis van de dataclassificatie beveiligd (principe MA5.1). Informatiediensten en bijhorende beheerdiensten dienen dus ‘dunne’ front-end applicaties te ondersteunen door onder andere te zorgen voor (eigen) opslagmogelijkheden, transactiemanagement, herstel na het, al dan niet tijdelijk, wegvallen van de mobiele applicatie en beveiliging.

Bronsystemen

De generieke informatiediensten ontkoppelen de mobiele applicaties van de achterliggende bronsystemen van de gemeenten (en andere partijen). Dit geeft elke gemeente de vrijheid om, gegeven de specifieke kenmerken van de gemeente zoals omvang en budget, de best passende oplossing te kiezen. De GEMMA biedt hierbij ondersteuning door middel van o.a. de bedrijfsarchitectuur, de applicatiearchitectuur en de software catalogus.

Informatiebeveiliging

De informatiebeveiliging in de mobiele architectuur is feitelijk een keten van informatiebeveiligingsaspecten op verschillende niveaus :

  1. De beveiliging van de mobiele apparaten zelf;
  2. De beveiliging van het mobiele platform (native, web, hybride, virtualisatie)
  3. De beveiliging van de applicaties en opgeslagen informatie. Hoewel principe MA5 stelt dat er geen (gevoelige) data lokaal opgeslagen mag worden zal er in de praktijk een afweging met de beschikbaarheid van de applicatie gemaakt moeten worden. Den bijvoorbeeld aan een applicatie met inspectiegegevens voor een inspectie op locatie;
  4. De beveiliging van de generieke informatiediensten (buiten scope van deze architectuur);
  5. De beveiliging van de achterliggende bronsystemen (buiten scope van deze architectuur);
  6. De beveiliging van de onderliggende infrastructuur (buiten scope van deze architectuur).

Merk op dat hoewel de beveiliging van informatiediensten, achterliggende bronsystemen en de onderliggende infrastructuur buiten de scope van dit katern vallen, hier vanuit het mobiele kanaal wel aanvullende beveiligignseisen aan gesteld kunnen worden. Deze vormen dan samen met de beveiligingseisen uit de andere kanalen een integraal pakket van beveiligingseisen.

Daarnaast moet er een onderscheid gemaakt worden tussen de verschillende vormen van bedreigingen (16):

  1. Remote. Dit zijn bedreigingen afkomstig vanaf het netwerk op de entry points van de applicatie (webview, JSON-client, vanuit een gecompromitteerde server, etc.);
  2. Lokaal. Bedreigingen vanaf het eigen apparaat doordat er elektronisch toegang tot het apparaat verkregen wordt (malware, jailbreak, etc.);
  3. Fysiek. Toegang bij verlies of diefstal van het apparaat. Vergrendeling van het apparaat vormt dan slechts een eerste barrière.

Architectuurmodel

Inleiding

KING ziet mobiele applicaties als een middel om via het mobiele kanaal aan te sluiten op de gemeentelijke informatievoorziening. Figuur 3 toont een concept model van het gemeentelijk gegevenslandschap en de positie van mobiele applicaties hier in [1].

Gemeentelijk gegevenslandschap v0.72.png

Figuur 3: Gemeentelijk gegevenslandschap v0.72 (11)

Een essentieel aspect van dit model is dat er een strikt onderscheid gemaakt wordt tussen de gebruikerstoepassingen en de gebruikte informatiediensten met het achterliggende, gemeente specifieke IT-inrichting. Deze scheiding faciliteert een bimodale inrichting van de informatievoorziening met enerzijds een robuuste, veilige en stabiele inrichting van het gemeentelijk IT-landschap ontsloten via informatiediensten en anderzijds een flexibele front-end waarin mobiele applicaties zeer snel ontwikkeld en aangepast kunnen worden.

Bimodaal IV model.png

Figuur 4: Bimodaal IV model

Een ander belangrijk aspect is dat er, naast de informatiediensten die gemeentelijke informatie zelf toegankelijk maken, er ook beheerdiensten zijn die bijvoorbeeld de toegang tot informatie regelen. Zo kan een burger bijvoorbeeld zelf bepalen wie er toegang tot zijn gegevens krijgt. Dit geeft een expliciete invulling van het uitgangspunt dat de burger zelf eigenaar is van zijn/haar gegevens. Dit uitgangspunt is ook de essentie van de Inwonerscloud van de gemeente Woerden.

Op basis van dit model toont Figuur 2 de ‘lagen’ die onderscheiden worden in de architectuur mobiel:

  1. De gebruiker(s)
  2. De front-end (de app)
  3. Het (fysieke) mobiele apparaat
  4. Het besturingssysteem van het mobiele apparaat
  5. Het netwerk (internet)
  6. De generieke informatiediensten waar de front-end gebruik van maakt
  7. De achterliggende bronsystemen
  8. Informatiebeveiliging op de verschillende lagen.

De mobiele architectuur is niet specifiek gerelateerde aan bepaalde bedrijfsfuncties. Mobiele applicaties kunnen, net als andere applicaties, vrijwel alle bedrijfsfuncties ondersteunen. Overigens kunnen er ook mobiele applicaties ontwikkeld worden die geen directe relatie hebben met het gemeentelijk bedrijfsfunctiemodel. Dit architectuuraspect wordt daarom niet behandeld in dit katern. De onderstaande paragrafen gaan dieper in op de verschillende lagen.

Applicatielaag

De keuze welke technologie gebruikt wordt voor het realiseren van een mobiele applicatie hangt van een aantal factoren af zoals de herbruikbaarheid, het gebruik van specifieke functionaliteiten van mobiele apparaten, de doelgroep etc. Aangezien dit per gemeente, per doelgroep en per functie verschilt is er expliciet geen principe opgesteld die hier een voorkeur voor uitspreekt. In (15) is een hoofdstuk over de softwarearchitectuur opgenomen met daarin een ‘scorelijst’ waarbij native, web en hybride apps op detailpunten aan elkaar worden gewogen. Dit katern volstaat met de onderstaande beslisboom :

800px

Figuur 5: Beslisboom mobiele applicatie technieken

Kwaliteitseisen en -richtlijnen mobiele applicaties Naast generieke kwaliteitseisen kennen mobiele applicaties een aantal specifieke kwaliteitseisen. De onderstaande tabel somt deze op alsmede een aantal generieke eisen die ook op andere applicaties van toepassing maar (nog) niet eerder expliciet benoemd zijn.

Eis/ richtlijn Toelichting Bron
De applicatie dient ontworpen te zijn om om te kunnen gaan met niet beschikbare informatiediensten en internet. Door de mobiele aard van apparaten kan de internet connectie regelmatig wegvallen of zelfs niet beschikbaar zijn. MA2
Voorkeuren van de afnemer worden bewaard en hergebruikt. Dit geldt binnen een applicatie, maar ook in de keten en over kanalen. NORA AP20
Mobile first webdesign Mobiele apparaten worden ook vaak gebruikt om websites te bezoeken. Om deze toegankelijk en gebruikersvriendelijk te maken op mobiele apparaten zullen hiervoor specifieke maatregelen genomen moeten worden. Een best practice ontwerpfilosofie hiervoor is mobile first.
  • Websites worden in eerste instantie ontwikkeld voor het kleinste scherm en van vandaar uit opgeschaald naar grotere viewports (17);
  • Invoermogelijkheden zullen getuned moeten worden voor mobiele apparaten;
-
Vermijd lokale opslag van gevoelige informatie Opslag van gevoelige informatie op een mobiel apparaat dient vermeden, of minimaal versleuteld, te worden (zero-footprint) op basis van de data classificatie. Ook moet er geen ‘technisch gevoelige informatie’ op het apparaat opgeslagen (wachtwoorden, sleutels, interne URLs). Zie CIP (16) eis 5 en eis 8. MA5
Vermijd lokale opslag van relevante business logica Voor ‘relevante’ business logica in applicaties geldt hetzelfde als voor gevoelige informatie. MA5
Applicaties zorgen zelf voor veilige toegang tot de applicatie en de informatie. Applicaties dienen zelf maatregelen te nemen voor beveiligde toegang tot gevoelige informatie indien de dataclassificatie-niveau dat vereist. Waar mogelijk maken de applicaties gebruik van standaard bouwblokken zoals bijvoorbeeld voor authenticatie. MA5
Controleer op aansluitvoorwaarden In het geval van niet openbare gegevens controleren applicaties of er aan een minimale set aansluitwaarden voldaan is voordat ze (mogen) aanloggen op de gegevensdiensten. Dit geldt ook voor het betreffende besturingssysteem. Zie CIP (16) eis 2. MA5
Bepaal vooraf de lifecyle- en updatestrategy Zowel de architectuur van de applicatie als de in te regelen ondersteuning en beheer zijn in belangrijke mate afhankelijk van de life-cycle- en updatestrategie. Ook de informatiebeveiligingsrisico’s zijn hieraan gerelateerd.
  • Bepaal de life-cyclestrategie van de applicatie. Is het experiment, een éénmalig product of is het een integraal onderdeel van de gemeentelijke dienstverlening?
  • Bepaald hiermee de ontwikkelstrategie (hardcoded/configurabel, 100% of 80/20, zware invoercontrole, etc.)
  • Richt hier ook de juiste ondersteuning op in en communiceer duidelijk welke ondersteuning verwacht kan worden en hoe lang;
  • Bepaal of er een verplichte updatestrategie is (o.a. vanuit informatiebeveiligingsperspectief) en of oudere versies geblokkeerd worden 16 eis 3];
  • Bepaal of de applicatie eisen stelt aan een up-to-date besturingssysteem en of de applicatie op oudere besturingssystemen geblokkeerd moet worden.
EMR (15),CIP (16) eis 3 (up-to-date apps)
Scheiding gebruikersinterface en data en business logica De gebruikersinterface wordt gescheiden van data en business logica en gekoppeld via open standaarden. Light-weight userinterfaces hebben de voorkeur. De business logica en data worden waar mogelijk geïntegreerd in gemeentelijke informatiediensten.
  • De modules en koppelingen tussen de modules worden ‘fail-safe’ ontworpen. In het bijzonder is het niet beschikbaar kunnen zijn van andere modules en diensten een uitgangspunt (zie ook MA1: design for failure);
Apps gebruiken alleen vertrouwde broncode bibliotheken van derden (16) eis 5)
GEMMA principe 5, 6 en 7.
Deelfunctionaliteiten worden in (herbruikbare) modules ontwikkeld GEMMA principe 5, 6 en 7.
De modules en koppelingen tussen de modules worden ‘fail-safe’ ontworpen. In het bijzonder iMA1s het niet beschikbaar kunnen zijn van andere modules en diensten een uitgangspunt. MA1

Een belangrijk vraagstuk is hoe de gemeenten de kwaliteit van applicaties – en hierin de beveiliging in het bijzonder – kunnen borgen (zie ook de eerste vraag van het GPO in hoofdstuk 1). Zeker gezien de visie dat de applicatieontwikkeling aan de markt wordt overgelaten. Om deze vraag te beantwoorden moeten onderscheid gemaakt worden tussen drie soorten applicatiegroepen:

  1. Applicaties die gebruik maken vrij beschikbare data en/of informatiediensten; Voor deze categorie mobiele applicaties kan de gemeente weinig tot geen eisen stellen aan de kwaliteit van de applicatie en gezien de wens om de markt hier vrij te laten is het ook de vraag of dit wenselijk is.
  2. Applicaties die ontwikkeld worden in opdracht van de gemeente en waar het eigenaarschap bij de gemeente ligt; Voor deze categorie applicaties is de gemeente opdrachtgever en eigenaar en heeft een verantwoordelijkheid de kwaliteit te borgen. Als basis hiervoor kan dit katern en de gerelateerde stukken gebruikt worden.
  3. Applicaties die gebruik maken niet vrij beschikbare informatiediensten – dus met minimaal een vorm van autorisatie. Voor deze categorie applicaties is het moeilijk om invloed op de kwaliteit van de applicatie zelf uit te oefenen. Wel is sturing op het juiste gebruik van de informatiediensten mogelijk. Hiervoor kunnen leveringsafspraken gemaakt worden en kan er op de naleving gestuurd worden.

Een ander instrument is het gebruik van een app-store. Bij de rijksdiensten er is bijvoorbeeld een rijksapp-store beschikbaar waarin alleen apps worden opgenomen die aan bepaalde voorwaarden voldoen. Ook voor de gemeenten kan er een app-store opgezet worden of de gemeenten kunnen aansluiten bij een bestaande app-store van de overheid. KING heeft aangegeven hier niet de juiste organisatie voor te zijn. Merk overigens op dat hiermee alleen de native apps geraakt worden.

Besturingssysteem

Voor elke toepassing moet expliciet bekeken worden welke besturingssystemen ondersteund worden. Dit geldt niet alleen voor native applicaties, maar ook voor webapplicaties. Elk besturingssysteem heeft zijn eigen specifieke kenmerken, maar ook de gebruikte browsers op dit besturingssysteem hebben hun eigen specifieke kenmerken. Er kan niet van uitgegaan worden dat een webapplicatie op elke browser werkt.

Bij het vaststellen welke besturingssystemen ondersteund moeten gaan worden spelen (minimaal) de volgende afwegingen mee:

  1. Welke voorkeuren heeft de gebruiker (principe MA 4)?
  2. Wat zijn de kosten en baten (in termen van aansluiting bij de gebruikersvraag) voor het ondersteunen van welke platformen. In (15) wordt een indicatie gegeven van het gebruik van mobiele platformen in Q3-2016:
    • Android 87%
    • iOS 12,5%
    • Windows 0,3%
    • Overig 0,4%
  3. Zijn er specifieke beveiligingsrisico’s voor een bepaald besturingssysteem?

Mobiel apparaat

Bij deze keuze voor een mobiel apparaat spelen min of meer dezelfde afwegingen als voor het mobiele besturingssysteem. Daarnaast spelen ook zaken als:

  1. Smartphone of tablet? In het bijzonder spelen hier de omvang van het scherm en de performance eisen mee.
  2. Gaat het om incidenteel gebruik of structureel gebruik? Een mobiel apparaat mag in geen geval als vervanger van de werkplek apparatuur gezien worden, mede vanwege de Arbowetgeving.

Internet

De mobiele applicaties worden via het internet gekoppeld aan de informatiebronnen. In sommige gevallen gaat het om publieke gegevens maar soms ook over gevoelige gegevens. Principe MA5.1 stelt dat de dataclassificatie bepaald welke beveiligingsmaatregelen er nodig zijn. Mogelijke maatregelen zijn:

  • Het versleutelen van het berichtenverkeer;
  • Alleen veilige, afgeschermde WiFi-netwerken gebruiken;
  • Alleen internet via 4G toestaan (en geen WiFi);
  • Etc.

Ook moet er rekening mee gehouden worden dat de internetverbinding regelmatig weg kan vallen. Dit houdt in dat er maatregelen genomen moeten worden om (zie principe GEMMA-principe 5):

  • De stabiele werking van de applicatie te kunnen blijven garanderen bij het (tijdelijk) wegvallen van de internetverbinding;
  • Gegevens transactioneel worden bijgewerkt om data consistentie te garanderen;
  • De applicatie herstartbaar is in een stabiele toestand.

Dezelfde eisen gelden voor het ‘wegvallen van de verbinding’ doordat de batterij van het mobiele apparaat leeg is.

Generieke informatiebronnen

De volgende groepen generieke informatiebronnen worden onderscheiden:

  1. Basisregistraties;
  2. Gemeentelijke (open) datadiensten;
  3. Overige publieke informatiebronnen van de overheid
  4. Private informatiebronnen.

De generieke informatiebronnen zijn om een aantal redenen belangrijk. Enerzijds stelt de NORA dat de geleverde dienst via de verschillende kanalen hetzelfde resultaat heeft (NORA AP11) anderzijds zijn er veel principes die het gebruik van standaarden en herbruikbare componenten promoten (AP06, AP07, AS08, GEMMA-principe 5 en MA6). Voordelen zijn onder meer (niet limitatief):

  • Schaalvoordeel bij de ontwikkeling van toepassingen;
  • Verkorten ontwikkeltijden (o.a. door hergebruik van interfaces en functies hierop);
  • Gegevensportabiliteit (bij migraties, overdracht tussen gemeenten onderling, etc.);
  • Betere kwaliteit;
  • Vereenvoudiging gegevensuitwisseling tussen gemeentelijke afdelingen, gemeenten onderling en ketenparters;
  • Etc.

Basisregistraties

Het stelsel van Nederlandse basisregistraties is volledig beschreven en zal in dit katern niet verder uitgewerkt worden. Een goede ingang voor meer informatie is (21).

Gemeentelijke (open) databronnen

Qua gegevensstandaarden kent KING twee gegevenssets die via gestandaardiseerde koppelvlakken ontsloten kunnen worden:

  • Basisregistraties, conform het RSGB (25)
  • Zakendiensten, conform het RGBZ (26)
  • Zaaktypen, conform het ImZTC (27)

Voor ontsluiting van sectorale gegevens zijn geen berichtstandaarden beschikbaar.

Berichtenstandaarden

De gegevensdiensten die door KING worden ondersteund zijn gebaseerd op StUF-berichten (soap/XML). Voor mobiele applicaties is het gebruik van soap/ XML, mede door de grote overhead van gegevens die overgedragen worden met XML niet aan te raden. Bij mobiele applicaties is het gebruik van rest/json koppelingen gebruikelijk. Door KING zijn i.c.m. de gemeente Den Haag de eerste stappen gezet op het vlak van JSON (19). Vanuit de omgevingswet, en dan specifiek het DSO, is een API-strategie opgesteld die specifiek gaat over de wijze van toepassing van REST [20]/JSON. Adoptie van deze API-strategie door KING is in het kader van de standaardisatie van berichtuitwisseling in de overheid gewenst.

Gemeentelijke API-strategie

Mobiele applicaties nemen gegevens van de gemeente af via Application Programming Interfaces ofwel APIs. Een API is een gebruikersinterface voor ontwikkelaars – hiervoor geldt, zoals bij elke gebruikersinterface, dat het belangrijk is dat de gebruikerservaring goed doordacht is. Deze gebruikerservaring dient ook, ongeacht de gemeente die een API aanbiedt, identiek te zijn. Vanuit het oogpunt van een ontwikkelaar zouden alle gemeenten een uniforme API-strategie moeten hanteren en ook identieke APIs bieden. Om dit te bereiken wordt vanuit KING gewerkt aan een kaderstellende gemeentelijke API-strategie. Deze API-strategie gaat uit van een API-first strategie. Dit betekent dat de API ontworpen en gebouwd wordt onafhankelijk van de front-end(s) waarin deze gebruikt wordt. Een API is hiermee een product op zichzelf. Een API moet elk kanaal kunnen bedienen en niet één specifiek kanaal. Dit wil niet zeggen dat de API los van de werkelijkheid wordt ontwikkeld. Er wordt afgestemd met de verschillende partijen en hun input wordt gebruikt bij het ontwikkelen, beheren en onderhouden. Een API is een combinatie van het koppelvlak, documentatie en andere ondersteunde hulpmiddelen.

Onderdeel van de API-strategie is een segmentering naar interactiepatronen. Voorbeelden van interactiepatronen zijn vraag-antwoord, synchronisatie, levering en transactionele interacties. Per interactiepatroon worden kaders opgesteld die gelden voor de APIs die binnen dat interactiepatroon gehanteerd worden. Te denken valt hierbij aan kaders en richtlijnen ten aanzien van architectuurconcepten (SOAP/WSDL, REST) en berichtstandaarden (XML, StUF, JSON).

De gemeentelijke API-strategie wordt door KING in samenwerking met het Digitaal Stelsel Omgevingswet (DSO) ontwikkeld. Doel is te komen tot een landelijk geldende overheid API-strategie, of als dat een brug te ver is een gemeentelijke API-strategie die in lijn is met de API-strategie van het DSO.

(24) Beschrijft een aantal afwegingen ten aanzien van gebruiksvriendelijkheid versus beveiliging bij mobiele interfaces. Ook wordt hierin de standaard OAuth 2.0 beschreven die op de PTOLU lijst in de lijst van te onderzoeken standaarden staat. Deze staat nog voor de introductie van deze standaard on-hold tot een toepassingsprofiel voor de Nederlandse overheid is gedefinieerd. De authenticatie (SAML) en de autorisatie (OAuth/OpenID connect) aspecten van mobiele applicaties zijn goede kandidaten om later in de architectuur op te nemen.

Overige publieke databronnen

Deze worden in dit katern niet nader beschreven.

Private informatiebronnen

Deze worden in dit katern niet nader beschreven.

Bronsystemen

Dit zijn de achterliggende gemeentelijke informatiesystemen. Voor de scope van deze architectuur is hun enige functie het zorgen dat de generieke informatiediensten de juiste informatie hebben.

Informatiebeveiliging

Mobiele apparaten en platform

Voor de beveiliging van mobiele apparaten moeten wordt een tweedeling gemaakt. Enerzijds hebben zijn er de mobiele apparaten van afnemers van de gemeentelijke diensten (inwoners, ondernemers en ketenpartners). En anderzijds de eigen medewerkers. Voor de afnemers van de gemeentelijke diensten is er weinig invloed uit te oefenen welke mobiele apparaten gebruikt worden en welke beveiligingsmaatregelen ze zelf dienen te gebruiken. Stuurmiddelen op dit gebied beperken zich tot ondersteuning in de bewustwording (principe MA2) en eventueel het softwarematig beperken van de type mobiele apparaten. Voor de eigen medewerkers zou een CYOD-beleid gevoerd kunnen worden. Dit geeft de mogelijkheid om mobile device management (MDM) technieken te gebruiken om updates, beveiligingsinstellingen, etc. af te dwingen (principe MA6.5). In de praktijk zal er echter een groei naar BYOD plaatsvinden (principe GEMMA-principe 5).

Mobiele applicaties

De beveiliging van de applicaties zelf valt formeel buiten de scope van dit katern. Dit is echter wel een belangrijk onderdeel in de keten van beveiligingsmaatregelen. Het CIP (16) geeft een uitgebreide baseline met beveiligingseisen aan mobiele applicaties en wordt sterk aanbevolen om als basis te gebruiken.

Mobiele informatiediensten

Mobiele informatiediensten van de gemeente worden ontwikkeld volgens de geldende (gemeentelijke) richtlijnen uit onder meer de GEMMA [09] en de BIG [22]. De gebruikte integratiearchitectuur staat beschreven in (18). Dit alles borgt dat de gemeentelijke informatie die wordt aangeboden aan publieke maar ook interne mobiele applicaties voldoende beveiligd is tot en met het niveau van connectie. Hiervoor worden de standaard authorisatiemechanismen gebruikt die hiervoor beschikbaar zijn (principe MA5.2).




Bestaande architecturen

Overzicht

Het onderstaande figuur geeft een overzicht van de relaties tussen de verschillende architecturen die zijn gebruikt bij het opstellen van dit katern.

Overzicht gebruikte architecturen.png

Figuur 6: Overzicht gebruikte architecturen

Het onderstaande model geeft een indicatie van het bereik van de verschillende architecturen verspreid over twee assen: welke doelgroepen richt deze architectuur zich op en richt de architectuur zich op de bestuurlijke-, informatie- en/of technische aspecten? de doelgroep(en) en het bestuurlijk/technisch aspect. Zo richt de mobiele architectuur van EZ zich primair op de ambtenaar op het informatie en technische vlak. Dit katern richt zich op alle doelgroepen en primair op het informatievlak en in mindere mate op het bestuurlijke en technische vlak.

Bereik en scope gebruikte architecturen.png

Figuur 7: Bereik & scope gebruikte architecturen

NORA

De NORA kent een aantal basisprincipes die het beleid van de Nederlandse Overheid verwoorden in richtinggevende uitspraken voor het inrichten van de informatiehuishouding van overheidsorganisaties. Op deze basisprincipes zijn afgeleide principes gedefinieerd die hier dieper op in gaan. Deze principes geven ook richting aan de ontwikkelingen op het gebied van mobiele applicaties. Uit het Overheids Mobility Overleg (OMO) blijkt dat deze principes ook passen in de ‘mobiele’ wereld maar dat er op sommige vlakken aanscherpingen en actualiseringen nodig zijn. In (12) zijn deze bevindingen uitgewerkt. In deze paragraaf worden de belangrijkste constateringen kort genoemd en verder uitgewerkt in de architectuurkaders.

  • Er moet sprake zijn van een volledige integratie van de klassieke en moderne technologie en werkwijzen. De mobiele wereld is geen losstaand fenomeen maar een ontwikkeling in het geheel. [Dit punt is opgenomen in principe GEMMA-principe 1]
  • Innovatie is een continu proces. Deze architectuur beschrijft de aspecten van de mobiele wereld binnen de gemeentelijke architectuur, maar zowel veranderingen in de mobiele wereld als andere ontwikkelingen vinden continue plaats. De architectuur dient dus uit te gaan van continue innovatie en verandering. Dit punt is opgenomen in GEMMA-principe 6 en 7, principe MA6 en de applicatierichtlijnen.
  • Werken met mobiel – het ondersteunen van eigen medewerkers in hun werk met mobiele voorzieningen is een prominent actiepunt op de agenda’s geworden.
  • Er is (meer) ruimte voor trial en error nodig om tot collectieve oplossingen te komen. De kennis en zeker ervaring en inzichten met mobiele technologie zijn beperkt. Om tot betere inzichten te komen is er ruimte nodig om te experimenteren (dit volgt ook uit de behoefte aan innovatie). (Dit punt is opgenomen in principe MA6 en applicatierichtlijnen).
  • Leren omgaan met publiek-private clouddiensten. Dit aspect is breder dan mobiel alleen, maar speelt uiteraard ook hier. Clouddiensten zullen een steeds belangrijkere plek in de gemeentelijke dienstverlening innemen. De gemeenten moeten echter voor kwaliteit garant staan en de regie blijven houden op deze diensten.
  • Ook de ontvanger of gebruiker van een (mobiele) dienst draagt verantwoordelijkheid. In de praktijk ligt de zwakste schakel hier, maar bewustwording en mitigerende maatregelen aan de andere kant – die van de gemeente – zijn ook nodig. (Dit punt is opgenomen in principe MA5).

De eisen van mobility aan de informatiehuishouding van de overheid kunnen worden samengevat als (zie 12): het voorbereid zijn op onvoorzien gebruik van gegevens en diensten. Dit onderstreept zowel de kansen als de risico’s van het mobiele kanaal in het multi-, cross- of omni-channel scenario van (gemeentelijke) informatie en informatiediensten.

GEMMA

De GEMMA kent net als de NORA een aantal overkoepelende principes die ook toepasbaar zijn in de mobiele wereld. Maar ook hier is een verbijzondering nodig voor de mobiele context. Dit katern gaat daar specifiek op in.

IBD/BIG (22)

De informatiebeveiligingsdienst (IBD) van de VNG en KING is de sectorale CERT / CSIRT voor alle Nederlandse gemeenten en richt zich op de (incident) ondersteuning op het gebied van informatiebeveiliging. De IBD beheert de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG 22). Deze BIG geldt ook voor de mobiele architectuur en uitwerking hiervan binnen de gemeenten. Relevante onderdelen van de BIG zijn in dit katern opgenomen of wordt naar gerefereerd. Dit gebeurt soms direct, of indirect via architectuurprincipes, of via gerelateerde bronnen als het CIP (16).

Enterprise Architecture Rijksdiensten (01)

Enterprise Mobility Rijksoverheid (10, 14, 15)

De Enterprise Mobility Rijksoverheid (EMR) beschrijft “de manier waarop ICT-leveranciers de rijksmedewerkers faciliteren in de mogelijkheden om met een overwogen, flexibele en mobiele insteek hun werk te doen.”. De focus ligt dus op mobiele toepassingen van medewerkers van het Rijk (zie ook Bereik & scope gebruikte architecturen) maar veel concepten zijn ook in bredere zin (her)bruikbaar. De basis wordt gevormd door een visiedocument (10) uit 2013. Op basis hiervan zijn in een 2016 concretere handreikingen geschreven (14). Veel concepten en principes uit deze architectuur zijn in dit katern overgenomen. Vanuit de EMR is ook een handreiking voor app-ontwikkeling en -beheer geschreven (15). Dit valt deels buiten de scope van dit katern, maar het is een goede referentie om te gebruiken bij app ontwikkelings- en beheerkaders. Merk op dat in de context van EMR ook laptops als mobiele apparaten worden gezien – dit verschilt met de visie in dit katern.

Als voorwaarden voor succes worden de onderstaande punten genoemd die ook in de huidige context onverminderd van kracht blijven:

  • Niet alles zelf regelen;
  • Buiten de gebaande paden bewegen;
  • Alignment binnen het Rijk - voor de gemeenten is alignment binnen de gemeenten én met de ketenpartners essentieel (dit katern sluit zoveel mogelijk aan bij bestaande architecturen binnen de overheid);
  • Ability to execute;
  • Inzicht in de toegevoegde waarde – wat het belang van experimenten en innovatie in het gemeentelijk domein onderschrijft;
  • Werken vanuit een (veilige) architectuur (dit katern – en de architecturen waar dit katern op voortbouwt – draagt hier aan bij).

Een deel van de principes uit de EMR zijn, al dan niet verbijzonderd, aan het gemeentelijk domein en in de architectuur opgenomen.

Referentiearchitectuur mobiele applicaties voor EZ (06)

De referentiearchitectuur voor mobiele applicaties van EZ is een relatief nieuwe architectuur waarvan veel elementen hergebruikt kunnen worden voor dit katern voor de GEMMA. Uit deze architectuur zijn een aantal principes, de classificatie van soorten mobiele applicaties en een beslisboom om hier een keuze in te kunnen maken overgenomen. De architectuur van EZ gaat ook dieper in op (de keuzes in) gebruikte technologieën. Dit katern zal dat niet doen. De architectuur van EZ kan echter wel gebruikt worden voor een verdere verdieping in deze technologieën.

Overig

Digitale overheid: maak het waar!

In het rapport ‘Digitale overheid: maak het waar!’ (28) staan een aantal fundamentele veranderingen die een sterke relatie hebben tot de mobiele architectuur. De punten worden hier slechts aangehaald, zie voor een gedetailleerde beschrijving het rapport;

  • Er is een radicale omkering van houding nodig: van ‘first time right’ naar ‘permanent bèta’;
  • Overheidsorganisaties zelf, tot in de kern van hun (primaire) processen, moeten ICT begrijpen, regisseren en, zonder afhankelijkheid van private partijen, ook kúnnen uitvoeren;
  • Digitale dienstverlening moet het niveau van websites en digitale formulieren voorbij en proactief worden georganiseerd rond behoeften van burgers en bedrijven;
  • Bewindslieden en bestuurders moeten zich realiseren dat ICT en digitalisering kern zijn van hun (primaire) processen.

Centrum voor Informatiebeveiliging en Privacybescherming

Het Centrum voor Informatiebeveiliging en Privacybescherming (CIP) heeft een set met beveiligingseisen voor mobile apps (16) opgesteld. De beveiligingseisen richten zich op native en hybride apps, primair op de front-end en voor interne medewerkers. Echter, veel elementen zijn ook in de bredere context van dit katern goed bruikbaar en opgenomen bij de principes en mobiele architectuur.




Architectuurprincipes

Inleiding

Architectuurprincipes zijn richtinggevende uitspraken, op basis van strategie, beleid of bijvoorbeeld wetgeving. Door veranderingen of vraagstukken te toetsen aan deze architectuurprincipes kan getoetst worden of de oplosrichting van veranderingen conform het beleid van de strategie van de verandering is of – waar noodzakelijk – dat hier bewust en weloverwogen van afgeweken wordt. Dit wordt ‘pas toe of leg uit’ genoemd’.

Architectuurprincipes worden omschreven door een krachtig, makkelijk te onthouden ‘statement’, een rationale (waarom is dit principe belangrijk?), implicaties (wat betekent dit nu concreet, wat zijn de gevolgen, waar moet rekening mee gehouden worden?) en een bronvermelding waar nodig.

In zowel overkoepelende referentiearchitecturen (NORA en GEMMA) als zusterarchitecturen (VeRa) zijn reeds de nodige architectuurprincipes gedefinieerd die in dit domein (her)gebruikt kunnen worden (zie Figuur 6). Daarnaast zijn er aanvullende principes, specifiek voor het domein openbare orde en veiligheid, die volledig beschreven worden.

Nederlandse Overheid Referentie Architectuur (NORA)

De NORA is de basisreferentiearchitectuur voor alle overheidsorganisaties. Dochterarchitecturen voor specifieke overheidsdomeinen, zoals de GEMMA, bouwen hierop voort voor hun specifieke domein. Alleen de principes die raakvlakken hebben met het mobiele domein zijn opgenomen. In de ‘dochterarchitectuur’ GEMMA wordt waar van toepassing een verbijzondering voor gemeenten van de NORA-principes gemaakt. Evenzo worden sommige NORA en GEMMA-principes verbijzonderd in principes die specifiek voor het mobiele domein zijn. De onderstaande tabel geeft een samenvatting van de – voor dit katern – relevante NORA-basisprincipes en de hierop voortbouwende NORA afgeleide principes. Details over deze principes zijn opgenomen in de bijlage relevante NORA principes en in de noraonline (via de hyperlinks).

NORA basis principe NORA afgeleid principe Statement
BP01 Afnemers krijgen de dienstverlening waar ze behoefte aan hebben (proactief)
AP20 Persoonlijke benadering
BP03 Afnemers hebben eenvoudig toegang tot de dienst (vindbaar)
AP09 Voorkeurskanaal internet
AP10 Aanvullend kanaal
AP11 Gelijkwaardig resultaat ongeacht kanaal
AP18 Ruimtelijke informatie via locatie
AP20 Persoonlijke benadering
BP04 Afnemers ervaren uniformiteit in de dienstverlening door het gebruik van standaardoplossingen (standaard)
AP06 Gebruik standaard oplossingen
AP07 Gebruik de landelijke bouwstenen
AP08 Gebruik open standaarden
BP08 Afnemers kunnen erop vertrouwen dat informatie niet wordt misbruikt (vertrouwelijk)
AP37 Identificatie authenticatie en autorisatie
AP39 Controle op juistheid volledigheid en tijdigheid
BP09 Afnemers kunnen erop vertrouwen dat de dienstverlener zich aan afspraken houdt (betrouwbaar)
AP11 Gelijkwaardig resultaat ongeacht kanaal
AP36 Uitgangssituatie herstellen
AP39 Controle op juistheid volledigheid en tijdigheid
AP40 Uitwisseling berichten onweerlegbaar

Het mobiele kanaal maak diensten eenvoudig beschikbaar (BP03) en maakt een laagdrempelige, persoonlijke en proactieve dienstverlening beter mogelijk (BP01, AP20). Een gestandaardiseerd, en door gestandaardiseerde APIs ontsloten, gegevenslandschap is een fundamentele bouwsteen voor het mobiele kanaal (BP04, AP06, AP07, AP08) om het internet kanaal beter te benutten (AP09) maar ook om dezelfde dienstverlening via een aanvullend kanaal (AP10) met dezelfde resultaten te garanderen (AP11). Mobiele apparaten zijn ook bij uitstek geschikt om de toegevoegde waarde van het werken op basis van geo-locatie te benutten (AP18). Uitgangspunt is dat mobiele applicaties, de mobiele devices en de gebruikte netwerkverbindingen onveilig en onbetrouwbaar zijn. Er moet in het mobiele domein dan ook specifiek meer aandacht besteed worden aan de informatiebeveiliging (BP08, AP37) en juistheid van de informatie en transacties (BP08, AP39, BP09, AP36, AP40).

Gemeentelijke model architectuur (GEMMA)

De principes uit de gemeentelijke referentiearchitectuur zijn een verbijzondering en aanvulling op de principes uit de overheid referentiearchitectuur die specifiek voor gemeenten zijn. De onderstaande tabel geeft een samenvatting van de GEMMA-principes en – de voor dit katern – relevante bovenliggende NORA-principes. Daar waar van toepassing worden implicaties genoemd die specifiek zijn voor het mobiele domein of bijzonder van belang in mobiele domein.

GEMMA-principeNORA-principe referentieStatement
1BP01, BP02, BP03, BP04, BP05, BP06Onze gemeente denkt vanuit de positie van de klant
2BP04Onze gemeente gebruikt generieke processen en functies
4BP01, BP02, BP03, BP06, BP10, AP14Onze gemeente biedt de klant een goede informatiepositie
5BP03Onze gemeente digitaliseert haar diensten en processen
6BP06, AP08Onze gemeente stelt openbare gegevens als open data beschikbaar
7BP07Onze gemeente hergebruikt gegevens
8BP08Onze gemeente gaat op een vertrouwelijke manier met gegevens om
GEMMA principe 1 Onze gemeente denkt vanuit de positie van de klant
Bron https://www.gemmaonline.nl/index.php/Overzicht_GEMMA_Architectuurprincipes, NORA BP01, BP02, BP03, BP04, BP05, BP06
Opmerkingen Het mobiele kanaal helpt om de klant beter van informatie te kunnen voorzien. Continue innovatie op dit gebied is essentieel. Het mobiele kanaal moet hierbij niet als een losse technologie gezien worden, maar als integraal onderdeel van het gehele pallet van middelen waarmee de gemeente haar klanten van informatie voorziet (zie 12).


GEMMA principe 2 Onze gemeente gebruikt generieke processen en functies
Bron https://www.gemmaonline.nl/index.php/Overzicht_GEMMA_Architectuurprincipes, NORA BP04
Opmerkingen In het verlengde van de generieke processen en functies moeten ook de informatiediensten die hier voor nodig zijn gestandaardiseerd worden. Alleen dan kunnen gemeentes en marktpartijen samen applicaties ontwikkelen die breder toepasbaar zijn dan één enkele gemeente voor één enkel doel.


GEMMA principe 4 Onze gemeente biedt de klant een goede informatiepositie
Bron https://www.gemmaonline.nl/index.php/Overzicht_GEMMA_Architectuurprincipes, NORA BP01, BP02, BP03, BP06, BP10, AP14
Opmerkingen Mobiele applicaties helpen om de klant inzicht te geven in de gegevens die van de klant geregistreerd staan bij de gemeente. Dit geeft de klant een middel om fouten in deze registraties te signalen en hier actie op te laten ondernemen. Ook de gemeente heeft hier baat bij omdat dit resulteert in een hoger kwaliteitsniveau van de registraties.


GEMMA principe 5 Onze gemeente digitaliseert haar diensten en processen
Bron https://www.gemmaonline.nl/index.php/Overzicht_GEMMA_Architectuurprincipes, NORA BP03
Opmerkingen Dit is een expliciete ambitie van de overheid. Ook verlaagt dit de uitvoeringskosten en doorlooptijden van processen en reduceert dit de kans op fouten. Dit stelt – zowel impliciet als expliciet – eisen aan de kwaliteitsaspecten van de informatiehuishouding zoals beschikbaarheid, vertrouwelijkheid, etc. En hoewel het streven is om maximaal te digitaliseren moet er ook rekening houden worden met klanten die niet digitaal werken.

Implicaties Diensten zijn altijd, overal en op ieder apparaat beschikbaar:

  • Er moet een juiste aansluiting met de kanaalstrategie zijn, een cross- en omni-channel ondersteunt dit beter;
  • Er zal gekozen moeten worden voor oplossingen die op een breed scala aan mobiele apparaten werkt;
  • Dit vereist een goede beschikbaarheid 24x7 van de achterliggende informatiediensten;
  • Ook zal er een keuze gemaakt moeten worden wat te doen met ondersteuning buiten kantoortijden voor zowel technische als functionele ondersteuning.


Ga uit van BYOD:

  • Voor de meeste doelgroepen is Bring Your Own Device (BYOD) geen vraag maar een feit – ga hier dan ook van uit;
  • Voor eigen medewerkers zal er een beleid gemaakt moeten worden. Choose Your Own Device (CYOD) heeft veelal de voorkeur, maar of dit te realiseren is, is de vraag – medewerkers gebruiker ook steeds vaker eigen apparaten;
  • Eventueel kan er gestuurd worden door een keuze gemaakt worden welke besturingssystemen en/of browsers ondersteund worden.
Zie ook EAR (Altijd, Overal, ieder apparaat)

EMR principe 17 (voorkeur BYOD tenzij…)
EZ principe 1 (any time, any place, anywhere)

EZ principe 3 (BYO)


GEMMA principe 6 Onze gemeente stelt openbare gegevens als open data beschikbaar
Bron https://www.gemmaonline.nl/index.php/Overzicht_GEMMA_Architectuurprincipes, NORA BP06, AP08
Opmerkingen Het standaardiseren en beschikbaar stellen van (zowel open als niet-open) data vormt de basis voor een goede mobiele architectuur. De mobiele architectuur bouwt immers op het beschikbaar zijn van gestandaardiseerde API’s die de connectie vormen met het gemeentelijk en buitengemeentelijk gegevenslandschap (zie Figuur 3).


GEMMA principe 7 Onze gemeente hergebruikt gegevens
Bron https://www.gemmaonline.nl/index.php/Overzicht_GEMMA_Architectuurprincipes, NORA BP07
Opmerkingen Het fundament bij het hergebruik van gegevens ligt in de landelijke basisregistraties, gemeentelijke kernregistraties en kernregistraties in andere domeinen. Door deze via gegevensdiensten te ontsluiten maken niet alleen de gemeentelijke kernsystemen en systemen van partners gebruik van dezelfde gegevens, ook mobiele applicaties maken hier gebruik van. Naast de primaire gegevens worden ook authenticatie- (AP06 en AP07) en voorkeursgegevens hergebruikt (NORA AP20).


GEMMA principe 8 Onze gemeente gaat op een vertrouwelijke manier met gegevens om
Bron https://www.gemmaonline.nl/index.php/Overzicht_GEMMA_Architectuurprincipes, NORA BP08
Opmerkingen Gemeentelijke informatie, waaronder vertrouwelijke informatie, blijft niet binnen het gemeentehuis maar wordt door klanten en medewerkers ook daarbuiten gebuikt. In de mobiele context hebben we veelal te maken met onveilige apparaten en onveilige netwerken. Informatie moet dan ook op basis van de data-classificatie voldoende beveiligd zijn tegen lekken, misbruik, integriteit, etc..


Bijzondere principes architectuur mobiele applicaties

De onderstaande principes zijn door de werkgroep onderkend als specifiek voor mobiele applicaties. Sommige principes bouwen voort op, of zijn een verbijzondering van een breder of abstracter principe. Deze principes staan onder het hoofdprincipe en zijn iets ingesprongen, zie de onderstaande ‘hark’.

Overzicht:

IDMobiel / EMR
MA1Design for failure
MA2Besteed continue aandacht aan kennisontwikkeling en bewustwording voor het mobiele kanaal.
MA3De inrichting van het mobiele kanaal sluit aan op de kanaalstrategie van de gemeente
MA4Mobiele oplossingen passen binnen de verwachtingen van de eindgebruikers
MA5De mobiele werkplek is onveilig
MA5.1De beveiligingsmaatregelen worden geïmplementeerd op basis van de data classificatie
MA5.2 Applicaties maken gebruik van bestaande autorisatie mechanismen.
MA6Ga uit van continue verandering
MA6.1Data staat centraal in de mobiele architectuur
MA6.2 Maak ruimte voor innoveren en experimenten



Sjabloon:ToonTabelVoorMobielPrincipe

Sjabloon:ToonTabelVoorMobielPrincipe

Sjabloon:ToonTabelVoorMobielPrincipe

Sjabloon:ToonTabelVoorMobielPrincipe

Sjabloon:ToonTabelVoorMobielPrincipe

Sjabloon:ToonTabelVoorMobielPrincipe

Sjabloon:ToonTabelVoorMobielPrincipe

Sjabloon:ToonTabelVoorMobielPrincipe

Sjabloon:ToonTabelVoorMobielPrincipe

Sjabloon:ToonTabelVoorMobielPrincipe




Bijlage (actuele) voorbeelden

Voorbeelden uit het gemeentelijk domein

Inwonercloud – gemeente Woerden

Doel

Inwoners zelf maximaal regie geven over hun proces en hun gegevens in het sociaal domein (5).

Focus

Sociaal domein

Kansen

  • Inwoners zelf meer regie geven over hun zaak;
  • Verhogen van de klantgerichtheid;
  • Meer mogelijkheden voor online samenwerkingsvormen;
  • Transparantie over de lopende processen en gegevens voor de inwoners;
  • Verlichten administratieve last voor zowel de gemeente als de inwoners.

Huidige knelpunten

  • Er is een veelheid aan apps, maar door een gebrek aan integraliteit en centrale authenticatie zijn het losse functionaliteiten in plaats van geïntegreerde voorzieningen;
  • Professionals ervaren een administratieve last omdat deze apps niet verbonden zijn met de gemeentelijke systemen (zoals het zaaksysteem);
  • Met meerdere apps moeten werken – onder andere omdat de achterliggende systemen niet gekoppeld zijn;
  • Onvoldoende borging ten aanzien van beveiliging en privacy;
  • Taak- en specifieke gemeentelijke systemen zijn niet geschikt om met (interactieve) apps te werken.

Concrete behoeftes

  • Een keurmerk voor apps (privacy, beveiliging, e.a.);
  • Een mogelijkheid om eenvoudig en snel de juiste apps te vinden (bijv. via een AppStore);
  • Standaardisatie voor koppelingen tussen de gemeentelijke informatievoorziening en apps (bijv. de koppeling met zaaksystemen);
  • Samenwerking met gelijksoortige en gerelateerde initiatieven;
  • Samenwerking tussen apps onderling door bijv. up- en download functionaliteiten tussen apps (concrete feedback over het gebruik van de huidige apps);
  • Het maken van afspraken via apps met verschillende instanties;
  • Het verschaffen van inzicht aan inwoners over lopende processen;
  • Het aanleveren van informatie door inwoners voor het aanvragen van gemeentelijke diensten;
  • Het kunnen leveren van extra informatie en diensten (o.a. door mobiele innovaties);
  • Hoe kunnen we koppelingen mogelijk maken en opschalingspotentie vergroten?
  • Wat is de impact van apps op bedrijfsvoering?

Referenties

4, 5

Nationaal Parkeerregister

Het Nationaal Parkeer Register (NPR) is een landelijke database, beheerd door de RDW, waarin alle actuele parkeerrechten op kenteken geregistreerd staan. De brongegevens in het register worden door gemeenten geleverd via het Servicehuis Parkeer-en Verblijfsrechten (SPHV). Verschillende afnemers (leveranciers van mobiele diensten) kunnen gebruik maken van de gegevens die in het NPR zijn opgeslagen. Het NPR is een centrale, generieke gegevensdienst die gemeentelijke informatie aanbiedt aan markpartijen om daarmee diensten richting de inwoners te kunnen leveren. Het opzetten van het NPR heeft veel voeten in de aarde gehad, maar het leveren van deze dienst wordt inmiddels als ‘vanzelfsprekend’ ervaren. De sleutel van het succes van deze dienst ligt in de standaardisatie van de dienst en de standaardisatie van gegevens (open data).

Kenmerken van het NPR zijn

  • het faciliteren van mobiel parkeren via alle parkeerproviders;
  • het registreren van vergunningen en parkeerrechten via de parkeerautomaat;
  • het verzamelen en publiceren van openbare informatie en tarieven over parkeergebieden en –tarieven;
  • het registreren van gehandicaptenparkeerkaarten;
  • het mogelijk maken van digitale parkeerhandhaving;
  • Publiceren Open Parkeerdata (statisch en dynamisch).

Waarom het NPR? De voordelen van deze dienst zijn

  • De mogelijkheid voor gedifferentieerde parkeertarieven;
  • Er wordt alleen betaald voor daadwerkelijk geparkeerde tijd;
  • De parkeerhandhaving kan veel efficiënter worden ingericht;
  • Gemeenten hoeven niet langer te onderhandelen met verschillende providers;
  • Een gezamenlijke infrastructuur; - bestaande uit het gemeentelijk domein en een extern domein.
  • Een gezamenlijke infrastructuur (bestaande uit het gemeentelijk domein en het buitengemeentelijk domein op basis van een centrale registratie die de domeinen samenvoegt);
  • Mobiel parkeren wordt voor iedereen gemakkelijker.

Architectuur NPR.png
Figuur 8: Architectuur NPR

Meld een vermoeden

Een belangrijke factor in het succes van een veiligheidsinformatieknooppunt is het genereren van signalen. Enerzijds komen deze signalen vanuit de BI-oplossing maar een ander belangrijk deel moet vanuit het veld komen via de terugmelding op vermoedens tot fouten in de basisregistraties en signalen van onder meer fraude en ondermijning. Hoewel de terugmelding een wettelijke verplichting is, is niet elke medewerker zich hiervan bewust en zelfs indien ze hiervan bewust zijn is er een behoorlijke drempel om dit alsnog te melden. Denk bijvoorbeeld aan een politieagent die constateert dat een – volgens de registraties – onbewoond pand, toch bewoond blijkt te zijn. De politieagent maakt hier een notitie van en eenmaal terug op kantoor kan hij of zij hier formeel een melding van maken in de systemen. In de praktijk blijkt dit veel te omslachtig waardoor veel signalen verloren gaan.

De gemeente Den Haag heeft in samenwerking met Anti-Fraud Company het ‘Meld een Vermoeden’ platform ontwikkeld (23) waarmee de ketenpartners en gemeenteambtenaren via een app op een smartphone eenvoudig en snel een melding kunnen maken. Eventuele foto’s kunnen direct meegestuurd worden. Meldingen vanuit deze app worden op een centraal systeem bij de gemeente ontvangen van waaruit al dan niet actie ondernomen wordt en de medewerker in het veld automatisch terugkoppeling krijgt. Het effect is dat er meer meldingen gedaan worden - en dus meer signalen voor het veiligheidsinformatieknooppunt – met een minimale extra ‘kantoor’ belasting voor de medewerkers in het veld. Ook is er tussen de gemeente Den Haag en de Politie Den Haag een afspraak dat een melding binnen 48 uur opgepakt wordt en dat de melder in veel gevallen hier terugkoppeling over krijgt via dezelfde app. Het effect van de melding is hierdoor ook zichtbaarder voor melder. Dit verbetert dus ook de integrale samenwerking tussen gemeente en ketenpartners.

Meld een vermoeden platform.png
Figuur 9: Voorbeeld: meld een vermoeden platform

Overige voorbeelden

VoorbeeldURL
Financieel Paspoorthttps://www.gemeente.nu/dienstverlening/overzicht-schuldhulpverlening-financieel-paspoort/
LUCAhttp://www.ad.nl/den-haag/nieuwe-app-helpt-jongeren-als-psychische-nood-te-hoog-wordt~ac9c82ba/
Afvalwijzerhttps://www.addcomm.nl/afvalwijzer
Apps Westerkwartierhttps://www.gemeente.nu/dienstverlening/e-overheid/lancering-winnende-gemeenteapp/
Ongehinderd apphttp://www.ongehinderd.nl/


Voorbeelden uit het publieke domein

Ook zijn er in het publieke domein diverse mobiele applicaties te vinden die gebruikt kunnen worden door de gemeenten. Enerzijds zijn dit apps uit de markt die al dan niet gebruik maken van gemeentelijke informatievoorziening anderzijds zijn dit bijvoorbeeld de sociale media zoals WhatsApp, Twitter, Facebook etc. Deze laatsten vallen buiten de scope van deze architectuur maar vormen wel een potentieel communicatiekanaal van en naar de gemeente met specifieke voor- en nadelen.




Relevante NORA principes

Principe NORA BP01 Afnemers krijgen de dienstverlening waar ze behoefte aan hebben (proactief)
Bron http://noraonline.nl/wiki/Proactief
Opmerkingen Het mobiele kanaal is, voor bepaalde diensten, bij uitstek geschikt om de afnemers laagdrempelig en proactief te informeren. Mobiele oplossingen dragen bij aan dit principe.


Principe NORA AP20 Persoonlijke benadering
Bron http://noraonline.nl/wiki/Persoonlijke_benadering
Opmerkingen Voorkeuren van de afnemers worden onthouden en hergebruikt in mobiele applicaties. Dit geldt voor de applicatie, in de keten (zover mogelijk vanuit privacy beperkingen) en over de kanalen.


Principe NORA BP03 Afnemers hebben eenvoudig toegang tot de dienst (vindbaar)
Bron http://noraonline.nl/wiki/Vindbaar
Opmerkingen Het mobiele kanaal is, voor bepaalde diensten, geschikt om eenvoudig en laagdrempelig toegang tot deze dienst te kunnen krijgen. Mobiele oplossingen dragen bij aan dit principe.


Principe NORA AP09 Voorkeurskanaal internet
Bron http://noraonline.nl/wiki/Voorkeurskanaal_internet
Opmerkingen Afnemers verwachten 24 uur per dag, 7 dagen per week zaken te kunnen afhandelen. Internet maakt het mogelijk om 7/24 diensten te verlenen en informatie te verstrekken.


Principe NORA AP10 Aanvullend kanaal
Bron http://noraonline.nl/wiki/Aanvullend_kanaal
Opmerkingen De dienst kan, behalve via internet, via minimaal één ander kanaal aangevraagd worden. Dit impliceert op z’n minst een multi-channel benadering.


Principe NORA AP11 Gelijkwaardig resultaat ongeacht kanaal
Bron http://noraonline.nl/wiki/Gelijkwaardig_resultaat_ongeacht_kanaal
Opmerkingen Dit stelt eisen aan o.a. het gebruik van dezelfde brongegevens, het synchroniseren van gegevens van de verschillende kanalen etc. Zie voor details de noraonline.


Principe NORA AP18 Ruimtelijke informatie via locatie
Bron http://noraonline.nl/wiki/Ruimtelijke_informatie_via_locatie
Opmerkingen Ruimtelijke informatie wordt locatiegewijs ontsloten. Mobiele apparaten zijn hier bij uitstek geschikt voor.


Principe NORA AP20 Persoonlijke benadering
Bron http://noraonline.nl/wiki/Persoonlijke_benadering
Opmerkingen Voorkeuren van de afnemers worden onthouden en hergebruikt in applicaties. Dit geldt voor de applicatie, in de keten (zover mogelijk vanuit privacy beperkingen) en over de kanalen.


Principe NORA BP04 Afnemers ervaren uniformiteit in de dienstverlening door het gebruik van standaardoplossingen (standaard)
Bron http://noraonline.nl/wiki/Standaard
Opmerkingen Het succes van mobiele initiatieven steunt op primair het gestandaardiseerd beschikbaar stellen van gegevens – zoals via open data – en secundair door het standaardiseren en hergebruiken van mobiele toepassingen door verschillende gemeenten. Standaardisatie is dus randvoorwaardelijk voor het succesvol inzetten van het mobiele kanaal.


Principe NORA AP06 Gebruik van standaard oplossingen
Bron http://noraonline.nl/wiki/Gebruik_standaard_oplossingen
Opmerkingen


Principe NORA AP07 Gebruik van de landelijke bouwstenen
Bron http://noraonline.nl/wiki/Gebruik_de_landelijke_bouwstenen
Opmerkingen


Principe NORA AP08 Gebruik open standaarden
Bron http://noraonline.nl/wiki/Gebruik_open_standaarden
Opmerkingen


Principe NORA BP08 Afnemers kunnen erop vertrouwen dat informatie niet wordt misbruikt (vertrouwelijk)
Bron http://noraonline.nl/wiki/Vertrouwelijk
Opmerkingen Dit stelt eisen aan het beveiligen én het gebruik van alle onderdelen van de keten van mobiele oplossingen. Voor de gemeente omvat dit in elk geval de beschikbaar gestelde informatie(diensten) maar ook de gebruiker van de mobiele oplossing heeft een verantwoordelijkheid en moet zich bewust zijn van de risico’s van het gebruik van mobiele apparaten en mobiele applicaties (1212). Ook zal de leverancier van de mobiele dienst ook expliciet maatregelen moeten nemen voor specifieke beveiligingen aan mobiele apparaten.


Principe NORA AP37 Identificatie authenticatie en autorisatie
Bron http://noraonline.nl/wiki/Identificatie_authenticatie_en_autorisatie
Opmerkingen Dienstverlener en afnemer zijn geauthentiseerd wanneer de dienst een vertrouwelijk karakter heeft. Verder verbijzonderd in principe MA5.1


Principe NORA AP39 Controle op juistheid, volledigheid en tijdigheid
Bron http://noraonline.nl/wiki/Controle_op_juistheid_volledigheid_en_tijdigheid
Opmerkingen Controles zijn onmisbaar om de juiste werking van systemen en de integriteit van de informatievoorziening als geheel te waarborgen. Geprogrammeerde, automatische controles bieden de beste waarborgen dat de integriteit van de informatievoorziening gehandhaafd kan worden: zij zijn efficiënter en effectiever dan handmatige controles. Verder verbijzonderd in principe MA5.1.


Principe NORA BP09 Afnemers kunnen erop vertrouwen dat de dienstverlener zich aan afspraken houdt (betrouwbaar)
Bron http://noraonline.nl/wiki/Betrouwbaar
Opmerkingen De kwaliteit van de informatiediensten waar de mobiele applicaties mee werken moet hoog zijn. Dit geldt op alle kwaliteitsaspecten waaronder de beschikbaarheid, actualiteit, juistheid, onweerlegbaarheid, etc


Principe NORA AP11 Gelijkwaardig resultaat ongeacht kanaal
Bron http://noraonline.nl/wiki/Gelijkwaardig_resultaat_ongeacht_kanaal
Opmerkingen Dit stelt eisen aan o.a. het gebruik van dezelfde brongegevens, het synchroniseren van gegevens van de verschillende kanalen etc. Zie voor details de noraonline.


Principe NORA AP36 Uitgangssituatie herstellen
Bron http://noraonline.nl/wiki/Uitgangssituatie_herstellen
Opmerkingen Afnemers mogen niet benadeeld worden wanneer een dienstverleningsproces door menselijke- of systeemfouten niet voltooid kan worden. Mobiele toepassingen in het bijzonder zijn erg gevoelig voor verstoringen.


Principe NORA AP39 Controle op juistheid, volledigheid en tijdigheid
Bron http://noraonline.nl/wiki/Controle_op_juistheid_volledigheid_en_tijdigheid
Opmerkingen Controles zijn onmisbaar om de juiste werking van systemen en de integriteit van de informatievoorziening als geheel te waarborgen. Geprogrammeerde, automatische controles bieden de beste waarborgen dat de integriteit van de informatievoorziening gehandhaafd kan worden: zij zijn efficiënter en effectiever dan handmatige controles. Verder verbijzonderd in principe MA5.1.


Principe NORA AP40 Uitwisseling berichten onweerlegbaar
Bron http://noraonline.nl/wiki/Uitwisseling_berichten_onweerlegbaar
Opmerkingen Bij diensten met rechtsconsequenties is onweerlegbaarheid van groot belang.





Template mobiele applicatie catalogus

In het onderstaande tabel is een concept opgenomen voor het inventariseren van mobiele applicaties binnen gemeenten. Ter illustratie is één voorbeeld ingevuld (‘Meld een Vermoeden’).

App-catalogus App Leverancier URL Gemeente Doelgroep Domein App-technologie Ondersteund platform Omschrijving
Meld een vermoeden Antifraud company http://antifraud.company/ Den Haag Medewerkers Domeinoverstijgend Native Android App voor het laagdrempelig maken van meldingen door medewerkers op straat.




Referenties

NrReferentie
01Enterprise Architectuur Rijksdiensten, http://earonline.nl/index.php/Informatiseringsdomein_Werkplekdiensten
02Presentatie katern mobiele architectuur – Digitale agenda 2020, 5 april 2017
04Inwonercloud, http://www.inwonercloud.nl/
05GPO voorstellen onderdeel inwonercloud, 04-04-2016, gemeente Woerden
06Referentiearchitectuur voor mobiele applicaties voor EZ (publieke versie), versie 1.1, 8 januari 2016.
07GEMMA software catalogus, https://www.softwarecatalogus.nl/
08Nederlandse Overheid Referentiearchitectuur, NORA, http://noraonline.nl/wiki/NORA_online
09Gemeentelijke Referentie Architectuur, GEMMA, http://gemmaonline.nl/index.php/Gemeentelijke_Model_Architectuur_(GEMMA)
10Enterprise mobility Rijksoverheid – Anyplace, Anytime, Any device, versie 1.1, 30 mei 2013, Shared Service Center ICT DJI
11Gemeentelijk gegevenslandschap v0.72, 2017, KING 2017
12Digitale mobiliteit en de NORA – over de impact van mobility op de iOverheid en de NORA principes, 17 juni 2016
13Vervangen door 18
14Handreiking mobility 2017-2018 (Enterprise Mobility Rijk), SSC-ICT DJI, v1.0, 24 november 2016.
15Handreiking Mobiele App. Ontwikkeling en Beheer voor de Rijksoverheid. Versie 2.0 - april 2018
16Beveiligingseisen voor mobile apps v1.0, 25 februari 2016, Centrum Informatiebeveiliging en Privacy bescherming
17Resonsive webdesign, wikipedia, https://nl.wikipedia.org/wiki/Responsive_webdesign
18Katern GEMMA 2.0 integratiearchitectuur, KING, http://www.gemmaonline.nl/images/gemmaonline/b/bc/Katern_GEMMA_2.0_Integratiearchitectuur.pdf
19JSON wiki, https://nl.wikipedia.org/wiki/JSON
20Rest, https://en.wikipedia.org/wiki/Representational_state_transfer
21Stelsel van basisregistraties, Digitale overheid, https://www.digitaleoverheid.nl/voorzieningen/gegevens/inhoud-basisregistraties/
22Strategische en Tactische Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG), KING, 30 april 2014
23Meld een vermoeden platform, http://antifraud.company/, AntiFraud Company
24Instellingsdiensten toegankelijk via mobiele interfaces? Een afweging tussen gebruiksvriendelijkheid en beveiliging, https://blog.surf.nl/instellingsdiensten-toegankelijk-via-mobiele-interfaces-een-afweging-tussen-gebruiksvriendelijkheid-en-beveiliging/
25Informatiemodel Basis- en Kerngegevens (RSGB), versie 2.0, https://www.gemmaonline.nl/index.php/Informatiemodel_Basis-_en_Kerngegevens_(RSGB)
26Informatiemodel Zaken (RGBZ), versie 1.0, https://www.gemmaonline.nl/index.php/Informatiemodel_Zaken_(RGBZ)
27Informatiemodel Zaaktypen (ImZTC), versie 2.1, https://www.gemmaonline.nl/index.php/Informatiemodel_Zaaktypen_(ImZTC)
28De digitale overheid: maak het waar!, Studiegroep informatiesamenleving en overheid, 18 april 2017, https://www.digitaleoverheid.nl/document/rapport-maak-studiegroep-informatiesamenleving-en-overheid/



Eindnoten

  1. Op het moment van schrijven is dit model en de uitwerking nog ontwikkeling. Desalniettemin geeft dit wel een duidelijke visie op dit vlak.