Alternatieve solution architecturen
In dit artikel verkennen we de gevolgen van de Common Ground-beweging en privacywetgeving voor de inrichting van Business Intelligence bij gemeenten en andere (decentrale) overheidsorganen. We kijken ook naar alternatieve solution architecturen om te kunnen voldoen aan de principes van de Common Ground-beweging. Tot slot bespreken we kort de randvoorwaarden die nodig zijn voor een succesvolle Business Intelligence-implementatie die voldoet aan de Common Ground-principes.
Wat behelst de Common Ground?
De Common Ground-beweging staat voor een radicaal andere aanpak van de gehele informatievoorziening van gemeenten. Het doel is om het gemeentelijke applicatielandschap flexibel te maken, aan privacywetgeving te kunnen voldoen en onafhankelijker te worden van commerciële marktpartijen. Met als uiteindelijk doel om de gemeentelijke dienstverlening te verbeteren.
De Common Ground is een bottom-up initiatief van twee gemeentelijke koepelverenigingen voor informatiserings- en automatiseringsprofessionals. Het concept is geïnspireerd op de Estlandse X-road-beweging. Het initiatief is in Nederland enthousiast omarmd door de Taskforce Samen Organiseren van de VNG. Deze taakgroep wil flinke stappen zetten op weg naar een open, transparante overheid. Het is nadrukkelijk geen van bovenaf opgelegde systeemwijziging, maar een beweging die samen met gemeenten werkt aan een stapsgewijze modernisering van de ICT-infrastructuur binnen de decentrale overheid.
Common Ground focust op een open, transparante overheid via een stapsgewijze modernisering van de ICT-infrastructuur.
In dit kader wordt toegewerkt naar een verregaande “separation of concerns” (scheiding van functionaliteiten) in het applicatielandschap. Databases worden losgekoppeld van applicaties, werkprocessen en data-integratie. Alle gegevensuitwisseling wordt volgens deze visie verregaand gestandaardiseerd.
Figuur 1: Common Ground: het scheiden van functionaliteiten staat centraal
Een belangrijk aspect hierbij is dat data die gebruikt wordt door applicaties altijd opgevraagd wordt bij de oorspronkelijke bron in plaats van eindeloos kopieën te maken. Het is in Nederland namelijk zo geregeld dat gemeentelijke administraties elkaars databases continu moeten raadplegen. Het opvragen van data bij de bronadministratie in plaats van kopiëren is ook de meest voor de hand liggende oplossing om zinvolle logging en daarmee verantwoording van het gebruik van gevoelige (burger)data te realiseren. Het voorkomt het bijhouden van tientallen verantwoordingsregisters.
Gevolgen van Common Ground
Het ontmoedigingsbeleid ten aanzien van het kopiëren van data raakt Business Intelligence in de kern. Sinds jaar en dag kopiëren we immers data naar datawarehouses om ontkoppeld te raken van de bronsystemen, om een compleet beeld over de tijd vast te houden en om data te kunnen combineren en transformeren. We kopiëren data en gaan daarna pas besluiten wat we er mee gaan doen. Lees hier verder over deze werkwijze.
Kortom, we hebben een generiek verzameldoel. In de toekomst is dit niet meer toegestaan. Er moet volgens de Common Ground-principes sprake van doelbinding zijn, en je mag alleen met een specifiek verzameldoel gegevens opvragen.
De opleiding Datawarehouse & Data Governance 
Ambitieuze gemeentefunctionarissen die deze 3-daagse opleiding hebben gevolgd, zijn voortaan in staat om een strakke regie te voeren op hun Datawarehouse-project. Ze doorgronden het begrip datavirtualisatie en hebben daarnaast geleerd hoe ze een robuuste data governance-structuur opstellen. Wil jij ook een strak, superefficiënt ingericht datawarehouse?
Een mogelijke solution architectuur
Naast het bekende, klassieke Enterprise Data Warehouse (EDW) dat gebaseerd is op het kopiëren van data, is er nog een andere solution architectuur. Dit is het Logisch Data Warehouse (LDW). In plaats van data te kopiëren, worden alleen verwijzingen naar bronsystemen gemaakt. Pas op het moment van het verversen van bijvoorbeeld een rapport, wordt de daadwerkelijke data rechtstreeks in het bronsysteem opgevraagd.
Figuur 2: Het verschil tussen een Enterprise Data Warehouse en een Logisch Data Warehouse
Dit is vergelijkbaar met bijvoorbeeld een Business Objects Universe. Dit bestaat ook uit verwijzingen naar brontabellen, waar dan allerlei virtuele bewerkingen op gemodelleerd kunnen worden, die pas daadwerkelijk uitgevoerd worden nadat de data wordt opgevraagd.
De kern van een Logisch Data Warehouse wordt gevormd door een datavirtualisatie platform. Het datavirtualisatie platform is in staat om alle verwijzingen naar bronsystemen bij te houden. Het platform kan ook allerlei bewerkingen op de data doen, zoals het transformeren naar dimensionele modellen, die nodig zijn voor rapportages. Dit lijkt sterk op database views. Het datavirtualisatie platform biedt daarna de data aan via een generieke, virtuele SQL-laag. Dit betekent ook dat er meerdere rapportage- en analyse tools ingezet kunnen worden, die allemaal naar dezelfde (virtuele) data kijken. Cognos, PowerBI, R en Python kunnen dus naast elkaar gebruikt worden en kijken allemaal naar dezelfde data.
LET OP: Door de inzet van een datavirtualisatie platform wordt de data pas (direct uit de bron) opgehaald wanneer deze nodig is voor het rapport of de analyse. En er wordt ook niet meer data opgehaald dan strikt noodzakelijk.
Voordelen van een Logisch Data Warehouse
Een Logisch Data Warehouse kent een aantal voordelen:
- Het past goed in de Common Ground-beweging. Er is geen lokale opslag van gegevens. Er kan eenvoudiger worden voldaan aan privacywetgeving en aan de Archiefwet.
- Een Logisch Data Warehouse biedt flexibiliteit en snelheid van ontwikkelen. Het is namelijk niet nodig om laadprocessen te bouwen en te testen. Een nadeel van (fysieke) laadprocessen is dat het herstellen van fouten en het verwerken van nieuwe inzichten en veranderingen erg bewerkelijk is. Zogenoemde laadjobs moeten aan de hand van run id’s teruggedraaid worden om daarna in gewijzigde vorm opnieuw gedraaid te worden. Er zijn in het geval van datavirtualisatie alleen verwijzingen, geen laadstromen. Hiermee kunnen gemeenten beter inspelen op het veranderende applicatielandschap dat de Common Ground met zich mee zal brengen.
- Omdat er geen bewerkelijke laadprocessen nodig zijn, wordt het opeens ook haalbaar om veel meer lagen in het Data Warehouse te maken. Van oudsher proberen we het aantal lagen in een datawarehouse te beperken, omdat ze allemaal afzonderlijk een point of failure kunnen zijn. Dit betekent veel berekeningen in één keer uitvoeren en weinig tussenresultaten opslaan. Om het overzicht te houden op complexe berekeningen, is het juist praktisch om alle tussenstappen en tussenresultaten te kunnen volgen. In een Logisch Data Warehouse zijn er weinig beperkingen om met veel lagen en tussenresultaten te werken.
- Real time data is mogelijk door directe bevraging van de bronsystemen.
- Het ontwikkelen binnen een datavirtualisatie platform is “vergevingsgezind”. Fouten kun je eenvoudig herstellen. Als je een fout ontdekt, hoef je alleen de verwijzingen aan te passen. Het is niet nodig om talloze laadjobs terug te draaien en opnieuw te laden.
- Een Logisch Data Warehouse kan ook lokale datawarehouses als bron gebruiken. Het is dus mogelijk voor een gemeente om bijvoorbeeld een datawarehouse voor het sociale domein in stand te houden en centraal te ontsluiten via het Logisch Data Warehouse. Hierdoor vindt er weinig kapitaalvernietiging plaats. Ook is het mogelijk om incrementeel live te gaan in plaats van te kiezen voor een meer risicovolle “big bang”.
- Datavirtualisatie platforms zijn in staat om gedetailleerde rechten voor analyse en reporting toe te kennen op data. Ook kunnen ze indien nodig data maskeren of anonimiseren. Hiermee kan je centraal regie voeren op wie toegang krijgt tot welke data.
Kortom: met een Logisch Data Warehouse beschik je over een flexibele oplossing, waarmee je snel kan ontwikkelen en waarmee je beter kan voldoen aan privacywetgeving.
Nadelen van een Logisch Data Warehouse
Natuurlijk heeft het Logisch Data Warehouse ook bepaalde nadelen. De belangrijkste worden hieronder uiteengezet, inclusief mogelijke mitigerende maatregelen.
- Bepaalde bronnen kunnen de directe bevragingen niet aan en worden onaanvaardbaar traag of vallen simpelweg om. Een mogelijke maatregel is om (toch) op regelmatige basis een “dump” te maken van de ruwe data naar bijvoorbeeld een data hub en deze data hub te bevragen. Een andere optie is om gebruik te maken van caching van tabellen, en deze cache bijvoorbeeld ’s nachts te verversen. Het belangrijkste principe om geen data te kopiëren wordt in beide gevallen geweld aan gedaan, maar dit betekent dat het bronsysteem in principe niet toekomstvast is en op termijn vervangen moet worden.
- Bepaalde bronnen houden geen historie vast, maar overschrijven hun data. Ook dit past eigenlijk niet meer in een moderne architectuur. De mitigerende maatregelen zijn dezelfde als hierboven en daarnaast moet je ook de historie expliciet opbouwen.
- Bepaalde bronnen zijn niet in staat om grote uitvragen te faciliteren. Dit kan voorkomen bij SaaS-applicaties waarbij rechtstreekse toegang tot de database niet mogelijk is en alleen data opgevraagd kan worden via een API. Als de API niet ingericht is op grote uitvragen, dan is het bronsysteem moeilijk inpasbaar in een Logisch Data Warehouse solution architectuur. Vaak wordt dan weer teruggegrepen op exports of “dumps”.
Kortom: een Logisch Data Warehouse is afhankelijk van een goede inrichting van de bronsystemen. Deze moeten ontsluitbaar, performant en historisch compleet zijn. Dit zijn echter eisen die we tegenwoordig aan moderne softwaresystemen mogen stellen.
Uitdagingen bij het implementeren van een Logisch Data Warehouse
Als een Logisch Data Warehouse zo’n goede oplossing is, waarom is dan nog niet iedereen overgestapt? De volgende oorzaken zijn hiervoor verantwoordelijk:
- ONBEKENDHEID. Datavirtualisatie technologie was lange tijd een wat obscure technologie, maar wordt inmiddels door steeds meer (vooral grote) bedrijven omarmd voor diverse toepassingen. Het wordt gebruikt in migratietrajecten om tijdelijk verspreide data toch als één geheel te presenteren. Het wordt tevens gebruikt als abstractielaag ten behoeve van gegevensuitwisseling tussen systemen. En het wordt ook steeds meer gebruikt om Business Intelligence toepassingen te ondersteunen. Datavirtualisatie is echter nog lang niet zo ingeburgerd als klassieke datawarehouses en ETL-producten.
- HOGE KOSTEN. De aanschaf van een datavirtualisatie platform vergt een flinke investering. Dat geldt zeker als je shopt bij een van de marktleiders. Deze investering verdient zich doorgaans snel terug door de hogere productiviteit van BI developers. Toch vormen de initiële licentiekosten een flinke hobbel voor organisaties die minder diepe zakken hebben vergeleken met grote “corporates”. Er zijn prijstechnisch echter ook gunstigere alternatieven.
- STARHEID. Traditionele manieren van denken houden ons tegen. Een moderne manier van denken betekent: denken vanuit data in plaats van applicaties. Stel de data centraal, en dus ook de gedachte dat data vrij moet kunnen bewegen door het ecosysteem. Dit is in lijn met de data mesh-filosofie, die stelt dat een domeineigenaar de verantwoordelijkheid draagt om zijn data te kunnen uitwisselen met andere applicaties en met de analytische functie. Een moderne manier van data management houdt verder in dat we voortaan denken vanuit ketens in plaats van afdelingen of organisaties. Het datagebruik staat centraal in plaats van het databezit. Wederom betekent dit dat data vrij moet kunnen bewegen, tot aan de analytische functie. Kortom: wanneer iedereen de traditionele, verkokerde manier van denken achter zich laat, wordt datavirtualisatie een voor de hand liggend concept.
Met de ETL & Data Integratie Guide™ 2024 voer je als gemeente eenvoudig een toolselectie uit. Deze online gids geeft gemeenten alle kennisbronnen in handen om het vaak als arbeidsintensief en complex ervaren ETL proces te analyseren en te vereenvoudigen. Ze dringen hiermee automatisch door tot in de kern van andere belangrijke datawarehouse-processen, zoals data-integratie, datamigratie, datareplicatie en data governance.
Operationele data versus analytische data
Op dit moment concentreert de Common Ground-beweging zich nog met name op het faciliteren van gegevensuitwisseling tussen applicaties, oftewel het operationele vlak. Met het analytische vlak wordt echter al rekening gehouden. De NLX en API’s worden voorbereid zodat ze grote hoeveelheden data kunnen doorsturen. In principe gaat het natuurlijk allemaal om dezelfde data. Maar het gebruik is verschillend, en daarmee ook de eisen en randvoorwaarden. Op het operationele vlak wordt data gebruikt om de uitvoering van bedrijfsprocessen mogelijk te maken. Op het analytische vlak willen we aan de hand van dezelfde data over deze bedrijfsprocessen rapporteren en deze analyseren.
Een ander verschil is dat men voor het analytische vlak doorlopend grote sets opvraagt, waar het op het operationele vlak vaak om het raadplegen van enkele records gaat. Op het analytische vlak is men ook geïnteresseerd in het verloop over tijd, waarvoor het operationele vlak de actuele status voldoende is. Denk hierbij bijvoorbeeld aan de woonplaats van een burger.
Het verschil tussen het operationele vlak en het analytische vlak wordt in onderstaande figuur 3 uiteengezet.
Figuur 3: Het analytische data vlak naast het operationele data vlak
Het is dus belangrijk dat de integratiefaciliteit (NLX) en de services die communiceren met de data-laag beide soorten datagebruik kunnen faciliteren. Verder is het nog belangrijk op te merken dat gemeenten zich in een data ecosysteem bevinden met andere (semi) overheidsinstellingen, die allemaal elkaars data nodig hebben om nuttige analyses te maken. Om te voorkomen dat complete administraties met gevoelige data keer op keer meervoudig gekopieerd worden naar al deze instellingen, is het nog meer van belang dat iedere instelling de data voor rapportage en analyse alleen leest uit de bronadministraties.
Conclusies
- Voor gemeenten is het absoluut de moeite waard om een solution architectuur gebaseerd op het Logisch Data Warehouse te onderzoeken. Dit met het oog op de centrale dataverzameling voor Business Intelligence.
- Daarnaast wordt het voor gemeenten steeds belangrijker om extra kritisch te zijn op de systemen die ze aanschaffen voor het voeren van de bronadministraties. Deze moeten ontsluitbaar, performant en historisch compleet zijn.
Tot slot
Zoals gezegd Common Ground is een bottom-up beweging. In die zin wordt de soep misschien nu nog niet zo heet gegeten. Maar de ontwikkelingen op het gebied van de digitale transformatie in het algemeen en applicatie-rationalisatie en (data)virtualisatie in het bijzonder gaan onverminderd door. Slimme gemeenten haken tijdig aan op deze trends.
Elke gemeente die wil aansluiten bij Common Ground heeft waarschijnlijk een andere focus. En daarmee ook een ander vertrekpunt en tempo. Daarom kun je als gemeente op verschillende momenten en manieren ‘instappen’. Lees bijvoorbeeld in een van onze klantcases hoe gemeente Sittard-Geleen datavirtualisatie handen en voeten heeft gegeven. Ook geïnteresseerd in datavirtualisatie? Neem nu contact op met onze datavirtualisatie specialist of een van onze gemeente-adviseurs.
