Serving the storyhow BPM and EA work together in

the enterprise

Tom Graves, Tetradian ConsultingBPMCP Conference, Lisbon, April 2013

Hi.

I’m Tom.

(That’s all of the PR stuffout of the way...)

(...so let’s go straight into practice?)

Practice-sections

Practice-sections look like this slide:• work in pairs, if possible

• work fast – 3-5mins for each item

• record as you go, with notes or sketches

Get pen-and-paper or tablet ready now…

(There are four practice-sections in this session.)

Process, structure, story

Overture

Current EA emphasises structure...

So, here’s a structure...

CC-BY Avodrocc via Flickr

It’s called the Sambadromo...Which doesn’t really tell us anything.

To make sense of a structure,

we need the story...and the processes that use it,

CC-BY Boban021 via Flickr

…here, the story of Carnaval.

CC-BY sfmission via Flickr

…it’s one huge city-wide party…

CC-BY-SA adriagarcia via Flickr

…and yes, it really is city-wide…

CC-BY sfmission via Flickr

But when the party’s over,and it’s time to head home...

CC-BY otubo via Flickr

Someone must be there to clean up...- because that’s part of the story too.

CC-BY jorgeBRAZIL via Flickr

Process, assets, data, locations....- all the usual stuff of EA and BPM......all those necessary details of organisation.

CC-BY Avodrocc via Flickr

Organisation focusseson structure and process…

CC-BY Boban021 via Flickr

yet the enterprise is the story.

Structure and process exist because of the story.

CC-BY SheilaTostes via Flickr

A key task here, for EA and BPM

is to rememberand design for that fact,

maintaining the balancebetween structure, process and story.

CC-BY SheilaTostes via Flickr

What we do is about structure, and process.

What, how, why; structure, process, story.

We need them all, to make it all happen.

What it’s for is about the purpose, the story.

Inside-out and outside-in

#1

“We create an architecturefor an organisation,

but about an enterprise.”

“We create an architecturefor an organisation,

but about an enterprise.”Tom Graves, Mapping the Enterprise, Tetradian, 2010

Whose architecture?

Organisation aligns with structure, enterprise with story.We need a balance of both for the architecture to work.

A useful guideline:“The enterprise in scope

should be three steps largerthan the organisation in scope.”

A useful guideline:“The enterprise in scope

should be three steps largerthan the organisation in scope.”

Tom Graves, Mapping the Enterprise, Tetradian, 2010

Which architecture?

If the organisation says it ‘is’ the enterprise,there’s no shared-story - and often, no story at all.

Whose story?

The minimum real enterprise is the supply-chain - a story of shared transactions.

Whose story?

The organisation and enterprise of the supply-chain take place within a broader organisation of the market.

Whose story?

The market itself exists within a context of ‘intangible’ interactions with the broader shared-enterprise story.

Whose story?

Inside-in…

CC-BY Myrmi via Flickr

always at risk of

drowning in the detail…

Inside-out…

CC-BY – Paul – via Flickr

We create an architecturefor an organisation,

but about a broader enterprise.

Outside-in…

CC-BY Fretro via Flickr

“Customers do not appear

in our processes,we appear in

their experiences.”Chris Potts, recrEAtion, Technics, 2010

CC-BY Matt Brown via Flickr

Outside-out…

There’s always a larger scope…

Practice: Perspective

What changes as you change perspective?

•Inside-in

•Inside-out

•Outside-in

•Outside-out

What do these differences imply? To whom?

Purpose as story

#2

“An organisation is bounded byrules, roles and responsibilities;

an enterprise is bounded byvision, values and commitments.”

“An organisation is bounded byrules, roles and responsibilities;

an enterprise is bounded byvision, values and commitments.”

Tom Graves, Mapping the Enterprise, Tetradian, 2010

What architecture?

Organisation aligns with structure, enterprise with story.We need a balance of both for the architecture to work.

A myriad of ‘guiding stars’ out there…

…choose one that looks right to you.

Use it as your guiding-star. Everywhere.

Example (TED conferences): “Ideas worth spreading”

“An architecturedescribes structure

to support a shared-story.”

“An architecturedescribes structure

to support a shared-story.”

Why architecture?

Organisation aligns with structure, enterprise with story.We need a balance of both for the architecture to work.

Tom Graves, The Enterprise As Story, Tetradian, 2012

That ‘guiding star’ or ‘vision’- the core for the enterprise story -has a distinctive three-part format:

Concern.Action.

Qualifier.

Concern: the focus of interest to everyone in the shared-enterprise

“Ideas worth spreading”

CC-BY UK DFID via Flickr

“Ideas worth spreading”

Action: what is being done to or with or aboutthe concern

CC-BY US Army Africa via Flickr

“Ideas worth spreading”

Qualifier:the emotivedriver for actionon the concern

CC-BY HDTPCAR via Flickr

(Note: ‘making money’ isnot a meaningful vision in this sense.

It’s a measurement, not a vision– at best, a desirable side-effect.Don’t get misled by that mistake!)

Practice: Purpose

What guiding-star for the enterprise?

•Concern

•Action

•Qualifier

How to link organisation with enterprise?

How to use it as your enterprise-story?

Service and story

Interlude

Product

CC-BY Kiran Kodoru via Flickr

Product is static…

Service

CC-BY Igor Schwarzmann via Flickr

Serviceimpliesaction… …action

