Ate Togaf - 000 - Definitions

Front 1

Application

Back 1

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.

Front 2

Application Architecture

Back 2

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

Front 3

Architecture

Back 3

1. A formal description of a system, or a detailed plan of the system at component level, to guide its implementation (source: ISO/IEC 42010:2007).

2. The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.

Front 4

Architecture Building Block (ABB)

Back 4

A constituent of the architecture model that describes a single aspect of the overall model.

Front 5

Architecture Development Method (ADM)

Back 5

The core of TOGAF. A step-by-step approach to develop and use an enterprise architecture.

Front 6

Architecture Domain

Back 6

The architectural area being considered. There are four architecture domains within TOGAF: business, data, application, and technology.

Front 7

Architecture Framework

Back 7

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

Front 8

Architecture Principle

Back 8

A qualitative statement of intent that should be met by the architecture. Has at least a supporting rationale and a measure of importance.

Front 9

Artifact

Back 9

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

Front 10

Boundaryless Information Flow

Back 10

1. A trademark of The Open Group.

2. 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.

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.

Front 11

Business Function

Back 11

Delivers business capabilities closely aligned to an organization, but not necessarily explicitly governed by the organization.

Front 12

Capability

Back 12

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.

Front 13

Capability Increment

Back 13

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

Front 14

Data Architecture

Back 14

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.

Front 15

Deliverable

Back 15

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.

Front 16

Enterprise

Back 16

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

Front 17

Enterprise Continuum

Back 17

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.

Front 18

Gap

Back 18

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.

Front 19

Information

Back 19

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

Front 20

Information Technology (IT)

Back 20

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

2. 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.

3. A term commonly assigned to a department within an organization tasked with provisioning some or all of the domains described in (2) above.

4. Alternate names commonly adopted include Information Services, Information Management, et al.

Front 21

Interoperability

Back 21

1. The ability to share information and services.

2. The ability of two or more systems or components to exchange and use information.

3. 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.

Front 22

Metamodel

Back 22

A model that describes how and with what the architecture will be described in a structured way.

Front 23

Method

Back 23

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

Front 24

Methodology

Back 24

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.

Front 25

Model

Back 25

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.

Front 26

Modeling

Back 26

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.

Front 27

Objective

Back 27

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".

Front 28

Patterns

Back 28

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.

Front 29

Platform Service

Back 29

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

Front 30

Requirement

Back 30

A statement of need that must be met by a particular architecture or work package.

Front 31

Roadmap

Back 31

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.

Front 32

Solutions Continuum

Back 32

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.

Front 33

Stakeholder

Back 33

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.

Front 34

Strategic Architecture

Back 34

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.

Front 35

Taxonomy of Architecture Views

Back 35

The organized collection of all views pertinent to an architecture.

Front 36

View

Back 36

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.

Front 37

Viewpoint

Back 37

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.

Front 38

Work Package

Back 38

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.