Вы находитесь на странице: 1из 40

An Introduction to TOGAF

An Overview TOGAF (The Open Group Architecture Framework)


September 2008 <onSite in Rome>
1

Agenda

Overview of EA Overview of TOGAF TOGAF v8 Value of TOGAF Comparison with ADM TOGAF v9

Copyright 2008 Accenture All Rights Reserved.

Overview of Enterprise Architecture


An Enterprise Architecture supports the business by providing the fundamental technology and process structure for an IT strategy. This in turn makes IT a responsive asset for a successful modern business strategy.
Enterprise: Collection of organisations that share common set of goals Government agency Part of a corporation Corporation Large corporations comprise multiple enterprises May be an Extended enterprise Including partners, suppliers and customers Drivers: Laws and regulations Clinger-Cohen Act (US Information Technology Management Reform Act 1996) EU Directives on the Award of Public Contracts Sarbanes-Oxley More extended enterprises More co-operative IT operations Greater publicity to failures Increase in litigation Audit requirements Architecture: Fundamental organisation of something, embodied in Its components, their relationships to each other and the environment, And the principles governing its design and evolution

Why Enterprise Architecture?


A good Enterprise Architecture enables you to achieve the right balance between IT efficiency and business innovation.
Effective management and exploitation of information through IT is key to business success Good information management = competitive advantage Current IT systems do not really meet the needs of business

Fragmented, duplicated Poorly understood Not responsive to change Focused on system maintenance Tactical developments rather than a strategic plan
Enterprise view of capabilities required to execute strategy

Investment in Information Technology

Individual Capability Blueprints

Levels of Architecture
The levels of Architecture consist of the Business Architecture, Information Systems Architecture and Technology Architecture.

Source: The Open Group, Architecting the Enterprise

The importance of Governance


The adoption of governance into TOGAF aligns the framework with current business best practice and also ensures a level of visibility, guidance, and control that will support all architecture stakeholder requirements and obligations.
An Enterprise Architecture is only as good as the decision making framework that is established around it governance framework The Governance Framework depends on a clear authority structure and the right participants Benefits: Increased transparency of accountability, and informed delegation of authority Controlled risk management Protection of the existing asset base through maximising re-use of existing architectural components Proactive control, monitoring, and management mechanisms Process, concept, and component re-use across all organisational business units Value creation through monitoring, measuring, evaluation, and feedback Increased visibility supporting internal processes and external parties requirements Governance: Governance looks at the way in which decisions are made, who is responsible for them, who is involved and who is accountable?

Architecture Framework
Using an architecture framework will speed up and simplify architecture development, ensure more complete coverage of the designed solution, and make certain that the architecture selected allows for future growth in response to the needs of the business.

An architecture framework is a toolkit which can be used for developing a broad range of different architectures. It should describe a method for designing an information system in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks.

Agenda

Overview of EA Overview of TOGAF TOGAF v8 Value of TOGAF Comparison with ADM TOGAF v9

Copyright 2008 Accenture All Rights Reserved.

The Components of TOGAF


A set of methods and tools for developing a broad range of different IT architectures.
TOGAF is an architecture framework The Open Group Architecture Framework. It enables you to design, evaluate, and build the right architecture for your organisation. The key to TOGAF is the Architecture Development Method (ADM) a reliable, proven method for developing an IT Enterprise Architecture that meets the needs of your business. TOGAF consists of 3 main parts: 1. The TOGAF Architecture Development Method (ADM): explains how to derive an organisation-specific Enterprise Architecture that addresses business requirements. The Enterprise Continuum: a virtual repository of all the architecture assets: models, patterns, architecture descriptions, etc. The TOGAF Resource Base: a set of resources: guidelines, templates, background information to help the architect in the use of the ADM.

1.

2.

Enterprise Continuum
The Enterprise Continuum provides a framework and context for the leveraging of relevant architecture assets in executing the ADM.

Guides and supports

Guides and supports

Guides and supports

Guides and supports

Enterprise Continuum = Architecture Continuum + Solution Continuum

Reference Models
Technical Reference Model: Reference Models: Focuses on the application platform

Integrated Information Infrastructure Reference Model: A major challenge in any project is effective communication between all participants Reference models create the common vocabulary and structure Use of reference model(s) is essential to identify duplicate functionality and opportunities for infrastructure simplification

Focuses on the flow of information at the application level

Agenda

