Practical Data: Stop Managing with Facts

When I'm asked to take "a quick look" at an organization's data environment, it usually doesn't take long to understand where they are.

One of the first clues is listening to the conversations between the business and the data team. If the discussion quickly drifts to what's in the data warehouse's fact and dimension tables, it's usually a sign the organization is still managing data primarily for analytics.

Today's organizations need to manage information for far more than analytics. They need to manage it for the business, both for people and increasingly for AI. That requires more than facts. It requires understanding.

Why Organizations Should Model Business Subjects, Not Analytical Structures

For more than three decades, fact tables and dimension tables have been the foundation of modern analytical data platforms. Dimensional modeling gave organizations a practical way to organize transactional data into structures optimized for reporting, historical analysis, and business intelligence. By separating measurable business events from the descriptive context that gives those events meaning, star schemas enabled organizations to build analytical platforms capable of delivering consistent metrics, executive dashboards, and high-performance reporting at unprecedented scale. Their success has been so complete that many organizations gradually came to view dimensional models not simply as a reporting technique, but as the way the business itself should be represented.

This evolution was understandable. For many years, reporting was the primary consumer of organizational data, so it made sense to optimize around reporting. Today, however, organizations must support far more than dashboards and executive reports. Operational applications, APIs, AI, search, governance, regulatory compliance, and data products all require information that reflects how the business actually operates. Reporting has become one consumer of organizational data rather than the reason for organizing it.

That shift forces us to reconsider a fundamental architectural question. Should organizations continue to manage their information through facts and dimensions, or should facts and dimensions become one of many representations derived from a richer business model?

I believe the answer is clear.

We Optimized for Reporting, Not for the Business

Dimensional modeling was designed to answer analytical questions. How much revenue did we generate? Which products sold the most? Which regions are growing fastest? What was our profit last quarter? These are the kinds of questions that fact tables answer exceptionally well because they organize measurable business events into structures optimized for aggregation and analysis.

Organizations, however, do not operate by managing facts. They operate by managing people, organizations, products, assets, agreements, and the relationships between them. Whether a board is discussing a merger, a regulator is reviewing compliance, or a customer service representative is resolving an issue, the conversation revolves around enduring business concepts rather than analytical summaries.

Walk into almost any executive meeting, and you will hear discussions about customers, suppliers, products, contracts, employees, facilities, acquisitions, and strategic partners. Nobody asks to review the Customer Dimension or debate the grain of the Sales Fact table. The language of the business has always been object-oriented because that is how people naturally understand organizations.

Those enduring subjects typically include:

• People
• Organizations
• Products
• Assets
• Agreements
• Locations
• Events
• Documents
• The relationships between them

These are not reporting constructs. They are the things an organization owns, manages, governs, and depends upon every day. They continue to exist whether or not a report is generated or a dashboard is refreshed.

Facts describe what happened. Subjects describe what exists. That distinction changes everything.

Subject-Based Data Modeling 

Recognizing that organizations think in enduring subjects rather than analytical facts naturally leads to a different approach to data modeling.  Over many years, this thinking has evolved into what we now call Subject-Based Data Modeling.

Rather than organizing information around transactions, reports, or business functions, Subject-Based Data Modeling begins by identifying the enduring subjects that exist within an organization. These subjects become the stable foundation from which every downstream representation is derived, whether that is a dimensional model, an API, a search index, or an AI knowledge model.

The defining principle of Subject-Based Data Modeling is simple.

Model the subject, not the role.

Many data warehouse implementations often confuse the two. Separate entities are created for Customer, Employee, Supplier, Prospect, Contact, Account Manager, Sales Representative, or Contractor because those are the terms used by different departments or applications. Yet these are not different subjects. They are different roles played by the same underlying subject.

For example, rather than modeling:

• Customer
• Prospect
• Employee
• Contractor
• Contact
• Account Manager

we model Person.

Likewise, rather than modeling:

• Customer
• Supplier
• Partner
• Manufacturer
• Distributor
• Regulator

we model  Organization.

Similarly, we model Address, not Billing Address, Shipping Address, Registered Address, or Residential Address. Those are simply different ways in which an address is used.

