Who Owns What? A Practical Guide to Architecture Roles

Architecture titles are surprisingly poor at explaining what an architect actually does.

Two companies can employ people with the title Solution Architect and give them completely different responsibilities. One may design end to end systems. Another may spend most of the week reviewing diagrams. A third may effectively operate as the senior engineer on a delivery team.

The more useful way to distinguish architecture roles is not by title. It is by decision ownership.

Architecture roles should be distinguished by the decisions they own, not by the diagrams they create or the meetings they attend.

A successful architect is not the architect who makes the most decisions. It is the architect who helps the right decisions get made at the right level.

A Simple Mental Model

For general architecture roles, the scope often moves through four levels:

Enterprise
    ↓
Domain
    ↓
Solution
    ↓
Application / Software

Specialist architects such as Platform, Cloud, Data, Security, Integration, Infrastructure, and AI Architects intersect those levels. They are not necessarily above or below the other roles. Their scope follows a particular technical concern across the organization.

An organization does not need every title on this list. It does need clarity about who owns the decisions represented by them.

Enterprise Architect

Primary question: How should the organization's technology landscape evolve?

The Enterprise Architect works at the level of direction, coherence, shared principles, major capabilities, target states, and decisions that affect multiple domains.

Consider an organization deciding that event driven architecture should become a strategic capability. The Enterprise Architect might establish why that capability matters, where it should and should not be encouraged, the enterprise principles around ownership and interoperability, and the guardrails that downstream teams should respect.

The Enterprise Architect should not normally design every event, configure the platform, or decide the retry strategy inside an individual service.

What good looks like

• Maintains a small number of meaningful principles and guardrails that teams can actually apply.
• Stays close enough to delivery and operations to know whether strategic direction works in practice.
• Focuses enterprise attention on decisions that genuinely require enterprise scope.
• Creates reusable direction and reference patterns rather than making every project seek approval.
• Revisits standards when evidence, technology, economics, or organizational needs change.
• Deliberately leaves local decisions local.

Common failures

• The approval board: enterprise architecture becomes a gate every team must pass through.
• Presentation architecture: target states look compelling but have little connection to engineering reality.
• Excessive reach: enterprise architects begin owning detailed solution and implementation choices.
• Permanent standards: strategic decisions survive long after the assumptions behind them have changed.

Domain Architect

Primary question: How should this business or technology domain evolve?

The Domain Architect connects enterprise direction with the systems, capabilities, information, and roadmaps inside a particular domain.

In an event streaming example, the Domain Architect may identify authoritative event producers, domain boundaries, ownership, important contracts, and where asynchronous interaction makes sense within that domain.

This role is especially valuable in large organizations because the distance between enterprise strategy and individual projects can otherwise become too large.

What good looks like

• Maintains a coherent view of domain capabilities, systems, ownership, dependencies, and important data.
• Translates enterprise direction into domain choices without simply copying enterprise standards downward.
• Identifies recurring solution problems and resolves them once at the appropriate domain level.
• Works across product and solution boundaries so local projects do not gradually fragment the domain.
• Balances today's delivery pressures with a credible path for long term domain evolution.

Common failures

• The missing middle: the role does not exist, leaving enterprise architects too far from reality and solution architects reinventing domain decisions.
• Shadow enterprise architecture: the domain architect creates an independent standards organization inside the domain.
• Project gravity: urgent delivery work consumes the role until long term domain evolution disappears.

Solution Architect

Primary question: How should we solve this particular business problem end to end?

The Solution Architect translates requirements, constraints, quality attributes, enterprise guardrails, and domain context into a coherent solution.

For a particular solution, this architect may decide whether events are appropriate, how systems integrate, where responsibilities sit, what failure modes matter, and how reliability, security, scalability, observability, and cost affect the design.

What good looks like

