Webinar for Australian Computer Society - Enterprise Architecture Special Interest Group, September 2015 A core aim in Enterprise Architecture (EA) and Systems-Thinking (ST): things work better when they work together on purpose. For this to happen, we need guided conversations that are actually everyone’s responsibility. What visual tools can we use to engage people in this? This webinar introduces these concepts, and provides the tools and techniques need to bridge this gap. We will highlight some of the common approaches, frameworks and tools used in both of these highly related and important disciplines. We will discuss how they can be used together and enhanced to deliver a common sense approach for everyday EA and ST practice. Included in this discussion is an introduction to the Enterprise Canvas, which is a powerful tool to enable visualisations of the enterprise by defining the services it offers and their relationships and interactions.

1. ACS EA-SIG Webinar
Bridging enterprise-architecture
and systems-thinking
Tom Graves, Tetradian Consulting: September 2015

2. Hi there.
This is me. I’m Tom Graves.
(to provide a face to go with the voice…)

3. investor
(money etc)
customer
(value)
citizen
(values)
supplier
relations
value-
proposition
supplier
channels
value-
creation
customer
channels
customer
relations
value-
outlay
value-
governance
value-
return
supplier customer
investor beneficiary
coordinationdirectionvalidation
before before
during during
after after
investment dividend
guidanceguidance
mgmt-info
Enterprise Service Canvas

4. Setting the scene…

5. What is architecture?

6. The aim of all architecture,
and systems-thinking too:
things work better
when they work together
on purpose

7. Two definitions…
Enterprise
“a shared purpose, a bold endeavour”
(bounded by vision, values and commitments)
Organisation
“a structure and means to achieve ends”
(bounded by rules, roles and responsibilities)
Organisation and enterprise are not the same!

8. Where is architecture?
A generic business-structure
Contact
Customer
Manage the Business
Support the Business
Accept
Orders
Deliver
Orders
Process
Orders
Fulfil
Orders

9. Where is architecture?
The architecture is in the ‘between-spaces’
Contact
Customer
Manage the Business
Support the Business
Accept
Orders
Deliver
Orders
Process
Orders
Fulfil
Orders
analysts
(inside the boxes)
architects
(between the boxes)

10. Solution architects
(connect everything together within a project)
Who are the architects?
design-solutions will be needed
wherever there’s some kind of change going on…
- project, programme, portfolio, transformation -
…and wherever a solution is being developed,
we’ll need a solution-architect

11. Domain architects
(connect everything across a discipline or domain)
Who are the architects?
these include: infrastructure-architect,
data-architect, applications-architect,
business-architect, security-architect,
financial-architect, facilities-architect,
brand-architect, organisation-architect,
process-architect, skills/training architect,
governance-architect, and many more

12. Enterprise architects
(connect everything together)
Who are the architects?
that ‘everything’ will include: IT-infrastructure, data,
applications, non-IT technologies, business-models,
security, financials, facilities, brands, organisation-
structures, processes, interactions, skills/training,
governance, quality, environment, health-and-safety…
- every distinct domain, and much, much more

13. What architects say…
“I don’t know…”
“(but I know how to find out)”
“It depends…”
“(and I know what it depends on)”
“Just enough detail…”
“(and I know the level of detail that it needs)”

14. For architecture to happen,
we need guided-conversations
that are everyone’s responsibility.
What visual tools
will engage people in this?

15. Where do we start?

16. Short answer:
start with the tools
we already have
in our ideas-toolkit…

17. Exploring the toolkit

18. On one side, there’s
enterprise-architecture…

19. Enterprise-architecture…
Zachman Framework

20. Enterprise-architecture…
The ‘BDAT stack’
Business Architecture
Data
Architecture
Applications
Architecture
Technology
Architecture
(Information-Systems Architecture)

21. Enterprise-architecture…
TOGAF (The Open
Group Architecture
Framework)

22. Enterprise-architecture…
PRM (Performance Reference Model) from
FEAF ([US] Federal Enterprise Architecture Framework)

23. Enterprise-architecture…
Process-models (lots of them)

24. Enterprise-architecture…
Capability-models (lots of them)

25. Enterprise-architecture…
Information-models (lots of them)

26. Enterprise-architecture…
Business-models (lots of them)

27. Enterprise-architecture…
And computers, of course.
(lots and lots and lots of them…)

28. Experience:
mainstream ‘enterprise’-architecture
may be too IT-centric,
too fragmenting,
too incomplete?

29. On the other side, there’s
systems-thinking
and other whole-context methods…

30. Systems-thinking…
ISO9000 quality-system standards
work-instruction
procedure
policy
vision
more concrete
more abstract

31. Systems-thinking…
‘Tetradian’ dimensions – physical ‘things’, virtual
information, relational links between people, aspirational
purpose
Shared-purpose
(vision and values)
Relationships
(person-to-person)
Transactions
(products and services)
Conversations
(exchange of information)
Integration
(how the market
links together)

32. Systems-thinking…
Rotating between perspectives…

33. Systems-thinking…
Modality – the MoSCoW set
(“Must, Should, Could, can-Wait”)
CC-BY-NC-SA thisisbossi via Flickr
(or “Maybe, Sometimes, Could-be-possible, We-don’t-know”?)

34. Systems-thinking…
SCAN – making sense of complexity…

35. Systems-thinking…
Systems-interdependency maps

36. Systems-thinking…
Stafford Beer’s
‘Viable System
Model’

37. Systems-thinking…
Recursion and fractality in natural systems
CC-BY-NC-SA gjshepherd via Flickr

38. Systems-thinking…
Extensions to Tuckman, and Five Element (wu-xing)
Performance
(adjourning)
reporting etc
Purpose
(forming)
strategy etc
People
(storming)
HR etc
Preparation
(norming)
scheduling etc
Process
(performing)
production etc
Operations (‘do’)
Tactics (‘think’)
Strategy (‘feel’)

39. Systems-thinking…
Extensions to Five Element (wu-xing) on leadership, flow
Performance
Purpose
People
Preparation
Process
PoliciesValues
Events
Completions
Success
(start here)
Trust /
Commitment
(Initiating-Events)
(Completion-Events)

40. Systems-thinking…
Extensions to SWOT for strategy and effectiveness

41. Systems-thinking…
Worldviews, deep-metaphors and modes of operation…
Scientist
(‘outer truth’)
Believer
(‘inner truth’)
Technologist
(‘outer value’)
Artist
(‘inner value’)
truth
(thought)
value
(feeling)
internalised (subjective)
externalised (objective)
uncharted
swamp

42. Systems-thinking…
Models of power-interactions between people…
power-over
power-with
power-under
power-from-within
person A person B

43. Systems-thinking…
An emphasis on people, and spaces…
CC-BY-ND alanclarkdesign via Flickr

44. Systems-thinking…
Include the people-story…

45. Systems-thinking…
An emphasis on the system as a whole…
CC-BY-ND Kecko via Flickr

46. Experience:
systems-thinking tools
can be very powerful,
yet may be too ‘abstract’
for people to follow?

47. How do we link
EA and ST together,
into tools that can work
and ‘make sense’
for everyday EA / ST practice?

48. Recursion:
this process to develop tools
for EA and systems-thinking
is itself an application
of EA and systems-thinking

49. investor
(money etc)
customer
(value)
citizen
(values)
supplier
relations
value-
proposition
supplier
channels
value-
creation
customer
channels
customer
relations
value-
outlay
value-
governance
value-
return
supplier customer
investor beneficiary
coordinationdirectionvalidation
before before
during during
after after
investment dividend
guidanceguidance
mgmt-info
Enterprise Service Canvas…

50. About service

51. Start with an assertion:
Everything in the enterprise
is or represents a service.
(If so, we can describe everything
in the same consistent way.)

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

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

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

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

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

57. Value-flow is ‘horizontal’, but connection is first made by
‘vertical’ connection to shared-value and value-proposition
How connection happens

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

59. Crossmap between Business Model Canvas and Enterprise Canvas
Business-model as service

60. Services link together in chains or webs, as
structured and/or unstructured processes, to deliver
more complex and versatile composite-services.
Supply-chain as shared-service

61. Guidance for services

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

63. Viable System Model, representing a fractal service
Keeping on track: VSM

64. Viable System Model ‘systems’ are orthogonal to each other
Keeping on track: VSM

65. Coordination and Validation don’t fit comfortably with Taylorism
Keeping on track: VSM

66. This is the equivalents of VSM system-3, -4 and -5
Keeping on track: Direction
management-services
policy
strategy
direction

67. Interactions with delivery-services (system-1), and recursion
Keeping on track: Direction
management-services
policy
strategy
direction
policy
strategy
direction
interaction with
management-services
in parent-service above
interaction with
management-services
in child-services below

