TOGAF® Standard — Introduction

4. Definitions

For the purposes of the TOGAF Standard, the following terms and definitions apply. B. Glossary of Supplementary Definitions should be referenced for supplementary definitions not defined in this chapter. The Merriam-Webster® Collegiate Dictionary should be referenced for terms not defined in this section or B. Glossary of Supplementary Definitions .

4.1 Abstraction

The technique of providing summarized or generalized descriptions of detailed and complex content.

Note:: Abstraction, as in "level of abstraction", can also mean providing a focus for analysis that is concerned with a consistent and common level of detail or abstraction. Abstraction in this sense is typically used in architecture to allow a consistent level of definition and understanding to be achieved in each area of the architecture in order to support effective communication and decision-making. It is especially useful when dealing with large and complex architectures as it allows relevant issues to be identified before further detail is attempted.

4.2 Actor

A person, organization, or system that has one or more roles that initiates or interacts with activities; for example, a sales representative who travels to visit customers. Actors may be internal or external to an organization.

Note:: In the automotive industry, an original equipment manufacturer would be considered an actor by an automotive dealership that interacts with its supply chain activities.

4.3 Application Architecture

A description of the structure and interaction of the applications that provide key business capabilities and manage the data assets.

Note:: Application Architecture is described in the TOGAF Standard — Architecture Development Method.

4.4 Application Component

An encapsulation of application functionality aligned to implementation structure, which is modular and replaceable. It encapsulates its behavior and data, provides services, and makes them available through interfaces.

Note:: For example, a business application such as an accounting, payroll, or CRM system.
An application component usually maintains a data component. It is enabled by technology services provided by technology components.

4.5 Application Platform

The collection of technology components of hardware and software that provide the services used to support applications.

4.6 Application Service

A discrete behavior requestable from an application; an automated element supporting or delivering part or all of one or more business services.

4.7 Architectural Style

The combination of distinctive features related to the specific context within which architecture is performed or expressed; a collection of principles and characteristics that steer or constrain how an architecture is formed.

4.8 Architecture

The fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution. (Source: ISO/IEC/IEEE 42010:2011)
The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.

4.9 Architecture Building Block (ABB)

An architectural component that specifies the required Solution Building Blocks (SBBs) at a more logical (or supplier-independent) level.

4.10 Architecture Continuum

A categorization mechanism, with increasing detail and specialization, for the components and artifacts stored in the Architecture Landscape or Reference Library (part of the Architecture Repository).

Note:: This Continuum begins with foundational definitions like reference models, core strategies, and basic building blocks. From there it spans to Industry Architectures and all the way to an Organization-Specific Architecture.

4.11 Architecture Development Method (ADM)

The core of the TOGAF framework. A multi-phase, iterative approach to develop and use an Enterprise Architecture to shape and govern business transformation.

Note:: The ADM is described in the TOGAF Standard — ADM Techniques.

4.12 Architecture Domain

The architectural area being considered. The TOGAF framework follows the tradition of dividing Enterprise Architecture into four primary architecture domains: business, data, application, and technology. Other domains (motivation, security, governance, etc.) may span those four primary domains.

4.13 Architecture Framework

A conceptual structure used to plan, develop, implement, govern, and sustain an architecture.

4.14 Architecture Governance

The practice of monitoring and directing architecture-related work. The goal is to deliver desired outcomes and adhere to relevant principles, standards, and roadmaps.

4.15 Architecture Landscape

The architectural representation of assets in use, or planned, by the enterprise at particular points in time.

4.16 Architecture Level

Levels provide a framework for dividing the Architecture Landscape into levels of granularity.

Note:: Architecture levels are distinct from architecture partitions.

4.17 Architecture Model

A representation of a subject of interest.

Note:: An architecture model provides a smaller scale, simplified, and/or abstract representation of the subject matter.

4.18 Architecture Partition

A subset of architecture resulting from dividing that architecture to facilitate its development and management.

4.19 Architecture Principle

