foundations
Enterprise Architecture Foundations
Essential concepts, principles, and practices that form the foundation of enterprise architecture practice.
Enterprise Architecture Foundations
TL;DR
Enterprise Architecture (EA) provides a holistic view of an organization's business, information, applications, and technology to enable strategic decision-making and effective change. Good EA connects business strategy to technology execution, ensuring IT investments deliver business value.
Key Takeaways
- EA is about alignment: Connecting business strategy to technology implementation
- Four domains: Business, Data, Application, Technology—all interconnected
- Value through decisions: EA delivers value when it influences decisions
- Governance enables change: Without governance, architecture is just documentation
- Iterate continuously: EA is a practice, not a one-time project
Why This Matters
Organizations waste billions on technology investments that don't deliver business value. Systems proliferate without coordination, creating redundancy, integration nightmares, and technical debt. Business and IT speak different languages, leading to solutions that miss the mark. Enterprise architecture addresses these problems by providing a structured approach to understanding, planning, and governing technology investments in support of business objectives.
The Business Case
Gartner research shows that organizations with mature EA practices deliver projects 20% faster, reduce IT costs by 15-20%, and improve time-to-market for new capabilities.
What is Enterprise Architecture?
Definition
ENTERPRISE ARCHITECTURE DEFINED
Enterprise Architecture is:
"A coherent whole of principles, methods, and models
that are used in the design and realization of an
enterprise's organizational structure, business
processes, information systems, and infrastructure."
— Marc Lankhorst
SIMPLIFIED:
EA = Strategic planning for technology
that connects to business outcomes
EA Scope
ENTERPRISE ARCHITECTURE SCOPE
BUSINESS
STRATEGY
│
▼
┌─────────────────────────────────────────────────────────────┐
│ ENTERPRISE ARCHITECTURE │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ BUSINESS │ │ DATA │ │ APPLICATION │ │
│ │ARCHITECTURE │ │ARCHITECTURE │ │ARCHITECTURE │ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │ │
│ └────────────────┼────────────────┘ │
│ │ │
│ ┌───────▼───────┐ │
│ │ TECHNOLOGY │ │
│ │ ARCHITECTURE │ │
│ └───────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
│
▼
IMPLEMENTATION
(Projects)
The Four Architecture Domains
What It Is
Business Architecture defines the business strategy, governance, organization, and key business processes.
Key Components
BUSINESS ARCHITECTURE COMPONENTS
CAPABILITIES
├── What the business does (not how)
├── Stable over time
├── Example: "Order Management", "Customer Service"
VALUE STREAMS
├── End-to-end value delivery
├── Cross-functional
├── Example: "Quote to Cash", "Hire to Retire"
ORGANIZATION
├── Structure and roles
├── Decision rights
├── Reporting relationships
PROCESSES
├── How work gets done
├── Activities, tasks, flows
├── Example: "Process Customer Order"
INFORMATION
├── Business-critical data concepts
├── Data ownership
├── Example: "Customer", "Product", "Order"
Why It Matters
Business architecture ensures technology investments align with business capabilities and priorities. Without it, IT builds systems that may work technically but miss business needs.
Architecture Levels
ARCHITECTURE ABSTRACTION LEVELS
┌─────────────────────────────────────────────────────────────┐
│ ENTERPRISE ARCHITECTURE │
│ • Cross-organization scope │
│ • Strategic, multi-year view │
│ • Principles, standards, roadmaps │
│ • Owner: Enterprise Architect │
├─────────────────────────────────────────────────────────────┤
│ DOMAIN ARCHITECTURE │
│ • Specific domain (data, security, integration) │
│ • Patterns and standards within domain │
│ • Reference architectures │
│ • Owner: Domain Architect │
├─────────────────────────────────────────────────────────────┤
│ SOLUTION ARCHITECTURE │
│ • Individual system or project │
│ • Detailed design decisions │
│ • Technology selection │
│ • Owner: Solution Architect │
├─────────────────────────────────────────────────────────────┤
│ SOFTWARE ARCHITECTURE │
│ • Internal application structure │
│ • Component design, patterns │
│ • Code organization │
│ • Owner: Software Architect / Tech Lead │
└─────────────────────────────────────────────────────────────┘
EA Value Proposition
Value Drivers
| Value Area | How EA Contributes |
|---|---|
| Cost Reduction | Eliminate redundancy, optimize portfolio, enable reuse |
| Risk Management | Identify dependencies, ensure compliance, guide security |
| Agility | Standard platforms, clear integration patterns, modular design |
| Quality | Architecture standards, technical debt management, design reviews |
| Alignment | Connect business strategy to technology investment |
| Decision Support | Provide analysis, options, and recommendations |
When EA Fails
EA FAILURE MODES
IVORY TOWER
├── Architects disconnected from delivery
├── Beautiful diagrams nobody uses
├── Recommendations ignored
└── Fix: Embed architects in teams
ANALYSIS PARALYSIS
├── Over-documentation
├── Delayed decisions
├── Perfect as enemy of good
└── Fix: Time-box analysis, bias to action
POLICE STATE
├── EA as "Department of No"
├── Blocked projects, frustrated teams
├── Workarounds and shadow IT
└── Fix: Enable, don't just govern
SHELF-WARE
├── Expensive frameworks nobody uses
├── Artifacts created but not maintained
├── No connection to decisions
└── Fix: Focus on decisions, not documents
EA Principles
Fundamental Principles
CORE EA PRINCIPLES
1. BUSINESS-DRIVEN
Architecture decisions serve business objectives,
not technology for technology's sake.
2. SIMPLICITY
Prefer simple solutions. Complexity has ongoing costs
in understanding, maintenance, and change.
3. REUSE BEFORE BUY BEFORE BUILD
Leverage existing assets, then commercial products,
then custom development.
4. DATA AS AN ASSET
Treat data with the same rigor as financial assets.
Single source of truth, governed access.
5. SECURITY BY DESIGN
Build security in from the start, not as an afterthought.
Defense in depth, least privilege.
6. INTEROPERABILITY
Design for integration. Standard interfaces, open formats,
avoid vendor lock-in where practical.
7. MANAGE TECHNICAL DEBT
Acknowledge and track technical debt. Budget for
remediation. Don't let it compound.
Principle Application
| Principle | Project Decision Example |
|---|---|
| Business-Driven | Choose solution that best supports business capability, not most technically elegant |
| Simplicity | Select proven technology over cutting-edge when requirements allow |
| Reuse | Check for existing services before building new |
| Data as Asset | Define data ownership and quality standards |
| Security by Design | Include security requirements in initial design |
| Interoperability | Use standard APIs, avoid proprietary formats |
| Manage Tech Debt | Document debt, include remediation in roadmap |
EA Governance
Governance Structure
EA GOVERNANCE MODEL
┌─────────────────────────────────────────────────────────────┐
│ ARCHITECTURE BOARD │
│ • Senior business and IT leaders │
│ • Approve major architecture decisions │
│ • Resolve escalations │
│ • Quarterly or monthly meetings │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ ARCHITECTURE REVIEW BOARD │
│ • Senior architects and technical leads │
│ • Review solution architectures │
│ • Ensure standards compliance │
│ • Weekly or bi-weekly meetings │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ PROJECT ARCHITECTURE REVIEWS │
│ • Solution architect and project team │
│ • Design reviews at key milestones │
│ • Document decisions and deviations │
│ • As needed during project lifecycle │
└─────────────────────────────────────────────────────────────┘
Review Points
| Project Phase | Review Focus |
|---|---|
| Initiation | Alignment with EA principles, major risks |
| Design | Solution architecture, standards compliance |
| Build | Implementation conformance, technical debt |
| Deploy | Operational readiness, security |
| Post-Implementation | Lessons learned, architecture updates |
EA Maturity
Maturity Levels
EA MATURITY MODEL
LEVEL 1: INITIAL
├── No formal EA practice
├── Ad-hoc, reactive decisions
├── Siloed technology choices
└── Tribal knowledge
LEVEL 2: DEVELOPING
├── EA function established
├── Basic documentation exists
├── Some standards defined
└── Limited governance
LEVEL 3: DEFINED
├── Formal EA methodology
├── Documented standards and principles
├── Regular architecture reviews
└── EA repository in place
LEVEL 4: MANAGED
├── Metrics-driven EA
├── Strong business alignment
├── Continuous improvement
└── EA informs investment decisions
LEVEL 5: OPTIMIZING
├── EA drives business strategy
├── Innovation enablement
├── Industry-leading practices
└── Full business-IT integration
Progression Path
| From Level | To Level | Key Actions |
|---|---|---|
| 1 → 2 | Establish EA function, document current state | |
| 2 → 3 | Define standards, implement governance | |
| 3 → 4 | Measure EA value, improve business alignment | |
| 4 → 5 | EA as strategic capability, innovation focus |
Getting Started with EA
First 90 Days
EA QUICK START (90 Days)
DAYS 1-30: UNDERSTAND
├── Map key stakeholders
├── Understand business strategy
├── Inventory major systems
├── Identify pain points
└── Establish relationships
DAYS 31-60: ESTABLISH
├── Draft initial principles
├── Define standards baseline
├── Set up governance (light)
├── Create repository structure
└── Identify quick wins
DAYS 61-90: DELIVER
├── Complete current state assessment
├── Identify target state opportunities
├── Deliver first architecture recommendation
├── Demonstrate early value
└── Build momentum
Quick Reference Card
┌─────────────────────────────────────────────────────────────┐
│ EA FOUNDATIONS CHEAT SHEET │
├─────────────────────────────────────────────────────────────┤
│ │
│ FOUR DOMAINS │
│ ───────────────────────────────────────────────────────── │
│ Business → Strategy, capabilities, processes │
│ Data → Data assets and management │
│ Application → Systems and integrations │
│ Technology → Infrastructure and platforms │
│ │
│ EA LEVELS │
│ ───────────────────────────────────────────────────────── │
│ Enterprise → Organization-wide, strategic │
│ Domain → Specific area (data, security) │
│ Solution → Individual system/project │
│ Software → Internal application design │
│ │
│ CORE PRINCIPLES │
│ ───────────────────────────────────────────────────────── │
│ • Business-driven (not technology for technology) │
│ • Simplicity (complexity has ongoing costs) │
│ • Reuse before buy before build │
│ • Data as an asset │
│ • Security by design │
│ • Manage technical debt explicitly │
│ │
│ VALUE DELIVERED │
│ ───────────────────────────────────────────────────────── │
│ • Cost reduction (eliminate redundancy) │
│ • Risk management (dependencies, compliance) │
│ • Agility (standard platforms, clear patterns) │
│ • Alignment (strategy to implementation) │
│ │
│ SUCCESS FACTORS │
│ ───────────────────────────────────────────────────────── │
│ • Executive sponsorship │
│ • Business engagement (not just IT) │
│ • Focus on decisions, not documents │
│ • Governance that enables, not blocks │
│ • Continuous iteration │
│ │
└─────────────────────────────────────────────────────────────┘
Decision Trees
Framework Selection
Loading diagram...
Architecture Pattern Selection
Loading diagram...
Related Topics
- What is Enterprise Architecture? - Deep dive on EA fundamentals
- TOGAF - Leading EA framework
- C4 Model - Architecture visualization
- Consulting Toolkit - EA delivery practices
Sources
- TOGAF Standard - The Open Group
- Gartner EA Research
- McKinsey EA Practices
- Enterprise Architecture as Strategy - Ross, Weill, Robertson