Chapter 5: Introduction to the Architecture Development Method

• The Architecture Development Cycle

  

  • Preliminary Phase: Prepares the organization for successful TOGAF architecture projects. Undertake the preparation and initiation activities required to create an Architecture Capability, including the customization of the TOGAF framework, selection of tools, and the definition of Architecture Principles.
  • Requirements Management: Every stage of a TOGAF project is based on and validates business requirements. Requirements are identified, stored, and fed into and out of the relevant ADM phases, which dispose of, address, and prioritize requirements.
  • Phase A: Architecture Vision: Sets the scope, constraints, and expectations for a TOGAF project. Create the Architecture Vision, Identify stakeholders, Validate the business context and create the Statement of Architecture Work, and Obtain approvals.
  • Phase B: Business Architecture Phase C: Information Systems Architectures (Application & Data) Phase D: Technology Architecture Develop architectures in four domains:
    • 1. Business
    • 2. Information Systems – Application
    • 3. Information Systems – Data
    • 4. Technology

    In each case, develop the Baseline and Target Architecture and analyze gaps.

  • Phase E: Opportunities & Solutions Perform initial implementation planning and the identification of delivery vehicles for the building blocks identified in the previous phases. Determine whether an incremental approach is required, and if so identify Transition Architectures.
  • Phase F: Migration Planning Develop Detailed Implementation and Migration Plan that addresses how to move from the Baseline to the Target Architecture.
  • Phase G: Implementation Governance Provide architectural oversight for the implementation. Prepare and issue Architecture Contracts. Ensure that the implementation project conforms to the architecture.
  • Phase H: Architecture Change Management: Provide continual monitoring and a change management process to ensure that the architecture responds to the needs of the enterprise and maximizes the value of the architecture to the business.

Chapter 6: The Enterprise Continuum and Tools

• The Architecture Repository:
  • The Architecture Metamodel describes the organizationally tailored application of an architecture framework, including a method for architecture development and a metamodel for architecture content.
  • The Architecture Capability defines the parameters, structures, and processes that support governance of the Architecture Repository.
  • The Architecture Landscape presents an architectural representation of assets in use, or planned, by the enterprise at particular points in time.
  • The Standards Information Base 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 Open Group provides an example of a Standards Information Base on its web site.
  • 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.

Chapter 7: The ADM Phases

• Preliminary Phase: includes the preparation and initiation activities to create an Architecture Capability. Key activities are as follows:
  • Understand the business environment
  • Ensure high-level management commitment
  • Obtain agreement on scope
  • Establish architecture principles
  • Establish governance structure
  • Customization of the TOGAF framework
• Business Capability Management (Business Direction and Planning) which determine what business capabilities are required.
• Portfolio/Project Management Methods which determine how a company manages its change initiatives.
• Operations Management Methods which describe how a company runs its day-to-day operations, including IT.
• Solution Development Methods which formalize the way that business systems are delivered

  

  

• Phase A: Architecture Vision: Phase A is about project establishment and initiates an iteration of the Architecture Development Cycle, setting the scope, constraints, and expectations for the iteration. Objectives:
  • Develop a high-level aspirational vision of the capabilities and business value to be delivered because of the proposed enterprise architecture.
  • Obtain approval for a Statement of Architecture Work that defines a program of works to develop and deploy the architecture outlined in the Architecture Vision.
• Phase B: Business Architecture Phase B is about development of a Business Architecture to support an agreed Architecture Vision. This describes the fundamental organization of a business embodied in:
  • Its business process and people
  • Their relationships to each other and the people
  • The principles governing its design and evolution
  • and shows how an organization meets its business goals.
• Objectives are:
  • Develop the Target Business Architecture describing how the enterprise needs to operate to achieve the business goals, responds to the strategic drivers set out in the Architecture Vision, and addresses the Request for Architecture Work and stakeholder concerns
  • Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Business Architectures
• Phase C: Information Systems Architectures: Phase C is about documenting the Information Systems Architectures for an architecture project, including the development of Data and Application Architectures. This describes the major types of information and the application systems that process the information, and their relationships to each other and the environment. There are two steps in this phase, which may be developed either sequentially or concurrently:
  • Data Architecture
  • Application Architecture
