What is the TOGAF Standard?
The TOGAF standard is an architecture framework that provides the methods and tools for
assisting in the acceptance, production, use, and maintenance of an Enterprise Architecture.
What is architecture in the context of the TOGAF ?
The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.
There are four architecture domains that are commonly accepted as subsets of an overall Enterprise Architecture, all of which the TOGAF standard is designed to support
- Business Architecture defines the business strategy, governance, organization, and
key business processes - Data Architecture describes the structure of an organization’s logical and physical
data assets and data management resources - Application Architecture provides a blueprint for the individual applications to be deployed, their interactions, and their relationships to the core business processes of the organization
- Technology Architecture describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services; this includes IT infrastructure, middleware, networks, communications, processing, standards, etc.
Architecture Development Method
The TOGAF Architecture Development Method (ADM) provides a tested and repeatable process for developing architectures. The ADM includes establishing an architecture framework, developing architecture content, transitioning, and governing the realization of architectures.
Preliminary Phase
The Preliminary Phase describes the preparation and initiation activities required to create an Architecture Capability** including **customization of the TOGAF framework** and d_efinition of Architecture Principles_**
Phase A: Architecture Vision
Phase A: Architecture Vision describes the initial phase of an architecture development cycle** It includes information about defining the **scope** of the architecture development initiative, **identifying the stakeholders**, **creating the Architecture Vision**, and obtaining **approval to proceed with the architecture development.
Phase B: Business Architecture
Phase B: Business Architecture describes the development of a Business Architecture to support the agreed Architecture Vision.
Phase C: Information Systems Architecture (_D_ata & _A_pplication)
Phase C: Information Systems Architectures describes the development of Information Systems Architectures to support the agreed Architecture Vision.
Phase D: Technology Architecture
Phase D: Technology Architecture describes the development of the Technology Architecture to support the agreed Architecture Vision
Phase E: Opportunities & Solutions
Phase E: Opportunities & Solutions conducts initial implementation planning and the identification of delivery vehicles for the architecture defined in the previous phases
Phase F: Migration Planning
Phase F: Migration Planning addresses how to move from the Baseline to the Target Architectures** by **finalizing** a **detailed Implementation and Migration Plan
Phase G: Implementation Governance
Phase G: Implementation Governance provides an architectural oversight of the implementation
Phase H: Architecture Change Management
Phase H: Architecture Change Management establishes procedures for managing change to the new architecture.
Requirements Management
Requirements Management examines the process of managing architecture requirements throughout the ADM.
Deliverable
A deliverable is a work product that is contractually specified and in turn formally reviewed, agreed, and signed off by the stakeholders
Artifact
An artifact is an architectural work product that describes an aspect of the architecture** Artifacts are generally classified as **catalogs (lists of things)**, **matrices (showing relationships between things)**, and **diagrams (pictures of things)
Building Block
A building block represents a (potentially re-usable) component of enterprise capability that can be combined with other building blocks to deliver architectures and solutions
— Architecture Building Blocks (ABBs) typically describe required capability and shape the specification of Solution Building Blocks (SBBs).
— Solution Building Blocks (SBBs) represent components that will be used to implement the required capability.
Enterprise Continuum
The Enterprise Continuum is a view of the Architecture Repository that provides methods for classifying** architecture and solution artifacts as they evolve **from generic Foundation Architectures to Organization-Specific Architectures**. The Enterprise Continuum comprises two complementary concepts: the **Architecture Continuum** and the **Solutions Continuum.
Architecture Repository
Architecture Repository can be used to store different classes of architectural output** at different levels of abstraction, created by the ADM. In this way, the TOGAF standard facilitates u_nderstanding and co-operation between stakeholders and practitioners_** at different levels.
The major components within an Architecture Repository are as follows:
- The Architecture Metamodel describes the organizationally tailored application of an architecture framework, including a metamodel for architecture content
- The Architecture Capability defines the parameters, structures, and processes that support governance of the Architecture Repository
- The Architecture Landscape is the architectural representation of assets deployed within the operating enterprise at a particular point in time — the landscape is likely to exist at multiple levels of abstraction to suit different architecture objectives
- The Standards Information Base (SIB) captures the standards with which new architectures must comply, which may include industry standards, selected products and services from suppliers, or shared services already deployed within the organization
The major components within an Architecture Repository are as follows:
- The Reference Library provides guidelines, templates, patterns, and other forms of reference material that can be leveraged in order to accelerate the creation of new architectures for the enterprise
- The Governance Log provides a record of governance activity across the enterprise
- The Architecture Requirements Repository provides a view of all authorized architecture requirements which have been agreed with the Architecture Board
- The Solutions Landscape presents an architectural representation of the SBBs supporting the Architecture Landscape which have been planned or deployed by the enterprise
The benefits of Architecture Governance include:
- Increased transparency of accountability, and informed delegation of authority
- Controlled risk management
- Protection of the existing asset base through maximizing re-use of existing architectural components
- Proactive control**, **monitoring, and management mechanisms
- Process, concept, and component re-use across all organizational business units
- Value creation through monitoring, measuring, evaluation, and feedback
The benefits of Architecture Governance include:
- Increased visibility supporting internal processes and external parties’ requirements; in particular, increased visibility of decision-making at lower levels ensures oversight at an appropriate level within the enterprise of decisions that may have far-reaching strategic consequences for the organization
- Greater shareholder value; in particular, Enterprise Architecture increasingly represents the core intellectual property of the enterprise — studies have demonstrated a correlation between increased shareholder value and well-governed enterprises
- Integrates with existing processes and methodologies and complements functionality by adding control capabilities
