Most Used Terms in TOGAF
Below you find a selection of the most used words in TOGAF and their TOGAF definition.
If possible a comparison of that definition is made with other framework glossaries.
A full list of TOGAF terms you find on the TOGAF Wiki: http://www.opengroup.org
- What does TOGAF mean?
- What does ArchiMate mean?
Other Glossaries
Other Methods and Frameworks with their glossaries on Dragon1 are:
- Dragon1 open EA Method - Enterprise Architecture Method and Framework
DISCLAIMER
Dragon1 is a business platform but also an open EA Method. Dragon1 does not endorse TOGAF. Some definitions of Dragon1 and TOGAF even conflict with each other, such as the definitions for Architecture and Principle. We only provide for means of comparison of the terms of TOGAF here. We do not recommend using these terms. We recommend using the Dragon1 glossary of terms and definitions.
TOGAF 9.1 Definitions List
1 Abstraction
The technique of providing summarized or generalized descriptions of detailed and complex content.
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 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.
2 Actor
A person, organization, or system that has a role 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. 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 Application
A deployed and operational IT system that supports business functions and services; for example, a payroll. Applications use data and are supported by multiple technology components but are distinct from the technology components that support the application.
4 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.
5 Application Platform
The collection of technology components of hardware and software that provide the services used to support applications.
6 Application Platform Interface (API)
The interface, or set of functions, between application software and/or the application platform.
7 Architectural Style
The combination of distinctive features in which architecture is performed or expressed.
8 Architecture
- A formal description of a system, or a detailed plan of the system at the component level, to guide its implementation (source: ISO/IEC 42010:2007).
- The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.
9 Architecture Building Block (ABB)
A constituent of the architecture model that describes a single aspect of the overall model.
10 Architecture Continuum
A part of the Enterprise Continuum. A repository of architectural elements with increasing detail and specialization. This Continuum begins with foundational definitions like reference models, core strategies, and basic building blocks. From there it spans Industry Architectures and all the way to an organization's specific architecture.
11 Architecture Development Method (ADM)
The core of TOGAF. A step-by-step approach to developing and using an enterprise architecture.
12 Architecture Domain
The architectural area being considered. There are four architecture domains within TOGAF: business, data, application, and technology.
13 Architecture Framework
A conceptual structure used to develop, implement, and sustain an architecture.
14 Architecture Governance
The practice and orientation by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level. It is concerned with change processes (design governance) and the operation of production systems (operational governance).
15 Architecture Landscape
The architectural representation of assets in use, or planned, by the enterprise at particular points in time.
16 Architecture Principles
A qualitative statement of intent that should be met by the architecture. Has at least a supporting rationale and a measure of importance.
17 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.
18 Artifact
An architectural work product that describes an aspect of the architecture.
19 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.
20 Boundaryless Information Flow
- A trademark of The Open Group.
- A shorthand representation of 'access to integrated information to support business process improvements' representing the desired state of an enterprise's infrastructure specific to the business needs of the organization.
An infrastructure that provides Boundaryless Information Flow has open standard components that provide services in a customer's extended enterprise that:
- Combine multiple sources of information
- Securely deliver the information whenever and wherever it is needed, in the right context for the people or systems using that information.
21 Building Block
Represents a (potentially reusable) component of a business, IT, or architectural capability that can be combined with other building blocks to deliver architectures and solutions.
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'.
22 Business Architecture
A description of the structure and interaction between the business strategy, organization, functions, business processes, and information needs.
23 Business Function
Delivers business capabilities closely aligned to an organization, but not necessarily explicitly governed by the organization.
24 Business Governance
Concerned with ensuring that the business processes and policies (and their operation) deliver the business outcomes and adhere to relevant business regulations.
25 Business Service
Supports business capabilities through an explicitly defined interface and is explicitly governed by an organization.
26 Capability
An ability that an organization, person, or system possesses. Capabilities are typically expressed in general and high-level terms and typically require a combination of organization, people, processes, and technology to achieve. For example, marketing, customer contact, or outbound telemarketing.
27 Capability Architecture
A highly detailed description of the architectural approach to realize a particular solution or solution aspect.
28 Capability Increment
A discrete portion of a capability architecture that delivers specific value. When all increments have been completed, the capability has been realized.
29 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.
30 Concerns
The key interests that are crucially important to the stakeholders in a system, and determine the acceptability of the system. Concerns may pertain to any aspect of the system's functioning, development, or operation, including considerations such as performance, reliability, security, distribution, and evolvability.
31 Constraint
An external factor that prevents an organization from pursuing particular approaches to meet its goals. For example, customer data is not harmonized within the organization, regionally or nationally, constraining the organization's ability to offer effective customer service.
32 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.
33 Deliverable
An architectural work product that is contractually specified and in turn formally reviewed, agreed and signed off by the stakeholders. Deliverables represent the output of projects and those deliverables that are in documentation form will typically be archived after the 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.
34 Enterprise
The highest level (typically) of the description of an organization and typically covers all missions and functions. An enterprise will often span multiple organizations.
35 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.
36 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.
37 Framework
A structure for content or process that can be used as a tool to structure thinking, ensuring consistency and completeness.
38 Gap
A statement of the difference between two states. Used in the context of gap analysis, where the difference between the Baseline and Target Architecture is identified.
39 Governance
The discipline of monitoring, managing, and steering a business (or IS/IT landscape) to deliver the business outcome required.
40 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.
41 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.
42 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.
43 Logical
An implementation-independent definition of the architecture, often grouping related physical entities according to their purpose and structure. For example, the products from multiple infrastructure software vendors can all be logically grouped as Java application server platforms.
44 Metadata
Data about data, of any sort in any media, that describes the characteristics of an entity.
45 Metamodel
A model that describes how and with what the architecture will be described in a structured way.
46 Method
A defined, repeatable approach to address a particular type of problem.
47 Methodology
A defined, repeatable series of steps to address a particular type of problem, which typically centers on a defined process, but may also include the definition of content.
48 Model
A representation of a subject of interest. A model provides a smaller-scale, simplified, and/or abstract representation of the subject matter. A model is constructed as a 'means to an end'. In the context of enterprise architecture, the subject matter is a whole or part of the enterprise and the end is the ability to construct 'views' that address the concerns of particular stakeholders; i.e., their 'viewpoints' in relation to the subject matter.
49 Modeling
A technique through the construction of models that enables a subject to be represented in a form that enables reasoning, insight, and clarity concerning the essence of the subject matter.
50 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 2009 to support the planned increase in market share'.
51 Patterns
A technique for putting building blocks into context; for example, to describe a reusable solution to a problem. Building blocks are what you use: patterns can tell you how you use them, when, why, and what trade-offs you have to make in doing so.
52 Performance Management
The monitoring, control, and reporting of the enterprise architecture practice performance. Also concerned with continuous improvement.
53 Physical
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.
54 Platform
A combination of technology infrastructure products and components that provides that prerequisites host application software.
55 Platform Service
A technical capability required to provide enabling infrastructure that supports the delivery of applications.
56 Principle
Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission.***
57 Reference Model (RM)
A reference model is 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. 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 a common semantics that can be used unambiguously across and between different implementations.
58 Repository
A system that manages all of the data of an enterprise, including data and process models and other enterprise information. Hence, 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.
59 Requirement
A statement of need that must be met by a particular architecture or work package.
60 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.
61 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.
62 Segment Architecture
A detailed, formal description of areas within an enterprise, used at the program or portfolio level to organize and align change activity.
63 Service Orientation
A way of thinking in terms of services and service-based development and the outcomes of services.
64 Service Oriented Architecture (SOA)
An architectural style that supports service orientation. It has the following distinctive features:
- It is based on the design of the services - which mirror real-world business activities - comprising the enterprise (or inter-enterprise) business processes.
- Service representation utilizes business descriptions to provide context (i.e., business process, goal, rule, policy, service interface, and service component) and implements services using service orchestration.
- It places unique requirements on the infrastructure - it is recommended that implementations use open standards to realize interoperability and location transparency.
- Implementations are environment-specific - they are constrained or enabled by context and must be described within that context.
- It requires strong governance of service representation and implementation.
- It requires a 'Litmus Test', which determines a 'good service'.
65 Solution Architecture
A description of a discrete and focused business operation or activity and how IS/IT supports that operation. 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.
66 Solution Building Block (SBB)
A candidate solution that conforms to the specification of an Architecture Building Block (ABB).
67 Solutions Continuum
A part of the Enterprise Continuum. A repository of reusable solutions for future implementation efforts. It contains implementations of the corresponding definitions in the Architecture Continuum.
68 Stakeholder
An individual, team, or organization (or classes thereof) with interests in, or concerns relative to, the outcome of the architecture. Different stakeholders with different roles will have different concerns.
69 Standards Information Base (SIB)
A database of standards that can be used to define the particular services and other components of an Organization-Specific Architecture.
70 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.
71 Target Architecture
The description of a future state of the architecture being developed for an organization. There may be several future states developed as a roadmap to show the evolution of the architecture to a target state.
72 Taxonomy of Architecture Views
The organized collection of all views pertinent to an architecture.
73 Technology Architecture
A description of the structure and interaction of the platform services, and logical and physical technology components.
74 Transition Architecture
A formal description of one state of the architecture at an architecturally significant point in time. One or more Transition Architectures may be used to describe the progression in time from the Baseline to the Target Architecture.
75 View
The representation of a related set of concerns. A view is what is seen from a viewpoint. An architecture view may be represented by a model to demonstrate to stakeholders their areas of interest in the architecture. A view does not have to be visual or graphical in nature.
76 Viewpoint
A definition of the perspective from which a view is taken. It is a specification of the conventions for constructing and using a view (often by means of an appropriate schema or template). A view is what you see; a viewpoint is where you are looking from - the vantage point or perspective that determines what you see.
77 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.