• some degree. So, while managers are always pushing themselves and their staff to look forward, an architect's plea to spend some time determining exactly what is already there doesn't always fly. Yet, without a good understanding of what is there and how it is used, it is all but impossible to plan a renovation, much less a new addition.
  • You can't wrap your arms around an enterprise architecture the same way you can a house. When a home is built, you can look at it, touch it and walk through the rooms. When an EA has been done well, you're able to get your work done but there's no thoroughly satisfying way to take a tour. Even worse, the only time an enterprise architecture (or its lack) usually becomes visible is when something breaks.
  • Enterprise architecture has its own set of terms and procedures which need to be understood: not understanding those terms acts as a false barrier to what is in reality a very simple idea.

Even people with no building experience know what a "blueprint" is and when they look at one, they can find the bathrooms, kitchen, bedrooms and family rooms. They can locate the windows and doors and would know immediately if a room had no door. By contrast, most people do not immediately know what a "Context Diagram" is, yet it is just a somewhat analogous type of diagram used in EA to specify how a computer application or system interacts with other applications or systems -- it shows the "doors" between applications or systems and allows one to see immediately if one is missing.

As pointed out by Bill Roth, chief information technology architect for the state of Kansas, the fact "that EA is not understood is the biggest barrier to its adoption. There is a lack of clarity of what EA brings to the business management and IT management." According to Roth this is more a failure to communicate than anything else. When EA is explained, its intent is obvious even to non-technical people. Roth has done 45-minute presentations to high level state executives about enterprise architecture and knew he'd succeeded when they suddenly said "Oh you're not describing technology problems, you're talking about helping me to do my business better!"

So, one of the key things to know about enterprise architecture is that it is not "just an IT matter" -- it involves the discussion and clarification of business processes and procedures. There is no sense building applications and an infrastructure that simply automate disorganized or inefficient processes, so defining and documenting business processes are key components of a full enterprise architecture undertaking.

Crossing the Terminology Barrier

As mentioned, enterprise architecture like any other professional practice, comes with its own set of terms which can act as a barrier to understanding. The following is not an exhaustive list of the terms by any means, but highlights two of the most important. For more details see some of the online EA resources.

One of the most commonly heard terms in enterprise architecture is "framework," a word that is used in other professions for other things and so is subject to not only non-comprehension, but also mis-comprehension. Within the enterprise architecture world, a "framework" is simply an agreed-upon way to organize the data about an enterprise or department. Since the data that is important to enterprise architecture includes everything from what an organization's goals and strategies are to its business processes to the applications it uses and how its network is connected, it is important to have a plan for organizing the data.

Enterprise architecture "frameworks" are plans for organizing data about the enterprise and, more important, they facilitate getting meaningful answers for business people. For example, when the finance director wants to stop

David Aden  | 
David Aden DAden@webworldtech.com is a writer from Washington, D.C.