As enterprise architecture expands outward towards the full whole-enterprise scope, what tools and methods will we need? Presentation for IQPC Enterprise Architecture Summit, Sydney, 20-21 April 2021. (This slidedeck includes extensive links to further sources of information - blog-posts, videos and other slidedecks.)

1. Tools and techniques
for whole-enterprise architecture
Tom Graves, Tetradian
IQPC EA Summit, April 2021

2. Hi.
(yeah, I’ve been working in architectures
for maybe too many years now...?)
I’m Tom.

3. These days I’m best described as
a maker of tools for change...
also on the architecture of change,
linking strategy to execution
and back again, as needed...

4. Four themes for
whole-enterprise architecture…
1. About context and scope for EA
2. About fitness-for-purpose
3. About tools and fractality
4. About methods for whole-EA

5. Part 1:
A question of scope

6. The role of all architecture is
to ensure effectiveness
across the whole of the scope:
“Things work better when
they work together, on-purpose”

7. Over the years, the scope for
EA has expanded steadily from
IT-infrastructure to business-
architecture and beyond.
Let’s look at that history...

8. A bit of history: 1960s-1970s…
First usages of
the ‘architecture’
term in IT,
such as for the
IBM System/360
series
Image: Bundesarchiv, B 145 Bild-
F038812-0014 / Schaack, Lothar /
CC-BY-SA 3.0

9. A bit of history: 1980s…
IBM-PC etc
provide
standards
for hardware,
OS; also key
theory-elements
such as
Zachman’s
papers
Image: John Zachman via Wikipedia

10. A bit of history: 1990s…
Client-driven
demands for
improved IT-
effectiveness,
such as per US
Clinger-Cohen
Act
Image: CC-BY-SA MysteryBee via
Flickr

11. A bit of history: 2000s…
IT-architecture
now also covers
apps, data and
some aspects of
business, and is
lazily renamed
to ‘enterprise
architecture’
Image: Open Group

12. A bit of history: 2010s onward…
This ‘enterprise-
architecture’ now
aims to cover all
aspects of the
business and its
enterprise
Image: Alex Osterwalder et al

13. ...yet we’ve been here before...
- let’s look at that history too...

14. Dowding System: 1940
The ‘Dowding
System’ for UK
air-defence – full
integration of
process, people,
information-flow,
feedback,
redundancy and
more

15. Ford’s ‘integrated factory’: 1910
Henry Ford’s
‘integrated
factory’, from
raw-materials to
full lifetime of
finished product
(and waste-
management
too)

16. US railroad systems: 1860
US railroads –
mapping
physical-layout,
people and their
responsibilities,
business-
structure and
more

17. Roman Empire: CE100
Full integration
of resource-
management,
security,
economics,
politics and
more, across the
entire Empire

18. Enterprise-architecture as
the architecture of the enterprise
- every aspect of the enterprise,
whatever that enterprise may be

19. Need ‘architecture of architectures’
that’s consistent across:
every type of enterprise,
every scope and scale,
every type of content and context,
every stage of implementation,
every part of the change-lifecycle

20. Part 2:
A question of fitness

21. Do our current tools and techniques
have fitness-for-purpose for:
every type of enterprise,
every scope and scale,
every type of content and context,
every stage of implementation,
every part of the change-lifecycle

22. Short-answer:
No.

23. The main reason for unfitness:
a persistent scope-error
mistaking the scope for
enterprise-wide IT
with the scope for
the enterprise itself

24. One of these is not like the others…
• Data-architecture is the architecture of data
• Security-architecture is the architecture of security
• Process-architecture is the architecture of processes
• Business-architecture is the architecture of business
• Enterprise-architecture is the architectural-analysis for
detail-design of IT-infrastructure in large organisations

25. “Enterprise architecture
is solely the architecture
for enterprise-wide IT” ?
- hmm…
CC-BY-ND-SA ores2k via Flickr

26. …gonna hafta think about this one…
CC-BY-ND alexsemenzato via Flickr

27. Enterprise-wide IT-architecture
is only one small subset
of whole-enterprise architecture
(and it’s actually the easy bit...)

