For many agency heads or department managers, any mention of "Enterprise Architecture" causes emotional reactions ranging from fear to outright antagonism. Often enterprise architecture has come to mean "yet another IT project and expense which I don't have time for and from which I won't see any tangible results." For others, it is simply a checkbox that must be filled to get the money needed to get real work done.

But what is Enterprise Architecture really? And who is it intended to benefit?

Many complicated definitions and explanations could be presented, but at the core, enterprise architecture is very simple: it starts with the idea that one should plan technology purchases and development ahead of time and -- here's the important part -- that the business people, not technology people, should determine what is needed (the requirements).

The classic analogy in a non-high tech realm is building a home. Telling an architect to "build me a house!" is not nearly enough information. The architect needs details about how many people will live in it, what kinds of activities it needs to support, the quality of furnishings to use, how long it needs to last, , etc.

And those are just the high-level questions. A thousand and one details will need to be filled in below these by all the individual tradesman who help build the house.

You, as the owner, may not need or care to know that eight-penny finishing nails were used in one section of the kitchen cabinets whereas 10-penny were used elsewhere. What you do want to know is that the cabinets look good, have the shelving space that will serve your needs and that they will stay securely in place for the life of the house.

To carry the analogy a bit further, the architect may not start from scratch -- he or she may come to you with a series of predefined plans and ask you to suggest modifications to fit your needs. Such plans usually accommodate certain types of changes but may not allow for major alterations such as arbitrarily sticking an indoor swimming pool in the middle of the house.

When talking about building a house, it is obvious that the owner needs to set these kinds of high-level requirements: unless you have money to burn, don't care about schedules and don't really plan to live in the house anyway, you're going to want to give instructions to the architect and general contractor about what you need and want.

Enterprise Architecture is derived from the understanding that technology exists to fulfill business needs. Which technologies are chosen should not be a matter of "coolness" and is only partially a matter of cost: more properly it is a matter of what technologies get the job done. And what constitutes "the job" must, of course, be defined by the executive branch, the legislature, the agency head, etc., not by the technologists who, while perhaps experts at what they do, are often more interested and aware of bits and bytes than in agency purposes or political needs.

Of course, time enters into this as well. What "the job" is today may not be the same as it will be in five years. Today's technology need will definitely not be the technology need in five years. So the future always needs to be part of any enterprise architecture discussion.

So, how does the idea of enterprise architecture get so hard or seem to engender such resounding boredom (or worse)?

Although enterprise architecture represents the very same problems as building a house and even involves many of the same processes, several difficulties make it more difficult to grasp:

  • Usually, enterprise architecture doesn't start with an empty lot -- something's there and works to
David Aden  | 
David Aden is a writer from Washington, D.C.