1. 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

2. 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

3. 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

4. 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!

5. 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

6. 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

7. 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

8. 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

9. 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!

10. 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

11. TOGAF ADM Deliverables MapPD 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

12. 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

13. TOGAF ADM Feeds to TBI External Input Internal Input Output Prel PhasePD 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

14. 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!

15. Contact Details
Terence Blevins
VP and CIO
Mobile
44 Montgomery Street
Suite 960
San Francisco, CA
94104 USA
Tel ext. 231
Fax
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.

16. Backups

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

18. 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

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

20. 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!

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

22. 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”

23. 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

24. 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

25. 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

26. 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.

27. 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 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.

28. 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.