Using TOGAF beyond IT

the futures of business

10 Apr 2023 (c) Tom Graves / Tetradian 2009 1

Using TOGAF beyond ITTom Graves, Tetradian Consultingin association with White Knight Management

TOGAF Hong Kong, October [email protected] / www.tetradian.com

the futures of business 10 Apr 2023 (c) Tom Graves / Tetradian 2009 2

The TOGAF ADM: an old friend...

• Designed for IT-architecture• Focus is business/IT alignment

RequirementsManagement

G.Governance

and Compliance

E.Opportunities

andSolutions

C.Develop

Data / Apps Architecture

A.ArchitectureScope and Purpose

Preliminary:Framework,

Principles and Core Content

H.Architecture

Change Management

B.Develop

Business Architecture

D.Develop

TechnologyArchitecture

F.Migration Planning

BUT...• Increasing

consensus that EA is more than IT

• EA as ‘the architecture of the enterprise’

SO...• How do we use

TOGAF beyond IT?


Enterprise-architecture beyond ITSome examples where EA must extend beyond

IT:• Telecoms

– emphasis on market; technology is more than IT

• Logistics– emphasis on ‘things’; manual/machine-based processes

• Engineering research– emphasis on interpretation; long info lifecycles (20yrs+)

• Government social-services– emphasis on people (IT as background-support only);

very long info lifecycles; narrative knowledge

Ultimately, every enterprise extends beyond IT



The purpose, and the aim...-- THE BUSINESS ROLE OF ENTERPRISE ARCHITECTURE --

• Enterprise architecture acts as custodian for a body of knowledge on structure and purpose:– “what structure changes do we need for this strategy?”– “what strategy can we support with this structure?”– “what risks, opportunities does this strategy create?”

• Provides bridge between strategy and PMO etc

-- A PRACTICAL AIM --

• Make TOGAF and ADM usable for architecture at any scope, any complexity, any duration, in any and every part of the enterprise


Two levels of extension...

Part 1: Expand the scope• requires only minor refocus of Phases B, C,

D• no structural change to ADM

– limitation: like TOGAF 9, can only handle a subset of architecture needs

Part 2: Extend the capability• includes iterations and their governance• consistent at every scope and level• does require restructure of ADM Phases A-

D10 Apr 2023 (c) Tom Graves / Tetradian 2009 5


All needed is already in TOGAF 9...Required TOGAF sections include:• Architecture Development Method (Chs 6-17)• Adapting the ADM (Ch 5.3)• Applying the ADM at different enterprise

levels (Ch 20)• Capability-based planning (Ch 32)• Architecture maturity models (Ch 51)• Applying iteration to the ADM (Ch 19)• Architecture governance (Ch 50)...though we may need to use some in new

ways



Part 1: Expand the scope



An unfortunate kludge...

Classic scope of IT-based ‘enterprise architecture’


G.Governance

and Compliance

E.Opportunities

andSolutions

C.Develop





H.Architecture

Change Management

B.Develop


D.Develop



BusinessArchitecture

Data Architecture

ApplicationsArchitecture


IT(3% of enterprise)

Everything not-IT ?(97% of enterprise)


Scope of IT in enterprise context

Whole-of-enterprise scope


Data Architecture



IT is only a small subset (not even all of Information)


InformationIntegration-Architecture

Machine / AssetIntegration-Architecture

Information-ProcessDetail-Architecture

Manual-ProcessDetail-Architecture

Machine-ProcessDetail-Architecture

PeopleIntegration-Architecture

– three layers: Business, Integration (Common), Detail– three columns: People, Information, physical ‘Things’

IT domain(typical)


Scope of enterprise architecture

• Big-picture: vision, strategy, overview, ‘business of business’• Common: interfaces etc common to all implementations• Detail: implementation-specific, context-specificAligns well with service-oriented architecture for the whole enterprise


Data Architecture



Big-picture / BusinessZachman rows 0-2

Common / ConnectionZachman rows 2-3

Design / DetailZachman rows 4-6

[People] [Things][Information]


A simple extension of scope...

Change the labels / focus for Phases B, C, D


G.Governance

and Compliance

E.Opportunities

andSolutions

C.Develop





H.Architecture

Change Management

B.Develop


D.Develop




Data Architecture



Phase B Big-picture / Business

Phase CCommon / Connection

Phase DDesign / Detail

C.Develop

Common / Connection Architecture

B.Develop

Big-Picture / Business

Architecture

D.Develop

Detail-levelArchitecture

Repositories for Architectures / Issues / Risks /

Requirements etc

G.Governance

and Compliance

E.Opportunities

andSolutions

A.Architecture

Iteration Scope and Purpose



H.Architecture

Change Management

F.Plan

Implementation


A richer architectural ‘stack’


