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.
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)
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
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â
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!]
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
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â
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!
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
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!
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
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
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
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
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!
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
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
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.