Business Context Isn't New. So Why Are We Acting Like It Is?

Why it's time to bring data modeling back to the heart of enterprise data architecture.

By: Keith Belanger

It seems everywhere I turn these days, someone is talking about Business Context. Whether it's a conversation about AI agents, semantic layers, or the next generation of enterprise analytics, we're hearing the same message: If we want accurate, trustworthy results from our data, we need to provide the appropriate Business Context. And I couldn't agree more. But as someone who has spent three decades working in data and enterprise data architecture, I can't help wondering why we're having some of these conversations so late in the data lifecycle.

Don't get me wrong. I'm a strong advocate for semantic technologies and the role they play in providing consistent, governed business meaning to traditional analytics and emerging AI-powered solutions. They help establish common definitions, govern metrics, and provide the relationships necessary for consumers to interpret enterprise information correctly. But I keep coming back to a question that I believe deserves more attention. Shouldn't much of this Business Context have been established long before we reached the semantic layer? And shouldn't that understanding already be reflected in the data models and physical structures we've designed to represent the business?

My concern isn't with semantic layers themselves. It's that we may be asking them to compensate for architectural decisions that should have been addressed much earlier. As Enterprise Data Architects, have we become so focused on how quickly we can ingest, transform, and deliver data that we've lost sight of the importance of data modeling throughout the entire lifecycle?

We've Been Here Before

I started my data career in 1996, and one of the first lessons I learned was that understanding the business came before designing the data structures intended to represent it. We didn't begin by examining source tables and figuring out how to move them into a warehouse. We began by talking with the business. We worked to understand how the organization operated, the concepts that mattered, the relationships between them, and the rules governing those relationships. Those conversations weren't limited to a handful of requirements gathered from one department. Understanding the business meant speaking with people at different levels of the organization, from leadership responsible for strategic direction to the people working with the business processes every day.

That understanding became the foundation for our conceptual data models. From there, we developed logical models that defined the entities, attributes, and relationships necessary to represent the business, and ultimately physical models appropriate for the technologies and workloads we were supporting. The process wasn't always perfect, and we certainly didn't know everything before development began. But there was a deliberate effort to understand what we were modeling before deciding how to implement it.

And these weren't new ideas even when I entered the profession. Bill Inmon had already helped establish the foundations of enterprise data warehousing, emphasizing integrated, subject-oriented data structures. In his 2000 interview discussing enterprise data warehousing and the Corporate Information Factory, Inmon described an architectural approach in which integrated enterprise information provides the foundation for downstream analytical needs. The importance of designing an integrated representation of enterprise information was already well established.

Ralph Kimball continued advancing business-oriented analytical modeling, demonstrating how dimensional models and conformed dimensions could make enterprise information understandable and consistent across business processes. In his 1997 article, A Dimensional Modeling Manifesto, Kimball emphasized the importance of designing analytical structures around recognizable business processes and shared dimensions. His work helped reinforce the relationship between understanding the business and designing data models that could consistently support analytical requirements.

Dan Linstedt subsequently introduced Data Vault, building upon decades of data warehousing experience with an approach focused on business keys, relationships, historical tracking, and enterprise integration. In his early 2002 Data Vault Overview, Linstedt described the evolution of enterprise data modeling and introduced the foundational structures of Data Vault. His later article on Link Tables explored how business relationships are represented within a physical Data Vault model, reinforcing the importance of understanding those relationships as part of the modeling process.

I see these contributions as part of the continuing evolution of our profession. Each brought valuable ideas, methodologies, and techniques that expanded how we approach enterprise data architecture. I don't see them as competing philosophies that require us to choose one over another. I see them as part of the collective knowledge that has shaped how we model enterprise information. And throughout that evolution, one principle remained fundamental: We need to understand the business before we can effectively design the data structures intended to represent it.

That's what makes today's conversations about Business Context so interesting to me. We've spent decades developing and refining approaches to business centric data modeling, yet we're now discussing the importance of Business Context as though it emerged with AI and semantic technologies. In reality, those technologies are reminding us of something our profession has understood for a very long time.

Somewhere Along the Way, Did We Lose Sight of the Business?

Over the past decade or more, I've watched something happen in our industry that genuinely concerns me. Data modeling, once considered a fundamental part of the data development lifecycle, has increasingly been brushed aside or treated as an unnecessary step that slows down delivery. I've encountered organizations building sophisticated enterprise data platforms with little emphasis on conceptual or logical modeling, sometimes without any formal data modeling discipline at all. The priority has become getting data ingested, transformed, and delivered, with the assumption that we can figure out the business meaning somewhere along the way.

Perhaps even more concerning are some of the conversations I've had with students graduating from undergraduate and graduate programs in data engineering. I've spoken with individuals preparing to enter our profession who have received little, if any, formal education in the fundamentals of data and data modeling. Think about that for a moment. We're educating the next generation of data engineers to build and operate increasingly complex data platforms, yet some are entering the workforce without having learned how to design the data structures those platforms depend upon.

To me, that's like pursuing a career in architectural engineering without learning how to read or create a blueprint. Would we consider constructing a building without first understanding what we're building, how its components relate, and how the structure is intended to function? Of course, buildings evolve during construction, and designs change as new requirements emerge. But we wouldn't use that as justification to abandon the blueprint altogether. Yet somewhere along the way, we've seemingly normalized building enterprise data solutions without the data models that should be guiding their design.

