Starting from scratch to build its Data Vault business object model or datawarehouse is a luxury that only a few companies have. Indeed, all companies, especially the largest ones, are suffering from their existing data flows (extractions merging and/or aggregating unit data, etc.) from the operational systems to their BI system(s).
So, let’s put our foot in it right away: we don’t build a Data Vault system with the aim of decommission BI legacy because we don’t just ”replace“ an existing BI systemwith a Data Vault system!!
Why: simply because these 2 subjects, although complementary, are very different in terms of uses and objectives!
- The BI system, by design, is “reporting and business management needs” oriented
- The Data Vault system (see our other articles on this subject), is corporate objects and business processes oriented
However (and this is the right approach to consider), we can start building a Data Vault system and, as long as the business objects are integrated, we will be able to build the upper “Information Mart” layer which *as itself*, being the layer supporting business needs, will allow to replace/disable BI legacy systems.
There are 2 major traps in which you must avoid falling when you want to make concur both the Data Vault system implementation and the BI legacy disablement.
- To remain in a siloed “flow” / “source application” vision and therefore want to migrate/disable BI system after BI system by migrating the existing unit flows to the Data Vault system. This can only lead to the repetition of possible past errors and distort what should have been a global model.
- To wish to avoid impacting the operational “source” systems on their extractions while the existing extractions were produced in a former and different context / logic that don’t necessarily suit the implementation of transversal rules.
When you have some experience on Data Vault, the 1st point is natural and linked to the basics of a Data Vault implementation: the definition of an object and its business key is thought in a global way and the overall context of the company, not only in the context of a single operational application.
Example :
- in the Insurance industry, the concept of a client of a contract may vary according to the types of contracts (collective, personal, etc.) in the dedicated management systems. Thus, the implementation in systems will differ, as the client can be the subscriber client (1..1 relationship with the contract) or the client can be the grantee client (1..N relationship with the contract);
- moreover, even if the different concepts of contracts may be close to each other, they will not have the same business keys: in some cases, the contract number will be the only element of the key and in others cases we will need to add a complementary notion like a contract sub-type, not to mention the same contract number may exist in two different management systems (Property&Casualty and Life for example); so it will be necessary to set up a complementary discriminating key…
Conclusion :
Whether you are *or are not* in the context of a will to disable a legacy, the implementation of a Data Vault system keeps the same guidelines:
- Put data governance in the middle of the equation:
- What are my business objects?
- What are the “master” systems (creation, modification, deletion) of the data and what are the consumer systems? What is the transmission of the data between the different services and therefore its propagation in between the different operational systems?
- Work with all businesses that use business objects to detail the processes and definition of these business objects with them (or definitions because there is often a divergence between the different businesses…)
Concerning the 2nd trap (but not the last 😉), let us put once again the foot in it: unless we already have raw extractions from management systems (in line and column), unaggregated, unmerged, Budgets should be planned for operational systems to recreate extractions which will be consistent with the Data Vault system to be built.
To sum-up:
- Do not get BI system and Data Vault mixed up – do not replace one with the other!
- The Data Vault design is and will remain for a long time the most relevant modelling way to implement a business object model.
- A BI system is characterized rather by a star/snowflake schema or even “flat” views (these can now be more effective on some analyses based on raw data) …
Do not hesitate to contact us to learn more 😉
Recent Comments