Unpacking business-architecture

the futures of business

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

Unpacking Business Architecture

Tom Graves, Tetradian ConsultingTOGAF Stockholm, November 2010info@tetradian.com / www.tetradian.com

Business architecture and the enterprise

or, What to do when the enterprise impacts on the business

What is ‘business architecture’?...and how does it differ from enterprise-

architecture?• No clear definition in TOGAF or elsewhere:

– TOGAF: “strategy”, “business drivers”, “business capabilities”, “business processes”

– “knowledge of the Business Architecture is a prerequisite for architecture work in any other domain (Data, Application, Technology)” – but doesn’t say what it is...

• Should it be ‘the architecture of the business”?– but what is ‘the business’, anyway?

A real business problem...

...“we’ve gone from the most-respected bank in our region to the least-respected bank – and it’s starting to hurt everything we do...”

• Serious impacts at whole-enterprise scale– customer-relations, employee-relations, government-

relations, business-processes, business-results

• Affects everywhere – hence architectural issue– “everything depends on everything else”

• Yet what is the ‘architecture’ of respect?– and how would we describe it, with TOGAF?

Let’s just step back a bit...

...think about this in strict architectural terms

the futures of business 10 Apr 2023 (c) Tom Graves / Tetradian 2010 6

Whole-of-enterprise architectureEach EA generation has had to extend the scope:• ‘Classic’ EA starts with IT infrastructure• IT tech-architecture depends on applications• Applications-architecture depends on data• Data-architecture depends on business-info

need• Information-architecture depends on business• Business-architecture depends on enterprise• Enterprise-architecture defines the contextAn enterprise-architecture must have whole-of-

enterprise scope – it’s not just detail-level IT!

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)

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 8.1

TOGAF 9

‘Big-picture’ strategy

Pain-points + wicked-problems

But business most wants us to work on these...(...everything else is just ‘detail stuff’)

Importance of ‘Know your business’• We need that ‘Stage 1’ work (‘Know your

business’) as the anchor for the architecture– high-level overview of ‘what business are we in?’

• TOGAF assumes this is ‘business architecture’– but TOGAF’s handling of business-architecture is not

well-suited for this purpose at present – we’ll come back to this later

• First requirement: distinction between ‘organisation’ and ‘enterprise’– we create an architecture for an organisation,

but about an enterprise

Organisation and enterprise

Organisation and enterprise are not the same!

• Enterprise: a social structure defined by vision, values, mutual commitments

• Organisation: a legal structure defined by rules, roles, responsibilities

• The enterprise is – it provides motivation• The organisation does – it provides action

They’re fundamentally different – don’t mix them up!

Organisation as ‘the enterprise’

From a business perspective, this is the effective scope of TOGAF’s ‘business architecture’

Business-model as ‘the enterprise’

Typical business-model or supply-chain view(complete supply-chain should extend beyond this)

Market as ‘the enterprise’

Overall market includes actors who do not yet have active transactions with us, or other transactions

The real scope of ‘the enterprise’

The overall enterprise has many actors who may have only ‘intangible’ transactions / interactions with us(yet can have major impacts on our business)

The architecture of respect

• Many of the sources for our bank’s problems were out in the extended-enterprise– not ‘visible’ to a conventional IT-oriented architecture

• We needed to ‘surface’ those sources so as to resolve them in the business-architecture– to do this, must be able to extend the architecture

beyond the organisation, beyond the market

• Identify unifying factors to rebuild trust– provide customers etc reason-to-connect with bank– pre-empt / minimise impact of anti-client incidents

A classic anti-client incident• ‘United Breaks Guitars’ http://www.youtube.com/watch?v

=5YGc4zOqozo

• Real business impacts for United Airlines– direct cost (PR, media etc) in excess of $20m?– contributed to short-term hit of c.$180m on share-value– long-term damage to brand, reputation etc incalculable

• Social-media gives anti-clients great leverage– complaints can now spread faster, and wider– (but with care, so can stories of customer-satisfaction)

The market-cycle

transactions depend on (reaffirmed) reputation and trust

boundary of ‘market’in conventional

business-models

So where does TOGAF fit into this?

...or, how would we use TOGAF for this type

of architecture?

We need a more balanced view...

“everywhere and nowhere is ‘the centre’ of the enterprise-architecture”

...current TOGAF is too parochial?

“IT-infrastructure is the centre of the enterprise-architecture”(but there’s a whole world out there beyond IT...)

The TOGAF ADM: an old friend...

• Designed for IT-architecture• Focus is IT/business 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 can we use

TOGAF beyond IT?

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