• Understands the business problem before selecting the technical shape of the solution.
• Makes important tradeoffs, assumptions, constraints, and quality attributes visible.
• Stays engaged with delivery long enough to see whether the architecture survives implementation.
• Designs with engineers rather than handing engineers a finished architecture.
• Uses enterprise, domain, security, data, and platform guardrails with judgment rather than mechanically.
• Leaves appropriate implementation decisions with the engineering team.

Common failures

• The accidental project manager: coordination and meetings replace architecture work.
• The super developer: the architect personally solves every difficult implementation problem and becomes a bottleneck.
• The diagram handoff: architecture is produced before delivery and then detached from what engineers actually build.
• Local optimization: the solution works for one initiative while creating unnecessary complexity for the wider domain.

Application and Software Architect

Primary question: How should the software itself be structured?

These titles vary considerably between organizations, but both usually sit closer to implementation than enterprise or solution architecture.

The work includes component boundaries, contracts, domain structure, runtime behavior, failure handling, persistence, APIs, internal patterns, and the technical evolution of the software.

In the event example, this is where questions such as idempotency, retries, ordering, consumer behavior, local persistence, and error recovery become concrete.

What good looks like

• Remains close to code, tests, runtime behavior, and operational evidence.
• Keeps boundaries and contracts understandable as the system evolves.
• Chooses the simplest design that satisfies the important quality attributes.
• Uses prototypes and measurements when important technical assumptions are uncertain.
• Develops architectural judgment across senior engineers instead of centralizing every decision.
• Treats architecture as something that evolves with the software rather than a design phase that ends.

Common failures

• Architecture without code proximity: the architect gradually loses contact with how the system actually behaves.
• Overengineering: architectural sophistication becomes a goal independent of business value.
• Centralized technical ownership: senior engineers stop developing architectural judgment because every meaningful decision goes through one person.

Platform Architect

Primary question: What reusable capabilities should engineering teams consume?

The Platform Architect thinks across many teams. The objective is not to solve the same infrastructure and engineering problems repeatedly, but to turn common needs into reliable capabilities with clear interfaces and a good developer experience.

For event streaming, the Platform Architect may shape provisioning, authentication, authorization, observability, schemas, operational defaults, self service workflows, and the experience teams use to adopt the capability.

What good looks like

• Treats engineering teams as customers and measures whether the platform actually reduces their cognitive load.
• Provides paved paths with sensible defaults while preserving escape hatches for legitimate exceptions.
• Designs stable, reusable capabilities and interfaces rather than exposing infrastructure complexity directly.
• Uses adoption, reliability, developer feedback, support burden, and delivery outcomes as evidence.
• Partners with security, cloud, data, solution, and software architecture instead of absorbing their responsibilities.
• Earns adoption through usefulness wherever possible rather than relying on mandates.

Common failures

• The platform dictator: adoption is driven by mandates rather than usefulness.
• Infrastructure disguised as platform: technology exists, but there is no usable product experience around it.
• Lowest common denominator design: centralization removes the flexibility teams genuinely need.
• Building without customers: the platform roadmap is disconnected from engineering teams using it.

Specialist Architects

Some architecture roles are better understood as disciplines that cut across several levels.

• Cloud Architect: cloud foundations, workload patterns, networking, resilience, identity, capacity, and economics.
• Data Architect: data ownership, models, contracts, lineage, movement, governance, and analytical or operational use.
• Security Architect: threat models, trust boundaries, identity, authorization, controls, blast radius, and detection.
• Integration Architect: APIs, events, messaging, contracts, schemas, interoperability, and integration patterns.
• Infrastructure Architect: compute, network, storage, runtime foundations, capacity, resilience, and infrastructure standards.
• AI Architect: models, context, retrieval, agents, tools, evaluation, inference, observability, governance, security, cost, and human oversight.

What good looks like

Strong specialist architects begin with the system problem and bring their specialty into the decision at the right depth. They create reusable expertise, patterns, evidence, and guardrails without forcing every problem through the same technology. They also know when another discipline should own the decision.

