80
Backbone and edge architecting the balance between continuity and change Tom Graves, Tetradian Consulting IASA Architecture Summit, London, April 2013

Backbone and edge - architecting the balance between continuity and change

Embed Size (px)

DESCRIPTION

Presentation at IASA 2013, April 2013

Citation preview

Page 1: Backbone and edge - architecting the balance between continuity and change

Backbone and edgearchitecting the balance

between continuity and change

Tom Graves, Tetradian ConsultingIASA Architecture Summit, London, April 2013

Page 2: Backbone and edge - architecting the balance between continuity and change

Hi.

I’m Tom.(That’s all of the PR stuff out of the way...)

Page 3: Backbone and edge - architecting the balance between continuity and change

Governance.(Okay, it’s not a popular word...

but we do have to face it,otherwise nothing works...)

Page 4: Backbone and edge - architecting the balance between continuity and change

Waterfall?

or Agile?

or what?

(the only thing that’s certain is that one-size-doesn’t-fit-all...)

Page 5: Backbone and edge - architecting the balance between continuity and change

A practical answer:

All of them, together(Waterfall, Agile and Mixed)

by using an architecture-pattern called

backbone and edge...

Page 6: Backbone and edge - architecting the balance between continuity and change

CC-BY GardenOfEaden

…agility needs a backbone!

Page 7: Backbone and edge - architecting the balance between continuity and change

Practice-stuff

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

• work fast – max. 1minute per question

• record as you go, with notes or sketches

Get pen-and-paper or tablet ready now…

(There are ~12 practical questions in this session)

Page 8: Backbone and edge - architecting the balance between continuity and change

Design and governance

#1

Page 9: Backbone and edge - architecting the balance between continuity and change

Assertion:Everything in the enterprise

is connected with everything else.

(If so, we can start anywhere.)

Page 10: Backbone and edge - architecting the balance between continuity and change

Practice-question

What’s your problem?Start anywhere:

Pick a practical challenge from your current context to work with here.

Page 11: Backbone and edge - architecting the balance between continuity and change

Trade-offs and uncertainties

#2

Page 12: Backbone and edge - architecting the balance between continuity and change

Too many trade-offs?

stability adaptability

continuity(exploitation)

change(innovation)

sameness(economy-of-scale)

uniqueness(market-of-one)

‘control’ ‘anarchy’?

Waterfall Agile

versus

versus

versus

versus

versus

Page 13: Backbone and edge - architecting the balance between continuity and change

Practice-question

What trade-offs do you face?Summarise some examples for your

current context.

Page 14: Backbone and edge - architecting the balance between continuity and change

Design for uncertainty

CC-BY Todd Hudson via Flickr

…requisite-variety

Page 15: Backbone and edge - architecting the balance between continuity and change

Design for uncertainty

© AviationExplorer

…requisite-inefficiency

Page 16: Backbone and edge - architecting the balance between continuity and change

Design for uncertainty

…requisite-fuzziness

Page 17: Backbone and edge - architecting the balance between continuity and change

Practice-questions

What are the uncertainties?

How do you work with this?Summarise the requisite-variety, variety-weather, requisite-inefficiency, requisite-

fuzziness and suchlike in the context.

Page 18: Backbone and edge - architecting the balance between continuity and change

Everything-as-a-service

#3

Page 19: Backbone and edge - architecting the balance between continuity and change

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

in the same consistent way.)

Page 20: Backbone and edge - architecting the balance between continuity and change

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

Page 21: Backbone and edge - architecting the balance between continuity and change

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

The nature of service

Page 22: Backbone and edge - architecting the balance between continuity and change

Product

CC-BY Kiran Kodoru via Flickr

Product is static…

…a kind of ‘proto-service’

Page 23: Backbone and edge - architecting the balance between continuity and change

Service

CC-BY Igor Schwarzmann via Flickr

Serviceimpliesaction… …action

impliesservice

Page 24: Backbone and edge - architecting the balance between continuity and change

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

