Common Ground-beweging zet business-intelligenceprincipes onder druk

Wat behelst Common Ground?

De Common Ground-beweging staat voor een radicaal andere aanpak van de gehele informatievoorziening van gemeenten. Het doel is het gemeentelijke applicatielandschap flexibel te maken, aan privacywetgeving te voldoen en onafhankelijker te worden van commerciële marktpartijen, met als uiteindelijk doel de gemeentelijke dienstverlening te verbeteren. Het is een bottom-upinitiatief van twee verenigingen van gemeentelijke ICT-professionals, geïnspireerd op het Estse X-Road, en enthousiast omarmd door de Taskforce Samen Organiseren van de VNG. Het is nadrukkelijk geen van bovenaf opgelegde systeemwijziging.

Common Ground focust op een open, transparante overheid via een stapsgewijze modernisering van de ICT-infrastructuur.

De beweging werkt toe naar een verregaande ‘separation of concerns’ (scheiding van functionaliteiten) in het applicatielandschap. Databases worden losgekoppeld van applicaties, werkprocessen en data-integratie, en alle gegevensuitwisseling wordt gestandaardiseerd. Een belangrijk aspect is dat data die applicaties gebruiken altijd bij de oorspronkelijke bron wordt opgevraagd in plaats van eindeloos gekopieerd. Data opvragen bij de bronadministratie is ook de meest voor de hand liggende manier om zinvolle logging en daarmee verantwoording over het gebruik van gevoelige burgerdata te realiseren. Het voorkomt het bijhouden van tientallen verantwoordingsregisters.

Gevolgen voor business intelligence

Het ontmoedigingsbeleid voor het kopiëren van data raakt business intelligence in de kern. Sinds jaar en dag kopiëren we data naar datawarehouses om ontkoppeld te zijn van de bronsystemen, een compleet beeld over de tijd vast te houden en data te combineren en te transformeren. We kopiëren data en besluiten daarna pas wat we ermee doen: het nut van een datawarehouse berust op een generiek verzameldoel. Volgens de Common Ground-principes moet er sprake zijn van doelbinding: je mag alleen met een specifiek verzameldoel gegevens opvragen.

Een mogelijke solution-architectuur: het logisch datawarehouse

Een logisch datawarehouse (LDW) is een datawarehouse waarin data niet wordt gekopieerd: het bevat alleen verwijzingen naar bronsystemen, en de daadwerkelijke data wordt rechtstreeks bij de bron opgevraagd op het moment dat een rapport wordt ververst.

Naast het klassieke enterprise-datawarehouse (EDW) dat is gebaseerd op het kopiëren van data is er dus een andere solution-architectuur. De kern van een logisch datawarehouse is een datavirtualisatieplatform dat alle verwijzingen naar bronsystemen bijhoudt. Het kan ook allerlei bewerkingen op de data uitvoeren, zoals het transformeren naar de dimensionele modellen die nodig zijn voor rapportages, vergelijkbaar met databaseviews. Het platform biedt de data daarna aan via een generieke, virtuele SQL-laag. Daardoor kunnen meerdere rapportage- en analysetools, zoals Cognos, Power BI, R en Python, naast elkaar worden gebruikt en kijken ze allemaal naar dezelfde virtuele data. De data wordt pas opgehaald, rechtstreeks uit de bron, wanneer ze nodig is voor een rapport of analyse, en er wordt niet meer data opgehaald dan strikt noodzakelijk.

Enterprise-datawarehouse versus logisch datawarehouse

De wezenlijke verschillen tussen de twee architecturen.

Voordelen van een logisch datawarehouse

• Het past bij Common Ground. Er is geen lokale opslag van gegevens, waardoor eenvoudiger te voldoen is aan privacywetgeving en de Archiefwet.
• Flexibiliteit en ontwikkelsnelheid. Er hoeven geen laadprocessen te worden gebouwd en getest. Bij fysieke laadprocessen is het herstellen van fouten en het verwerken van wijzigingen bewerkelijk: laadjobs moeten worden teruggedraaid en opnieuw gedraaid.
• Veel lagen worden haalbaar. Van oudsher wordt het aantal lagen in een datawarehouse beperkt omdat elke laag een ‘point of failure’ is. Zonder bewerkelijke laadprocessen kun je met veel lagen en tussenresultaten werken, wat complexe berekeningen navolgbaar houdt.
• Realtime data is mogelijk door directe bevraging van de bronsystemen.
• Vergevingsgezind ontwikkelen. Ontdek je een fout, dan hoef je alleen de verwijzingen aan te passen.
• Lokale datawarehouses kunnen als bron dienen. Een gemeente kan bijvoorbeeld een datawarehouse voor het sociaal domein in stand houden en centraal ontsluiten, zodat er weinig kapitaalvernietiging is en je incrementeel live kunt gaan in plaats van met een risicovolle big bang.
• Centrale regie op toegang. Datavirtualisatieplatforms kunnen gedetailleerde rechten toekennen en data waar nodig maskeren of anonimiseren.

Nadelen en mitigerende maatregelen