68. Extended functions for equivalent of VSM system-2
Keeping on track: Coordination
delivery-
service
management-services
policy
strategy
direction
develop
the business
change
the business
run
the business
delivery-
service
delivery-
service

69. The VSM algedonic links
- ‘any-to-any’ connections -
provide another kind of coordination.
(Hard to show on diagrams, though.)

70. Major extensions / rethink for VSM system-3*
Keeping on track: Validation

71. Validation-services:
for each enterprise-value:
- build awareness of the value
- build capability to enact support
- enact in practice at run-time
- assess and review
(for continual improvement)

72. Investors and
beneficiaries

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

74. Another useful assertion:
Every enterprise
is ‘for-profit’.
(We need to think of ‘profit’ in a much
broader sense than money alone.)

75. Investors and beneficiaries are often outside even of the
market – yet are still part of the same shared-enterprise.
Investor and beneficiary
shared-enterprise
includes community, government, non-clients, anti-clients, others
market
includes competitors, regulators, otherssupplier-
prospects
customer-
prospects
organisationsupplier customer
includes investors, beneficiaries

76. We need to consider
investments and returns
of every applicable type,
to and from
every type of stakeholder.
(‘Applicable type’ is determined
by the shared-enterprise values.)

77. A stakeholder
in the story
is anyone
who can wield
a sharp-pointed
stake
in your direction…
CC-BY-NC-SA evilpeacock via Flickr
Stakeholders in the enterprise
(Hint: there are a lot
more of them than you
might at first think…)

78. value-flow
(‘how’,
‘with-what’)
value-flow
(‘how’,
‘with-what’)
These are distinct flows – don’t mix them up!
values
(‘why’)
values
(‘why’)
profit
(money and more)
profit
(money and more)
Values, value-flow, money

79. Values-first enables full connection with shared-enterprise
Doing it right: values-first…

80. Money-first causes disconnect from shared-enterprise
Doing it wrong: money-first…

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

82. Layers of abstraction
for service views

83. Row-numbering aligns with Zachman
‘Rows’ – layers of abstraction
Enterprise
Scope
(context)
Business-
services
Service-
content
Service-
design
Service-
deployment
Action-
record
other other
other other
supplier customer
supplier customer
supplier customer
supplier customer
Enterprise identity, vision and values
Lists of key players and items in enterprise
Roles / relations between / within key players / items
Actions / transactions - implementation-independent
Actions / transactions - implementation-specific
Actions / transactions - operations-specific (action-plan)
Actions / transactions - as actioned / completed (past)
row-0
row-1
row-2
row-3
row-4
row-5
row-6

84. Each ‘row’ downward
adds something more
to the description.
Example:
row-3 is implementation-independent,
row-4 is implementation-specific.

85. These are not layers…
They’re related views into a shared scope
Business Architecture
Data
Architecture
Applications
Architecture
Technology
Architecture
(Information-Systems Architecture)

86. Layers in Enterprise Canvas
are layers of abstraction
within the same scope
- not arbitrary views into
different parts of the scope,
with arbitrary interconnections!

87. Row-0 is solely the enterprise-vision and (optional) values
Row-0 example - ZapaMex
“making
feet happy”
enterprise-vision as identified by ZapaMex

88. Row-1 is simple lists from Zachman interrogatives,
describing entities needed to make the enterprise happen
Row-1 example - ZapaMex
“making
feet happy”
Who What How Where When Why

89. Row-2 starts to show relationships across the enterprise
Row-2 example - ZapaMex
“making
feet
happy”
leather
supplier
ZapaMex
designer
overseas
market-
partner
shoe-
buyer
medical
partner
competitor

90. An overly-simplistic row-3, based on transactions only
Row-3 example - ZapaMex
receive
materials to
inventory
make shoes
store and
ready shoes
for shipment
obtain
materials
deliver
shoessupplier customer

91. Describe more of the row-3 detail for service-delivery
Row-3 example - ZapaMex
procurement
product-
development
+ marketing
receive
materials to
inventory
make shoes
store and
ready shoes
for shipment
sales and
service
accounts
payable
manage
budget,
operations
accounts
receivable
identify and
support
suppliers
obtain
materials
pay for
materials
identify and
support
customers
deliver
shoes
be paid for
shoes
supplier customer

