TBI and TOGAF Reconciliation Global EAI Summit 2004 TBI and TOGAF Reconciliation Terence Blevins, VP and CIO 10:10 am/Monday May 24th DC Coleman Room

What Does Reconciliation Mean? A reconciling or being reconciled Reconcile To bring together again in love or friendship To induce to accept something disagreeable To reach a compromise agreement about To make or show to be consistent We’ll focus on 4 today – we think that TOGAF and TBI are consistent

Position TBI and TOGAF ADM are both great candidates for a Global Integration Framework Why TOGAF ADM Any large effort requires enterprise architecture Doing enterprise architecture requires an architecture development method An enterprise architecture method will include consideration of integration given the appropriate situation – in most cases An open architecture method is less likely to create new integration challenges Why TBI Any large project requires integration implementation plans TBI is a proven method for dealing with integration details What can be done downstream… harden the points of interaction between TOGAF ADM and TBI to ensure interoperability

A Definition of Enterprise Architecture The structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time Enterprise architecture Covers the components in an enterprise organizations, processes, humans, data, applications, technology etc. Enterprise means enterprise-wide, not everything in the enterprise … An enterprise architecture effort must address a specific problem, not all problems at once!

The Role of Architecture “Architecture is fast becoming one of the main instruments for improving Business IT Alignment.” “It is time to broaden our view and build systems that last and that keep delivering value to the business. Business and IT Architecture play a pivotal role in achieving this goal..“ Raymond Slot M.Sc, MBA, Principal Consultant and Enterprise Architect for Cap Gemini Ernst & Young

Pressures on IT … Align Information Technology to Business Understand where change is needed Align Information Technology to Business Increase accountability to improve cost performance Drive accountability of spending Ensure network availability Ensure security Drive standardization What direction is appropriate How do we keep alignment What process are in most need of support How do we impact what is being deployed How do we ensure information security Create Alignment How do we incorporate a new system How do we ensure that the technical components are fit How do we pick the right solutions and ensure support for stds

Other Pressures … Understand where change is needed Effective business process to reconcile and adequately govern Short term spending Short product life cycles Rapid technological change Sub-optimal spending Dealing with “hidden” costs Sub-optimal vendor management What direction is appropriate How do we keep alignment What process are in most need of support How do we impact what is being deployed How do we ensure information security Create Alignment How do we incorporate a new system How do we ensure that the technical components are fit How do we pick the right solutions and ensure support for stds

And the Impact? Proliferation of point solutions Understand where change is needed Proliferation of point solutions High costs of integration Not leveraging standards Few discount deals Higher support costs Less responsive support High costs and long lead times to deliver security Higher risk of security Disconnected decisions Lack of effectiveness What direction is appropriate How do we keep alignment What process are in most need of support How do we impact what is being deployed How do we ensure information security Create Alignment How do we incorporate a new system How do we ensure that the technical components are fit How do we pick the right solutions and ensure support for stds

TOGAF 8 ADM Designed to address key issues! A Architecture Vision H Architecture Change Management G Implementation Governance C Information System Architectures Requirements B Business Architecture E Opportunities and Solutions F Migration Planning Prelim: Framework and Principles D Technology Architecture Designed to address key issues! Lowering costs Control costs Delivering new value Better operational efficiency of business Better understand impact of change Holistic requirements management Lower risk Faster decisions The journey provides benefits at each step! http://www.opengroup.org/architecture/togaf8/index8.htm

TBI Deliverables Map DEFINE DESIGN BUILD DEPLOY Business Analyst Process Analysis Tech Req Document Business Analyst Software QA Plan Req WT report Unit Test Integration Results Test Quality Manager Results Logical Design WT Integration Integration System Test Cases Test Cases System Report WT Report Test Result Error Logical Integration Architect. Handling TDB Architect / Designer Design Design Document Guide Code Simulation Reviews Document Unit Test Source Developer Cases Code Lessons Learned FDR Rpt FDR Rpt FDR Rpt FDR Rpt Governance Repository Repository Repository CTQ Signoff Repository

