Architecture Capability Framework: Building the EA Function That Actually Delivers

Framework: Architecture Capability Framework Perspective: Enterprise Architect

You can know every TOGAF phase by heart and still fail as an enterprise architect if the EA function itself is poorly designed. The Architecture Capability Framework is the meta-discipline: architecture of the architecture practice.

Key Inputs

Organisational strategy and maturity
Current EA team structure and skills
Business demand for architecture services
Governance and decision-making structures
Budget and resource constraints
Benchmarks from peer organisations

The Process

Assess current EA capability maturity
Define target EA operating model
Design EA team structure and roles
Establish Architecture Board and governance forums
Define EA service catalogue
Build skills development and recruitment plan

Deliverables

EA Operating Model
Architecture Organisation Structure
Architecture Board Terms of Reference
EA Service Catalogue
Skills Framework and Capability Plan
EA Maturity Assessment and Roadmap

Practitioner Perspective

The Architecture Capability Framework covers everything required to run a credible EA function: the organisation design, the governance forums, the skills framework, and the operating model. This is the framework that answers the question every EA programme must eventually face: what kind of EA function does this organisation need, and does it exist yet?

Design your Architecture Board carefully. It should include senior business leaders, not just IT. Business representation is what gives architecture decisions commercial legitimacy and ensures the function is seen as a business capability rather than an IT overhead. Define clear decision rights: what the board decides, what it advises on, and what sits with project governance or programme boards.

Your EA Service Catalogue defines the function's offer to the organisation. Be explicit and measurable. Common EA services include: architecture assurance (reviewing projects for compliance), architecture advisory (engaging with strategy and investment decisions), architecture development (producing architecture artefacts), and architecture governance (running the ARB and managing the repository). If you cannot describe what you deliver in service terms, you will forever be defending your existence in budget cycles.

EA maturity models (such as Gartner's ITScore or the TOGAF Maturity Model) provide useful benchmarks for assessing where you are and where you need to be. Do not aim for maximum maturity — aim for the maturity level appropriate to your organisation's size, complexity, and ambition.

The most common mistake: Building an EA function sized for an organisation that does not yet exist. A team of 12 architects in a 2,000-person company that has never had EA before will struggle for relevance. Start small, prove value, grow deliberately.

Practical tips:

Define a clear EA engagement model: when projects must engage EA, at what stages, with what lead time, and through what process — ambiguity here creates friction and resentment
Create an EA career pathway that is distinct from solution architecture and IT management — if there is no career in EA, you will not attract or retain the right people
Measure the EA function on outcomes, not outputs: reduced time-to-market, reduced integration cost, improved investment decision quality — not number of diagrams produced
Run an annual EA stakeholder satisfaction survey — it forces honest reflection on whether the function is serving the organisation or serving itself

Part of a series: TOGAF from an Enterprise Architect's Perspective