Roles vs Titles
Many architecture discussions begin with titles.
Should we have Enterprise Architects?
Do we need Domain Architects?
What is the difference between a Chief Architect and a Solution Architect?
While these questions seem important, they often distract from a more fundamental concern:
Architecture effectiveness depends on responsibilities and decision rights, not job titles.
Organizations frequently spend significant effort defining titles while leaving accountability unclear.
The result is confusion, overlap, and governance that depends more on individuals than on the operating model.
Titles Are Labels
Titles are useful.
They help communicate seniority, specialization, and organizational structure.
Examples include:
- Chief Architect
- Enterprise Architect
- Domain Architect
- Solution Architect
- Platform Architect
- Product Owner
- Technical Lead
However, titles alone tell us very little about what someone actually owns.
An Enterprise Architect in one organization may define strategy and investment priorities.
In another organization, the same title may primarily review solution designs.
The title is identical.
The responsibilities are not.
Roles Define Accountability
Roles exist to establish accountability.
A role answers questions such as:
- What decisions can this person make?
- What outcomes are they responsible for?
- What risks do they own?
- What authority do they have?
Architecture governance becomes significantly clearer when organizations focus on roles rather than titles.
Consider the following simplified operating model.
| Role | Primary Responsibility |
|---|---|
| Board | Business strategy and investment direction |
| IT Management | Technology strategy and governance |
| IT Architect | Architecture principles, target architecture, and decision support |
| Delivery Team | Solution design and implementation |
Notice that none of these are job titles.
They are roles.
Multiple individuals may perform the same role.
A single individual may perform multiple roles.
The focus remains on accountability.
Start with Decisions, Not Titles
When designing an architecture operating model, begin with decisions rather than titles.
Ask:
- Who defines architecture principles?
- Who owns technology strategy?
- Who approves major investments?
- Who designs solutions?
- Who accepts architecture exceptions?
Only after these responsibilities are clear should titles be assigned.
A useful principle is:
Decisions create roles. Titles communicate them.
The Problem with Title-Centric Organizations
When organizations optimize around titles, several problems emerge.
Governance Becomes Person-Dependent
Architecture decisions depend on who attends a meeting rather than on defined decision rights.
Responsibility Overlaps
Multiple architects review the same decision without clear ownership.
Delivery Slows Down
Teams spend time navigating organizational structures rather than solving business problems.
Architecture Becomes a Function
Architecture becomes something architects do instead of a capability embedded across the organization.
Architecture as a Capability
This is one of the reasons I believe architecture should be viewed as a capability rather than a function.
Capabilities are not owned by titles.
Capabilities are enabled through operating models, governance, skills, principles, and decision-making structures.
The goal is therefore not to create more architecture titles.
The goal is to ensure that architectural responsibilities are understood and that decision rights are clear.
Titles Change. Responsibilities Endure.
Titles vary significantly between organizations.
What one company calls an Enterprise Architect may be called a Chief Architect, Domain Architect, Lead Architect, or Principal Architect somewhere else.
The title is less important than the decisions that role owns.
Architecture maturity improves when organizations stop asking:
What architects should we have?
and start asking:
What architectural decisions need to be made?
Final Thoughts
Titles matter.
But roles matter more.
Organizations rarely fail because they chose the wrong architecture title.
They fail because decision ownership, accountability, and governance are unclear.
Architecture is ultimately about enabling better decisions.
The first step is ensuring that everyone understands who owns them.