A qualitative statement of intent that should be met by the architecture.

Note:: A sample set of Architecture Principles is defined in the TOGAF Standard — ADM Techniques.

4.20 Architecture View

A representation of a system from the perspective of a related set of concerns.

Note:: In some sections of this standard, the term "view" is used as a synonym for "architecture view".

4.21 Architecture Viewpoint

A specification of the conventions for a particular kind of architecture view.

Note:: An architecture viewpoint can also be seen as the definition or schema for that kind of architecture view. It establishes the conventions for constructing, interpreting, and using an architecture view to address a specific concern (or set of concerns) about a system-of-interest.
In some sections of this standard, the term "viewpoint" is used as a synonym for "architecture viewpoint".

4.22 Architecture Vision

A succinct description of the Target Architecture that describes its business value and the changes to the enterprise that will result from its successful deployment. It serves as an aspirational vision and a boundary for detailed architecture development.

Note:: Phase A (Architecture Vision) is described in the TOGAF Standard — Architecture Development Method.

4.23 Artifact

An architectural work product that describes an aspect of the architecture.

4.24 Baseline

A specification that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development or change and that can be changed only through formal change control procedures or a type of procedure such as configuration management.

4.25 Boundaryless Information Flow^TM

A shorthand representation of "access to integrated information to support business process improvements" representing a desired state of an enterprise's infrastructure specific to the business needs of the organization.

Note:: The need for Boundaryless Information Flow — a trademark of The Open Group — is described in the TOGAF® Series Guide: The TOGAF Integrated Information Infrastructure Reference Model (III-RM).

4.26 Building Block

A potentially re-usable component that can be combined with other building blocks to deliver architectures and solutions.

Note:: Building blocks can be defined at various levels of detail, depending on what stage of architecture development has been reached. For instance, at an early stage, a building block can simply consist of a name or an outline description. Later on, a building block may be decomposed into multiple supporting building blocks and may be accompanied by a full specification. Building blocks can relate to "architectures" or "solutions".
Building blocks are described in the TOGAF Standard — Architecture Content.

4.27 Business Architecture

A representation of holistic, multi-dimensional business views of: capabilities, end-to-end value delivery, information, and organizational structure; and the relationships among these business views and strategies, products, policies, processes, initiatives, and stakeholders.

Note:: Business Architecture relates business elements to business goals and elements of other domains.
Business Architecture is described in the TOGAF Standard — Architecture Development Method.

4.28 Business Capability

A particular ability that a business may possess or exchange to achieve a specific purpose.

4.29 Business Function

A collection of business behavior based on a chosen set of criteria, closely aligned to an organization.

4.30 Business Governance

Concerned with ensuring that the business processes and policies (and their operation) deliver the business outcomes and adhere to relevant business regulation.

4.31 Business Model

A model describing the rationale for how an enterprise creates, delivers, and captures value.

4.32 Business Service

Supports the business by encapsulating a unique "element of business behavior".

Note:: A service offered external to the enterprise may be supported by business services.

4.33 Capability

An ability that an organization, person, or system possesses.

Note:: This a general-purpose definition. See 4.28 Business Capability for how this concept is refined for usage in Business Architecture.

4.34 Capability Architecture

An architecture that describes the abilities that an enterprise possesses.

4.35 Capability Increment

A discrete portion of a capability architecture that delivers specific value. When all increments have been completed, the capability has been realized.

4.36 Communications and Stakeholder Management

The management of needs of stakeholders of the Enterprise Architecture practice. It also manages the execution of communication between the practice and the stakeholders and the practice and the consumers of its services.

Note:: Architecture stakeholder management is described in the TOGAF Standard — ADM Techniques.

4.37 Concern

An interest in a system relevant to one or more of its stakeholders.

Note:: Concerns may pertain to any aspect of the system's functioning, development, or operation, including considerations such as performance, reliability, security, distribution, and evolvability and may determine the acceptability of the system.

