TOGAF Abbreviations and Terminology Glossary

This is a comprehensive learning glossary for the TOGAF Standard, 10th Edition and the Enterprise Architecture terminology commonly encountered around it. Definitions are concise, original explanations rather than reproduced normative text.

Use the labels as follows:

• Core TOGAF — central vocabulary used by the current framework;
• Common EA — widely used Enterprise Architecture or delivery language, but not necessarily a prescribed TOGAF term;
• Certification — examination or learning-path terminology; and
• Classic TOGAF — terminology frequently found in earlier TOGAF material or reference models and still encountered in practice.

For exact normative wording, consult the official TOGAF publications catalog.

Abbreviations and acronyms

ADM phase terminology

A–Z terminology

A

Acceptance criteria — Conditions used to decide whether a deliverable, architecture, implementation, or transition has been completed acceptably. Clear criteria are observable and linked to outcomes or requirements.

Actor — A person, organization, role, or system that performs behavior or interacts with a service or process.

Agile — A family of iterative, feedback-driven approaches to developing products and services. TOGAF can work with Agile delivery when architecture is incremental, proportional, and connected to product decisions.

Application Architecture — The domain covering application services, responsibilities, interactions, interfaces, portfolio structure, and alignment to business and data needs.

Architecture — The fundamental organization of a subject and the principles guiding its evolution; in practice, also the discipline of making and governing consequential structural choices.

Architecture Board — An accountable governance body with authority over defined architecture decisions, standards, conformance, and exceptions. It need not review every design.

Architecture Building Block — A reusable, implementation-independent description of required capability or behavior. Compare with Solution Building Block.

Architecture capability — The people, roles, skills, method, governance, information, tools, and organizational relationships needed to perform useful architecture work repeatedly.

Architecture change management — The monitoring and decision process used to keep architecture relevant as strategy, operations, technology, risk, and delivery evidence change. It is the purpose of ADM Phase H.

Architecture Change Request — A controlled request to evaluate a proposed change to architecture scope, content, requirements, standards, or an approved implementation.

Architecture compliance — The degree to which an implementation follows applicable architecture requirements, principles, standards, and decisions.

Architecture compliance review — A formal or proportionate review of implementation evidence against applicable architecture requirements, principles, standards, and decisions.

Architecture Continuum — The Enterprise Continuum dimension classifying architecture assets from foundational and common-system material through industry and organization-specific architectures.

Architecture Contract — An agreement between architecture and implementation stakeholders covering responsibilities, conformance evidence, review points, exceptions, and acceptance.

Architecture debt — The accumulated cost, risk, or constraint caused by architecture compromises, outdated decisions, duplication, or deferred remediation.

Architecture decision — A choice with material consequences for enterprise structure, behavior, standards, investment, risk, or future options.

Architecture Decision Record — A compact record of a decision's context, options, choice, rationale, consequences, owner, status, and revisit triggers.

Architecture Definition Document — The integrated architecture description, normally bringing together relevant baseline, target, gaps, rationale, and views across the selected domains.

Architecture description — The collection of work products used to express an architecture for its stakeholders and purposes.

Architecture Development Method — TOGAF's configurable, iterative method for moving from architecture capability and vision through domain development, migration planning, implementation governance, and change management.

Architecture domain — A major subject area of architecture work. The four commonly used TOGAF domains are Business, Data, Application, and Technology.

Architecture framework — A conceptual structure, method, vocabulary, content approach, and supporting practices used to develop and govern architectures.

Architecture governance — The system of decision rights, criteria, controls, accountabilities, conformance, exception handling, and feedback used to direct architecture.

Architecture Landscape — The organized view of baseline, transition, and target architectures across scopes, domains, levels, and time horizons.

Architecture level — The level of detail and decision horizon at which architecture is developed. Common examples include strategic, segment, capability, portfolio, product, and solution architecture.

Architecture maturity — The degree to which an architecture capability is established, repeatable, governed, measured, integrated, and continuously improved.

Architecture model — A purposeful representation of selected architecture concepts and relationships.

Architecture partitioning — Dividing a large architecture landscape or body of work into manageable, governed parts while maintaining boundaries, dependencies, ownership, and overall coherence.

Architecture pattern — A reusable response to a recurring architecture problem, including its context, forces, solution structure, and consequences.

Architecture principle — A durable rule or guideline used to make consistent decisions. A useful principle includes a statement, rationale, and implications.

Architecture Repository — The managed storage and operating mechanism for architecture content, standards, reusable assets, governance records, and capability information.

Architecture requirements repository — The controlled store of architecture requirements, attributes, owners, status, priorities, relationships, and traceability across ADM work.

