Altijd leuk deze discussie….

Information hiding is een enorm sterk architectureel principe.

Echter, zoals altijd; er is geen silver-bullet antwoord m.b.t. bronontsluiting. De functionele benadering omarm ik….als die voorradig is (en let’s face it, dat is vaak niet zo) en ook als die voldoet aan de architecturele principes die je hebt gesteld (bv. laagste granulair niveau, en changes only please). Vaak echter is er een soort CGM die op geen enkele wijze technisch beschikbaar is om tegen aan te praten. Wat moet je dan als DWH/BI? Opdracht geven aan de bron dat eerst te maken? Denk niet dat de klant erg happy is..

Die functionele benadering is wat mij betreft zeker de enige optie voor zogenaamde koop-systemen/applicaties. Die technisch ontsluiten is een slecht idee, voor alle redenen die jij ook aangeeft. Komt echter bij dat je als klant van een dergelijk systeem niet in control van de changes bent.
Ik ben er dus ook sterk voorstander bij om bij de selectie van dergelijke systemen altijd criteria op te nemen dat er een functionele interface moet zijn (dus; een TECHNISCH gerealiseerde functionele interface, niet alleen een CGM..).

Ik neem deze discussie liever een tandje dieper…..en dat is dee quote van je:

‘ Want bij systemen waarvan interface en implementatie uit elkaar lopen, boet de data aan betekenis in als deze niet door de bril van de applicatielogica bekeken wordt’

Daar zit hem het echte probleem; er worden data omgevingen gecreeerd die alleen interpreteerbaar zijn met applicatie logica. Wanneer stoppen we hier nu eens mee??? Hierdoor moeten we inderdaad weer een functionele interface hebben om er soep van te koken. Laten we data zoveel mogelijk proces-dood maken. Processen zijn erg volatiel, de data is dat veel minder. Institutionaliseer je gegevens…..Zou een hoop ellende kunnen schelen. Durf zelfs te stellen dat - als we dit doen - data warehouses verleden tijd zijn.

Maar das een andere blog.

Lidwine,

Dit is een zeer lastig onderwerp.

Om meteen maar met de deur in huis te vallen, De bron bepaalt vaak (een groot deel van) de aanpak.

Ik zie vaak een technisch+functioneel hybride model als beste compromis. Je houd een groot deel van je technische gegevenstraceerbaarheid, en je vangt de ergste technische problemen af door gegevens te functionaliseren.

In de praktijk gebeurt dit vaak door een (eenvoudige) view laag op een bron-datamodel of een Audit Trail. Dit vangt een aantal onduidelijkheden uit het bronmodel en de applicatielogica gedeeltelijk af zonder de (technische) traceerbaarheid al te zeer te verstoren. Dit is vaak wel een compromis tussen traceerbaarheid en functionele correctheid. Wel heb je zo beter inzicht in de kwaliteit en betekenis van de fysieke brondata.

Er zijn echter bronnen die zo lastig zijn dat deze benadering niet werkt. In feite is dan het fysieke datamodel niet direct gecorreleerd aan het logische model, maar komen er (complexe) transformaties aan te pas. Dan is het zaak een API te hebben die via abstractie het functionele/logische model aan het DWH voorspiegelt. Belangrijk is dan om te weten dat het technische gegevensmodel dan in feite gedegradeerd wordt tot een black (storage) box, en verder ook niet auditable is. Deze situatie zou voor veel organisaties eigenlijk volstrekt onacceptabel moeten zijn, maar gezien de huidige praktijk(o.a. SOA) vind met zulke API’s vaak prachtig.

Correcter is het om toch ook de (niet te begrijpen) fysieke gegevens over te halen in het EDW en de API gecontroleerd binnen het DWH uit te voeren om zo de functionele gegevens te reconstrueren/af te leiden in je EDW+
Daarmee heb je dan zowel je technische als functionele gegevens (met historie) van je bron te pakken. Dit vergt nogal wat van het DWH en de gebruikte API’s, dus ik zie dit niet als de meest realistische optie.

