TOGAF Definitionen

A way of thinking in terms of services and service-based development and the outcomes of services.

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

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 solution which conforms to the specification of an Architecture Building Block (ABB).

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.

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.

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 description of the structure and interaction of the platform services, and logical and physical technology components.

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.

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.

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.

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.

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.

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 structure and interaction of the applications as groups of capabilities that provide key business functions and manage the data assets.

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.

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.

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

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 conceptual structure used to develop, implement, and sustain an architecture.

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

The architectural representation of assets in use, or planned, by the enterprise at particular points in time.