TOGAF’s ‘business architecture’......in essence, ‘anything not-IT that might impact IT’

• To be blunt, ADM Phase B is not very usable– inadequate context: where does everything fit?– inadequate layering: ‘big-picture’ strategy mixed in

with ops-level process, ‘scenarios’ are just use-cases– inadequate instructions: provides lists of models that

could be useful, but without explaining how or why

• Clean-up Step 1: describe context and patterns

• Clean-up Step 2: clarify layering• Clean-up Step 3: consistency for models

Step 1: Context and patterns

...or, rethinking the real pattern behindTOGAF Phases B, C and D

Look at pattern, not content

• We naturally focus on our ‘own’ area of interest– for TOGAF 8/9, this is IT-infrastructure– the layers are actually layers of ‘distance from self’– Phases B/C/D successively focus in on our area of

interest, each ‘layer’ providing context for the next

Same pattern at larger scope

• For business-architecture, repeat the pattern– architecture of business becomes key focus (‘Phase D’)– layers are ‘distance from business-organisation’– Phases B/C/D focus in on business-architecture, each

‘layer’ providing context for the next

Scope of enterprise-architecture

(complete EA includes many other intersecting ‘architectures’ – security, process, brand, organisation etc)

Step 2: Layering and cycles

...or, where Zachman really works with TOGAF

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 [Business-purpose]Zachman rows 0-2

Common / ConnectionZachman rows 2-3

Design / DetailZachman rows 4-6

[People](FEAF labels this as ‘Human Capital’)

[Things](FEAF labels this as ‘Other Fixed Assets’)

[Information]

Layers of abstraction

(row-0 = ‘always’; rows 1-5 = far-future to near-future; row-6 = past)

Cycles of structural dependency

(adapted from classic Group Dynamics project-lifecycle and VPEC-T framework)

Strategy, tactics, operations

(overall cycle and relationships need to be in balance)

The ‘quick-money’ failure-cycle

(this was a key source of problems for the bank – too short-term focus,with the classic “last year +10%” used as a substitute for strategy)

Step 3: Consistency for models

...or, service-oriented architecturefor the whole enterprise

Everything serves the vision

• The vision describes the shared aims of the entire enterprise• We observe and learn from what we achieve in the real world• Everything in the enterprise is a service towards the vision

