Enterprise Architecture Capability and Governance
Architecture capability
An Enterprise Architecture capability is the combination of people, roles, skills, method, governance, information, tools, and relationships required to perform useful architecture work repeatedly.
An architecture team alone is not a capability. The capability exists only when architecture connects to how the enterprise sets strategy, funds change, makes decisions, delivers, operates, and learns.
Capability components
- mandate and sponsorship;
- scope and service model;
- roles and competencies;
- tailored method and content standards;
- decision rights and governance bodies;
- engagement model with delivery teams;
- repository and tooling;
- metrics and improvement cycle;
- integration with portfolio, risk, security, procurement, and operations.
Operating models
| Model | Strength | Risk |
|---|---|---|
| Centralized | Consistency and enterprise-wide authority | Bottlenecks and distance from delivery |
| Federated | Domain knowledge with common guardrails | Ambiguous accountability |
| Embedded | Fast product and solution support | Local optimization and duplication |
| Hybrid | Balances enterprise and local needs | Requires explicit decision boundaries |
A hybrid or federated model is common: a small central function owns shared principles and cross-enterprise concerns while domain and product architects work close to delivery.
Key roles
Role titles vary. Clarify accountabilities rather than relying on names.
| Role | Primary accountability |
|---|---|
| Executive sponsor | Mandate, funding, and removal of organizational barriers |
| Architecture Board | Material architecture decisions and governance oversight |
| Chief/Lead Architect | Coherence of the architecture practice and landscape |
| Enterprise Architect | Strategy-to-change alignment across broad scope |
| Business Architect | Capabilities, value, organization, and operating model |
| Data Architect | Meaning, ownership, flow, quality, and governance of data |
| Application Architect | Application services, interactions, and portfolio |
| Technology/Platform Architect | Platform services, standards, and lifecycle |
| Security Architect | Risk-driven security requirements and designs |
| Solution Architect | Architecture of a bounded initiative or solution |
| Product/Domain Architect | Evolution of a persistent product or domain |
| Repository custodian | Integrity and usability of controlled architecture content |
Architecture Board
An Architecture Board is an accountable governance body, not necessarily a large committee. It should have:
- a defined mandate;
- scope and delegated authority;
- membership appropriate to decisions;
- published decision criteria;
- quorum and escalation rules;
- conflict-of-interest handling;
- a predictable meeting or asynchronous process;
- recorded decisions and actions.
Delegate low-risk decisions. Escalate only when scope, risk, cost, or cross-enterprise impact requires it.
Architecture governance
Architecture governance is the system by which architecture decisions are made, implemented, monitored, and corrected.
Good governance provides:
- clear decision rights;
- transparent criteria;
- timely engagement;
- traceability;
- proportional controls;
- exception handling;
- accountability for outcomes; and
- feedback from delivery and operations.
Governance is not the same as centralized design approval.
Decision rights
For each decision type, define:
- who proposes;
- who must be consulted;
- who decides;
- who can approve an exception;
- what evidence is required;
- when the decision is revisited.
Examples include principles, enterprise standards, domain models, shared platforms, solution designs, data ownership, investment sequencing, and exceptions.
Architecture Contract
An Architecture Contract or equivalent working agreement can specify:
- parties and scope;
- architecture requirements and standards;
- roles and responsibilities;
- deliverables and evidence;
- review points;
- conformance measures;
- exception and escalation process;
- change control; and
- acceptance conditions.
Keep it integrated with delivery agreements rather than creating a disconnected legalistic document.
Compliance reviews
A compliance review should ask:
- Which approved architecture, principles, requirements, and standards apply?
- What evidence shows conformance?
- Where does the design differ?
- Is the difference an improvement, a necessary exception, or unmanaged debt?
- What is the risk and business impact?
- Who can accept it, for how long, and with what conditions?
Possible outcomes:
- conformant;
- conformant with actions;
- partially conformant with approved exception;
- non-conformant and must change;
- reference architecture itself requires revision.
Exceptions
An exception should record:
- exact scope;
- rationale and alternatives considered;
- affected requirements and standards;
- risks and compensating controls;
- owner and approving authority;
- start and expiry/review date;
- remediation or exit plan;
- monitoring evidence.
Permanent exceptions without review are hidden standards changes.
Connecting governance to delivery
Use risk-based touchpoints:
| Delivery point | Architecture purpose |
|---|---|
| Idea or discovery | Clarify outcome, scope, dependencies, and reusable assets |
| Investment decision | Assess alignment, options, risk, and roadmap fit |
| Inception | Agree requirements, constraints, and decision ownership |
| Design | Resolve consequential and cross-cutting choices |
| Before build/release | Confirm evidence for high-risk requirements |
| Release/operate | Validate actual behavior and residual risk |
| Post-implementation | Capture outcomes, debt, patterns, and architecture updates |
Automate checks for machine-verifiable standards where practical.
Metrics
Balance activity, quality, delivery, and outcome measures:
- lead time for architecture decisions;
- percentage of engagements started early enough;
- exception age and closure rate;
- technology risk and obsolescence trend;
- duplicated capabilities or applications removed;
- reuse of shared services and patterns;
- requirements verified at release;
- roadmap outcome realization;
- stakeholder usefulness feedback.
“Number of diagrams produced” is not a value metric.
Maturity progression
A simple progression:
- Ad hoc — architecture depends on individuals.
- Repeatable — basic method, roles, and artifacts exist.
- Defined — governance and repository are organization-wide.
- Measured — outcomes and conformance are tracked.
- Adaptive — architecture continuously informs and learns from strategy and delivery.
Improve the constraint causing the most harm; do not pursue maturity scores for their own sake.