• Sommige bronnen kunnen directe bevragingen niet aan en worden onaanvaardbaar traag of vallen simpelweg om. Een mogelijke maatregel is regelmatig een dump van de ruwe data naar een data hub maken en die bevragen, of tabellen cachen en de cache ’s nachts verversen. Beide doen het principe van niet kopiëren geweld aan, en ze betekenen dat het bronsysteem niet toekomstvast is en op termijn vervangen moet worden.
• Sommige bronnen houden geen historie vast maar overschrijven hun data. De maatregelen zijn dezelfde, en je moet de historie ook expliciet opbouwen.
• Sommige bronnen kunnen geen grote uitvragen faciliteren. Dat komt voor bij SaaS-applicaties waar data alleen via een API is op te vragen die niet op grote volumes is ingericht. Dan wordt vaak teruggegrepen op exports of dumps.

Kortom: een logisch datawarehouse is afhankelijk van goed ingerichte bronsystemen die ontsluitbaar, performant en historisch compleet zijn. Dat zijn eisen die we tegenwoordig aan moderne softwaresystemen mogen stellen.

Waarom is nog niet iedereen overgestapt?

• Onbekendheid. Datavirtualisatie was lange tijd een wat obscure technologie. Ze wordt inmiddels door steeds meer (vooral grote) bedrijven omarmd, voor migraties, als abstractielaag voor gegevensuitwisseling en steeds vaker voor BI, maar is nog lang niet zo ingeburgerd als klassieke datawarehouses en ETL-producten.
• Hoge kosten. Een datavirtualisatieplatform vergt een flinke investering, zeker bij een van de marktleiders. Die verdient zich doorgaans snel terug door de hogere productiviteit van BI-ontwikkelaars, maar de initiële licentiekosten vormen een hobbel voor organisaties met minder diepe zakken. Er zijn prijstechnisch gunstigere alternatieven.
• Starheid. Traditionele denkwijzen houden ons tegen. Een moderne denkwijze vertrekt vanuit data in plaats van applicaties: data moet vrij kunnen bewegen door het ecosysteem. Dat is in lijn met de data-meshfilosofie, waarin een domeineigenaar verantwoordelijk is voor het uitwisselbaar maken van data. Het betekent ook denken in ketens in plaats van afdelingen: het datagebruik staat centraal, niet het databezit.

Operationele data versus analytische data

Op dit moment concentreert Common Ground zich vooral op het faciliteren van gegevensuitwisseling tussen applicaties: het operationele vlak. Met het analytische vlak wordt al rekening gehouden; NLX en API’s worden voorbereid om grote hoeveelheden data door te sturen. In principe gaat het om dezelfde data, maar het gebruik verschilt en daarmee de eisen. Op het operationele vlak wordt data gebruikt om bedrijfsprocessen uit te voeren, meestal door enkele records en de actuele status te raadplegen. Op het analytische vlak willen we over die processen rapporteren en ze analyseren, wat grote sets en het verloop over tijd vereist. Denk aan de woonplaats van een burger: operationeel volstaat het huidige adres, analytisch telt de historie.

Gemeenten bevinden zich bovendien in een data-ecosysteem met andere (semi)overheidsinstellingen, die allemaal elkaars data nodig hebben voor nuttige analyses. Om te voorkomen dat complete administraties met gevoelige data keer op keer naar al die instellingen worden gekopieerd, is het des te belangrijker dat iedere instelling de data voor rapportage en analyse alleen uit de bronadministraties leest.

Conclusies

• Voor gemeenten is het absoluut de moeite waard een solution-architectuur op basis van het logisch datawarehouse te onderzoeken voor de centrale dataverzameling voor business intelligence.
• Het wordt steeds belangrijker extra kritisch te zijn op de systemen die worden aangeschaft voor de bronadministraties: ze moeten ontsluitbaar, performant en historisch compleet zijn.

Common Ground is een bottom-upbeweging, dus de soep wordt nu misschien nog niet zo heet gegeten. Maar digitale transformatie, applicatierationalisatie en datavirtualisatie gaan onverminderd door, en slimme gemeenten haken tijdig aan. Elke gemeente heeft een andere focus, een ander vertrekpunt en tempo, en kan op verschillende momenten instappen. De case van de gemeente Sittard-Geleen laat zien hoe.

Verder lezen

• Datawarehouse
• Extract, transform, load (ETL)
• Blog: Het nut van een datawarehouse
• Blog: Data mesh

Over de auteur

Rick van der Linden

Rick heeft ruim twintig jaar ervaring in business intelligence en analytics, als dashboard- en datawarehouse-ontwikkelaar, architect, business analist en product owner. Hij is een praktische professional met een down-to-earth mentaliteit en een constante focus op waardecreatie.

Over Diamond Decisions

Diamond Decisions helpt organisaties beter te worden door betere beslissingen mogelijk te maken. We starten niet bij data, dashboards of AI, maar bij de beslissing die beter moet, en bouwen van daaruit terug naar KPI’s, data en technologie. Dat doen we in vier stappen: inspiratie en alignment, business modeling, analytics en dataplatform en datagedreven beslissers. Zo zorgen we dat BI en AI geen IT-project blijven, maar elke dag waarde opleveren.