Serving the story: how process-management and enterprise-architecture work together in the overall enterprise. Presentation and practical-exercises for BPM Portugal conference, April 2013.

1. Serving the story
how BPM and EA work together in
the enterprise
Tom Graves, Tetradian Consulting
BPMCP Conference, Lisbon, April 2013

2. Hi.
I‟m Tom.

3. (That‟s all of the PR stuff
out of the way...)
(...so let‟s go straight into practice?)

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

5. Process, structure, story
Overture

6. Current EA emphasises structure...
So, here‟s a structure...

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

8. CC-BY Boban021 via Flickr
…here, the story of Carnaval.

9. CC-BY sfmission via Flickr
…it‟s one huge city-wide party…

10. CC-BY-SA adriagarcia via Flickr
…and yes, it really is city-wide…

11. CC-BY sfmission via Flickr
But when the party‟s over,
and it‟s time to head home...

12. CC-BY otubo via Flickr
Someone must be there to clean up...
- because that‟s part of the story too.

13. CC-BY jorgeBRAZIL via Flickr
Process, assets, data, locations....
- all the usual stuff of EA and BPM...
...all those necessary details
of organisation.

14. CC-BY Avodrocc via Flickr
Organisation focusses
on structure and process…

15. CC-BY Boban021 via Flickr
yet the enterprise is the story.

16. Structure and process exist
because of the story.

17. CC-BY SheilaTostes via Flickr
A key task here, for EA and BPM
is to remember
and design for that fact,
maintaining the balance
between structure, process and story.

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

19. Inside-out and outside-in
#1

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

21. A useful guideline:
“The enterprise in scope
should be three steps larger
than the organisation in scope.”
Tom Graves, Mapping the Enterprise, Tetradian, 2010
Which architecture?

22. If the organisation says it „is‟ the enterprise,
there‟s no shared-story - and often, no story at all.
Whose story?

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

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

25. The market itself exists within a context of „intangible‟
interactions with the broader shared-enterprise story.
Whose story?

26. Inside-in…
CC-BY Myrmi via Flickr
always
at risk of
drowning in
the detail…

27. Inside-out…
CC-BY – Paul – via Flickr
We create an architecture
for an organisation,
but about a broader enterprise.

28. Outside-in…
CC-BY Fretro via Flickr
“Customers
do not appear
in our processes,
we appear in
their experiences.”
Chris Potts, recrEAtion, Technics, 2010

29. CC-BY Matt Brown via Flickr
Outside-out…
There‟s always a larger scope…

30. Practice: Perspective
What changes as you change perspective?
• Inside-in
• Inside-out
• Outside-in
• Outside-out
What do these differences imply? To whom?

31. Purpose as story
#2

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

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

34. “An architecture
describes 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

35. That „guiding star‟ or „vision‟
- the core for the enterprise story -
has a distinctive three-part format:
Concern.
Action.
Qualifier.

36. Concern: the focus of
interest to everyone in
the shared-enterprise
“Ideas worth
spreading”
CC-BY UK DFID via Flickr

37. “Ideas worth
spreading”
Action: what is
being done to
or with or about
the concern
CC-BY US Army Africa via Flickr

38. “Ideas worth
spreading”
Qualifier:
the emotive
driver for action
on the concern
CC-BY HDTPCAR via Flickr

39. (Note: „making money‟ is
not 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!)

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

41. Service and story
Interlude

42. Product
CC-BY Kiran Kodoru via Flickr
Product is static…

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

44. CC-BY AllBrazilian via Wikimedia
It‟s also always about people…
…„service‟ means that
someone‟s needs are served

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

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

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

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

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

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

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

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

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

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

55. value-flow
(„how‟,
„with-what‟)
These are distinct flows – don‟t mix them up!
values
(„why‟)
money
Values, value-flow, money

56. Always start from values,
not money.

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

58. Same and different
#3

59. “Let‟s do a quick SCAN of this…”
Making sense for action

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

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

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

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

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

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

66. Backbone and edge
#4

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

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

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

70. A spectrum of services

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

72. Vision and values
are always part of the backbone:
values as „shared-services‟.

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

74. Whether „backbone‟ or „edge‟,
every service needs to maintain
its connection with the story.

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

76. Share the story
Afterword

77. Nice view of structure, but…

78. …where are the people?

79. …where‟s the story?

80. Start with structure, or process...

81. …but include the people-story!

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

83. Obrigado!

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