Architecture Requirements Specification — The controlled set of measurable requirements that the architecture and its implementations must satisfy.

Architecture Roadmap — A strategic, time-oriented sequence of work packages and transition architectures showing dependencies and intended outcomes.

Architecture runway — Enabling architecture capability prepared ahead of near-term product or delivery needs. This is common Agile architecture language, not a mandatory TOGAF artifact.

Architecture Vision — A concise, stakeholder-oriented explanation of the drivers, scope, high-level baseline and target, value, risks, requirements, and proposed approach.

Artifact — A representation of architecture information. TOGAF commonly groups artifacts into catalogs, matrices, and diagrams.

B

Baseline Architecture — The relevant current state used as the starting point for analysis. It should be detailed only enough to support the decision.

Boundaryless Information Flow — A vision of integrated information being available to authorized users when and where needed across organizational, system, and technology boundaries.

Building block — A potentially reusable unit of architecture or solution content. Building blocks have responsibilities, interfaces, relationships, and required qualities.

Business Architecture — The domain covering strategy, capabilities, value streams, organization, actors, services, processes, information concepts, and operating model.

Business capability — An ability the enterprise possesses or needs to achieve an outcome. A capability describes what the enterprise can do, rather than a particular organization or process for doing it.

Business capability map — A structured view of business capabilities, usually organized into stable levels and used for investment, ownership, heat mapping, or change analysis.

Business driver — An internal or external condition creating a reason for action, such as regulation, competition, cost, customer expectations, or technology obsolescence.

Business footprint diagram — An artifact relating business goals, organizational units, functions, and services to show where change has impact.

Business goal — A broad intended result that gives direction to more specific objectives and measures.

Business interaction matrix — An artifact showing interactions, dependencies, or information exchange among business actors, roles, units, or functions.

Business outcome — A meaningful result or change in business performance, behavior, risk, or stakeholder value.

Business scenario — A structured description of a business problem, environment, actors, process, desired outcomes, measures, and implied requirements.

Business service — An externally or internally visible unit of business behavior that provides value to a consumer.

Business Transformation Readiness Assessment — An assessment of factors such as sponsorship, culture, skills, capacity, funding, governance, and stakeholder commitment that affect the ability to execute change.

C

Capability — An ability to achieve an effect or outcome. Capabilities can be business, architecture, organizational, solution, or technology capabilities.

Capability Architecture — Architecture focused on developing or changing a particular capability across the business, data, application, technology, and delivery concerns needed to realize it.

Capability-Based Planning — Planning that starts with the capabilities required to achieve strategic outcomes, then coordinates increments of change across organizational boundaries.

Catalog — An artifact that lists architecture entities of one kind, such as stakeholders, requirements, capabilities, applications, standards, or risks.

Change — A controlled movement from a baseline toward a target or transition state. Change can affect architecture, implementation, organization, or the architecture capability itself.

Communications plan — A plan mapping stakeholders and concerns to messages, views, channels, timing, ownership, and feedback.

Compliance assessment — Evidence-based evaluation of whether a solution or implementation conforms to applicable architecture requirements, principles, standards, and decisions.

Compliance review — The governance activity that performs or considers a compliance assessment and determines required actions or exceptions.

Concern — An interest, issue, need, risk, or expectation important to a stakeholder. Views should be selected to address defined concerns.

Conformance — Satisfaction of specified requirements, rules, standards, or contractual expectations.

Constraint — A limitation or condition that restricts the available architecture choices. Constraints may be legal, financial, organizational, technical, contractual, or time-based.

Content framework — The structured approach used to organize architecture deliverables, artifacts, and building blocks.

Content metamodel — The definition of architecture entity types, relationships, attributes, and rules that govern architecture content.

D

Data Architecture — The domain covering data meaning, structure, ownership, quality, use, movement, lifecycle, governance, and protection.

Data entity — A concept representing information of interest to the enterprise, such as Customer, Product, Contract, or Assessment.

Data product — A managed, discoverable data asset or service with defined consumers, ownership, quality expectations, interfaces, and lifecycle.

Decision rights — Explicit authority defining who proposes, advises, decides, approves exceptions, and is accountable for each type of decision.

Deliverable — A formally reviewed work product. A deliverable may contain multiple artifacts and may be contractually specified.

Dependency — A relationship in which one outcome, decision, work package, system, or capability relies on another.

Diagram — An artifact used to communicate structure, behavior, sequence, context, or relationships visually.

Digital enterprise — An organization whose strategy, operating model, products, decisions, and interactions substantially depend on digital capabilities and information.

E