4.38 Course of Action

Direction and focus provided by strategic goals and objectives, often to deliver the value proposition characterized in the business model.

4.39 Data Architecture

A description of the structure of the enterprise's major types and sources of data, logical data assets, physical data assets, and data management resources.

Note:: Data Architecture is described in the TOGAF Standard — Architecture Development Method.

4.40 Deliverable

An architectural work product that is contractually specified and in turn formally reviewed, agreed, and signed off by the stakeholders.

Note:: Deliverables represent the output of projects and those deliverables that are in documentation form will typically be archived at completion of a project, or transitioned into an Architecture Repository as a reference model, standard, or snapshot of the Architecture Landscape at a point in time.

4.41 Digital Architecture

The inclusive architecture focused on a combination of Enterprise Architecture, data science, telecommunications and IoT, security, artificial intelligence, cognitive science, neuroscience, robotics, and social medias to deliver operational services.

4.42 Enterprise

The highest level (typically) of description of an organization and typically covers all missions and functions. An enterprise will often span multiple organizations.

4.43 Enterprise Architecture Service

An encapsulated element of Enterprise Architecture capability that delivers specific Enterprise Architecture functionality.

4.44 Enterprise Continuum

A categorization mechanism for classifying architecture and Solution Building Blocks (SBBs) as they evolve from generic to specific applicability (or vice versa).

4.45 Foundation Architecture

Generic building blocks, their inter-relationships with other building blocks, combined with the principles and guidelines that provide a foundation on which more specific architectures can be built.

4.46 Framework

A structure for content or process that can be used as a tool to structure thinking, ensuring consistency and completeness.

4.47 Gap

A statement of difference between two states. Used in the context of gap analysis, where the difference between the Baseline and Target Architecture is identified.

Note:: Gap analysis is described in the TOGAF Standard — ADM Techniques.

4.48 Governance

The discipline of monitoring and guiding the management of a business (or IS/IT landscape) to deliver the business outcomes required.

4.49 Information

Any communication or representation of facts, data, or opinions, in any medium or form, including textual, numerical, graphic, cartographic, narrative, or audio-visual forms.

4.50 Information Technology (IT)

The lifecycle management of information and related technology used by an organization.

4.51 Interoperability

The ability to share information and services.
The ability of two or more systems or components to exchange and use information.
The ability of systems to provide and receive services from other systems and to use the services so interchanged to enable them to operate effectively together.

4.52 Logical

Implementation-independent.

Note:: A logical architecture is an implementation-independent definition of the architecture.

4.53 Metadata

Data about data, of any sort in any media, that describes the characteristics of an entity.

4.54 Metamodel

A model that describes the entities used in building an Architecture Description, their characteristics, and the key relationships between those entities.

4.55 Method

A defined, repeatable approach to address a particular type of problem.

4.56 Modeling

A technique through construction of models which enables a subject to be represented in a form that enables reasoning, insight, and clarity concerning the essence of the subject matter.

4.57 Model Kind

Conventions for a type of modeling.

Note:: An architecture viewpoint references one or more model kinds; an architecture view incorporates one or more models.

4.58 Objective

An organizational aim that is declared in a Specific, Measurable, Actionable, Realistic, and Timebound (SMART) way. For example, "Increase capacity utilization by 30% by the end of the year, to support the planned increase in market share".

4.59 Pattern

A technique for putting building blocks into context; for example, to describe a re-usable solution to a problem.

Note:: Building blocks are what you use: (architecture) patterns can tell you how you use them, when, why, and what trade-offs you have to make in doing so.

4.60 Physical

Real-world, tangible.

Note:: A logical architecture is realized through a physical architecture.

4.61 Principle

See 4.19 Architecture Principle .

4.62 Product

An outcome generated by the business to be offered to customers. Products include materials and/or services.

4.63 Reference Model (RM)

An abstract framework for understanding significant relationships among the entities of [an] environment, and for the development of consistent standards or specifications supporting that environment.

