Today, the wonderfully clever
Kevin Smith of
PEAF fame began a discussion in
the Australasian Architecture Network LinkedIn Group.
If I understood
Kevin correctly, the general ideas of the discussion were
that EA practitioners should be looking at "taking the architecture
[conversation] up the food chain (out of project land and IT and into
management)." I broadly agree with the view that EA should be part of the
organisational management conversation but I would say it slightly differently.
I would say that we should "push the conversation up to management AS WELL
AS into project land and IT" and indeed onto all relevant parts of your
business.
Kevin makes an insightful comparison between
Deming &
TQM, against
Zachman and
EA.
Kevin "advocate[s] that anyone involved in EA should adopt
this approach for explaining EA in order to get organisations to adopt
it." It is an adept comparison of methodology but I do not agree that it
is a good way to explain EA to management.
I simply think that it is an unnecessarily complicated approach to the task.
Indeed, this over-complication is something that we EA practitioners can often
been guilty of. It is understandable that we tend toward highly evolved language
because we need precise semantic meanings to communicate with each other and
with technical experts. So we tend to use specific and highbrow language but
(and I have no doubt that
Kevin would agree with this) we should really be
striving to use language that best communicates our meaning to the person we
are speaking to. I also believe that EA can be described to most people in very
simple terms.
Is it not enough to explain EA to executives by saying, "EA (verb) is a
decision support tool. The enterprise architecture (noun) provides an
evidence-basis to support decision-making. EA can help executives make
decisions about strategy and it can help implementers make decisions about how
to implement."?
When EA practitioners say "domain modelling", can we not explain
it to most stakeholders as "a way to put things into categories so that we
can sort them and identify where there is either too much or too little of each
type of thing. This can also help us understand the costs and risks for each
category."?
When EA practitioners say "reference architecture", can we not
explain it to most stakeholders as "a system for sorting things, like the
Dewey Decimal System used in a library to help you sort types of books."?
When EA practitioners say "alignment mapping", can we not explain
it to most stakeholders as "a way of showing how things connect, like the
parts list and assembly instructions in an IKEA product."?
In these days, where optimizing customer experience is essential for
success, EA practitioners really need to think, "how can we optimise the
experience of the customers of the EA services that we provide."
Famed architect
Vitruvius’ wrote in his book “
De Architectura” way back in
15 BC that all architecture must be 3 things: “useful, solid, beautiful.”
Simple forms of communication lead to each of these 3 fundamental goals.