And this is where I believe we need to challenge ourselves as an industry. I'm not suggesting that every project requires months of upfront modeling or that we should return to rigid development processes. Modern data modeling can and should be iterative, collaborative, and supported by automation and AI. But there's a significant difference between making data modeling more efficient and deciding that we no longer need it. One represents progress. The other risks losing the very discipline that helps ensure we're building the right solution in the first place.

Give Your Semantic Layer a Little Help

This brings me back to semantic layers and why I believe this conversation is becoming increasingly important. As organizations introduce AI agents and expand self-service analytics, semantic technologies are being asked to provide consistent business definitions, relationships, metrics, and rules across increasingly complex data environments. These are important capabilities, and I believe they have a valuable role to play in modern enterprise data architecture.

But imagine an organization that has spent years developing independent data solutions, each designed to satisfy a particular business requirement. Over time, business concepts become fragmented across tables, transformation pipelines, reporting applications, and individual data products. Different teams establish their own interpretations of customer, product, revenue, or other important business concepts, often without realizing that similar definitions already exist elsewhere in the organization.

Now the organization introduces a semantic layer to provide a consistent business interface for analytics and AI. Suddenly, it needs to reconcile those different representations, establish common definitions, and account for relationships and business rules that were never consistently reflected in the underlying data models and physical structures. The semantic layer may be capable of addressing many of these challenges, but we're asking it to do additional work because we didn't establish that consistency earlier.

What if those conversations had started before we designed the integration structures? What if we'd taken the time to understand the business conceptually, developed logical models that reflected that understanding, and used those models to guide our physical implementations? We might still have different physical representations optimized for different purposes, but those differences would be intentional and grounded in a shared understanding of the enterprise.

I don't believe a well-designed physical data model eliminates the need for a semantic layer. They serve different purposes and complement one another. Semantic technologies provide valuable capabilities for governing metrics, managing business-facing definitions, applying security, and exposing consistent information to different consumers. But there's a difference between a semantic layer that builds upon a well-designed architectural foundation and one that must continually compensate for fragmented business concepts and inconsistent relationships beneath it.

And this is where AI makes the issue even more consequential. An experienced analyst may understand that two departments calculate revenue differently or that a particular dataset uses a specialized definition of customer. An AI agent doesn't inherently possess that institutional knowledge. It needs access to authoritative Business Context to interpret information correctly. Semantic layers can provide that understanding, but they shouldn't be the first place we seriously attempt to establish it.

As Enterprise Data Architects, we should be thinking about Business Context long before data is integrated, transformed, or presented for consumption. Those conversations should begin when we're working with the business to understand its concepts, processes, relationships, and rules. That understanding should guide our conceptual and logical models, influence the physical structures we design, and carry forward into the semantic models that ultimately make enterprise information accessible to analytics and AI.

Of course, I'm not suggesting that organizations should abandon existing platforms or undertake massive redesign efforts simply because a more elegant data model might be possible. There are practical considerations involving cost, complexity, operational risk, and existing investments. But neither should we automatically assume that another layer of abstraction is always the best long-term answer. Sometimes improving the underlying data models and physical structures, consolidating duplicated logic, or revisiting how business entities are represented may provide greater architectural value than continually compensating for those issues downstream.

Maybe We've Had the Answers to the Test All Along

After three decades working in data modeling and enterprise architecture, I find it fascinating that one of the most transformative technologies of our time is reminding us of principles that were foundational when I began my career. AI has fundamentally changed what we can accomplish with data and how quickly we can accomplish it, but it hasn't changed the importance of understanding the business behind that data. If anything, it's exposing just how important those architectural foundations have always been.

When I talk about bringing data modeling back into the development lifecycle, I'm not suggesting we return to the traditional processes and tools we used decades ago. I believe AI presents an opportunity to fundamentally rethink how we approach data modeling, particularly when it comes to logical, physical, and now semantic modeling. But there's one part of the discipline that I believe deserves renewed attention: the art of conceptual data modeling. Understanding the business, asking the right questions, challenging assumptions, and identifying the concepts and relationships that define how an organization operates. That's where Business Context begins, and it's the foundation upon which everything else should be built.

Through my own exploration of Spec-Driven Data Modeling, I'm beginning to see how we might connect these disciplines in entirely new ways, making data modeling more accessible, efficient, and integrated into modern development workflows. But that's a conversation for another day. For now, I believe the opportunity for Enterprise Data Architects is to refocus on understanding the business and ensure that understanding guides everything we design and deliver.

Before we ask our semantic layers to make sense of our data, perhaps we should take a closer look at the physical data structures we're asking them to interpret. Have we truly understood and modeled the business, or have we simply become very good at moving and transforming data? Business Context should have been guiding our decisions long before we reached this point, beginning with conceptual modeling and carrying through our logical and physical designs. If we're only beginning to establish that understanding when we're building our semantic layer, we're already late to the party.

Let's Bring Data Modeling Back Into the Conversation

Whether you're looking to establish data modeling as a core practice within your organization, strengthen your team's skills, or revisit your approach to conceptual, logical, physical, and semantic modeling, I'd welcome the conversation.

With nearly 30 years of experience in enterprise data architecture and data modeling, I help organizations build the knowledge, standards, and practices needed to make business-centric data modeling an integral part of their development lifecycle.

If your organization could use some guidance, training, or strategic support, I'd love to help.

Reach out to me at [email protected].