28. Scope of
enterprise-
wide IT…

29. Scope of
whole-
enterprise

30. what we need… what we have…

31. utter confusion…
Content-before-context causes confusion...
confusion…
IT-specific

32. The scope and architecture for
enterprise-wide IT
is not the same as
the scope and architecture for
the enterprise itself…
- don’t mix them up!

33. Other reasons for poor fitness:
• Over-emphasis on ‘state’
• Over-emphasis on certainty
• Optimised for mass-sameness
• Optimised for single timescales
• Fragmentation into ‘walled-gardens’

34. In most classic
change-models,
we contrast
‘current state’
and ‘future state’
- yet in the real-
world there is no
‘state’ – there is
only change
Concern: Over-emphasis on ‘state’

35. Concern: Over-emphasis on certainty
(after Damien Newman)
Key information is lost
for use in the ‘messy’
part of the next loop
Tools over-focus
on the ‘certainty’
part of the process

36. Concern: Optimised for sameness
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)
An acceptance of
uncertainty:
experiment, patterns,
probabilities, ‘design-
thinking’, unstructured
process, ‘human’...
certain uncertain

37. Concern: Optimised for single timescales
Like a forest, the
real-world has
many complex,
interleaving
timescales

38. Concern: Tools as ‘walled-gardens’
No connection
between tools –
causes fragmentation
Tools are scattered all
over the exploration-
space

