Why do enterprise-architecture fail? Three of the most common causes are: -- Blurring between the distinct rolesof architecture and design -- Starting architecture too lateand/or finishing too early in the process for making something real -- Placing arbitrary constraintson content, scope and/or scale Each of these errors causes the architecture to fragment and then fail. In this slidedeck, we explore the causes for each of these errors, why they occur, the effects that the errors have, and what to do to avoid them.

1. How architectures fail, and what to do
about it
Tom Graves, Tetradian
The Bridge, June 2021

2. Hi.
I’m Tom.
(yeah, I’ve
been around
for a while…)

3. These days I’d describe myself as
a travelling salesman
for useful ideas...
and perhaps also as
a maker of tools for change

4. Three common causes for
architecture failure:
#1: Blurring between distinct roles
of architecture and design
#2: Starting architecture too late
and/or finishing too early
#3: Placing arbitrary constraints
on content, scope and/or scale

5. We’ll use
a modified
(service-
oriented)
version of the
Zachman
frame
to illustrate
these fails
Row-0 ‘Enterprise’ is in
‘unchanging future’,
and should not change;
Row-6 ‘Action-record’
is in the ‘unchangeable
past’, and cannot
change
(Only the layers / rows
are shown here – for
this purpose, we’ll only
need Zachman-like
columns to describe
Fail #3)

6. Each layer downward brings us closer to reality

7. Fail #1:
Blurring between distinct roles
of architecture and design

8. Architecture and design
are two distinct types of task
within a process of realisation…
- a process of change to take an
abstract intent and make it real

9. Each layer downward brings us closer to reality

10. The change-process is iterative,
going up and down the stack…
- things are usable to the extent that
they’re ‘architecturally-complete’
- things are re-usable to the extent
that they’re ‘architecturally-incomplete’

11. ‘Architecturally-complete’ means that
we can give exact real-world answers
to each of the Zachman questions:
- Who?
- What?
- When?
- Where?
- How?
- Why?

12. So what are
architecture and design?
- what are the differences in their
tasks?

13. Architecture is…
“fundamental concepts or properties of a
system in its environment embodied in its
elements, relationships, and in the
principles of its design and evolution”
(source: IEEE-1471)
[...and as a verb, the processes of development for these items]

14. Architecture is also…
“an exercise in narrative... a vehicle for
the telling of stories, a canvas for relaying
societal myths, a stage for the theatre of
everyday life”
(source: Matthew Frederick, ‘101 Things I Learned In Architecture School’)
[Don’t ignore this - the architecture won’t work without it!]

15. Architecture
connects back
‘upwards’ to the
broader-scope
constraints, and
refines them for
the current layer

16. Design is…
“specifications towards implementation, in
accordance with defined constraints, and
at the requisite level of detail for the
current stage of realisation”
(source: Tom Graves)
[...and as a verb, the processes of development for these items]

17. Design adds the
detail needed
for the current
layer, reaching
‘downwards’
towards the real

18. Note:
the design at each layer also provides
the architecture for the next layer down
towards reality

19. If we consider each
layer as a distinct
viewpoint, then
architecture and
design represent
distinct views that
are available from
each and all of
those viewpoints

20. Architecture and design
are different tasks…
...don’t mix them up!

21. Core architecture questions:
- What are the underlying vision,
values, desires, drivers, stories?
- For options, what are the constraints,
boundaries, laws, standards?

22. Architecture is not design...
if we only do architecture,
we get stuck in analysis-paralysis,
never getting any closer to reality

23. Core design questions:
- Given the constraints, what is the
most effective option?
- Given the constraints, what is the
best way to make that option real?

24. Design is not architecture...
if we only do design, we wander
out of scope, build on untested
assumptions, or get stuck with
‘vendor-driven architecture’

25. Architecture and design
are different tasks…
...don’t mix them up!

26. How to avoid Fail #1:
Blurring between distinct roles
of architecture and design

27. Architects work most on architecture,
but also do some design
Designers work most on design,
but also do some architecture
Be clear at all times which type of task
you’re doing – they’re not the same!

28. At all times, remember which layer
you’re working on, and the type of
content and detail that it requires
– the layers are not the same!

29. At all times, remember which way you
face, either ‘upwards’ for architecture,
‘downwards’ for design
– their tasks are not the same!

30. Fail #2:
Starting architecture too late
and/or finishing too early

31. Architecture and design
will iterate up and down the
realisation-stack…
- Start too late: ignoring upper layers
- Finish too early: no support for final
stages of realisation

32. Enterprise-
architecture
must address
the whole of
the realisation-
stack – or else
the overall
architecture will
fragment

33. Classic ‘EA’
only covers
part of the
realisation-
stack -
‘logical’, plus
some of
‘physical’ and
‘conceptual’

34. A question of timescales:
- Classic ‘EA’: c.1-5 years
- Engineering: c.5-50 years
- Human: c.0-100 years
- Real EA: microseconds to millennia

35. If we only have a
partial architecture,
covering only part of
the real timescale,
how will the whole
realisation-process
work, with nothing to
hold it together?

36. Partial architectures are not
enough to make this work…
If the connections from abstract
to real are not complete,
across all requisite timescales,
the architecture will fail!

37. To support continual-iteration,
architecture and design
must support the entire lifecycle…
This must include run-time, task-
outcomes and decommissioning

38. We do this bit!
(No idea – it’s
nothing to do
with us…)
We tell others
how to do this
bit
Not our
problem –
let them
deal with it
Architecture
done wrong...

39. Architecture
done right…
We do this bit!
We are also
responsible
for this bit
We advise
others on the
architectures
for this bit
We learn
from this bit

40. A simple guideline:
If you can’t decommission it,
don’t build it!

41. If decommission is ignored, the
plan/build process becomes a
machine for creating technical-
debt...
- decommissioning must be
included in the architecture!

42. How to avoid Fail #2:
Starting architecture too late
and/or finishing too early

43. TOGAF done wrong
Time to look at
all the shiny
new toys!
Tedious
paperwork that
doesn’t matter and
no-one reads
Where we get to
do the fun bit!
The final design,
which is perfect,
of course
The boring bit
where we have
to keep telling
people that
they’ve got the
design wrong

44. TOGAF done right
Benefits-realised,
lessons-learned,
tasks to reduce
technical-debt
Essential setup to
connect to earlier
architecture-work
Our part of the
architecture
responsibility
Demonstrator
design showing
how to align to
the architecture
Help people
ensure that their
designs and
design-choices
do align with
architecture
constraints and
guidelines

45. If a classic ‘EA’ must
run as a separate
entity, ensure that it
has adequate hooks
into architecture and
design for all other
parts of the realisation-
stack, maintained by
other business units

46. Fail #3:
Placing arbitrary constraints
on content, scope and/or scale

47. We need to include in the architecture
all of the Zachman columns:
Who? What? When? Where? How? Why?
But we need to do it properly
- there’s an entire dimension missing
from the Zachman framework...

48. C
a
p
a
b
i
l
i
t
i
e
s
L
o
c
a
t
i
o
n
s
F
u
n
c
t
i
o
n
s
A
s
s
e
t
s
E
v
e
n
t
s
D
e
c
i
s
i
o
n
s
What How Where Who When Why
C
a
p
a
b
i
l
i
t
i
e
s
(
a
g
e
n
t
/
a
c
t
i
o
n
s
)
L
o
c
a
t
i
o
n
s
F
u
n
c
t
i
o
n
s
A
s
s
e
t
s
C
a
p
a
b
i
l
i
t
i
e
s
(
s
k
i
l
l
-
l
e
v
e
l
)
E
v
e
n
t
s
D
e
c
i
s
i
o
n
s
Asset-types:
Physical
Virtual
Relational
Aspirational
Abstract
Decision/skill-types:
Rule-based
Algorithmic
Guidelines
Principle-based
rows 1-2
rows 2-3
rows 3-6
Vision
row 0

49. That missing dimension in Zachman…

50. Asset-types apply in What, How, Where, When

51. Decision/skill-types apply in Who, Why

52. The realisation
process only
works properly
when all of those
dimensions are
fully present

53. Classic IT-centric ‘EA’ only works on a subset…

54. …if the architecture
and design will only
address this subset-
of-a-subset, how will
it connect up with
everything else in the
overall architecture of
the enterprise?
‘whole-enterprise’ EA
‘classic’
EA
Enterprise
Scope
(context)
Business-
services
Service-
content
Service-
design
Service-
deployment
Action-
record
row-0
row-1
row-2
row-3
row-4
row-5
row-6
FUTURE
NOW

55. On ‘enterprise-architecture’:
a subset is not the whole:
‘enterprise-wide IT-architecture’
is only one small subset of
‘the architecture of the enterprise’
- don’t mix them up!

56. Beware of ‘anything-centrism’!
IT-centrism is a serious problem in
enterprise-architecture – but so is
business-centrism and the like
The problem is not in IT itself, but in any
over-focus on a single arbitrary domain

57. Beware of frameworks and
methods that cannot link subsets
of architecture together!
Frameworks that cannot link together will
cause the architecture to fragment and fail

58. Many current
architecture-
frameworks are
‘something-
centric’ - they
embed arbitrary
hard-wired
constraints on
content, scope
and scale…

59. …but there is no
reason why this
has to be so –
we can instead
restructure the
framework to be
consistent for
any content,
scope and scale

60. Beware of IT-centrism, business-
centrism, all forms of ‘-centrism’
- all of them will cause the
architecture to fragment and fail

61. How to avoid Fail #3:
Placing arbitrary constraints
on content, scope and/or scale

62. Subsets are part of a larger whole
Most times we’ll only be working on
a subset, but we need to ensure that
it’s always connected to the whole
Ensure that the whole is always
maintained as the whole

63. Subsets are part of a larger whole
Build and maintain ‘hooks’ that can
connect each aspect of change to
the broader whole
Do this for every stage throughout
the realisation-stack

64. Subsets are part of a larger whole
Specialism in frameworks is often
useful, but we must ensure that they
‘play nice’ with all other specialisms
Take active steps to guard against any
and all forms of ‘anything-centrism’

65. Subsets are part of a larger whole
Wherever practicable, use tools and
frameworks that are self-adapting to
the needs of each context
Specialism in our frameworks needs to
be optional, not hard-wired!

66. Wrapping up...

67. Fail #1:
Blurring between distinct roles
of architecture and design

68. How to avoid Fail #1:
- Be clear about the differences
between architecture and design
- Know which to use at each moment
- Know which layer you’re working
on at each moment

69. Fail #2:
Starting architecture too late
and/or finishing too early

70. How to avoid Fail #2:
- Ensure that the whole realisation-
stack is fully covered
- If your architecture covers only part,
establish hooks to connect to the rest
- Include run-time and decommission
in the overall architecture

71. Fail #3:
Placing arbitrary constraints
on content, scope and/or scale

72. How to avoid Fail #3:
- Always start from the needs of the
context – not hardwired assumptions!
- Always connect across the whole
- Always beware of potential risks
from any form of ‘anything-centrism’

73. A final note:
Our real aim here is to improve
effectiveness across the whole:
“Things work better when
they work together, on-purpose”
http://weblog.tetradian.com/tagline-for-enterprise-effectiveness/

74. Why do architecture?
Because life is better for everyone
when things work better,
things work together,
things work more on-purpose,
as a more effective, unified whole.

75. Thank you!
tetradian.com