In last months I have been dealing very much with the general issue of how to build a data platform that actually brings value to a company.
I have also been reading and working a lot with Data Vault so I agree on the notion that the key value provided by a data platform is the ability to help the business take decisions, both looking at historical data and powering models of the future.
A data platform can deliver value also through more direct support of operations like providing audits and insights on processes, and in more advanced settings, serving meaningful data for APIs and ML / AI processes.
Actionable Information is the value
Business and operations can extract value from data only if they understand what the data represents and if they can connect the raw data with what they do, with the decisions they have to take. This is information.
I believe that the ability of the Business to derive information from data, and thus to provide value to the enterprise, is directly proportional to how easy it is for them to understand the data model they need to interact with and this increases very much if the model and language is close to the business way of thinking and talking.
The Data Vault methodology puts the conceptual modelling square at the center of the data platform and strives to use the business concepts as anchors to integrate the different, disparate operational systems, towards those common business concepts.
The adoption of a business conceptual model at the center of the data platform has the obvious benefit to lower the effort needed to turn source data into actionable information, but also greatly improves the resilience to change of the data platform. The business concepts are in fact pretty stable and tend to remain valid despite changes in the operational systems and processes.
To recap value comes from the ability to turn data into information and this is simpler when the distance between the business concepts and the data model is small. A model based on business concepts is also more resilient to change.
How to identify the business concepts?
If the business concepts and their relations are so important to build a solid core of a data platform, how can we discover them?
In this article I want to present a possible method to identify concepts and their relations that I call “Concept storming“. Yes, the name is a reference to the “Event Storming” method invented by Alberto Brandolini, but a lot of insights come also from “the Elephant in the Fridge” by John Giles and more in general from the business centred philosophy of Data Vault 2.0.
The idea is to keep the same light weight and tech free approach of the event storming to keep workshops about the people who know about a domain, with the goal to explore Business Concepts and their Relations instead of Domain Events and Commands.
The premises for a good workshop are also the same with Event storming, i.e. invite the right people (mixing who knows the questions to ask and who knows the answers) and get a large room with plenty of post it and room to draw.
The basic next step are as follow:
- discover business concepts: start by identifying the concepts that feel important for the enterprise in the domain; they will be at different level of abstraction, and you can organise them around some basic data model patterns.
- discover relations: uncover the relationships the business cares about, discover how the business concepts and relations are connected to each other.
With these initial steps, repeated iteratively, you identify the concepts that the business people use to describe their job, you also create a common language that both business and tech people are able to clearly understand.
Then you can proceed to refine the concepts and relations by organising the concepts in a hierarchy, identifying important super-types, sub-types, important specialisations and the relations that connect them.
Then you can identify the main attributes and business keys, i.e. how the business identifies each concept, and what they think important to know about it.
Finally, as John suggests, you can test and ulteriorly refine the model by “throwing at it”:
- pain points: understand the pain point; why there is a pain today, why it will be better tomorrow?
- business processes: pick a couple of important process and verify you have the concepts and relations to describe them.
The last steps are useful to verify the model is sound and also to discover more sub-types, specialisations and eventually also new relations.
This exercise should stay light and help you build a sufficient enterprise data model that is wide enough to cover all the domain, and allows you to dig deeper with pain points and/or processes only in minimal areas and if it feels needed to uncover more details or double check the model.
In a next post I will try to be more specific on the steps and instructions for the participant, but if this basic ideas resonates with you, I’d like to know and discuss your ideas.
Ciao, Roberto
Roberto "robmczag" Zagni 