Woorden uit mijn mond Martijn:
‘Belangrijk is dan om te weten dat het technische gegevensmodel dan in feite gedegradeerd wordt tot een black (storage) box, en verder ook niet auditable is. Deze situatie zou voor veel organisaties eigenlijk volstrekt onacceptabel moeten zijn, maar gezien de huidige praktijk(o.a. SOA) vind met zulke API’s vaak prachtig.’

De echte boeven zijn diegene die dergelijke Generieke_SOA_proces_confused_je_bent_nu_afhankelijk_van_mijn_API_gegevens_modellen maken. Oppakken en opsluiten….

Ronald, Martijn,

Goeie input - dank! Ben het met jullie eens dat de bron uiteindelijk de aanpak bepaalt. Koopsysteem, grote chaos achter de schermen of 1:1 correspondentie tussen CGM en FGM, zullen ieder om een andere behandeling vragen.

Het probleem van de uit elkaar lopende interface en implementatie kun je m.i. op twee manieren tacklen:
- Je kunt developers die implementaties maken die afwijken van de functionele betekenis, oppakken en opsluiten (de Ronald-aanpak )
- Je kunt afdwingen dat systemen zijn applicatielogica in alle koppelvlakken uitvoert. Dus niet alleen in de user interface, maar ook in de koppelvlakken met andere systemen.

Van de eerste optie moeten we het volgens mij niet hebben; al was het alleen maar omdat ook in huis ontwikkelde software vaak van standaard libraries gebruikmaakt, die achter de schermen hun eigen implementatie meebrengen. De data access layer is daar een typisch voorbeeld van - precies de component die de data-opslag het meest beïnvloedt. Ook performance-optimalisaties kunnen een heel legitieme reden zijn om een afwijkende implementatie neer te zetten.
Bovendien, zoals Ronald al aangeeft: bij koopsystemen kun je sowieso geen eisen stellen aan de implementatie, dus moet je wel voor de tweede optie gaan.
Black data boxes are here to stay - het probleem is niet dat de data intern tot prut vermalen wordt, maar dat ‘t er ook als prut uit komt.
(Een derde optie is natuurlijk: je doet er niets mee, en laat ieder ontvangend systeem, waaronder het EDW, zelf de troep opruimen.)

@Ronald: de praktische kant van het verhaal is zeker een niet te onderschatten factor: je wilt je klant blij houden, en dat doe je niet als het DWH pas live kan nadat het bronsysteem een interface gebouwd heeft. Zelf de API bouwen is dan een pragmatische oplossing - maar gaat ‘t ook werken? Al was het alleen maar omdat we meestal stellen dat het een slecht idee is als het data warehouse de functionaliteit van het bronsysteem gaat nabouwen. Bovendien, om dat te kunnen doen, heeft het EDW toch weer de kennis van de jongens van het bronsysteem nodig - die jongens die nergens tijd voor hebben. Hoe zie jij die afhankelijkheid?

@Martijn: ik zou me kunnen voorstellen dat je inderdaad qua traceerbaarheid, compliance-eisen e.d. het beste af bent als je de “prut” binnenhaalt en binnen het EDW verder bewerkt. Ik ben alleen niet zo gecharmeerd van het idee van “de logica van de bron nabouwen” (tenzij de bron zelf de EDW+-API ontwikkelt en onderhoudt!). Bovendien, wat je al zegt, het zal inderdaad heel wat vergen van het DWH. Je geeft aan dat je dat niet de meest realistische optie vindt; zie jij nog andere mogelijkheden om zulke black storage boxes te handlen?

Lidwine,

De correcte oplossing is dat het DWH zowel de technische brongegevens alsook de functionele gegevens heeft (en het liefst ook hun relatie dmv transformatieregels). Wel moeten de transformatieregels/API van het bronsysteem zelf komen. Zelf nabouwen van API’s/transformaties is natuurlijk gewoon een vorm van werkverschaffing.

Ik onderscheid 3 niveaus van aanpak om dit enigszins te bereiken:

