Enterprise Architecture (EA) is the structured practice of aligning an organization's business strategy, processes, information flows, and technology systems into a coherent, documented blueprint. EA Governance is the companion discipline that establishes who holds decision-making authority over architectural choices, how those decisions are made, enforced, and reviewed, and how architecture remains aligned with organizational objectives over time. Together, EA and EA Governance answer two distinct questions: 'What should our technology landscape look like?' (the architecture artifact) and 'How do we make, approve, and sustain good architectural decisions?' (the governance process).
EA encompasses five interconnected domains: Business Architecture (capabilities, processes, organizational structure), Application Architecture (software systems and their interactions), Data Architecture (information assets, flows, and data management), Technology/Infrastructure Architecture (hardware, networks, cloud, and platforms), and Security Architecture (controls, zero-trust boundaries, and risk posture).
EA is NOT: a one-time IT project plan, a vendor product roadmap, an IT operations runbook, or a substitute for IT strategy. EA governance is NOT the same as IT project governance or IT service management.
Where it stops · what it isn't
- —EA IS the discipline of documenting and governing the alignment between business capabilities and technology systems across all five architecture domains (business, application, data, technology, security).
- —EA governance IS the set of decision rights, approval processes, standards bodies, and oversight mechanisms that control architectural choices — not day-to-day IT operations or project management.
- —EA IS NOT a purely technical exercise: business strategy, risk appetite, compliance requirements, and organizational dynamics are inputs of equal weight to technical feasibility.
- —EA governance IS NOT a one-size-fits-all process: governance structures must be tailored to organizational size, maturity, regulatory environment, and culture.
- —EA frameworks (TOGAF, Zachman, DoDAF) ARE structured methodologies for producing and maintaining architecture artifacts — they are tools, not outcomes. Adopting a framework does not equal having EA governance.
- —EA IS NOT synonymous with IT infrastructure management: infrastructure is one domain (technology architecture) within the broader EA scope.
- —Shadow IT and unreviewed point solutions ARE evidence of EA governance failure, not alternative architecture approaches.
Connected concepts in the graph
Every cubelet sits in a knowledge graph. Here's what this one connects to.
PART OFIT GovernanceISACA CISA Domain 2: Governance and Management of IT
REQUIRESEnterprise Risk Management (ERM)IT Strategy
ENABLESIT Policies and StandardsData GovernanceIT Vendor ManagementIT Resource Management
RELATED TOIT Control Frameworks (COBIT, NIST CSF)
CONSTRAINSIT Project Portfolio ManagementCloud Adoption and Migration Decisions