Overview of EA Overview of TOGAF TOGAF v8 Value of TOGAF Comparison with ADM TOGAF v9

Copyright 2008 Accenture All Rights Reserved.

TOGAF 8 Scope and Goals


TOGAF 8 scope covers the development of four related types of architecture:

TOGAF 8 Goals: Long-term: An industry standard, generic enterprise architecture method. .usable in conjunction with frameworks having products relevant / specific to particular sectors. Several frameworks have mindshare: Zachman, Spewak, DoD Framework, FEAF, TEAF, Almost all focus on products, not method TOGAF and. (not TOGAF or.) Version 8:

An overall structure and core method for enterprise architecture that can be filled out in future years.

The Enterprise Architecture Development Method


The EA Development Method for defining business needs and developing an architecture that meets those needs, utilising the elements of TOGAF and other architectural assets available to the organisation.
An iterative method Each iteration = new decisions: Enterprise coverage Level of detail Time horizon Architecture asset re-use: Previous ADM iterations other frameworks, system models, industry models,) Decisions based on:

Competence / resource availability Value accruing to the enterprise.

The Enterprise Architecture Development Method


The Preliminary Framework and Principles sets the direction for the architecture as it prepare the organisation for a successful architecture project. In each case develop the baseline as is and target to be and analyse gaps
Architecture Change Management Ensure that the architecture responds to the needs of the organisation Requirements Management Every stage of the project should be based on and validate business requirements

Implementation Governance Ensure that the implementation project conforms to the architecture

Business Architecture Develop architectures at 3 levels

Migration Planning Analyse cost benefits and risk. Produce implementation roadmap

Information Systems Architecture Systems supporting the processes

Technology Architecture Opportunities and Solutions Identify major implementation projects Technology supporting the organisation

Frameworks and Principles


To ensure that everyone who will be involved in, or benefit from, this approach is committed to the success of the architectural process

Objectives: This phase prepares the organisation for a successful Enterprise Architecture project Understand business environment High level management commitment Agreement on scope of architecture activities Establish principles Establish governance structure Agree method

Outputs: This phase prepares the organisation for a successful Enterprise Architecture project Framework definition Architecture principles Restatement of, or reference to, business principles, business goals, and business drivers

Architecture Principles

General rules and guidelines that support the way in which an organisation sets about fulfilling its mission

Enduring and seldom amended Clearly related back to the business objectives

Value As drivers for defining the functional and non-functional requirements To provide a framework within which the enterprise can start to make conscious decisions about IT As a guide to making choices As an input to assessing both existing systems and the future directions

A) Architecture Vision
The Architecture Vision is essentially the architects elevator pitch the key opportunity to sell the benefits of the proposed development to the decision-makers within the enterprise.

Objectives: Initiates one iteration of the architecture process

Steps: Establish the Project Identify Business Goals and Business Drivers Review Architecture Principles, including Business Principles Define Scope Define Constraints Identify Stakeholders and Concerns, Business Requirements, and Architecture Vision Develop Statement of Architecture Work and Secure Approval

Outputs: Approved Statement of Architecture Work Refined statements of business goals and strategic drivers Architecture principles Architecture Vision

Sets scope, constraints, expectations for this project Required at the start of every architecture cycle

Validates business context Creates Statement of Architecture work

B) Business Architecture
A knowledge of the Business Architecture is a prerequisite for architecture work in any other domain (Data, Applications, Technology), and is therefore the first architecture activity that needs to be undertaken.

Business Architecture: The fundamental organisation of a business, embodied in its business processes and people, their relationships to each other and the environment, and the principles governing its design and evolution Shows how the organisation meets its business goals Steps: Confirm context Define baseline Define target Views are important Validate Requirements Concerns Gap analysis Produce report Outputs: Organisation structure Business goals and objectives Business functions Business Services Business processes Business roles Correlation of organisation and functions.

C) Information Systems Architecture


Objectives: The fundamental organisation of an IT system, embodied in

the major types of information and the application systems that process them their relationships to each other and the environment, and the principles governing its design and evolution Data or Applications First? It is usually necessary to address both Not always the case, depending on project scope and constraints

Shows how the IT systems meets the business goals of the enterprise Steps: Data Architecture Applications Architecture Outputs: Statement of Architecture Work Baseline & Target Data Architecture Baseline & Target Applications Architecture Data and Application Architecture views

May be developed in either order, or in parallel Theory suggests Data Architecture comes first Practical considerations may mean that starting with Application Systems may be more efficient

