The epiphany occurred the other day while talking to a Department of Defense customer; enterprise architecture (EA) for the sake of doing enterprise architecture is a seemingly valid and important activity, but in retrospect flounders aimlessly in search of respect.

We hear it consistently throughout the industry—EA gets no respect.  Organizations, such as IASA and CAEAP have emerged to try to bring clarity and purpose to the role of the enterprise architect and the profession for those less aware of the value and purpose.  Still, EA struggles to be recognized for its strategic importance.  Why is this?

Until recently, I was among those who simply, and perhaps naively, believed it was because of the lack of agreement on what EA is and what value it provides.  However, given my epiphany, I would now say that has relatively little cause for the inability of EA to be recognized as an important and critical aspect of business planning.  Now, I believe the real reason it that enterprise architecture for EA’s sake brings a whole new meaning to “boiling the ocean”.  Attempting to catalog and garner every facet of how all the interrelated systems impact the business is a fruitless exercise.  To be meaningful, it must have a contextual focus with a specific goal of transformation.

EA provides clarity over the interrelatedness of systems in an business, but is not in and of itself a standalone task.  One of the major problems with EA is that it needs focus to make sense.  EA brings clarity to other activities.  For example, data center consolidation as an activity requires a full understanding of the as-is environment including the interactions and relationships between the various components, both hardware and software.  EA facilitates that clarity and provides a mapping of the existing architecture in a way that can be manipulated to gain the advantages of consolidation.

Could an ongoing EA effort have made these as-is artifacts available so that when the data center consolidation task as initiated it would have the necessary “blueprints” from which to start planning?  Absolutely.  However, while you can categorically examine the general details of an existing architecture, there are some details that just aren’t going to be captured until they become important.  These details become important when they become the focus of another exercise that requires them in order to make appropriate decisions.  Hence, while I can minimize the need for some up-front research, when the time comes, I still have to perform the exercise of gathering more data relative to my specific goals at a future point in time after I have applied the focus and context of another task.

So, as a business leader, am I going to spend precious overhead dollars in preparation of a future activity that may never become important or wait and bite the bullet to perform the necessary cataloging and data gathering associated with my EA task at the time it becomes important and roll that cost into the cost of the entire project? Moreover, am I going to catalog everything in my enterprise, or only those things that matter to the task at hand?  These are important business questions that many IT specialists don’t fully relish the importance of given their understanding of how EA would improve many facets of the business and perhaps even lower operational costs.  However, I would argue, if this is the case, then propose a project to lower operational costs and perform the EA task as part of that effort.

My epiphany left me with two conclusions regarding enterprise architecture:

1. Stop trying to make the rest of the world see the importance of EA and just make sure it’s a critical component of any transformational task
2. (one we’ve heard many times before) IT needs to start thinking more like the business and less like engineers

EA best practices are still important and we need to have highly-skilled enterprise architects, but the task of EA is not a noun or a verb, as many Enterprise Architects would like the world to accept, it is merely a modifier to provide clarity to the real nouns and verbs in our organization.