« "Data Kwaliteit moet omhoog" | Main | A new beginning »

Saturday, March 10, 2012


Feed You can follow this conversation by subscribing to the comment feed for this post.


Indeed: break the rules but be sure you understand the impact... Think, then act, not the other way around as we so all to often.

If rules (or better: best practices) can enforce some basic DWH quality (by re-using others knowledge) I can live with that.



I didn't realise this pattern had a name, and an ancient japanese one at that ;)

At the MATTER program we actually use levels that more or less correspond with Dreyfuss's original skill stages, but that is lets say less "poetic". This also means that we do not have level 600 courses, since you can't really teach mastery, you can only attain it.

A problem I see in this, and it is IMO apparent in the Kimball Methodology (note I didn't say Architecture, but that is for another time) that in the "Mastery" phase you might be tempted to overuse/overstretch your methodology into realms it should not be applied. This gray areas (The Dark Side?) is a dangerous place to go to, even for a Master in the chosen methodolodgy. Luckily the basis for Data Vault (modeling) lies in normalization and hence should be quite robust, unlike dimensional modelling, whose basis lie in denormalization and versioning.

I suspect the question of existence of the basic methodology when you are in the Ri phase (Dreyfus skill lvl 6/7) becomes one of perception, it has probably no real meaning.

Dan Linstedt

Nice post Ronald, great observations.

My thoughts are as follows:
1) I am currently breaking my own rules, in an attempt to innovate within the walls of the Data Vault - this is what I call "lab work", or work in progress.
2) when I break the rules, yes, sometimes I discover new opportunities - but more than that - when the rules are broken and new discoveries are made, they then need to subject themselves to "tests". Rigorous testing. Just as in martial arts - when a master creates a new set of moves, they need to ensure: a) they do not "hurt" oneself, b) they contain optimal flow and balance, c) they actually can attack and defend as necessary for specific points of interest.

One who breaks the rules: should always test the results, otherwise the rule that is broken may come back to "bite them" in unwanted ways.
3) breaking the rules is the form of innovation, without it, we cannot move forward.
4) real-life is not "golden utopia", and thus, rules MUST be broken, but when they are, the broken rules *should* be documented, so that the entire team understands WHY the rule was broken.

Anyhow, just my thoughts on the subject.

And what's in my lab? Data Vault & Real-Time, Data Vault & Unstructured Data, Data Vault & humungous data sets
And yes, I'm also looking at Data Vault & Hadoop, etc..

Dan Linstedt

The comments to this entry are closed.