There will need to be some iteration to ensure consistency

D) Technology Architecture
A Technology Architecture that will for m the basis of the following implementation work.
Objectives: The fundamental organisation of an IT System, embodied in its hardware, software and communications technology their relationships to each other and the environment, and the principles governing its design and evolution Steps: Outputs: Develop Baseline Technology Architecture Description Develop Target Technology Architecture

Statement of Architecture Work Baseline Technology Architecture Validated technology principles Technology Architecture Report Target Technology Architecture Technology Architecture, gap report Viewpoints addressing key stakeholder concerns Views corresponding to the selected viewpoints

Developing the Technology Architecture

E) Opportunities and Solutions


Identifies the parameters of change, the major phases along the way, and the toplevel projects to be undertaken in moving from the current environment to the target
Objectives: Decide on approach Make v Buy v Re-Use Outsource COTS Open Source Assess priorities Identify the dependencies, costs, and benefits of the various projects Identify the strategic parameters for change Generate an overall implementation and migration strategy Identify Key Business Drivers Review Gap Analysis Brainstorm Technical Requirements Brainstorm Co-existence and Interoperability Brainstorm Co-existence and Interoperability Implementation and migration strategy High-level Implementation Plan Impact Analysis Steps: Outputs:

F) Migration Approach
The objective of the Migration Approach phase is to sort the various implementation projects into priority order.
Key business drivers to be addressed that will also tend to dictate the sequence of implementation, such as: Reduction of costs Consolidation of services Ability to handle change A goal to have a minimum of interim solutions Steps: Prioritise projects Estimate resource requirements and availability Perform cost/benefit assessment of the various migration projects Perform risk assessment Generate implementation roadmap Document the Migration Plan Outputs: Impact Analysis Detailed Implementation Plan and Migration Plan Including Architecture Implementation Contract, if appropriate)

Objectives:

Cost/benefit analysis Risk assessment Technology roadmap

G) Implementation Governance
All the information for successful management of the various implementation projects is brought together.

Objectives:

Steps:

Outputs:

Defines architecture constraints on implementation projects Architecture contract Monitors implementation work for conformance

Formulate Project Recommendation Document Architecture Contract Review Ongoing Implementation Governance and Architecture Compliance

Impact Analysis Architecture Contract The architecturecompliant implemented system

H) Architecture Change Management


This phase establishes an Architecture Change Management process for the new Enterprise Architecture baseline.

Objectives:

Steps: Monitor Technology Changes Monitor Business Changes Assess Changes and Development of Position to Act Arrange Meeting of Architecture Board (or other governing council)

Outputs: Architecture updates Changes to architecture framework and principles New Request for Architecture Work

Ensures that changes to the architecture are managed in a cohesive and architected way Establishes and supports the Enterprise Architecture to provide flexibility to evolve rapidly in response to changes in the technology or business environment

Agenda

Overview of EA Overview of TOGAF TOGAF v8 Value of TOGAF Comparison with ADM TOGAF v9

Copyright 2008 Accenture All Rights Reserved.

The Value of a Framework

Provides a practical starting point for an Architecture Project

Avoids the initial panic when the scale of the task becomes apparent Systematic Codified common sense Captures what others have found to work in real life Baseline set of resources Foundation architecture in the Enterprise Continuum

Agenda

Overview of EA Overview of TOGAF TOGAF v8 Value of TOGAF Comparison with ADM TOGAF v9

Copyright 2008 Accenture All Rights Reserved.

Accenture has a number of frameworks for architecture and methods that relate to the TOGAF
While TOGAF is restricted to IT architecture, Accenture frameworks address non-IT architectures for Strategy, Organisation/Change management, Process architecture and IT Architectures.
TOGAF I. II. Architecture development method Enterprise Continuum Accenture equivalent Application architecture & technical architecture workstreams in Accenture Delivery Methods (ADM) Business Integration Blueprint Standard Architecture Frameworks Industry specific assets like Architecture Reference model, ACS*, Navitaire, Accenture Platform Accelerator etc. Examples from the Accenture Delivery Suite (ADS) Numerous sample deliverables and assets in the Knowledge Exchange

Architecture Continuum Solutions Continuum

III. Resources

Notes: This comparison is deliberately incomplete and is only meant to aid in understanding the TOGAF
*Accenture Communication Solutions

Enterprise Architecture Framework and EA Planning Methodology


