An architecture function is not a homogeneous group of generalists all doing the same thing. The most effective ones have differentiated roles — architects operating at different levels of abstraction, with different stakeholder sets, and with different balances of the two hats.
Five archetypes recur consistently across mature architecture practices.
Solution Architect
Works at the initiative level. Owns the design and delivery governance of individual IT projects, from Solution Overview development through IT Design to delivery review. Primary stakeholders: project managers, business analysts, and technical specialists. Uses the Technology Expert hat heavily during design, the Change Agent hat when navigating competing interests. The most numerous archetype and the entry point for most architects — Initiative Alignment is where architecture begins.
Domain Architect
Works at the technical landscape level. Owns a specific EA domain — applications, data, integration, infrastructure, security, cloud — and is responsible for the IT Standards and IT Landscapes in that domain. Primary stakeholders: solution architects (whose designs they review for domain compliance) and senior IT specialists (whose expertise they synthesise into standards). The primary operator of the Technology Alignment process.
Business Area Architect
Works at the business unit level. Owns end-to-end IT planning for a specific business area — a line of business, a major function, a geography. Runs both Strategic Alignment and Initiative Alignment for their area, and must be as credible in a conversation with a business unit director as in a discussion about integration architecture. The archetype requiring the most balanced combination of both hats.
Enterprise Architect
Works at the organisation-wide level. Responsible for the cross-cutting planning that transcends any individual domain or business area: owns the Business Capability Model, the overarching Roadmap, the top-level Business Factors, and cross-domain IT Standards. Primary stakeholders: the C-suite. Operates the Change Agent hat at its highest intensity — trusted advisory relationships with senior business executives are their primary value.
Architecture Manager
Not primarily an architect. Manages other architects, organises the function’s operations, and ensures the practice is improving over time. Responsible for governance forums running effectively, artefact quality being reviewed periodically, and architectural capability being developed in the team. In small organisations this role may be combined with Enterprise Architect; in large ones it is usually separate.
Two supporting roles
- Engagement Managers — handle the stakeholder identification and relationship management work that precedes the D-E-A process, opening the conversations that architects then have.
- Technical Designers — handle the detailed implementation specifications that sit below the level of IT Designs — system internals, detailed data models, infrastructure configurations — delegating that work from architects to specialists.
Building the function incrementally
The practical implication for building an architecture function: start with what the practice needs to do now, not with an ideal org chart.
- Stage One (Initiative Alignment): Solution Architects only.
- Stage Two (adding Technology Alignment): Domain Architects are added.
- Stage Three (adding Strategic Alignment): Enterprise Architects and Business Area Architects become necessary.
One observation the evidence strongly supports: an Enterprise Architect in an organisation with no Strategic Alignment practice is not doing Enterprise Architecture. Hire for the capability you can use now. The architecture function should grow incrementally, each role added when the organisation is ready to support what that role does.