TOGAF Definitions Flashcards
The technique of providing summarized or generalized descriptions of detailed and complex content.
1 Abstraction 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.
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. They may be internal or external to an organization.
2 Actor In the automotive industry, an original equipment manufacturer would be considered an actor by an automotive dealership that interacts with its supply chain activities.
A description of the structure and interaction of the applications as groups of capabilities that provide key business functions and manage the data assets.
3 Application Architecture Application Architecture is described in Part II, 10. Phase C: Information Systems Architectures - Application Architecture .
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.
4 Application Component For example, a business application such as an accounting, payroll, or CRM system.
The collection of technology components of hardware and software that provide the services used to support applications.
5 Application Platform
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.
6 Architectural Style
- 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)
7 Architecture
A constituent of the architecture model that describes a single aspect of the overall model.
8 Architecture Building Block (ABB)
A part of the Enterprise Continuum. A repository of architectural elements with increasing detail and specialization.
9 Architecture Continuum 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.
10 Architecture Development Method (ADM) The ADM is described in Part II: Architecture Development Method (ADM).
The architectural area being considered. The TOGAF framework has four primary ones: business, data, application, and technology. Others may also be considered (e.g., security).
11 Architecture Domain
A conceptual structure used to plan, develop, implement, govern, and sustain an architecture.
12 Architecture Framework
The practice of monitoring and directing architecture-related work. The goal is to deliver desired outcomes and adhere to relevant principles, standards, and roadmaps.
13 Architecture Governance
The layout and representation of assets in use, or planned, by the enterprise at particular points in time.
14 Architecture Landscape
A representation of a subject of interest within an architecture, providing a smaller scale, simplified, and/or abstract representation of the subject matter.
15 Architecture Model An architecture model provides a smaller scale, simplified, and/or abstract representation of the subject matter.
A qualitative statement of intent that should be met by the architecture.
16 Architecture Principle A sample set of Architecture Principles is defined in Part III, 20. Architecture Principles .
A representation of a system from the perspective of a related set of concerns.
17 Architecture View In some sections of this standard, the term “view” is used as a synonym for “architecture view”.
A specification of the conventions for a particular kind of architecture view.
18 Architecture Viewpoint 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.
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 and a boundary for detailed architecture development.
19 Architecture Vision Phase A (Architecture Vision) is described in Part II, 6. Phase A: Architecture Vision .
An architectural work product that describes an aspect of the architecture.
20 Artifact
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.
21 Baseline
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.
22 Boundaryless Information Flow™ 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).
A (potentially re-usable) component of enterprise capability that can be combined with others to deliver architectures and solutions.
23 Building Block 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.
24 Business Architecture 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.
25 Business Capability
Delivers business capabilities closely aligned to an organization, but not necessarily explicitly governed by the organization.
26 Business Function
Concerned with ensuring that the business processes and policies (and their operation) deliver the business outcomes and adhere to relevant business regulation.
27 Business Governance
A model describing the rationale for how an enterprise creates, delivers, and captures value.
28 Business Model
Supports business capabilities through an explicitly defined interface and is explicitly governed by an organization.
29 Business Service
An ability that an organization, person, or system possesses.
30 Capability For example, Enterprise Architecture, marketing, customer contact, or outbound telemarketing.
A highly detailed description of the architectural approach to realize the ability of a business to provide a specific solution or solution aspect.
31 Capability Architecture
A discrete portion of a capability architecture that delivers specific value. When all of these have been completed, the capability has been realized.
32 Capability Increment
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.
33 Communications and Stakeholder Management Architecture stakeholder management is described in 21. Stakeholder Management .
An interest in a system relevant to one or more of its stakeholders.
34 Concern 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.
Activity undertaken to achieve strategic goals and objectives, often specified to provide direction and focus when delivering the value proposition characterized in the business model.
35 Course of Action
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.
36 Data Architecture Data Architecture is described in Part II, 9. Phase C: Information Systems Architectures - Data Architecture .
An architectural work product that is contractually specified and in turn formally reviewed, agreed, and signed off by the stakeholders.
37 Deliverable 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.
The highest level (typically) of description of an organization and typically covers all missions and functions. It will often span multiple organizations.
38 Enterprise
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.
39 Enterprise Continuum
Generic building blocks, their inter-relationships with other building blocks, combined with the principles and guidelines that provide the basis on which more specific architectures can be built.
40 Foundation Architecture
A structure for content or process that can be used as a tool to structure thinking, ensuring consistency and completeness.
41 Framework
A statement of difference between two states. Itemized in an analysis which identifies the differences between the Baseline and Target Architecture.
42 Gap Gap analysis is described in Part III, 23. Gap Analysis .
The discipline of monitoring, managing, and steering a business (or IS/IT landscape) as it delivers a business outcome required.
43 Governance
Any communication or representation of facts, data, or opinions, in any medium or form, including textual, numerical, graphic, cartographic, narrative, or audio-visual forms.
44 Information
- A discrete behavior requestable from an application (e.g., log in, book train seat, transfer money). 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.
45 Information System Service
- The lifecycle management of information and related technology used by an organization.
46 Information Technology (IT)
- The ability to share information and services. [across systems]
47 Interoperability
An implementation-independent definition of the architecture, often grouping related physical entities according to their purpose and structure.
48 Logical For example, the products from multiple infrastructure software vendors can all be logically grouped as Java® application server platforms.
Data about data, of any sort in any media, that describes the characteristics of an entity.
49 Metadata
A model that describes how and with what the architecture will be described in a structured way.
50 Metamodel
A defined, repeatable approach to address a particular type of problem.
51 Method
A technique which enables a subject to be represented in forms that enable reasoning, insight, and clarity concerning the essence of the subject matter, without constructing or depicting the entire subject.
52 Modeling
Conventions for a type of modeling referenced in an architectural viewpoint.
53 Model Kind
An architecture viewpoint references one or more model kinds; an architecture view incorporates one or more models.
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”.
54 Objective
An articulation of the relationships between the primary entities that make up the enterprise, its partners, and stakeholders.
55 Organization Map
A re-usable technique for putting building blocks into context; for example, to describe a re-usable solution to a problem.
(Or) A repeatable behavior
56 Pattern
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 as opposed to abstract or reference. These elements in an Enterprise Architecture may still be considerably abstracted from Solution Architecture, design, or implementation views.
57 Physical
A qualitative statement of intent that should be met by the product or outcome.
58 Principle (See 3.16 Architecture principle)
An abstract framework for understanding significant relationships among the entities of [an] environment, based on a small number of unifying concepts. May be used as a basis for education and explaining standards to a non-specialist, and for the development of consistent standards or specifications supporting that environment. 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.
59 Reference Model (RM) 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 collects and manages all of the data of an enterprise, including data and process models and other enterprise information.
60 Repository 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.
