75265149 ea session 04 overview of togaf
TRANSCRIPT
1
An Introduction to TOGAF
An Overview TOGAF (The Open Group Architecture Framework)
September 2008 – <onSite in Rome>
Copyright © 2008 Accenture All Rights Reserved.
Agenda
Overview of EA
Overview of TOGAF
TOGAF v8
Value of TOGAF
Comparison with ADM
TOGAF v9
Overview of Enterprise Architecture
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
Fundamental organisation of something, embodied in
Its components,
their relationships to each other and the environment,
And the principles governing its design and evolution
•More extended enterprises•More co-operative IT operations•Greater publicity to failures•Increase in litigation•Audit requirements
Enterprise: Architecture:
Drivers:
Laws and regulations• Clinger-Cohen Act (US Information Technology Management Reform Act 1996)• EU Directives on the Award of Public Contracts• Sarbanes-Oxley
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.
Why Enterprise Architecture?
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
Investment in Information Technology
• Focused on system maintenance
• Tactical developments rather than a strategic plan
Individual Capability Blueprints
Enterprise view of
capabilities required to
execute strategy
A good Enterprise Architecture enables you to achieve the right balance betweenIT efficiency and business innovation.
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
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
Governance looks at the way in which decisions are made, who is responsible for them, who is involved and who is accountable?
Governance:
• 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
Benefits:
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.
Architecture Framework
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.
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.
Copyright © 2008 Accenture All Rights Reserved.
Agenda
Overview of EA
Overview of TOGAF
TOGAF v8
Value of TOGAF
Comparison with ADM
TOGAF v9
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.
1. The TOGAF Architecture Development Method (ADM): explains how to derive an organisation-specific Enterprise Architecture that addresses business requirements.
2. The Enterprise Continuum: a ‘‘virtual repository’’ of all the architecture assets: models, patterns, architecture descriptions, etc.
3. The TOGAF Resource Base: a set of resources: guidelines, templates,
background information to help the architect in the use of the ADM.
TOGAF consists of 3 main parts:
Enterprise Continuum
Guides and supports
Guides and supports
Guides and supports
Guides and supports
Enterprise Continuum = Architecture Continuum + Solution Continuum
The Enterprise Continuum provides a framework and context for the leveraging of relevant architecture assets in executing the ADM.
Reference Models
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 application platform
Focuses on the flow of information at theapplication level
Reference Models:
Technical Reference Model:
Integrated Information Infrastructure Reference Model:
Copyright © 2008 Accenture All Rights Reserved.
Agenda
Overview of EA
Overview of TOGAF
TOGAF v8
Value of TOGAF
Comparison with ADM
TOGAF v9
TOGAF 8 Scope and Goals
TOGAF 8 scope covers the development of four related types of architecture:
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.
TOGAF 8 Goals:
The Enterprise Architecture Development Method
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 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.
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
Business Architecture
Develop architectures at 3 levels
Information Systems Architecture
Systems supporting the processes
Technology Architecture
Technology supporting the organisation
Requirements Management
Every stage of the project should be based on and validate business requirements
Opportunities and Solutions
Identify major implementation projects
Migration Planning
Analyse cost benefits and risk. Produce implementation roadmap
Implementation Governance
Ensure that the implementation project conforms to the architecture
Architecture Change Management
Ensure that the architecture responds to the needs of the organisation
Frameworks and Principles
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
Objectives:
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
Outputs:
To ensure that everyone who will be involved in, or benefit from, this approach is committed to the success of the architectural process
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
Initiates one iteration of the architecture process
• Sets scope, constraints, expectations for this project
• Required at the start of every architecture cycle
Validates business context
Creates Statement of Architecture work
Objectives:
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
Steps:
Approved Statement of Architecture Work
Refined statements of business goals and strategic drivers
Architecture principles
Architecture Vision
Outputs:
The Architecture Vision is essentially the architect’s ‘‘elevator pitch’’ — the key opportunity to sell the benefits of the proposed development to the decision-makers within the enterprise.
B) 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 it’s business goals
• Organisation structure
• Business goals and objectives
• Business functions
• Business Services
• Business processes
• Business roles
• Correlation of organisation and functions.
• Confirm context
• Define baseline
• Define target
• Views are important
• Validate
• Requirements
• Concerns
• Gap analysis
• Produce report
Business Architecture:
Outputs:Steps:
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.
C) Information Systems Architecture
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
Shows how the IT systems meets the business goals of the enterprise
It is usually necessary to address both
• Not always the case, depending on project scope and constraints
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
Objectives:
Data or Applications First?
• Statement of Architecture Work
• Baseline & Target Data Architecture
• Baseline & Target Applications Architecture
• Data and Application Architecture views
Outputs:
• Data Architecture
• Applications Architecture
Steps:
D) Technology Architecture
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
Developing the Technology Architecture
Objectives:
• Develop Baseline Technology Architecture Description
• Develop Target Technology Architecture
Steps:
• 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
Outputs:
A Technology Architecture that will for m the basis of the following implementation work.
E) Opportunities and Solutions
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
Objectives:
• Identify Key Business Drivers
• Review Gap Analysis
• Brainstorm Technical Requirements
• Brainstorm Co-existence and Interoperability
• Brainstorm Co-existence and Interoperability
Steps:
• Implementation and migration strategy
• High-level Implementation Plan
• Impact Analysis
Outputs:
Identifies the parameters of change, the major phases along the way, and the top-level projects to be undertaken in moving from the current environment to the target
F) Migration Approach
Cost/benefit analysis
Risk assessment
Technology road-map
Objectives:
• 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
Steps:
• Impact Analysis
• Detailed Implementation Plan and Migration Plan
• Including Architecture Implementation Contract, if appropriate)
Outputs:
The objective of the Migration Approach phase is to sort the various implementation projects into priority order.
Reduction of costs
Consolidation of services
Ability to handle change
A goal to have a minimum of
‘‘interim’’ solutions
Key business drivers to be addressed that will also tend to dictate the sequence of implementation, such as:
G) Implementation Governance
Defines architecture constraints on implementation projects
• Architecture contract
Monitors implementation work for conformance
Objectives:
• Formulate Project Recommendation
• Document Architecture Contract
• Review Ongoing Implementation Governance and Architecture Compliance
Steps:
• Impact Analysis
• Architecture Contract
• The architecture-compliant implemented system
Outputs:
All the information for successful management of the various implementationprojects is brought together.
H) Architecture Change Management
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
Objectives:
• Monitor Technology Changes
• Monitor Business Changes
• Assess Changes and Development of Position to Act
• Arrange Meeting of Architecture Board (or other governing council)
Steps:
• Architecture updates
• Changes to architecture framework and principles
• New Request for Architecture Work
Outputs:
This phase establishes an Architecture Change Management process for the new Enterprise Architecture baseline.
Copyright © 2008 Accenture All Rights Reserved.
Agenda
Overview of EA
Overview of TOGAF
TOGAF v8
Value of TOGAF
Comparison with ADM
TOGAF v9
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
Copyright © 2008 Accenture All Rights Reserved.
Agenda
Overview of EA
Overview of TOGAF
TOGAF v8
Value of TOGAF
Comparison with ADM
TOGAF v9
Accenture has a number of frameworks for architecture and methods that relate to the TOGAF
TOGAF Accenture equivalent
I. Architecture development method Application architecture & technical architecture workstreams in Accenture Delivery Methods (ADM)
II. Enterprise Continuum
• Architecture Continuum
• Solutions Continuum
Business Integration Blueprint
Standard Architecture Frameworks
Industry specific assets like Architecture Reference model, ACS*, Navitaire, Accenture Platform Accelerator etc.
III. Resources Examples from the Accenture Delivery Suite (ADS)
Numerous sample deliverables and assets in the Knowledge Exchange
*Accenture Communication Solutions
Notes: This comparison is deliberately incomplete and is only meant to aid in understanding 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.
30Copyright © 2008 Accenture All Rights Reserved.
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.
DiagnoseCurrent
Capabilities
Create Visionand Confirm
Opportunities
Iterate?
Refresh
CreateRoadmap
Launch EnterpriseArchitecture
Initiative
Deliver and Govern
BlueprintFutureState
1
2
34
5
Enterprise Architecture Framework:
Methodology for EA Planning:
31Copyright © 2008 Accenture All Rights Reserved.
1. Launch Enterprise Architecture Initiative
• 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.
Objectives:
• 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
• Enterprise Architect
• Business Architect• Application Architect• Information Architect• Technical Architect• Project Manager
• Statement of Work / Contract
• Corporate/Business Mission Statement
• Corporate/Business Vision Statement
• Corporate/Business Values
• Corporate/Business Strategy
• Business Imperatives• IT Mission Statement
Activity
Confirm Scope,Approach
and Objectives
UnderstandBusiness Context,
Strategies andImperatives
Develop/ConfirmTechnology
Imperatives andGuiding Principles
Participating:
Inputs: Deliverables: Responsible:
• IT Vision Statement• IT Strategy• Inventory of
ongoing and planned IT initiatives
• Company Information – High level facts
• Guiding Principles• Known Issues
32Copyright © 2008 Accenture All Rights Reserved.
• 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
Objectives:
• Enterprise Architect
• Business Architect• Application Architect• Information Architect• Technical Architect• Project Manager
• 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)
• Enterprise Architecture Assessment Pack
• EA Project Approach• Current Capability Assessment
* If available for given industry
Activity
Participating:
Inputs: Deliverables: Responsible:
Prepare For
Assessment
ValidateCapability andEnvironment
Discovery
AssessCurrent
Capabilities
• Technical Quality and Functional Quality Surveys
• Data Collection Templates• Diagnostic Tools• Data Collection Checklist
Job Aids:
2. Diagnose Current Capabilities
33Copyright © 2008 Accenture All Rights Reserved.
• Create a business capability blueprint that is a pictorial representation of the major future capabilities of the enterprise. It’s 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.
• Enterprise Architect• Operating Vision• Business Capability Blueprint• Opportunity Summary
• Opportunity Definition• Opportunity Prioritization
Matrix• Quick Win Opportunities
• Business Analyst• Application Architect• Technical Architect• Capability Lead/SME• Industry Lead/SME• Project Manager
• Industry Best Practices• Accenture Thought
Leadership• Business Imperatives• Technology Imperatives• Technology Guiding
Principles• Current Capability
Assessment
Objectives:
Activity
Participating:
Inputs: Deliverables: Responsible:
Create Vision
ValidateOpportunityDiscovery
Identify andPrioritize
Opportunities
Create Business CapabilityBlueprints
3. Create Vision and Confirm Opportunities
34Copyright © 2008 Accenture All Rights Reserved.
• Business Architect• Information Architect• Application Architect• Process Architect• Technical Architect
• 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.
Participating:
Objectives:
• Business Capability Blueprint• Key Architecture Requirements• Process Blueprint• Information Blueprint• Application Blueprint• Technology Blueprints
• Enterprise Architect• Business Imperatives• Technology Imperatives• Technology Guiding Principles• Opportunity Summary• Current Capability Assessment• Business Capability Blueprint
Inputs: Deliverables: Responsible:
SummarizeBlueprint
Requirements
ValidateEnterprise
Architecture
Develop Blueprints
Information
Application
Technology
Process
Activity
4. Blueprint Future State
35Copyright © 2008 Accenture All Rights Reserved.
Detailed Tasks Example
SummarizeBlueprint
Requirements
ValidateEnterprise
Architecture
Develop Blueprints
Information
Application
Technology
Process
• 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.
Objectives:
Identify application
building blocks
Identify and define
applications
Define application interactions
& association
Determine Application
characteristics and styles
Create application blueprint
Activity
Develop Application Blueprints
Blueprint Future State
Task
36Copyright © 2008 Accenture All Rights Reserved.
Task Detail – Develop Application Blueprints
Identify application
building blocks
Identify and define
applications
Define application interactions
& association
Determine Application
characteristics and styles
Create application blueprint
Develop Application Blueprints
►Determine Application characteristics and stylesThe 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?
Detailed Task Steps:
Task
37Copyright © 2008 Accenture All Rights Reserved.
• 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
Objectives:
• Program Roadmap• Project List• Project Plan• Business Case• Communication Plan
• Business Capability Blueprint• Process Blueprint• Information Blueprint• Technology Blueprints• Application Blueprints• Opportunity Summary
Inputs: Deliverables:
Define andIntegrate
Opportunitiesinto Initial Plan
ValidatePlans
Develop Implementation Plans
Finalize Business Case
• Enterprise Architect• Business Architect• Process Architect• Information Architect• Application Architect• Technical Architect
• Project Manager
Participating:
Responsible:
5. Create Roadmap
Activity
Copyright © 2008 Accenture All Rights Reserved.
Agenda
Overview of EA
Overview of TOGAF
TOGAF v8
Value of TOGAF
Comparison with ADM
TOGAF v9
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