- 30,000 Feet and Climbing
- Bleeding Edge
- Brain Trust Parking Lot
- Buzzword-Driven Architecture
- Detailed Enterprise Modeling
- Enterprise Parking Lot
- Goldplating
- Ivory Tower Architecture
- Modeling for Modeling’s Sake
- One Truth Above All Else
- Real-World Disconnect
- Strive for Perfection
- Stuck in the Weeds
- Technology Above All
- Tomorrow Suffers From Today
- Ungrounded Future
- Yesterday’s Enterprise Model
Anti-Pattern
Problem
Solution
30,000 Feet and Climbing
The enterprise model is so high-level that it is of limited or no practical use to application teams.
Develop 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).
Bleeding Edge
The architects are constantly trying out new technologies and techniques before they are mature or stable enough to deploy effectively.
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 teams, perhaps as a modeling mentor or as a subject matter expert (SME) in the business domain.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.
Buzzword-Driven Architecture-or-
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 done.
Fund your enterprise groups appropriately.
Goldplating
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 initial 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
Someone 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 aren’t sufficient.
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 Else
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 actually require.
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 business today.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 application teams.
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 business enabler.
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.
Ungrounded Future
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 restrictions.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 are realistic.
Yesterday’s Enterprise Model
Your enterprise 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 model(s).
Update your enterprise models on a regular basis as the business changes.
Recommended Resources
- Agile Enterprise Architecture
- Agile Modeling Core Practices
- Situation Context Framework (SCF)
- Core Practices for Agile/Lean Documentation
- Big Modeling Up Front (BMUF) Anti-Pattern
- EUP Enterprise Architecture Discipline
- EUP Enterprise Business Modeling Discipline
- Initial High-Level Architectural Envisioning
- Initial High-Level Requirements Envisioning
- The “One Truth Above All Else” Anti-Pattern
The Object Primer 3rd Edition: Agile Model Driven Development (AMDD) with UML 2
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 of the 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 such as refactoring and test-driven development (TDD). The Object Primer also includes a chapter overviewing the critical database development techniques (database refactoring, object/relational mapping, legacy analysis, and database access coding) from my award-winning Agile Database Techniques book.
Agile Modeling
Agile Modeling: Effective Practices for Extreme Programming and the Unified Process is the seminal book describing how agile software developers approach modeling and documentation. It describes principles and practices which you can tailor into your existing software process, such as Scrum or SAFe, to streamline your modeling and documentation efforts. Modeling and documentation are important aspects of any software initiative, including agile teams, and this book describes in detail how to elicit requirements, architect, and then design your system in an agile manner.
Enterprise ARchitecture
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.
Acknowledgements
I’d like to thank Jesper R. Jensen, Paul Oldfield, and Edmund Schweppe for their input into this article.