Enterprise Data and AI Operating Model

Why this chapter matters

Introduction

Enterprise data architecture does not operate in isolation from the organization around it. A well-designed architecture can still fail if ownership is unclear, decision rights are fragmented, platform teams are disconnected from business domains, governance is treated as a separate bureaucracy, or funding models make it difficult to sustain shared capabilities.

The emergence of cloud platforms, data products, generative AI, and agentic systems has made the operating model even more important. Traditional organizations often separated application development, infrastructure, data management, analytics, security, and governance into distinct functions. Modern enterprise architecture increasingly requires these capabilities to work together around shared information assets, reusable platforms, and business outcomes.

The operating model defines how this happens.

It establishes who owns data, who builds and operates platforms, who defines enterprise standards, who makes architectural decisions, who manages risk, who funds shared capabilities, and how business domains participate in the evolution of the data and AI ecosystem. It also determines how quickly the organization can respond when technologies, regulations, business priorities, or AI capabilities change.

For the Enterprise Data Architect, the operating model is therefore not an organizational-chart exercise. It is an architectural concern. Organizational structures influence architecture, and architecture in turn creates requirements for organizational accountability. This chapter explores the operating model required to turn enterprise data and AI architecture into an enduring organizational capability. It emphasizes federated ownership, platform thinking, clear decision rights, domain accountability, reusable capabilities, measurable outcomes, and continuous architectural evolution.

20.1 From Architecture to Operating Model

Architecture describes how capabilities, information, platforms, applications, and controls fit together. An operating model describes how people and teams continuously make that architecture work.

This distinction is important because architecture has a lifecycle. Data products must be maintained. Platforms must be upgraded. Security policies must evolve. Metadata must remain current. Quality issues must be resolved. AI applications must be evaluated and monitored. New domains must be onboarded. Existing systems must eventually be retired.

If the operating model does not assign responsibility for these activities, the architecture gradually deteriorates.

In traditional environments, many data responsibilities were embedded in individual application or database teams. A reporting team might own extracts, an application team might own operational data, and a centralized data warehouse team might own analytical structures. These arrangements can work at smaller scale, but they often create ambiguity when the same business concept is distributed across multiple platforms.

Modern data architecture requires a stronger distinction between ownership and implementation. The business domain should generally own the meaning and quality expectations of important data, while specialized technology teams provide the platforms and engineering capabilities required to deliver it. This leads to a fundamental operating-model principle:

The teams closest to the business meaning of data should have meaningful accountability for that data, while shared technology capabilities should be provided as reusable enterprise services.

The principle does not imply that every domain must build its own technology stack. In fact, the opposite is usually more sustainable. Domains should own their information and data products while leveraging common platforms, security controls, observability, metadata services, and engineering standards.

20.2 Centralized, Federated, and Hybrid Operating Models

Organizations commonly move through several operating-model patterns as their data environments mature.

A centralized model places most data architecture, engineering, governance, and platform responsibilities in a central organization. This approach can provide strong consistency and simplify early platform development. It can also create bottlenecks when every new data requirement must pass through a central team.

A decentralized model distributes ownership almost entirely to business units or technology teams. This can improve responsiveness and domain knowledge, but it can also produce duplicated platforms, inconsistent definitions, fragmented governance, and incompatible data products. A federated model attempts to combine the strengths of both. Domains own business data and data products, while enterprise teams establish common standards and provide shared capabilities. Decision rights are distributed according to the nature of the decision.

In practice, many large enterprises use a hybrid arrangement. Some capabilities remain centralized because they require enterprise-wide control or economies of scale. Identity, security, shared metadata services, platform infrastructure, enterprise architecture standards, and certain regulatory controls are common examples. Other responsibilities are distributed to domains because they depend heavily on business context.

The appropriate balance varies by organization. The objective is not to select a particular organizational fashion but to place decisions at the level where the required knowledge, accountability, and authority exist.

