Chapter 3: Core Concepts

• What are the ADM phase names and the purpose of each phase?
  

  
  

• The Preliminary Phase describes the preparation and initiation activities required to create an Architecture Capability, including the customization of the TOGAF framework, and the definition of Architecture Principles.
• Phase A: Architecture Vision describes the initial phase of an Architecture Development Cycle. It includes information about defining the scope, identifying the stakeholders, creating the Architecture Vision, and obtaining approvals.
• Phase B: Business Architecture describes the development of a Business Architecture to support an agreed Architecture Vision.
• Phase C: Information Systems Architectures describes the development of Information Systems Architectures for an architecture project, including the development of Data and Application Architectures.
• Phase D: Technology Architecture describes the development of the Technology Architecture for an architecture project.
• Phase E: Opportunities and Solutions describes the process of identifying major implementation projects and grouping them into work packages that deliver the Target Architecture defined in the previous phases.
• Phase F: Migration Planning describes the development of a detailed Implementation and Migration Plan that addresses how to move from the Baseline to the Target Architecture.
• Phase G: Implementation Governance provides an architectural oversight of the implementation.
• Phase H: Architecture Change Management establishes procedures for managing change to the new architecture.
• Requirements Management examines the process of managing architecture requirements throughout the ADM.
• What are deliverables, artifacts, and building blocks?
  

• What is the 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.

The Enterprise Continuum and the Architecture Repository The Enterprise Continuum provides a view of the Architecture Repository that shows the evolution of these related architectures from generic to specific, from abstract to concrete, and from logical to physical. [Source: TOGAF 9 Part V: Enterprise Continuum and Tools]

• What is the Architecture Repository?
  

Architecture Repository is used to store different classes of architectural output at different levels of abstraction

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 shows an architectural view of the building blocks that are in use within the organization today (e.g., a list of the live applications). 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 Reference Library provides guidelines, templates, patterns, and other forms of reference material that can be leveraged to accelerate the creation of new architectures for the enterprise.
• The Governance Log provides a record of governance activity across the enterprise. abstraction to suit different architecture objectives

• How to establish and operate an enterprise architecture capability?
  

  
  

  
  

  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
• 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
• How to use the TOGAF framework with other frameworks?
  

Why is the TOGAF standard becoming so popular in the industry? One key reason is that architects can use the TOGAF ADM in conjunction with any of the popular frameworks. The TOGAF ADM is framework-agnostic and helps IT architects fill in the framework they might already have in use.

Chapter 4: Key Terminology

• Architecture: Architecture has two meanings depending upon its contextual usage:
  • A formal description of a system, or a detailed plan of the system at component level to guide its implementation
  • The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.
• Architecture Principles: A qualitative statement of intent that should be met by the architecture. Has at least a supporting rationale and a measure of importance.
• Architecture Vision: 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 vision and a boundary for detailed architecture development.
• Baseline: 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.