TOGAF® Enterprise Architecture Foundation key terms

An open, industry-standard framework from The Open Group that supplies a method, content guidance and supporting assets for developing, governing and maintaining enterprise architecture.

A discipline that turns business strategy into effective change by describing the current and target states of an organization across business, data, application and technology, plus the roadmap between them.

The core iterative method of TOGAF, defining a cycle of phases from Preliminary through Phase H, with Requirements Management at its center, used to develop and govern an architecture.

One of four related subject areas in TOGAF - business, data, application and technology - each describing a distinct layer of the enterprise and addressed across several ADM phases.

General, enduring rules and guidelines that inform and constrain how an organization develops and uses its architecture; each is stated with a rationale and implications.

A document from the sponsoring organization that triggers an architecture project, stating business goals, scope, constraints, budget and expected deliverables, and authorizing the work to begin.

A planning approach that organizes investment around the business capabilities needed to achieve strategic outcomes, rather than around organizational units or existing systems.

The ADM phase that establishes the architecture capability, defining the tailored TOGAF framework, architecture principles, governance arrangements and supporting tools and repositories before formal projects begin.

The ADM phase that develops the Architecture Vision and high-level target, secures sponsor approval, sets scope and constraints, and produces the Statement of Architecture Work.

A high-level, aspirational description of the target architecture that communicates the business value and intent of the change to stakeholders and supports approval of the architecture work.

The agreed plan for an architecture project, defining scope, approach, deliverables, acceptance criteria, risks and schedule; produced in Phase A and approved by the sponsor.

The ADM phase that develops baseline and target Business Architecture, performs gap analysis, and identifies candidate architecture and solution building blocks that support the Architecture Vision.

The ADM phase that develops baseline and target Information Systems Architectures - data and application architecture - with gap analysis and identification of building blocks.

The ADM phase that develops baseline and target Technology Architecture covering infrastructure, platforms and standards, and performs gap analysis in support of the Architecture Vision.

The ADM phase that identifies major work packages and projects, groups them into Transition Architectures, and produces the initial Architecture Roadmap and migration options.

The ADM phase that develops the detailed Implementation and Migration Plan, sequences work packages into Transition Architectures, and confirms costs, benefits and risks with business stakeholders.

The ADM phase that provides architecture oversight of implementation projects, ensuring delivery conforms to the target architecture through architecture contracts, compliance reviews and guidance.

The ADM phase that manages change after deployment, assessing change requests, monitoring business and technology change, and deciding whether to re-enter the ADM cycle.

The continuous ADM activity that captures, classifies and tracks architecture requirements through all phases, storing them centrally so they drive and remain traceable through the architecture.

A plan listing work packages and Transition Architectures over time, showing how the enterprise moves from its baseline to its target architecture in manageable increments.

A formally described intermediate state between baseline and target architectures, defining a coherent, deliverable increment and the work packages needed to reach it.

A technique comparing baseline and target architectures to identify missing, changed or new elements; results are documented and used to derive work packages and building blocks.

A structured model defining the types of work product produced during the ADM - deliverables, artifacts and building blocks - and how they relate within the Architecture Metamodel.

A model describing the entities and relationships that make up an architecture, such as building blocks, deliverables and artifacts, giving a common structure for architecture description.

A reusable component of architecture that can be combined with others; architecture building blocks define required capability, while solution building blocks define actual implementation components.

A store for architecture assets, including the Architecture Metamodel, Architecture Capability, Architecture Landscape, Standards Information Base, Governance Log and Reference Library, supporting reuse and governance.

A classification framework comprising the Architecture and Solutions Continuums, showing how assets progress from generic foundations to organization-specific architectures and deployed solutions, enabling reuse.

The set of architectures held in the repository at different levels of abstraction and detail - strategic, segment and capability - describing the enterprise at a point in time.

The core deliverable describing baseline, target and transition architectures, including building blocks, views and gaps, produced across Phases A to D of the ADM.

A deliverable holding the functional and non-functional requirements, constraints and assumptions the architecture must satisfy, maintained through the Requirements Management process.

The practice of controlling and overseeing architecture at enterprise level through principles, policies, boards, contracts and compliance reviews, so that it meets business objectives.

A governing body of senior stakeholders responsible for reviewing and approving architecture, resolving issues, monitoring compliance and controlling change through the governance process.

The process of reviewing delivered projects against the established architecture, identifying conformity or gaps, and reporting results to the Architecture Board for action.

A formal agreement between the architecture organization and a delivery project that defines expectations, deliverables and compliance criteria the project must meet during implementation governance.

An individual, group or organization with an interest in the architecture, whose concerns must be identified and addressed in architecture views and other communication.

A representation of the architecture from the perspective of a set of stakeholder concerns, selected and structured according to a defined viewpoint.

A specification of how views are constructed and used, defining conventions, model types and notations to address a particular set of stakeholder concerns.

The organization's ability to develop and govern architecture, supported by roles, skills, processes, governance and tools, often assessed using a maturity model.