Architecture Glossary - Adrian Ashdown

Plain-English definitions of the architecture terms used across this site.

Definitions are written to be practical rather than formal. For the precise wording of a standard, see its official source, such as The Open Group for TOGAF and ArchiMate. For longer explanations, see the Architecture Library.

Jump to: A · B · D · E · G · L · M · N · O · P · R · S · T · V · W

A

Application component

A self-contained part of a software system that provides a set of related functions, such as a booking system, an accounts package or an API. In ArchiMate, it is the main building block of the application layer.

See also: Layers (ArchiMate)

ArchiMate

An open modelling language, published by The Open Group, for describing enterprise architectures. It provides a standard set of elements and relationships across the business, application and technology layers, plus elements for motivation, strategy, and implementation and migration.

See also: Layers (ArchiMate) · View and viewpoint

Architecture decision record (ADR)

A short document that records one significant architecture decision: the context, the options considered, the decision made and its consequences. Over time, ADRs build up into a log that explains why a system is the way it is.

Architecture Development Method (ADM)

The core of TOGAF: a cycle of phases for developing and managing an architecture, from an initial vision, through business, information systems and technology architecture, to migration planning, implementation governance and change management. Requirements management sits at the centre of the cycle. The ADM is designed to be tailored to the problem in hand.

See also: TOGAF · Phase (TOGAF ADM)

Architecture governance

The practices that keep implementation in line with the agreed architecture, such as reviews, decision records, standards and clear ownership of decisions. Proportionate governance can be as light as a regular review and a decision log.

Architecture principle

A general rule that guides architecture decisions, usually stated with its rationale and implications. For example: “buy commodity capabilities, build differentiating ones”. Principles make decisions more consistent and easier to explain.

Architecture vision

A short, high-level description of the intended outcome of an architecture effort and why it matters. In TOGAF, it is produced in Phase A to agree scope and gain support before detailed work begins.

B

Baseline architecture

The architecture as it is today, sometimes called the “as-is” or current state. It is the starting point for gap analysis and migration planning.

See also: Target architecture · Gap analysis

Big-bang migration

Replacing a system in a single cut-over, switching everything from old to new at once. It is simple to describe but high-risk, because problems surface all at once and rolling back is difficult.

Build vs. buy

The decision whether to develop a capability in-house or use an existing product or service. It is often best made capability by capability, rather than once for a whole system.

See also: Business capability

Business capability

Something a business is able to do, such as “take orders” or “plan deliveries”, described independently of who does it or which system supports it. Capabilities give a stable way to compare the baseline and target architectures.

D

Driver

In ArchiMate, an internal or external factor that creates a need for change, such as new regulation, customer demands or unsupported technology. Drivers lead to goals.

See also: Goal

E

Enterprise architecture

Architecture at the level of the whole organisation: how business strategy, processes, information, applications and technology fit together and change over time. TOGAF and ArchiMate are both enterprise architecture standards.

See also: Solution architecture

G

Gap analysis

Comparing the baseline and target architectures to identify what needs to be added, changed or removed. The gaps become the basis for work packages and the migration plan.

Goal

In ArchiMate, a high-level statement of intent or a desired end state, such as “all platforms in support”. Goals are usually prompted by drivers, and guide the requirements and principles that follow.

See also: Driver

L

Layers (ArchiMate)

ArchiMate’s core is organised into three layers: business (people, roles and processes), application (software and data) and technology (infrastructure and platforms). Each layer serves the one above it, which is how diagrams show the dependencies between them.

See also: ArchiMate

Legacy system

An older system that remains important to the business but is increasingly hard to change, support or connect to anything new. “Legacy” describes its position, not its quality: many legacy systems still do their job well.

See also: Strangler fig pattern

M

Migration planning

Working out how to move from the baseline to the target: the order of change, the transition architectures along the way, dependencies, risks and timing. In TOGAF, this is Phase F.

See also: Transition architecture · Work package

N

Non-functional requirement (NFR)

A requirement about how well a system must work, rather than what it does, such as availability, performance, security or scalability.

O

Opportunities and solutions

TOGAF Phase E, where the options for closing the gaps are identified and compared, including build vs. buy, and grouped into work packages and possible transition architectures.

See also: Gap analysis · Build vs. buy

P

Phase (TOGAF ADM)

One stage of the ADM: Preliminary; A – Architecture Vision; B – Business Architecture; C – Information Systems Architectures; D – Technology Architecture; E – Opportunities and Solutions; F – Migration Planning; G – Implementation Governance; and H – Architecture Change Management. Requirements Management runs throughout. In practice, the depth given to each phase depends on the problem.

Plateau

In ArchiMate, a relatively stable state of the architecture that exists for a period of time. The baseline, any transition architectures and the target can all be shown as plateaus.

See also: Transition architecture

R

Recovery point objective (RPO)

The maximum amount of data, measured in time, that the business can accept losing after an incident. An RPO of one hour means the system must be recoverable to a point no more than an hour before the failure.

See also: Recovery time objective

Recovery time objective (RTO)

The maximum length of time the business can accept a system being unavailable before it is restored.

Requirements management

In TOGAF, the continuous process at the centre of the ADM that captures, prioritises and tracks requirements as they emerge and change during every phase.

S

Single source of truth

Giving each key record, such as a customer, order or price, one authoritative home, so that systems and reports agree instead of holding conflicting copies.

Solution architecture

Architecture focused on a specific problem, system or change, bridging business needs and technical design. It is narrower in scope than enterprise architecture and closer to delivery.

See also: Enterprise architecture

Stakeholder

Anyone with an interest in, or concerns about, the architecture: owners, users, customers, suppliers, regulators, or the teams who build and run the systems. Architecture views are chosen to address stakeholders’ concerns.

See also: View and viewpoint

Strangler fig pattern

An approach to replacing a system gradually. New functionality is built around the old system, usually behind a shared interface, and parts are moved across one at a time until the old system can be retired. The name, coined by Martin Fowler, comes from a fig that grows around its host tree.

T

Target architecture

The intended future state of the architecture, sometimes called the “to-be”. It describes where the change is heading, at whatever level of detail the decisions need.

See also: Baseline architecture

Technical debt

The future cost created by shortcuts, workarounds and deferred maintenance. Like financial debt, it is sometimes worth taking on deliberately, but it accumulates “interest” in the form of slower, riskier change.

TOGAF

An enterprise architecture standard published by The Open Group. It provides a method (the ADM), guidance and a common vocabulary for developing and governing architectures, and is intended to be adapted to each organisation.

Transition architecture

An intermediate state between the baseline and the target that is stable enough for the business to operate in. Planning change as a series of transition architectures delivers value earlier and creates natural points to review, adjust or pause.

See also: Plateau · Migration planning

V

View and viewpoint

A view is a representation of the architecture, often a diagram, aimed at the concerns of particular stakeholders. A viewpoint defines the conventions for creating that kind of view: which elements, relationships and notation to use.

See also: Stakeholder

W

Work package

In ArchiMate, a set of actions with a defined goal and timescale: a unit of planned change, such as a project or a stage of one. Work packages realise the move from one plateau to the next.

See also: Plateau · Migration planning

Last reviewed: November 2026

TOGAF® and ArchiMate® are registered trademarks of The Open Group.