What is an Enterprise Architect?

Research Question

What does an Enterprise Architect (EA) do, what do they explicitly not do, and how is the role distinguished from Business Architect and Domain Architect roles, including what they own, what they govern, what they produce, and what good versus poor performance looks like?

Findings

Executive Summary

An Enterprise Architect (EA) owns and maintains an enterprise-wide, cross-domain architecture baseline (spanning business, data, application, and technology) and a roadmap for moving from current state to target state, governing conformance to that baseline through negotiated standards rather than personally authoring every solution-level artefact. This ownership-and-governance boundary is what most reliably separates the EA role from a Business Architect, whose scope is limited to the technology-agnostic business-capability and value-stream layer, and from a Domain Architect, whose scope is technical depth within one domain such as data, security, or infrastructure. The role explicitly excludes unilateral solution design and technology mandate-setting, which belong to Solution and Software Architects operating inside EA-set guardrails. Good EA performance is recognised through outcome-linked metrics such as total cost of ownership reduction and project conformance rate, whereas poor performance recurs across independent practitioner sources as "ivory tower" detachment from delivery and deliverables (diagrams, decks) that do not translate into actionable guidance. The single largest residual uncertainty is that framework standards (TOGAF, FEAF) specify roles more formally than commercial practice actually follows them, so the aspirational and empirical pictures diverge in ways this item can only partly reconcile from public secondary sources.

Key Findings

1. The TOGAF Standard, published by The Open Group, defines the Enterprise Architect as accountable for developing and maintaining an enterprise-wide architecture spanning Business, Data, Application, and Technology domains, in contrast to narrower single-domain or single-project architect roles.
2. The Zachman Framework is a classification ontology, not a process methodology, organising enterprise knowledge into six perspectives crossed with six interrogatives, which makes the Zachman-derived EA role one of ensuring completeness and consistency of enterprise descriptions rather than executing a change process.
3. Gregor Hohpe's "Architect Elevator" framing holds that most traditional architect tasks such as drawing diagrams and mandating designs are better performed by development teams and tooling, and that the distinctive, non-substitutable contribution of an enterprise-level architect is moving between an organisation's strategic and technical layers to keep them mutually informed.
4. Enterprise architects in the Federal Enterprise Architecture Framework (FEAF) context are required to maintain current-state and target-state descriptions across Performance, Business, Data, Application, Infrastructure, and Security reference models and to produce a transition roadmap, partly to support statutory Clinger-Cohen Act IT capital-planning compliance.
5. A practitioner source (Ben Morris) names "ivory tower" architecture, where strategy and guidance are produced with too little contact with delivery reality, as one of several named enterprise architecture anti-patterns.
6. A three-tier accountability model recurs across practitioner sources: the EA owns the enterprise-wide architecture framework and standards, governs solution-level designs by requiring conformance without personally producing every artefact, and advises delivery teams and executives without unilateral authority outside its governance remit.
7. Enterprise Architecture Metrics practitioners and analyst sources describe EA success measurement as outcome-based rather than activity-based, citing strategic-alignment ratios, total cost of ownership reduction, application-portfolio rationalisation, and project conformance rate as recurring key performance indicators.
8. Business Architecture, as described in secondary sources summarising the Business Architecture Guild's BIZBOK Guide, is technology-agnostic and scoped to organisational capabilities, value streams, and business processes, whereas Enterprise Architecture is the broader, technology-inclusive discipline that treats business architecture as one of its constituent domains.
9. Solution Architects operate at project-specific, tactical scope designing and delivering an individual system within guardrails the Enterprise Architect sets, while Domain Architects (e.g. Data, Security, Infrastructure Architect) operate with technical depth in one domain across the organisation.
10. IASA's Business Technology Architecture Body of Knowledge (BTABoK), formerly the IT Architecture Body of Knowledge (ITABoK), names Enterprise Architect as one of several distinct architect specialisations sharing a common five-pillar competency baseline (Business Technology Strategy, Human Dynamics, IT Environment, Design, Quality Attributes) alongside Business, Solution, Software, Information, and Infrastructure Architect roles.
11. The EA-Solution Architect relationship functions as a negotiated "handshake" in practice: the EA sets integration and governance standards, and the Solution Architect flags when a specific project requirement falls outside the established framework, making architectural coherence a joint rather than a unilaterally top-down responsibility.

Assumptions

The BTABoK/ITABoK five-pillar competency model is assumed to still reflect IASA's current framework structure as of this research. This assumption is justified because the secondary search results describing it were current and IASA's own education portal, though only its landing page was directly accessible, still resolves under the same domain and naming. Gartner's outcome-based EA measurement position is assumed to be accurately represented by secondary paraphrase rather than direct primary-document text. This assumption is justified because the Gartner document itself sits behind an access-controlled client portal and no freely accessible primary text could be independently verified in this session. The Business Architecture Guild's BIZBOK-derived Business Architecture/Enterprise Architecture boundary is assumed to be accurately summarised by vendor blog sources rather than the primary Guild text. This assumption is justified because the BIZBOK Guide itself is a paywalled membership publication not accessible in this session, while two independent vendor sources converge on the same boundary description.

Analysis

