Skip to content
July 24, 2011 / David Bleeker

Do Enterprise Architects have it backwards? Some do.

Building an Enterprise Architecture practice is not easy. But it can be done.

As an Enterprise Architect, I have watched as the industry has embraced enterprise architecture (EA), watched as frameworks have solidified, tools matured and overall acceptance climb. The major consulting firms like Gartner and Forrester have full-blown practices around EA, and their conferences are well attended. There is a sense that the level of innovative thinking within EA is accelerating, and that there are constantly better representations and toolsets available to help EAs do their job.

One would think that all this means that EA is embraced and loved by all. Not so. Executive management is as foggy about the meaning of EA, its impact on how business is conducted and what the value is to the organization. Online message boards are filled with questions from EAs asking how to engage upper management, gain a foothold for EA within their organization. I have also bemoaned the slow progress on occasion, lamenting that the rest of the organization was slow to understand the value that was so clear to me. I have come to understand that EA is not something that is automatic, and where there is visibility, the transformational change is slow and sometimes agonizing.

Architecture has value in all organizations.Attending the conferences and webinars I hear over and over again: “Here’s a new tool. You’ll love it. Everyone else will love it too.” Enthused and inspired, you descend the mountain, stone tablets in hand. As you begin to share your experiences and the new tools, folks start to run. Why? Because the tools require approaches that in turn require changes to the way the business runs. It is not possible to cover the how-to-apply aspect of these tools in a two-day conference. At least not in any significant way. And the business is not ready to comply.

Based on the message boards and my own experience, this is the point where most EAs struggle. At times this seemed to me to be an inherent flaw in EA itself. It was too out of step with IT and the business, like an answer looking for a problem. It was too big when the rest of the organization needed small. Then it seemed to be a problem with positioning. Or any one of a myriad of other things. And it seemed I was not alone. Others were finding it difficult to install EA practice because the rest of the organization was not complying.

Some of the ideas represented by the new tools imply major organization changes before they function in a meaningful way. One example of this is the Capability Map. Used effectively, this tool allows an organization to rationalize its IT investments by prioritizing improvements to specific capabilities. It requires careful change management to fully employ this throughout the organization. While beneficial, this may not be where the company feels pain. And without strong executive support, particularly from the CIO, and particularly for the kinds of organizational transformation required to benefit from enterprise architecture, the architect will have limited impact or even worse, fail.

It is not all doom-and-gloom. There are ways to achieve the goal without going insane or suffering major rejection. Here are some things I have learned, that are useful to remember when approaching your implementation of enterprise architecture:

  • Most everything is based on relationship. Build strong relationships first. It is more important to have good relationships than good process or deliverables.
  • Establish trust. You do this by listening and focusing on what the organization needs. Most often it does not need another framework or tool. It doesn’t need your list of credentials or clever solutions. They need you to care about what matters most to them.
  • Don’t expect the rest of the organization to change just so that you can implement a new tool. This especially true if you have not worked to establish trust first. You may be working in an environment where your favorite framework may never be implemented. Ever. That’s OK.
  • Decompose the new framework, tool or process and extract the pieces that matter now. Defer the rest for later. Demonstrate value by implementing the pieces you can implement. Build on the value. If you don’t get traction with something, drop it and try something else. Perhaps the real value lies somewhere else. Keep digging until you find it. Keep your increments small.
  • Be careful with your language. Terms like “framework,” or “process” sometimes sound like a lot of work, like unnecessary delays. Use different terms, ones that are easier to understand if you’re not technical. Some terms get you into the penalty box because they are topics that are overused, or because they are too technical.
  • Make yourself useful. Your life as an enterprise architect is not about being served. Roll up your sleeves, get in the trenches and serve others. Your list of principles isn’t as useful as you would think.
Enterprise Architecture has value for the organization. You can help your organization realize that value. Take it one step at a time. It can happen.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: