Artikel

Samenwerken onder architectuur

Architectuur voor intergemeentelijke samenwerking

Anno 2011 is 'werken onder architectuur' een bekend begrip. Met de actuele ontwikkelingen die op de overheid afkomen is naast architectuur ook samenwerking een steeds belangrijker thema; samenwerken in de dienstenketen (met ketenpartners), samenwerken aan zaken (zaakgericht werken) en samenwerking tussen gemeenten (omwille van bezuinigingen). Gemeenten gaan daarom steeds meer 'Samenwerken onder architectuur'. Daarvoor is een architectuur nodig die samenwerking ondersteunt. Dit artikel geeft een roadmap voor een gestandaardiseerde architectuur voor samenwerking.

Meer samenwerken dient te leiden tot een compactere en efficiëntere overheid met betere dienstverlening naar burgers en bedrijven. Vanuit de landelijke overheid wordt daarom gestuurd op samenwerking en op een gestandaardiseerde informatie architectuur voor gemeenten (werknaam 'de basisgemeente'). Dat zou onder andere kostenbesparing en beheervoordelen moeten opleveren. Dit artikel beschrijft op welke wijze een gestandaardiseerde architectuur intergemeentelijke samenwerking (Dimpact) ondersteund via een achttal architectuurthema’s.

Dimpact: 30 samenwerkende gemeenten

Dimpact is een samenwerkingsverband van zo'n 30 gemeenten. Zij werken samen aan het realiseren van multichannel dienstverlening en efficiënte bedrijfsvoering. De (standaard)programmatuur wordt ingekocht via gebundelde aanbestedingen. Gezamenlijke implementatie, beheer, hosting en kennisdeling zijn belangrijke peilers in het samenwerkingsverband. Landelijk laat Dimpact haar stem horen bij stakeholders en is ze proeftuin voor nieuwe e-overheidontwikkelingen en (wetenschappelijk) onderzoek. Inmiddels heeft Dimpact met dit concept een Front- en Midoffice oplossing (‘de E-Suite’) gerealiseerd waarop de komende jaren verder geïnnoveerd wordt (zie figuur 1, E-Suite, de Dimpact architectuur). Standaardisatie vormt daarbij de basis van de roadmap.

Figuur 1: E-Suite, de Dimpact architectuur (klik voor vergroting)

Standaardisatie

Gezamenlijk inkopen van programmatuur levert schaalvoordelen op. Hoe meer generiek, hoe meer het oplevert. Standaardisatie zorgt voor minder (doorgaans dure) maatwerkkoppelingen. Maar wellicht nog belangrijker, zijn de lagere beheerlasten door standaardisatie. De beheerlasten die er zijn kunnen verdeeld of gecentraliseerd worden. Standaardisatie geeft tevens ruimte voor additionele samenwerkingsvormen, zoals gezamenlijk content onderhouden voor gemeentelijke websites.

Om tot standaardisatie te komen dienen samenwerkende partners de dialoog met elkaar aan te gaan: wat is de beste oplossingen voor ons allemaal? Specialisten zijn doorgaans overtuigd dat hun lokale oplossing de beste is. In samenwerking zijn de ideeën van één afdeling niet meer het uitgangspunt. Daarom wordt men gedwongen terug te gaan naar de bron: de klant. Die klant wil in alle gemeenten hetzelfde, namelijk goede dienstverlening.

Architectuur gestandaardiseerd op doelen

Een gestandaardiseerde architectuur helpt Dimpact bij het realiseren van haar organisatiedoelstellingen, te noemen:

  • Betere dienstverlening en bedrijfsvoering door het faciliteren van landelijke e-overheid visie(s), ketenintegratie en zaakgericht werken
  • Kostenbesparing voor lidgemeenten
  • Leveranciersonafhankelijkheid
  • Standaardisatie met aandacht voor lokale flexibiliteit

Ze realiseert deze doelen vooral door de juiste architectuur. De doelen zijn daarvoor doorvertaald naar een roadmap voor samenwerken onder een gestandaardiseerde architectuur. Daaruit vloeien ook aanknopingspunten voor de samenwerkingsvormen en –initiatieven. Onderstaand worden een aantal voor Dimpact wezenlijke architectuuraspecten (o.a. oriëntaties en standaarden) besproken die het samenwerken aan een gestandaardiseerde architectuur [a]  faciliteren.