Adapted from S-EA-T (www.s-ea-t.com) free enterprise-architecture toolset

Use extended scope to develop a more business-oriented view of the usual IT ‘stack’ of architectures

Identify features common to all implementations – IT-based, manual, machine-based etc


Example: Business Operating Model


Screenshot from free S-EA-T toolset (www.s-ea-t.com)


Expand the scope - summaryProblem:• TOGAF Phases B-D too IT-centric for whole-EASolution:• refocus Phase B as ‘Big-picture’ (Zachman 0-

2)• refocus Phase C as ‘Common’ (Zachman 2-4)• refocus Phase D as ‘Detail’ (Zachman 4-6)• shift to stronger business-orientation• may assess information, people, ‘things’ etc• requires no structural change to ADM



Part 2: Extend the capability



Need for a more generic process • Various attempts

made to create a more generic framework– most are still IT-centric– example here is from

Oracle Enterprise Architecture Framework

• Would be better to re-use what we already have in TOGAF 9


(http://www.oracle.com/technology/architect/entarch/pdf/oadp_whitepaper.pdf)


Use the TOGAF maturity-model

Step 1: Know your business(focus on business-purpose)

Step 2: Clean up the mess(horizontal assessment)

Step 3: Strategy and stuff(top-down assessment)

Step 4: Work with the real world(bottom-up assessment)

Step 5: Pull together(spiral-out assessment)

Maintainthe dialogue

Prepare and maintain foundations for architecture

(Initialpilot test)







(Start EAdev’ment)


(Initialpilot test)








Level 1:Ad-hoc


(Initialpilot test)








Level 1:Ad-hoc

Level 2:Repeatable


(Initialpilot test)








Level 1:Ad-hoc

Level 2:Repeatable

Level 3:Defined


(Initialpilot test)








Level 1:Ad-hoc

Level 2:Repeatable

Level 3:Defined

Level 4:Managed


(Initialpilot test)








Level 1:Ad-hoc

Level 2:Repeatable

Level 3:Defined

Level 4:Managed

Level 5:Optimised


(Initialpilot test)


TOGAF scope in maturity-model








(Initialpilot test)









(Initialpilot test)








Level 1:Ad-hoc


(Initialpilot test)








Level 1:Ad-hoc

Level 2:Repeatable


(Initialpilot test)








Level 1:Ad-hoc

Level 2:Repeatable

Level 3:Defined


(Initialpilot test)








Level 1:Ad-hoc

Level 2:Repeatable

Level 3:Defined

Level 4:Managed


(Initialpilot test)








Level 1:Ad-hoc

Level 2:Repeatable

Level 3:Defined

Level 4:Managed

Level 5:Optimised


(Initialpilot test)

Main emphasis of TOGAF,for IT-architecture only


TOGAF assumes top-down sequence


G.Governance

and Compliance

E.Opportunities

andSolutions

C.Develop





H.Architecture

Change Management

B.Develop


D.Develop


F.Migration Planning ...this can easily become a

governance nightmare...

Phases B-D each include:

• predefined scope(s)

• ‘as-is’architecture

• ‘to-be’ architecture

• gap-analysis

Preliminary Phase is a special type of cycle, with its own specific governance etc


Adapt to support any scope

A: Define scope for iteration

B: Assess for key time-horizon– usually ‘to-be’

D: Conduct gap-analysis– derive change-

requirements

C: Assess for comparison time– usually ‘as-is’ or transition

Preliminary Phase becomes just another scope, another iteration of the same overall cycle

C.Develop

Common / Connection Architecture

B.Develop

Big-Picture / Business

Architecture

D.Develop

Detail-levelArchitecture


Requirements etc

G.Governance

and Compliance

E.Opportunities

andSolutions

A.Architecture




H.Architecture

Change Management

F.Plan

Implementation

C.Develop

Comparison Architecture(e.g. ‘As-Is”)

B.DevelopPrimary

Architecture(e.g. ‘To-Be’)

D.Conduct

Gap-Analysisfor change


Requirements etc

G.Governance

and Compliance

E.Opportunities

andSolutions

A.Architecture




H.Architecture

Assessment / Improvement

F.Plan

Implementation


Implementation largely unchanged

Phases E-G much as per standard– may not always be required

– (i.e. optional for assessment-only)

– different stakeholders each phase

– E: solution-architects– F: planners / designers– G: implementers / program

mgrs

– may act on any domain(s)– not just for IT-based projects!

Phase H expands its role– includes lessons-learned,

benefits-realisation etc for continuous-improvement

C.Develop


B.DevelopPrimary


D.Conduct



Requirements etc

G.Governance

and Compliance

E.Opportunities

andSolutions

A.Architecture




H.Architecture


F.Plan

Implementation


Process and governance• Use ADM in iterative Agile style for rapid ROI

– business will not wait 2+ years before any returns!

• Every iteration begins from a business-question– all EA anchored to business drivers, business needs

• Duration / budget implied by business-question– also indicates likely scale of change for Phases E-G

• Scope is identified / defined in Phase A– indicates stakeholders / governance for the iteration– indicates models etc needed in Phases B-D– indicates success-criteria to be used in Phase H review


Adapt Zachman to describe scope


1: Overall scope

2: Business

3: Systems

4: Design

5: Implementation

6: Operations

What How Where Who When Why

Zachman rows work well enough as-is

Zachman columnsneed significant rethink to break free of IT-centrism


Base-framework columnsColumns need restructure to support whole-EA

At Operations level, we should be able to describe every service as:

What How Where Who When Why

Asset

What

ObjectInformationRelationship

Value

(examplesegment)

<asset>

(revised)

(original)

with

Function

How

MechanicalIT-basedManualAbstract

<function>do

Location

Where

PhysicalVirtual

RelationalTemporal

<location>at

Capability

Who

RulesAnalysisHeuristicPrinciple

<capability>using

Event

When

PhysicalVirtual

RelationalTemporal

<event>on

Reason

Why

RulesAnalysisHeuristicPrinciple

<reason>because

-- this is an ‘architecturally complete’ pattern or composite


Base-framework segments

Needs dimension of ‘segments’ within columns

Physical(e.g. server)

Virtual(e.g. data)

Relational(e.g. employee

via contract)

Abstract(e.g. finance)

Example segments

Segments are rarely relevant at upper layers

Segments become more significant in design layers

Segments are essential to implementations

Asset FunctionLocation Event Decision

1: Scope

2: Business

3: System

4: Develop

5: Deploy

6: Operations

Capability

0: UniversalsColumns rarely used in ‘Universals’ row


Methods – governance for Agile EA

Statement of Architecture Work (for iteration)

Stakeholder review for primary architecture

Stakeholder review for comparison architecture

Gap-analysis / requirements review

Solution design review

Project plan

review

Project architectur

e compliance

review

Benefits realisation

(‘lessons learned’

etc)

Architecture Charter

Governance-artefactsdefine methodology’sphase-boundaries

C.Develop


B.DevelopPrimary


D.Conduct



Requirements etc

G.Governance

and Compliance

E.Opportunities

andSolutions

A.Architecture




H.Architecture


F.Plan

Implementation


That bit in the middle...

All Phases / tasks share common set of repositories– contain shared ‘products’ of architecture work– enables PRINCE2-style governance by ‘products’

‘Products’ from architecture work include:• Models, metamodels and reference-models• Change-roadmaps and portfolio ‘blueprints’• Requirements-repository• Risks, opportunities and issues registers• Architecture-dispensations register• Glossary and thesaurus


Extending the capability - summaryProblem:• TOGAF imposes limits on assessment-

capability• TOGAF governance too inconsistent for AgileSolution:• use time-horizons etc as focus for Phases B-D• use expanded Zachman as frame for scope etc• define scope for iteration in Phase A• allow iterations to nest as required• address any architecture, any scope, any scale



Using TOGAF for whole-enterprise EA• Adapted TOGAF-ADM for whole-enterprise EA

– restructure of Phases A-D to resolve IT-centrism

• Extended-Zachman as base-framework for EA– complete coverage of full whole-of-enterprise scope

• Agile-style model permits rapid return-on-effort– consistent for all architecture-iteration timescales

• TOGAF maturity-model as ‘stepping-stones’– gives graded plan for whole-enterprise architecture

• Proven in real-world practice in and beyond IT– logistics, utilities, government, telco etc


Some suggested resourcesBooks by Tom Graves (www.tetradianbooks.com):• Real Enterprise Architecture: beyond IT to the whole enterprise• Bridging the Silos: enterprise architecture for IT-architects• The Service Oriented Enterprise: enterprise architecture and viable

systems• Doing Enterprise Architecture: process and practice in the real enterprise• SEMPER and SCORE: enhancing enterprise effectiveness• Power and Response-ability: the human side of systems

Books by other authors:• Lost in Translation (Nigel Green et al) (www.LIThandbook.com)

– introduces ‘VPEC-T’ – a path to improved communication between business and IT

• Enterprise Architecture as Strategy (Ross, Weill et al)– describes business-oriented role for enterprise architecture

• Business Model Generation (Osterwalder et al) (www.businessmodelgeneration.com)– describes systematic TOGAF-compatible process to model business drivers etc

Simple Enterprise Architecture Toolset (www.s-ea-t.com)– free entry-level toolset for business-oriented enterprise architecture [coming soon]


Using TOGAF beyond IT

Business

c tom graves tetradian

enterprise scope

togaf scope

based enterprise architecture

tetradian consulting

togaf adm

togaf phases bd

subset of architecture