Module 2: Overview of Enterprise Architecture Frameworks

Enterprise Architecture Framework

A formal structure listing the key elements and factors used in enterprise architecture.

Framework (General Definition)

A structure that guides or supports the creation of something useful.

Framework in Computer Systems

A layered structure showing what programs can be built and how they interact.

Vertical Model of Framework

Represents hierarchy where the top layer shows abstract ideas (concepts, strategies) and the bottom shows real infrastructure (hardware, components).

Purpose of Enterprise Architecture Framework

Documents architecture-centric concepts to align IT systems with business goals.

Skeleton / Structure

Serves as an outline or foundation when practicing enterprise architecture.

Classification of Schema / Ontology

Schema groups EA components by their characteristics, while ontology defines relationships among EA concepts.

Thinking Tool

Helps visualize, plan, and design the future configuration of enterprise architecture.

Management Tool

Guides the transition from the current state to the target state, ensuring business-aligned growth and evolution.

Mnemonic: S.C.T.M.

“Smart Cats Think Methodically” representing Skeleton, Classification, Thinking, Management.

IEEE 1471:2000 Standard

Originated from civil architecture, forming the foundation for software-intensive and composite systems.

Adoption of IEEE 1471

Widely applied in modern EA frameworks for defining consistent structures and standards.

Conceptual Model

Collects different views (Business, Service, System) under the System Architecture.

Domain-Specific Framework

Created by defining stakeholder viewpoints and setting conformance rules for architecture alignment.

Conceptual Map

Illustrates relationships between major enterprise architecture concepts and viewpoints.

EA Framework

A structured guide organizing how people, processes, and technology connect to strategically plan and evolve the enterprise.

Zachman Framework

A structured framework developed by John Zachman (IBM, 1980s) inspired by construction and airplane design principles.

Origin of Zachman Framework

Created to apply architectural thinking to information systems by drawing parallels with physical architecture.

Roles in Design Process

Defines perspectives of Owner, Designer, and Builder to structure enterprise understanding.

Owner Role

Focuses on business requirements and enterprise needs.

Designer Role

Creates models and architectural design diagrams.

Builder Role

Translates design plans into actual technology systems and implementations.

Abstractions / Perspectives

Six core questions used to view the enterprise: What, How, Where, Who, When, and Why.

What Perspective

Focuses on materials or data such as data models and bills of materials.

How Perspective

Refers to processes or functions like workflows and functional specifications.

Where Perspective

Deals with location, such as network diagrams and system layouts.

Who Perspective

Defines people, roles, and responsibilities in the organization.

When Perspective

Refers to timing and scheduling of processes or events.

Why Perspective

Focuses on motivations, goals, and business strategies.

Mnemonic: W-H-W³

“Who, What, Where, When, Why, How” — the six essential questions of the Zachman Framework.

Zachman Framework Matrix

Composed of 5 rows (Planner, Owner, Designer, Builder, Subcontractor) and 6 columns (What, How, Where, Who, When, Why).

Sixth Row

Represents the Functioning Enterprise or actual operations.

Purpose of the Zachman Matrix

Provides a complete view of the enterprise through roles and interrogative questions.

Advantages of the Zachman Framework

Simple, holistic, tool-independent, and helps identify where issues belong in the organization.

Drawbacks of the Zachman Framework

Too many cells make it complex, lacks strong relationships between cells, and provides no clear step-by-step process.

Limitation of Zachman

Does not evaluate or justify future architecture needs.

Zachman Framework

Offers a universal language and grid structure for understanding an organization but lacks procedural guidance.

TOGAF (The Open Group Architecture Framework)

A widely used framework developed in 1995 by The Open Group, based on TAFIM, for creating business-aligned enterprise architectures.

History of TOGAF

Originated from the U.S. Department of Defense’s TAFIM and later expanded by The Open Group for commercial use.

Purpose of TOGAF

Provides methods and tools to build consistent, open, and business-aligned architectures.

Architecture Capability Framework

Defines the organization, roles, processes, and skills required for practicing enterprise architecture.

Architecture Development Method (ADM)

The core of TOGAF; a detailed, step-by-step process for developing and managing enterprise architecture.

Architecture Content Framework

Provides a metamodel, artifacts, and deliverables used in architecture design and documentation.

Enterprise Continuum & Tools

Defines taxonomies and repositories for organizing and storing architecture outputs.

Mnemonic: C-D-C-T

“Cats Don’t Catch Trees” representing Capability, Development, Content, and Tools.

Benefits of TOGAF

Supports mission-critical architecture design and promotes interoperability and efficiency.

Boundary-less Information Flow

Enables seamless information exchange between enterprises through open systems.

Open System Implementation

Reduces risk and vendor dependency by promoting standardized approaches.

Consistency and Alignment

Ensures all stakeholders share a unified architectural vision and best practices.

TOGAF vs. Zachman

TOGAF provides a structured, procedural guide for developing and managing EA, while Zachman offers a descriptive, conceptual framework.

TOGAF Summary

A methodological framework for developing, managing, and evolving enterprise architecture through structured steps and best practices.

Type Comparison

Zachman is descriptive (taxonomy-based), while TOGAF is prescriptive (methodology-based).

Focus Comparison

Zachman focuses on structure and perspectives; TOGAF focuses on process and execution.

Main Strength Comparison

Zachman offers a holistic enterprise view; TOGAF provides practical guidance and clear steps.

Drawback Comparison

Zachman is complex with no process; TOGAF requires expertise to apply effectively.

Best Use Comparison

Zachman is best for understanding enterprise perspectives; TOGAF is best for building and managing enterprise architecture.

Enterprise Architecture (EA)

A structured approach that aligns IT systems with business goals.

Framework

A structured guide or support system used to organize and build enterprise architecture.

Ontology

A formal representation of relationships among EA concepts.

TAFIM

Technical Architecture Framework for Information Management; the foundation of TOGAF.

ADM (Architecture Development Method)

TOGAF’s core process that provides a step-by-step approach for developing and managing EA.

EA Frameworks Core Idea

Organize how IT and business connect to ensure scalability, alignment, and strategic direction.

Zachman vs. TOGAF

Zachman = Map of perspectives; TOGAF = Step-by-step guide for implementation.

Choosing a Framework

Use Zachman for conceptual understanding and TOGAF for practical application and execution.

IEEE 1471:2000 Standard

Establishes guidelines for architecture views and viewpoints, influencing modern EA frameworks.

Real-World Example: Banking

Banks use EA frameworks to integrate multiple branches and digital systems effectively.

Real-World Example: Airlines

Airlines use EA frameworks for synchronized booking, maintenance, and operations.

Real-World Example: Government

Government agencies apply TOGAF to standardize IT modernization projects.