Het EDW[1] (enterprise data warehouse) heeft als lastige taak om de semantiek van de diverse bedrijfsonderdelen te integreren naar één verzameling eenduidige begrippen voor de hele organisatie. Daarvoor is een ‘enterprise data model’ nodig. Een ESB (enterprise service bus)[2] kan een belangrijke rol spelen bij de semantische ontkoppeling van services en requestors als de ESB gebruik maakt van een ‘canonical data model’. Zowel onder het EDW als onder de ESB ligt dus een generiek datamodel dat een eenduidige, partij-onafhankelijke begripsdefinitie probeert vast te stellen. De effort om een dergelijk model op te stellen is fors. En gezien het feit dat beide een eind moeten maken aan een semantische discussie, lijkt het verdacht veel op dubbel werk als je ze los van elkaar opstelt. Je zult je dus waarschijnlijk snel afvragen of hergebruik van één model voor het andere doel mogelijk is en zo ja, met welke kun je dan het best beginnen?
In dit artikel uit de themareeks BI & Architectuur, gaan we verder in op de generieke datamodellering die nodig is bij een ESB en bij een EDW. Centrale vraag daarbij: kunnen we uit eventuele verschillen afleiden met welke vorm we het beste kunnen starten?
Het integraal data model onder een EDW
Eén van de belangrijkste functies van een EDW is de integratie van gegevens uit 'alle' bronsystemen van een organisatie. Die integratie is niet alleen een technische uitdaging, maar vooraleerst een semantische. De aanleverende operationele afdelingen zullen binnen de organisatie vaak verschillende interpretaties hebben van ogenschijnlijk gelijke termen. Denk eens aan termen als klant, project, contract, opdracht, aanvraag, transactie, periode, product, et cetera. Ogenschijnlijk redelijk eenvoudige, concrete termen maar als je gegevens rond een dergelijke term gaat integreren blijken de verschillende interpretaties van diezelfde term opeens flink uiteen te lopen. Het datamodel onder een EDW hoort een organisatiebrede definitie van elk van de termen te bevatten (EDM: enterprise datamodel). Hiermee vertaalt de ETL de brondata naar de centrale terminologie en laadt de vertaalde, geconvergeerde data daarna in het EDW.
De afnemers van het EDW zijn onder andere managers, informatiewerkers en analisten. Elke managementdiscipline kent ook weer haar eigen lingo. De termen bij marketing management kunnen verschillen met die van financieel management. Dat betekent dus dat er een tweede, 'divergerende' vertaalslag nodig is aan de afleverkant van het EDW.
Het integraal data model onder een ESB
Een ESB verzorgt een stuk van de enterprise application integration door zo flexibel mogelijk requestors en services aan elkaar te verbinden. In een service oriented architecture draagt een ESB zorg voor de communicatie tussen 'requestors' en 'services'. De ESB ondersteunt vrijwel altijd meerdere communicatievormen (bijv. request-reply, fire-and-forget en publish-and-subscribe). Bij de meest simpele vorm ('fire-and-forget') stuurt de requestor een service-request naar de ESB, die dan zorgdraagt voor de aflevering ervan bij de gevraagde service. Bovenop de basistaak van het verzorgen van de communicatie kan een ESB ook vertalingen doen. 
De ESB vertaalt dan de termen in het service-request bericht naar de termen waarin de aangesproken service ze graag wil zien. De vertaling kan 'on-ramp' (bij ontvangst van de request door de bus) of 'off-ramp' (bij het doorsturen van de request naar de service vanuit de bus) plaatsvinden. Dit kan de ESB ook combineren, waardoor een tweetraps-proces ontstaat:
- On-ramp vertaalt de termen in de service-request van de requestor-taal naar een centrale partij-overstijgende taal.
- Off-ramp vertaalt de termen in de service-request daarna weer van de centrale taal naar de service-taal.
En juist om die centrale, partij-overstijgende taal gaat het hier. Deze taal is beschreven in een zogenaamd canonical data model (CDM)[3], een centrale definitie van alle termen binnen het bedrijf en hun onderlinge relaties. De vertaal-functie en het gebruik van een CDM kunnen een semantische ontkoppeling bewerkstelligen en daarmee bijdragen aan de aansluitingsflexibiliteit van het service/applicatie-landschap aan de ESB. De afnemers van de ESB zijn requestors en services, hetgeen feitelijk 'rollen' zijn van aanwezige operationele applicaties.
Verschillen tussen CDM en EDM
Laten we wat verschillen tussen de twee modellen bekijken, zodat we een betere conclusie kunnen trekken rond mogelijk hergebruik en een eventueel preferent initieel model.
Verschillen in betrokken partijen
Bij een EDW zijn de aanleverende partijen meestal (applicaties van) operationele afdelingen, terwijl de afnemende partijen hoofdzakelijk (applicaties van) management-disciplines zijn. Bij een ESB zijn zowel aanleverende als afnemende partijen (applicaties van) vooral operationele afdelingen. Omdat bij een ESB services zelf ook als requestor kunnen optreden en omgekeerd, zullen de operationele afdelingen vaak tegelijkertijd zowel leverancier als afnemer zijn. Wat betekent dit voor de te integreren semantiek? Laten we daarvoor de plaatjes een beetje anders[4] vormgeven.
Als we wat meer detail aanbrengen in het EDW zien we dat we een drietal lagen rond semantiek kunnen onderscheiden:
- laag 1: integratie van de binnen het bedrijf gehanteerde operationele, proces-georiënteerde begrippen,
- laag 2: integrale vertaling van het integrale operationele begrippenkader naar het integrale management-begrippenkader[5] en
- laag 3: vertaling van integrale management-begrippen naar begrippen per management-discipline.
Aangezien de eerste laag zich alleen bezighoudt met semantische integratie van operationele begrippen, ligt eventueel hergebruik van een EDM als CDM vooral daar. Binnen de eerste semantische integratie-laag van een EDW is de scope van de gehanteerde begrippen dus in feite beperkt tot dezelfde partijen (de operationele afdelingen) als bij de ESB.
Verschillen in positionering van het semantisch integratieproces
Even wegblijvend bij de discussie rond real-time data warehousing[6], zal het integratieproces binnen het EDW een periodiek karakter hebben, grotendeels afzijdig van het bedrijfskritische, operationele proces, terwijl de ESB daar juist middenin staat. Een versagend ESB heeft de potentie om het hele bedrijf direct op non-actief te zetten. Door haar positionering zijn derhalve de requirements rond borging veel strikter en meer rigide dan voor de borging van een EDW.
Verschillen in implementatie- en migratieprocessen
In de totstandkoming en verdere ontwikkeling van een EDW/EDM versus een ESB/CDM zitten weinig verschillen. Aan beide ligt dezelfde basale migratiebeslissing ten grondslag, namelijk: stel ik het model compleet vooraf op (pre-emptive) of laat ik het langzamerhand ontstaan naar gebruik (business-driven)? Wel verschilt de 'trigger' voor business-driven change: bij een ESB is dat een nieuwe service of requestor, bij een EDW een nieuw rapport of KPI.
Verschillen in te integreren begrippen
Bij een EDW is bij de modellering altijd sprake van de zoektocht naar het meest elementaire procesfeit. Dit om te voorkomen dat de overgang naar multi-dimensionale modellen (uitgaande van een organisatiesbrede scope) niet spaak loopt op een te grove granulariteit. Het meest elementaire procesfeit is vaak uitstekend te herleiden uit de berichten op een ESB. Veel van de ESB-leveranciers spelen hier handig op in (bijv. Spotfire van TIBCO). Dat betekent dat ons begrippenkader zich voor zowel EDM’s als CDM’s afspeelt op het granulariteit-niveau van berichten.
Conclusies rond hergebruik en startmodel
De verschillen en overeenkomsten beschouwend hebbende, kun je de volgende conclusies trekken:
-
Hergebruik beperkt zich tot de eerste integratie-laag van het EDW waar procesmatige begrippen semantisch worden samengebracht.
-
Hergebruik is goed mogelijk gezien het gelijke begrippenkader en –niveau.
-
Gelijktijdige business-driven migratie van beide modellen is niet goed mogelijk door de verschillende change-triggers.
-
De cruciale positie en bedrijfskritische rol van een ESB maakt het CDM niet de plaats om te 'leren' hoe een integraal semantisch kader eruit zou moeten zien. Dat betekent dat een initieel enterprise datamodel het best eerst in een EDW omgeving tot stand kan komen en bij voldoende omvang (scope) en kwaliteit, hergebruikt zou kunnen worden als CDM in een ESB.
Wil je meer over dit onderwerp weten? Bekijk dan onze gratis white paper
Dit blogartikel is geschreven door Gerrit Versteeg
[1] EDW: Archetype 7, zie whitepaper BI-Architectuur.
[3] NB de termen canonical, CDM en EDM zijn vrij vluchtig gebruikt. In principe gaat het om de problematiek van een datamodel dat een eenduidig begrippenkader vastlegt voor de hele organisatie. Bij ESB-implementaties wordt een dergelijk model vaak een CDM genoemd, bij EDW-implementaties vaker een EDM. Beide zijn natuurlijk canonieke, organisatie-brede modellen en in die zin dus ook onderling vergelijkbaar.
[4] Bij het EDM is de term divergerende vertaling weggelaten omdat door de mogelijke rolwisselingen tussen services en requestors (waarmee de lingo agnostisch wordt voor rol), de divergerende vertaling feitelijk niet meer is dan de omgekeerde convergerende vertaling.
[5] De bron voor bijv.conformed dimensions in het Multi-Dimensionale model.
[6] Deze discussie wordt binnenkort nader beschouwd in de white paper over double-loop besturingsmodellen in de serie Management & BI.