Enterprise — The organizational scope addressed by the architecture. It can be an entire company, public body, partnership, business unit, ecosystem, or another purposeful boundary.

Enterprise Architecture — The discipline that connects strategic intent and desired outcomes to coordinated change across business, data, applications, technology, and cross-cutting concerns.

Enterprise Architecture capability — Another form of architecture capability, emphasizing its enterprise-wide mandate, relationships, and operating model.

Enterprise architecture levels — Related scopes and decision horizons at which architectures are developed. Organizations commonly distinguish strategic, segment, capability, portfolio, product, and solution levels.

Enterprise Continuum — A classification mechanism for understanding architecture and solution assets from generic to organization-specific. It is not the same as a physical repository.

Exception — A formally reviewed and authorized departure from an applicable architecture requirement, principle, standard, or decision. Good exceptions have scope, rationale, risk, owner, conditions, and expiry or review date.

F

Fitness for purpose — The degree to which architecture work is sufficient, usable, timely, and appropriate for the decision and risk at hand.

Foundation Architecture — A generic architecture of broadly applicable services, functions, and standards from which more specific architectures can be developed. This is prominent in classic TOGAF continuum material.

Foundation certification — The TOGAF Enterprise Architecture learning level focused on terminology, concepts, ADM structure, foundational techniques, governance, and content knowledge.

G

Gap — A meaningful difference between baseline and target that implies change, such as something to add, remove, replace, improve, retain, or govern differently.

Gap analysis — The structured comparison of baseline and target to identify required changes, dependencies, risks, and candidate work packages.

Governance Log — The repository area for decisions, compliance results, exceptions, risks, issues, actions, and other architecture governance evidence.

I

Implementation and Migration Plan — The prioritized, resourced, and integrated plan for executing work packages, managing dependencies, and reaching transition and target states.

Implementation Factor Assessment and Deduction Matrix — A structured technique for capturing factors that affect implementation and migration, assessing their impacts, and deriving actions, risks, or plan changes.

Implementation Governance — Oversight that helps implementation realize the approved architecture through clear agreements, review points, evidence, conformance, and managed deviations. It is the focus of ADM Phase G.

Information Systems Architectures — The collective term for Data Architecture and Application Architecture in ADM Phase C.

Interoperability — The ability of people, processes, information, and systems to exchange and use services or information effectively across boundaries.

Interoperability requirement — A condition defining the organizational, semantic, information, application, or technology compatibility required between parties or systems.

Iteration — Repeating or revisiting architecture work as understanding improves. TOGAF supports iteration within phases, between phases, across ADM cycles, and at different architecture levels.

M

Matrix — An artifact showing relationships between two or more kinds of architecture content, such as capability/application or stakeholder/concern.

Measure — A defined observation used to evaluate progress, performance, risk, conformance, or outcomes.

Metamodel — A model defining the concepts, relationships, attributes, and rules used to create other models.

Migration Planning — The prioritization and sequencing of work packages using value, cost, risk, dependency, readiness, and resource evidence. It is the focus of ADM Phase F.

Model — A simplified representation of a subject created for a defined purpose and audience.

O

Objective — A specific result to be achieved in support of a broader goal, ideally with a measure and time horizon.

Opportunities & Solutions — ADM Phase E, where architecture gaps are grouped into work packages, solution options are considered, and candidate transition architectures are formed.

Organization map — An artifact showing organizational units, roles, locations, responsibilities, reporting, or other relationships relevant to the architecture.

Organization model for Enterprise Architecture — The definition of architecture scope, roles, responsibilities, governance, skills, services, and connections to the rest of the organization.

Outcome — The effect or result produced for a stakeholder, as distinct from an output such as a document, system, or completed activity.

P

Pattern — A reusable response to a recurring problem in a stated context, including the forces, structure, and trade-offs involved.

Portfolio — A managed collection of investments, products, programs, projects, services, or assets considered together for prioritization and governance.

Practitioner certification — The TOGAF Enterprise Architecture learning level focused on analyzing and applying the framework in realistic situations.

Principle — A durable rule or guideline used to make consistent decisions. Architecture principles should have explicit rationale and implications.

Product — A persistently managed offering that provides value to customers or users and evolves through an ongoing lifecycle.

Project — A temporary endeavor organized to deliver a defined change or result.

R

Reference Architecture — A reusable architecture approach for a recurring class of problem, providing structures, patterns, decisions, and guidance that must be specialized for a context.

Reference Library — The Architecture Repository area containing reusable patterns, reference architectures, templates, viewpoints, examples, and lessons.

Reference Model — An abstract, reusable model defining key concepts, functions, services, or relationships for a domain.

Requirement — A statement of what an architecture or implementation must enable, satisfy, constrain, or demonstrate.