Accenture believes effective Enterprise Architecture is driven by Business and IT strategy. It links long-range strategy to day-to-day execution.
Enterprise Architecture Framework:

Methodology for EA Planning: 5


Deliver and Govern Iterate?

Create Roadmap

Refresh

3
Create Vision and Confirm Opportunities Diagnose Current Capabilities

4
Blueprint Future State

Launch Enterprise Architecture Initiative

Copyright 2008 Accenture All Rights Reserved.

30

1. Launch Enterprise Architecture Initiative


Activity
Confirm Scope, Approach and Objectives Understand Business Context, Strategies and Imperatives Develop/Confirm Technology Imperatives and Guiding Principles

Objectives: Capture the project scope, approach and objectives with project sponsor to develop the project approach. Identify key business opportunities and capability challenges. Define and prioritise key business imperatives. Define technology imperatives. Derive initial hypotheses on areas of pain and opportunities based on the technology imperatives.
Inputs: Statement of Work / Contract Corporate/Business Mission Statement Corporate/Business Vision Statement Corporate/Business Values Corporate/Business Strategy Business Imperatives IT Mission Statement IT Vision Statement IT Strategy Inventory of ongoing and planned IT initiatives Company Information High level facts Guiding Principles Known Issues Deliverables: Risk Mitigation Plan Stakeholder Goals, Expectations and Concerns Enterprise Architecture Project Approach Project Plan Prioritized Business Imperatives Technology Imperatives Technology Guiding Principles Value & Issue Hypotheses Responsible: Enterprise Architect

Participating: Business Architect Application Architect Information Architect Technical Architect Project Manager

Copyright 2008 Accenture All Rights Reserved.

31

2. Diagnose Current Capabilities


Activity
Prepare For Assessment Assess Current Capabilities Validate Capability and Environment Discovery

Objectives: Understand the assessment boundaries and availability of information. Agree upon data collection techniques, tools, templates and surveys with project sponsor (e.g., surveys will be used to analyse application health, etc.) Develop a point of view on the existing applications, information, technology, organization, financials and processes Gain consensus on assessment findings with project sponsors and stakeholders resolving all points of contention
Inputs: Ongoing IT initiatives Stakeholder Goals, Expectations and Concerns Enterprise Architecture Project Approach Application Inventory Existing Architecture documentation IT Organization Chart Existing Architecture documentation (Technology, Application, Process and Information) Copyright 2008 Accenture All Rights Reserved.
* If available for given industry

Deliverables: Enterprise Architecture Assessment Pack EA Project Approach Current Capability Assessment Job Aids: Technical Quality and Functional Quality Surveys Data Collection Templates Diagnostic Tools Data Collection Checklist

Responsible: Enterprise Architect Participating: Business Architect Application Architect Information Architect Technical Architect Project Manager

32

3. Create Vision and Confirm Opportunities


Activity
Create Vision Create Business Capability Blueprints Identify and Prioritize Opportunities Validate Opportunity Discovery

Objectives: Create a business capability blueprint that is a pictorial representation of the major future capabilities of the enterprise. Its design and organisation should be driven by an operating vision and the business and technology imperatives. It should be based on industry best practice and Accenture thought leadership. It will be a key to identify and prioritize opportunities for change. It will form the basis for the application and technology blueprints to be created at a later stage. Identify high-level opportunities for change that directs the enterprise towards its business goals, and that is aligned with the business capability blueprint. Prioritise the list of opportunities, and identify quick-wins. The prioritisation of opportunities will be the basis for creating the future roadmap and plan for value realization at a later stage. Validate the opportunities with the client sponsor and stakeholders. Inputs:
Industry Best Practices Accenture Thought Leadership Business Imperatives Technology Imperatives Technology Guiding Principles Current Capability Assessment
Copyright 2008 Accenture All Rights Reserved.

Deliverables:
Operating Vision Business Capability Blueprint Opportunity Summary Opportunity Definition Opportunity Prioritization Matrix Quick Win Opportunities

Responsible:
Enterprise Architect

Participating:
Business Analyst Application Architect Technical Architect Capability Lead/SME Industry Lead/SME Project Manager
33

4. Blueprint Future State


Activity
Summarize Blueprint Requirements

Develop Blueprints
Process Information Application Technology Validate Enterprise Architecture