Sooner or later, every organization reaches the point where the same real-world entity begins performing multiple roles. A prospect becomes a customer, a customer becomes an employee, or a supplier becomes a strategic partner. Role-based models begin to fracture as teams grapple with duplicate records, reconciliation, identity resolution, and increasingly complex integration. Subject-Based Data Modeling anticipates this inevitability by modeling the enduring subject first and allowing roles to emerge through relationships and context, preventing many of the reconciliation challenges that traditional models inevitably create.

Roles evolve continuously throughout the life of an organization, but the underlying subject rarely changes. By modeling subjects rather than roles, organizations establish a far more stable representation of their information. Identity is managed once. Relationships are defined once. Governance is applied once. New business capabilities are introduced by extending relationships and behaviors rather than redesigning the core model. The result is a model that is significantly more resilient to organizational change because it reflects what the organization is, rather than how it happens to operate today.

AI Has Exposed an Existing Problem

Artificial intelligence has not created this challenge. It has simply exposed it.

Modern AI systems reason about people, organizations, products, agreements, assets, events, and the relationships between them. They build understanding by connecting these concepts into context. That is exactly how people understand businesses as well.

Neither humans nor AI naturally think in terms of fact tables, dimension tables, surrogate keys, or star schemas. Those are implementation techniques designed to optimize analytical performance, not conceptual models that describe how an organization works.

The same is true for many other consumers of organizational data. Today, information is consumed by operational applications, APIs, AI assistants, knowledge graphs, enterprise search, integration platforms, data products, and analytical platforms. Each of these consumers benefits from information organized around stable business subjects. Analytics is simply one consumer among many.

Facts Still Matter

Nothing in this discussion diminishes the importance of dimensional modeling.

Fact tables remain one of the most effective techniques ever developed for analytical workloads. If an organization needs to summarize billions of transactions, calculate KPIs, produce executive dashboards, or support self-service reporting, dimensional models remain extraordinarily effective. Their simplicity, predictable query patterns, and compatibility with analytical platforms continue to make them the preferred design for reporting systems.

The mistake is not building dimensional models. The mistake is asking them to become the authoritative representation of organizational information.

Those are fundamentally different responsibilities.

Manage Subjects. Publish Facts.

Once organizations separate the management of information from its consumption, the architecture becomes considerably simpler.

Subject-Based Data Modeling provides the authoritative representation of the organization's information. From that common foundation, multiple purpose-built models can be generated to satisfy different consumers.

• Analytics leverages re-presented fact and dimension tables.

• Operational systems consume APIs.

• Search platforms index business subjects.

• Knowledge graphs preserve relationships.

• AI receives contextual business information.

Each consumer receives a representation optimized for its purpose without redefining the underlying business.

The distinction can be summarized.

This is not an argument against dimensional modeling. It is an argument for using dimensional modeling exactly where it delivers the greatest value.

Stop Managing with Facts

Organizations do not create value by managing reports. They create value by managing people, organizations, products, assets, agreements, and the relationships that connect them. Those are the enduring subjects of the business, and they deserve to be represented as the authoritative foundation of the organization's information.

Fact and dimension tables remain indispensable for analytics, but they are analytical products, not business models. They should be derived from the business, not define it. When organizations separate the management of business information from the optimization of analytical information, they gain a model that is easier to govern, simpler to integrate, more resilient to organizational change, and far better suited to support operational systems, AI, and whatever technologies come next.

Subject-Based Data Modeling embraces this principle by modeling the enduring subjects of an organization and allowing roles, processes, applications, and analytical structures to evolve around them. Instead of continually redesigning data models to accommodate changing business roles, organizations establish a stable information foundation that supports change without redefining the business itself.

The future of data architecture is not about replacing dimensional modeling. It is about restoring its original purpose. Manage the business through its subjects and relationships. Publish fact and dimension tables for analytics.

Stop managing with facts. Start managing the business.

Ready to Make the Transition?

Many organizations have invested heavily in analytical data environments because that was the right architectural response for the reporting challenges of the past. Today's challenge is different. Organizations need business information environments that can simultaneously support operations, governance, AI, integration, digital services, and analytics from a common information foundation.

If your organization is ready to evolve from managing analytical data environments to managing business information environments, we'd welcome the opportunity to discuss your architecture, your data strategy, and how Subject-Based Data Modeling can help establish a more resilient foundation for the future.