20.3 The Domain as a Unit of Data Accountability

Business domains provide a useful boundary for assigning data accountability because they correspond to meaningful areas of business responsibility. Examples might include customer, payments, lending, finance, supply chain, human resources, or risk. A domain understands the business processes that create its data, the meaning of important entities, the consumers of that information, and the consequences of poor quality. Domain ownership does not mean that every domain creates an independent architecture. It means that the domain is accountable for the information it publishes.

A domain should therefore be able to answer several basic questions. What does this data represent? Who owns it? Which systems create it? Which attributes are authoritative? What quality expectations apply? Who consumes it? What restrictions govern its use? How frequently does it change? What happens when it becomes unavailable or incorrect?

These questions become especially important in a data-product-oriented architecture. A data product should not simply be a technical dataset published to a platform. It should represent a defined business capability or information need, with an owner, documented semantics, quality expectations, access controls, and a supported interface.

The domain model also creates a natural connection between data architecture and business architecture. Data ownership should align with business accountability rather than being determined solely by which technology system happens to store the data.

20.4 Enterprise Data and AI Roles

A modern operating model requires a clear distinction between roles while encouraging collaboration across them:

• The Enterprise Data Architect defines enterprise-level information and data architecture, establishes architectural principles, connects domain architectures, and ensures that data capabilities support business strategy. The role increasingly extends into AI architecture because AI depends on data, metadata, semantics, governance, and platform capabilities.
• The Domain Data Architect translates enterprise principles into domain-specific architecture. This role understands the domain’s information structures, applications, data products, integration patterns, and analytical needs.
• The Data Product Owner is accountable for the business purpose and lifecycle of a data product. The product owner works with consumers, defines priorities, and ensures that quality, usability, documentation, and service expectations are maintained.
• The Data Steward focuses on business meaning, definitions, quality rules, metadata, and appropriate use. Stewardship should be connected to actual business responsibility rather than treated as purely administrative work.
• The Data Engineer implements and operates pipelines, transformations, data products, and engineering controls. Increasingly, data engineers also participate in platform engineering and infrastructure automation.
• The Data Platform Engineer provides reusable capabilities such as storage, compute, orchestration, streaming, metadata integration, observability, security controls, and developer tooling.
• The AI Architect or AI Engineering Team designs AI-specific capabilities, including model integration, retrieval, evaluation, prompt and context management, agent architectures, and AI application platforms.
• The Security, Privacy, Risk, and Responsible AI Functions establish controls, assess risk, and provide oversight appropriate to the organization’s regulatory and risk environment.

These roles should not operate as isolated functions. Their effectiveness depends on shared decision processes and common architectural artifacts.

20.5 Platform Teams as Internal Product Teams

One of the most important changes in modern data operating models is the shift from infrastructure teams to platform product teams. A traditional infrastructure team may be measured by whether servers, storage, or databases are available. A platform product team is responsible for creating capabilities that make other teams more productive and reliable. The distinction matters. Data teams need more than infrastructure. They need reusable ingestion patterns, orchestration, security integration, observability, metadata, lineage, testing frameworks, deployment automation, cost visibility, and standardized interfaces to cloud services.

A platform team should therefore treat its users as customers. It should understand the needs of domain data teams, application developers, analysts, AI engineers, and governance functions. It should provide documentation, onboarding, support, usage metrics, service expectations, and a roadmap.

Platform-as-product thinking also discourages unnecessary centralization. A platform team should provide reusable capabilities rather than become the team through which every data change must pass.

The Enterprise Data Architect plays an important role in defining the boundary between platform capabilities and domain responsibilities. If the boundary is too centralized, domains lose autonomy. If it is too fragmented, the organization duplicates expensive capabilities and creates inconsistent controls.

20.6 Decision Rights and Architectural Governance

Operating models become ineffective when responsibility exists without authority.