1. Een hybride technisch/functioneel model doorgeven aan het EDW. Zoals ik al aangaf is dit de pragmatische aanpak die gelukkig vaak redelijk werkt. Hierbij rol je het technische en functionele model enigszins “in elkaar” en geef je dat aan het EDW door als “de” data van “het” datamodel.

2. De eenvoudige duale aanpak:
Bepaal eerst welk model je als hoofdbestanddeel inleest in het EDW, functioneel of technisch. Daarna lees je alleen die gegevens van het *andere* model in wat niet een “simpele” mapping heeft naar het eerste datamodel (Daar waar het technische en functionele datamodel dus duidelijk van elkaar afwijken). De mapping zelf heb/maak je natuurlijk in bv. een ER-tool, dus die kan je er ook nog in je EDW bij zetten.
Het basisidee hierachter is dat bronsystemen ook de (toonbare) resultaten van niet triviale, niet persistente business rules/transformaties als gegevens mee moet sturen naar het EDW.
Dat geld dus ook voor vertalingen tussen datamodel lagen.

Deze oplossing kan een goed compromis vormen voor ‘black box’ systemen, mits de chaos daarbinnen niet compleet is.

3. De extreme oplossing (mooi, maar vaak niet zo realistisch):
Het bronsysteem levert zowel de technische brondata met ook alle (bron)business rules (evt. hele API!) aan het EDW (dus niet nabouwen!), het EDW is dan niet alleen een system of (bron)facts, maar ook system (of facts ) of bron business rules.
Het EDW past alleen maar de bron business rules nogmaals toe op de technische brondata, en slaat het resultaat op (in het EDW+).
Voila, de perfecte audit van brondata is dan een feit.

Lidwine,

In antwoord op je vraag; soms moeten we onze klant durven adviseren om het systeem niet te ontsluiten. Helemaal mee eens, maar het ontslaat ons niet van de plicht heel erg duidelijk te maken waarom niet.