Note:: A reference model is based on a small number of unifying concepts and may be used as a basis for education and explaining standards to a non-specialist. A reference model is not directly tied to any standards, technologies, or other concrete implementation details, but it does seek to provide common semantics that can be used unambiguously across and between different implementations.
Source: OASIS®; refer to www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm.

4.64 Requirement

A statement of need, which is unambiguous, testable or measurable, and necessary for acceptability.

4.65 Roadmap

An abstracted plan for business or technology change, typically operating across multiple disciplines over multiple years. Normally used in the phrases Technology Roadmap, Architecture Roadmap, etc.

4.66 Role

The usual or expected behavior of an actor, or the part somebody or something plays in a particular process or event. An actor may have a number of roles.
The part an individual plays in an organization and the contribution they make through the application of their skills, knowledge, experience, and abilities.

4.67 Segment Architecture

A detailed, formal description of areas within an enterprise, used at the program or portfolio level to organize and align change activity.

4.68 Service

An encapsulated element of behavior that provides specific functionality in response to requests from actors or other services.

Note:: A service has an interface and description.

4.69 Service Orientation

Viewing an enterprise, system, or building block in terms of services provided and consumed.

4.70 Service-Oriented Architecture (SOA)

An architectural style that supports service orientation.

4.71 Service Portfolio

A collection of services, potentially an interface definition.

Note:: It is used in the TOGAF framework to define the requirement for a building block or system.

4.72 Solution Architecture

A description of a discrete and focused business operation or activity and how IS/IT supports that operation.

4.73 Solution Building Block (SBB)

A physical or implementation-specific component that realizes part or all of one or more logical Architecture Building Blocks (ABBs).

Note:: There are business, application, and technology SBBs.

4.74 Solutions Continuum

A categorization mechanism, with increasing detail and specialization, for the components and artifacts stored in the Solutions Landscape or Reference Library (part of the Architecture Repository).

4.75 Stakeholder

An individual, team, organization, or class thereof, having an interest in a system.

4.76 Standards Library

A library of standards that can be used to define the particular services and other components of an Organization-Specific Architecture.

Note:: The Standards Library is described in the TOGAF Standard — Architecture Content: Architecture Repository.

4.77 Strategic Architecture

A summary formal description of the enterprise, providing an organizing framework for operational and change activity, and an executive-level, long-term view for direction setting.

4.78 Target Architecture

The description of a future state of the architecture being developed for an organization.

Note:: There may be several future states developed as a roadmap to show the evolution of the architecture to a target state.

4.79 Taxonomy of Architecture Views

The organized collection of all architecture views pertinent to an architecture.

4.80 Technology Architecture

A description of the structure and interaction of the technology services and technology components.

Note:: Technology Architecture is described in the TOGAF Standard — Architecture Development Method.

4.81 Technology Component

A technology building block. A generic infrastructure technology that supports and enables application or data components (directly or indirectly) by providing technology services.
An encapsulation of technology infrastructure that represents a class of technology product or specific technology product.

4.82 Technology Service

A technical capability required to provide enabling infrastructure that supports the delivery of applications.

4.83 Transition Architecture

A formal description of one state of the architecture at an architecturally significant point in time.

Note:: One or more Transition Architectures may be used to describe the progression in time from the Baseline to the Target Architecture.
Transition Architecture is described in the TOGAF Standard — Architecture Content: Architecture Definition Document.

4.84 Value Stream

A representation of an end-to-end collection of activities that create an overall result for a customer, stakeholder, or end user.

4.85 View

See 4.20 Architecture View .

4.86 Viewpoint

See 4.21 Architecture Viewpoint .

4.87 Viewpoint Library

A collection of the specifications of architecture viewpoints contained in the Reference Library portion of the Architecture Repository.

4.88 Work Package

A set of actions identified to achieve one or more objectives for the business. A work package can be a part of a project, a complete project, or a program.

return to top of page

<<< Previous

Home

Next >>>

Search