TOGAF an Overview – Part-2

So, once you have done your planning for project (As described in Part-1), you proceed to define the requirement.

In this step you need to define, in these four dimensions, where you are (baseline), where you want to be (target) and what the gap is.. And Define requirement is what we will learn in post below.

Steps for Defining the Requirement

We had discussed the following lists (without the 3 steps in “Define Requirement”) in my earlier posts –
What is TOGAF? & Planning a project.

  1. Tailor TOGAF to suit your need
  2. Define scope of work and prepare plan for rollout
    1. Define the scope and get approval from the sponsor
    2. Define requirement in terms of how the business process will change, what data, application and technical infrastructure is required for accomplishing the work
      1. What should the new business process be?
      2. What application & data do we need to support the changed process?
      3. What technology infrastructure do we require to implement the change?
    3. Select a suitable solution and make the implementation plan
  3. Oversee development and implementation
  4. Manage post-implementation change

Here are some of the terminologies used in TOGAF and their meaning as used in TOGAF.

View & Viewpoint

  • View = What you see or what a stakeholder sees
  • Viewpoint = Model or description of the information contained in a view

Baseline, Target & Gap

  • Baseline = Where you are now
  • Target = Where you want to be
  • Gap = What needs to change

Deliverable & Artifact

  • Deliverable = Contractually specified document – formally reviewed, agreed, and signed off by the stakeholders
  • Artifact = Architecture from a specific viewpoint – can be a Catalog, a Matrix or a Diagram

What artifacts do you may produce?

Catalog Matrix Diagram
Business Architecture
  • Organization/Actor catalog
  • Driver/Goal/Objective catalog
  • Role catalog
  • Business Service/Function catalog
  • Location catalog
  • Process/Event/Control/Product catalog
  • Contract/Measure catalog
  • Business Interaction matrix
  • Actor/Role matrix
  • Business Footprint diagram
  • Business Service/Information diagram
  • Functional Decomposition diagram
  • Product Lifecycle diagram
  • Goal/Objective/Service diagram
  • Use-Case diagram
  • Organization Decomposition diagram
  • Process Flow diagram
  • Event diagram
Data Architecture
  • Data Entity/Data Component catalog
  • Data Entity/Business Function matrix
  • System/Data matrix
  • Class diagram
  • Data Dissemination diagram
  • Data Lifecycle diagram
  • Data Security diagram
  • Data Migration diagram
  • Class Hierarchy diagram
Application Architecture
  • Application Portfolio catalog
  • Interface catalog
  • System/Organization matrix
  • Role/System matrix
  • Application Interaction matrix
  • System/Function matrix
  • Application Communication diagram
  • Application and User Location diagram
  • System Use-Case diagram
  • Enterprise Manageability diagram
  • Process/System Realization diagram
  • Software Engineering diagram
  • Application Migration diagram
  • Software Distribution diagram
Technology Architecture
  • Technology Standards catalog
  • Technology Portfolio catalog
  • System/Technology matrix
  • Environments and Locations diagram
  • Platform Decomposition diagram
  • Processing diagram
  • Networked Computing/Hardware diagram
  • Communications Engineering diagram

Comparison of ADM Objectives – TOGAF 9 vs. TOGAF 9.1

Phase Objective as per TOGAF 9 Objective as per TOGAF 9.1
Preliminary
  • To review the organizational context for conducting enterprise architecture
  • To identify the sponsor stakeholder(s) and other major stakeholders impacted by the business directive to create an enterprise architecture and determine their requirements and priorities from the enterprise, their relationships with the enterprise, and required working behaviors with each other
  • To ensure that everyone who will be involved in, or benefit from, this approach is committed to the success of the architectural process
  • To enable the architecture sponsor to create requirements for work across the affected business areas
  • To identify and scope the elements of the enterprise organizations affected by the business directive and define the constraints and assumptions (particularly in a federated architecture environment)
  • To define the ‘‘architecture footprint’’ for the organization — the people responsible for performing architecture work, where they are located, and their responsibilities
  • To define the framework and detailed methodologies that are going to be used to develop enterprise architectures in the organization concerned (typically, an adaptation of the generic ADM)
  • To confirm a governance and support framework that will provide business process and resources for architecture governance through the ADM cycle; these will confirm the fitness-for-purpose of the Target Architecture and measure its ongoing effectiveness (normally includes a pilot project)
  • To select and implement supporting tools and other infrastructure to support the architecture activity
  • To define the architecture principles that will form part of the constraints on any architecture work
  1. Determine the Architecture Capability desired by the organization:
    • Review the organizational context for conducting enterprise architecture
    • Identify and scope the elements of the enterprise organizations affected by the Architecture Capability
    • Identify the established frameworks, methods, and processes that intersect with the Architecture Capability
    • Establish Capability Maturity target
  2. Establish the Architecture Capability:
    • Define and establish the Organizational Model for Enterprise Architecture
    • Define and establish the detailed process and resources for architecture governance
    • Select and implement tools that support the Architecture Capability
    • Define the Architecture Principles
