What to Do When Your Org Deviates from the Standard

I initially learned about Data Vault on the team where I currently work, and that ultimately led me to the obsession I have today with this “system of business intelligence,” including pursuing the practitioner certification.

After more than one year of working here, our team has been deviating from applying DV 2.0 requirements in the design, despite my objections. We have been building our own automation for DV, and I believe that may be the root cause of this issue. Rather than correcting the automation, we are forcing the DV to fit the design (my opinion).

Has anyone here faced these same kinds of issues? How have you dealt with it? Any recommendations on how to diplomatically correct the situation without losing your job?

As a responsible practitioner, my job is to ensure we do NOT call it a Data Vault anymore due to the deviation from the standards. I prefer, however, to attempt to lead the team back to doing things the right way.

This is an excellent dilema I see too and even conducted a poll about two years ago to see who sticks to the standards and who don’t.
It is quite tempting to deviate form the standards and I think the trend to do so falls on Data Engineers building Data Models rather than Data Modeller building Data Models.
Some of the more recent sins I have seen:

  • defaulting the BKCC to the system code
  • adding start and end dates to link tables
  • omitting link tables
  • enforcing column name changes to raw vault satellite attributes
  • ignoring business key treatments and losing passive integration

I have a list :slight_smile:

1 Like

It is a people management issue I guess and may be not for this forum.

I agree. It is a change and people management issue. Deviating from the standards can result in unintended consequences - such as loss of scalability, slower performance, increased code complexity (and more likelihood of bugs), etc. Depending on your local circumstances this may or may not be an issue. Unless you know what you are doing don’t touch things!

I know this is a long time ago, but I would argue that all change, and in particular in data models or anything else is about people and it should always be relevant to discuss the people side of things.

1 Like

Read this and found it to be very useful. DV practitioners be reminded of the deadly sins and avoid it

1 Like