• Cloud: starts from workload characteristics and quality attributes, then chooses cloud capabilities.
• Data: makes ownership, meaning, quality, movement, and lifecycle explicit rather than focusing only on storage technology.
• Security: participates early as a design partner and makes trust boundaries and threat assumptions concrete.
• Integration: chooses communication patterns from semantics, coupling, reliability, and ownership needs rather than tool preference.
• Infrastructure: connects runtime foundations to application reliability, operability, capacity, and cost.
• AI: treats probabilistic model behavior, evaluation, authority, observability, security, cost, and human oversight as architectural concerns.

Common failures

The recurring failure across specialist roles is starting with the specialty rather than the problem. A Cloud Architect who begins with cloud products, an Integration Architect who begins with Kafka, or an AI Architect who begins with an LLM has already narrowed the decision too early.

One Decision, Seen Through Different Roles

Imagine an organization wants an enterprise event streaming capability.

Role	Decision perspective
Enterprise Architect	Should event streaming be a strategic enterprise capability, and what principles should govern it?
Domain Architect	Where do events belong in this domain, what do they mean, and who owns them?
Platform Architect	What reusable event capability and developer experience should teams receive?
Solution Architect	Should this particular solution use events, where, and for what reason?
Software Architect	How should producers and consumers behave, fail, recover, and evolve?
Engineers	How do we implement, test, operate, and improve it?

Notice that several roles may participate in the same technology decision without owning the same part of the decision.

The Architecture Ownership Map

A useful alternative to arguing about titles is to define four relationships for important architecture decisions.

• Own: this role is accountable for making or maintaining the decision.
• Influence: this role provides expertise that should materially shape the decision.
• Collaborate: the decision crosses a boundary and should be worked through together.
• Do Not Own: this role should deliberately leave the decision somewhere else.

The fourth category matters. Healthy architecture is not only about establishing authority. It is also about establishing restraint.

Relationship	Enterprise Architect example	Solution Architect example
Own	Enterprise direction, principles, major cross domain guardrails	End to end architecture for the solution
Influence	Major platform and technology strategy	Enterprise and domain standards that affect delivery
Collaborate	Domain, platform, security, data, and engineering leadership	Engineering, domain, platform, security, data, and operations
Do Not Own	Component implementation and local engineering choices	The entire enterprise technology portfolio or every implementation detail

When Architecture Organizations Go Wrong

Most architecture dysfunction is not caused by a missing diagram. It comes from unclear decision boundaries.

• The Approval Board: architects become people who approve designs produced elsewhere.
• The Everything Architect: one role attempts to own enterprise standards, solution design, cloud, security, data, and implementation.
• The Architecture Vacuum: nobody owns long term domain evolution, so projects repeatedly solve the same problem differently.
• The Vendor Architect: architecture becomes a sequence of product selections instead of a response to system qualities and constraints.
• The Handoff Model: architects design, engineers implement, and neither remains accountable for the gap between the two.
• The Governance Trap: consistency is pursued by centralizing decisions that would be safer and faster when kept local.

Not Every Organization Needs Every Architect

A smaller organization may have one experienced architect covering several scopes. A large enterprise may need distinct enterprise, domain, solution, platform, security, data, and software architecture responsibilities.

The organizational chart is secondary. The important question is whether consequential decisions have clear ownership without removing appropriate autonomy from engineering teams.

Adding another architect title does not fix an unclear operating model.

Four Questions Every Architecture Role Should Answer

Instead of beginning with a job description, begin with four questions:

1. What decisions do I own?
2. What decisions do I influence?
3. Where must I collaborate?
4. What decisions should I deliberately not own?

The last question may be the most important.

Architecture organizations rarely struggle because they lack intelligent people. They struggle when multiple intelligent people believe they own the same decision, or when everybody assumes somebody else owns it.

Make the decision visible. Make the boundary explicit. Then let each architecture role operate at the level where it creates the most value.

Explore this topic

Part of the Architecture Practice topic collection.

• A Practical Architecture Decision Framework
• Platform Engineering 2.0
• Cognitive Load Is an Architecture Constraint