• paying for support on an application that is 15 years old, it would be helpful to know:

    • Which applications depend on it
    • What parts of the agency accesses data it manages
    • Which constituents would be affected
    • Which strategies or goals set by Congress or state legislatures, if any, might be impacted

    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

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