impliesservice

CC-BY AllBrazilian via Wikimedia

It’s also always about people…

…‘service’ means thatsomeone’s needs are served

Assertion:Everything in the enterprise is or represents a service.(If so, we can describe everything

in the same consistent way.)

A tension exists between what is, and what we want.

The vision describes the desired-ends for action;values guide action, describing how success would feel.

Why anything happens

A service represents a means toward an end – ultimately, the desired-ends of the enterprise-vision.

The nature of service

Services exchange value with each other, to help each service reach toward their respective vision and outcome.

Relations between services

Services serve.(That’s why they’re called ‘services’…)

What they serve is the story,via exchange of value.

(And if we get that right,they can sometimes make money, too.)

Each service sits at an intersection of values (vertical) and exchanges of value (horizontal)

Values and value

Interactions during the main-transactions are preceded by set-up interactions (before), and typically followed by other

wrap-up interactions such as payment (after).We can describe ‘child-services’ to support each of these.

value-add

(self)

customer-facing

supplier-facing

In more detail

Services link together in chains or webs, as structured and/or unstructured processes, to deliver more complex

and versatile composite-services.

Supply-chain or value-web

Use the Viable System Model (direction, coordination, validation) to describe service-relationships to keep this service on track to purpose and in sync with the whole.

Keeping on track

These flows (of which only some types are monetary) are separate and distinct from the main value-flows.

Investor and beneficiary

value-flow(‘how’,‘with-what’)

value-flow(‘how’,‘with-what’)

These are distinct flows – don’t mix them up!

values(‘why’)values(‘why’)

moneymoney

Values, value-flow, money

Always start from values,not money.

If we focus on money,we lose track of value.

If we focus on the ‘how’ of value,we lose track of the ‘why’ of values.

Always start from the values.(Not the money.)

Same and different

#3

“Let’s do a quick SCAN of this…”

Making sense for action

“Insanityis doingthe same thingand expectingdifferent results”

(Albert Einstein)

ORDER(rules do work here)

Take control! Impose order!

“Insanityis doingthe same thingand expectingdifferent results”

(Albert Einstein)

“Insanityis doingthe same thingand expectingthe same results”

(not Albert Einstein)

ORDER(rules do work here)

UNORDER(rules don’t work here)

Order and unorder

A quest for certainty: analysis, algorithms, identicality, efficiency, business-rule engines, executable models, Six Sigma...

SAMENESS(IT-systems do work

well here)

UNIQUENESS(IT-systems don’t work

well here)

Same and different

An acceptance of uncertainty: experiment, patterns, probabilities, ‘design-thinking’, unstructured process...

THEORYWhat we plan to do, in the expected conditions

What we actually do, in the actual conditions

PRACTICE

Theory and practice

algorithm guideline

rule principle

Sensemaking creates clarity for action

Making sense with SCAN

What parts of each service are:

How to ensure using the right methods for each?

How to switch appropriately between methods?

Practice: Order and unorder

•Simple and straightforward?•Complicated but controllable?•Ambiguous but actionable?•Not-known – always unique or

unknowable?

Backbone and edge

#4

ORDER(a sense of ‘the known’)

UNORDER(a sense of ‘the unknown’)

We need to adapt to work with the full spectrum.

A spectrum of uncertainty

One of the hardest partsof working with uncertaintyis to build the right balance

between known and unknown- between backbone and edge.

order(rules do work here)

unorder(rules don’t work here)

fail-safe(high-dependency)

safe-fail(low-dependency)

analysis(knowable result)

experiment(unknowable result)

BACKBONE EDGE

Waterfall(‘controlled’ change)

Agile(iterative change)

Backbone and edge

A spectrum of services

Choices:everything we place in the backbone

is a constraint on agility;anything we omit from the backbone

may not be dependable.It’s not an easy trade-off…

Vision and valuesare always part of the backbone:

values as ‘shared-services’.

A spectrum of servicesalso implies

a spectrum of governance:governance of governance itself.

Whether ‘backbone’ or ‘edge’,every service needs to maintain

its connection with the story.

Where would each type of service belong?

What governance do you need for each?

What governance of governance itself?

Practice: Design for change

•What needs to be in the backbone (core)?

•What needs to be in domains (complexity)?

•What needs to be at the edge (change)?

•What interfaces does each service need?

Share the story

Afterword

Nice view of structure, but…

…where are the people?

…where’s the story?

Start with structure, or process...

…but include the people-story!

What did you discover in doing this?

What will you do different on Monday morning?

Practice: Your insights

•Perspective (Inside-out and outside-in)

•Purpose (Concern, action, qualifier)

•Design for uncertainty (Same and different)

•Design for change (Backbone and edge)

Obrigado!

Contact: Tom Graves

Company: Tetradian Consulting

Email: tom@tetradian.com

Twitter: @tetradian ( http://twitter.com/tetradian )

Weblog: http://weblog.tetradian.com

Slidedecks: http://www.slideshare.net/tetradian

Publications: http://tetradianbooks.com and http://leanpub.com/u/tetradian

Books: • The enterprise as story: the role of narrative in enterprise-architecture (2012)

• Mapping the enterprise: modelling the enterprise as services with the Enterprise Canvas (2010)

• Everyday enterprise-architecture: sensemaking, strategy, structures and solutions (2010)

• Doing enterprise-architecture: process and practice in the real enterprise (2009)

Further information: