Your Architecture Decision Has an Operating Model Consequence

The architecture decision is only half the decision

An architecture review can produce a technically sound design and still leave the organisation unprepared to operate the resulting capability.

The technology might meet requirements for integration, security, scalability and resilience. Yet ownership might be unclear, decision rights might conflict, specialist skills might be unavailable, or funding for ongoing operations might be missing.

The design is not the only thing being approved. The organisation is also accepting a set of operating commitments.

An architecture decision is incomplete until the enterprise understands how the resulting capability will be owned, governed, operated, funded and evolved.

Architecture includes technology components and interfaces, along with the structural choices determining how capabilities are integrated, governed and operated. The operating model defines how people, responsibilities, decision rights, processes, skills and economics support the resulting capability.

The distinction matters. A technology choice does not operate itself. The enterprise must establish the conditions under which the chosen design delivers its intended business outcome.

Five operating consequences deserve explicit executive attention:

1. Ownership.

2. Decision rights.

3. Skills and capacity.

4. Operating responsibilities.

5. Economics and accountability.

These are not additional administrative tasks after the architecture review. They form part of the decision itself.

1. Ownership: who owns the capability after implementation?

Architecture decisions often begin with a business requirement and quickly become discussions about platforms, components, interfaces and technical standards.

A question receives less attention: who owns the capability once the programme team moves on?

Ownership must extend beyond implementation. Someone needs to be accountable for the business capability, while named teams manage the technical services, data and operational activities required to sustain it.

Consider an enterprise data platform. A central team might own the platform technology, while business domains own the meaning, quality and use of their data. Security teams define controls, and consuming teams build products using shared data services.

The architecture needs to establish how these responsibilities fit together.

Without explicit ownership, common questions remain unresolved:

• Who owns the business capability and its intended outcome?
• Who owns the technical service and its service commitments?
• Who is responsible for data definitions, quality, access and retention?
• Who resolves conflicts between platform standards and domain requirements?
• Who funds changes when the capability evolves?
• Who is answerable when an issue crosses organisational boundaries?

The distinction between owning a component and owning an outcome is important. A platform team might operate its service successfully while the business capability depending on it continues to underperform.

The architecture decision should make the ownership boundaries visible and establish how end-to-end issues will be resolved.

Executive implication: Do not approve an architecture without identifying the business owner, technical service owner, data-management responsibilities and the mechanism for resolving cross-boundary issues.

2. Decision rights: who has authority to make changes?

An architecture distributes more than technology. It distributes decisions.

A central platform may define standards and shared services. Domain teams may control local configurations and product decisions. Security, risk and data governance functions may hold specific approval rights.

The question is not whether every decision should be centralised or decentralised. The question is where each decision belongs, and whether the authority model fits the architecture.

A distributed architecture with centralised decision-making for every routine change creates queues and delays. A shared platform without clear control over standards, security or exceptions creates fragmentation and risk.

The architecture decision should therefore establish decision rights for matters such as:

• Platform standards and approved technology choices.
• Changes to shared interfaces and service contracts.
• Data access, quality rules and information products.
• Security controls and risk exceptions.
• Capacity allocation and service priorities.
• Local extensions and deviations from common standards.
• Incident escalation and recovery decisions.

These rights should be explicit enough to resolve conflicts without requiring senior escalation for every operational issue.

The distinction among responsibility, accountability, authority and control is essential:

• Responsibility means performing or managing an activity.
• Accountability means being answerable for the outcome.
• Authority means having the right to make the decisions required.
• Control means having practical influence over the result.

A team might be responsible for operating a component without being accountable for the end-to-end business outcome. A role with accountability but no practical influence over the outcome is unlikely to succeed.

The architecture decision must align these elements. Accountability without authority creates frustration. Authority without accountability weakens governance. Responsibility without clear escalation paths leaves cross-team problems unresolved.

Executive implication: Confirm who decides, who executes, who approves exceptions and who resolves conflicts. Do not assume the organisation's existing authority model will fit the new architecture.

3. Skills and capacity: can the organisation sustain the design?

A design can depend on skills the organisation does not possess at the required scale or cannot retain over time.

Cloud-native platforms, distributed data architectures, automation and AI-enabled capabilities often introduce specialist requirements for engineering, security, reliability, data management, model oversight and service operations.

The initial programme might fund external specialists and implementation teams. Once the programme ends, the enterprise still needs people who understand the design, operate the services and make safe changes.

The skills decision should cover more than the initial implementation:

• Which capabilities must exist in-house?
• Which skills are available, and which need to be developed or recruited?
• Which responsibilities will be retained by partners or vendors?
• How much capacity is needed for routine operation, incidents and planned change?
• What knowledge must transfer before implementation teams leave?
• How will the organisation manage critical dependencies on specialist individuals, vendors or temporary programme teams?
• Has the organisation funded and assigned the capabilities required to operate the chosen design over time, including continuity and succession of expertise?

Dependence on one specialist, vendor or temporary programme team should be treated as an operating risk, not only a staffing issue.

The architecture may also change the distribution of skills. A shared platform might reduce duplicated engineering effort while increasing demand for platform engineering and product management. Greater automation might reduce manual activity while increasing the need for monitoring, exception handling and control design.

These consequences should be understood before approval, not discovered during transition to operations.

Executive implication: Approve the capability plan alongside the design. Identify the skills, capacity, knowledge transfer and funding needed to sustain the architecture beyond implementation.

4. Operating responsibilities: who runs, changes and retires the capability?

The operating model must cover the full lifecycle, not only steady-state operation.

Someone needs to monitor performance, manage incidents, apply security controls, maintain integrations, handle service requests, recover from failure and evolve the capability as business needs change.

In a distributed architecture, these responsibilities may sit across several teams. The arrangement needs to establish how the pieces work together.

For example, a central platform team might operate a shared service while product teams own the applications consuming it. If an incident crosses the platform and application boundaries, the operating model must identify who coordinates recovery and who communicates the business impact.

Data and AI-enabled capabilities introduce further questions. Who manages data quality and access? Who monitors model or automated-decision performance? Who investigates unexpected behaviour? Who authorises changes to controls and thresholds? Who decides when a capability should be withdrawn?

The answers should reflect the risk and complexity of the capability. A low-risk internal service does not need the same governance as a business-critical service or an automated process affecting customers.

The operating model must also cover transition and retirement.

During transition, the enterprise might need parallel running, migration support, temporary controls and additional service capacity. At retirement, teams need to manage legacy dependencies, residual contracts, archived data, retained records and the removal of access or infrastructure.

If these responsibilities are absent from the decision, the architecture might create long-term costs and operational risks even when implementation succeeds.

A new capability is not fully operational merely because the technology is live; it is operational when the responsible teams have accepted the service, controls and obligations required to sustain it.

A documented target operating model is not enough. The relevant teams must accept their responsibilities, and the required changes must be funded, staffed and incorporated into their plans.

Executive implication: Confirm operational acceptance, service ownership, cross-team incident handling, change responsibilities and lifecycle exit arrangements before committing to the design.

5. Economics and accountability: who funds the capability and validates its value?

Architecture economics extend beyond implementation costs.

A design might appear affordable because the initial business case includes licences, infrastructure and delivery effort. The full operating cost might also include platform engineering, specialist skills, service management, observability, security, resilience, support and continuous improvement.

Shared platforms create additional allocation questions. One team might fund the core service while several business domains consume it. Usage might grow faster than expected, or one domain might require an extension that adds cost for everyone.

The operating model needs to establish how these costs are governed.

A practical economic view should distinguish five areas:

1. Core platform and service funding: Who funds the shared capability and its baseline operating costs?

2. Consumption costs: How are usage, capacity and demand growth measured and allocated?

3. Enhancements and roadmap changes: Who pays for improvements, upgrades and new business requirements?

4. Exceptions and local extensions: Who funds deviations from the common design, and who accepts their long-term support implications?

5. Benefits ownership and validation: Who owns the expected business benefits, and who validates the resulting value?

These are related but separate economic decisions.

The business owner should be accountable for the intended business outcome. Finance, assurance or another appropriately independent function should challenge and validate value using agreed measures and evidence. Technology teams should provide reliable service and cost information, but should not be expected to claim business benefits solely because a technical deliverable went live.

The distinction between planned, actual, claimed and validated value is important. A business case states an expectation. Actual performance shows what happened. A benefits claim attributes a result to an intervention. Validation tests whether the evidence and attribution support the claim.

Architecture decisions should make the economic assumptions visible, including who bears the cost when usage, scope or operating requirements change.

A technically elegant design might still be a poor enterprise choice if the organisation cannot fund its ongoing operation or if the expected benefits depend on operating changes nobody has committed to deliver.

Executive implication: Require a credible lifecycle cost model, explicit funding ownership, agreed benefit measures and a clear process for validating value after implementation.

