📐 CSS323 — Chapter 5: Enterprise Architecture (EA) Cheat Sheet
1. What Is Enterprise Architecture?
One-liner: EA = Strategic Planning that aligns IT with Business so both sides work toward the same goals.
EA has three complementary definitions — know all three:
Definition 1 — Architecture of the Enterprise (Blueprint Analogy)
Just like building a house needs multiple plans (structure, electricity, plumbing), a business needs:
| House Plan | Business Equivalent |
|---|---|
| Foundation/Structure | Technology Infrastructure |
| Floor plan | Processes & Organization |
| Electrical plan | Applications |
| Plumbing plan | Data |
| Location | Locations / Branches |
Definition 2 — Plan of Transition (Current → Future State)
EA is the roadmap from the current ("as-is") state to the desired ("to-be") future state.
🏠 Analogy: Renovating an old house → EA is the renovation plan that tells you step-by-step how to reach the dream house without tearing everything down at once.
Definition 3 — A Management Method (Bridge Analogy)
EA bridges the gap between:
- Management / Decision-makers (big-picture, strategic)
- Operational teams (hands-on, tactical)
🌉 EA is a translator — execs say "we need to grow internationally," and EA translates that into specific IT and process changes the dev team can act on.
2. Why Does EA Exist? (The Two Root Problems)
| Problem | Description |
|---|---|
| System Complexity | Organizations kept spending more money on IT systems, which became entangled and hard to manage |
| Poor Business Alignment | Expensive IT systems drifted away from actual business needs over time |
🍎 Apple analogy: Imagine Apple's iOS team building features the business team never asked for, while the business team makes promises the iOS team can't deliver — EA prevents this disconnect.
3. EA Validates at Three Levels
| Level | What It Validates |
|---|---|
| Strategic Level | Confirms and validates strategies |
| Operations Level | Validates requirements |
| Implementation Level | Validates implementations |
4. Common Misconception ⚠️
| ❌ Wrong | ✅ Correct |
|---|---|
| EA is purely an IT function | EA requires Business AND IT people to design together |
5. EA Framework Pyramid
A framework = disciplines/guidelines for defining and maintaining architecture models, governance, and transition initiatives so that everyone moves toward shared business & IT goals.
┌──────────────┐
│ BUSINESS │ ← Drives everything (top)
├──────────────┤
│ INFORMATION │ ← Prescribes
├──────────────┤
│ DATA │ ← Supports Information
├──────────────┤
│ APPLICATIONS │ ← Supported by Tech
├──────────────┤
│ TECHNOLOGY │ ← Foundation (bottom)
└──────────────┘
Cross-cutting concerns that span all layers: Strategy and Security
The pyramid is Business-Driven → Technology-Driven (top-to-bottom direction of control).
6. Architecture Components
| Component | What It Is | Real Example |
|---|---|---|
| Business Architecture | Business strategies, processes, functional requirements | Org chart, process flows, roles |
| Information Architecture | Physical & logical aspects of data; manages data resources | ER diagram, data dictionaries |
| Application Architecture | Developing/implementing apps to fulfill business requirements | System diagrams, API design |
| Technical Architecture | Computing services forming the tech infrastructure | Servers, networks, cloud setup |
| Product Architecture | Standards & configs for enabling technologies within Technical Arch | Approved tech stack, licensed software |
Hierarchy Tree
Enterprise Architecture
├── Business Architecture
├── Information Systems Architecture
│ ├── Information Architecture
│ └── Application Architecture
└── Technical Architecture
└── Product Architecture
7. Architecture Levels (Zoom Analogy 🗺️)
| Level | Scope | Detail | Impact | Audience |
|---|---|---|---|---|
| Enterprise Architecture | Whole Organization | 🔎 Low | Strategic Outcomes | All Stakeholders |
| Segment Architecture | Line of Business / Department | 🔎🔎 Medium | Business Outcomes | Business Owners |
| Solution Architecture | Specific Function/Process | 🔎🔎🔎 High | Operational Outcomes | Users & Developers |
🗺️ Think of Google Maps zoom levels: Enterprise = country view, Segment = city view, Solution = street view. More zoom = more detail, smaller scope.
8. Popular EA Frameworks
| Framework | Key Characteristic |
|---|---|
| Zachman Framework | Classification schema — organizes what you know into a structured matrix |
| TOGAF | Process framework — tells you what to do and when via the ADM cycle |
🔲 ZACHMAN FRAMEWORK
Overview
Zachman = intersection of two classical schemas:
- Primitive Interrogatives (the 6 questions):
What · How · Where · Who · When · Why - Reification (abstraction → reality, top-to-bottom):
Identification → Definition → Representation → Specification → Configuration → Instantiation
📰 Think of it as journalism's "5W+H" applied at 6 levels of abstraction — like answering the same 6 questions from the CEO's view, the designer's view, the developer's view, etc.
6 Perspectives (Rows) — "Who Is Looking?"
| Row | Perspective | Role | Concern |
|---|---|---|---|
| 1 | Scope | Planner | Context, positioning the product, specifying scope |
| 2 | Enterprise Model | Owner | Business deliverable and how it will be used |
| 3 | System Model | Designer | Specs ensuring product fulfills owner's expectations |
| 4 | Technology Model | Builder | Assembling and fabricating components |
| 5 | Detailed Representations | Subcontractor (Programmer) | Out-of-context components meeting builder's specs |
| 6 | Functional Representations | Operator (User) | Validates usability and performance |
6 Dimensions (Columns) — "What Are We Asking?"
| Column | Question | Description |
|---|---|---|
| Data | What? | Enterprise data understanding across all rows |
| Function | How? | Translating mission into detailed operational definitions |
| Network | Where? | Geographical distribution of enterprise activities |
| People | Who? | Who is involved in business and technology |
| Time | When? | Effects of time / events on the enterprise |
| Motivation | Why? | Business goals/strategies → specific ends and means |
Zachman Matrix (Full Grid) 🧮
Each cell = a unique artifact/deliverable. Each row is a complete view. Each column uses the same basic model
Entity — Relationship — Entity.
| DATA (What) | FUNCTION (How) | NETWORK (Where) | PEOPLE (Who) | TIME (When) | MOTIVATION (Why) | |
|---|---|---|---|---|---|---|
| Planner(Scope) | List of important business things | List of Business Processes | List of Business Locations | List of key Organizations | List of Events | List of Business Goals & Strategies |
| Owner(Enterprise Model) | Conceptual Data / Object Model | Business Process Model | Business Logistics System | Work Flow Model | Master Schedule | Business Plan |
| Designer(System Model) | Logical Data Model | System Architecture Model | Distributed Systems Architecture | Human Interface Architecture | Processing Structure | Business Rule Model |
| Builder(Technology Model) | Physical Data/Class Model | Technology Design Model | Technology Architecture | Presentation Architecture | Control Structure | Rule Design |
| Programmer(Detailed Rep.) | Data Definition | Program | Network Architecture | Security Architecture | Timing Definition | Rule Specification |
| User(Functioning Enterprise) | Usable Data | Working Function | Usable Network | Functioning Organization | Implemented Schedule | Working Strategy |
Zachman — 6 Framework Rules
| Rule | What It Says |
|---|---|
| Rule 1 | Columns have no order (no column is more important than another) |
| Rule 2 | Each column has a simple, basic model: Entity — Relationship — Entity |
| Rule 3 | The basic model of each column is unique (they are not interchangeable) |
| Rule 4 | Each row represents a distinct and complete view |
| Rule 5 | Each cell is unique (no two cells contain the same artifact) |
| Rule 6 | Combining all cells in one row = complete description from that perspective |
TOGAF + Zachman Mapping
| TOGAF Phase | Zachman Perspective |
|---|---|
| Phase A — Architecture Vision | Scope / Planner |
| Phase B — Business Architecture | Enterprise Model / Owner |
| Phase C — Information Systems | System Model / Designer |
| Phase D — Technology Architecture | Technology Model / Builder |
Key insight: TOGAF gives you the process (steps to follow), Zachman gives you the classification schema(how to organize what you know). They complement each other.
🏛️ TOGAF (The Open Group Architecture Framework)
TOGAF Structure — 3 Layers
🔼 Top Layer: Principles, Vision & Requirements
Preliminary inputs:
- Architecture Principles
- Business Strategy + Technology Strategy
- Business Principles, Objectives, Drivers
- Architecture Vision
- Stakeholders
Architecture Requirements:
- Requirements | Constraints | Assumptions | Gaps
🔷 Middle Layer: Core Architecture Domains
| Business Architecture | Information Systems Architecture | Technology Architecture |
|---|---|---|
| Motivation: Drivers, Goals, Objectives, Measures | Data: Data Entities → Logical → Physical Data Components | Platform Services |
| Organization: Org Units, Locations, Actors/Roles | Application: IS Services → Logical → Physical App Components | Logical Technology Components |
| Function: Business Services, Processes, Events, Controls, Products | Physical Technology Components |
🔽 Bottom Layer: Architecture Realization
- Opportunities, Solutions & Migration Planning: Capabilities, Work Packages, Architecture Contracts
- Implementation Governance: Standards, Guidelines, Specifications
ADM — Architecture Development Method
ADM = Tested and repeatable process for developing architectures, run as an iterative cycle of continuous architecture definition and realization.
ADM Basic Principles
- Iterative — both between phases AND within phases
- Each iteration revisits:
- Enterprise coverage scope
- Level of detail
- Time horizon
- Architecture asset re-use (from previous ADM iterations, other frameworks, industry models)
- Decisions based on: competence/resource availability + value to the enterprise
- Every phase is validated against current business requirements (bidirectional validation)
🏃 Like Agile sprints but for architecture — each loop through the cycle refines the design against real business needs. Requirements Management is at the center (like a Product Backlog).
ADM Phases — Full Detail
🔵 Preliminary Phase — Framework & Principles
Purpose: Prepare the organization to undertake EA successfully
Activities:
- Understand the business environment
- Gain commitment from key stakeholders
- Agree on scope
- Establish architecture principles
- Establish governance structure
- Agree on methods/tools to adopt
Key Artifacts: Principles Catalog, Stakeholder Map Matrix, Value Chain Diagram, Solution Concept Diagram
🅐 Phase A — Architecture Vision
Purpose: Initiate one iteration of the architecture process; set scope, constraints, and expectations
- Required at the start of every architecture cycle
- Validates business context
- Establishes the "why" before the "how"
Key Artifacts: Requirement Catalog
🅑 Phase B — Business Architecture
Purpose: Define the business strategy, governance, organization, and key business processes
Contents:
- Organization structure
- Business goals and objectives
- Business functions and services
- Business processes
- Business roles
- Correlation of organizations and functions
Key Artifacts: Org/Actor Catalog, Role Catalog, Business Service Catalog, Location Catalog, Business Capability Catalog, Value Stream Map, Business Capability Map, Organization Map, Business Footprint Diagram, Business Model Diagram, Product Lifecycle Diagram, Functional Decomposition Diagram
🅒 Phase C — Information Systems Architectures
Purpose: Describe how IT systems meet business goals
Covers fundamental organization of IT systems including:
- Relationships between systems and environment
- Principles governing design and evolution
Includes both Data Architecture and Application Architecture.
Key Artifacts: Data Entity Catalog, Application Portfolio Catalog, Conceptual Data Diagram, Interface Catalog, Logical Data Diagram, Application Communication Diagram, Data Dissemination Diagram, Application and User Location Diagram, Application Use Case Catalog
🅓 Phase D — Technology Architecture
Purpose: Describe the hardware, software, and communications technology that supports the information systems
Covers:
- Hardware, software, and communications technology
- Relationships to each other and the environment
- Principles governing design and evolution
Key Artifacts: Technology Standard Catalog, Technology Portfolio Catalog, Environments and Locations Diagram, Platform Decomposition Diagram
🅔 Phase E — Opportunities and Solutions
Purpose: Identify implementation projects and decide on delivery approach
Decisions to make:
- Make vs. Buy vs. Re-use
- Outsource
- COTS (Commercial Off-The-Shelf)
- Open Source
Also: Assess priorities, identify dependencies
Key Artifacts: Project Context Diagram, Benefit Diagram
🅕 Phase F — Migration Planning
Purpose: Turn Phase E opportunities into an actionable roadmap
Activities:
- Cost/benefit analysis for each project
- Risk assessment
- Produce Implementation Road-map (prioritized list of transition architectures)
🅖 Phase G — Implementation Governance
Purpose: Ensure implementation projects conform to the architecture
Activities:
- Define architecture constraints on implementation projects
- Produce Architecture Contract
- Monitor implementation work for conformance
🅗 Phase H — Architecture Change Management
Purpose: Manage architecture changes in a controlled, coherent way
- Provides flexibility to evolve rapidly in response to business/technology changes
- Ensures changes don't break the overall architecture coherence
- Feeds back into the next ADM cycle (continuous loop)
ADM — 4 Iteration Cycles
| Cycle | Phases |
|---|---|
| Architecture Context | Preliminary + Phase A |
| Architecture Delivery | Phase A → B → C → D → E |
| Transition Planning | Phase E → F |
| Architecture Governance | Phase G → H |
TOGAF ADM ↔ Agile Mapping
| Agile Concept | ADM Equivalent |
|---|---|
| Product Vision | Architecture Vision (Phase A) |
| Product Backlog | Architecture Backlog (from Phase A) |
| Sprint / Iteration | ADM Architecture Development Iteration (B→C→D→E) |
| Sprint Backlog | Iteration Backlog (from Phase B) |
| Sprint Review/Retro | Showcase + Retrospective (end of B→E cycle) |
| Sprint Output | Defined Architecture (Phase E output) |
| Release | Solution (from Phase G/H) |
| Continuous feedback | New Architecture Backlog Items → back to Preliminary |
TOGAF ADM is not waterfall — it's iterative by design, just at the architectural level rather than the feature level.
ADM Phase Summary Table (Quick Reference)
| Phase | Name | Key Output |
|---|---|---|
| Prelim | Framework & Principles | Principles, Governance Structure |
| A | Architecture Vision | Vision Statement, Requirement Catalog |
| B | Business Architecture | Business Capability/Service/Process models |
| C | Information Systems Architecture | Data & Application models |
| D | Technology Architecture | Tech stack, platform specs |
| E | Opportunities & Solutions | Project list, make/buy decisions |
| F | Migration Planning | Implementation Roadmap, Risk Assessment |
| G | Implementation Governance | Architecture Contract, Conformance reports |
| H | Architecture Change Management | Updated architecture, change records |
🔁 Big Picture: How Everything Connects
EA exists because of:
└─► System Complexity + Poor Business Alignment
EA is defined as:
└─► Blueprint (Def 1) + Transition Plan (Def 2) + Management Method (Def 3)
EA is structured by the Pyramid:
└─► Business → Information → Data → Applications → Technology
Two Frameworks:
├─► ZACHMAN = The WHAT (classification matrix: 6 rows × 6 columns)
└─► TOGAF = The HOW (process: ADM with 9 phases in 4 iteration cycles)
They work together:
└─► TOGAF Phases A–D map to Zachman Rows 1–4 (Planner → Builder)
Cheat sheet for CSS323 Software Engineering — Chapter 5: Enterprise Architecture Remember: EA ≠ just IT. It's Business + IT together. 🤝