From system of record to source of meaning.

For years, enterprise architecture conversations around data have been dominated by a familiar question: where should the authoritative data live?

That question still matters. But it is no longer enough.

An enterprise can know exactly where a customer, product, material, supplier or financial record is stored and still struggle to answer a more important question: what does this information mean in the context of a business decision?

1. System of record solved a location problem

A system of record gives an enterprise an authoritative place where a particular class of information is maintained. ERP, CRM, MDM and specialist platforms all play this role.

For example, an ERP system may be authoritative for a material master. A CRM platform may own customer engagement information. An HR platform may own employee data.

This model gives us governance through ownership. If somebody asks, “Where is the official record?”, architecture can point to a system.

2. Source of truth solved a trust problem

As enterprise landscapes became more distributed, data was consumed far beyond the system that created it. It moved into data warehouses, lakes, analytics platforms, integration layers and external applications.

The challenge became not just where the record originated, but which version the enterprise should trust.

But even a trusted value can become misleading when separated from context. Consider “revenue.” A number can be technically correct and still mean different things depending on whether the business is discussing booked revenue, recognized revenue, invoiced revenue, net revenue, local-currency revenue or a management reporting view.

The data can be right. The interpretation can still be wrong.

3. Source of meaning solves a context problem

A source of meaning is not necessarily another platform. It is an architectural capability that preserves the business context around information.

That context includes definitions, relationships, ownership, business rules, temporal relevance, lineage, policy and the purpose for which information is being used.

This distinction becomes especially important as enterprises introduce AI.

Traditional applications often encode context implicitly inside screens, workflows and business processes. Human users learn that context over time. AI systems do not automatically inherit it.

If an AI agent retrieves a value but does not understand its definition, scope, business relationship or policy boundary, it can produce an answer that is syntactically impressive and operationally wrong.

That is why semantic architecture, knowledge models, business glossaries, metadata, knowledge graphs and capability models are becoming more important. They help machines and humans interpret information within an enterprise context.

4. The enterprise architecture consequence

Architecture cannot stop at where the data is stored, how it moves, which platform owns it or how quickly it can be accessed.

We also need to ask what business concept the data represents, who defines it, which capabilities depend on it, what relationships give it meaning, which assumptions are hidden in the definition and whether an application or AI agent can discover that context without tribal knowledge.

This is where business architecture and data architecture need to become much more connected.

A business capability model describes what the enterprise must be able to do. A value stream explains how value is created. Information concepts explain what the enterprise needs to know. Applications and data platforms provide the technology implementation.

When these are connected, architecture creates a line of sight from business intent to data meaning to technology execution.

5. A practical architecture test

Take any important enterprise metric or master-data object and ask five people from different functions what it means.

If you receive five materially different answers, the enterprise does not have a technology problem. It has a meaning problem.

For example, take “active customer.” Sales may define it using opportunity activity. Finance may define it using recent revenue. Service may use open support relationships. Marketing may use engagement. Master data may only indicate that the customer record is not blocked.

Every system can be technically correct while the enterprise remains conceptually inconsistent.

6. Closing thought

The next generation of enterprise architecture will not be defined only by how well we integrate systems.

It will be defined by how well we integrate meaning.

Systems of record remain necessary. Sources of truth remain necessary. But as data becomes distributed and AI becomes a participant in enterprise decision-making, architecture must preserve enough context for both humans and machines to understand what the enterprise actually means.

That shift matters more than the latest platform debate.