When must the operating model change first?

Some architecture choices depend on operating changes before the design can deliver its intended outcome.

A platform might require product-based ownership where budgets and accountability still follow temporary projects. A data architecture might depend on domain ownership where data quality responsibilities are fragmented. An automated process might require new control and exception-handling responsibilities before production use.

In such cases, the organisation should not treat the operating model as a later workstream.

The executive decision should establish which changes are prerequisites, who owns them, what funding and capacity they require, and what evidence demonstrates readiness.

Four choices are available:

• Proceed: The current operating model supports the architecture, and remaining actions have clear owners.
• Proceed with conditions: The design is suitable, but named operating changes must be completed before specified commitments, transition points or go-live.
• Redesign: The architecture depends on responsibilities, skills, economics or decision rights the organisation cannot credibly establish in the proposed arrangement.
• Defer or decline: Material prerequisites remain unresolved, or the enterprise is unwilling to fund and accept the required operating commitments.

The right answer depends on the scale of the consequence and the evidence available. Not every technical choice requires an executive approval process. Governance should be proportionate to business impact, risk, cost and the extent of organisational change.

The principle is straightforward: do not approve a target operating model on presentation quality alone. Confirm that the organisation has accepted the changes needed to make the design work.

The architecture decision record

The operating consequences should be recorded alongside the technical rationale. A concise architecture decision record can capture five elements.

1. Business capability and outcome

What business capability is being created or changed? What business outcome must improve? How will success be measured?

2. Architecture choice and trade-offs

Which architecture option was selected? What alternatives were considered? What trade-offs, constraints, dependencies and material risks shaped the decision?

3. Operating-model changes

What must change in ownership, decision rights, skills, processes, service management, data management or funding? Which changes are prerequisites, and which can follow later?

4. Accountable owners and commitments

Name the owners responsible for the business capability, technical service, operational acceptance and required operating changes. Record the commitments, authority, capacity and funding needed to deliver them.

5. Review conditions and evidence

What must be true before implementation, transition, go-live and eventual retirement? Which measures will demonstrate that the capability is operating as intended? When will the decision be reviewed, and what conditions would trigger redesign or retirement?

This record should be proportionate. The purpose is not to add paperwork to every technical decision. It is to make the consequences visible when an architecture choice changes how the enterprise works.

The six-question executive test

Before approving a material architecture decision, executives should ask:

1. 01Outcome: What business outcome must improve, and how will success be measured?
2. 02Ownership: Who owns the business capability, technical service, data management and ongoing performance?
3. 03Authority: Do the people accountable for the outcome have the decision rights and practical control required?
4. 04Capability: Which skills, capacity, data, operational responsibilities and funding arrangements must change?
5. 05Fit: Does the proposed operating model fit the architecture, or are prerequisite organisational changes still unresolved?
6. 06Evidence: What evidence will demonstrate readiness, operational acceptance and sustained performance?

If these questions cannot be answered, the architecture decision is incomplete.

The right architecture is one the enterprise can operate

The strongest architecture is the one that meets business requirements within the organisation's actual constraints, while making the necessary changes to those constraints explicit.

A design should not be judged solely on technology fit, integration, security, scalability and cost. Those dimensions are necessary, but they do not establish whether the enterprise is prepared to operate the resulting capability.

The operating model determines how architecture becomes a working business service: who owns the capability, who makes decisions, which skills are required, how exceptions are managed and who is accountable for outcomes.

Executives do not need to resolve every operating detail before approving every technical choice. They do need to understand which consequences are material, who owns them and what must be true before the expected benefits are credible.

Before approving the architecture, ask: what must change in the way the organisation works for this design to deliver its intended business outcome, who owns those changes and what evidence will show the arrangement is working?

That is the difference between approving a design and making an enterprise architecture decision.

Sources and further reading

These sources provide conceptual grounding for the article's relationship between architecture, operating-model design, decision rights and technology investment. They should not be interpreted as empirical validation of every recommendation or of the five-part framework presented here.

1. Ross, J. W., Weill, P. and Robertson, D. C. (2006). Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. Harvard Business School Press. MIT CISR publication page

2. Weill, P. and Ross, J. W. (2004). IT Governance: How Top Performers Manage IT Decision Rights for Superior Results. Harvard Business School Press.

3. Ross, J. W. and Beath, C. M. (2002). “Beyond the Business Case: New Approaches to IT Investment.” MIT Sloan Management Review. Read the article