Doing Enterprise Architecture-Planning: TOGAF

1. TOGAF

Consists of two continua:

1. Architectural continuum

Foundation Common Systems IndustryOrganisation

Architectures ====>  Architectures========> Architectures======> Architecture

reference model, Focus on a specific Aligned to industryleverage architectures

service taxonomy, subject area. i.e. security, of target organisationdeveloped along the

list of products andnetwork mgt, etc. common e.g. POSC (petro-continuum

technologies-logicalacross IT industry e.g. IBM chemical architectures)

Microsoft

2. Solution continuum

Products & Services ====> Systems Solutions ====> Industry Solutions ====>Organisation Solutions

2. TOGAF Structure

Business Strategy and Requirements

ArchitecturesArchitecture Development Method Governance

Business Reference ModelsTechnical Reference Model Standards Information Base

Standards Information Base

A database of open industry standards

Complete set of Open Group endorsed standards

-Content determined by Open Group consensus process

-Structured according to TOGAF Technical Reference Model Taxonomy

Regularly updated

Available for public web access

Gateway to many linked resources

Resource Base

A set of resources including guidelines, templates, and background information to help the architecture in the use of the ADM:

-Guidelines

-Principles

-Mock set of function views

-A method for deriving business requirements for architecture and implied technical requirements

-Real-life examples of TOGAF

-Definitions of key terms

-Tools and techniques helpful in using TOGAF

-Mapping the TOGAF ADM to the Zachman Framework

Architecture Development Methodology

Defined process guiding the development of an enterprise architecture

Essentially a requirements gathering methodology across architecture domains:

-business

-data

-applications

-infrastructure

Iterative across the whole process or between and within phases.

For each iteration of the ADM, new decisions must be taken regarding:

-Breadth of coverage of the enterprise to be defined

-Level of detail to be defined

-Extent of the time horizon aimed at, including the number and extend of any intermediate time horizons

TOGAF does not build model,it allows you to use set of processes,tasks, templates etc. to arrive the importance of your architecture.

Preliminary Framework & Principles

Objectives:

To define  'how we do architecture' in the enterprise

-framework to be used

-Architectural principles

To engage and get commitment from relevant stakeholders incl. major executives, line managers, major customers

-Define the 'architecture footprint' for the organization - the people responsible for performing architecture work, where they are located, and their responsibilities.

-Define the project scope and assumptions

Inputs

Business strategy, Business Principles, Business Goals and Business Drivers

Phase A: Architecture Vision

(check the definition of the framework and principles

details of building the architecture

prepare the grand work for developing the architecture)

Objectives:

-Validate business principles, business goals, and strategic drivers of the organization

-Define scope and constraints

-Breadth of enterprise coverage, level of detail to be defined, specific domains to be covered, timelines, assets to be leveraged

-Project-specific constraints (time, schedule, resources, etc.) and enterprise

-Create vision and prioritize components

-Must reflect requirements and constraints

-High-level description of the baseline ('as-is') and target ('to-be') environments

-Ensure management sponsorship and commitment

-Understand the impact on, and of other enterprise projects

Phase B: Business Architecture

(Gathering business requirements on what we need capture the understand about how we our work)

Objectives:

-Describe the current baseline business architecture

-Develop target Business Architecture

-Organizational, functional, process (inventory), information, and geographic aspects of the enterprise

-Based on the business principles, business goals, and strategic drivers

-Gap analysis of baseline and target Business Architectures

-Select appropriate architectural viewpoints to demonstrate how stakeholder concerns are resolved in the Business Architecture

Phase C: Information Systems Architecture

(What sort of things we need to know and collect the document the way we provide about the ICT infrastructure and information systems)

Objectives:

Data Architecture:

-Define the key data type and sources of data required to support the business

-Data must be complete and consistent

-Presentation of model must be comprehensible to stakeholders

Application Architecture:

-Define what types of application systems are relevant to the enterprise and what services those applications need to provide in order to manage and present the required data

Phase D: Technical Architecture

(Definition of what is doing that and analysis understanding it and place it up interation)

Objectives:

Develop a technology architecture what will form the basis of the implementation project

Steps:

-Technology Baseline Description

Review Business, Data, Application Baseline

Business functions supported

Organizational units supported

Networks accessed

Applications and data supported

System inter-dependencies (for example, fall-back configurations)

-Identify candidate technology architecture building blocks (potential reusable assets)

-Develop a baseline description of As Is Technology Architecture

-Define for each major hardware or software platform type: Name(short and long), Physical location, Owner(s)

Phase E: Opportunities & Solutions

(What are the things we gonna do?how we gonna do,what steps we gonna take?)

Objectives:

To progress the Implementation plan:

Identify parameters of change, major phases

High priority projects for transition from legacy to target environment

Note:

New application may be identified and so it may be necessary to iterate between Phase D

Risk:

Must be careful not to waste time and money in search of the perfect architecture

Phase F: Migration Planning

(why need migration planning?-project management part)

Objectives:

To prioritise implementation projects

- Assess dependencies, costs, benefits

- Assess Risks

- Identify and manage contingent projects/ initiatives

- Identify and Schedule resources

- Build Implementation Plan

Phase G: Implementation Governance

Objectives:

To develop recommendations for each implementation project

Develop architecture contract to govern the system implementation and deployment

System implementation during this phase

Develop Governance modus operand

Phase H: Architecture Change Management

Objectives:

To define the architecture change management process for the new baseline architecture

Provide for the continual monitoring of:

Technology developments

Changes in the business environment

Determine whether or not to initiate a new cycle of the architecture evolution cycle.

3. ADM Benefit

It's Free!

Comprehensive and generalized method

Provide Baseline to start

Can be tailored to the specific needs of an organisation

The whole methodology can be adapted

-Some phases may be unnecessary

-Some procedures might need to be modified

-Some procedures might need to be added