“Is it Business Vault or is it Not?”
Good morning! In this week’s blog we’ll explore one of the most common questions that gets asked out in the field … “Is it Business Vault or is it Not?”
Let’s begin by defining what a Business Vault is,
“Business Vault is the sparsely modelled extension of Raw Vault providing the same auditability, agility and automation patterns to store derived Business Rule outcomes.” — there are various definitions, but this is probably the most accurate!
Now that the audience know the definition, let’s reveal the scenarios.
1. If it is derived content, then it fits in the Business Vault.
What do we mean by derived? If it is complex business rules, then yes of course! But there are a few requirements for these business rules that should serve as guide for developing them.
Raw Vault provides the modelled outcome of business processes from source systems , business vault extends those business processes to how the business sees them. Business rules supplied to Raw Vault are idempotent, business vault’s rules must be the same.
2. Business Vault are views
This could be problematic; Business Vault’s source is Raw Vault, but it can also include other Business Vault artefacts. This means to deploy a view-only Business Vault you begin to stack views on views. Not ideal. As volume and complexity grows the Business Vault becomes a house of cards, or another way to describe it, Jenga! You’re also subjecting yourself to vendor lock-in, if Business Vault were the model outcomes stored as tables, then it does not matter what you use to get that output. You can even swap the business rule engine out and still produce the same result!
3. PITs & Bridges are Business Vault
No, these are query assistance tables that help improve and simplify the ability to query out of Data Vault that includes Raw and Business Vault. It’s important to make that distinction, query assistance tables are collections of keys that you may include simple derived content with them, they are disposable (like the rest of Information Mart layer) and therefore not Business Vault artefacts because they do not support data vault agility, automation, and auditability! Derived content here does not need to be idempotent, this type of content lives in the Information Mart layer.
4. Business Vault does not need auditability
This is very incorrect! If you were to produce regulatory reporting or anything that affects the bottom line you must have the audit trail of how those figures got there. If Business Vault were views, then any change in Raw Vault may in fact destroy that audit trail completely! Delivered as tables you’re able to inherit the same loading patterns as Raw Vault, inherit the same applied date as Raw Vault and participate in timeline correction if needed (using XTS). RV + BV = DV, to query a DV use QA tables such as PITs and Bridges.
5. Business Vault completes the Business Process as the Business sees it
Yes, but not the only usage of a Business Vault. If a derived business rule needs the agility, auditability, and automation of Raw Vault then use Business Vault.
6. Business Vault is sparsely populated
Only use a Business Vault where needed, ideally business process gaps should be solved at the source so the time between business event and analytical output is minimised. But we do recognize operational reality may not allow for this to take place and that is but one use of Business Vault. To automate the data vault artefacts where Raw Vault cannot, if the source could solve this gap, then the modelled Raw Vault supersedes the Business Vault artefact.
7. In Business Vault you will find Hubs, Links and Satellites.
Not quite, hubs are the unique list of business keys, and they are not generated/derived in data vault. Hubs form the integration point of multiple source systems passively integrating the business process automation outcomes. Yes, you will find Business Vault links and satellites but no hubs, Business Vault simply extends Raw Vault-Hubs with derived idempotent business rules.
8. What happens when Business Rules change?
In Raw Vault we simply ingest the source as is with the change and the outcome could be one of the following:
· a change is recorded because the business rule change caused a change in the outcome;
· no change is recorded, despite the rule change no outcome changed.
The same is expected in Business Vault and the change in a business rule here is independent of what happens in Raw Vault. The business rule change metadata is recorded in the record source column as a business rule version number. A business rule change in Raw Vault or Business Vault will have a ripple effect to dependent Business Vault and Information Mart artefacts while still maintaining the audit history because they are tables and not views.
In an ideal world there would be no Business Vault! Raw Vault will contain ALL the automated business process outcomes and there is no need to derive more content in a Business Vault!
The views expressed in this article are that of my own, you should test implementation performance before committing to this implementation. The author provides no guarantees in this regard.