Objectives: Comprehensively describe the EA model from multiple dimensions. Describe the key characteristics of each of those dimensions Understand the linkages between all the model elements Enable consistent development of systems and solution in line with business imperatives Validate and gain consensus on all blueprints with sponsors and stakeholders.
Deliverables:
Business Capability Blueprint Key Architecture Requirements Process Blueprint Information Blueprint Application Blueprint Technology Blueprints

Inputs:
Business Imperatives Technology Imperatives Technology Guiding Principles Opportunity Summary Current Capability Assessment Business Capability Blueprint

Responsible:
Enterprise Architect

Participating:
Business Architect Information Architect Application Architect Process Architect Technical Architect

Copyright 2008 Accenture All Rights Reserved.

34

Detailed Tasks Example


Activity Develop Blueprints
Process Summarize Blueprint Requirements Information Application Technology Validate Enterprise Architecture

Blueprint Future State

Develop Application Blueprints


Task
Identify and define applications Identify application building blocks Define application interactions & association Determine Application characteristics and styles Create application blueprint

Objectives: Describe the business application assets needed by the enterprise in support of its business imperatives and business capabilities Provide a structure and form to organise and integrate the application assets to deliver specific service Enable automation of business processes and organisational interactions with internal and external stakeholders Enable the organisation to review its portfolio of business application investments and identify new investment areas that would enable the attainment of its business objectives.
Copyright 2008 Accenture All Rights Reserved. 35

Task Detail Develop Application Blueprints


Develop Application Blueprints
Task
Identify and define applications Identify application building blocks Define application interactions & association Determine Application characteristics and styles Create application blueprint

Detailed Task Steps:


Determine Application characteristics and styles The purpose of this step to determine the characteristic, both functional and technical, and style (e.g. portal, web services, OLTP, batch, etc) of the application based on the capability requirements, building blocks and application interaction information that was identified in the previous steps. When determining the characteristic and style of an application, think about how it can meet the functional requirements of the business capability. Based on the functional characteristics, determine the technical characteristics of the application. Things to consider while going through this step are: a. What are the key technologies required to support the application? b. What are the key impact to the current architect as a result of introducing the new technology / application? c. Is the user base of the application global or local? If it is global, should application support multiple languages? d. Depending upon the user base of the application, should it have a thin client or a fat client? Or should the application be available from the internet to internal and external users? e. What is the anticipated life span of the application? f. Is it necessary for the application to be available 24 X 7 to its users? What are the operational hours for the application? g. How often is the data refreshed for the application? Is it batch processes or is it real-time OLTP? h. How does the application tie up to the databases and other data sources identified in the information blueprint? What is the information exchange format (e.g. flat file, XML, HTML, etc) i. Are Service Level Agreements required for the application?
Copyright 2008 Accenture All Rights Reserved. 36

5. Create Roadmap

Activity
Define and Integrate Opportunities into Initial Plan Develop Implementation Plans Validate Plans Finalize Business Case

Objectives: Develop roadmap or transition plan that defines the program necessary to implement the future state blueprints Derive a business case for the program and initiative to provide economic justification for all planned activities Create change management plans that will be required to startup, govern, and navigate the roadmap Validate and gain consensus on Roadmap Deliverables with sponsors and stakeholders Transfer ownership of blueprints and roadmap to program managers that will drive the ensuing implementation

Inputs:
Business Capability Blueprint Process Blueprint Information Blueprint Technology Blueprints Application Blueprints Opportunity Summary

Deliverables:
Program Roadmap Project List Project Plan Business Case Communication Plan

Responsible:
Project Manager

Participating:
Enterprise Architect Business Architect Process Architect Information Architect Application Architect Technical Architect
37

Copyright 2008 Accenture All Rights Reserved.

Agenda

Overview of EA Overview of TOGAF TOGAF v8 Value of TOGAF Comparison with ADM TOGAF v9

Copyright 2008 Accenture All Rights Reserved.

Plans for TOGAF Version 9

Six domains:

Business Context the enterprise context for EA work Architecture Development development of an enterprise architecture. Business Transformation Planning use of enterprise architecture to drive a program of change throughout the enterprise Architecture Deployment implementation of the enterprise architecture and the Transformation Plan, via the various projects in the Transformation Program. Architecture Value Realisation use of enterprise architecture during normal operational services to realise the business benefits that were envisioned when the architecture was developed. Architecture Management management and governance of the enterprise architecture, and the change in scope of the overall enterprise as it evolves over time.

ADM Mapping to TOGAF 9

Вам также может понравиться