TOGAF ADM Deliverables Map PD DP TP EC RFAW EFW BD RFC EC EC RFAW SOW IGS EC SD AP RFAW RFAW SOW TISA BD RFAW TD BS RFAW BS SOW TISA TTA AP RFAW SOW RFC BA2 EC AP BS BA2 BA2 I I I I I I I I I I Prel Phase Phase A Phase B Phase C Phase D Phase E Phase F Phase G Phase H Reqs Mgmt O O O O O O O O O O BD BD BD IA TP IA IA AC RFAW SRS FWD SOW SOW TISA TTA IA AP BS BA2 BA2 BA1 AP External Input BD:Business Data EFW:External Frameworks IGS:IT Govern Strategy PD:Product Definitions RFC:Req for Changes SD:Standards Devs TD:Tech Devs Internal Input AP:Arch Principles FRAW:Req for Arch Work EC:Enterprise Continuum DP:Data Principles TP:Technical Principles ABL:Application Baseline DBL:Data Baseline Output BD:Business Data FWD:Framework Definition AP:Arch Principles BS:Business Scenario BA:Business Architecture SOW:Statement Of Work TISA:Target IS Architecture TTA:Target Tech Arch IA:Impact Analysis AC:Architecture Contract SRS:Structured Req Statement

Intersections at… DEFINE DESIGN BUILD DEPLOY Business Process Analysis Tech Req Document Business Analyst Software QA Plan Req WT report Unit Test Integration Results Test Quality Manager Results Logical Design WT Integration Integration System Test Cases System Report Test Cases WT Report Test Result Error Logical Integration Architect. Handling TDB Architect / Designer Design Design Document Guide Code Simulation Reviews Document Unit Test Source Developer Cases Code Lessons Learned FDR Rpt FDR Rpt FDR Rpt FDR Rpt Governance Repository Repository Repository CTQ Signoff Repository http://www.opengroup.org/architecture/togaf8/index8.htm

TOGAF ADM Feeds to TBI External Input Internal Input Output Prel Phase PD DP TP EC RFAW EFW BD RFC EC EC RFAW SOW IGS EC SD AP RFAW RFAW SOW TISA BD RFAW TD BS RFAW BS SOW TISA TTA AP RFAW SOW RFC BA2 EC AP BS BA2 BA2 I I I I I I I I I I Prel Phase Phase A Phase B Phase C Phase D Phase E Phase F Phase G Phase H Reqs Mgmt O O O O O O O O O O BD BD BD IA TP IA IA AC RFAW SRS FWD SOW SOW TISA TTA IA AP BS BA2 BA2 BA1 AP External Input BD:Business Data EFW:External Frameworks IGS:IT Govern Strategy PD:Product Definitions RFC:Req for Changes SD:Standards Devs TD:Tech Devs Internal Input AP:Arch Principles FRAW:Req for Arch Work EC:Enterprise Continuum DP:Data Principles TP:Technical Principles ABL:Application Baseline DBL:Data Baseline Output BD:Business Data FWD:Framework Definition AP:Arch Principles BS:Business Scenario BA:Business Architecture SOW:Statement Of Work TISA:Target IS Architecture TTA:Target Tech Arch IA:Impact Analysis AC:Architecture Contract SRS:Structured Req Statement

Summary TBI and TOGAF ADM are both great for GIF A Architecture Vision H Architecture Change Management G Implementation Governance C Information System Architectures Requirements B Business Architecture E Opportunities and Solutions F Migration Planning Prelim: Framework and Principles D Technology Architecture TBI and TOGAF ADM are both great for GIF Any large effort requires enterprise architecture and doing so requires an open ADM Enterprise architecture method includes consideration of integration An open architecture method is less likely to create new integration challenges Any large project requires integration implementation plans TBI is a proven method for dealing with integration details We can harden the points of interaction between TOGAF ADM and TBI to ensure interoperability for GIF Leverage will get us all to the top! http://www.opengroup.org/architecture/togaf8/index8.htm

