| You are here: | ||
| <<< Previous | Home | Next >>> |
For the purposes of TOGAF 9, the following terms and definitions apply. A. Glossary of Supplementary Definitions should be referenced for supplementary definitions not defined in this chapter.
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 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 task or collection of tasks that support the functions of an organization. For example, a user entering data into an IT system or traveling to visit customers.
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.
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.
A description of the major logical grouping of capabilities that manage the data objects necessary to process the data and
support the business.
The collection of technology components of hardware and software that provide the services used to support applications.
The interface, or set of functions, between application software and/or the application platform.
The combination of distinctive features in which architecture is performed or expressed.
A constituent of the architecture model that describes a single aspect of the overall model.
See also 3.24 Building Block .
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 to Industry Architectures and all the way to an organization's specific architecture.
See also 3.39 Enterprise Continuum .
The core of TOGAF. A step-by-step approach to develop and use an enterprise architecture.
The architectural area being considered. There are four architecture domains within TOGAF: business, data, application, and technology.
A foundational structure, or set of structures, which can be used for developing a broad range of different architectures. It should contain a method for designing an information system in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks.
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 operation of product systems (operational governance).
See also 3.45 Governance .
The architectural representation of assets deployed within the operating enterprise at a particular point in time. The views are segmented into strategic, segment, and capability levels of abstraction to meet diverse stakeholder needs.
A qualitative statement of intent that should be met by the architecture. Has at least a supporting rationale and a measure of
importance.
See 3.88 View .
An architectural work product that describes an architecture from a specific viewpoint. Examples include a network diagram, a server specification, a use-case specification, a list of architectural requirements, and a business interaction matrix. Artifacts are generally classified as catalogs (lists of things), matrices (showing relationships between things), and diagrams (pictures of things). An architectural deliverable may contain multiple artifacts and artifacts will form the content of the Architecture Repository.
See also 3.24 Building Block .
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.
The existing defined system architecture before entering a cycle of architecture review and redesign.
An infrastructure that provides Boundaryless Information Flow has open standard components that provide services in a customer's extended enterprise that:
Represents a (potentially re-usable) component of 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".
See also 3.20 Artifact .
The business strategy, governance, organization, and key business processes information, as well as the interaction between
these concepts.
A grouping of coherent business functions and activities (in the context of a business sector) over which meaningful responsibility can be taken. For example, Finance, Human Resources (HR), Automobile Manufacturing, Retail, etc. The phrase is often used to identify specific business knowledge (a business domain expert).
Delivers business capabilities closely aligned to an organization, but not necessarily explicitly governed by the organization.
Concerned with ensuring that the business processes and policies (and their operation) deliver the business outcomes and adhere to relevant business regulation.
Supports business capabilities through an explicitly defined interface and is explicitly governed by an organization.
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.
A highly detailed description of the architectural approach to realize a particular solution or solution aspect.
The output from a business change initiative that delivers an increase in performance for a particular capability of the enterprise.
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.
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.
See also 3.80 Stakeholder .
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.
The structure of an organization's logical and 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. 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. An enterprise will often span multiple organizations.
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.
See also 3.11 Architecture Continuum and 3.79 Solutions Continuum .
The provision and management of the environment required to support the operations of the enterprise architecture practice, including facilities, equipment, tools, and information systems.
The management of the financial aspects of the enterprise architecture practice; e.g., budgeting and forecasting.
An architecture of generic services and functions that provides a foundation on which more specific architectures and architectural components can be built. The TOGAF Foundation Architecture includes a Technical Reference Model (TRM).
A structure for content or process that can be used as a tool to structure thinking, ensuring consistency and completeness.
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.
The discipline of monitoring, managing, and steering a business (or IS/IT landscape) to deliver the business outcome required.
See also 3.15 Architecture Governance , 3.28 Business Governance , and A.60 Operational Governance in A. Glossary of Supplementary Definitions .
Any communication or representation of facts, data, or opinions, in any medium or form, including textual, numerical, graphic, cartographic, narrative, or audio-visual forms.
The awareness and understanding of facts, truths, or information gained in the form of experience or learning (a posteriori), or through introspection (a priori). Knowledge is an appreciation of the possession of interconnected details which, in isolation, are of lesser value.
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.
Data about data, of any sort in any media, that describes the characteristics of an entity.
A model that describes how and with what the architecture will be described in a structured way.
A defined, repeatable approach to address a particular type of problem.
See also 3.54 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 definition of content.
See also 3.53 Method .
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.
See also 3.80 Stakeholder , 3.88 View , and 3.89 Viewpoint .
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.
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".
A self-contained unit of resources with line management responsibility, goals, objectives, and measures. Organizations may include external parties and business partner organizations.
A technique for putting building blocks into context; for example, to describe a re-usable 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.
See also 3.24 Building Block .
The monitoring, control, and reporting of the enterprise architecture practice performance. Also concerned with continuous improvement.
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.
A combination of technology infrastructure products and components that provides that pre-requisites to host application software.
A technical capability required to provide enabling infrastructure that supports the delivery of applications.
See 3.17 Architecture Principles .
The management of the quality aspects of the enterprise architecture practice; e.g., management plans, quality criteria, review processes.
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 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. 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.
A quantitative statement of business need that must be met by a particular architecture or work package.
The acquisition, development, and management of human resources within the enterprise architecture practice in response to
demand for enterprise architecture services and financial constraints.
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.
See also 3.3 Actor .
A detailed, formal description of areas within an enterprise, used at the program or portfolio level to organize and align change activity.
See also 3.82 Strategic Architecture .
The management of the execution and performance of the enterprise architecture practice services. This includes managing the "pipeline" plus current service portfolio.
A way of thinking in terms of services and service-based development and the outcomes of services.
See also 3.75 Service Oriented Architecture (SOA) .
An architectural style that supports service orientation. It has the following distinctive features:
See also 3.8 Architectural Style and 3.74 Service Orientation .
The ability to perform a job-related activity, which contributes to the effective performance of a task.
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.
A candidate physical solution for an Architecture Building Block (ABB); e.g., a Commercial Off-The-Shelf (COTS) package, that is a component of the Acquirer view of the architecture.
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.
See also 3.39 Enterprise Continuum and 3.11 Architecture Continuum .
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.
See also A.86 System Stakeholder in A. Glossary of Supplementary Definitions .
A database of standards that can be used to define the particular services and other components of an Organization-Specific
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.
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.
The organized collection of all views pertinent to an architecture.
A structure which allows components of an information system to be described in a consistent manner (i.e., the way in which you describe the components).
See also 3.66 Reference Model (RM) .
The logical software and hardware capabilities that are required to support deployment of business, data, and application
services. This includes IT infrastructure, middleware, networks, communications, processing, and standards.
A formal description of the enterprise architecture showing periods of transition and development for particular parts of the
enterprise. Transition Architectures are used to provide an overview of current and target capability and allow for individual work
packages and projects to be grouped into managed portfolios and programs.
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.
See also 3.80 Stakeholder and 3.89 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.
See also A.56 Metaview in A. Glossary of Supplementary Definitions .
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
The TOGAF document set is designed for use with frames. To navigate around the document:
Downloads of the TOGAF documentation, are available under license from the TOGAF information web site. The license is free to any organization wishing to use TOGAF entirely for internal purposes (for example, to develop an information system architecture for use within that organization). A book is also available (in hardcopy and pdf) from The Open Group Bookstore as document G091.