Verder opteer in ik een eerdere blogpost (http://prudenza.typepad.com/dwh/2009/01/who-owns-the-data.html) er erg voor dat het bronsysteem verantwoordelijkheid (regie) neemt van de propagatie van haar gegevens tot en met het centrale DWH. De grenzen (boundaries) van het het ’systeem’ worden dus verder opgerekt. In onze nieuwe generatie EDW past dit uitstekend omdat we tot en met het CDW zo authentiek mogelijk met gegevens om willen gaan (in de oudere generaties EDW past deze regie-verandering dus totaal niet).

Het systeem blijft dus verantwoordelijk - zou het resource probleem moeten oplossen. Het BICC geeft natuurlijk ondersteuning, maar is vooral bezig met het post-cdw proces (waar BI zich voornamelijk zou moeten afspelen).

Naar mijn idee wordt bij bronontsluiting te snel naar technische oplossingen gezocht terwijl de governance aspecten (in dit geval regie) niet in orde zijn. Dan blijft het dus allemaal moeizaam.

Ronald,

Ik ben volledig met je mee eens, maar ik zou het zelfs nog wat sterker formuleren.

Ik vind dat de bron *ten alle tijde* verantwoordelijk blijft voor al zijn (bron)gegevens, *ongeacht* hun fysieke verschijningsvormen en opslaglocaties (dwz rapporten & publicaties, interfaces, Data Vault EDW etc…). Mits deze gegevens natuurlijk nog als zodanig ‘herkenbaar’ zijn. Dit houd idd post-cdw vaak op (maar niet altijd!). Jou opmerking zou dus eigenlijk een *gevolg* van goede data-governance moeten zijn.

De discussie zou zicht dus wat mij betreft op deze ‘herkenbaarheid’ moeten toespitsen. Dit is het terrein van de semantische equivalente transformaties van informatie (waar Data Vault er een van is). Ik acht het dan ook van belang dat elk data-governance initiatief een classificatie en inventarisatie van deze transformaties maakt. Helaas ben ik het in deze context nog niet in de praktijk tegen gekomen.

Ronald, Martijn,

Bedankt voor jullie toelichtingen - goeie discussie dit!

E.e.a. samenvattend, zijn we het er volgens mij in ieder geval over eens dat het overbrengen van de correcte betekenis van brongegevens de verantwoordelijkheid is (moet zijn) van de bron. Noch de functionele, noch de technische benadering gaat ergens toe leiden als dat stuk governance niet (goed) ingericht is.

Het verschil tussen de functionele en de technische benadering lijkt zich daarmee toe te spitsen op de plaats en het moment waarop de bron zijn verantwoordelijkheid neemt in het proces, en de uitgebreidheid van die verantwoordelijkheid:
- óf de bron voert op de systeemgrens direct een interpretatie van de fysieke gegevens uit m.b.v. een functionele API, en laat alleen de geïnterpreteerde gegevens door naar buiten (de functionele benadering)
- óf de fysieke gegevens worden onder regie van de bron naar buiten en in andere systemen gebracht, en pas op moment van gebruik wordt alsnog de interpretatie-API, eveneens onder regie van de bron, erop losgelaten (de technische benadering). Feitelijk verleg je dus de systeemgrens van de bron.

De gekozen aanpak is duidelijk van invloed is op het karakter van het CDW. In de functionele benadering is het CDW een system of real-world facts; in de technische benadering is het eerder een systeemlog van alle bronnen. Beide kunnen m.i. legitiem zijn, de keuze voor één van de twee “smaken” is geen “one size fits all”, maar zal afhangen van de rol die het EDW gaat vervullen in de organisatie, en de eisen die aan de architectuur gesteld worden.
Het is dus in ieder geval van belang dat men daar een heldere visie op heeft.

Verder spelen haalbaarheid en praktische begrenzingen een rol; bijv. een functionele benadering als enige alternatief voor een applicatie-omgeving met uitgangspunt “buy before build” (in ieder geval: totdat koopsystemen standaard een Data Vault connector meeleveren - wat voorlopig nog toekomstmuziek is). Idem voor een omgeving waar gestreefd wordt naar outsourcing van in-house ontwikkelde applicaties.
En niet te vergeten: voor veel organisaties is het al een hele stap om aan bronsystemen te verplichten een functionele API op te leveren - gedeelde verantwoordelijkheid voor het CDW is dan al helemaal een no-go.

Het grote voordeel van de opmerking van Ronald om de data delivery tbv het EDW te verschuiven naar het bronsysteem is, dat ze er nu wel tijd voor moeten maken.

Bijkomend/hoofd voordeel is dan dat eventuele functionele vertaling binnen de bron applicatie laag hergebruikt kan worden zodat er duaal werk voorkomen wordt. een technische of functionele benadering van de bron is dan eigenlijk geen issue meer.

Feitelijk is de regel “schoenmaker blijf bij je leest” hier van toepassing”:
DWH/BI is er niet om bronsystemen te doorgronden en bronsystemen zijn er niet om BI te verzorgen.

(Operational BI is dan even een bewust gekozen grijs gebied)

@Henk: “Ze moeten wel”, mwah…zouden ze die urgentie zelf ook voelen? Even gechargeerd: volgens mij zal het het bronsysteem van nature een zorg zijn wat er met hun gegevens gebeurt…totdat het expliciet verantwoordelijk gemaakt wordt voor een correcte functioneel gebruik van die gegevens door andere systemen. En dan maakt het natuurlijk niet meer uit waar de functionele vertaling nou precies gebeurt: in de interface tussen bron en EDW, of binnen het EDW in de Big T.

Ben het overigens absoluut met je eens dat hergebruik van de reeds aanwezige functionele applicatielogica de meest ideale oplossing is. Volgens mij zijn er op dat gebied nog wel wat praktijkproblemen te overwinnen.
@Martijn: jij had het over het aanleveren van de rules door het bronsysteem, zodat nabouwen van de applicatielogica niet nodig is - hoe zie jij dat praktisch ingevuld?
Ik kan me nl. voorstellen dat zoiets kan werken als je in je programmatuur (bronsysteem én ETL-processen) gebruikmaakt van een business rules engine; of als de bronsystemen zijn gebouwd op basis van services voor de uitvoering van specifieke business rules, waarbij die services ook vanuit de ETL aanroepbaar zijn.
Maar in de huidige systeemlandschappen zijn die twee nog geen gemeengoed - is de aanpak die jij schetst dan nog wel haalbaar?

@Lidwine,

Dat zou natuurlijk heel mooi zijn, maar het kan ook met simpelere middelen dan je denkt. Veel applicaties die een duidelijke discrepantie hebben tussen functioneel en technisch model hebben vaak een hoog abstractie OO model met een object role mapping tussen database en applicatie. Soms zit er nog een (extra) API bovenop deze mapping. Meestal is deze API of mapping te gebruiken, vaak om de applicatielogica aan te passen (customzing), of interfaces te schrijven. Dit hoeven dan nog geen webservices of BPEL modules te zijn, een .NET klasse kan ook heel goed.
Door nu via een abstractielaag (in het DWH) de DWH data aan de API aan te bieden alsof het brondata betrof, en dan via de API de data op te vragen en het resultaat van de API weer (gecontroleerd) op te slaan in het DWH kun je de feitelijke vertaling binnen het DWH laten lopen.
De grootste kunst is het daarbij om de gebruikte API voor de gek te houden als deze DWH data leest ipv brondata. Dit zal een flinke DBMS trukendoos vergen, maar het is zeker te doen.

@Martijn: dus eerst wordt bij het laden van het EDW het bronmodel omgevormd naar een DV-model, en daarna wordt het DV-model weer virtueel on-the-fly terugvertaald naar 3NF zodat het zich aan de API kan voordoen als zijnde de bron? En dat alles met behulp van truken op DBMS-niveau (views, neem ik aan).
Dat klinkt me nogal omslachtig in de oren; het lijkt me erg complex en oninzichtelijk worden. Bovendien vraag ik me af of traceability en auditability bij zo’n aanpak niet in de knel komen.

Dan zou ik eerder kiezen voor jouw optie 2, de duale aanpak. Dat lijkt me een eenvoudige en elegante manier om beide gegevensniveaus in het EDW op te nemen.

@Lidwine,

Dat scenario zou ik alleen bij eenvoudige bronnen zo aanpakken.
In lastigere gevallen kun je beter eerst een natuurgetrouwe schaduwomgeving van het bronsysteem binnen de datastage omgeving maken dmv bv replicatie, en daarvan het DWH vullen. Ik geef toe, dat lijkt wel weer wat op een niveau 2 aanpak, maar nu staat wel de vertaling volledig onder curatele van het DWH.

Bedenk, op niveau 2 kan er altijd een discrepantie optreden tussen de 2 modelniveaus, op niveau 3 kan dat dus bijna niet meer gebeuren, maar als het gebeurt kun je altijd nog een (volledig geisoleerde) herlaadactie starten.

wil nogmaals de strategie benadrukken om gewoon ‘njet’ te verkopen. ‘Behalve dat het technisch en functioneel complex is, zijn ook de kosten dermate hoog dat we dit gewoon niet willen laden in het DWH’.

Bagger bronsystemen verdienen geen plek in het mekka der data. Ik zeg isoleren en zoek het zelf maar uit, en dus wachten op de volgende opvolging van het betreffende systeem en wat preciezere eisen neerleggen tav de gegevens in dat betreffende systeem.

In dat geval zal de klant zich toch al snel afvragen waarom hij eigenlijk geld uitgeeft om een data warehouse te laten bouwen, als die lui van IT toch weigeren om de data die hij nodig heeft, erin op te nemen. Met een functionele benadering kun je de data-inhoud van de bron gewoon gebruiken, terwijl je jezelf afschermt van evt. technische problemen en eigenaardigheden in de bron. Nogmaals: principes als loose coupling zijn niet voor niets best practices in software-architectuur.
Dat een functionele interface in de meeste gevallen nog gebouwd moet worden, lijkt me voor de klant altijd nog gemakkelijker te verteren dan de boodschap dat hij zijn data pas krijgt als de bronsystemen inhoudelijk data walhalla-waardig bevonden zijn (if ever).