Contact Details Terence Blevins VP and CIO Mobile +1 650 888 6950 t.blevins@opengroup.org 44 Montgomery Street Suite 960 San Francisco, CA 94104 USA Tel +1 415 374 8280 ext. 231 Fax 413-683-4199 www.opengroup.org TOGAF 8 represents an industry consensus framework and method for Enterprise Architecture that is available for use internally by any organization around the world - members and non-members of The Open Group alike - under a free, perpetual license. http://www.opengroup.org/architecture/togaf8/index8.htm

Backups

Presentation Outline Background Why Enterprise Architecture is Important TOGAF and TOGAF History TOGAF and TBI Summary

Integration Is a Big Issue Gartner Dataquest forecasts Worldwide End-User IT Spending will grow from $2.7 US trillion in 2001 to greater than $3.0 US trillion in 2002 and reach $3.4 US trillion in 2003 The worldwide integration services market is expected to see a 25% compounded annual growth rate between 2001 and 2005 to $116.5 US billion, according to IDC CIO magazine survey says companies spend over 35% on integrating systems and processes

Presentation Outline Background Why Enterprise Architecture is Important TOGAF and TOGAF History TOGAF and TBI Summary

CIOs Have Issues in Common In general there is a trend Demands on IT increasing IT budgets are decreasing or flat CIOs must do more for less, so Look for leverage Outsourcing Off shore development Open source Collaborative development Reusable building blocks… IT demand Ever widening gap! IT budget - run rates are declining!

Presentation Outline Background Why Enterprise Architecture is Important TOGAF and TOGAF History TOGAF and TBI Summary

TOGAF 8 Scope TOGAF covers the development of four related types of architecture: Business architecture Data or information architecture Application architecture Technology architecture TOGAF 8 “Enterprise Edition” TOGAF 7 “Technical Edition” First lets consider the scope of TOGAF 8. TOGAF 8 covers the development of four related types of architecture: Business architecture covering business goals, strategies, organization, processes, locations etc, Data or information architecture covering the lifeblood of an organization, Application architecture where data gets turned into information, and Technology architecture addressing the infrastructure required to ensure that information flows and applications run TOGAF version 7 was focused on technology architecture and introduced the beginnings of business architecture. TOGAF 8 brought in data, information, and application architecture that resulted in the “Enterprise Edition.” So what is TOGAF made of? TOGAF 7 “Technical Edition”

TOGAF 8 – Enterprise Edition Target Enterprise Architectures Architecture Development Method Enterprise Continuum TOGAF 8 is an architecture framework called The Open Group Architecture Framework. It enables you to design, evaluate, and build the right target enterprise architecture for your organization. TOGAF 8 consists of three main parts that will be described in more detail in subsequent charts: The TOGAF Architecture Development Method (ADM), explains how to derive an organization-specific enterprise architecture that addresses business requirements. The Enterprise Continuum, is a "virtual repository" of architecture assets - models, patterns, architecture descriptions, etc… that exist both within the enterprise and in the IT industry at large. The TOGAF Resource Base, is a set of resources - guidelines, templates, background information, etc…. to help the architect in the use of the ADM. The key to TOGAF is the TOGAF Architecture Development Method (ADM) - a reliable, proven method for developing an IT enterprise architecture that meets the needs of your business. TOGAF provides a common sense, practical, prudent, and effective method of developing an enterprise architecture. Let me explain each of these in a little more detail. Resource Base

Enterprise ADM An iterative method Each iteration = new decisions: A Architecture Vision H Architecture Change Management G Implementation Governance C Information System Architectures Requirements B Business Architecture E Opportunities and Solutions F Migration Planning Prelim: Framework and Principles D Technology Architecture An iterative method Each iteration = new decisions: Enterprise coverage Level of detail Time period Architecture asset re-use Decisions based on: Competence / resource availability Value accruing to the enterprise. The Architecture Development Method is an iterative method where each iteration produces new decisions that relate to: The level of enterprise coverage for an architecture effort, the level of detail required to address the needs of the project, the time period that should be considered, and the architecture assets that can be re-used throughout the process – be those assets from past iterations of TOGAF or be they re-usable assets from other frameworks, other systems, or other industry models. The decisions that are made are based upon competence, resource availability, appropriateness of resources, and the value accruing to the enterprise. The TOGAF Architecture Development Method (ADM), provides: A reliable, proven way of developing the architecture, Architecture views which enable the architect to ensure that a complex set of requirements are adequately addressed, Linkages to practical case studies, and Guidelines on tools for architecture development

