Learning Center
Plans & pricing Sign in
Sign Out




Evaluating Enterprise Architecture Processes
Enterprise architecture literature - books, blogs, websites, frameworks,
and other materials provide much direction and insight on how to
evaluate an enterprise architecture, or why one should be
produced to some degree of formalism. Very few comment on how
to do enterprise architecture - specifically how to practice EA -
beyond the usual: avoid ivory towers | it's all about technology |
it's all about the business | it's all about people | it's all about
processes | it's all about the code | it's all about requirements | it's
agile | it's not agile | it's all about governance | it's all about
frameworks | it's all about the get the picture...
I'm taking a bit of a counterintuitive tack here and am presenting a
list of issues that one could use as a starting point for evaluating
enterprise architecture process - not the EA itself, but the
processes involved in defining what enterprise architects produce,
and when they do so.
Each of these issues has varying weight in any given organization,
from none to huge, so I'm not presenting this list as either all-
inclusive or prioritized in any manner. Rather, they are furnished to
allow you to begin thinking about how this specifically works in

your own organizations and situations, or help you better evaluate
a potential employer or client when you are interviewing with them.
Factor 1: Is EA a distinct function in the organization? This is not an
issue about whether EA is part of IT, the business, or both. It's an
issue about whether EA is a distinct, recognized function in the
organization that is not just listed in the organization chart, but has
defined and formal responsibilities to management and various
constituencies that are being served.
Factor 2: Does the EA group have both functional and technical
responsibilities and generate actionable outputs to both? Too many
organizations skew to one of these sides at the expense of the
other, and that's not really EA, it's business analysis if skewed
toward functional and solution/software/technical architecture if
leaning toward the IT side. The issue to evaluate here is how EA
horizontally crosses an organization and delivers value to business
and technical groups. If there are gaps between the functional and
technical sides of the organization with respect to EA, what are
they and how can they be closed?

Factor 3: How is EA specifically funded? I commented in more
depth on this previously, and the answers you receive here may be

very revealing. A firm commitment to EA as practice also requires
organizations to fund it properly and consistently. My general rule-
of-thumb here is that the more informally EA is funded, the less
seriously it's taken by management and constituents, with the
inevitable results. Such schemes also make EA vulnerable to
cutbacks or being dissolved when times get rough for the
organization, regardless of the competency or contributions of the
EA group.
Factor 4: How are EA outputs received and utilized by the
organization? EA groups serve multiple constituencies that present
complex and unique challenges. As I have argued in the past, EA
output must be actionable by others in the organization to have
any value beyond the EA function itself. If EA is producing view-
and-instantly-forget presentations for the business, or expansive
and detailed models that immediately hit the binder and shelf after
printing, there is usually a big problem, and it's not with the
business, the developers, the project managers, or the rest of the
IT department.
Factor 5: How skewed are EA efforts toward specific vendors
and/or integrators? All IT departments have a natural bias toward
specific products and services because that's what's running 24x7

in the data center, so it's a known commodity and the IT staff is
competent and comfortable with the products. That isn't the issue -
rather, the issue is the presence of dogma, and the inability to
conceptualize, design, and execute architectures and technical
solutions that fulfill business needs using different approaches,
tools, and products. This factor deals more with narrow-minded
viewpoints that cause multiple misses of the 'bigger picture' rather
than suggesting the design and implementation of a baroque
patchwork of systems that are difficult to integrate, deploy, and
Factor 6: Does the EA organization set IT standards, and if so, how
are they specifically enforced (and exceptions made)? It's one thing
to set standards, and quite another to enforce them and make
exceptions for valid reasons. EA groups that spend much time
creating standards that nobody can or will follow speaks volumes
about the state of EA in that organization. While authority over such
matters is important, how the authority is used is even more so.
Factor 7: What is the relationship between EA and the business?
Successful enterprise architects and their organizations have a
mutually-satisfactory relationship with the business. This includes

intangibles such as trust, understanding of people and issues, and
balancing business needs with technology solutions and direction.
Factor 8: What is the relationship between EA and IT
management? IT management is another critical constituency to
enterprise architects, and if architects are present for the wrong
reasons - to make IT 'look good' or give a false impression that IT
is 'proactively doing something' about business-technology issues, or
serving some other non-fulfilling agenda, there are deep problems
and issues to solve, if they ever can be.
Factor 9: What is the relationship between EA and project
management? Enterprise architects can (and quite often do) have
rocky relationships with IT project managers. Enterprise architects
must realize one critical fact about project managers: that PM
performance is evaluated almost entirely on successful project
deliveries with respect to time, cost, and scope. And that isn't going
to change anytime soon. The friction usually arises when EA
groups attempt to dictate architecture and in particular, standards,
after projects have been planned and started. The best case
scenario is that EA and project management collaborate before
specific projects are started, with EA providing actionable
specifications, standards, project management and PMs

properly accounting for these items when the project is being
planned. In this instance, awareness is everything. Here's another
thing for EAs to keep in mind: without getting project management
on-board with the architecture, it's highly likely that something
other than the architecture postulated by EAs are going to be
implemented by projects. This doesn't imply that EA is subservient
to project management, but it strongly suggests that the relationship
exists as a partnership.
Factor 10: Are EA toolsets used? What kinds, how often, and for
what specifically? There is nothing wrong with using toolsets to
efficiently produce models, documents, and other artifacts,
provided that the toolsets don't become the focal point of EA
efforts at the expense of serving and maintaining relationships with
the constituencies. An 'enterprise architect' that spends the
majority of their days producing documents and ornate diagrams
is not an architect, just a tool jockey producing prose nobody
reads and diagrams that someone may look at once. It's like the
development analogy of 'old Joe' maintaining long-dead code that
nobody cares about because that's 'what was in the contract.'
As always, I'm interested in dialog on these topics, and will add factors to the 10
presented above as they come into mind.

To top