Data-gedreven op vakantie

Een hotel boeken

Zoals velen was ik deze dagen bezig om de reis naar een vakantiebestemming uit te stippelen, met een aantal hotelovernachtingen langs de route. Dat gaat tegenwoordig wel makkelijker dan pakweg 10 jaar terug. Je geeft online je bestemming in en de route verschijnt op de kaart. Je selecteert "hotels", geeft de aankomst datum in, filtert nog wat op prijs of bepaalde voorzieningen en sorteert naar behoefte. Vrolijk poppen de markers op de landkaart, met een prijslabeltje erbij, precies in het gebied dat ik verschuif of waar ik inzoom.

Na aanklikken van een marker krijg ik detailinformatie. Je kan ook nog even 3D in het gebied kijken of staat met straatview bijna voor de deur van het hotel. In korte tijd verken je als consument tientallen opties.
Het is digitalisering ten voeten uit, waarbij de kracht van het op standaard wijze ontsluiten van al die gegevensbronnen wel heel duidelijk werd.

Data-gedreven?

Was ik nou lekker data-gedreven aan het werken? Of ben ik vooral gewoon bezig met mijn eigen proces - vakantie houden - met een taak/deelproces om de heenreis te regelen? Ik zoek toch naar specifieke en toegankelijke informatie, naar een lijstje van hotels die op mijn route liggen en die aan bepaalde voorwaarden voldoen? Het is vooral proces+informatie, waar mijn interesse ligt. Daardoor neemt mijn kennis van het hotelaanbod toe en kan ik er vervolgens iets mee kon doen, zoals een geschikt hotel boeken of juist ervan afzien. Een "handelingsperspectief" zoals dat zo mooi heet.

Softwarebouwers: van data naar informatie

Als gebruiker merk je niet direct iets van al die onderliggende losse gegevens. Ongetwijfeld zijn API's op de achtergrond driftig aan het werk, die hun datasets ophalen en waarmee softwarebouwers prachtige "informatieproducten" maken. Hun applicatie (of software, programma, toepassing, webservice) verwerkt de gegevens tot een informatieproduct. Groepjes van gegevens met een bepaalde logica staan bij elkaar op het scherm, vaak op vaste plekken. En dat voor meerdere mediakanalen/devices, met een passende gebruikersinterface en goede toegankelijkheid. Na een tijdje weet je precies hoe je snel iets opzoekt.
Ook verwacht je dat de datakwaliteit geborgd is, dat beschikbaarheid en prijs ook altijd kloppen. Hetzelfde geldt voor de proceskwaliteit, geen dubbele boekingen alstublieft.

De lagen van een informatiesysteem zien er dan zo uit:

Alles is data?

De term "data" wordt momenteel volop gebruikt in de communicatie, met name naar bestuurders toe. Er zijn diverse ontwikkelingen met "data" als kernwoord, zoals data bij de bron, het Federatief Datastelsel, interbestuurlijke datastrategie, data.overheid.nl, data catalogi. Het begrip "data" is dus erg ruim en vaak inwisselbaar voor "gegeven(s)", "gegevensset" of "informatie". Is dat erg? Misschien niet voor een globaal begrip en bewustwording van het belang van digitalisering. Maar voor het gesprek tussen proceseigenaar en informatici - zoals bij Common Ground voor gemeenten - kunnen we scherper zijn. En zeker in de context van een Gegevenswoordenboek.

De applicatie bakt er informatie van

Kan je een vergelijking maken met een brood van de bakker? Het graan is een grondstof, de zak meel een halffabricaat, het brood het product. De bakker verwerkt het. Als consument wil je een brood, geen graan.

Je zou dus eenvoudigweg kunnen zeggen dat gegevens de grondstoffen zijn en gegevenssets halffabricaten, die met een applicatie verwerkt worden tot informatieproducten.

Zo ben je weer terug bij een eenvoudige, misschien wel klassieke basis. Bij modellen waarin het informatiesysteem een aspect is van het beschouwde "supersysteem" (de dienstverlening naar de samenleving, het functioneren van een bepaald deel in de werkelijkheid).

Data-, gegevens- of informatiemodel

We strooien dus kwistig met de termen "data", "gegevens" of "informatie" en meestal begrijpen we elkaar wel. Zo kennen we MIM, Metamodel Informatiemodellering, dat juist vooral het gegevensmodel beschrijft, maar geen informatieproducten. Zou dat misschien invloed hebben op het gesprek tussen de meer theoretische informatie-architecten en het praktisch ingestelde Agile-bouwteam?

Vijflagenmodel

Daarnaast geeft het ook houvast om de weeffout in het Common Ground vijflagen-model aan te passen. De twee bovenste lagen heten daar "Interactie" en "Procesinrichting". Dat is verwarrend, want "Proces" - bedoeld als dienstverlening - is een eigenstandig ding, dat gebruik maakt van resources (mensen, middelen, informatie).

NB. Deze laatste variant met rollen maakt het niet beter, met dienstafnemer en -aanbieder, waar je dan eigenlijk moet lezen: gegevens**dienstafnemer en -aanbieder.

Proces en informatievoorziening

Je kan een proces immers op meerdere wijzen vorm geven, met andere resources en andere informatievoorziening. Mijn hotelboeking is qua doel en processtappen nog hetzelfde als 20 jaar terug: overnachten op reis, route uitzetten, hotels zoeken, een keuze maken en boeken. De handelingen en informatiebreedte zijn echter door digitalisering enorm veranderd, mede en vooral door de moderne dienstenaanbieders. Maar telkens zijn het gewoon weer gegevens(sets) die door een applicatie worden verwerkt en gepresenteerd tot informatieproduct. Je kan proces dus vervangen door "Applicatie". "Interactie" betreft dan de kanalen/devices met eigen interfaces waarover de informatie beschikbaar is.

Ecosysteem voor software-ontwikkeling

De huidige aandacht voor API-ontwikkelingen om data te ontsluiten is belangrijk, maar het versluiert de noodzaak om te komen tot een integraal eigentijds ecosysteem van software-ontwikkeling voor >300 gemeenten. Waarin alle actoren betrokken zijn en dat in een hoog tempo applicaties oplevert die herbruikbaar en schaalbaar zijn, bij voorkeur als open source.

Ter afsluiting nog even het gehele plaatje van de samenhang van werk + actoren/middelen + informatie.

Nou, eerst eens kijken of mijn hotelboekingen allemaal goed zijn aangekomen en genieten van de reis en locaties. Fijne vakantie allen!

Dit artikel is ook gepubliceerd op LinkedIn.