Relations between services

Page 25: Backbone and edge - architecting the balance between continuity and change

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

Values and value

Page 26: Backbone and edge - architecting the balance between continuity and change

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

What they serve is a shared vision,via exchange of value.

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

Page 27: Backbone and edge - architecting the balance between continuity and change

CC-BY AllBrazilian via Wikimedia

It’s also always about people…

…‘service’ means thatsomeone’s needs are served

Page 28: Backbone and edge - architecting the balance between continuity and change

Practice-questions

What is this service?

Whom does it serve, and why?Summarise the context as a service

– its inputs, actions and outputs,actors and stakeholders,

values and value-exchanges,and its overarching ‘why’.

Page 29: Backbone and edge - architecting the balance between continuity and change

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

Page 30: Backbone and edge - architecting the balance between continuity and change

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

Page 31: Backbone and edge - architecting the balance between continuity and change

Practice-questions

What are the interfaces between services?

What is exchanged between each pairing of services,

or along chains of services?

What Exchanges take place before, during and after each main-transaction?

Page 32: Backbone and edge - architecting the balance between continuity and change

Backbone and edge

#4

Page 33: Backbone and edge - architecting the balance between continuity and change

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

Making sense for design

Page 34: Backbone and edge - architecting the balance between continuity and change

“Insanityis doingthe same thingand expectingdifferent results”

(Albert Einstein)

ORDER(rules do work here)

Take control! Impose order!

Page 35: Backbone and edge - architecting the balance between continuity and change

“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

Page 36: Backbone and edge - architecting the balance between continuity and change

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

Page 37: Backbone and edge - architecting the balance between continuity and change

THEORYWhat we plan to do, in the expected conditions

What we actually do, in the actual conditions

PRACTICE

Theory and practice

Page 38: Backbone and edge - architecting the balance between continuity and change

algorithm guideline

rule principle

Sensemaking creates clarity for action

Making sense with SCAN

Page 39: Backbone and edge - architecting the balance between continuity and change

Practice-questions

What do you need to be certain about?

What is always going to be uncertain or unique?

(‘Messy’ – politics, management, wicked-problems, ‘should’ vs ‘is’, etc.)

What will always be ‘messy’?

Page 40: Backbone and edge - architecting the balance between continuity and change

ORDER(a sense of ‘the known’)

UNORDER(a sense of ‘the unknown’)

We need governance that can adapt to work with the full spectrum.

A spectrum of uncertainty

Page 41: Backbone and edge - architecting the balance between continuity and change

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

between known and unknown- between backbone and edge.

Page 42: Backbone and edge - architecting the balance between continuity and change

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)

Page 43: Backbone and edge - architecting the balance between continuity and change

Backbone, domain and edge

order unorder

fail-safe(high-dependency)

BACKBONEsafe-fail

(low-dependency)

EDGE

plan

actual

Waterfall(‘controlled’ change)

Agile(iterative change)

Mixed(guided change)

analysis(knowable result)

DOMAINexperiment

(unknowable result)

Page 44: Backbone and edge - architecting the balance between continuity and change

A spectrum of services

Page 45: Backbone and edge - architecting the balance between continuity and change

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…

Page 46: Backbone and edge - architecting the balance between continuity and change

Vision and valuesare always part of the backbone:

values as ‘shared-services’.

Page 47: Backbone and edge - architecting the balance between continuity and change

A spectrum of servicesalso implies

a spectrum of governance:governance of governance itself.

Page 48: Backbone and edge - architecting the balance between continuity and change

Practice-questions

Which services fit more in backbone, domain or edge?

What governance to apply to each: Waterfall, Agile, Mixed?

If Mixed, how would the appropriate mix be identified and governed?

Page 49: Backbone and edge - architecting the balance between continuity and change

Viable services

#5

Page 50: Backbone and edge - architecting the balance between continuity and change

Use the Viable Services 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

Page 51: Backbone and edge - architecting the balance between continuity and change

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

Investor and beneficiary