1. Service Georiënteerde Architectuur

Het e-overheid concept zorgt voor betere informatie-uitwisseling en daarmee betere dienstverlening naar de klant en efficiëntere bedrijfsvoering. Daarbij gaat men uit van een service georiënteerde architectuur.

De architectuur van de E-suite is daarom volledig servicegeoriënteerd opgebouwd. Daarmee kunnen onder andere de hoofdcomponenten van het systeem hun functionaliteiten via web services aanbieden aan andere componenten. Verder communiceren de componenten niet direct met elkaar maar via een servicebus. Er wordt ook een strikte scheiding gehanteerd van gegevens, logica en presentatie. Het Medewerkerportaal, Beheerportaal en Digitale Loket zijn bijvoorbeeld “dunne” frontends die van de onderliggende services gebruikmaken.

De voordelen van serviceoriëntatie zijn evident. De onderhoudbaarheid en uitbreidbaarheid van het systeem is groter. De mogelijkheden om het systeem te koppelen met andere systemen in het applicatielandschap van de gemeente en met externe systemen (zoals landelijke voorzieningen) zijn tevens groter. Ook de scheiding tussen dienst (of contract) en realisatie van die dienst vergroot mede de leveranciersonafhankelijkheid. Een service georiënteerde architectuur draagt daarmee bij aan de hoofddoelstellingen van Dimpact.

2. Zero coding

Zero coding maakt functionele inrichting van een systeem mogelijk zonder te programmeren. Het voordeel is dat men - zonder tussenkomst van een software leverancier - het systeem vergaand kan aanpassen aan de eigen situatie. Dimpact kan een standaard vormgeven, uitrollen naar haar leden en die kunnen dus lokale aanpassingen maken. Dit betekent minder afhankelijkheid van de software leverancier en meer flexibiliteit.

De flexibiliteit dient echter niet de standaardisatie(voordelen) binnen de samenwerking in gevaar te brengen. Standaardisatie op hoofdlijnen is noodzakelijk om het geheel over alle samenwerkingspartners beheersbaar en (door-)ontwikkelbaar te houden. Bij meer flexibiliteit komt er ook meer verantwoordelijkheid bij de deelnemende organisaties te liggen.

Zero coding

Hieronder volgen drie voorbeelden van onderdelen uit de gerealiseerde Dimpact programmatuur die reeds zonder programmeerwerk worden ingericht:

  • Referentietabellen: De configuratie van de programmatuur vindt grotendeels plaats met zogenaamde referentietabellen. Deze tabellen bevatten een grote hoeveelheid instellingen voor zowel de FrontOffice als de MidOffice. Dit varieert van waarden voor berekeningen zoals leges en bouwkosten tot teksten voor e-mails.
  • E-formulieren: Het FrontOffice bevat E-formulieren voor burgers en bedrijven om online hun zaken te regelen met de gemeente. Deze digitale formulieren zijn generiek opgezet en lokaal aanpasbaar door middel van parameters. Een voorbeeld van zo'n parameter is de instelling of er betaald moet worden voor de dienst (en de gebruiker langs de internetkassa moet worden geleid). E-formulieren worden nu nog op basis van functioneel ontwerpen van Dimpact door de leverancier gerealiseerd. Uiteindelijk zullen gemeenten zelf in staat worden gesteld E-formulieren te ontwikkelen.
  • E-diensten: Het MidOffice biedt gemeenten de mogelijkheid om de zaakafhandeling (via een ‘E-dienst’) volledig naar eigen inzicht vorm te geven. Daartoe is het instrument ‘Grafische editors’ ontwikkeld. Deze editors komen bij onderdeel drie nader aan bod.

In de toekomst wil Dimpact het concept van zero coding verder doortrekken. Ze zal een moedersjabloon gaan onderhouden voor de functionele inrichting waarmee instappende gemeenten een vliegende start kunnen maken. Gemeenten werken met ‘kinderen’ van het moedersjabloon. Als een gemeente aanpassingen maakt aan hun kind dan blijven deze behouden als er een nieuwe release van het moedersjabloon uitkomt. Het concept van moedersjabloon met kinderen is sterk gerelateerd aan het concept 'multi-tenancy'; zie ook onderdeel vier.