Phase A
  • To ensure that this evolution of the architecture development cycle has proper recognition and endorsement from the corporate management of the enterprise, and the support and commitment of the necessary line management
  • To define and organize an architecture development cycle within the overall context of the architecture framework, as established in the Preliminary phase
  • To validate the business principles, business goals, and strategic business drivers of the organization and the enterprise architecture Key Performance Indicators (KPIs)
  • To define the scope of, and to identify and prioritize the components of, the Baseline Architecture effort
  • To define the relevant stakeholders, and their concerns and objectives
  • To define the key business requirements to be addressed in this architecture effort, and the constraints that must be dealt with
  • To articulate an Architecture Vision and formalize the value proposition that demonstrates a response to those requirements and constraints
  • To create a comprehensive plan that addresses scheduling, resourcing, financing, communication, risks, constraints, assumptions, and dependencies, in line with the project management frameworks adopted by the enterprise (such as PRINCE2 or PMBOK)
  • To secure formal approval to proceed
  • To understand the impact on, and of, other enterprise architecture development cycles ongoing in parallel
  1. Develop a high-level aspirational vision of the capabilities and business value to be delivered as a result of the proposed enterprise architecture
  2. 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
  • To describe the Baseline Business Architecture
  • To develop a Target Business Architecture, describing the product and/or service strategy, and the organizational, functional, process, information, and geographic aspects of the business environment, based on the business principles, business goals, and strategic drivers
  • To analyze the gaps between the Baseline and Target Business Architectures
  • To select and develop the relevant architecture viewpoints that will enable the architect to demonstrate how the stakeholder concerns are addressed in the Business Architecture
  • To select the relevant tools and techniques to be used in association with the selected viewpoints
  1. Develop the Target Business Architecture that describes how the enterprise needs to operate to achieve the business goals, and respond to the strategic drivers set out in the Architecture Vision, in a way that addresses the Request for Architecture Work and stakeholder concerns
  2. Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Business Architectures

 

Phase C The objective of Phase C is to develop Target Architectures covering either or both (depending on project scope) of the data and application systems domains.Information Systems Architecture focuses on identifying and defining the applications and data considerations that support an enterprise’s Business Architecture; for example, by defining views that relate to information, knowledge, application services, etc.
  1. 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
  2. Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Information Systems (Data and Application) Architectures

 

Phase D The Technology Architecture phase seeks to map application components defined in the Application Architecture phase into a set of technology components, which represent software and hardware components, available from the market or configured within the organization into technology platforms.As Technology Architecture defines the physical realization of an architectural solution, it has strong links to implementation and migration planning.Technology Architecture will define baseline (i.e., current) and target views of the technology portfolio, detailing the roadmap towards the Target Architecture, and to identify key work packages in the roadmap. Technology Architecture completes the set of architectural information and therefore supports cost assessment for particular migration scenarios.
  1. 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
  2. Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Technology Architectures

 

Phase E
  • To review the target business objectives and capabilities, consolidate the gaps from Phases B to D, and then organize groups of building blocks to address these capabilities
  • To review and confirm the enterprise’s current parameters for and ability to absorb change
  • To derive a series of Transition Architectures that deliver continuous business value (e.g., capability increments) through the exploitation of opportunities to realize the building blocks
  • To generate and gain consensus on an outline Implementation and Migration Strategy
  1. 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
  2. Deter mine whether an incremental approach is required, and if so identify Transition Architectures that will deliver continuous business value

 

Phase F
  • To ensure that the Implementation and Migration Plan is coordinated with the various management frameworks in use within the enterprise
  • To prioritize all work packages, projects, and building blocks by assigning business value to each and conducting a cost/business analysis
  • To finalize the Architecture Vision and Architecture Definition Documents, in line with the agreed implementation approach
  • To confirm the Transition Architectures defined in Phase E with relevant stakeholders
  • To create, evolve, and monitor the detailed Implementation and Migration Plan providing necessary resources to enable the realization of the Transition Architectures, as defined in Phase E
  1. Finalize the Architecture Roadmap and the supporting Implementation and Migration Plan
  2. 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
  3. Ensure that the business value and cost of work packages and Transition Architectures is understood by key stakeholders

 

Phase G
  • To formulate recommendations for each implementation project
  • To govern and manage an Architecture Contract covering the overall implementation and deployment process
  • To perform appropriate governance functions while the solution is being implemented and deployed
  • To ensure conformance with the defined architecture by implementation projects and other projects
  • To ensure that the program of solutions is deployed successfully, as a planned program of work
  • To ensure conformance of the deployed solution with the Target Architecture
  • To mobilize supporting operations that will underpin the future working lifetime of the deployed solution
  1. Ensure conformance with the Target Architecture by implementation projects
  2. Perform appropriate Architecture Governance functions for the solution and any implementation-driven architecture Change Requests

 

Phase H
  • To ensure that baseline architectures continue to be fit-for-purpose
  • To assess the performance of the architecture and make recommendations for change
  • To assess changes to the framework and principles set up in previous phases
  • To establish an architecture change management process for the new enterprise architecture baseline that is achieved with completion of Phase G
  • To maximize the business value from the architecture and ongoing operations
  • To operate the Governance Framework
  1. Ensure that the architecture lifecycle is maintained
  2. Ensure that the Architecture Governance Framework is executed
  3. Ensure that the enterprise Architecture Capability meets current requirements

 

Here are the links to the material from The Open Group

This entry was posted in TOGAF and tagged , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s