Presentation at IASA 2013, April 2013

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

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

3. Governance.
(Okay, it’s not a popular word...
but we do have to face it,
otherwise nothing works...)

4. Waterfall?
or Agile?
or what?
(the only thing that’s certain is that
one-size-doesn’t-fit-all...)

5. A practical answer:
All of them, together
(Waterfall, Agile and Mixed)
by using an architecture-pattern called
backbone and edge...

6. CC-BY GardenOfEaden
…agility needs a backbone!

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

8. Design and governance
#1

9. Assertion:
Everything in the enterprise
is connected with
everything else.
(If so, we can start anywhere.)

10. Practice-question
What’s your problem?
Start anywhere:
Pick a practical challenge from your
current context to work with here.

11. Trade-offs and
uncertainties
#2

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

13. Practice-question
What trade-offs do you face?
Summarise some examples for your
current context.

14. Design for uncertainty
CC-BY Todd Hudson via Flickr
…requisite-variety

15. Design for uncertainty
© AviationExplorer
…requisite-inefficiency

16. Design for uncertainty
…requisite-fuzziness

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

18. Everything-as-a-service
#3

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

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

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

22. Product
CC-BY Kiran Kodoru via Flickr
Product is static…
…a kind of ‘proto-service’

23. Service
CC-BY Igor Schwarzmann via Flickr
Service
implies
action… …action
implies
service

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

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

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

27. CC-BY AllBrazilian via Wikimedia
It’s also always about people…
…‘service’ means that
someone’s needs are served

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

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

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

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

32. Backbone and edge
#4

33. “Let’s do a quick SCAN of this…”
Making sense for design

34. “Insanity
is doing
the same thing
and expecting
different results”
(Albert Einstein)
ORDER
(rules do work here)
Take control! Impose order!

35. “Insanity
is doing
the same thing
and expecting
different results”
(Albert Einstein)
“Insanity
is doing
the same thing
and expecting
the same results”
(not Albert Einstein)
ORDER
(rules do work here)
UNORDER
(rules don’t work here)
Order and unorder

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

37. THEORY
What we plan to do, in the expected conditions
What we actually do, in the actual conditions
PRACTICE
Theory and practice

38. algorithm guideline
rule principle
Sensemaking creates clarity for action
Making sense with SCAN

39. 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’?

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

41. One of the hardest parts
of working with uncertainty
is to build the right balance
between known and unknown
- between backbone and edge.

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

43. Backbone, domain and edge
order unorder
fail-safe
(high-dependency)
BACKBONE
safe-fail
(low-dependency)
EDGE
plan
actual
Waterfall
(‘controlled’ change)
Agile
(iterative change)
Mixed
(guided change)
analysis
(knowable result)
DOMAIN
experiment
(unknowable result)

44. A spectrum of services

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

46. Vision and values
are always part of the backbone:
values as ‘shared-services’.

47. A spectrum of services
also implies
a spectrum of governance:
governance of governance itself.

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

49. Viable services
#5

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

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

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

53. More on the big-picture
#6

54. “We create an architecture
for an organisation,
but about an enterprise.”
“We create an architecture
for 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.

55. “An organisation is bounded by
rules, roles and responsibilities;
an enterprise is bounded by
vision, values and commitments.”
“An organisation is bounded by
rules, roles and responsibilities;
an enterprise is bounded by
vision, 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.

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

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

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

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

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

61. Every service has its own myriad of stakeholders.
Whose story?

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

63. Always start from values,
not money.

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

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

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

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

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

69. 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’?

70. Architecting for change
#7

71. Everything changes…

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

73. Structure and story
Afterword

74. Nice view of structure, but…

75. …where are the people?

76. Start with structure, or process...

77. …but include the people-story!

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

79. Thank you!

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