3. Workflow modelleren

Een belangrijk onderdeel van het bovengenoemde zero coding concept is het zelf modelleren van workflow en taakschermen. Hiermee worden de E-diensten in een gebruikersvriendelijke grafische omgeving ontwikkeld. De grafische editor is zo'n modelleertool om workflowmodellen voor zaakafhandeling te maken met bijbehorende taakschermen die de medewerker ondersteunt bij de afhandeling van taken. Aan ieder zaaktype (in de ZaakTypeCatalogus ofwel ZTC) kan een workflowproces worden gekoppeld.

Figuur 2: Workflow, voorbeeld van een workflow model in de grafische editor

Gemeenten kunnen hiermee zelf hun processen ontwikkelen en samenwerken aan het ontwerpen van processen. Dimpact faciliteert dergelijke samenwerking door het centraal realiseren van een set standaard E-diensten. Naast deze gestandaardiseerde set E-diensten kunnen gemeenten zelfstandig of in kleinere samenwerkingsvormen - via een 'procesbibliotheek' in de online collaboratieomgeving - werken aan het configureren van deze processen en/of nieuwe processen ontwerpen. Goed georganiseerde samenwerking hierbij is belangrijk. Daarmee kan veel tijd en geld bespaard worden door standaardisatie, terwijl ruimte gecreëerd wordt voor lokale flexibiliteit.

4. Multi-tenancy

Multi-tenancy maakt het mogelijk om de generieke (algemene) functionaliteit en de gemeentelijke (specifieke) configuraties te scheiden. Het refereert naar een principe in de software architectuur waarbij een systeem op één server draait en daarbij meerdere (cliënt)organisaties bedient. Er wordt gebruik gemaakt van virtuele partities (bij data en configuratie) op een server. Elke afnemende organisatie werkt met een afgeleide van het centrale systeem waarbij lokale aanpassingen kunnen worden gedaan. Multi-tenancy is een relatief nieuw concept en van belang bij Cloud Computing.

Bij Dimpact worden verschillende niveaus onderscheiden bij multi-tenancy waarbij het delen van gegevens (inclusief dossiers) en configuraties (bijvoorbeeld van processen) een belangrijke rol speelt. Uiteindelijk is de visie om multi-tenancy op basis van één codebase, ofwel SaaS, te realiseren. Dit impliceert dat alle Dimpact-gemeenten ook in technische zin gebruikmaken van één Front- en MidOffice Suite (één codebase), met logisch gescheiden ‘compartimenten’ voor de configuratie per gemeente (zgn. ‘tenants’).

Het samenwerken met één gestandaardiseerd platform maakt de uitwisseling van gegevens en configuraties tussen gemeenten onderling beter mogelijk. Dit is van belang wanneer gemeenten (nauwer) onderling en/of met ketenpartners gaan samenwerken. Het betekent minder lokaal beheer (door gemeente), beter centraal beheer (door het Dimpact-bureau) en minder inrichtingsinspanning.

5. Interoperabiliteit

Er wordt naar gestreefd de E-suite zoveel mogelijk open te stellen voor koppeling met andere systemen binnen en buiten het gemeentelijke applicatielandschap en aansluiting op landelijke voorzieningen. Om dit te bereiken zijn recent twee koppelvlakken toegevoegd aan de gegevensmagazijnen van de E-suite: een web service op het gegevensmagazijn voor het opvragen van persoons- en bedrijfsgegevens en een web service volgens de StUF-zaken standaard voor de uitwisseling van zaakgegevens. Vooral het laatste koppelvlak biedt veel mogelijkheden voor de integratie met de buitenwereld.

StUF-zaken is een (sector)model binnen de landelijke StUF-standaard voor het uitwisselen van zaakgegevens binnen de overheid. StUF-zaken is een zogenaamde verstuffing van het informatiemodel RGBZ (de entiteiten en relaties in het RGBZ zijn als het ware platgeslagen tot XML-berichten waarmee systemen zaakgegevens kunnen uitwisselen).

StUF-zaken

Een paar voorbeelden van de toepassing van StUF-zaken:

  • Document Management Systeem (DMS): Een gemeente handelt bepaalde zaken in het DMS af en andere in het Zaaksysteem; het DMS kan dan alle zaken ook aanmaken in het Zaaksysteem en het Zaaksysteem op de hoogte houden van statuswijzigingen. Het Zaaksysteem kan de statusupdate publiceren naar het Digitale Loket om de burger te informeren.
  • Parkeervergunningen: Burgers kunnen via de E-formulieren een parkeervergunning aanvragen. Sommige gemeenten handelen dit soort aanvragen af in een taakspecifiek systeem. Vanuit het Zaaksysteem kan een zaak worden aangemaakt in het taakspecifieke systeem. De medewerker kan vervolgens de aanvraag afhandelen waarbij het systeem statusupdates stuurt naar het Zaaksysteem die vervolgens worden gepubliceerd in het Digitaal Loket.
  • Ketensamenwerking: Steeds vaker zal de afhandeling van zaken organisatiegrenzen overschrijden, we spreken dan van ketensamenwerking. Denk hierbij aan de uitvoering van een inspectie door de Brandweer in het kader van een bouwaanvraag. Ook hiervoor kan StUF-zaken worden ingezet.

Het voordeel van het gestandaardiseerde StUF-zaken koppeling voor gemeenten is dat zij het Zaaksysteem kunnen openstellen voor externe partijen om zaken bij de gemeente aan te brengen, dat zij zelf andere partijen kunnen aansturen door zaken bij hen in te schieten en dat zij het Zaaksysteem kunnen koppelen met taakspecifieke systemen in hun eigen applicatielandschap. StUF-zaken faciliteert dus onder andere ketenintegratie en ontkokering door te communiceren met taakspecifieke applicaties.

6. Domein Specifieke Registraties

Bij de ontwikkeling van E-diensten is gebleken dat de bestaande informatiemodellen vanuit de landelijke overheid (RSGB en RGBZ) niet voorzien in processpecifieke gegevens bij gemeenten. Om dit soort gegevens te kunnen opslaan is ervoor gekozen om zogenaamde Domein Specifieke Registraties (DSRs) naast de gegevensmagazijnen te plaatsen. Deze worden ook wel eens kernregistraties genoemd.

