TOGAF Framework establishes the common language of Enterprise Architecture. TOGAF is highly structured, and precise terminology is critical for clear communication, passing the certification exam, and applying the framework correctly in real-world scenarios. This guide covers all key terms of the TOGAF framework, grouped thematically for easier learning.
| Term | Official Definition (TOGAF 9) | Beginner Explanation & Example |
|---|---|---|
| Enterprise | The highest level of description of an organization, typically covering all missions and functions. Often spans multiple organizations. | Not just a single company. It’s the entire ecosystem working toward common goals. 🔹 Example: A global airline + its catering suppliers + airport ground handlers + booking platforms. |
| Architecture | The fundamental concepts/properties of a system in its environment, embodied in its elements, relationships, and principles of design/evolution. | The “blueprint” showing how parts connect, why they’re arranged that way, and how they’ll change over time. 🔹 Example: A city’s urban plan showing roads, power grids, zoning laws, and future expansion zones. |
| Architecture Framework | A conceptual structure used to plan, develop, implement, govern, and sustain an architecture. | A toolkit that provides a method, common vocabulary, tools, and recommended standards. 🔹 Example: TOGAF, Zachman, or FEAF. Think of it as a “recipe book” for building architectures. |
| Capability | An ability that an organization, person, or system possesses. | What the business can do, regardless of how it’s currently done. 🔹 Example: “Online Order Fulfillment” or “Customer Identity Verification”. |
| Method | A defined, repeatable approach to address a particular type of problem. | A step-by-step process you follow consistently. 🔹 Example: The TOGAF ADM cycle is the core method for developing architectures. |
| Reference Model (RM) | An abstract framework for understanding significant relationships among entities of an environment, used to develop consistent standards. | A high-level, vendor-neutral blueprint used to align tools and standards. 🔹 Example: TOGAF Technical Reference Model (TRM) for platform services. |
| Term | Official Definition | Beginner Explanation & Example |
|---|---|---|
| Architecture Development Method (ADM) | The core of TOGAF. A multi-phase, iterative approach to develop and use an Enterprise Architecture to shape and govern business transformation. | The 10-step cycle (Preliminary → Requirements Management) architects follow to build an architecture. It’s iterative, not linear. |
| Architecture Principle | A qualitative statement of intent that should be met by the architecture. Enduring and seldom amended. | Guiding rules that drive decisions. 🔹 Example: “Data is an enterprise asset” or “Cloud-first deployment”. |
| Baseline Architecture | A specification formally reviewed/agreed upon, serving as the basis for further development/change. | The Current State (“As-Is”). 🔹 Example: Legacy on-premise servers running outdated ERP v5.2. |
| Target Architecture | Description of a future state of the architecture being developed. | The Desired Future State (“To-Be”). 🔹 Example: Cloud-native microservices running on AWS with AI-driven analytics. |
| Transition Architecture | Formal description of one state at an architecturally significant point in time during progression from Baseline to Target. | A stepping stone between current and future states. 🔹 Example: Year 1: Hybrid cloud migration. Year 2: Data warehouse modernization. |
| Gap | A statement of difference between two states. Used in gap analysis to identify differences between Baseline and Target. | What’s missing or needs to change. 🔹 Example: “Current system lacks mobile API; Target requires RESTful mobile endpoints.” |
| Term | Official Definition | Beginner Explanation & Example |
|---|---|---|
| Enterprise Continuum | A categorization mechanism for classifying architecture/solution artifacts as they evolve from generic Foundation to Organization-Specific Architectures. | A “virtual library” ranging from universal IT standards (left) to your company’s custom setups (right). |
| Architecture Continuum | Part of Enterprise Continuum. A repository of architectural elements with increasing detail/specialization. | How designs evolve: Foundation → Common Systems → Industry → Organization-Specific. 🔹 Example: Generic CRM design → Banking CRM design → Your Bank’s CRM design. |
| Solutions Continuum | Part of Enterprise Continuum. A repository of re-usable solutions/implementations for future efforts. | How products/code evolve to match the Architecture Continuum. 🔹 Example: Off-the-shelf CRM → Customized Salesforce → Fully tailored banking module. |
| Repository | A system that manages all data of an enterprise, including data/process models and other enterprise information. | The database/tool where all architecture artifacts, standards, and decisions are stored. 🔹 Example: Sparx EA, LeanIX, or a structured SharePoint/wiki. |
| Term | Official Definition | Beginner Explanation & Example |
|---|---|---|
| Architecture Domain | The architectural area being considered. Primary: Business, Data, Application, Technology. | The lens you’re using to view the enterprise. TOGAF covers all four. |
| Business Architecture | Representation of holistic business views: capabilities, value delivery, information, org structure, and relationships to strategies/stakeholders. | How the business operates, creates value, and organizes itself. 🔹 Example: Value stream maps, capability heatmaps, organizational charts. |
| Data Architecture | Description of structure/interaction of major data types, logical/physical data assets, and management resources. | How data is created, stored, moved, secured, and governed. 🔹 Example: Master data management strategy, data lake design, GDPR compliance rules. |
| Application Architecture | Description of structure/interaction of applications as groups of capabilities providing key business functions. | How software systems talk to each other and support business processes. 🔹 Example: Application portfolio, integration diagrams, API contracts. |
| Technology Architecture | Description of structure/interaction of technology services/components (hardware, software, networks, middleware). | The underlying IT infrastructure that runs everything. 🔹 Example: Cloud platforms, server specs, network topology, security firewalls. |
| Term | Official Definition | Beginner Explanation & Example |
|---|---|---|
| Building Block | A (potentially re-usable) component of enterprise capability that can be combined with others. Defined at various detail levels. | A modular piece of functionality or technology. 🔹 Example: “Customer Authentication Module”. |
| Architecture Building Block (ABB) | Constituent of architecture model describing a single aspect. Defines what functionality will be implemented. Captures requirements. | The specification/requirements for a capability. 🔹 Example: “Must support OAuth 2.0, handle 10k req/sec, log all attempts.” |
| Solution Building Block (SBB) | Candidate solution conforming to an ABB. Defines which products/components will implement it. | The actual implementation/product. 🔹 Example: “Okta Enterprise Identity Platform v3”. |
| Artifact | Architectural work product describing an aspect of architecture. Classified as catalogs, matrices, diagrams. | A single piece of documentation or model. 🔹 Example: A swimlane diagram, a server-to-app mapping matrix, or a requirements catalog. |
| Deliverable | Work product contractually specified, formally reviewed, agreed, and signed off by stakeholders. | A formal output that gets approved and archived. 🔹 Example: The signed “Target Architecture Document” or “Statement of Architecture Work”. |
| Term | Official Definition | Beginner Explanation & Example |
|---|---|---|
| Stakeholder | Individual, team, organization, or class having an interest in a system. | Anyone affected by or interested in the architecture. 🔹 Example: CIO, compliance officer, end-users, vendors. |
| Concern | Interest in a system relevant to one or more stakeholders. Determines acceptability. | What a stakeholder cares about. 🔹 Example: Security, cost, performance, regulatory compliance, user experience. |
| Architecture View | Representation of a system from the perspective of a related set of concerns. | What you see to address specific stakeholder concerns. 🔹 Example: A network security diagram shown to the CISO. |
| Architecture Viewpoint | Specification of conventions for a particular kind of architecture view. Defines how to construct/interpret a view. | Where you’re looking from (the template/perspective). 🔹 Example: “UML Deployment Diagram” rules used to create the security view. |
| Architecture Governance | Practice of monitoring/directing architecture-related work to deliver outcomes and adhere to principles/standards. | The oversight process ensuring projects follow the blueprint. 🔹 Example: Architecture Board reviewing designs for compliance before funding. |
| Business Governance | Ensuring business processes/policies deliver outcomes and adhere to regulations. | Corporate oversight of business operations and compliance. 🔹 Example: Ensuring all financial reporting meets SOX requirements. |
| Term | Official Definition | Beginner Explanation & Example |
|---|---|---|
| Strategic Architecture | Summary formal description providing executive-level long-term view for direction setting. | High-level roadmap for leadership. 🔹 Example: 5-year digital transformation blueprint. |
| Segment Architecture | Detailed formal description of areas within an enterprise, used at program/portfolio level to organize change. | Architecture for a specific division or region. 🔹 Example: “European Retail Division Architecture”. |
| Solution Architecture | Description of a discrete/focused business operation and how IS/IT supports it. Applies to single project/release. | Project-level architecture. 🔹 Example: Architecture for launching the new mobile banking app. |
| Metamodel | A model describing how/with what architecture will be described structurally. | Rules for how you build models. 🔹 Example: “All diagrams must use ArchiMate notation and link to business capabilities.” |
| Modeling | Technique constructing models to represent a subject for reasoning/clarity. | Creating visual/structured representations to understand complex systems. |
| Requirement | Statement of need that must be met by an architecture or work package. | What the system must do or have. 🔹 Example: “99.99% uptime, PCI-DSS compliant.” |
| Service | Repeatable activity/discrete behavior a building block performs in response to requests. | A specific function offered by a component. 🔹 Example: “User Login”, “Invoice Generation”, “Data Backup”. |
| Logical Architecture | Implementation-independent definition grouping physical entities by purpose/structure. | Abstract grouping. 🔹 Example: “Relational Database Layer” (covers Oracle, SQL Server, MySQL). |
| Physical | Description of a real-world entity. | Concrete, tangible implementation. 🔹 Example: Dell PowerEdge R740 server running Windows Server 2022. |
| Metadata | Data about data, describing characteristics of an entity. | Labels/tags that give context to information. 🔹 Example: Owner: IT Security, Classification: Confidential, Last Updated: 2025-03-10. |
| Objective | Time-bounded milestone demonstrating progress toward a goal. | Measurable target with a deadline. 🔹 Example: “Migrate 50% of workloads to cloud by Q4 2025.” |
| Course of Action | Direction/focus from strategic goals/objectives, often to deliver value proposition. | The path chosen to achieve goals. 🔹 Example: “Adopt microservices to accelerate release cycles.” |
| Value Stream | End-to-end collection of value-adding activities creating an overall result for a customer/stakeholder. | The journey from trigger to delivered value. 🔹 Example: “Order-to-Cash” process. |
| Architectural Style | Combination of distinctive features related to context, steering how architecture is formed. | A recognized design pattern or approach. 🔹 Example: SOA, Microservices, Event-Driven Architecture. |
| Information | Any communication/representation of facts, data, or opinions in any medium. | Raw or processed content. 🔹 Example: Customer records, sensor logs, financial statements. |
| Information Technology (IT) | Lifecycle management of information and related tech; umbrella term for computer industry domains. | All tech-related systems, processes, and teams. |
Start with the Enterprise → Identify Stakeholders and their Concerns.
Use an Architecture Framework (TOGAF) and its Method (ADM) to structure the work.
Define Architecture Principles to guide decisions.
Model the current (Baseline) and desired (Target) states across the Four Domains (BDAT).
Use Building Blocks: ABBs define what is needed; SBBs define which products will deliver it.
Store everything in a Repository, classified using the Enterprise Continuum (from generic Foundation to Organization-Specific).
Create Views (what stakeholders see) using Viewpoints (templates/rules).
Produce Artifacts → Package into Deliverables → Get stakeholder sign-off.
Govern the process via Architecture Governance and monitor Gaps across Transition Architectures.
ABB vs SBB: ABB = Requirements/Specification (Phase A-D). SBB = Implementation/Product (Phase E+).
View vs Viewpoint: View = Instance (what you see). Viewpoint = Template (how you create it).
Enterprise Continuum: Not a physical tool, but a classification model for assets from generic → specific.
Architecture Principle: Must be enduring, unambiguous, and include rationale + implications. Not transient.
Gap Analysis: Always compares Baseline ↔ Target. Missing items = gaps to be filled or intentionally removed.