Requirements impact assessment — Analysis of how a new or changed requirement affects scope, stakeholders, architectures, gaps, work packages, plans, risk, and governance.

Requirements Management — The continuous ADM activity for eliciting, analyzing, prioritizing, tracing, verifying, and controlling requirements while feeding impacts into every phase.

Requirements repository — The controlled store for requirements and their attributes, status, owners, priorities, relationships, decisions, and traceability.

Risk — The effect of uncertainty on objectives. Architecture risk should record likelihood, impact, exposure, treatment, owner, evidence, and review.

Risk management — The continuous identification, assessment, treatment, monitoring, and communication of uncertainty affecting architecture and transformation outcomes.

S

Scope — The boundaries of architecture work, commonly considered by breadth, depth, time period, architecture domains, organizational coverage, and subject matter.

Security Architecture — Architecture that expresses security outcomes, threats, controls, trust boundaries, identity, protection, detection, response, and recovery across all domains.

Segment Architecture — Architecture for a coherent part of an enterprise, such as a business segment, mission area, region, or major portfolio.

Service — Defined behavior or capability offered by one party or component to another through an understood interface or agreement.

Solution Architecture — The architecture of a bounded initiative or solution, connecting enterprise and domain direction to implementable choices.

Solution Building Block — A specific implementable or procured component that realizes one or more Architecture Building Blocks.

Solution concept diagram — A high-level visual summary of the major solution participants, services, interactions, and technology direction used to communicate an emerging solution concept.

Solutions Continuum — The Enterprise Continuum dimension classifying implemented solutions from generic products and services through industry-specific and organization-specific solutions.

Stakeholder — A person, group, role, or organization with an interest in or influence over the architecture and its outcomes.

Stakeholder management — The continuous identification and analysis of stakeholders, concerns, influence, decision rights, engagement, communications, and changing support.

Standard — An approved rule, specification, product choice, interface, technology, or practice that constrains or guides implementation in a defined scope.

Standards Information Base — The Architecture Repository area containing standards, approved technologies and products, versions, lifecycle status, owners, exceptions, and migration guidance.

Statement of Architecture Work — The agreement defining an architecture engagement's objectives, scope, approach, work plan, roles, governance, deliverables, acceptance criteria, assumptions, constraints, and risks.

Strategic Architecture — A high-level, longer-horizon architecture that guides major enterprise direction and provides context for more focused segment, capability, product, or solution work.

T

Tailoring — Deliberately configuring the ADM, content, techniques, governance, depth, cadence, and deliverables to suit outcomes, scope, risk, uncertainty, culture, and delivery context.

Target Architecture — The intended future state designed to satisfy agreed drivers, goals, stakeholder concerns, and requirements.

Technology Architecture — The domain covering platforms, infrastructure, networks, runtime services, middleware, technology standards, operations, and lifecycle.

TOGAF Fundamental Content — The stable core of the modular 10th Edition, including concepts, the ADM, techniques, applying the ADM, content, capability, and governance.

TOGAF Series Guide — Topic-focused guidance for configuring or applying the TOGAF framework in a particular area. Series Guides can evolve more frequently than the Fundamental Content.

Traceability — The ability to follow relationships from drivers and stakeholder concerns through goals, requirements, architecture decisions, gaps, work packages, implementation, and measured outcomes.

Trade-off analysis — A structured comparison of credible options against stakeholder concerns, criteria, constraints, uncertainty, risk, cost, value, reversibility, and consequences.

Transition Architecture — A coherent intermediate architecture state between baseline and target, useful when the target cannot be reached in one step.

V

Value — The benefit, usefulness, or importance perceived by a stakeholder relative to cost, risk, sacrifice, or alternatives.

Value stream — The end-to-end stages through which value is created and delivered to a stakeholder.

View — The actual representation of an architecture created from a viewpoint to address particular stakeholder concerns.

Viewpoint — The conventions, concerns, model kinds, and rules used to construct, interpret, and use a view.

W

Waiver — A common synonym for an approved exception. It should be governed, bounded, owned, and time-limited rather than treated as permanent silent non-conformance.

Work package — A bounded set of coordinated actions or change used to realize part of an Architecture Roadmap.

Architecture Repository areas

Deliverables and work products

Commonly confused terminology

See also

• Fast-learning mind map
• Editable draw.io mind map
• Core concepts
• Architecture Development Method
• Content, deliverables, and artifacts
• Enterprise Continuum and Architecture Repository
• Capability and governance
• Official references

This glossary is an independent learning aid. The TOGAF Standard publications catalog and TOGAF Library remain the authoritative sources for current standard material.