What is Enterprise Architecture?

Three Definitions of EA

• Definition 1: Architecture of the Enterprise
  • Just like building a house requires building plans, floor plans, electricity plans, and plumbing plans...
  • Building a business requires:
    • Processes
    • Organizations (Employees)
    • Location
    • Data
    • Applications
    • Technology

Think of EA like a blueprint — a house needs structural, electrical, and plumbing plans; a business needs its own equivalent set of "plans" across people, data, and tech.

• Definition 2: Mapping of Present and Future States
  • EA is the plan of transition from the current state of the business to the desired future state

Like renovating a house — EA is the renovation plan that tells you how to get from your current rundown house to the dream house you want.

• Definition 3: A Management Method
  • EA aims to bridge the gap between:
    • Management decision stakeholders
    • Operational teams

EA is like a translator between the "big picture" executives and the "hands-on" teams — making sure everyone is working toward the same goal.

Simple Answer

EA = Strategic Planning that relates and aligns information technology (IT) with the business functions that it supports.

Why EA Exists — Two Problems It Addresses

• System Complexity — Organizations were spending more and more money building IT systems
• Poor Business Alignment — Organizations found it increasingly difficult to keep expensive IT systems aligned with business needs

EA Validates Across Three Levels

• Strategic Level — Confirms and validates strategies
• Operations Level — Validates requirements
• Implementation Level — Validates implementations

Common Misconception

• ❌ EA is a function of IT
• ✅ EA must get Business & IT people to design together

EA Framework

A disciplines/guidelines for defining and maintaining the architecture models, governance and transition initiatives needed to effectively co-ordinate disparate groups towards common business and IT goals.

EA Framework Pyramid (Business-Driven → Technology-Driven)

• Business (top) — drives
• Information — prescribes
• Data — supported by
• Applications — supported by
• Technical Infrastructure (bottom)

Cross-cutting concerns: Strategy, Security

Architecture Relationships

Components within Enterprise Architecture

Hierarchy

Enterprise Architecture
├── Business Architecture
├── Information Systems Architecture
│   ├── Information Architecture
│   └── Application Architecture
└── Technical Architecture
    └── Product Architecture

Architecture Levels

Like zoom levels on a map — Enterprise is the country view (low detail, big impact), Solution is the street view (high detail, specific outcomes).

EA Frameworks

• Many EA frameworks have been published:
  • Zachman Framework
  • TOGAF (The Open Group Architecture Framework)
• Each framework has its own Methods, Techniques, Tools, Strengths & Weaknesses

The Zachman Framework

Overview

• An intersection between two classical schemas:
  1. Primitive Interrogatives: What, How, When, Who, Where, Why
     • Integration of answers to these questions enables comprehensive description of complex ideas
  2. Reification (transformation of abstract → instantiation):
     • Identification → Definition → Representation → Specification → Configuration → Instantiation

Like journalism's "5 W's + H" meets a multi-level blueprint — you answer the same key questions from different perspectives/roles.

Six Perspectives (Rows)

Six Dimensions (Columns)

Overview of the Zachman Framework (Matrix)

Framework Rules

• Rule 1: Columns have no order
• Rule 2: Each column has a simple, basic model
  • Basic Model = Entities and Relationships: Entity — Relationship — Entity
• Rule 3: Basic model of each column is unique
• Rule 4: Each row represents a distinct view
• Rule 5: Each cell is unique
• Rule 6: Combining the cells in one row forms a complete description from that view

Tools for Zachman

• Visual Paradigm
• Sparx Systems
• Gartner Review: EA Tools

TOGAF (The Open Group Architecture Framework)

By the Open Group Standard

TOGAF Architecture Framework — Structure

Top Layer: Architecture Principles, Vision, and Requirements

Preliminary:

• Architecture Principles
• Business Strategy
• Technology Strategy
• Business Principles, Objectives, and Drivers
• Architecture Vision
• Stakeholders

Architecture Requirements:

• Requirements | Constraints | Assumptions | Gaps

Middle Layer: Core Architecture Domains

