A process anti-pattern is a common strategy which sounds good in theory but
in practice proves to be harmful, if not outright disastrous. This article
overviews a collection of anti-patterns pertaining to enterprise architecture
efforts within an IT organization. These anti-patterns are:
|30,000 Feet and Climbing
||The enterprise model is so high-level that it is of limited
or no practical use to application teams.
reference architectures which provide working examples of
individual aspects of your architecture.
Roll up your sleeves and get
actively involved with the development teams.
Act on feedback from the development teams to evolve your model(s).
||The architects are constantly trying out new technologies and
techniques before they are mature or stable enough to deploy
||Accept the fact that older technologies do in fact work quite well;
the majority of your business may still be batch COBOL running on an IBM
mainframe, and that's actually the best platform for those systems.
|Brain Trust Parking Lot
||Your enterprise modeling group is composed of a lot of very smart
people who don't fit in well anywhere else within IT but you don't want
to lose their knowledge.
||Find a way to make them useful to existing project teams, perhaps as
modeling mentor or as a subject matter expert (SME) in the business
Recognize that if they can't provide value within your
organization now, then it is unlikely they ever will be able to do so.
Motivate them to find employment elsewhere.
Architecture By Magazine
|Your enterprise architecture model depicts an amalgam of
technologies, many of which were added into the model when someone read
about a "really cool" new technology.
||Recognize that your first priority is an architecture which meets
your actual needs, not one which you can brag about to your buddies on
the golf course.
The decision to add a new technology should be made
by people with the expertise, and who have taken the time to
prove that it works. It should not be a political decision.
|Detailed Enterprise Model
||The enterprise model(s) are overly detailed, often in an attempt to
comprehensive define what the enterprise does (or should do).
||Recognize that people rarely read the details, often because
they're not interested in them or because they don't trust them to be
accurate. What is typically needed is a
solid overview and vision of
what is required.
Model with a purpose and know the audience for your model(s), enabling you to model just enough.
Work with your audience to develop the models: they're the best
judges of what they need, not you.
|Enterprise Parking Lot
||An organization forms an enterprise modeling or enterprise
architecture group and "parks" a lot of really smart people there
because they don't want to lose the people but at the same time can't
find practical positions for them.
||Recognize that just because someone is really smart, that doesn't
mean that they're ready, or ever will be, for an enterprise group.
Staff your enterprise groups with people who can actually get the job
Fund your enterprise groups appropriately.
||The architects overbuild the architecture to implement really cool
features that you might need at some point, but these features don't add
value today (and may never do so).
||Consider the big picture by doing some
envisioning but also
trust in your ability to solve tomorrow's problems tomorrow. If
you have the skill to address a problem today, won't you also have the
skill to address it
just in time (JIT) when and if you need to?
|Ivory Tower Architecture
||Your enterprise architecture model(s) reflect a wishful, perfect
world scenario instead of the realities of your actual environment.
||See the solution to 30,000 Feet and Climbing.
|Modeling for Modeling's Sake
thought it would be a good idea to develop an enterprise model but did
not have a concrete plan for how to use it in practice. Vague
ideas that development teams will be able to use the model for guidance
||First garner support for enterprise modeling and then only model
enough to add immediate and obvious value to your IT organization.
|One Truth Above All
||The "one truth" philosophy says that it is desirable
to have a single definition for a data element or business term, that
there should be a common, shared definition for your master reference
data and perhaps even your major business entities. The "One
Truth Above All Else" anti-pattern occurs when this philosophy is
taken to the extreme and you seek to get to the one truth about all data
entities and data elements within your environment.
||Recognize that the true goal is to deliver business
value, not perfect data. Requirements and priorities change, so
you must be willing to evolve your database anyway. Be flexible
about defining the semantics for your data.
|Real World Disconnect
||The enterprise models reflect the vision, and the misunderstandings,
of the modelers but do not reflect what your business stakeholders
||Recognize that just because someone worked in the domain 20 years
ago doesn't mean that they still understand what is going on in the
Involve the people who actually execute the
business processes and get their perspective in the modeling process.
|Strive for Perfection
||The architects are always prototyping and tinkering but never
actually rolling anything out because it's not "perfect."
||Accept the fact that your architecture will need to evolve and then
develop a "good enough for now" architecture instead. Developers
would rather imperfect advice today than simply a request to wait until
the enterprise architects are ready.
|Stuck in the Weeds
||You are too far into the details, attempting to do all the work for
Mentor developers in the architecture, work with them as equal
partners on the development teams, and, after they've gotten going,
focus on providing them with guidance and advice as needed.
|Technology Above All
||The architects make technology a business driver instead of a
||Base your enterprise architecture on actual requirements defined by
your stakeholders. Anything else would be "hacking in the large".
|Tomorrow Suffers From Today
||While attempting to improve business processes, a common mistake is
to describe how things are currently done without exploring how things
could be done.
||Explore new possibilities while keeping today's realities in mind.
Consider a technology-independent approach to model, perhaps using
essential/abstract use cases, which enables you to explore the business
without exploring the solution space.
||The enterprise models reflect a near-perfect, "utopian" future for
your organization but don't provide a clear path to that future.
||Recognize that you are constrained by
your organizational culture, human imperfections, and resource
Investigate and understand the current situation before
attempting to improve it. Although the current processes may not be
optimal, there are probably reasons why things are done the way they
are. Understanding those reasons will help to formulate processes that
|Yesterday's Enterprise Model
model(s) are declared finished and put on the shelf. The "finished models"
quickly become out of
date due to changes in your environment, reducing the value of the
Update your enterprise models on a regular basis as the business
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2 is an
important reference book for agile modelers,
describing how to develop 35
types of agile
models including all 13
UML 2 diagrams.
Furthermore, this book describes the techniques
Full Lifecycle Object Oriented Testing
(FLOOT) methodology to give you the fundamental
testing skills which you require to succeed at
agile software development. The book also
shows how to move from your agile models to
source code (Java examples are provided) as well
as how to succeed at implementation techniques
(TDD). The Object Primer also includes a
chapter overviewing the critical database
development techniques (database refactoring,
legacy analysis, and
database access coding) from my award-winning
Agile Database Techniques
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
Rational Unified Process (RUP), or the
Agile Unified Process (AUP), to streamline your
modeling and documentation efforts. Modeling and
documentation are important aspects of any software
project, including agile projects, and this book
describes in detail how to
architect, and then
design your system in an agile manner.
This book demystifies enterprise architecture and helps organizations
recognize real business value through effective implementation.
- Written by expert practitioners who have hands-on experience solving
real-world problems for large corporations
- Helps enterprise architects make sense of data, systems, software,
services, product lines, methodologies, and much more
- Provides explanations of theory and implementation with real-world
business examples to support key points.
The role of the enterprise architecture professional is one of the most
challenging roles in information technology today. Many aspects of the role
are technical, while much more of the job is becoming political. To say the
least, it is a challenging position. Many enterprise architects have
significant responsibility, but do not have the necessary authority to bring
about success. The primary focus of this book is to be a guide and trusted
advisor to those who want to be successful in this pursuit. Through
real-world examples from experts who have filled the role of enterprise
architect, the reader will learn how to solve complex problems, maintain
technical competencies, and make a positive impact on the overall business.
The most successful architecture will have an architect that can describe the
motivation behind the technical choices; this book provides the background
the practitioners will need to become the enterprise evangelist.
I'd like to thank Jesper R.
Jensen, Paul Oldfield, and Edmund Schweppe for
their input into this article.