92. Expand row-3 modelling out to the full enterprise-context
Row-3 example - ZapaMex
shared-enterprise
market
procurement
product-
development
+ marketing
receive
materials to
inventory
make shoes
store and
ready shoes
for shipment
sales and
service
accounts
payable
manage
budget,
operations
accounts
receivable
identify and
support
suppliers
obtain
materials
pay for
materials
identify and
support
customers
deliver
shoes
be paid for
shoes
supplier customer
gain supplier
respect
gain customer
respect
verify supplier
satisfaction
verify customer
satisfaction
gain / maintain market respect
gain / maintain enterprise reputation
verify market satisfaction
verify enterprise satisfaction

93. Rows 4, 5 and 6
add levels of implementation-detail.
Row 4: all implementation types.
Row 5: intended run-time set-up.
Row 6: what was actually used.

94. Internal structures
of services

95. We can view what services consist of in various ways
- but eventually we’ll need the full detail
Service-content

96. In rows 1 and 2 (lists, and basic relations between entities),
we can get away with the simple Zachman-interrogatives
Service-content
What How Where Who When Why

97. For rows 2 and 3 (implementation-independent),
we start to need to become more specific
Service-content
Capabilities
Locations
Functions
Assets
Events
Decisions

98. Asset (‘What’)
- a resource for which
the organisation acknowledges
responsibility
Composition:
any combination of asset-dimensions.

99. Function (external of ‘How’)
- external-facing interface,
responsible for service-contracts,
protocols, SLAs, etc;
accepts and returns assets
Composition:
any combination of asset-dimensions.

100. Location (‘Where’)
- a position within the terms of
a specific schema
Composition:
any combination of asset-dimensions,
plus time-as-location.

101. Capability (‘Who’ / ‘How’ / ‘What’)
- the ability to do something:
- agent enacts the capability
- action asset-type acted upon
- skill-level competence of the agent
Composition:
agent / action: asset-dimensions
skill-level: skills/decision dimensions
(also recursively composed of other services)

102. Event (‘When’)
- trigger for a function and
underlying capability
Composition:
any combination of asset-dimensions.

103. Decision / Reason (‘Why’)
- sensemaking / decision-making
for the service, and/or its type of
guidance or governance
Composition:
any combination of decision/skills
dimensions.

104. Seen from outside, function and service may seem the same:
service is the whole thing, function is just its external-interface
Function, capability and service
service
capabilities
function
(interface)

105. Starting in row-3, and downward to the real-world,
we must have the full detail of how all the elements intersect
Service-content

106. Most entities will consist of any appropriate combination
– e.g. book is physical ‘thing’, contains information, is valued
Asset dimensions
Assets
Phys
Virtual
Reln
Aspn
physical object, machine, geographic location etc
information, software-application, IP-address etc
link between people and/or to other tangible 'things'
person-to-virtual or virtual-to virtual link (brand etc)
Physical
Virtual
Relational
Aspirational
WhatAsset-types

107. is when they are slaves…
CC-BY-NC-ND littlejoncollection via Flickr
A warning on relational-assets…
- the only time that people are ‘assets’
“Our people are our greatest asset!”
The asset is the relationship
- not the person…

108. Most contexts will need to include combinations of these
Decision/skills dimensions
Decisions
simple, linear, true/false or limited-quantitative
complicated, linear but allow for delays, feedback
complex, ambiguous, non-linear, 'wild-problems'
uniqueness, extreme-uncertainty, 'chaotic'
Rules
Algor’m
Guideln
Princpl
Rule-based (trainee)
Algorithmic (apprentice)
Guidelines (journeyman)
Principle-based (master)
WhyDecision/skill-types

109. Decision/skills dimensions
Decisions
simple, linear, true/false or limited-quantitative
complicated, linear but allow for delays, feedback
complex, ambiguous, non-linear, 'wild-problems'
uniqueness, extreme-uncertainty, 'chaotic'
Rules
Algor’m
Guideln
Princpl
Rule-based (trainee)
Algorithmic (apprentice)
Guidelines (journeyman)
Principle-based (master)
WhyDecision/skill-types
IT
not ITNote that IT can’t do everything…

110. Human decision/skills have a distinct development-pattern
Decision/skills dimensions

111. Architects can use this as a graphical checklist
to describe the content and structure of all services.
(Also illustrates that Zachman needs an entire extra dimension…)
Service-content

112. Products as exchanges
between services

113. Products are exchanged between services
Exchanges
Service Product Service

114. A product
is an outcome of service
and the promise
of future service or self-service.

