For the purposes of the TOGAF standard, the following terms and definitions apply. A. 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 A. Glossary of Supplementary Definitions .
3.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.
3.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.
3.3 Application Architecture
A description of the structure and interaction of the applications as groups of capabilities that provide key business functions
and manage the data assets.
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.
3.5 Application Platform
The collection of technology components of hardware and software that provide the services used to support applications.
3.6 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.
3.7 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.
3.8 Architecture Building Block (ABB)
A constituent of the architecture model that describes a single aspect of the overall model.
A part of the Enterprise Continuum. A repository of architectural elements with increasing detail and specialization.
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.
The core of the TOGAF framework. A multi-phase, iterative approach to develop and use an Enterprise Architecture to shape and
govern business transformation and implementation projects.
The architectural area being considered. The TOGAF framework has four primary architecture domains: business, data, application,
and technology. Other domains may also be considered (e.g., security).
3.12 Architecture Framework
A conceptual structure used to plan, develop, implement, govern, and sustain an architecture.
3.13 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.
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".
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.
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.
3.22 Boundaryless Information Flow™
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).
3.23 Building Block
A (potentially re-usable) component of enterprise capability 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".
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, initiatives, and
stakeholders.
Note:
Business Architecture relates business elements to business goals and elements of other domains.
A particular ability that a business may possess or exchange to achieve a specific purpose.
3.26 Business Function
Delivers business capabilities closely aligned to an organization, but not necessarily explicitly governed by the
organization.
3.27 Business Governance
Concerned with ensuring that the business processes and policies (and their operation) deliver the business outcomes and adhere
to relevant business regulation.
3.28 Business Model
A model describing the rationale for how an enterprise creates, delivers, and captures value.
3.29 Business Service
Supports business capabilities through an explicitly defined interface and is explicitly governed by an organization.
3.30 Capability
An ability that an organization, person, or system possesses.
Note:
For example, Enterprise Architecture, marketing, customer contact, or outbound telemarketing.
3.31 Capability Architecture
A highly detailed description of the architectural approach to realize a particular solution or solution aspect.
3.32 Capability Increment
A discrete portion of a capability architecture that delivers specific value. When all increments have been completed, the
capability has been realized.
3.33 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.
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.
Direction and focus provided by strategic goals and objectives, often to deliver the value proposition characterized in the
business model.
3.36 Data Architecture
A description of the structure and interaction of the enterprise's major types and sources of data, logical data assets,
physical data assets, and data management resources.
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.
3.38 Enterprise
The highest level (typically) of description of an organization and typically covers all missions and functions. An enterprise
will often span multiple organizations.
3.39 Enterprise Continuum
A categorization mechanism useful for classifying architecture and solution artifacts, both internal and external to the
Architecture Repository, as they evolve from generic Foundation Architectures to Organization-Specific Architectures.
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.
3.41 Framework
A structure for content or process that can be used as a tool to structure thinking, ensuring consistency and completeness.
3.42 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.
Any communication or representation of facts, data, or opinions, in any medium or form, including textual, numerical, graphic,
cartographic, narrative, or audio-visual forms.
3.45 Information System Service
A discrete behavior requestable from an application (e.g., log in, book train seat, transfer money).
Note:
It supports and enables business roles and processes by capturing or providing data or automating a process. It can be
coarse-grained or fine-grained (cf. a use-case or user story). It can be found in and invoked via an interface.
The automated elements of a business service.
3.46 Information Technology (IT)
The lifecycle management of information and related technology used by an organization.
An umbrella term that includes all or some of the subject areas relating to the computer industry, such as Business Continuity,
Business IT Interface, Business Process Modeling and Management, Communication, Compliance and Legislation, Computers, Content
Management, Hardware, Information Management, Internet, Offshoring, Networking, Programming and Software, Professional Issues,
Project Management, Security, Standards, Storage, Voice and Data Communications. Various countries and industries employ other
umbrella terms to describe this same collection.
A term commonly assigned to a department within an organization tasked with provisioning some or all of the domains described
in (2) above.
Alternate names commonly adopted include Information Services, Information Management, et al.
3.47 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.
3.48 Logical
An implementation-independent definition of the architecture, often grouping related physical entities according to their
purpose and structure.
Note:
For example, the products from multiple infrastructure software vendors can all be logically grouped as Java® application
server platforms.
3.49 Metadata
Data about data, of any sort in any media, that describes the characteristics of an entity.
3.50 Metamodel
A model that describes how and with what the architecture will be described in a structured way.
3.51 Method
A defined, repeatable approach to address a particular type of problem.
3.52 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.
3.53 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.
3.54 Objective
A time-bounded milestone for an organization used to demonstrate progress towards a goal; for example, "Increase capacity
utilization by 30% by the end of 2019 to support the planned increase in market share".
3.55 Organization Map
An articulation of the relationships between the primary entities that make up the enterprise, its partners, and
stakeholders.
3.56 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.
A description of a real-world entity. Physical elements in an Enterprise Architecture may still be considerably abstracted from
Solution Architecture, design, or implementation views.
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.
A system that manages all of the data of an enterprise, including data and process models and other enterprise information.
Note:
The data in a repository is much more extensive than that in a data dictionary, which generally defines only the data making up
a database.
3.61 Requirement
A statement of need that must be met by a particular architecture or work package.
3.62 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.
3.63 Role
The usual or expected function of an actor, or the part somebody or something plays in a particular action 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.
A repeatable activity; a discrete behavior that a building block may be requested or otherwise triggered to perform.
Note:
Examples include check customer credit, provide weather data, and consolidate drilling reports. It serves a client or customer
by delivering an output or changing system state. It can be defined in a logical service contract that defines input and output
flows and/or state changes. It encapsulates any building block that processes the input and output flows. It may be one of several
services in a service portfolio or Service-Level Agreement (SLA). It may be invoked via an interface. It can be coarse-grained
(build a house) or fine-grained (retrieve an address).
An element of behavior that provides specific functionality in response to requests from actors or other services.
3.66 Service Orientation
Viewing an enterprise, system, or building block in terms of services provided and consumed.
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.
3.69 Solution Architecture
A description of a discrete and focused business operation or activity and how IS/IT supports that operation.
Note:
A Solution Architecture typically applies to a single project or project release, assisting in the translation of requirements
into a solution vision, high-level business and/or IT system specifications, and a portfolio of implementation tasks.
3.70 Solution Building Block (SBB)
A candidate solution which conforms to the specification of an Architecture Building Block (ABB).
3.71 Solutions Continuum
A part of the Enterprise Continuum. A repository of re-usable solutions for future implementation efforts. It contains
implementations of the corresponding definitions in the Architecture Continuum.
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.
3.75 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.
3.76 Taxonomy of Architecture Views
The organized collection of all architecture views pertinent to an architecture.
3.77 Technology Architecture
A description of the structure and interaction of the technology services and technology components.
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.
3.79 Technology Service
A technical capability required to provide enabling infrastructure that supports the delivery of applications.
3.80 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.
A collection of the specifications of architecture viewpoints contained in the Reference Library portion of the Architecture
Repository.
3.85 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
return to top of page