September 24, 2008 By David Aden
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
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
You may use or reference this story with attribution and a link to