Here’s the latest draft excerpt from the upcoming chapter on Modeling Business Processes and Domains. This chapter should be easy to write, but there’s a nagging sense I need to put more mental cycles into anticipating changes that might be looming due to AI agents running rampant in the enterprise. Might agents create their own processes and domains? And might the reverse question need to be asked - how does the data model impact the processes that agents act act upon or create? Hell if I know. These are brand new questions that nobody needed to ask before recently, so I’m deep in thought right now on how this all might work. If you have ideas, drop them in the comments.
I expect the draft chapter will be done sometime next week. I can’t say it will be final, but you’ll at least learn how to model business processes and domains, which is critical for any data modeler’s skillset.
Thanks,
Joe
How many times we’ve inherited poorly documented source systems (and even DWH, data vaults) and struggled to make sense of them. Well, look no further. Ellie.ai connects to 160+ systems and creates synthetic metadata with AI and our copilot with source navigator helps you answer questions like “what do I need to calculate profitability?”. You can even create effective models chatting with AI!
Ellie.ai to the rescue!
Thanks to Ellie.ai for supporting Practical Data Modeling!
We Model Reality, Not Just Data Systems
“The map is not the territory” - Alfred Korzybski.
Too many data practitioners think of data modeling solely in terms of system implementation. They focus on the database schema, data pipelines, or how datasets join. While these technical details are necessary to get work done, obsessing over them before a proper data model is in place is backwards. The model comes first, and the systems that serve it come last.
Underneath the data’s structure lies the reality 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. In the spirit of Mixed Model Arts, we will “learn how to see,” adopting an agnostic approach that refuses to silo classical and modern techniques. The world is increasingly integrated, and our modeling approach must reflect that. And it all starts with understanding what we’re modeling.
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, or AI agents) that transforms inputs into outputs to achieve a business outcome. This sequence is fundamentally about flow: an event is triggered, ordered steps are taken, something changes, and a result is achieved. We will use business process and process interchangeably.
The world is made up of processes. You encounter them 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. It is a specific area of an organization where language, rules, data, and responsibilities are consistent and coherent. Unlike processes, domains are not about flow; they are about semantics and ownership. Sometimes a domain is macro, like a major department (Sales, Operations, Marketing). Other times, a domain forms at a specific functional level (Inventory, Order Fulfillment, Compliance).
In data modeling terms, a business process is where events originate, and data is created or changed, and a domain is where meaning lives and is protected.
Business processes naturally intersect multiple domains. In Figure x-y below, we see a generic business process flowing through the Sales, Fulfillment, Logistics, and Finance domains.
Figure x-y: How business processes and domains relate to each other.
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. 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.
Why not jump straight to implementing the data model in your data system? Let’s understand why we first need to understand the processes and domains we’re modeling.
Why Model Processes and Domains?
In the first part of this book, we dove into the gory details of the modeling building blocks. We discussed instances, identity, attributes, relationships, time, events, grain, and counting. 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. Sadly, I’ve seen far too many shoddy 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. And I suppose to extend the analogy to a more ridiculous degree, you could try to build a data model that encompasses every idea, workflow, and anything else in the universe. But that’s neither feasible nor practical.
Obviously, we need a way to constrain what we’re modeling. These constraints are boundaries. To build something that brings shared meaning to both humans and machines, we need to assemble these blocks within a boundary intentionally. Business processes and domains provide the necessary boundaries for a data model, defining its scope and context. Processes represent the workflow’s scope (e.g., “We are only modeling the ‘Checkout’ flow, not the ‘Return’ flow”). Domains provide the boundary of language (e.g., “What does ‘customer’ mean here?”). Together, a process and its domains describe a shared meaning for who or what consumes the data model.
As a reminder, when we set the boundaries of our model, we need to consider who or what we’re modeling. In the era of Mixed Model Arts, our data models must serve three distinct personas, sometimes independently and other times altogether. But each audience requires the boundaries of processes and domains to be communicated in different ways.
- 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 how it operates 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 Agents need Semantics. As I write this, this is the new frontier. Unlike applications and data systems, which follow rigid rules, AI agents (namely LLMs) require context. Right now, this is provided through a combination of documentation, 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) to understand the “rules of the road.” For AI, this collection of structured and contextual data provides the context needed to make decisions or answer questions about the data.
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 ML models deployed for specific tasks. Documentation was usually ignored or left in outdated wikis that nobody read. This was the classic silo trap, and I wager it’s responsible for many of the problems that led organizations to fail to get value from technology initiatives. AI is changing this, and the possibilities are just now being discovered, as we’ll explore through this book. To model effectively, we must unify these silos. A change in the business process must be reflected everywhere humans and machines consume data.
As organizations grow, so does entropy. Simple processes become complex, leading to communication breakdowns and poor team coordination. While small-scale processes can be managed informally or verbally, this approach quickly fails as the organization scales. For large organizations, a map is essential. Process modeling enables zooming out for domain-level context and zooming in for process-step minutiae. This ability to adjust the zoom level is crucial for modeling a complex organization without becoming overwhelmed.
These modeling concepts align with Domain-Driven Design (DDD), a software engineering approach popularized in the early 2000s that advocates modeling software around a “bounded context.” In the data world, similar ideas are resurfacing through trends like Data Mesh. The core philosophy remains the same: it’s impossible to model the world as a whole at once.
Complexity must be made manageable, governable, and understandable by breaking it down into domains and processes. Whether you call it DDD, Data Mesh, or just specific common sense, the goal remains the same. You cannot model the whole world at once. But if you respect the process’s boundaries and the domain’s meaning, you can finally build a model that reflects reality rather than just serving the database.
Let’s next dive into using business processes and domains to build a data model.
(to be continued…)