The Enterprise Continuum Technology Architecture Continuum Foundation Architectures Common Systems Architectures Industry Architectures Organisation Architectures Guides & Supports Guides & Supports Guides & Supports Guides & Supports The "Enterprise Continuum" is a phrase that describes the combination of two complementary concepts: the "Architecture Continuum" and the "Solutions Continuum." The Architecture Continuum offers a consistent way to define and understand the generic rules, representations and relationships in an information system. The Architecture Continuum represents a structuring of re-usable architecture assets. The Architecture Continuum shows the relationships among foundational frameworks such as The Open Group’s Technical Reference Model, common systems architectures such as The Open Group’s Integrated Information Infrastructure Reference Model, industry architectures, and enterprise architectures. The Architecture Continuum is a useful tool to discover commonality and eliminate unnecessary redundancy. The Solutions Continuum provides a consistent way to describe and understand the implementation of the Architecture Continuum. The Solutions Continuum defines what is available in the organizational environment as re-usable solutions building blocks. The solutions are the results of agreements, between customers and business partners, that implement the rules and relationships defined in the architecture space. The Solutions Continuum addresses the commonalties and differences among the products, systems and services of implemented systems. Products & Services Systems Solutions Industry Solutions Organisation Solutions Solutions Continuum

Resource Base Architecture Compliance Reviews Architecture Principles Architecture Views Architecture Tool evaluation criteria Business Scenarios Architecture Governance Case Studies Comparisons with other Frameworks Mapping to Zachman Framework The last main part of TOGAF is the Resource Base… some of the key resources included in the resource base are: Architecture compliance review guidance Re-usable architecture principles with rationale Re-usable architecture views Architecture tool evaluation criteria to help you pick a tool for your enterprise Business Scenarios, a method that helps develop the business picture Architecture Governance guidance to help you set up a structure for governing architecture efforts Additional resources are also available.

TOGAF Origins A customer initiative A framework, not an architecture A framework for developing architectures to meet different business needs Not a “one-size-fits-all” architecture Originally based on Technical Architectural Framework for Information Management (TAFIM) from US Department of Defense It is important to note that TOGAF started out as a customer initiative in 1994. Customers of The Open Group requested that we put together a framework to understand the various standards and how they fit together resulting in a Technical Reference Model… Also they expected we need a way to help customers use those standards resulting in an Architecture Development Method since one Technical Reference Model would not fit all cases. This was an architecture framework effort, not just an architecture of standards. A broad request for an initial starting point was sent out in 1995 resulting in the selection of the US Department of Defense Technical Architectural Framework for Information Management, called TAFIM, as the starting point. So TOGAF was originally founded on TAFIM. However as you will see it has evolved significantly since 1995.

TOGAF Development Proof of need Proof of concept Proof of application 1994: Requirement 1995: TOGAF Version 1 1996: TOGAF Version 2 1997: TOGAF Version 3 1998: TOGAF Version 4 1999: TOGAF Version 5 2000: TOGAF Version 6 2001: TOGAF Version 7 2002: TOGAF Version 8 Proof of need Proof of concept Proof of application Relevance to practical architectures (building blocks) Enterprise Continuum (TOGAF in context) Business Scenarios (architecture requirements) Architecture views - IEEE 1471 Architecture Principles; Compliance Reviews Extension for Enterprise Architecture So since 1995 you see yearly releases of TOGAF where industry experts have put in time and content to build up TOGAF based on real-world practical architecture experience. I have been lucky to have been involved since 1996 and have seen TOGAF grow to become a valuable asset,… a valuable business management tool.