Enterprise Architecture (EA) has developed a reputation. We’re often reminded of this when in a meeting with senior business leadership and someone explicitly mentions the EA program. Eyes roll back in heads, quick loaded glances are exchanged, an audible exhale is heard as if to say, “Ugh. Not this again.” If you’ve seen one of these reactions or maybe even all three simultaneously (unofficially known as the EA Trifecta), unfortunately you are not alone. EA programs in all corners of business and government are struggling to demonstrate substantial organizational value and achieve true enterprise buy-in and acceptance.
It is not for a lack of trying. Organizations that have decided to invest in EA programs are usually making substantial personnel (both internal resources and external consultants) as well as software investments in support of their EA programs. In addition, organizations typically incur significant indirect EA costs in the form of stakeholder meetings and presentations. Many enterprises have started to take a hard look at their EA program to assess whether the EA program is worth the investment. It has left organizations asking themselves, “What’s wrong with our architecture?”, a question that Frank Lloyd Wright most certainly asked himself more than once.
As IT professionals, we see organizations experiencing a variety of challenges with their enterprise architecture programs. There are many potential pitfalls when it comes to establishing a value-driven EA capability. If you find yourself struggling to comprehend what’s wrong with your architecture, consider the following questions that might uncover some of the issues preventing your EA program from providing real enterprise value.
Is Your Architecture the Wrong Size?
Having seen both successful and unsuccessful EA programs range in size from an army of people to an army of one, it is clear there is no “one size fits all” when it comes to the size of an EA program. While many might suggest that the size of your EA program should be a function of the size of your organization, I would argue that a more appropriate indicator of an EA program’s size should be the specific goals and objectives of that EA program. Maybe one person and an open-source EA tool is all your organization needs to successfully move the EA ball forward for your organization. Or maybe your segment architecture effort does in fact warrant an experienced team of architects equipped with an advanced enterprise modeling platform. It really all depends on the goals and objectives you have defined for your EA program.
We also find that many organizations misinterpret what is meant by stating that an EA should be comprehensive in nature. Many jump to the assumption that this means that everything in the enterprise that can be modeled, should be modeled. While to some degree this can be the easier path, it is rarely the right path. If your organization would get the most value by focusing your initial EA efforts on developing the Business layer of your architecture, then I would argue that is what your initial EA focus should be. While there are certainly some hard-line architects who would be quick to point to all of the empty sections of the framework you’re neglecting, the bottom line is that EA programs have to be smart about scoping their efforts to ensure value is delivered and to avoid being swept up in a sea that you tried to boil. Resources aren’t unlimited in the real-world and EA programs are seeing the increased importance of thinking big, starting small, and scaling fast.
Does your Architecture have the Wrong Architects?
This is often the hardest question for organizations to come to grips with. In our EA travels, we’ve heard the equivalent of, “What do you mean the new EA guy isn’t working out – his resume said he knew every EA framework and programming language that there is!” multiple times. What many organizations fail to realize is that many of the attributes that make a successful enterprise architect are the same attributes that make a successful business executive. Simply put, a successful enterprise architect must be a strategic thinker, an effective communicator, and a respected leader.
One of the elusive goals of many enterprise architects is having a seat at the executive table and contributing to the meetings that decide the direction of the organization and the investments made. In order for this to happen, the EA team has to be able to speak the language of the business (which will come in handy when modeling that business layer) and earn a seat at that table. Similarly, they need to be able to interface with and often lead technical resources that bring different but vitally important skills to the table. The ability to successfully walk that line is a vital skill that eludes many EA teams.
Is Your Architecture in the Wrong Language?
You don’t have to look any further than the term “enterprise architecture” itself to understand the language challenge that exists. Literally, this term has been misused more than the word “literally” itself. We know for certain that it is either a comprehensive framework or a conceptual blueprint or a strategic technique or a decision support mechanism or one of the other 10,000 definitions you can find out there. Similarly, there is further lack of definition and consensus in the marketplace about what it means or should mean to be an enterprise architect, certified or otherwise. If you are successful at reaching a definition of EA that is deemed acceptable by the powers that be in your organization, your language challenge is just starting as a plethora of methodologies and frameworks await your translation.
How many times have you had to explain (or be explained) the difference between an OV-1 and OV-2 diagram? Have you spent hours trying to dissect the cells or sub-steps of an EA framework or methodology only to discover it really didn’t matter? I recently had a client describe an architecture framework as something that sounded like it should be a condition for the podiatrist to diagnose. I had to laugh, but at the same time it hit home the point that too often EA is living in its own world and speaking its own language. This separate language can actually create the barriers that EA was designed to eliminate, ominously positioning EA as an island. If you are constantly tossing out EA-isms in meetings, don’t be surprised when your message falls on deaf ears. Business stakeholders and executives don’t want to have to learn a new language to talk about the enterprise, and frankly, they shouldn’t have to. It is the job of the EA program to put the EA in terms that the business understands and embraces.
Does Your Architecture Have the Wrong Focus?
It may sound surprising, but in a time when many EA programs are struggling to find the bandwidth necessary to support all the architectural needs of the enterprise, so many teams are spending the lion’s share of their time focusing on the wrong things. EA programs must thoroughly understand their goals and objectives while factoring in where they are in their maturity lifecycle. If the EA program is still at a point where the organization doesn’t understand what EA is or does, cranking out a network diagram isn’t going to move the needle. Again, the best EA measuring stick for success is whether or not your EA program is maximizing the value it provides to the organization. EA programs that sacrifice this in favor of documentation or adherence to a framework are heading down the wrong path.
I have observed enterprise architects prematurely declare victory upon completing all of the architectural documentation they set out to develop. While half of what was created was of no value to anyone but the enterprise architects themselves, the list of deliverables was a defined, achievable goal which can be rare in the EA world. As a result, a natural tendency exists to navigate toward those activities that have a defined start and end from which some semblance of progress can be reported – regardless of the amount of value these activities actually produce. These programs have to learn the hard way that, much like strategic planning, EA is something you do, not something you deliver.
Another common issue is the temptation to spend too much time documenting the current state architecture and not enough time defining a future state and a plan to successfully make that transition. While this may seem counter-intuitive, the reality is that it is much easier to document something that is tangible and real. It is much harder (and coincidentally much more valuable) to document something that doesn’t yet exist and, by the way, adequately addresses the challenges and issues your enterprise is experiencing. If your EA is focusing most of its efforts on the current state, it is likely they will come up short in guiding and driving successful enterprise change. In an era where organizations demand quickness and agility from their IT resources, an effective, future-looking architecture can make all the difference.
While it may be stating the obvious, it is worth acknowledging that doing EA the right way is hard. The key is for each organization to define what EA should do for their specific organization. Organizations who worry less about building the “ideal EA program” and concentrate on effectively delivering business value are much more likely to be successful with their efforts. EA is not IT’s chance to impose their will (in the form of governance and frameworks) on the business. It’s a chance for business and IT to come together to move and guide the organization forward.
Do you need help understanding and overcoming what’s wrong with your architecture? At TeraThink, we understand the issues and challenges that many EA programs face across both the federal and commercial sectors. We can help your organization diagnose, fix, and avoid these pitfalls. To learn how our experienced EA team can help you, please contact us.
[Editor’s Note: This post was originally published on the blog of Dominion Consulting. On November 1, 2017, Dominion Consulting merged with TeraThink and are now operating jointly as TeraThink. All blog posts migrated from the Dominion Consulting website have been updated to refer to ourselves as TeraThink.]