Page 52: Backbone and edge - architecting the balance between continuity and change

Practice-questions

What are the interdependencies for this service?

What is needed from other services for this to be viable?

Identify what is needed from value-web, direction and investor/beneficiaries.

Page 53: Backbone and edge - architecting the balance between continuity and change

More on the big-picture

#6

Page 54: Backbone and edge - architecting the balance between continuity and change

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

Page 55: Backbone and edge - architecting the balance between continuity and change

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

Page 56: Backbone and edge - architecting the balance between continuity and change

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

Whose story?

Page 57: Backbone and edge - architecting the balance between continuity and change

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

Whose story?

Page 58: Backbone and edge - architecting the balance between continuity and change

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

Whose story?

Page 59: Backbone and edge - architecting the balance between continuity and change

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

Whose story?

Page 60: Backbone and edge - architecting the balance between continuity and change

“Customers do not appear in our processes…

…we appear in their experiences.”

“Customers do not appear in our processes…

…we appear in their experiences.”

A question of perspective

We must create the architecture around the shared-story- not solely around our organisation’s structures.

Chris Potts, recrEAtion, Technics, 2010

Page 61: Backbone and edge - architecting the balance between continuity and change

Every service has its own myriad of stakeholders.

Whose story?

Page 62: Backbone and edge - architecting the balance between continuity and change

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

Page 63: Backbone and edge - architecting the balance between continuity and change

Always start from values,not money.

Page 64: Backbone and edge - architecting the balance between continuity and change

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

Page 65: Backbone and edge - architecting the balance between continuity and change

Practice-questions

Who are the stakeholders for this service?

What are their respective needs, priorities, drivers?

Identify what is needed to balance the relations and priorities of all stakeholders.

Page 66: Backbone and edge - architecting the balance between continuity and change

In sourcing via supply-chain, services are ‘outside’, and boundary-of-identity and boundary-of-control are same.

Sourcing: supply-chain

Page 67: Backbone and edge - architecting the balance between continuity and change

In insourcing, services are ‘inside’, and the boundary-of-identity and boundary-of-control are the same.

Sourcing: insourcing

Page 68: Backbone and edge - architecting the balance between continuity and change

In outsourcing, services are ‘inside’ boundary-of-identity but ‘outside’ boundary-of-control.

Sourcing: outsourcing

Page 69: Backbone and edge - architecting the balance between continuity and change

Practice-questions

Who ‘owns’ each service?

What is each respective boundary-of identity and

boundary-of-control?

If a service is outside the boundary-of-control, how is it managed and ‘controlled’?

Page 70: Backbone and edge - architecting the balance between continuity and change

Architecting for change

#7

Page 71: Backbone and edge - architecting the balance between continuity and change

Everything changes…

Page 72: Backbone and edge - architecting the balance between continuity and change

Practice-questions

How does each service change over time, and why?

How do you manage migration into and out of the backbone?

Identify governance needed to manage this, and governance of governance itself.

Page 73: Backbone and edge - architecting the balance between continuity and change

Structure and story

Afterword

Page 74: Backbone and edge - architecting the balance between continuity and change

Nice view of structure, but…

Page 75: Backbone and edge - architecting the balance between continuity and change

…where are the people?

Page 76: Backbone and edge - architecting the balance between continuity and change

Start with structure, or process...

Page 77: Backbone and edge - architecting the balance between continuity and change

…but include the people-story!

Page 78: Backbone and edge - architecting the balance between continuity and change

What did you discover in doing this?

What will you do different on Monday morning?

Questions and insights

•Governance (Waterfall, Agile and Mixed)

•Perspective (Inside-out and outside-in)

•Design for uncertainty (Same and different)

•Design for change (Backbone and edge)

Page 79: Backbone and edge - architecting the balance between continuity and change

Thank you!

Page 80: Backbone and edge - architecting the balance between continuity and change

Contact: Tom Graves

Company: Tetradian Consulting

Email: [email protected]

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: