In my previous post, I discussed how data modeling bridges business and IT -and how it can also bridge strategy to execution. I mentioned that it must scale, but not how.
A key prerequisite for scalability is something I mentioned earlier: we must let leaders and experts define their business problems in a way that feels natural to them - without requiring them to think and act like data modelers. Otherwise, engaging people across different functions becomes impossible.
But in addition to that, we also need a structured way to break down complexity - something that keeps things simple while ensuring everything connects, from the big picture down to details.
What has worked well for me in practice is focusing on just a few fundamental questions (of course, it’s never quite this simple, but at its core, it comes down to this):
🟢 What factors explain the behavior of my business problem?
🟢 How do these factors interact and depend on each other?
Why This Works (A Practical Example)
Let’s assume a company is pursuing a cost leadership strategy, with the goal of optimizing its supply chain.
At the highest level, the factors influencing this strategy are the sub-processes and functions that determine supply chain efficiency—such as procurement, logistics, and inventory management.
Breaking things down further, we identify the business entities relevant to each sub-process:
- In procurement, key entities might include suppliers, contracts, and purchase orders.
- In inventory management, key entities could be warehouses and inventory items.
Then, we go a step deeper—pinpointing the specific variables that explain the behavior of these business entities:
- For suppliers, this could be delivery times, defect rates, and cost per unit.
- For inventory items, it could be stock levels, reorder thresholds, and turnover rates.
By applying this same structured approach at every level, we are able to break the problem into progressively smaller pieces - until we fully understand each part, as well as the whole they form.
Those of you who are data modelers can surely see how a business problem defined this way translates into a data model.
Of course, things are never quite this simple. Entities have categories, roles, super and subtypes, all of which potentially form new entities. The relationship between two entities may require additional entities, etc.
But based on my experience modeling with a large number of non-data people, this gap can be filled with simple question lists, modeling templates, and other guiding tools.
Complemented with these tools, this a-few-fundamental-questions based approach has worked surprisingly well for modeling even complex business problems.
I will share more details about these tools in a future post.
