Blog

Even wat herwaardering voor gestructureerde data

Auteur Joost Lommers Joost Lommers is enterprise designer en Enterprise Architecture consultant bij Trivento. Joost vindt het leuk om diep onbekend terrein in te trekken en is altijd op zoek naar een waarden-volle oplossing – met menselijke maat en klantgericht, nooit alleen technologiegedreven.

Met alle hype rondom big data en data analytics zou je bijna vergeten dat er ook nog zoiets bestaat als gestructureerde data. Natuurlijk is het belangrijk dat we de laatste jaren druk bezig zijn geweest met het analyseren van ongestructureerde data. We hebben mooie en onverwachte patronen gevonden, en onze dienstverlening daarmee geoptimaliseerd. En toch, diep in de ICT systemen die we gebruiken voor het leveren van onze diensten zit ook een enorme hoeveelheid gestructureerde data.

Denken in processen

Iedereen kan “denken in processen". Het is de manier waarom we de meeste taken in ons leven in brokjes hakken: doe eerst dit, dan dan dat, dan zus, dan zo, etc. En tussendoor nemen we zo hier en daar een beslissing om in een andere tak van het proces te komen. Het gaat om het achtereenvolgens uitvoeren van de juiste activiteiten. Bedrijfsprocessen zit ook zo in elkaar, of het nu order-to-cash of van-korrel-tot-borrel wordt genoemd, het zijn stappenplannen. Data (of liever, informatie) is in dit soort denken een afgeleide. Om de activiteiten uit te voeren hebben we informatie nodig, bijvoorbeeld om een beslissing te kunnen nemen, om een burger een bouwvergunning te geven of om het juiste product uit het magazijn te halen en naar de klant op te sturen. Het uitvoeren van zulke activiteiten leidt ook tot nieuwe informatie, zoals de beslissing die genomen is, het feit dat iemand een garage mag bouwen of een bijgestelde voorraad nadat een product is uitgeleverd. Echter, bij “denken in processen” is dit soort informatie een afgeleide – leidend is het proces met haar activiteiten en beslissingen.

Denken in data – Business Object Model

Om mij heen zie ik dat het lastig is om te “denken in data”. Het is abstracter dan “denken in processen”. We beseffen dat we data nodig hebben, er zijn immers databases en die moeten gevuld en gebruikt worden. Maar het “denken in data” laten we graag over aan ICT professionals. Data zit immers in de applicaties die we gebruiken, dus laat hen het vooral uitzoeken.

Maar net als dat we procesmodellen maken om te begrijpen en uit te leggen wat onze organisatie doet, kunnen we ook datamodellen gebruiken. Niet zo gedetailleerd om een database te kunnen maken, en meer gericht op het modelleren van de wereld om ons heen, zonder ons druk te maken over de technologie voor vastlegging. We noemen dit een Business Object Model, en andere namen hiervoor zijn Entity-Relationschip model, Domain model, Class Model of Information Model. In deze modellen leggen we vast in welke dingen of concepten we geïnteresseerd zijn, de zaken waar we gegevens over vast willen leggen. En we zoeken uit welke relaties we vast willen leggen tussen deze gegevens. Een datamodel bevat ook definities van de zaken die we vastleggen, zodat we weten wat het is. Zo weten we bijvoorbeeld dat een Bestelling*) in relatie staat tot een Klant – en precies één Klant. En ook dat een Klant meerdere Bestellingen kan hebben. Kan een Klant ook nul Bestellingen hebben? Dat ligt aan hoe het object “Klant” is gedefinieerd: zit iemand al in onze klantendatabase als hij nog nooit iets besteld heeft, maar zich wel heeft ingeschreven op een nieuwsbrief? Of is iemand pas een Klant als hij minstens 1x iets besteld heeft?

*) Er zijn veel manieren om een Business Object Model te maken. In de meeste varianten is het gebruikelijk om business objecten te benoemen met een woord in enkelvoud, waarvan de naam begint met een hoofdletter.

Een datamodel is stabieler dan een procesmodel

