TOGAF Enterprise Architecture key terms

A description of how an enterprise's business, data, applications and technology fit together, together with the principles and roadmap that guide their coordinated change toward agreed business goals.

An open, vendor-neutral framework published by The Open Group that supplies a method, content guidance and common vocabulary for developing, governing and using enterprise architecture.

The core iterative process of the TOGAF standard, comprising phases from preliminary work and Architecture Vision through business, information systems and technology architecture, migration planning, implementation governance and change management.

The ADM phase before the main cycle in which the architecture capability is set up, covering scope, principles, governance, team, tools, tailoring and the architecture repository.

The ADM phase that defines the scope and constraints of an architecture initiative, identifies stakeholders and their concerns, and produces a high-level aspirational view plus approval to proceed.

A document from the sponsoring organization that triggers an architecture project, stating business goals, scope, constraints, budget and the deliverables the architecture team is expected to produce.

The agreed contract between the architecture function and the sponsor that defines scope, approach, plan, deliverables and acceptance criteria for a specific architecture engagement.

The continuous ADM activity that captures, stores and feeds requirements into every phase, and assesses change requests so the architecture remains aligned with business needs.

A formally described intermediate state of the enterprise between baseline and target, defined so value can be delivered incrementally while the end state is still being built.

The architecture domain describing business strategy, governance, organization and key business processes, showing how the enterprise creates value and which capabilities it needs.

The architecture domain covering data and applications: the structure of logical and physical data assets, and the applications that process them and how they interact.

The architecture domain describing the logical and physical technology infrastructure, including platforms, hardware, networks and middleware, required to support data, applications and business services.

A reusable architecture-level component that captures a required capability, defined mainly by its functionality and interfaces, and typically realized later by one or more solution building blocks.

A concrete implementation-level component, such as a purchased product, configured system or custom build, that realizes one or more architecture building blocks in a delivered solution.

The TOGAF structure that organizes architecture work products into a metamodel, a set of deliverables and a repository, giving a consistent way to describe, store and reuse architecture.

A structured store holding architecture models, building blocks, standards, reference material, landscape descriptions and governance records, supporting reuse and consistency across architecture projects.

The collection of architectures held at different levels of detail and stability, such as strategic, segment and capability architectures, describing the current state and planned changes across the enterprise.

The central deliverable that describes baseline and target architectures for the relevant domains, including building blocks, views, gaps, decisions and the rationale behind them.

A deliverable containing the measurable functional, non-functional, interoperability and constraint requirements that the target architecture and implementing projects must satisfy.

A deliverable listing the work packages needed to move from baseline to target architecture, sequenced over time and mapped to transition architectures and expected business value.

The deliverable setting out how projects, work packages and resources will deliver the transition and target architectures, including schedule, dependencies and migration steps.

An organized inventory of the standards and specifications that apply to the architecture, with their lifecycle status and scope, used to define targets and check compliance.

A technique that compares baseline and target architectures item by item to identify what is missing, added, changed or removed, producing the work needed to close the difference.

Short, memorable statements of intent that guide architecture decisions and standards, ideally derived from business principles and expressed with rationale and implications.

A person or group with an interest in or influence over the architecture, such as sponsors, business owners, architects, developers and operations staff, whose concerns must be understood and addressed.

A specification of the conventions for building and using a particular kind of architecture view, chosen so that it addresses the concerns of one or more stakeholders.

A matter of interest or importance to one or more stakeholders that motivates architecture work, such as cost, compliance, performance, risk or time to market.

A planning technique that organizes investment and change around the business capabilities the enterprise needs, linking strategy, architecture and delivery to capability increments.

A technique for rating how ready and willing an organization is to accept a proposed change, so that transformation risks and actions can be built into the migration plan.

A technique that divides the architecture into coherent, loosely coupled parts along dimensions such as business capability, organization or time, so each part can be owned and evolved separately.

Deliberate repetition of ADM phases or whole cycles at different scopes and levels of detail, such as enterprise, segment, capability or project, so architecture evolves in controlled increments.

Doing just enough architecture continuously in short cycles and collaborating closely with delivery teams, so the architecture emerges and is validated rather than fixed entirely up front.

The practices for directing, monitoring and controlling architecture work so decisions follow agreed principles, standards and processes, and outcomes stay aligned with business objectives.

A cross-organizational body of senior stakeholders that reviews and approves architecture decisions, resolves conflicts and enforces adherence to principles, standards and contracts.

A joint agreement between the architecture function and a delivery organization stating what the architecture requires, what the sponsor commits to, and how compliance will be verified.

A structured review that checks a project or architecture against agreed principles, standards and contracts, recording findings so deviations can be accepted, remediated or escalated.

The enterprise's ability to perform architecture work effectively, built from roles, skills, processes, governance, tools, information and funding, and improved over time.

A tool that assesses how capable and embedded the architecture practice is, usually through staged levels from ad hoc to optimized, to guide improvement planning.

A reference of architecture roles with their required skills and proficiency levels, used to define job families, plan training and assess team competency.