• Objectives
  • Develop the Target Information Systems (Data and Application) Architecture, describing how the enterprise’s Information Systems Architecture will enable the Business Architecture and the Architecture Vision, in a way that addresses the Request for Architecture Work and stakeholder concerns.
  • Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Information Systems (Data and Application) Architectures
• Key Considerations for the Data Architecture:
  • Data Management
    • Defining application components which will serve as the system of record or reference for enterprise master data
    • Defining enterprise-wide standards that all application components, including software packages, need to adopt
    • Understanding how data entities are utilized by business functions, processes, and services
    • Understanding how and where enterprise data entities are created, stored, transported, and reported
    • Understanding the level and complexity of data transformations required to support the information exchange needs between applications
    • Defining the requirement for software in supporting data integration with the enterprise’s customers and suppliers (e.g., use of ETL tools during the data migration, data profiling tools to evaluate data quality, etc.)
  • Data Migration
  • Data Governance
• Phase D: Technology Architecture is about documenting the Technology Architecture for an architecture project, in the form of the fundamental organization of the IT systems:
  • Embodied in the hardware, software, and communications technology
  • Their relationships to each other and the environment
  • The principles governing its design and evolution
• Objectives
  • Develop the Target Technology Architecture that enables the logical and physical application and data components and the Architecture Vision, addressing the Request for Architecture Work and stakeholder concerns
  • Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Technology Architectures
• Phase E: Opportunities and Solutions: is the first phase which is directly concerned with implementation. It describes the process of identifying major implementation projects and grouping them into work packages that deliver the Target Architecture identified in previous phases. Key activities are as follows:
  • Perform initial implementation planning
  • Identify the major implementation projects
  • Group changes into work packages
  • Decide on approach: — Make versus buy versus re-use — Outsource — COTS — Open Source
  • Assess priorities
  • Identify dependencies
• Objectives
  • Generate the initial complete version of the Architecture Roadmap, based upon the gap analysis and candidate Architecture Roadmap components from Phases B, C, and D
  • Determine whether an incremental approach is required, and if so identify Transition Architectures that will deliver continuous business value.
• Phase F: Migration Planning: addresses detailed migration planning; that is, how to move from the Baseline to the Target Architectures. Key activities include:
  • For work packages and projects identified, perform a cost/benefit analysis and a risk assessment
  • Finalize a detailed Implementation and Migration Plan
• Objectives
  • Finalize the Architecture Roadmap and the supporting Implementation and Migration Plan
  • Ensure that the Implementation and Migration Plan is coordinated with the enterprise’s approach to managing and implementing change in the enterprise’s overall change portfolio
  • Ensure that the business value and cost of work packages and Transition Architectures is understood by key stakeholders
• Phase G: Implementation Governance: defines how the architecture constrains the implementation projects, monitors it while building it, and produces a signed Architecture Contract. Key activities include:
  • Provide architectural oversight for the implementation
  • Define architecture constraints on implementation projects
  • Govern and manage an Architecture Contract
  • Monitor implementation work for conformance
• Objectives
  • Ensure conformance with the Target Architecture by implementation projects
  • Perform appropriate Architecture Governance functions for the solution and any implementation-driven architecture Change Requests
• Phase H: Architecture Change Management: ensures that changes to the architecture are managed in a controlled manner. Key activities include:
  • Provide continual monitoring and a change management process
  • Ensure that changes to the architecture are managed in a cohesive and architected way
  • Provide flexibility to evolve rapidly in response to changes in the technology or business environment
  • Monitor the business and capacity management
• Objectives
  • Ensure that the architecture lifecycle is maintained
  • Ensure that the Architecture Governance Framework is executed
  • Ensure that the enterprise’s Architecture Capability meets current requirement
• Requirements Management: The process of managing architecture requirements applies to all phases of the ADM cycle. The Requirements Management process is a dynamic process, which addresses the identification of requirements for the enterprise, stores them, and then feeds them in and out of the relevant ADM phases. This process is central to driving the ADM process.
• Objectives
  • Ensure that the Requirements Management process is sustained and operates for all relevant ADM phases
  • Manage architecture requirements identified during any execution of the ADM cycle or a phase
  • Ensure that the relevant architecture requirements are available for use by each phase as the phase is executed.