The System of Record
Has Been Demoted
The critical architecture question is how data, context, authority and model choice are governed between record and action.
A system of record remains essential, but is no longer organised to the full enterprise estate. The critical architecture question is how data, context, authority and model choice are governed between record and action.
For three decades, enterprise architecture has been organised around systems of record. The ERP, CRM and other core platforms established the authoritative transaction, and the surrounding estate was designed to capture, integrate and report it. This model remains necessary. It no longer describes where the most consequential architecture decisions are being made.
AI applications and agents increasingly operate a level above systems of record. They use data from several sources, apply business context, select models and, in some cases, initiate actions. The reliability of these actions depend on decisions which are not contained within any single platform. These decisions concern authority, context, traceability, data precedence and operating cost.
The system of record has not been replaced. Its role has been narrowed.
It remains the authoritative store of a transaction, but it is no longer sufficient to determine how an automated system should interpret information or act across the wider estate.
Systems of Record No Longer
Govern the Full Decision Path
Traditional enterprise architecture assumes that a person interprets information and acts through an application. The application records the transaction, and accountability follows the user and the system. An agent changes this arrangement. It interprets information from multiple sources, applies business rules stored outside the applications, and initiates action through service interfaces across several systems.
The architectural unit is therefore no longer the individual application. It is a controlled path from record to decision and from decision to action. That path cuts across application, data, risk and business ownership. If it is not designed and governed as a whole, the reliability of the result depends on local integrations and implicit decisions.
Four Responsibilities Now Sit
Between Record and Action
A data platform can provide storage, processing and lineage. It does not decide which definition should be authoritative when the ERP, customer system and operational platform hold different versions of the same entity. That is a governance decision which must be implemented technically and owned operationally.
AI systems require access to the policies, exceptions, commercial logic and operational knowledge employees apply when using system data. Much of this knowledge is not held in structured form. It resides in procedures, correspondence and experience. Capturing it is an engineering and operating model responsibility, not a model selection exercise.
An organisation must be able to establish what authority was granted, which policy applied, what information was used, and how the decision can be reviewed.
Different tasks may justify different models, service levels, and control requirements. Without a routing policy and an owner, local decisions cannot be reconciled into an enterprise view of cost or risk.
Fragmented Ownership Is
the Structural Problem
Platform teams have their own platform capability. Data teams own pipelines and models. Application teams own systems of record. Risk functions on its own policy. Business teams own the process outcome. None of these accountabilities are wrong. The problem is that there is no mechanism which joins them for an end-to-end automated process.
This fragmentation is manageable while a person remains responsible for interpreting the information and completing the action. It becomes a material constraint when an automated system is expected to do both. The organisation then needs an explicit position on data precedence, context, decision rights, and evidence. If those decisions remain distributed, the process may operate technically without being governable as a business process.
Vendor Capability Does Not
Replace Enterprise Accountability
Platform vendors will reasonably argue that unified governance, semantic layers, lineage, model gateways and agent frameworks already address much of this requirement. Within a single vendor environment, these capabilities are material and should be used. The limitations arise due to boundaries. Large enterprises operate on heterogeneous estates, and the most important decisions concern information and actions which cross those boundaries. A semantic layer cannot, on its own, resolve a conflict between a definition in the ERP and one in a separately governed customer platform.
A systems integrator can coordinate work across technologies. A specialist can deliver depth within a platform. Neither can determine the organisation's authoritative business definitions, supply its proprietary context or accept management accountability for a business decision. Those responsibilities remain with the enterprise.
The correct conclusion is not to build a parallel layer in place of vendor capability. It is to define enterprise accountability first, then use vendor capability where it meets the requirements.
Ownership should determine the architecture. The architecture should not be allowed to imply ownership after the fact.
Operating Model Decisions Should
Precede Platform Selection
The next architecture decision is often framed as a platform choice: which Lakehouse, data cloud, agent framework or model provider. These are important decisions, but they should follow a clearer decision about the target operating model across data authority, business context, control, and model routing.
Once accountability is explicit, platform evaluation becomes more disciplined. The organisation can distinguish the capabilities it should procure from the responsibilities it must retain. It can identify which controls must operate across platforms, which knowledge must be engineered from its own business and which cost measures must be reported centrally.
The Enterprise Must Own the
Movement From Record to Action
The system of record remains essential, but it is no longer the organising principle for the full estate. The organising principle is the controlled movement from record to decision and from decision to action. If the organisation has not assigned accountability for that movement, the architecture is incomplete regardless of the quality of its individual platforms.
The next architecture review should begin with accountability for the end-to-end decision path, not with a comparison of platforms.
Decision Inc. is an advisory-led cloud & AI partner that works with over 300 organisations annually to build and scale enterprise data platforms across financial services, retail, telecoms, manufacturing and the public sector.
Book an Architecture Accountability Review
Test whether your organisation has assigned ownership for data authority, context, control and model routing between record and action.