A domain may be accountable for data quality but lack authority to change a source application. A platform team may be responsible for reliability but have no control over incompatible consumer behavior. An enterprise architect may define a standard that no funding mechanism or governance process enforces.

Decision rights should therefore be explicit.

Enterprise architecture typically makes decisions about cross-domain standards, strategic technology direction, interoperability, enterprise principles, and major architectural risks. Domain architecture makes decisions about domain-specific implementation within those boundaries. Product teams make decisions about product features, quality improvements, and consumer priorities.

Governance should focus on decisions that genuinely require coordination. Not every implementation detail needs enterprise approval. Excessive governance slows delivery and encourages teams to bypass the architecture process.

A useful governance model distinguishes between mandatory standards, recommended patterns, and local choices. Mandatory standards address areas such as security, privacy, regulatory requirements, critical interoperability rules, and architectural principles. Recommended patterns provide proven approaches that teams can adopt unless they have a justified alternative. Local choices remain within the domain when enterprise-wide coordination is unnecessary.

This distinction helps governance become an enabler rather than a gate.

20.7 Data Governance as an Embedded Operating Capability

Modern data governance should not exist as a separate layer disconnected from engineering and product delivery.

Policies become effective when they are translated into architecture and operational controls. A classification policy, for example, should connect to metadata, access controls, encryption requirements, retention policies, and monitoring. A data quality policy should connect to product expectations, automated tests, incident management, and stewardship.

The operating model should therefore embed governance into normal delivery processes.

When a new data product is created, governance metadata should be established as part of product onboarding. When a dataset is classified as sensitive, the relevant access and protection controls should be applied through platform capabilities. When a quality rule fails, the incident should flow through the same operational process used for other production issues.

This approach reduces the perception that governance is paperwork added after engineering is complete. It also changes the role of governance professionals. Instead of primarily reviewing artifacts after the fact, governance teams increasingly work with architects and engineers to define policies that can be implemented through technology.

20.8 Funding and Financial Accountability

Operating models frequently fail because architecture responsibilities are defined without corresponding funding mechanisms. Shared data platforms require ongoing investment. They need engineering teams, cloud resources, security capabilities, support, upgrades, observability, and architecture governance. Data products also require continuing ownership after initial delivery.

If shared capabilities are funded only through individual projects, teams may optimize for short-term delivery and create fragmented solutions. A domain may build a local capability because it cannot access central platform funding, even though the enterprise would benefit from reuse.

A sustainable model distinguishes between investment in shared capabilities and investment in domain outcomes. Enterprise funding can support common platform services, security capabilities, metadata infrastructure, and foundational architecture. Domain funding can support product-specific requirements and business outcomes.

Cloud makes financial accountability especially important because consumption-based costs can obscure architectural decisions. Platform teams should provide cost transparency, while domains should understand the resources consumed by their products and workloads.

FinOps therefore becomes part of the operating model rather than merely a financial reporting exercise. Architecture decisions should consider not only technical feasibility but also ownership of recurring costs.

20.9 The Data and AI Product Lifecycle

The operating model should define how data and AI products move through their lifecycle. The lifecycle begins with an identified business need and an accountable owner. Architecture determines whether existing capabilities can satisfy the need or whether a new product or platform capability is required. During design, teams define information concepts, interfaces, quality expectations, security classifications, consumers, and operational requirements. During implementation, engineering teams build the product using approved platform capabilities and automated controls. Once deployed, the product enters an operational lifecycle. Monitoring, quality management, incident response, metadata maintenance, and consumer support become ongoing responsibilities.

Eventually, a product may need to be changed, replaced, or retired. Retirement requires the same level of discipline as creation. Consumers must be identified, migration paths established, retention requirements considered, and dependencies removed.

AI products introduce additional lifecycle activities. Models, prompts, retrieval indexes, evaluation datasets, agent tools, and policies may all evolve independently. The operating model should establish ownership for each component and define how changes are evaluated and released. The lifecycle perspective prevents the organization from treating architecture as a one-time project deliverable.

