Why modelling what data is — not the roles it plays — creates reusable, AI‑ready data foundations.

Introduction 

Open almost any mature data platform, and a pattern quickly emerges. The data models rarely reflect the structure of the business itself; instead, they reflect the history of past initiatives and the personalities of the leaders who sponsored them.

A schema often tells the story:

• tables created for a Customer 360 program
• attributes added during a Risk transformation initiative
• structures designed around a Marketing analytics dashboard
• schemas shaped by the priorities of a particular leadership era

None of these decisions was wrong at the time. Each initiative solved real problems and delivered real value, often delivering results quickly for the teams involved.

When every initiative designs its own version of the data, something subtle happens over time: the platform's overall structure begins to drift away from the business's underlying structure.

Instead of representing the business itself, the data platform slowly becomes a timeline of corporate programs, projects, and leadership priorities, with each new initiative leaving its own structural imprint on the models.

At that point, you are no longer looking at a coherent model of the enterprise; you are looking at a layered collection of structures created for different initiatives at different times.

The result is a collection of use‑case‑driven data models layered on top of one another, each optimized for its original purpose rather than for a shared understanding of the business.

Subject‑Based Data Modeling addresses this problem directly by modeling what the data is, rather than the roles it plays in different initiatives. By focusing on real‑world subjects, organizations create models that remain stable even as new use cases appear.

Our Approach

We use the term Subject‑Based Data Modeling to describe our practice of organizing data around real‑world entities that exist in the business and capturing everything the organization knows about those entities in a single coherent model.

• It encourages us to focus on what the data is, not the role it plays in a specific report or application.
• It helps us ensure all knowledge about an entity is incorporated into the same model.
• It allows us to support many different use cases to reuse the same shared understanding of the data.

In short:

Subject‑Based Data Modeling defines what data is. Use cases define what data is used for.

Use‑Case Models vs Subject‑Based Models

The diagram illustrates the core difference. In a use‑case architecture, each initiative creates its own version of key entities such as customers or products. In a subject‑based architecture, those entities are modeled once and reused across many different use cases.

The Root Cause: Use‑Case‑Driven Projects

Most organizations do not set out to create fragmented data environments. The problem usually begins with a simple and seemingly sensible question:

What data model do we need to support this use case?

A dashboard requires a schema, an AI model requires a dataset, and a regulatory report requires a transformation. Each of these needs often leads teams to design data structures specifically for that purpose.

Each project, therefore, builds the data structures it needs to succeed, often without considering how those structures relate to the broader enterprise data landscape.

Initially, this approach works well because it enables teams to deliver quickly and respond to immediate business needs. Over time, however, the accumulation of these decisions begins to fragment the overall architecture, and the consequences become increasingly visible across the platform.

When Use Cases Start Defining the Data

As more initiatives arrive, the data environment begins to show predictable symptoms, particularly as different teams create their own models for similar concepts.

Consequence #1 - Multiple Versions of Core Business Concepts

Different projects create their own definitions of concepts such as:

• Customer
• Account
• Product
• Transaction

Each model is optimized for its specific use case rather than the broader business context.

Consequence #2 - Fragmented Data Architectures

Instead of a cohesive platform, organizations accumulate:

• multiple data marts
• duplicated transformations
• inconsistent definitions
• competing sources of truth

The architecture begins to mirror project structures rather than business structures.

Consequence #3 - Personality‑Driven Data Concepts

Over time, the platform may even begin to reflect the personalities and priorities of past leaders.

Teams refer to parts of the platform by initiative names:

• “That’s the marketing model.”
• “That came from the digital transformation program.”
• “That schema was created for regulatory reporting.”

At that point, the data environment has effectively become a timeline of corporate initiatives.

What is Subject‑Based Data Modeling?

Subject‑Based Data Modeling is an approach to data design in which the structure of the data model reflects what the data actually represents in the real world, rather than the role it plays in a particular report, application, or analytical use case.

Put simply:

Subject‑Based Data Modeling models what the data is, not the role it plays.

Many traditional data models are created to support a specific purpose, such as a regulatory report, a marketing dashboard, a risk calculation, or a machine‑learning dataset.

In those cases, the data model reflects how the data will be used.

Subject‑Based Data Modeling takes a different approach.

Instead of asking:

What data structure do we need for this use case?

It asks:

What does this data represent in the real world?

Model the Real‑World Entity

Subject‑Based Data Modeling begins by identifying the real‑world subjects that exist within the business and first describing what they are before modeling the roles they play within the business.

Examples include:

• Entities (Companies, Charities, Organizations.)
• People
• Accounts
• Products
• Transactions
• Documents

Each subject represents a real‑world entity that exists independently of any specific system or use case, allowing the organization to define that entity consistently across the enterprise.

The goal of the model is to ensure that everything the organization knows about that entity is represented in the data model, bringing together knowledge that may otherwise remain scattered across systems and teams.