Een DSR bestaat in feite uit een database en is toegankelijk vanuit het Medewerkerportaal en vanuit de E-diensten die gebruikmaken van deze DSR. Een voorbeeld van een DSR is die van de Melding Openbare Ruimte (MOR). Burgers kunnen via het Digitale Loket op een kaart een melding insturen. De gegevens van deze melding worden in het MidOffice opgeslagen in de DSR voor MOR. Vervolgens wordt een zaak aangemaakt voor de afhandeling van de melding. Het proces voor de afhandeling heeft directe toegang tot de gegevens van de melding middels de DSR. Bovendien kunnen DSRs buiten de zaakafhandeling om worden geraadpleegd. Door de samenwerking is het probleem van de processpecifieke gegevens opgelost met een standaardoplossing (de DSR's). Dit kan alle Nederlandse gemeenten een standaardiseerde oplossing bieden. Het wiel hoeft zo niet opnieuw te worden uitgevonden. Zo biedt een in samenwerking gerealiseerde standaard een generieke oplossing voor landelijke uitdagingen.

7. Plugin-architectuur

Plugins zijn software componenten die specifieke functionaliteit aan een grotere software applicatie toevoegen, ze maken daarmee maatwerk / personalisatie van een applicatie mogelijk. Plugin architectuur staat de applicatie toe om plugins (van derden) te zoeken en te laten samenwerken met het systeem. De E-suite functioneert dan als het ware als een application framework waar derden op basis van een SDK plugins voor kunnen ontwikkelen. Dit biedt gemeenten de mogelijkheid de E-suite uit te breiden met functionaliteiten op een gestandaardiseerde wijze.

Het zaaksysteem biedt gemeenten een raamwerk om al hun producten en diensten af te handelen. De zaakafhandeling wordt middels workflow en taakschermen ingeregeld en waar nodig kunnen plugins worden toegevoegd voor (ingewikkelde) berekeningen of gegevensbewerkingen. Denk hierbij aan de berekening van leges, bouwkosten of een uitkering. Op die manier kan midoffice/zaaksysteem worden gebruikt om backoffice-systemen te vervangen en uit te faseren. Dimpact heeft inmiddels de WABO ontwikkeld en hiervoor ook een aantal plugins toegevoegd aan het zaaksysteem voor specifieke functionaliteiten.

In samenwerking kunnen gemeenten app-diensten inkopen. De overheid bespaart zich zo de ontwikkelkosten en kan inspelen op (niches in) interne en externe dienstverlening. Een plugin-architectuur maakt het mogelijk om aan gestandaardiseerde functionaliteit via apps maatwerk functionaliteit toe te voegen.

8. Modernisering Gemeentelijke Basis Administratie (GBA)

Het overheidsprogramma modernisering GBA (mGBA) werkt aan de Basisregistratie Personen (BRP). De BRP maakt deel uit van het stelsel van basisregistraties. Het doel van de BRP is om persoonsgegevens bij te houden en te verstrekken aan overheidsorganisaties.

Het mGBA bestaat uit twee onderdelen: 1) een landelijke voorziening met web services om persoonsgegevens op te vragen en te muteren en 2) een set Burgerzakenmodules. De Burgerzakenmodules zijn in detail uitgewerkt in de vorm van procesbeschrijvingen en use cases. De landelijke voorziening wordt centraal aangeboden, maar gemeenten moeten de Burgerzakenmodules zelf aanschaffen.

In de visie van Dimpact moeten de Burgerzakenmodules gerealiseerd worden door het MidOffice te koppelen aan de landelijke voorziening en door de Burgerzakenmodules zaaksgewijs in te richten. Het laatste betekent dat de benodigde processen met het Zaaksysteem worden afgehandeld (als E-diensten dus). Het betekent ook dat additionele functionaliteit als plugins aan het MidOffice worden toegevoegd.

Als het GBA in het MidOffice kan worden gerealiseerd, worden gemeenten minder afhankelijk van leveranciers van BackOffice-systemen. Dit levert substantiële kostenbesparingen op voor gemeenten. Deze vorm van standaardisatie bevordert samenwerking binnen de overheid, met als resultaat betere dienstverlening.

In dit artikel hebben we laten zien op welke wijze architectuur een basis vormt voor intergemeentelijke samenwerking. Architectuur kan zelfs samenwerking als geheel faciliteren en bijdragen aan de doelstellingen op missieniveau. Standaardisatie is daarbij de sleutel tot succes. Met standaardisatie worden de meeste voordelen uit samenwerking gehaald. Enige lokale flexibiliteit blijft echter wenselijk. De juiste architectuur laat lokale flexibiliteit toe waarbij de standaardisatie niet in gevaar komt. Dat is tegenwoordig steeds beter mogelijk. In de praktijk blijft het echter aftasten waar de optimale balans tussen standaardisatie en flexibiliteit ligt.

Voetnoten

[a] De overige ‘standaard elementen’ uit de e-overheid architectuur, zoals de referentie architecturen, worden in dit artikel als gegeven beschouwd en niet verder behandeld.

Categorie:   
Auteur(s)
afbeelding van hugoterdoest
Hugo ter Doest
Dimpact - Business Architect

Hugo ter Doest is Business Architect bij Dimpact. Zijn interessegebieden zijn enterprise architectuur en software architectuur. Bij Dimpact is hij verantwoordelijk voor de architectuur van de Dimpact-producten en de aansluiting op de gemeentelijke bedrijfsvoering en applicatielandschap.

afbeelding van ClaudiaVermeulen
Claudia Vermeulen
Dimpact - Marketing & Communicatie Adviseur

Claudia Vermeulen is Marketing & Communicatie Adviseur bij Dimpact; een intergemeentelijk samenwerkingsverband voor digitale dienstverlening. Ze is te volgen op Twitter via @claudiadimpact.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.