20.10 Architecture Communities and Communities of Practice

Distributed organizations need mechanisms for sharing architectural knowledge. Communities of practice provide a forum where architects, engineers, stewards, analysts, AI specialists, and governance professionals can discuss patterns, lessons learned, emerging technologies, and recurring problems. These communities should produce practical outcomes. They can maintain reference architectures, reusable patterns, decision records, implementation guidance, and examples. They can also identify areas where teams are solving the same problem repeatedly and recommend a shared platform capability.

Communities of practice are especially valuable in rapidly changing areas such as AI. Technology evolves faster than formal standards processes can respond. A community can create lightweight guidance while enterprise governance determines which practices become mandatory. The architect’s role in these communities is partly technical and partly social. Influence increasingly comes from helping teams solve problems rather than simply issuing standards.

20.11 Architecture Decision Records and Decision Transparency

As architecture becomes more distributed, decision transparency becomes essential. Architecture Decision Records provide a lightweight mechanism for documenting significant choices, alternatives considered, constraints, and consequences. They are especially valuable when different teams make decisions that affect shared data or platform capabilities. A useful decision record does not attempt to document every implementation detail. It captures the reasoning behind decisions that future teams may need to understand.

For example, a domain may choose to expose a data product through a particular interface because it supports both batch and streaming consumers. Another team may choose a specific storage architecture because of regulatory residency requirements. A platform team may establish a common observability standard because inconsistent monitoring has created operational risk.

Decision records make these choices visible and reduce the tendency to repeatedly revisit settled questions. They also provide historical context when technology or organizational circumstances change.

20.12 Skills and Workforce Evolution

The operating model must evolve alongside the skills of the workforce. The modern Enterprise Data Architect needs more than knowledge of data modeling and database technologies. The role increasingly requires understanding of cloud architecture, distributed systems, data products, security, governance, metadata, AI, financial management, organizational design, and business strategy.

Data engineers need stronger software engineering and platform skills. Analysts increasingly work with governed data products rather than directly navigating complex warehouse structures. Business stewards need enough technical understanding to work effectively with engineers. AI engineers need stronger awareness of data governance, provenance, privacy, and enterprise architecture.

The organization should therefore treat capability development as an architectural investment. Training alone is not sufficient. People learn effectively when the operating model provides opportunities to practice new capabilities, reusable patterns, mentoring, and communities of practice. Architecture standards should be accompanied by implementation guidance and examples. The goal is not to make every professional an expert in every discipline. It is to create enough shared understanding that cross-functional teams can collaborate without requiring constant translation between organizational silos.

20.13 The Operating Model for AI

AI introduces a particularly important operating-model question: who owns enterprise AI capability?

If every business unit builds its own AI applications independently, the organization may quickly accumulate duplicated model integrations, inconsistent security controls, fragmented knowledge stores, and incompatible evaluation practices. A centralized AI platform team can provide shared model access, security controls, evaluation services, retrieval capabilities, agent frameworks, monitoring, and cost management. Domain teams can then build business-specific applications on top of these capabilities.

However, centralization should not eliminate domain ownership. A customer service domain may own the business requirements and knowledge sources for its AI assistant, while the enterprise AI platform team provides the underlying model gateway, evaluation framework, identity integration, and observability.

This creates a layered operating model.

At the enterprise level, the organization governs models, security, responsible AI, shared platforms, and common architectural standards. At the domain level, teams own business context, data products, knowledge, workflows, and application outcomes. At the product level, teams operate specific AI applications and manage their users and use cases.

Agentic AI increases the importance of this model because agents can take actions rather than merely produce information. Tool access, authorization, approval policies, and operational accountability must be explicitly assigned.

20.14 Measuring the Operating Model

An operating model should be evaluated through outcomes rather than organizational activity alone.

