Ch 13 - Seeing the Business
Chapter 13 of Mixed Model Arts
When I was growing up and learning martial arts in the 1980s, the common advice was “Always look at your opponent’s eyes.” This was echoed in movies like Karate Kid, which an impressionable kid like me would internalize and use in fights. That ended up being terrible advice. Your opponent can deceive you in ways you won’t notice if you just look at their eyes. You need to look elsewhere for early clues to anticipate your opponent’s moves. My boxing coach told me to generally focus on the opponent’s shoulders and chest, since they signal weight shifts, shoulder rolls, hip turns, and level changes. As more of the limbs are involved, you’ll need to widen your perspective. In wrestling, you want to focus on your opponent’s hips, chest, and lead leg. In Muay Thai or mixed martial arts, you need to look at the whole frame, since an attack might come from anywhere. And you also need to open up shots and opportunities for yourself by using jabs and feints, and by learning your opponent’s timing and reactions. You need to learn to see.
Sadly, many people working with data don’t see the bigger picture. Technical people make this mistake constantly, building infrastructure and schemas without understanding the business processes those systems serve. You can build a data model that looks technically sound, and it can still be wrong because you never understood what the business actually does.
Here’s a fictitious story that is also all too real for massive enterprises. A major airline—let’s call them Hellta—bet the farm on a massive migration to a new, state-of-the-art data platform. The data team, full of brilliant software and data engineers, spent nearly two years laser-focused on the technical details: optimizing lakehouse schemas, writing complex ETL/ELT and streaming pipelines, and ensuring the various systems could connect and scale.
Technically speaking, they succeeded brilliantly. The launch was a disaster. Although the new data platform worked as designed, the numbers it produced didn’t make sense. Teams across the business, depending on the data, were flying blind. The business’s trust in the engineering team evaporated almost overnight.
What went wrong? The engineers had perfectly modeled the physical systems. They created perfectly partitioned lakehouse tables and “data models” that worked flawlessly within the new platform’s performance constraints. But they failed to model the business’s messy, interconnected processes and capture the vocabulary across various domains of meaning, spread across different teams. We’ll return to Hellta at the end of this chapter, once you have the diagnostic vocabulary to understand exactly how—and how expensively—they failed.
We Model the Business, Not Just Data Systems
“The map is not the territory.” — Alfred Korzybski
Remember the e-commerce company from Part 1? Their data modeling disaster didn’t start with a bad technical decision, but a failure to understand the business. People mapped out entities, but not the ones that mattered, how they related, or who needed what. The JSON blob was a symptom of a bigger issue of ignoring the business.
Too many data practitioners think of data modeling solely in terms of system implementation. They focus on database schemas, data pipelines, or dataset joins. While these technical details are necessary to get work done, obsessing over them before a proper data model is in place is backward. The model comes first, and the systems that serve it come last. We’ll discuss this flow more in the next chapter.
Underneath the data’s structure lies the reality that the model is trying to represent. When we model data, we must first understand what we are modeling. This chapter ties together the building blocks you’ve learned so far, helping you to “learn how to see” the processes and domains that crisscross every organization.
Back to the five data modeling camps, which often diverge in how they work with the business. None of them is wrong, but they’re also not complete by themselves. The Mixed Model Artist doesn’t choose one camp. Instead, they integrate all these perspectives into a unified view and set of actions for the business. You do this by first seeing the processes and domains, which allows you to recognize which modeling approach serves which part of the business. Historically, data professionals stayed in their respective camps because they were only asked to build for a single type of consumer. But the Mixed Model Artist doesn’t have that luxury, because the lines between consumers have blurred.
Three Audiences for Every Model
Our data models in the era of Mixed Model Arts must serve three distinct audiences, sometimes collectively and other times separately. When defining the model’s boundaries, it is essential to remember who or what we are modeling for.
People are visual thinkers. Flowcharts, diagrams, and whiteboards allow people to “see” the business process and validate if the model matches reality. Processes might also be documented, combining words, tables, and visualizations. For humans, the model is a map that helps them navigate the nuances of a process and its operation across domains.
Applications and data systems need structure. Traditional applications (ERP, CRM, or custom web and mobile apps) are the engines that drive business processes. They don’t care about the visual map or the nuance of diagrams. But they do need a precise data model to ensure data integrity and performance. In applications and data systems, the data model dictates exactly how to store and retrieve the process’s state.
AI requires much more than traditional data modeling can provide. This is the new frontier. Unlike applications and data systems, which follow rigid rules, AI agents benefit from context. Right now, this is provided through a combination of documentation, metadata, structured data from applications and data systems, and additional semantic context that ties all of this data together (such as semantic layers, ontologies, and knowledge graphs). For AI, this collection of structured and contextual data provides the context needed to make decisions or answer questions.
Historically, we treated these as separate disciplines. Business analysts created visual dashboards and reports for human decision-making, and software and database engineers built the applications and data systems. AI wasn’t in the picture, except as bespoke ML models deployed for specific tasks. Documentation was usually ignored or left in outdated wikis that nobody read. This was the classic silo trap. To model effectively, we must unify these silos. A change in the business process must be reflected everywhere humans and machines consume data.
Business Processes and Domains Explained
The terms “business process” and “domain” are ubiquitous in technology and data modeling, yet often overloaded. Let’s clarify exactly what they mean in the context of Mixed Model Arts.
A business process is a sequence of actions performed by specific actors (people, systems, agents, or machines) that transforms inputs into outputs to achieve a business outcome. This sequence is fundamentally about horizontal flow: an event is triggered, ordered steps are taken, something changes, and a result is achieved. We will use the terms “business process” and “process” interchangeably.
You encounter processes every day: applying for a loan, ordering online, getting a driver’s license, or buying groceries. Sometimes processes are clearly documented; other times, they are understood and followed implicitly. But regardless of documentation or consistency, a process describes how work actually gets done.
A domain is a boundary of meaning, often a specific area of an organization where language, rules, data, and responsibilities are consistent and coherent. Unlike processes, domains are not about horizontal flow. Instead, a process might encompass several domains. Sometimes a domain is macro, like a major department (Sales, Operations, Marketing). Other times, a domain forms at a specific functional level, called a subdomain (Inventory, Order Fulfillment, Compliance).
In data modeling terms, a business process is where events originate, and data is created or changed. A domain is where meaning lives and is protected.
Business processes naturally intersect multiple domains. In a typical scenario, we see a generic business process flowing through the Sales, Fulfillment, Logistics, and Finance domains.
Figure 13.1: Domains flowing through a business process
You might wonder if the process or domain comes first. It is a chicken-and-egg scenario. Sometimes processes dictate the domain; sometimes domains constrain the process. In reality, they co-exist and co-evolve. But for the data modeler, the order of creation doesn’t matter as much as the method of discovery. For example, if you’re creating a data model for a data warehouse, you’re integrating data from multiple domains. Here, I find it’s easiest to start with understanding a business process. Domains are easiest to discover after analyzing the business process. As you trace the flow of work through a process, the domain boundaries naturally appear at points where meaning, rules, ownership, or actors change. In other cases, such as modeling a microservice, your modeling scope will be narrower, focusing on a domain or subdomain.
A common question is, why not jump straight to implementing the data model in your data system? If you want to be like Hellta’s engineering team, go for it. But hopefully their story illustrates why jumping straight to physical implementation isn’t a wise approach.
Why Model Processes and Domains?
In the last section, we dove into the gory details of the modeling building blocks. We discussed instances, identity, attributes, relationships, time, events, grain, and counting, among others. But on their own, these building blocks are helpful but incomplete. They are like having a pile of high-quality bricks and 2x4s without a plan for how they come together. Do you build a house, a shed, a skateboard, or a wooden car? I’ve seen far too many data models built by haphazardly nailing randomly cut 2x4s and stacking bricks on top of each other without a plan. The result is what you expect: a teetering mess.