Bottom Layer: Architecture Realization

• Opportunities, Solutions, and Migration Planning: Capabilities, Work Packages, Architecture Contracts
• Implementation Governance: Standards, Guidelines, Specifications

ADM — Architecture Development Method

ADM provides a tested and repeatable process for developing architectures. Activities are carried out within an iterative cycle of continuous architecture definition and realization.

ADM Basic Principles

• Iterative method — over the whole process, between phases AND within phases
• Each iteration involves new decisions about:
  • Enterprise coverage
  • Level of detail
  • Time horizon
  • Architecture asset re-use (previous ADM iterations, other frameworks, system models, industry models)
• Decisions based on:
  • Competence / resource availability
  • Value accruing to the enterprise
• Every phase is validated against and validates the current requirements of the business

Like Agile sprints but for architecture — each loop through the cycle refines and confirms the design against real business needs.

ADM Phases

Preliminary Phase: Frameworks & Principles

• Prepares the organization for undertaking EA successfully
• Activities:
  • Understand business environment
  • Commitment of key stakeholders
  • Agreement on scope
  • Establish principles
  • Establish governance structure
  • Agree on methods to be adopted

Phase A: Architecture Vision

• Initiates one iteration of the architecture process
• Sets scope, constraints, expectations
• Required at the start of every architecture cycle
• Validates business context

Phase B: Business Architecture — Contents

• Organization structure
• Business goals and objectives
• Business functions
• Business Services
• Business processes
• Business roles
• Correlation of organization and functions

Phase C: Information Systems Architectures

• The fundamental organization of an IT system, embodied in:
  • Relationships to each other and the environment
  • Principles governing its design and evolution
• Shows how the IT systems meet the business goals of the enterprise

Phase D: Technology Architecture

• The fundamental organization of an IT system, embodied in:
  • Its hardware, software and communications technology
  • Their relationships to each other and the environment
  • The principles governing its design and evolution

Phase E: Opportunities and Solutions

• Identify the major implementation projects
• Decide on approach:
  • Make vs Buy vs Re-Use
  • Outsource
  • COTS (Commercial Off-The-Shelf)
  • Open Source
• Assess priorities
• Identify dependencies

Phase F: Migration Planning

• For projects identified in Phase E, perform:
  • Cost/benefit analysis
  • Risk assessment
• Produce an implementation road-map

Phase G: Implementation Governance

• Defines architecture constraints on implementation projects
• Architecture contract
• Monitors implementation work for conformance

Phase H: Architecture Change Management

• Ensures that changes to the architecture are managed in a cohesive and architected way
• Establishes and supports the Enterprise Architecture to provide flexibility to evolve rapidly in response to changes in the technology or business environment

ADM — 4 Iteration Cycles

Example Work Products per Phase

TOGAF + Zachman

• Zachman can be applied to TOGAF Phases A through D
  • Phase A (Architecture Vision) ↔ Zachman Scope/Planner perspective
  • Phase B (Business Architecture) ↔ Zachman Enterprise Model/Owner perspective
  • Phase C (Information Systems) ↔ Zachman System Model/Designer perspective
  • Phase D (Technology Architecture) ↔ Zachman Technology Model/Builder perspective

TOGAF gives you the process (what to do and when), while Zachman gives you the classification schema (how to organize what you know). Together they complement each other.

TOGAF ADM + Agile Mapping

• Architecture Backlog → fed from Architecture Vision (Phase A)
• Iteration Backlog → from Business Architecture (Phase B)
• Architecture Development Iteration → Phases B → C → D → E (showcase + retrospective)
• Defined Architecture → output of Phase E
• Solution Backlog → feeds into Solution Release Planning
• Solution → from Implementation (Phase G/H)
• New Architecture Backlog Items → fed back into Preliminary

TOGAF ADM maps cleanly onto Agile: Architecture Vision = Product Vision, ADM iterations = Sprints, Requirements Management Backlog = Product Backlog.

Further Reading

• TOGAF: http://www.opengroup.org/togaf/
• Zachman: http://www.zachmaninternational.com