Useful indicators include the time required to onboard a domain to the enterprise data platform, the proportion of critical data products with clear ownership, reuse of shared platform capabilities, time to resolve architectural decisions, frequency of duplicated technology capabilities, platform adoption, quality incident trends, and the proportion of critical AI applications using standardized governance and evaluation controls.

Financial measures should include shared platform cost, domain consumption, unit economics for major workloads, and the cost of maintaining duplicated capabilities. Employee and team experience also matters. Excessive governance queues, unclear ownership, difficult platform interfaces, and inconsistent standards create hidden architectural costs. Developer and data-team experience can therefore be an important indicator of operating-model health.

No single metric determines whether the operating model is effective. The objective is to create a balanced view of delivery speed, reliability, reuse, risk, cost, and business value.

20.15 Common Operating-Model Failure Patterns

Several failure patterns recur in enterprise data transformations:

1. Centralization without scalability. A central data team becomes responsible for every pipeline, model, quality rule, and architectural decision. As demand grows, the team becomes a bottleneck.
2. Federation without standards. Domains receive complete autonomy but create incompatible definitions, platforms, security practices, and interfaces. Integration becomes increasingly expensive.
3. Platform without product thinking. A platform team builds technically sophisticated infrastructure without understanding the needs of its users. Adoption remains low because the platform is difficult to use.
4. Governance without execution mechanisms. Policies are documented, but no technical controls, ownership, or operational processes enforce them.
5. Ownership without authority. Teams are accountable for outcomes but cannot influence the systems, funding, or policies necessary to achieve them.
6. Project-based data ownership. Teams own data while a project is active, but responsibility disappears after delivery. Quality, documentation, and maintenance subsequently decline.
7. AI experimentation without an enterprise operating model. Individual teams rapidly create AI solutions, but shared security, evaluation, data governance, cost controls, and operational practices emerge too late.

Recognizing these patterns early allows the enterprise architect to address structural problems before they become deeply embedded.

20.16 Reference Operating Model for the Intelligent Enterprise

A modern enterprise data and AI operating model can be viewed as several interconnected layers:

• Business and strategy establishes priorities, outcomes, risk appetite, and investment direction.
• Enterprise architecture and governance defines principles, reference architectures, standards, decision rights, and cross-domain coordination.
• The domain layer owns business information, data products, domain architecture, quality expectations, and domain-specific AI use cases.
• The platform layer provides shared data and AI capabilities, including cloud infrastructure, storage and compute, integration, orchestration, metadata, observability, model access, retrieval, evaluation, security integration, and developer tooling.
• The control layer provides security, privacy, compliance, responsible AI, financial management, and operational risk controls.
• The delivery and operations layer implements and runs data products, analytical services, AI applications, and business capabilities.

These layers should not be interpreted as rigid organizational departments. In some enterprises, several may exist within one organization. In others, they may span multiple business and technology groups. The important point is that the responsibilities and interfaces are explicit.

Case study: Meridian Financial Group

20.17 Enterprise Data and AI Operating Model at Meridian Financial Group

Meridian Financial Group initially organized its data capabilities around projects. Each major business initiative established a project team responsible for integration, reporting, and analytics. Once the project ended, ongoing ownership became fragmented. Several teams built similar pipelines and quality controls, while central governance struggled to maintain visibility.

As Meridian expanded its cloud platform and AI initiatives, this model became increasingly difficult to sustain. New AI applications required access to customer, transaction, product, and policy information. Different teams were independently selecting retrieval technologies, model providers, monitoring approaches, and data access mechanisms.

Meridian responds by establishing a federated data and AI operating model. Business domains become accountable for their important data products. Customer, payments, lending, finance, and risk domains each designate product owners and data stewards. Domain architects work with the enterprise architecture function to align information models, interfaces, and security requirements.

A central data platform organization becomes responsible for reusable engineering capabilities. It provides ingestion frameworks, orchestration, metadata and lineage, observability, security integration, and cloud platform services. The team adopts a platform-as-product model and establishes an internal roadmap based on domain requirements.