The most directly-verified claims in this item rest on primary practitioner sources fetched and read in full (Hohpe's Architect Elevator essay, Ben Morris's anti-pattern taxonomy, and EACOE's role comparison), rather than through secondary paraphrase, though each is still held at medium rather than high confidence because a single source, however directly verified, does not meet the two-independent-source bar for high confidence. Claims resting on the Zachman Framework, FEAF, BIZBOK, and BTABoK are held at medium rather than high confidence because the primary standard or body-of-knowledge text was either inaccessible in this session (Zachman.com, FEAF PDF, BIZBOK Guide, BTABoK content pages) or accessible only as a landing page, so the item relies on tertiary encyclopedic or secondary vendor summaries for those frameworks. The competing interpretation that EA is merely a job title applied inconsistently, with no stable underlying accountability, is only partly supported: while titling practice clearly varies in the labour market, every framework and practitioner source examined converges on the same four-part accountability core (enterprise-wide scope, standards governance rather than direct production, strategic-technical bridging, and an explicit boundary against unilateral solution design), which weighs against treating the role as purely title inflation with no substantive content. The main unresolved trade-off is between framework-prescribed authority (TOGAF's governance mandate, FEAF's statutory tie) and the practitioner-observed reality that this authority frequently does not translate into actual influence, which the anti-pattern literature attributes to a communication and delivery-engagement gap rather than to the frameworks themselves being wrong about what the role should do.

Risks, Gaps, and Uncertainties

• The Zachman Framework's official site (zachman.com) was inaccessible in this session; its role framing is corroborated only through the Wikipedia summary and secondary practitioner blogs rather than the primary framework text, so nuances in Zachman's own EA role framing may be missed.
• The primary FEAF Version 2 document could not be re-fetched directly (only reached via a secondary Wikipedia summary and a landing-page reference to a Whitehouse.gov PDF listed in the original Sources), so specific FEAF role text beyond the general reference-model structure was not independently verified.
• The Business Architecture Guild's BIZBOK Guide is a paywalled membership publication; this item relies on vendor-blog paraphrase for the Business Architecture/Enterprise Architecture boundary, which may understate nuances the Guild itself makes about overlapping scope.
• Gartner's specific outcome-metrics position was reached only via a secondary aggregator; the primary Gartner Executive FastStart document requires client access not available in this session.
• IASA's ITABoK/BTABoK direct content pages (itabok.iasaglobal.org, metis.iasaglobal.org) returned redirects or inaccessible content in this session, limiting the item to a secondary synthesis of the competency model rather than a direct primary-text read.
• Nick Malik's practitioner blog (a seeded source on MSDN) was not independently located or verified in this session, as MSDN blog archives from that author could not be confirmed accessible; this source is therefore removed from the item's evidence base pending future verification.

Open Questions

• Does TOGAF 10th Edition materially change the Architecture Skills Framework's competency-to-role mapping relative to TOGAF 9.2, and if so, how does that affect the EA/Solution Architect boundary described here?
• What does empirical labour-market data (job postings, salary surveys) show about how consistently "Enterprise Architect" job titles map to the accountability core identified in this item, versus being applied to project-level solution architecture roles?
• How does the Business Architecture Guild's BIZBOK Guide itself (rather than vendor paraphrase) describe the boundary and overlap between Business Architecture and Enterprise Architecture governance authority?

sources

• [x] The Open Group TOGAF Standard - defines EA responsibilities and Architecture Skills Framework competency-to-role mapping
• [x] Bizzdesign Business Architecture vs. Enterprise Architecture - summarises Business Architecture Guild's Business Architecture Body of Knowledge (BIZBOK) boundary between Business Architecture and Enterprise Architecture (replaces inaccessible opengroup.org/togaf/ba-guide)
• [x] Wikipedia Zachman Framework - original EA framework structure and role framing (replaces inaccessible zachman.com/about-the-zachman-framework)
• [x] International Association of Software Architects (IASA) Global Business Technology Architecture Body of Knowledge (BTABoK) education portal - practitioner-focused definition of architect specialisations (replaces inaccessible iasaglobal.org/itabok/)
• [x] Gregor Hohpe, The Architect Elevator (via Martin Fowler) - practitioner essay on EA role in modern organisations
• [x] Gartner Executive FastStart for Heads of Enterprise Architecture - analyst view on EA outcomes and value (accessed via secondary paraphrase only; see Risks/Gaps)
• [x] Wikipedia Federal Enterprise Architecture - government EA role definition for comparison (replaces inaccessible whitehouse.gov FEAF v2 PDF)
• [x] Ben Morris, Enterprise Architecture Anti-Patterns - practitioner taxonomy of EA failure modes
• [x] Enterprise Architecture Center of Excellence (EACOE) Enterprise Architect vs Solution Architect: Key Differences - practitioner comparison of EA, Solution Architect, and Domain Architect scope and the own/govern/advise accountability model
• [x] KPI Depot: 12 Most Important Enterprise Architecture KPIs - EA success metrics and benchmarks
• [x] LeanIX Enterprise Architecture Metrics - corroborating EA success metrics source
• [x] LeanIX Enterprise Architect vs. Domain Architect vs. Developer - Domain Architect scope distinction