(a literal ‘service-oriented architecture’

The structure of vision• Vision is the overall anchor for everything

– ‘vision’ in the ISO9000 sense – i.e. not ‘marketing puff’

• Vision-descriptor has distinct 3-part structure– focus [noun]: context or things of concern to everyone– action [verb]: what is to be done to or in the focus– qualifier [adjective]: why this is important to everyone

• Example: ‘ideas worth spreading’ (TED conferences)

– ‘ideas’ (focus)– ‘worth’ (qualifier)– ‘spreading’ (action)

Components may be in any order, but all must be present

All services have same structure

• Service exists at intersection of value and supply-chain• Service creates value towards the vision of the enterprise• Interactions / flows before, during, after main transaction

Including guidance and investors

(yes, I know it looks like Robbie-the-Robot, but that’s just how it came out...)

Identify internal content of servicesUse extended-Zachman to support whole-EA

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

What How Where Who When Why

ObjectInformationRelationship

(examplesegment)

<asset>

(revised)

(original)

Function

MechanicalIT-basedManualAbstract

<function>do

Location

PhysicalVirtual

RelationalTemporal

<location>at

Capability

RulesAnalysisHeuristicPrinciple

<capability>using

PhysicalVirtual

RelationalTemporal

<event>on

Reason

RulesAnalysisHeuristicPrinciple

<reason>because

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

Cross-links to market value-cycle

Many interactions with extended-enterprise relate to Value-Proposition only – Purpose, Values, People, Policies

Layers – row-0 (vision)

ZapaMex is a fictitious shoe-retailer (Las Zapaterias de Mexico) – we developed this model-set as a ‘demonstrator’ for the bank

Layers – row-1 (scope)

Row-1 consists only of lists of ‘relevant entities’ – for example, the ‘Who’ section lists key actors in the overall enterprise

Layers – row-2 (business-services)

Row-2 describes the relationship between the selected ‘relevant entities’ – for the enterprise to be effective, every entity must be accounted for somewhere in the overall system

Layers – row-3 (service content) [1]

Manufacturing’s view of the overall service, ignoring everything and everyone outside its scope (much like IT often does... or many would-be business-models)

a more realistic view of the business-architecture, including activities and flows that are needed before and after the main transactions

a more complete scope for the business-architecture

Services - guidance

Keep the service on-track to the enterprise vision

• Direction – provide strategy, futures-services, planning, performance-tracking

• Coordination – connect this service to others to coordinate run-time processes, change-projects and longer-term development

• Validation – develop awareness and capability for each value and quality associated with the vision, and audit performance against that value

Layers – rows 3-5 and row-6

• Rows 3-5 are very similar to each other, and will be modelled as services in much the same way on the Enterprise Canvas– only essential difference is the level of detail:

• row-3 (‘logical model’): implementation-independent• row-4 (‘physical model’): implementation-dependent• row-5 (‘action plan’): complete deployment detail

• Row-6 is records of action etc – always relates to the past, not the future– includes all metrics, history, performance-records

etc– use in reviews to link action etc back to vision

How do we do all this in TOGAF?• Option 1: retain existing Phase B/C/D, but

move everything up a couple of notches– Phase B: the overall enterprise (‘Big-picture’)– Phase C: market + supply-chain (‘Common/Connection’)– Phase D: business-architecture (‘Design/Detail’)

• Option 2: rethink ADM to support any scope– Phase A: identifies purpose for iteration (‘Aim’)– Phase B: assess main time-horizon (‘Base’)– Phase C: assess comparison time-horizon(s) (‘Compare’)– Phase D: do gap-analysis (‘Difference’)

Option 1: extend the 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

Option 2: rethink the structure...

Requires more radical change, but also more versatile

C.Develop

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

B.DevelopPrimary

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

D.Conduct

Gap-Analysisfor change

Repositories for Architectures / Issues / Risks /

Requirements etc

G.Governance

and Compliance

E.Opportunities

andSolutions

A.Architecture

Iteration Scope and Purpose

H.Architecture

Assessment / Improvement

F.Plan

Implementation

• Iterative – ADM cycles can include other cycles, and can be any duration from a couple of hours to a couple of years

• Unrestricted scope – can address any scope – not constrained to predefined scope such as the ‘four architectures’ of standard ADM

Some alternate approaches• Business Model Generation (Osterwalder et al)

(www.businessmodelgeneration.com)– probably the business-modelling technique - describes systematic

TOGAF-compatible process to model business drivers etc

• recrEAtion (Chris Potts) (see www.dominicbarrow.com)– uses fiction to describe a whole-of-enterprise architecture, with an

emphasis on business-specific ‘guiding ratios’

• Lost in Translation (Nigel Green et al) (www.LIThandbook.com)– introduces VPEC-T (values, policies, events, content, trust) – a path to

improved communication between business and IT

• Enterprise Architecture as Strategy (Ross, Weill et al)– use of IT-oriented architecture to underpin business-strategy – popular

introduction to enterprise-scale architecture for IT-architects

Summary• Enterprise-architecture is architecture of the

whole enterprise – not solely the enterprise-IT

• TOGAF at present is focussed on IT-architecture, but with some amendments also works well at whole-enterprise scale and scope

• Viewing everything as services provides consistency across all enterprise scope– ‘Enterprise Canvas’ model provides a means to link

different models in different layers

• Enterprise culture is the real key to enterprise-architecture

Unpacking business architecture

Any questions?

(or answers, perhaps?)

Thank you!

Further detail: books by Tom Graves• Doing Enterprise Architecture: process and practice in the

real enterprise

• Everyday Enterprise Architecture: sensemaking, strategy, structures and solutions

• Mapping the Enterprise: modelling the enterprise as services with the Enterprise Canvas

• Bridging the Silos: enterprise architecture for IT-architects

• The Service Oriented Enterprise: enterprise architecture and viable systems

• Real Enterprise Architecture: beyond IT to the whole enterprise

• SEMPER and SCORE: enhancing enterprise effectiveness

• Power and Response-ability: the human side of systems

(see tetradianbooks.com for details)

Unpacking business-architecture

architecture work

business drivers

business capabilities

business processesknowledge

business perspective

type of architecture

real business impacts

togaf scope

Business

Business Architecture: Architecting SOA With A Business...

The Value of Business Architecture -...

UNPACKING THE FEDERAL BUDGET POSITIVE CASH IMPACT FOR...

AgileCamp Dallas: Unpacking Business Value (Mironov)

Unpacking business model innovation process through an ...

Unpacking the implications of the Doing Business in South...

Unpacking business models for the arts and digital

Lean Business Architecture

Unpacking the Business Model Canvas

Aligning Enterprise Architecture and Business...

OMG 2014 Business Architecture Innovation Summit - Aligning....

Real Business Architecture Transforms...

Business Architecture: Overview

Business Services Architecture and Enterprise · PDF...

Business intelligence architecture

Unpacking Sourcing Business Models