Dit artikel gaat over verschillen, overeenkomsten en hergebruik van organisatie-brede datamodellering bij een ESB en bij een EDW.

1. Datamodellering en
semantiek: eerst het
EDW of eerst de ESB?
Door: Gerrit Versteeg

2. Datamodellering en semantiek: eerst het EDW of eerst de ESB?
Pg, 2
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?

3. Datamodellering en semantiek: eerst het EDW of eerst de ESB?
Pg, 3
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.

4. Datamodellering en semantiek: eerst het EDW of eerst de ESB?
Pg, 4
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.

5. Datamodellering en semantiek: eerst het EDW of eerst de ESB?
Pg, 5
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.

6. Datamodellering en semantiek: eerst het EDW of eerst de ESB?
Pg, 6
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.

7. Datamodellering en semantiek: eerst het EDW of eerst de ESB?
Pg, 7
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.

8. Datamodellering en semantiek: eerst het EDW of eerst de ESB?
Pg, 8

9. Datamodellering en semantiek: eerst het EDW of eerst de ESB?
Pg, 9
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.

10. Datamodellering en semantiek: eerst het EDW of eerst de ESB?
Pg, 10
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.

11. Datamodellering en semantiek: eerst het EDW of eerst de ESB?
Pg, 11
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.

12. Datamodellering en semantiek: eerst het EDW of eerst de ESB?
Pg, 12
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.

13. Datamodellering en semantiek: eerst het EDW of eerst de ESB?
Pg, 13
Ben je hierin geïnteresseerd? Bekijk de andere blog artikelen en whitepapers uit onze
themareeks 'BI & Architectuur' of download onze service-flyer:
Wil je meer informatie? Neem dan een kijkje op ons blog.
Dit blogartikel is geschreven door Gerrit Versteeg.

14. Datamodellering en semantiek: eerst het EDW of eerst de ESB?
Pg, 14
[1] EDW: Archetype 7, zie whitepaper BI-Architectuur.
[2] Als basis-hulpmiddel bij EAI (enterprise application integration).
[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.