115. Products / exchanges are always (sets of) assets,
composed of combinations of the asset-dimensions.
Exchanges as assets
Assets
Phys
Virtual
Reln
Aspn
physical object, machine, geographic location etc
information, software-application, IP-address etc
link between people and/or to other tangible 'things'
person-to-virtual or virtual-to virtual link (brand etc)
Physical
Virtual
Relational
Aspirational
WhatAsset-types

116. Views across service-boundary
• Outside-out: Big-picture ‘world’, beyond even the market
• Outside-in: View from ‘outside’ into organisation
• Journey: Touchpoints between ‘outsider’ and organisation
• Inside-out: View from the organisation’s perspective
• Inside-in: View of the organisation to inside itself

117. Cycles of interaction
between services

118. Overall flow of service and exchange follows a consistent cycle
The service-cycle
boundary of ‘market’
in conventional
business-models
Shared-purpose defines the service-context
Reputation / trust
Respect / relations
Attention / conversation
Transaction / exchange
(profit / value-return)
Completion
Reaffirmed trust

119. Much the same themes apply to shared-enterprise and market
Enterprise and service-cycle
shared-enterprise
includes community, government,
non-clients, anti-clients, others
market
includes prospects, competitors, regulators, others
transaction
organisationsupplier customer
Reputation / trust
Respect / relations
Attention / conversation
Transaction / exchange
(profit / value-return)
(completion)
(reaffirmed trust)

120. The service-cycle applies across all of these connections
Enterprise and service-cycles
shared-enterprise
market
procurement
product-
development
+ marketing
receive
materials to
inventory
make shoes
store and
ready shoes
for shipment
sales and
service
accounts
payable
manage
budget,
operations
accounts
receivable
identify and
support
suppliers
obtain
materials
pay for
materials
identify and
support
customers
deliver
shoes
be paid for
shoes
supplier customer
gain supplier
respect
gain customer
respect
verify supplier
satisfaction
verify customer
satisfaction
gain / maintain market respect
gain / maintain enterprise reputation
verify market satisfaction
verify enterprise satisfaction

121. Different stages of the cycle emphasise different asset-types
(overall cycle needs to complete for trust to be maintained)
Asset-dimensions and service-cycle
shared-purpose (aspirational)
relationship (relational)
conversation (virtual)
transaction (physical)
(delivery of service)
(completion of actions)
(completion for provider)
(completion for customer)
(completion for enterprise)
(reaffirmed trust)

122. Every instance of service is also a project in its own right
Project-cycle and service-cycle
Performance
(adjourning)
reporting etc
Purpose
(forming)
strategy etc
People
(storming)
HR etc
Preparation
(norming)
scheduling etc
Process
(performing)
production etc

123. An adaptation of Five Elements describes service-lifecycles
Five Elements and enterprise

124. Identify the elements that help to pull from one phase to next
Five Elements and service-cycle
Performance
Purpose
People
Preparation
Process
PoliciesValues
Events
Completions
Success
(start here)
Trust /
Commitment
(Initiating-Events)
(Completion-Events)

125. ‘Inside’ child-services of Enterprise Canvas shown to left;
‘outward-facing’ child-services shown to right.
Service-cycle and Enterprise Canvas
value-
proposition
value-
creation
supplier /
customer
channels
supplier /
customer
relations
value-
governance
value-
outlay / return
Purpose
Preparation
Performance
Values
Events
Success
Process
People
Policies
Completions
Values
Events
Completions
Success
Policies
Perform
ance
Purpose
People
Prepara
tion
Process
enterprise
vision Trust
Trust

126. Similar exchanges apply across every interchange and flow
Exchanges everywhere…

127. Wrapping-up…

128. Restate that assertion:
Everything in the enterprise
is or represents a service.
(If so, we can describe anything
in the shared-enterprise
with Enterprise Canvas.)

129. Remember, though,
that architecture is always
about more than structure, or IT…

130. …it’s always about people…
…making sense of the enterprise, together.Photo © Michael Smith Castillo

131. The aim of all architecture:
things work better
when they work together
on purpose

132. What will you do
to help make that happen?

133. Thank you!

134. Contact: Tom Graves
Company: Tetradian Consulting
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: • Mapping the enterprise: modelling the enterprise as services
with the Enterprise Canvas (2010)
• The service-oriented enterprise: enterprise architecture and
viable services (2009)
• Doing enterprise-architecture: process and practice in the
real enterprise (2009)
Courses: See post ‘Upcoming EA tour in Australia’ for details on
workshops, masterclasses and other events in Sydney, Perth
and Melbourne, October-November 2015
Further information: