TOGAF EA Practitioner key terms

The enterprise-level system of decision rights, processes, and accountability that directs and controls architecture work, ensuring it is authorised, monitored, and complies with agreed standards and policies.

General, enduring rules and guidelines that inform and constrain how the enterprise designs and evolves its architecture; each is stated with a name, rationale, and implications so it can be applied to decisions.

A cross-organisational body with a formal charter that approves architecture deliverables and contracts, resolves architecture conflicts, and oversees compliance with the enterprise architecture.

A structured store of architecture assets including principles, reference models, standards, the current landscape, and governance records, giving the enterprise one authoritative place to find architecture content.

A model showing how architecture assets evolve from foundational generic models through common industry models to organisation-specific architectures, with reuse and tailoring applied at each stage.

A companion model to the architecture continuum that describes reusable solution assets, from generic products through industry solutions to deployed organisation-specific solutions, aligned to matching architecture assets.

A document issued by the sponsoring organisation that authorises an architecture project and sets its scope, budget, schedule, and constraints, triggering the start of an ADM cycle.

A high-level summary of the target architecture produced in Phase A that conveys scope, stakeholders, and expected business value in order to obtain approval and funding.

The agreed contract for an architecture project, covering scope, approach, deliverables, plan, roles, and acceptance criteria, used to manage and measure the engagement.

A technique that examines how ready and able an organisation is to absorb the change implied by a target architecture, identifying readiness factors and actions needed to improve them.

A technique that derives requirements by describing a business problem, the environment, the desired outcome, and the actors involved, then testing whether a proposed architecture delivers value.

The principal deliverable describing baseline and target architectures for the business, data, application, and technology domains, together with the reasoning behind the architectural decisions.

The description of business strategy, governance, organisation, and key business processes, connecting what the enterprise intends to achieve with how it actually operates.

A particular ability the business has or needs, described without reference to how it is delivered, used to plan investment and to structure the architecture around what the business does.

An end-to-end sequence of activities that creates value for a customer by turning inputs into outcomes, used to align capabilities and identify where value is created, delayed, or lost.

An inventory of the organisational units, roles, and actors that take part in the architecture, recording their responsibilities, relationships, and locations.

The description of an organisation's logical and physical data assets and data management resources, covering entities, relationships, and the lifecycle of data.

The description of the applications in use or planned, their interactions and interfaces, and their relationship to business processes and data.

A diagram that shows applications and the interfaces between them, indicating the direction and content of the information exchanged.

The description of the hardware, software, and network infrastructure that supports the data and application architectures, including platforms, standards, and their relationships.

An inventory of approved, emerging, and retired technology standards and products, with lifecycle status, used to govern technology selection and procurement.

A coherent set of activities that delivers part of the target architecture, defined in Phase E and sequenced in Phase F, with identified business value and dependencies.

A formally defined intermediate state of the architecture between baseline and target, delivering agreed business value during a defined period.

A Phase E matrix that brings together identified gaps, candidate solutions, and dependencies so that related items can be grouped into projects and work packages.

A timeline of work packages and transition architectures showing how the enterprise will move from baseline to target, including dependencies and expected business value.

The methods applied in Phase F, such as cost-benefit and risk assessment, business value ranking, and dependency matrices, to sequence work packages into a funded, achievable implementation plan.

A documented arrangement of roles, decision rights, and processes by which architecture compliance is monitored while projects deliver, defined in Phase F and applied in Phase G.

A joint agreement between the architecture function and a delivery team that sets out what will be built, which standards apply, and how compliance will be checked.

A structured assessment of project deliverables against the architecture and its standards, producing findings, dispensation decisions, and required corrective actions.

The phase that monitors the deployed architecture and its business environment, decides whether change is a simplification, an incremental change, or a new architecture cycle, and acts accordingly.

A recorded request to alter the architecture, which is assessed for impact and business value before a decision is made to accept, reject, or defer it.

TOGAF's core iterative process, organised into phases from Preliminary through Phase H, that guides an enterprise from architecture vision to implementation and continuing change.

A technique that compares baseline and target architectures element by element to identify items missing, added, removed, or retained, producing the gaps used to plan work.

The description of the architecture as it currently exists and operates, providing the starting point against which the target is compared.

The description of the desired future state of the architecture, developed in the relevant ADM phases to satisfy the architecture vision and requirements.

A reusable architecture-level component describing a capability, function, or service the business needs, defined independently of any particular implementation or product.

A concrete, deployable implementation component that realises one or more architecture building blocks and is specific to a product, vendor, or technology.

A deliverable that records the measurable requirements the architecture must satisfy, kept current and prioritised through requirements management across the ADM.

An analysis of how a new or changed requirement affects architecture deliverables, phases, and contracts, used to decide what work must be revisited.

The continuous ADM activity that captures, stores, and tracks changes to requirements and ensures that each relevant phase addresses them.