2.6 Enterprise Architecture Standards

An enterprise architecture is a set of documents designed to communicate how IT components fit together to satisfy the higher level business objectives. Enterprise architecture has been under development for years. Attempts were made to increase the formalism of the enterprise architecture process and to provide simple, generic models of system components across entire classes of systems; much work has been done between these two extremes. The primary lesson learned from efforts to date is that any enterprise architecture needs to be tailored toward the audience that will use it for business decision making. In retrospect, this makes excellent sense because the decision makers are making the investment in the system and need on-going education into the alternatives, risks, and tradeoffs involved in how they make such decisions. Without either an enterprise architecture to communicate this information in terms others can understand or the people affected by their decisions, decision makers are forced to rely on blind faith in their IT staff or risk undermining efforts that may already be aligned to aid in accomplishing their business goals.

Natural languages such as English are adequate for planning discussions and setting high-level priorities. However, because natural languages are imprecise and can be interpreted in multiple ways, lower level models and share design artifacts require more specialized notations. For example, a detailed discussion of the contents of a database would drive most of the organization from the room in the first hour; however, defining the various data types, expected field lengths, and semantic meanings of the fields and relationships is absolutely essential for database construction.

The enterprise architecture defines the roadmap and how the various models at different levels of the enterprise are related. This description needs to be understandable across the enterprise, even if the individual models themselves have a more limited audience. A balance needs to be struck in developing artifacts that can simultaneously be used to provide technical information to business users and enough information to derive consistent technical guidance for development teams. An immediate benefit from having an enterprise architecture is that it allows everyone within an organization to communicate using a common set of documents. This provides an organizational alignment and allows everyone at different levels of the organization to understand the impact of both IT decisions and investments. For example, if a business group needed management information reports from different lines of business, then it should be possible to use the enterprise architecture to trace through what business areas generate the required data and what IT systems are impacted and to perform a quick assessment of where additional analysis would be required to produce a feasibility study. Furthermore, if a project is scoped out and approved, the technical people can use the same enterprise architecture as a starting point for their high-level design. Having the same information available as input into business decision making and technical analysis increases the chance for project success.

Regardless of the approach taken, the initial step in developing an enterprise architecture is obtaining and documenting the current business environment. It would be a mistake to adopt a "bottom up" approach, placing technical artifacts before an understanding of how they are linked to strategic business objectives. Also, when technical artifacts are included in the enterprise architect, they should be targeted to the business users. This does not mean that the more technical documentation customized for system designers, coders, and testers should not exist. It does, however, mean that some effort is needed to package and convey some essential information to a wider audience.

Federal Enterprise Architecture Framework

The Federal Enterprise Architecture Framework (FEAF) [FEAF 1999] is targeted at U. S. government agencies to assist them in complying with the 1996 Clinger-Cohen/Information Technology Reform Act, which required agencies to develop an enterprise architecture. It is expected that the agency enterprise architecture will be integrated into the organization's Capital Planning and Investment Control (CPIC) processes used to set priorities and make decisions about IT and other capital asset investments. The guidance is heavily based on the Zachman Framework customized for implementation within the U.S. government.

The FEAF is focused on defining the required processes with the assumption that agencies have the expertise to define additional standards for the specific artifacts expected to be created by the processes. The FEAF defines the structure for content after it is developed but does not go into the specifics of standards and examples for developing content. While reasonable, it has, in many agencies, produced artifacts that are not suitable for use in fulfilling their intended purpose. This is partially the result of the lack of sophistication in upper management, which has grown accustomed to making decisions about IT investment without a wealth of information being available. Some management may view the benefits of a unified view of IT and business as a hindrance when compared to the relative ease of making decisions in the dark and delegate the understanding, maintenance, and responsibility of the enterprise architecture to others while retaining the decision-making authority. Such a mindset effectively dooms the optimal use of an enterprise architecture immediately, relegating it to a lower level tool for the IT shop to use as an aid in their decision making. While this will result in some success, often it will not achieve the large cost benefit that the FEAF authors and advocates intended.

After its initial development, the FEAF was supplemented with a much needed guide, A Practical Guide to Federal Enterprise Architecture (PGFEA) [PGFEA 2001], providing more detailed instructions on applying enterprise architecture development and FEAF principles to agencies. This guide served the purpose of bridging the gap between the FEAF guidance and practical use and also aided in integrating other enterprise architecture approaches into the federal arena.

The first part of PGFEA outlines all the steps necessary to initiate an enterprise architecture program. This includes getting executive buy-in, clearly defining roles and responsibilities, and establishing management structure and control. Because the audience is federal government agencies, the PGFEA discusses how to integrate efforts with the structures of other agencies such as CPIC and CIO. The hope is that these government agencies will have analogous processes and organizations analogous to those of most large corporations. For example, the CPIC council that governs the financial investment in IT systems serves a role similar to the budget organization in most Fortune 500 companies. Furthermore, many of the efforts that are driven by IT legislation are considered industry-best practices and were created from them in an attempt to have the government achieve the same success rates in IT investments as those achieved by commercial organizations.

The next part of the PGFEA discusses deciding and documenting the approach the organization intends to take in developing the enterprise architecture. Making this determination is essential because it provides an opportunity to scope the enterprise architecture and ensure that what is being developed has a valid use within the organization. Unfortunately, it assumes that most agencies already have a standard approach to developing the artifacts associated with an enterprise architecture; this approach is seldom the reality in most organizations. It is expected that eventually additional guidance will be provided to assist federal agencies with more limited experience in software architecture development. The Department of Defense developed the Command, Control, Communications, Computer, Intelligence, Surveillance and Reconnaissance Architecture Framework [C4ISR 1997], which provides an example of the level of guidance that is needed to bridge the gap from the FEAF processes to a fully realized enterprise architecture. C4ISR takes a different approach to enterprise architecture development than FEAF by adopting a greater emphasis on standards for artifacts; C4ISR has been successfully adopted in numerous commercial and nonmilitary government enterprise efforts. The C4ISR architectural framework provides detailed rules, guidance, and product descriptions for developing the documentation of an enterprise architecture. The products are appropriately targeted to allow all participants to understand quickly and then synthesize knowledge about IT systems throughout the enterprise.

Other sections define the development, maintenance, and use of enterprise architecture. The three parts of an enterprise architecture are the baseline architecture, which depicts the enterprise environment as it currently is; the target architecture, which reflects the desired environment in the future; and the transition plan, which outlines how to proceed from the baseline architecture to the target architecture. Most environments are constantly changing so that both the baseline and target architectures are moving targets. Therefore, there is a real need to ensure that both architectures are updated regularly so that they have value in supporting business-level decision making.