39. • “Architecture is an exercise in truth”
- architecture is about structure
– (IT-architecture is often really good at this)
• “Architecture is an exercise in narrative”
- architecture is about story
– (IT-architecture is often really bad at this…)
We need balance between structure and story
‘Two points of view on architecture’
(adapted from Chapter 84, in Matthew Frederick, 101 Things I Learned In Architecture School, MIT Press, 2007

40. A quick recap:
What’s our current state of play?

41. Our sales-pitch to executives:
ensure and enhance effectiveness
across the enterprise as a whole,
adapting to and guiding change,
always ‘on-purpose’

42. Need effectiveness across the whole:
any form of local-optimisation is
Not A Good Idea…
(yet most current tools and methods for EA
are optimised only for specific domains
- mainly IT and ‘business-architecture’)

43. Our ‘architecture of architectures’
needs tools and methods that
work the same way everywhere
across a whole-enterprise scope
(and where everything links together
across the whole, always)

44. Yes, there’s
a lot to this
stuff about
‘whole-
enterprise’…

45. Don’t panic!

46. How to eat
an elephant?
…one bite
at a time!

47. For this too, it’s likewise
‘one bite at a time’
- yet each small bit linked into the whole,
each bit getting better at doing the work

48. Tools and methods must address:
• Any/all contexts, scopes, content etc
• Continual change, ‘statelessness’
• Certainty and uncertainty
• Mass-sameness and mass-uniqueness
• Any/all timescales, interleaving
• Integration across all ‘walled-gardens’
• Structure and story

49. Two questions to explore…
• What patterns, tools and guidelines
do we need for this work?
• What techniques and methods do we need,
to map each item of change, to do the right
things right, and learn from each action?

50. Part 3:
A question of tools

51. The core requirements again:
• tools able to address any type of
enterprise, any scope and scale, and
any content and context, stages of
implementation and change-lifecycle
• must help to link everything together
into a unified whole

52. An architects’ mantra:
“I don’t know” (but I know how to find out)
“It depends” (and I can find out what it depends on)
“Just enough detail” (not too little, not too much)
“Start anywhere” (everything’s connected!)
“Be honest, be kind” (everyone has their challenges)

53. Fractality is our friend…
Once we’ve
identified the
context, we can use
fractal-type ‘self-
similar’ patterns to
gather detail and
help connect across
the whole…
…tools that we can
use everywhere

54. Tools to help identify context:
• Visioning – identify the context-story,
values, guiding, principles, standards etc
• Layers – identify the core stakeholders
and required level or type of detail

55. Identifying context: Visioning
The vision or
story-descriptor
is the ultimate
anchor for
everything that
the enterprise is
and does – the
organisation then
links itself into
that story.
A three-part ‘story’ that makes sense to all enterprise-stakeholders
Elements of a vision-statement
Action (‘How’): what is being done to
or with or about the concern
Example: “Ideas worth spreading”
Qualifier (‘Why’): the emotive driver
for action on the concern
Example: “Ideas worth spreading”
Concern (‘What’): the focus of interest
to everyone in the shared-enterprise
Example: “Ideas worth spreading”

56. Visioning: Derive values, principles etc
Given the vision-
statement, we
can then derive
values and
principles that
can guide
decision-making
within the
organisation
Vision outlines the shared-story…
Principles devolve from values…
Value-propositions must align to
vision, values, principles…
Vision, role, mission, goal…
Values devolve from the vision…

57. Identifying context: Layers

58. Layers: Scope within the context
We can use a
layer-model to
identify which
parts of the
overall context
we will address
(Note that ‘classic’
EA will address only
a subset of these
layers)

59. Layers: Types of stakeholders
The layers that
we choose also
help us identify
the types of
stakeholders
that we will need
to work with and
consult

60. Fractal-checklist tools for content:
• Holomap – describe transactions,
interactions, dependencies, relationships
• SCORE – identify strategic options
• SCAN – model the complexity in context
• Service Canvas – describe services, service-
content and service-relationships

61. Identifying content: Holomap
The B(I)DAT-
stack used in
TOGAF etc is
just one context-
specific instance
of the more
generalised
pattern of the
Holomap
B(I)DAT-stack
Holomap
pattern

62. Holomap: Business-architecture
The Holomap
pattern also
shows why the
‘Business-
Architecture’
description in
TOGAF does not
work well for
business itself…
BIDAT-stack
Holomap
Business-
architecture
Holomap

63. Holomap: Both ‘outward’ and ‘inward’
The complete
Holomap pattern
also extends
downward,
fractally, into the
detail for
implementation
and action

64. Holomap: Organisation and enterprise
When the
‘service-in-focus’
for a Holomap is
the organisation
as a whole, the
pattern looks like
this…

65. Holomap: Implementation-detail
…where the
pattern for real-
world detail of
implementation
– for which the
BIDAT-pattern is
only one subset
– would look
more like this…
applications,
data etc
technology,
infrastructure,
agents etc
purpose,
guidance etc
scope of
BIDAT

66. Holomap: Adapt to context
It’s a checklist-
pattern, so we can
adapt it to more
complex contexts
such as a business’
IT-organisation…
IT-organisation
relationship-pattern
travel-ecommerce
relationship-pattern
…or a multi-partner
ecommerce
transaction-space

67. Holomap: Mapping responsibility
We can also merge
the Holomap with
other fractal-
compatible tools,
such as in linking
Holomap with RACI
to map the
organisation’s types
of responsibilities
with its stakeholders

68. Identifying content: SCORE
SCORE
(Strengths,
Challenges,
Options,
Responses,
Effectiveness)
provides a
consistent means
to explore
strategic choices
This work is licensed under the Creative Commons Attribution-ShareAlike 4.0
International License (CC BY-SA 4.0).
To view a copy of this license, visit https://creativecommons.org/licenses/by-sa/4.0/
Tetradian www.tetradian.com
Project By Date
Versio
n
SCORE
strengths
Strengths / Services / Support
(existing capabilities and resources, potential for
synergies)
challenges
Challenges / Capabilities-needed
(‘weaknesses’ indicate needed capabilities and
resources)
options
Options / Opportunities and risks
(opportunity is also risk, risk is also opportunity)
responses
Responses / Returns / Rewards
(probable or emergent consequences of action or
inaction)
effectiveness
default: efficient, reliable, elegant,
appropriate, integrated
focus-question

69. SCORE: Provenance of choices
With SCORE, we
move around the
space, linking
ideas to feedback
and actions, and
building a trail of
provenance for
each choice along
the way
This work is licensed under the Creative Commons Attribution-ShareAlike 4.0
International License (CC BY-SA 4.0).
To view a copy of this license, visit https://creativecommons.org/licenses/by-sa/4.0/
Tetradian www.tetradian.com
Project By Date
Versio
n
SCORE
strengths
Strengths / Services / Support
(existing capabilities and resources, potential for
synergies)
challenges
Challenges / Capabilities-needed
(‘weaknesses’ indicate needed capabilities and
resources)
options
Options / Opportunities and risks
(opportunity is also risk, risk is also opportunity)
responses
Responses / Returns / Rewards
(probable or emergent consequences of action or
inaction)
effectiveness
default: efficient, reliable, elegant,
appropriate, integrated
focus-question

70. Identifying content: SCAN
SCAN helps us to
map out types and
levels of uncertainty
before, during and
after the action at a
given ‘NOW’

71. SCAN: Resolve uncertainty
One use for SCAN
is to help identify
reducible-
uncertainty to
resolve before
action, versus
non-reducible
uncertainty that
can be resolved
only at run-time
reducible
uncertainty
non-reducible
uncertainty
purported
certainty

72. Identifying content: Service Canvas
A consistent,
symmetric, fully-
fractal way to
model every
type of activity in
the enterprise as
services and
their exchanges
support-
services
child-services
within the
service
(Note: Service Canvas is
also known as Enterprise
Canvas)

73. Service Canvas: Crosslink to Holomap
Support-services
in Service Canvas
link into different
parts of the
respective
Holomap and its
relationships:
transaction,
direct-interaction,
indirect-
interaction

74. Service Canvas: Crosslink with SCAN
Child-services
within each
Service Canvas
crosslink to the
‘before, during,
after’ of SCAN,
and other fractal
models such as
Service Cycle
‘before, during, after’ as in SCAN

75. Service Canvas: Service-content
Service Canvas
includes a
consistent way to
describe service-
content and
structure-
elements,
crosslinked to
context-layers

76. Reprise on core requirements:
• every type of enterprise, any scope and
scale, any content and context, stages of
implementation and change-lifecycle
• link everything together into a unified whole
• fractality is our friend in all of this

77. Part 4:
A question of method

78. Core requirements for method:
• works the same way everywhere
• work with every type of enterprise, any
scope, scale, content, context, stage
of implementation, change-lifecycle
• link everything into a unified whole

79. CAUTION:
current ‘EA’ methods will often:
• work well for only one type of context
• work well for only one type of enterprise,
scope, scale, content, context, stage of
implementation, or change-lifecycle
• create fragmented ‘walled-gardens’

80. Down to details for method...
• connect strategy to real-world action
• connect big-picture to fine-detail
• keep the whole in mind at all times
(Note: fractality is our friend for this
- the naturally recursive nature of tasks)

81. Rethinking tasks: Task…
On a Gantt-
chart, we would
show the task
just as a labelled
box…

82. Rethinking tasks: Action
Looking inside
the box, we’d
describe the
Action via a
work-instruction
– a set of mini-
tasks…

83. Rethinking tasks: Action and results
We’ll also need
to track the
outcomes of the
task: the records
of action, and
any variances,
incidents and
insights
arising…

84. Rethinking tasks: Plan and Action
Each task will
need its own
Plan, to resolve
uncertainties,
identify desired
outcomes and
records, and set
up for action…

85. Rethinking tasks: Context and Scope
We’ll need to
ensure that we
know the Scope
and Context for
the action – and
if we don’t know
what these are,
stop until we do
know them…

86. Rethinking tasks: Review and learn
The task is not
complete until
we’ve verified
benefits-realised,
identified the
lessons-learned,
and logged any
tasks-arising…

87. TOGAF does also follow this pattern…
The TOGAF ADM
(Architecture
Development
Method) does
sort-of follow
the same overall
pattern, if with
some parts
hardwired to an
IT-only focus
Context
Scope
Plan
Action
Review

88. what we have now… what we need for this…
…though it does need to be fully fractal

89. Dependencies drive the pattern...
• learning depends on info from action
• action depends on plan and preparation
• planning depends on awareness of scope
• scope for action depends on context
• successful outcomes depend on
doing the right things right,
and improving every time

90. “Do all of this
for the whole enterprise?
- that’s impossibly huge!”
Actually, no, it’s not that hard,
if we remember that one simple trick…

91. How to eat
an elephant?
…one bite
at a time!
(But remember
that it’s always a
whole elephant…)

92. Maturity-Model shows where to bite next…

93. All we have to do is
keep going, keep going,
one step at a time
- then fractality, consistent tools
and consistent methods
will do the rest for us
(mostly, anyway…)

94. Change-mapping provides a
consistent method to do this:
• guide and keep track of change-tasks,
and their provenance and outcomes
• keep track of all interdependencies
within and between change-tasks, and
guide use and re-use of task-outcomes

95. We hide the complexity via
separation of concerns and
separation of roles:
• roles such as Explorer, Pathfinder and
Reporter tackle the tasks for the context of
each mission and its underlying issue
• roles such as Librarian, Coordinator and
Architect tackle connection across all tasks

96. Think of it as like
the departments
in a factory…
1. Context
2. Scope
3. Plan
4. Action
5. Review
…an iterative,
recursive cycle
of change…
…everything
shared in the
centre and its
repository

97. Context-neutral tools and methods
as used in Change-mapping
connect everything, consistently,
across every part of the enterprise
- and keep it simple enough for
everyone to use, everywhere

98. Keep it simple with a folder metaphor
Missions act as
containers for each
set of tasks and
their sub-tasks
(tasks and their folders
may be nested to any
depth that we need)

99. A core concept:
everything is a plug-in tool
(even the method itself is just another plug-in tool…)
Use fractality, dependencies, layering
to link big-picture, context-neutral tools
to all those context-specific tools
that we need for detailed design

100. Use any tool as a plug-in
Every use of a tool is a ‘mini-task’ in its own right,
following the same pattern, invoked in the same way,
with its results stored in the respective folder

101. Change-mapping is already
proven in practice, using paper
forms and physical folders
- what’s needed next is the right software
toolset, such as an expanded Gantt-chart
with fully-fractal task-nesting, task-linking,
plug-in tools and central repository
(any developer interested in this, please get in touch with us!)

102. Books on Change-mapping
Published March 2020 Published March 2021 (to be published early 2022)

103. Wrapping up...

104. As enterprise-architects, we can
address a whole-enterprise scope
- any type of enterprise, at any scale,
any context, any type of content, whatever
Let’s do this!
- and link everything together, consistently,
in any way that we need

105. Three takeaways:
1.The purpose of EA is enterprise effectiveness
2.EA must be able to extend to whole-enterprise
3.Tools and methods to do this do already exist
(so let’s use them, make them easier to use)
Conversations on this need to happen
– let’s make them happen!

106. Thank you!

107. Further information (page 1 of 5)
• (Slide 04) Post-series 'Towards a whole-enterprise architecture standard': summary at
http://weblog.tetradian.com/2016/06/06/towards-a-whole-enterprise-architecture-standard-
summary/
• (Slide 06) Enterprise-effectiveness: post 'A tagline for enterprise effectiveness',
http://weblog.tetradian.com/2015/06/02/tagline-for-enterprise-effectiveness/
• (Slide 14) Wikipedia on Dowding system: 'Dowding system',
https://en.wikipedia.org/wiki/Dowding_system
• (Slide 23) IT-centrism: 'IT-centrism and real-world enterprise-architecture',
http://weblog.tetradian.com/2014/03/24/it-centrism-and-real-world-ea/
• (Slide 31) Confusion from the 'BDAT-stack': 'On business-architecture and enterprise-architecture',
http://weblog.tetradian.com/2017/07/03/on-ba-and-ea/
• (Slide 32) Consequences of IT-centrism: 'How IT-centrism creeps into enterprise-architecture',
http://weblog.tetradian.com/2012/01/30/how-it-centrism-creeps-into-ea/
• (Slide 34) Over-emphasis on 'state': 'The no-plan plan: Architecture dynamics',
http://weblog.tetradian.com/2011/10/21/the-no-plan-plan-architecture-dynamics/’

108. Further information (page 2 of 5)
• (Slide 36) Slidedeck 'Same and different: architectures for mass-uniqueness',
https://www.slideshare.net/tetradian/same-and-different-architectures-for-massuniqueness
• (Slide 35) Post 'Documenting the Not-known',
http://weblog.tetradian.com/2018/05/06/documenting-the-not-known/
• (Slide 36) Post 'Scalability and uniqueness', http://weblog.tetradian.com/2013/04/24/scalability-
and-uniqueness/
• (Slide 37) Post 'More on backbone and edge', http://weblog.tetradian.com/2013/05/04/more-on-
backbone-and-edge/
• (Slide 37) Slidedeck 'Backbone and edge: Architecting the balance between continuity and
change', https://www.slideshare.net/tetradian/backbone-and-edge-architecting-the-balance-
between-continuity-and-change
• (Slide 38) Tools as walled-gardens: slidedeck 'Disintegrated enterprise-architecture?',
https://www.slideshare.net/tetradian/disintegrated-enterprisearchitecture
• (Slide 38) Post 'Toolsets, pinball and un-dotting the joins',
http://weblog.tetradian.com/2015/01/16/toolsets-pinball-and-undotting-joins/

109. Further information (page 3 of 5)
• (Slide 39) Slidedeck 'The enterprise is the story', https://www.slideshare.net/tetradian/the-
enterprise-is-the-story-54141263
• (Slide 44) Slidedeck 'Whole-enterprise architecture',
https://www.slideshare.net/tetradian/wholeenterprise-architecture
• (Slide 48) Post 'Towards a whole-enterprise architecture standard – 3: Method',
http://weblog.tetradian.com/2016/04/27/towards-a-whole-enterprise-architecture-standard-3-
method/
• (Slide 48) Post 'Towards a whole-enterprise architecture standard – 4: Content',
http://weblog.tetradian.com/2016/05/01/towards-a-whole-enterprise-architecture-standard-4-
content/
• (Slide 52) Post 'An enterprise-architects' mantra', http://weblog.tetradian.com/2014/04/18/an-ea-
mantra/
• (Slide 54) Video 'Introduction to visioning', https://youtu.be/z0ybs2VOI-M
• (Slide 56) Post 'Services and Enterprise Canvas review - 4: Layers',
http://weblog.tetradian.com/2014/10/24/services-and-ecanvas-review-4-layers/

110. Further information (page 4 of 5)
• (Slide 61) Video 'Introduction to Holomap stakeholder-mapping', https://youtu.be/dZWFYbGcVgQ
• (Slide 68) Slidedeck 'What's the SCORE?', https://www.slideshare.net/tetradian/whats-the-score-
how-to-make-sense-of-a-business-change
• (Slide 68) Video 'Introduction to SCORE', https://youtu.be/SdkhYl7ae0M
• (Slide 70) Video 'Introduction to SCAN complexity-map', https://youtu.be/qvgBIXItVYw
• (Slide 72) Video 'Introduction to Enterprise Canvas core', https://youtu.be/vcaeDwPtsJY
• (Slide 72) Video 'Introduction to Enterprise Canvas support-services',
https://youtu.be/1XscaHoNVTs
• (Slide 72) Post-series ''"Services and Enterprise Canvas review': summary at
http://weblog.tetradian.com/2014/10/29/services-and-ecanvas-review-summary/
• (Slide 75) Post 'Services and Enterprise Canvas review – 5: Service-content',
http://weblog.tetradian.com/2014/10/27/services-and-ecanvas-review-5-service-content/
• (Slide 81) Post 'Architecture basics: The structure of a task',
http://weblog.tetradian.com/2021/03/26/architecture-basics-the-structure-of-a-task/

111. Further information (page 5 of 5)
• (Slide 92) Slidedeck 'Stepping-stones of enterprise-architecture',
https://www.slideshare.net/tetradian/steppingstones-of-enterprisearchitecture-process-and-
practice-in-the-real-enterprise
• (Slide 94) Video 'Introduction to Change-mapping', https://youtu.be/uey79fSYSNM
• (Slide 102) Change-mapping Books website: http://weblog.tetradian.com/2021/03/26/architecture-
basics-the-structure-of-a-task/