Notifications
Clear all

Help convincing client to avoid Source System Data Vault


Posts: 8
Topic starter
(@ryangross)
Active Member
Joined: 1 year ago

I am attempting to convince a client who was proposing to move to a "source system data vault", (as defined in this article: https://datavaultalliance.com/news/dv/source-system-datavault-and-business-keys/ ) of the value in using Business Keys.  Specifically, they are proposing to use Same-as-Links to enable the future joining of data in the business vault.  The argument they are making is that they do not have enterprise scoped business keys in a number of key areas.  

I have been trying to show the value in flexibility gained in the future by using the closest thing to an enterprise scoped key, looking for instances where the key is not available due to business process (i.e. treating applicants with no User ID as a different concept from Users who have accepted applications), and then driving change into the source systems to make the key closer to enterprise scope, but I am still getting pushback.  I'm wondering if anyone has some tips or stories of client (or your own organization's) pain introduced by using source system keys to help bolster my case.

I sent the article, which lists a number of reasons as to why a data vault implementation should stay true and utilize business keys exclusively.  I’ve listed below the article’s reasons as to why we should be using business keys with the client's responses for reference.  

 

Reason

Notes

Business Keys allow cross-line-of-business integration

This is still accomplished using SALs in the Business Vault

Business Keys provide better Master Data integration

This is still accomplished using SALs in the Business Vault

Business Keys provide 100% traceability across time (regardless of sequence surrogate changes) – just think VIN number for a single car over time….

This is still accomplished using SALs in the Business Vault

Business Keys are far more stable than Sequence Surrogates

Accurate, however, all of our selected business keys are currently sequence surrogates.

Business Keys align with the Enterprise Extended Ontologies and Taxonomies for business based integration and BI outcomes

Business keys still exist in the vault so does to preclude their inclusion in ontologies/taxonomies.

Business Keys (mostly) make sense to humans without having to be “looked up” in the system.

All of the business keys we’ve identified are integers (or sequence surrogates). None of the business keys we’ve selected codify an alternate key using alpha-numeric characters and/or delimitation.

Business keys will (when properly selected) REDUCE the number of tables in your Data Vault (Enterprise Data Warehouse)

It’s not clear where this reduction is occurring as the vault is modeled according to the business model and supporting entities. This is true in that it reduces the number of SALs required if we were to pivot to using source and source keys.

Business Keys TRACE the data across the enterprise from inception to completion, allowing you to measure the TIME it takes to “accomplish something” in your business.

This is accomplished using SALs in the Business Vault

 

Thanks,

Ryan

Reply
4 Replies