If multiple business groups each know something about an entity, that knowledge belongs within the same subject model.

The model therefore captures:

The model becomes a representation of the entity itself, not a structure optimized for a single analysis.

Use Cases Consume Data, They Do Not Define It

Once real‑world subjects are modeled, different use cases can consume the same data in different ways, including analytics, AI training, dashboards, and operational systems. The same underlying subject model, therefore, supports a wide range of applications.

These uses do not change the underlying definition of the subject. The subject model remains stable because it reflects what the data actually is, rather than the role it plays in any particular process or initiative.

Why This Matters

When data models reflect what the data is, rather than the purpose it serves in a project, the entire data environment behaves differently.

Subject‑Based Data Modeling creates several practical outcomes that are difficult to achieve in use‑case‑driven architectures.

Consistent Definitions Across the Organization

When a subject, such as an account, company, or product, is modeled once as a real‑world entity, the organization operates from a shared definition that all teams understand and use. This reduces the creation of competing interpretations of the same concept across projects, reporting, analytics, and operational systems.

By establishing a single model for each subject, organizations not only reduce inconsistent definitions but also enable consistent data reuse across the enterprise, allowing teams to work from the same understanding of what the data represents.

When a subject, such as an account, company, or product, is modeled once as a real‑world entity, the organization can operate from a shared definition.

Different teams no longer create their own interpretations of the same concept for different projects.

This dramatically reduces competing definitions across reporting, analytics, and operational systems.

More importantly, it enables consistent reuse of data across the organization. Teams can leverage the same underlying data with a shared understanding of what that data represents.

Reduced Personality‑Driven Politics

A more subtle benefit of Subject‑Based Data Modeling is that it naturally reduces the influence of personality‑driven preferences in data design conversations.

When discussions focus on real‑world subjects, such as companies, people, accounts, products, and transactions, the conversation shifts away from project‑specific preferences.

Instead of debating how data should be shaped for a particular initiative, teams align around a simpler question:

What do we actually know about this entity?

Strong businesses often have strong leaders, and strong leaders naturally bring strong opinions into strategic discussions. Grounding conversations in shared business subjects provides a neutral foundation that different teams and different leadership perspectives can align around.

Reusable Data Foundations

Because subject models represent the entity itself, they can support many different use cases simultaneously. Instead of building new data structures for each initiative, teams reuse existing models to support analytics, dashboards, operational workflows, regulatory reporting, and AI.

As a result, new initiatives rarely need to begin by redefining the underlying data. Teams can move directly to building analytics, transformations, or AI capabilities, which significantly accelerates the delivery of new use cases.

Easier Data Integration

When core subjects are already modeled and governed, new initiatives do not need to start by redefining the data.

Teams can focus directly on building analytics, transformations, or AI capabilities rather than recreating underlying data structures.

Easier Data Integration

Subject‑based models make it easier to combine information from multiple systems.

Because the model represents the real‑world entity, data from different sources can be matched and reconciled more easily.

This is particularly important in large enterprises where the same subject may appear across dozens or hundreds of systems.

Stronger Foundations for AI (see closing quote)

AI systems perform best when they can access well‑structured and consistently defined representations of business entities.

Subject‑based models provide exactly this: a stable and comprehensive representation of the business that AI systems can interpret reliably.

Because subject models clearly define the data, each attribute and relationship has an explicit meaning.

This makes the data far easier for AI systems to interpret and reason over.

Better Risk Management and Decision Making

When organizations operate from a consistent understanding of their core business entities, risk management improves significantly.

Subject‑based models ensure that decisions are made using the same underlying definitions across the organization.

This reduces the risk of conflicting reports, inconsistent regulatory submissions, or decisions based on incomplete data interpretations.

Data Models That Outlast Initiatives

Perhaps most importantly, subject‑based models are designed to outlast individual programs, leadership cycles, and technology changes.

Because they represent the business's structure, they remain relevant even as strategies and use cases evolve.

In other words, the architecture becomes a representation of the enterprise, not a collection of past projects.

A Simple Diagnostic Test

There is a question that quickly reveals the maturity of many data platforms:

When you look at your data models, do you see the structure of the business, or the personalities of past leaders?

If the architecture reflects initiatives, programs, and executive priorities from different eras, it is often a sign that the organization has relied too heavily on use‑case‑driven design.

That is usually the moment when organizations begin adopting Subject‑Based Data Modeling as the foundation for a more durable data architecture.

Final Thought

Use cases will always evolve as businesses introduce new products, new analytics, and new digital capabilities, strategies will change as markets shift, and leadership teams will introduce new priorities that reshape how data is used.

Your core data models, however, should not have to change with each new initiative.

Subject‑Based Data Modeling ensures that data architecture reflects the structure of the business itself, not the history of past initiatives.

AI does not struggle with data volume; it struggles with data meaning. Subject‑based models solve the meaning problem.

To find out more about our practical, data‑management‑first approach to improving business outcomes through better data use, use the contact for above.