A shared AI platform team is established alongside the data platform organization. It provides model gateways, retrieval services, evaluation frameworks, prompt and context management capabilities, AI observability, and standardized security integration. Domains remain responsible for their business use cases and knowledge sources.

Meridian also establishes an architecture council with representation from enterprise architecture, domain architecture, security, data governance, platform engineering, AI engineering, and key business functions. The council does not review every technical decision. It focuses on cross-domain standards, major architectural choices, strategic technology decisions, and exceptions to mandatory enterprise principles.

Funding changes as well. Shared platform capabilities receive enterprise-level investment, while domains fund product-specific development and consumption. Cloud costs are made visible to domains through FinOps reporting, allowing teams to understand the operational consequences of their architectural choices.

After several operating cycles, Meridian sees a reduction in duplicated platform capabilities and greater consistency in governance. More importantly, domain teams have clearer accountability for the data they publish, while platform teams have clearer accountability for making the enterprise technology environment usable.

The transformation does not eliminate organizational tension. Domains continue to request capabilities that compete for platform capacity, and enterprise standards occasionally conflict with local preferences. The operating model provides mechanisms for resolving these conflicts rather than assuming they will disappear.

20.18 Practical Artifact: Enterprise Data and AI Operating Model Assessment

The Enterprise Data and AI Operating Model Assessment helps architects evaluate whether organizational structures and decision mechanisms support the target architecture.

The assessment should identify structural constraints rather than simply grade organizational maturity. For each significant gap, the architect should document the consequence, the required change, the accountable owner, and the expected business or architectural benefit. A useful output is a target operating-model blueprint showing the major teams, responsibilities, decision rights, shared platforms, governance mechanisms, and funding relationships. The blueprint can then become part of the enterprise architecture roadmap.

Remember these

20.19 Key Takeaways

1. An enterprise data and AI architecture becomes sustainable only when the operating model assigns clear ownership, decision rights, funding, and accountability.
2. Federated models can provide a useful balance between enterprise consistency and domain autonomy. Domains should generally own the meaning, quality, and business purpose of their data products, while shared teams provide reusable platform capabilities.
3. Platform teams should operate as internal product teams. Their objective is not merely to provide infrastructure but to improve the ability of domain teams to build, operate, govern, and evolve data and AI products.
4. Governance should be embedded into delivery and operational processes. Policies have greater value when they are translated into metadata, access controls, quality checks, observability, and automated enforcement.
5. Funding is an architectural concern. Shared capabilities require sustainable investment, while domain teams need financial visibility into the cost of the products and workloads they operate.
6. AI requires a layered operating model in which enterprise teams provide shared model, security, evaluation, and platform capabilities while domains retain ownership of business context, knowledge, workflows, and outcomes.
7. Decision rights should be explicit. Centralization should be reserved for decisions that genuinely require enterprise coordination, while domain and product teams should retain authority over local decisions within defined architectural boundaries.
8. The operating model must evolve continuously. Architecture, technology, organizational capabilities, and business priorities change together.

Think about your own organization

Architect’s Reflection

Look beyond the architecture diagrams in your organization and ask a different question: who is responsible for making this architecture work five years from now?

If a data product becomes stale, who notices? If a critical business definition changes, who has the authority to update it? If two domains disagree about ownership of a customer concept, who resolves the issue? If a platform capability becomes too expensive, who can change its architecture? If an AI agent makes an incorrect or unauthorized action, who owns the resulting incident?

These are architectural questions because the answers determine whether the architecture can operate as designed.

The modern Enterprise Data Architect must therefore understand organizational design almost as deeply as technology design. The strongest architecture is not necessarily the one with the most sophisticated technology. It is the one that can be owned, operated, governed, funded, measured, and evolved.

As enterprises move toward intelligent systems, the operating model becomes part of the intelligence architecture itself. Data, platforms, people, governance, and AI capabilities must form a coherent system rather than a collection of independent functions.