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:
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
paying for support on an application that is 15 years old, it would be helpful to know:
Enterprise architecture frameworks are collections of data designed to organize the information in a way that makes it possible to answer these kinds of questions. An enterprise architecture framework is to planning for an organization what the Dewey Decimal system is to a library: it tells you where data is and puts related information "close" together.
The second key enterprise architecture term is "model" by which is very simply meant a diagram or a type of diagram. In order to gather and manage information about how the agency's network is organized, large quantities of information are most easily conveyed using diagrams. For example, when an enterprise architect wants to understand a business process to make sure that application they are building will support the business, it is often easiest to represent the business process diagrammatically.
Enterprise architecture frameworks often specify what kind of diagrams (models) should or could be used to represent which kind of information: a style of diagram that can represent an agency's network likely would not work for visualizing a business process. So, enterprise architecture frameworks specify both what kind of data to gather and, when appropriate, how to diagrammatically represent it.
Architects are constantly working to simplify and clarify the way the framework is organized and the kinds of models (diagrams) that most easily and intuitively capture and communicate essential data. But even though the attempt is to simplify the models as much as possible, it still takes some study to understand how to read each type of model and how one model can relate to another. However, with a bit of guidance, the models are readable, the same way a blueprint is readable even by non-architects. And with the ability to read comes the ability to understand the enterprise better and to more intelligently direct improvements to business processes and to better direct IT dollar expenditure.
The end product of enterprise architecture, to a large extent, is that information technology becomes invisible: instead, the agency is freed to just get on with its work. Conversely, to the extent that IT is a problem -- whether that takes the form of the network going down, files being lost, inter-office communication barriers, reporting difficulties or security breaches -- is the extent to which enterprise architecture efforts could help.
Local, State and Federal
According to speakers at a recent enterprise architecture conference held in Washington, D.C., the federal government actually tends to lead the way in the area of enterprise architecture theory and practice -- a situation that doesn't exist in many other areas.
But, according to Roth it also works in reverse because states are often able to engage in tests and pilots in smaller settings and so can provide feedback to the feds on what works and what doesn't.
Overall, Roth sees many reasons why states can and should be interested in what's being done at the federal level. "It's our best bet at this stage of the game," said Roth. "The amount of alignment between federal, state and local on any line of business is just huge. The states can use a different framework but to not directly align with the federal architecture is to ignore the alignment [which obviously exists]."
As an example, Roth pointed out that certain topics of discussions always end up crossing federal, state and local boundaries. For example when discussing Health and Human Services, "you immediately drop down
into the state options and the states talk about what they have available and that leads to the local providers. You can take any conversation and if you ignore the federal, state and local alignment you are ignoring the options available to provide the overall solution which is to provide service to the citizen."
Roth's suggestion: to take advantage of the work being done at the federal level and align state and local efforts with it.
Enterprise Architecture's Future
Enterprise architecture has suffered from a general misunderstanding which has often relegated it to an afterthought. Much of that has to do with the field's difficulty with clearly and succinctly explaining its value. According to Roth, part of the issue is the problem of how to measure enterprise architecture's value because enterprise architecture's value "is calculated differently than if you were showing the business value of a single system to fulfill a business need." Still, Roth sees improvement including changes in his own state. "We've got quite a few things going and we're learning every year how to work across state agencies and work with local government and business partners and that's probably the most exciting thing I see out here," said Roth. "Ten years ago, you'd almost never see state and local at the same conversation or anyone outside the individual agency but in the last five years I have been involved in a huge number of cross-agency initiatives and that is probably the most exciting thing because it allows us to really understand all the parties needed for process improvement."
Roth also gives kudos for the work being done by the federal government. "I like EA and the efforts the feds are doing," Roth commented. "We leverage a lot of their papers and things out here so I appreciate it. I encourage the federal community to keep their efforts going because it is leveraged by a lot states out here . They may not see that but it is appreciated -- we depend on them to bring a lot of best practices."
Whether enterprise architecture grows as a practice or fades, the need it attempts to fill will continue: to drive technology decisions based on business-side needs. It is, after all, the agency's purpose, services and products which are important, not the technology used to get the job done.