Het maken van een datamodel heeft een aantal voordelen. Zo helpt het bij het verfijnen van procesmodellen. Je kunt controleren of er voldoende activiteiten in je proces zitten om alle benodigde data en hun onderlinge verbanden te kunnen vastleggen. Daarnaast kunt je in een datamodel ook zien welke data je ter beschikking kunt stellen om activiteiten beter uit te voeren. Het belangrijkste voordeel is echter dat de kern van je datamodel veel stabieler is dan je procesmodel. Neem bijvoorbeeld een verzekeringsmaatschappij – bij schadeverzekeringen gaat het al honderden jaren over een Verzekerd Object, dat onder Condities wordt verzekerd. Je betaalt een Premie, en als een afgesproken Conditie optreedt, kun je een Claim indienen. Die Claim leidt uiteindelijk tot een Claimbeoordeling en een Afwijzing of een Uitkering. De data die nodig is om te kunnen verzekeren is in de kern hetzelfde gebleven, maar het proces is al vele malen aangepast. Doordat de organisatie-indeling veranderde, doordat de betrokken functies en rollen veranderden, of door nieuwe technologie die beschikbaar kwam. Bij luchtvaartmaatschappijen zie je hetzelfde: het gaat al ruim 100 jaar over o.a. Vlucht, Boeking en Passagier, maar het boeken van een vlucht is ondertussen veranderd van je persoonlijke secretaris naar het vliegveld sturen voor het regelen van een reis, via naar de reisagent in het winkelcentrum gaan of het call center bellen, naar self-service boeken via Internet.

Meerdere woorden voor hetzelfde business object

In de loop der jaren heeft het maken van een Business Object Model diverse keren een belangrijke rol gespeeld, om vervolgens weer te verdwijnen. Vaak omdat het doel was om een kloppend model voor de hele organisatie te maken. En dan bleek het moeilijk te zijn om tot een “goed" model te komen, maar vooral kwam men in middelgrote tot grote organisaties niet tot consensus over de objecten in het model. Er bleken meerdere woorden voor dezelfde business objecten te bestaan, en ook meerdere definities voor (zogenaamd) hetzelfde object.

Bij luchtvaartmaatschappijen zie je mooie voorbeelden: zo kun je als passagier “je Vlucht annuleren” en dan vlieg je zelf niet mee. Maar als de luchtvaartmaatschappij zelf “een Vlucht annuleert”, vliegt geen enkele passagier meer op dat moment. Vlucht betekent dus iets anders vanuit het interne perspectief van de organisatie, dan dat het vanuit klantperspectief betekent. Vanuit het interne perspectief heeft de passagier helemaal geen Vlucht geannuleerd, maar zijn of haar Boeking op die Vlucht. Je ziet dus een verschil tussen de klantgerichte betekenis van “Vlucht” en de organisatie-interne betekenis van “Vlucht”. Maar dat is nog niet alles, want zelfs binnen de organisatie zijn weer betekenisverschillen mogelijk. In hetzelfde voorbeeld blijkt bijvoorbeeld dat de vluchten die met een vliegtuig worden gevlogen, niet altijd overeenkomen met de vluchten die een maatschappij verkoopt. Zo hebben we al drie definities van Vlucht, en alle drie even waar in hun eigen context.

Dit probleem lossen we tegenwoordig op met Domain Driven Design. Hierbij modelleren we niet één, organisatiebrede waarheid, die meestal uitmondt in een grijze brij met definities die niemand meer aanspreekt. In plaats daarvan onderkennen we eerst dat er meerdere domeinen bestaan, en leggen we hier de grenzen van vast. Definities en relaties zijn vervolgens waar binnen de grenzen van een domein, maar gelden niet in een ander domein. Daarna beschrijven we expliciet de transformaties tussen domeinen, waardoor iedereen kan zien dat bijvoorbeeld een Vlucht in het ene domein, in het andere domein een Boeking wordt genoemd.

Krijg grip op de Babylonische spraakverwarring

In een moderne, agile organisatie met multidisciplinaire teams die samengesteld zijn uit medewerkers van verschillende afdelingen, heerst een enorme spraakverwarring. We denken allemaal dat we voor dezelfde organisatie werken, en dus dezelfde taal spreken. Maar dit is meestal een illusie, we hebben echt allemaal ons eigen jargon, bewust of onbewust. In deze situatie is een Domain-driven Business Object Model een goed en relatief simpel middel om deze spraakverwarring te verminderen, en om iedereen snel in te werken in de data die er toe doet voor de organisatie, hoe die data genoemd wordt in de verschillende domeinen, en hoe die data samenhangt.

Fijn om te hebben, zo'n model van je gestructureerde data.

Meer weten over het ontwerpen van digitale diensten op basis van data?

Dit artikel delen?

Ben je opzoek naar meer?

Bekijk hier een selectie van onze ebooks.

Digital Business met Microservices

Download nu

Van traditionele organisaties naar digitale winnaars

Download nu

Stappenplan voor digitaal succes

Download nu