Information Technology: The Federal Enterprise Architecture and Agencies' Enterprise Architectures Are Still Maturing
Published: 2004-05-19T00:00:00

Fast Facts:

Highlights:
section_title: Why GAO Did This Study
paragraphs: The concept of enterprise architecture emerged in the mid- 1980s as a means for optimizing integration and interoperability across organizations. In the early 1990s, GAO research of successful public and private sector organizations led it to identify enterprise architecture as a critical success factor for agencies that are attempting to modernize their information technology (IT) environments. Since then, GAO has repeatedly identified the lack of an enterprise architecture as a key management weakness in major modernization programs at a number of federal agencies. It has also collaborated with the Office of Management and Budget (OMB) and the federal Chief Information Officers (CIO) Council to develop architecture guidance. In 2002, OMB began developing the Federal Enterprise Architecture (FEA), an initiative intended to guide and constrain federal agencies' enterprise architectures and IT investments. GAO was asked to testify on the status of the FEA and on the state of federal agencies' development and use of enterprise architectures.
section_title: What GAO Found
paragraphs: OMB has made progress on the FEA, but it remains very much a work in process and is still maturing. Its stated purposes include facilitating (1) the development of agencies' enterprise architectures, (2) the reuse of common IT components across agencies, and (3) the identification of opportunities for interagency collaboration in developing common IT solutions. Currently, the FEA is made up of five parts known as reference models, four of which have been issued in at least initial form. OMB reports that the FEA has been used to help identify potentially redundant agency IT investments, choose five lines of business (e.g., grants management) in which to pursue opportunities for agency collaboration, and begin to develop the architectural foundation for some of these business lines. GAO supports the FEA as a framework for achieving these ends, but raises questions whose answers are important to the its future. For example: Should the FEA be described as an enterprise architecture? GAO's reading of its content suggests that it is more akin to a classification scheme for government operations than a true enterprise architecture. Further, OMB requires agencies to "map" and "align" their architectures with the FEA. However, since these terms are not well-defined, GAO asks if the expected relationship between the FEA and agencies' architectures is clear enough. Like the FEA, agencies' enterprise architectures are still maturing. GAO recently reported (GAO-04-40) that agencies' management of architecture programs was generally not mature. Using its Enterprise Architecture Management Maturity Framework as a benchmark, GAO found little change in overall maturity between 2001 and 2003. Only 20 of 96 agencies examined had established at least the foundation for effective architecture management. Further, while 22 agencies increased in maturity since 2001, 24 agencies decreased and 47 agencies remained the same. Recently, OMB and the federal CIO Council initiated actions to advance agency architecture programs that are consistent with many of GAO's recommendations.

section_title: Letter
paragraphs: The concept of enterprise  architecture emerged in the mid- 1980s as a means for optimizing  integration and interoperability  across organizations. In the early  1990s, GAO research of successful  public and private sector  organizations led it to identify  enterprise architecture as a critical  success factor for agencies that are  attempting to modernize their  information technology (IT)  environments. Since then, GAO has  repeatedly identified the lack of an  enterprise architecture as a key  management weakness in major  modernization programs at a  number of federal agencies. It has  also collaborated with the Office of  Management and Budget (OMB)  and the federal Chief Information  Officers (CIO) Council to develop  architecture guidance. In 2002,  OMB began developing the Federal  Enterprise Architecture (FEA), an  initiative intended to guide and  constrain federal agencies’  enterprise architectures and IT  investments.
OMB has made progress on the FEA, but it remains very much a work in  process and is still maturing. Its stated purposes include facilitating (1) the  development of agencies’ enterprise architectures, (2) the reuse of common  IT components across agencies, and (3) the identification of opportunities  for interagency collaboration in developing common IT solutions. Currently,  the FEA is made up of five parts known as reference models, four of which  have been issued in at least initial form (see table). OMB reports that the  FEA has been used to help identify potentially redundant agency IT  investments, choose five lines of business (e.g., grants management) in  which to pursue opportunities for agency collaboration, and begin to  develop the architectural foundation for some of these business lines. GAO  supports the FEA as a framework for achieving these ends, but raises  questions whose answers are important to the its future. For example:  Should the FEA be described as an enterprise architecture? GAO’s reading of  its content suggests that it is more akin to a classification scheme for  government operations than a true enterprise architecture. Further, OMB  requires agencies to “map” and “align” their architectures with the FEA.  However, since these terms are not well-defined, GAO asks if the expected  relationship between the FEA and agencies’ architectures is clear enough.
GAO was asked to testify on the  status of the FEA and on the state  of federal agencies’ development  and use of enterprise architectures.
Like the FEA, agencies’ enterprise architectures are still maturing. GAO  recently reported (GAO-04-40) that agencies’ management of architecture  programs was generally not mature. Using its Enterprise Architecture  Management Maturity Framework as a benchmark, GAO found little change  in overall maturity between 2001 and 2003. Only 20 of 96 agencies examined  had established at least the foundation for effective architecture  management. Further, while 22 agencies increased in maturity since 2001, 24  agencies decreased and 47 agencies remained the same. Recently, OMB and  the federal CIO Council initiated actions to advance agency architecture  programs that are consistent with many of GAO’s recommendations.
Reference  model  Performance Provides a common set of general performance outputs and  measures for agencies to use to achieve business goals and  objectives.  Describes the hierarchy of federal business operations  independent  of the agencies that perform them, including  defining the services provided to state and local governments.  Identifies and classifies IT service (i.e., application) components  that support federal business operations and promotes the reuse  of components across agencies  Is intended to describe, at an aggregate level, the types of data  and information that support program ad business line operatin  and the hierarchical relationships among them.  Describes how technology is supporting the  delivery of service  components, including relevant implementation standards.
Release date  V 1.0,  September  2003  V 2.0,   June 2003  V 1.0,   June 2003  www.gao.gov/cgi-bin/getrpt?GAO-04-798T.
To view the full product, including the scope  and methodology, click on the link above.  For more information, contact Randy Hite at  202-512-6256 or hiter@gao.gov.
Mr. Chairman and Members of the Subcommittee:  I appreciate the opportunity to participate in the Subcommittee’s  hearing on the status of the Federal Enterprise Architecture (FEA)  and on the state of federal agencies’ development and use of  enterprise architectures—two topics that are closely related.
An enterprise architecture can be viewed as a link between an  organization’s strategic plan and the program and supporting system  implementation investments that it intends to pursue to  systematically achieve its strategic goals and outcomes. As such, the  architecture is basically a blueprint, defined largely by interrelated  models, that describes (in both business and technology terms) an  entity’s “as is” or current environment, its “to be” or future  environment, and its investment plan for transitioning from the  current to the future environment. The use of such a blueprint is a  recognized hallmark of organizations that effectively leverage  technology in the transformation and modernization of business  operations and supporting systems. Further, it is recognized in  legislation and related Office of Management and Budget (OMB)  implementing guidance. The FEA is intended to provide a  governmentwide framework to guide and constrain federal agencies’  enterprise architectures and information technology (IT)  investments.
My testimony today is drawn largely from our 2003 report on federal  agencies’ development and use of enterprise architectures, which  was based on work conducted in accordance with generally  accepted government auditing standards. We augmented the results  in this report with available information on the recent actions of  OMB and the federal Chief Information Officers (CIO) Council to  address the recommendations that we made in the report. This  testimony is also based on discussions with and information from  OMB on the FEA, as well as discussions with GAO’s Executive  Council on Information Management and Technology.
subsections: section_title: Background
paragraphs: The concept of using an architecture to describe an enterprise  emerged in the mid-1980s, and over the years, the field of enterprise  architecture has continued to evolve and mature. In the early 1990s,  we identified an architecture as a critical success factor in allowing  organizations to effectively apply IT to meet mission goals. Since  then, we have worked with the Congress, OMB, and the CIO Council  to promote the importance of architectures and assist agencies in  developing, maintaining, and using them. In our reviews of selected  agency IT management practices and major systems modernization  programs, we have consistently identified the lack of an architecture  as a major management weakness and made recommendations to  address this important area.
To help oversee and budget for federal IT investments, OMB began  developing the FEA in 2002, and has since issued versions of four of  its five major parts. According to OMB, the FEA is to provide a  common, governmentwide framework for agency enterprise  architectures and IT investments. Thus far, OMB reports that it has  begun using the FEA to identify and address interagency duplication  of effort and to launch interagency projects.
subsections: section_title: What Is an Enterprise Architecture?
paragraphs: In simplest terms, an enterprise is any purposeful activity, and an  architecture is the structural description of an activity. Building on  this, we can view enterprise architectures as systematically derived  and captured structural descriptions—in useful models, diagrams,  and narrative—of the mode of operation for a given enterprise,  which can be either a single organization or a functional or mission  area that transcends more than one organizational boundary (e.g.,  financial management, homeland security).
The architecture can also be viewed as a blueprint that links an  enterprise’s strategic plan to the programs and supporting systems  that it intends to implement to accomplish the mission goals and  objectives laid out in the strategic plan. As such, the architecture  describes the enterprise’s operations in both logical terms (such as  interrelated business processes and business rules, information  needs and flows, and work locations and users) and technical terms  (such as hardware, software, data, communications, and security  attributes and performance standards). Moreover, it provides these  perspectives both for the enterprise’s current (or “as-is”)  environment and for its targeted future (or “to-be”) environment, as  well as for the transition plan for moving from the “as-is” to the “to- be” environment.
section_title: Importance of Enterprise Architectures
paragraphs: The importance of enterprise architectures is a basic tenet of IT  management, and their effective use is a recognized hallmark of  successful public and private organizations. For over a decade, we  have promoted the use of architectures, recognizing them as a  crucial means to a challenging goal: that is, agency operational  structures that are optimally defined, in terms of both business and  technology. The alternative, as our work has shown, is perpetuation  of the kinds of operational environments that saddle most agencies  today, in which the lack of integration among business operations  and the IT resources that support them leads to systems that are  duplicative, not well integrated, and unnecessarily costly to  maintain and interface.
Managed properly, an enterprise architecture can clarify and help  optimize the interdependencies and relationships among an  organization’s business operations and the underlying IT  infrastructure and applications that support these operations.  Employed in concert with other important IT management controls  (such as portfolio-based capital planning and investment control  practices), architectures can greatly increase the chances that  organizations’ operational and IT environments will be configured  so as to optimize mission performance. Enterprise architectures are  integral to managing large-scale programs in federal departments  and agencies, as well as initiatives that span several agencies, such  as those currently being undertaken to support OMB’s electronic  government (e-government) and “Line of Business” efforts.
section_title: Brief History of Enterprise Architecture Frameworks and Management Guidance
paragraphs: During the mid-1980s, John Zachman, widely recognized as a leader  in the field of enterprise architecture, identified the need to use a  logical construction blueprint (i.e., an architecture) for defining and  controlling the integration of systems and their components.  Accordingly, Zachman developed a structure or framework for  defining and capturing an architecture, which provides for six  “windows” from which to view the enterprise. Zachman also  proposed six abstractions or models associated with each of these  perspectives. Zachman’s framework provides a way to identify and  describe an entity’s existing and planned component parts, and the  relationships between those parts, before the entity begins the  costly and time-consuming efforts associated with developing or  transforming itself.
Since Zachman introduced his framework, a number of frameworks  have emerged within the federal government, beginning with the  publication of the National Institute of Standards and Technology  (NIST) framework in 1989. Since that time, other federal entities  have issued enterprise architecture frameworks, including the  Department of Defense (DOD) and the Department of the Treasury.  In September 1999, the federal CIO Council published the Federal  Enterprise Architecture Framework, which was intended to provide  federal agencies with a common construct for their architectures,  thereby facilitating the coordination of common business processes,  technology insertion, information flows, and system investments  among federal agencies. The Federal Enterprise Architecture  Framework describes an approach, including models and  definitions, for developing and documenting architecture  descriptions for multiorganizational functional segments of the  federal government.
In February 2002, OMB established the Federal Enterprise  Architecture Program Management Office to develop the FEA,  which, according to OMB, is intended to facilitate governmentwide  improvement through cross-agency analysis and identification of  duplicative investments, gaps, and opportunities for collaboration,  interoperability, and integration within and across agency programs.  The FEA is composed of five “reference models” describing the  federal government’s (1) business (or mission) processes and  functions, independent of the agencies that perform them,  (2) performance goals and outcome measures, (3) service delivery  means, (4) information and data definitions, and (5) technology  standards. The reference models are intended to inform agency  efforts to develop their agency-specific enterprise architectures and  enable agencies to ensure that their proposed investments are not  duplicative with those of other agencies and to pursue, where  appropriate, joint projects. The FEA reference models are  summarized in table 1.
Although these post-Zachman frameworks differ in their  nomenclatures and modeling approaches, most provide for defining  an enterprise’s operations in both logical terms and technical terms,  provide for defining these perspectives for the enterprise’s current  and target environments, and call for a transition plan between the  two.
Several laws and regulations have established requirements and  guidance for agencies’ management of architectures, beginning with  the Clinger-Cohen Act in 1996, which directs the CIOs of major  departments and agencies to develop, maintain, and facilitate the  implementation of IT architectures as a means of integrating agency  goals and business processes with IT. OMB Circular A-130, which  implements the Clinger-Cohen Act, requires that agencies document  and submit their initial enterprise architectures to OMB and updates  when significant changes to their architectures occur. The circular  also directs the OMB Director to use various kinds of reviews to  evaluate the adequacy and efficiency of agency compliance with the  circular.
OMB was given explicit responsibility for overseeing government  enterprise architectures by the E-Government Act of 2002, which  established the Office of Electronic Government within the office.  More specifically, it gives OMB the responsibility for facilitating the  development of enterprise architectures within and across agencies  and supporting improvements in government operations through the  use of IT.
section_title: Prior Work Indicates Opportunities for Improving Enterprise Architectures
paragraphs: We began reviewing federal agencies’ use of architectures in 1994,  initially focusing on those agencies that were pursuing major  systems modernization programs that were high risk. These  included the National Weather Service systems modernization, the  Federal Aviation Administration air traffic control modernization,and the Internal Revenue Service tax systems modernization.
Generally, we reported that these agencies’ enterprise architectures  were incomplete, and we made recommendations that they develop  and implement complete enterprise architectures to guide their  modernization efforts.
Since then, we have reviewed architecture efforts at other federal  agencies, including the Department of Education, the former  Customs Service, the former Immigration and Naturalization  Service, the Centers for Medicare and Medicaid Services, the  Department of Defense (DOD), the Federal Bureau of  Investigation, and the National Aeronautics and Space  Administration. These reviews have identified the absence of  complete and enforced enterprise architectures, which has led to  agency business operations, systems, and data that are not  integrated and that are duplicative and incompatible. These  conditions, in turn, have either prevented agencies from sharing  data or forced them to do so through inefficient manual processes  or costly, custom-developed system interfaces.
section_title: Our Enterprise Architecture Management Maturity Framework
paragraphs: To contribute to the evolution and maturity of the enterprise  architecture discipline, in 2002, we published version 1.0 of our  Enterprise Architecture Management Maturity Framework  (EAMMF) as an extension of A Practical Guide to Federal  Enterprise Architecture, Version 1.0, published by the CIO Council.  By arranging core elements from the practical guide into a matrix of  five hierarchical stages and four critical success attributes, this  framework provides a common benchmarking tool for planning and  measuring enterprise architecture efforts. In April 2003, we  published version 1.1 of this framework, which reflects changes  and additions that are based on comments we received on the initial  version, as well as on our experiences in reviewing enterprise  architecture programs.
EAMMF version 1.0 is made up of five stages of maturity, each of  which includes an associated set of elements along with all the  elements of the previous stages. In addition to the maturity stages,  each core element is associated with attributes that are critical to  the successful performance of any management function. Figure 1  shows a summary of version 1.0 of the framework and shows the  key elements with the associated stages and attributes.
Version 1.1 of this framework was released in April 2003. Like the  initial version, Version 1.1 is based on the CIO Council guidance,  augmented by our experience in reviewing agency architecture  programs. Changes and additions to the framework were also based  on comments received from federal agencies on the initial version.  Figure 2 shows a summary of Version 1.1.
Overall, version 1.1 is more demanding (i.e., sets a higher standard)  than version 1.0 because version 1.1 adds content and links the  framework to related IT management guidance, such as our IT  investment management framework. Key differences in version 1.1  of the framework appear first in stage 2 and affect later stages either  explicitly or implicitly. That is, some planning elements associated  with stage 2 now propagate explicitly through later stages as plans  are executed and architecture products are developed, completed,  and implemented. For example:  ●  Version 1.1 includes “performance” among the models that are  needed to describe the “as-is” and “to-be” environments; these  models are introduced into the planning elements in stage 2 and  built upon as plans are executed: that is, as architecture products  are developed and completed in stages 3 and 4, respectively.  ●  Version 1.1 explicitly recognizes the need to address security in the  descriptions of the “as-is” and “to-be” environments; this element is  introduced in stage 2 and reiterated in stages 3 and 4.  ●  Version 1.1 introduces the need to plan for metrics in stage 2 and to  measure different aspects of enterprise architecture development,  quality, and use in stages 3, 4, and 5.
section_title: OMB Has Made Progress on FEA, but Questions Remain
paragraphs: In 2001, the lack of a federal enterprise architecture was cited by  OMB’s E-Government Task Force as a barrier to the success of the  administration’s e-government initiatives. In response, OMB began  developing the FEA, and over the last 23 months it has released  various versions of all but one of the five FEA reference models.  According to OMB, the purpose of the FEA, among other things, is  to provide a common frame of reference or taxonomy for agencies’  individual enterprise architecture efforts and their planned and  ongoing investment activities.
OMB reports that it first began using the FEA in 2002 as part of the  fiscal year 2004 budget cycle to identify duplicative investments,  gaps, and opportunities for collaboration, interoperability, and  integration within and across government agency programs. OMB  has since required agencies to use the FEA in developing their fiscal  year 2005 budget submissions. Despite OMB’s progress, however,  questions remain about the FEA.
subsections: section_title: OMB Has Cited a Number of Broad Purposes for the FEA
paragraphs: OMB has identified multiple purposes for the FEA. One purpose  cited is to inform agencies’ individual enterprise architectures and  to facilitate their development by providing a common classification  structure and vocabulary. Another stated purpose is to provide a  governmentwide framework that can increase agencies’ awareness  of IT capabilities that other agencies have or plan to acquire, so that  they can explore opportunities for reuse. Still another stated  purpose is to help OMB decision-makers identify opportunities for  collaboration among agencies through the implementation of  common, reusable, and interoperable solutions. To this end, the  business reference model states that OMB will use the FEA to  analyze agency IT investments to identify   ●  which agencies share common business functions, processes, and  ●  which budget requests support duplicative business functions and  ●  where the government is investing money on redundant capabilities.
According to OMB, still another purpose of the FEA is to provide the  Congress with information that it can use as it considers the  authorization and appropriation of funding for federal programs.
section_title: OMB Has Released Versions of Four of Five FEA Reference Models
paragraphs: OMB has issued at least initial versions of four of the five reference  models and plans to issue the fifth in the near future (see table 1).  The following summarizes the purpose, content, and status of each  reference model.
Performance reference model. According to OMB, the performance  reference model is intended to produce IT performance information,  articulate the contribution of IT to business outputs and outcomes,  and identify performance improvement opportunities that cross  organizational boundaries.
To accomplish these purposes, the model specifies measurement  areas (e.g., mission and business results), measurement categories  (e.g., services for citizens), and generic measurement indicators  (e.g., delivery time) that agencies are to use to organize their  respective measurement indicators. It also describes a process for  agencies to use to identify and define these measurement indicators.  Version 1.0 of the model was released in September 2003.
Business reference model. OMB characterizes the business  reference model as being the foundation of the FEA. It describes the  businesses of the federal government, independent of the agencies  that perform them. According to OMB, the purpose of the business  reference model is to provide the basis for analyzing IT investments  and associated budget requests relative to whether they support  common business functions, processes, and activities. OMB expects  agencies to use the model as part of their capital planning and  investment control processes to help identify opportunities for  consolidating IT investments across the federal government.
The model consists of four business areas: (1) services for citizens,  (2) mode of delivery, (3) support delivery of services, and  (4) management of government resources. These four business  areas are decomposed into 39 lines of business, which are made up  of 153 subfunctions. Examples of lines of business under the  “services for citizens” business area are homeland security, law  enforcement, and economic development. For the homeland  security line of business, an example of a subfunction is border and  transportation security; for law enforcement, a subfunction example  is citizen protection; and for economic development, a subfunction  example is financial sector oversight. Version 1.0 of the model was  released to agencies in July 2002. In June 2003, version 2.0 was  released.
Service component reference model. According to OMB, the service  component reference model identifies and classifies IT service (i.e.,  application) components that support federal agencies so that OMB  can identify, among other things, agencies that are building or have  already built similar components that can be reused. Agencies are  expected to use the service reference model to do the same.
The model is organized as a hierarchy, beginning with seven service  domains. These service domains are decomposed into 29 service  types (see table 2), which are further broken down into 168  components. For example, the customer services domain is made up  of three service types: customer relationship management, customer  preferences, and customer-initiated assistance. Components of the  customer relationship management service type include call center  management and customer analytics; components of the customer  preferences service type include personalization and subscriptions;  and components of the customer-initiated assistance service type  include on-line help and on-line tutorials. Version 1.0 of the service  component reference model was released in June 2003.
Data and information reference model. The data and information  reference model is intended to help define the types of interactions  and information exchanges that occur between the government and  its customers. According to OMB, the model will describe data and  information types that support program and business line  operations and the relationships among these types. According to  OMB officials, the model’s release is imminent.
Technical reference model. The technical reference model is  intended to help agencies define their respective target technical  architectures. It describes the standards, specifications, and  technologies that collectively support the secure delivery, exchange,  and construction of service components. OMB describes the model  as being made up of the following four core service areas:   ●  Service access and delivery: the collection of standards and  specifications that support external access, exchange, and delivery  of service components.  ●  Service platform and infrastructure: the delivery platforms and  infrastructure that support the construction, maintenance, and  availability of a service component or capability.   ●  Component framework: the underlying foundation, technologies,  standards, and specifications by which service components are  built, exchanged, and deployed.  ●  Service interface and integration: the collection of technologies,  methodologies, standards, and specifications that govern how  agencies will interface internally and externally with a service  component.
Each of these four core service areas is made up of service  categories, which identify lower levels of technologies, standards,  and specifications; service standards, which define the standards  and technologies that support the service category; and the service  specification, which details the standard specification or the  provider of the specification. For example, within the first core  service area (service access and delivery), an example of a service  category is access channels, and service standards are Web browsers  and wireless personal digital assistants. Examples of service  specifications for the Web browser service standard are Internet  Explorer and Netscape Navigator. Version 1.0 of the technical  reference model was released in January 2003 and then revised in  August 2003 to incorporate minor revisions that were based, in part,  on agencies’ reviews. This version—version 1.1—was used during  the 2005 budget process.
section_title: OMB Has Used the FEA to Identify Five Areas for Interagency Collaboration
paragraphs: As part of the fiscal year 2004 budget cycle, OMB required agencies  to align business cases for their proposed IT investments to the  business reference model; beginning with the fiscal year 2005  budget cycle, agencies were required to align their business cases to  all the available reference models (i.e., the business, performance,  technical, and service component reference models). This alignment  activity was intended to result in the identification of redundancies  and opportunities for collaboration. According to OMB, the fiscal  year 2004 IT investment budget review process identified potential  redundancies in six lines of business. Further analysis of these six  lines of business as part of the fiscal year 2005 IT budget process  resulted in OMB settling on five lines of business in which to pursue  opportunities for collaboration (i.e., financial management, human  resources, grants, health, and case management).
Since then, OMB initiated a governmentwide analysis of these five  lines of business to examine business and IT data and best practices  for each. According to OMB, over the next several months, agency- led teams will identify common solutions and define a target  architecture that is to be reflected in a business case for proposed  IT investments for each line of business. The business cases are to  be submitted for review in the fiscal year 2006 budget process. To  this end, on April 15, 2004, OMB issued a formal request for  information, seeking information from industry and government  service providers on common solutions and target architectures for  three of the five lines of business: financial management, human  resources, and grants management.
section_title: OMB Plans to Improve the FEA and Expand Its Use
paragraphs: According to OMB officials, the FEA is in the early stages of its  development and use, with future development and uses planned.  OMB’s plans for improving the FEA include releasing the previously  mentioned data and information reference model, creating a plan for  FEA management and maintenance, revising and consolidating  reference models, and expanding use of the automated tool for  collecting FEA data from agencies. Each is discussed below.
First, OMB plans to develop a formalized Management and  Maintenance Plan that it says will provide explicit instructions to  agencies on the roles, responsibilities, standards, and expectations  for the management and upkeep of the FEA. Second, according to  OMB, another planned activity is annually revising the reference  models and consolidating all five reference models into one  document. Specifically, it plans to (1) release a new version of the  business reference model in mid-spring of each year, so that  agencies will be able to use it when setting strategic budget  priorities, and (2) create a consolidated set of models that,  according to OMB, will facilitate integration of the reference models  and changes across all the models as they are updated. Finally, it is  expecting agencies to expand their use of the Federal Enterprise  Architecture Management System, so that agencies themselves,  rather than OMB, will have the means to identify opportunities for  collaboration internally as well as across agency boundaries.
section_title: Agencies Have Expressed High Levels of FEA Understanding and Support
paragraphs: As part of our governmentwide report on enterprise architecture  maturity, we reported on federal agency views on the FEA,  particularly agencies’ understanding of and support for it and  agencies’ assessment of the impact of it on their respective  enterprise architectures. In general, we reported that most  agencies understood and supported the FEA, although a handful did  not. More specifically, of the 96 agencies that we contacted, about  80 percent told us that they understood the goals and objectives of  the FEA (about 8 percent did not). Additionally, about 67 percent  said that they understood the approach OMB was following to  develop the FEA (about 13 percent did not).
Regarding agency support for the FEA, about 80 percent of the  agencies said that they supported its goals and objectives (about 6  percent did not); about 63 percent stated that they supported OMB’s  approach to developing the FEA (about 10 percent did not). Further,  about 72 percent told us that their respective architectures were  traceable to the FEA (about 6 percent were not). With respect to its  impact, about 61 percent of the agencies said that their respective  enterprise architectures would change as a result of the FEA (about  8 percent did not). (See table 3.)
section_title: As the FEA Continues to Evolve, Questions Need to Be Addressed
paragraphs: Despite OMB progress in developing the FEA, questions remain. We  raise these questions in an effort to enhance agency understanding  of the FEA and facilitate its use. As OMB continues to mature the  FEA, these questions should be addressed.
Should the FEA be described as an enterprise architecture? As  discussed earlier in this statement, a true enterprise architecture is  intended to provide a blueprint for optimizing an organization’s  business operations and implementing the IT that supports them.  Accordingly, well-defined enterprise architectures describe, in  meaningful models, both the enterprise’s “as-is” and “to-be”  environments, along with the plan for transitioning from the current  to the target environment. To be meaningful, these models should  be inherently consistent with one another, in view of the many  interrelationships and interdependencies among, for example,  business functions, the information flows among the functions, the  security needs of this information, and the services and applications  that support these functions.
Our reading of the four available reference models does not  demonstrate to us that this kind of content exists in the FEA, and  thus we believe that the FEA is more akin to a point-in-time  framework or classification scheme for federal government  operations. Our discussions with OMB officials confirmed our  reading of the FEA. Accordingly, if agencies use the FEA as a model  for defining the depth and detail for their own architectures, the  agencies’ enterprise architectures may not provide sufficient  content for driving the implementation of systems.
Is the expected relationship between agencies’ enterprise  architectures and the FEA clearly articulated? According to OMB,  the FEA is to inform agency enterprise architectures. For example,  OMB has stated that although it is not mandating that the business  reference model serve as the foundation for every agency’s business  architecture, agencies should invest time mapping their respective  business architectures to the FEA. Similarly, OMB has stated that  agencies’ alignment of their respective architectures to the service  component reference model and the technical reference model will  enable each agency to categorize its IT investments according to  common definitions.
Such descriptions of the agency enterprise architecture/FEA  relationship, in our view, are not clear, in part because definitions of  such key terms as alignment, mapping, and consistency were not  apparent in the FEA. As with any endeavor, the more ambiguity and  uncertainty there is with requirements and expectations, the greater  the use of assumptions and thus deviation from the intended course  of action. This is particularly true in the area of enterprise  architecture.
How will the security aspects of the FEA be addressed? Our work  has found that a well-defined enterprise architecture should include  explicit discussion of security, including descriptions of security  policies, procedures, rules, standards, services, and tools.  Moreover, security is an element of the very fabric of architecture  artifacts and models and thus should be woven into them all. As our  experience in reviewing agency security practices and research of  leading practices shows, security cannot be an afterthought when it  comes to engineering systems or enterprises.
OMB has stated that it plans to address security through what it  terms a “security profile” to be added to the FEA. However, OMB  officials could not comment on the profile’s status or development  plans, beyond stating that the CIO Council is taking the lead in  developing the profile.
section_title: Overall, Federal Agency Architecture Management Is Not Mature, but Some Agencies Are Doing Well and Efforts Are under Way to Advance Governmentwide Maturity
paragraphs: As we reported in 2003, while some agencies have made progress in  improving their enterprise architecture management maturity,  progress for the federal government as a whole has not occurred.  In particular, the percentage of agencies that had established at least  the foundation for effective enterprise architecture management  was virtually unchanged from where it was in 2001 (about 50  percent). Further, we reported that when the state of enterprise  architecture is considered in relation to a more recent and  demanding benchmark, this percentage dropped to about 20 percent  (in round terms), even though some agencies fared favorably against  this benchmark and were role models for others to follow. This  composite picture of immature enterprise architecture management  can be attributed to several long-standing challenges, which were  the basis for the recommendations that we made to OMB in 2002  and reiterated in 2003. Recently, OMB and the federal CIO Council  began to take steps that are consistent with many of our  recommendations.
subsections: section_title: Governmentwide Progress in Managing Enterprise Architecture Has Been Limited
paragraphs: Between 2001 and 2003, little substantial change was revealed in  agencies’ collective enterprise architecture maturity, when this is  compared against version 1.0 of our framework. Of the 93 agencies  that we reported on in 2001 and 2003,   ●  22 agencies (24 percent) increased their maturity,  ●  24 agencies (26 percent) decreased their maturity, and   ●  47 agencies (51 percent) remained the same.
Agencies’ progress between 2001 and 2003 is similarly limited when  we consider the total number of EAMMF core elements satisfied.  Specifically, the 93 agencies satisfied about 57 percent of all  possible framework elements in 2001 and about 60 percent in 2003.  Upon further inspection, these data show that agencies improved in  satisfying certain core elements, but these improvements were  offset by declines in satisfaction of other core elements. The  following are examples of elements where agency satisfaction  significantly improved:  ●  “Metrics exist for measuring enterprise architecture benefits” (about  a 38 percent increase),   ●  “Chief architect exists” (about a 23 percent increase), and  ●  “Enterprise architecture products are under configuration  management” (about an 18 percent increase).
The following are examples of core elements where agency  satisfaction significantly declined:  ●  “Enterprise architecture products describe ‘as-is’ environment, ‘to- be’ environment, and sequencing plan” (about a 39 percent  decrease),  ●  “Enterprise architecture products describe enterprise’s business— and the data, applications, and technology that support it” (about a  36 percent decrease),  ●  “Either enterprise architecture steering committee, investment  review board, or agency head has approved enterprise architecture”  (about a 25 percent decrease), and   ●  “Program office responsible for enterprise architecture development  exists” (about a 23 percent decrease).
For the 22 agencies that advanced one or more maturity stages from  2001 to 2003, completion of no single core element accounted for  these advancements. That is, for the 22 agencies, increases in  maturity stages are most often attributable to the fulfillment of 7  core elements spanning 3 stages of maturity. Table 4 shows those  newly satisfied core elements that most often accounted for an  increase in a maturity stage.
As with increases in agency maturity levels, no single core element  accounted for the decreases in agency maturity between 2001 and  2003. However, as shown in table 5, the stage 2 framework element  requiring a program office was the most significant newly  unsatisfied element for the 24 agencies that had decreased maturity  levels.
One factor contributing to the decreases in maturity between 2001  and 2003 is improved accuracy in agencies’ responses to our data  collection instrument. Improved accuracy is a function of  (1) improved agency familiarity with and understanding of  enterprise architecture management and our framework and (2) the  requirement in our 2003 work for documentation to support certain  agency responses.
section_title: Overall, the State of Architecture Development and Use in Federal Agencies Is Uneven and Needs to Improve
paragraphs: When compared against version 1.1 of our framework, the state of  enterprise architecture management across the federal government  is not mature. In particular, about 21 percent of federal agencies (20  of 96) have the stage 2 management foundation that is needed to  begin successfully developing, implementing, and maintaining an  enterprise architecture, and about 79 percent of agencies (76 of 96)  have not yet advanced to this basic stage of maturity. (One agency,  the Executive Office of the President, was at a stage of maturity that  can be considered effective.) This overall state of maturity is  consistent for each of the three agency groups surveyed:  departments, component agencies, and independent agencies.
No single core element that was added to our framework  contributed significantly to this current state, but the “methodology”  subelement of the stage 2 element “Enterprise architecture is being  developed with a framework, methodology, and automated tool”  was the most significant factor that kept agencies from achieving  stage 2. The absence of a “methodology” kept seven agencies from  attaining stage 2 status.
Nevertheless, certain core elements of version 1.1 of our framework  were frequently not satisfied by agencies. Of the 31 core elements in  version 1.1, 17 were not satisfied by more than 50 percent of the  agencies. Further, 8 elements associated with stages 4 and 5 were  not satisfied by about 80 percent of the agencies.
Although significant gaps existed across federal agencies in meeting  the core elements of version 1.1 of the framework, at least 80  percent of the agencies reported performing 8 core elements that  were related to stages 2 and 3. The most often satisfied elements  included the following stage 2 elements:  ●  “Enterprise architecture plans call for describing both the ‘as-is’ and  the ‘to-be’ environments of the enterprise, as well as a sequencing  plan for transitioning from the ‘as-is’ to the ‘to-be’”(about 94  percent);  ●  “Enterprise architecture plans call for describing both the ‘as-is’ and  the ‘to-be’ environments in terms of business, performance,  information/data, application/service, and technology” (about 90  percent); and  ●  “Enterprise architecture plans call for business, performance,  information/data, application/service, and technology descriptions  to address security” (about 86 percent).
The most often satisfied elements also included the stage 3 element  ●  “Enterprise architecture products describe or will describe both the  ‘as-is’ and the ‘to-be’ environments of the enterprise, as well as a  sequencing plan for transitioning from the ‘as-is’ to the ‘to-be’”  (about 88 percent).
In addition, although only one agency has achieved stage 5, many  agencies reported satisfying the stage 5 core elements requiring that  IT investments comply with their enterprise architecture (about 80  percent) and that enterprise architecture is an integral component  of their IT investment management process (about 69 percent).
Departments, component agencies, and independent agencies had  varying degrees of success satisfying certain core elements within  individual stages. In general, departments had more success  satisfying lower stage elements than did components and  independent agencies. In stage 2, for example, while 69 percent of  departments reported using a framework, methodology, and  automated tool to develop their enterprise architecture, only 29  percent of components and 50 percent of independent agencies  reported the same. Additionally, in stage 3, while 81 percent of  departments reported that progress against plans is measured and  reported, only 25 percent of components and 25 percent of  independent agencies reported the same. One possible reason for  this situation is that OMB’s oversight of agency enterprise  architecture efforts focuses on departments and major independent  agencies—not on component agencies.
Although, as a whole, departments satisfied more lower-level  framework elements than did component agencies and independent  agencies, departments generally still would need to satisfy several  lower-level framework elements to achieve a stage 3 maturity level.  On average, each department needs to satisfy 2 core elements to  satisfy all stage 2 and 3 framework elements.
The maturity stage of a department generally was not indicative of  the maturity of its component agencies. For example, the  Departments of Health and Human Services and Transportation  reached stage 2, while their component agencies averaged stage 1.
Also, DOD’s Global Information Grid architecture was at stage 3,  while its business enterprise architecture was at stage 1, as were its  components, in general. Conversely, the Departments of Commerce,  Justice, and the Treasury were at stage 1, with their component  agencies averaging higher maturity levels; the component agencies  of Commerce showed a slightly higher maturity level than did  component agencies of all other departments. That is, the average  maturity level of all component agencies we surveyed was 1.23, but  the Commerce component agencies averaged 1.80, largely owing to  the maturity levels for the Bureau of the Census (stage 3), the U.S.  Patent and Trademark Office (stage 2), and the National Oceanic  and Atmospheric Administration (stage 2). The Department of  Agriculture’s maturity level (stage 1) was the same as the average  maturity level of its component agencies.
section_title: Eight Agencies Were Well Positioned to Achieve Stage 5 Maturity, and Many Agencies Were Performing Core Elements beyond Their Assigned Maturity Stages
paragraphs: Although the Executive Office of the President was the sole stage 5  agency, seven other agencies were close to becoming models of  enterprise architecture management. For example, the Office of  Personnel Management (OPM), which achieved stage 1 of version  1.1, needed to satisfy only five more elements to become a stage 5  agency. OPM needed to satisfy one stage 2 element (“Enterprise  architecture plans call for developing metrics for measuring  enterprise architecture progress, quality, compliance, and return on  investment”), one stage 3 element (“Progress against enterprise  architecture plans is measured and reported”),  two stage 4 elements  (“Enterprise architecture products and management processes  undergo independent verification and validation” and “Quality of  enterprise architecture products is measured and reported”), and  one stage 5 element (“Return on enterprise architecture investment  is measured and reported”).
Ninety-six percent of agencies in stages 1 through 4 were  performing at least one core element above their current maturity  stage, which means that as a whole, agencies are, to varying  degrees, performing above their assigned maturity stages.  Specifically, of the 76 agencies at stage 1, about 95 percent were  performing at least one core element in a higher maturity stage.  About 35 percent of agencies need to satisfy only one additional  core element to advance to at least the next maturity stage. Two of  these agencies, Commerce and the U.S. Mint, could advance two  stages by satisfying just one additional core element. Commerce,  currently a stage 1 agency, could advance to stage 3 by satisfying the  framework element “Program office responsible for development  and maintenance exists.” The Mint, also currently a stage 1 agency,  could advance to stage 3 by satisfying the framework element  “Adequate resources exist.”
section_title: Agencies Identified Enterprise Architecture Management Challenges
paragraphs: Agencies continue to face the same management challenges that we  identified in 2001—that is, obtaining top management support and  commitment, overcoming parochialism, and having the requisite  resources (financial and human capital) to accomplish the work.  Moreover, the prevalence of these challenges has grown. For  example, getting top management to understand the purpose,  content, and value of architectures was seen as a challenge by about  50 percent of agencies—up from 39 percent in 2001. As our  framework recognizes, obtaining executive understanding and  support is essential to having an effective enterprise architecture  program. Without it, agencies will have increased difficulty in  addressing other challenges such as overcoming parochialism  among organizational components and obtaining requisite resources  (funding and human capital). Our work in 2003 bears this out—at  the same time that the percentage of agencies identifying top  management understanding and support as a challenge rose, the  percentage of agencies identifying these other challenges almost all  rose. For example, the percentage that identified parochialism as a  challenge grew from about 39 to 47 percent. Also, while about 50  percent of agencies continued to report funding as a significant  challenge, the percentage of agencies that reported obtaining skilled  staff as a challenge grew from about 32 to 49 percent. (See table 6.)
Agencies have also reported mixed levels of satisfaction with OMB’s  efforts to address these management challenges. Specifically, just  over half of the agencies were satisfied with OMB’s efforts to foster  top management understanding and to overcome agency component  organization parochialism (about 58 and 53 percent, respectively).  Moreover, fewer than half of the agencies (40 percent) were  satisfied with OMB’s actions to address their enterprise architecture  funding and staffing challenges. (See table 7.)
section_title: OMB and the Federal CIO Council Have Recently Acted to Strengthen Agency Enterprise Architecture Maturity
paragraphs: Both OMB and the federal CIO Council have long been advocates of  enterprise architecture. For example, in collaboration with others  and us, OMB issued guidance on the purpose and use of enterprise  architectures shortly after passage of the Clinger-Cohen Act of  1996. Subsequently, it incorporated enterprise architecture  considerations into its oversight processes and issued guidance  directing that agency IT investments be based on agency enterprise  architectures. Further, OMB collaborated with the CIO Council and  us on the Practical Guide to Federal Enterprise Architecture,  Version 1.0. As a means of promoting agencies’ enterprise  architecture use, OMB has also included requirements for having  and using enterprise architectures as part of the budget process,  which began with the fiscal year 2002 budget cycle and, according to  OMB officials, has continued since then. OMB has also worked  through the CIO Council, which is chaired by OMB, to improve  enterprise architecture management and use.
Despite OMB’s longstanding advocacy and support for enterprise  architecture, we reported in 2002 that OMB needed to advance the  level of enterprise architecture management maturity by exercising  stronger leadership and improved oversight and by identifying  governmentwide solutions to common enterprise architecture  management challenges facing agencies. Accordingly, we  recommended that the OMB Director, in collaboration with the  federal CIO Council, use our maturity framework and the agency  baseline information provided in our February 2002 report as the  basis for helping agencies to advance the state of their respective  enterprise architecture development, implementation, and  maintenance efforts, and for measuring agency progress. We further  recommended that in doing so, the OMB Director require agencies  to (1) submit to OMB an annual update of the agency’s satisfaction  of each of the core elements contained in our maturity framework  and (2) have this update verified by the agency’s inspector general  or comparable audit function before it is submitted to OMB.  Additionally, we recommended that the OMB Director, in  collaboration with the CIO Council, develop and implement a plan  to address the governmentwide impediments to greater agency use  of enterprise architectures. We recommended that, at a minimum,  this plan should include the two primary challenges identified in our  2002 report—that is, agency executive management understanding  of enterprise architectures and the availability of enterprise  architecture human capital expertise. Finally, we recommended that  the director report annually to the Senate Committee on  Governmental Affairs and the House Committee on Government  Reform on the results of OMB’s annual update of the state and  progress of federal agencies’ enterprise architecture efforts. OMB  officials generally agreed with the findings and conclusions of our  report and stated that they would consider using our framework.
As previously noted, we reported in 2003 that agencies had  collectively made little progress toward improving their enterprise  architecture maturity. In commenting on this report, OMB officials  told us that they were still considering using our framework as a  basis for evaluating agencies’ progress in developing and  implementing their architectures, but had not committed to doing so  because they were still reviewing options. Additionally, these  officials did not have any plans to address governmentwide  impediments to greater agency use of architectures. Further, they  said that OMB has provided and plans to continue to provide  information to the Congress on the state of agency enterprise  architecture efforts and on progress in implementing the FEA. As a  result, we again called for stronger leadership and reiterated the  recommendations we made in our February 2002 report, with the  modification that OMB use version 1.1 of our framework and the  baseline data from our 2003 report. Additionally, we recommended  that the OMB Director, in developing and implementing the plan we  previously recommended to address governmentwide impediments  to greater agency use of enterprise architectures, ensure that the  plan provides for identifying agencies that have effectively  overcome enterprise architecture management challenges and  sharing those and other lessons learned and best practices. Also, we  recommended that the director, in annually reporting to the Senate  Committee on Governmental Affairs and the House Committee on  Government Reform, as we previously recommended, include in the  report what steps have been taken to implement our  recommendations, including reasons for not adopting our maturity  framework.
OMB and the CIO Council have recently initiated actions consistent  with many of our recommendations. For example, the council  established a Chief Architect Forum, the first meeting of which was  held on April 5, 2004, and in which we participated. This forum has  created a means for chief architects across federal agencies to  systematically collaborate on matters of mutual concern and  interest. Vehicles for this collaboration include periodic meetings, a  listserve to share information and ideas, and special gatherings that  focus on specific issues. As another example, OMB recently released  for comment version 1.0 of an agency enterprise architecture  assessment tool. The tool is intended to help individual agencies  assess their enterprise architecture programs. According to OMB,  this initial version will be revised to reflect comments it receives.
In summary, enterprise architecture development and use in the  federal government are maturing, but they are not mature. Given  that effective development and use of enterprise architectures are  critical to federal agencies achieving breakthrough levels of  performance, senior leadership across the government needs to  elevate its attention to this essential transformation and  modernization tool. While progress on this front has occurred over  the last few years, it has been spotty, and in our view, considerable  maturation is needed before the federal government will be  positioned to reap the rewards that others have reported from  effective architecture development and use. The fact remains that  until agencies have and use well-defined enterprise architectures,  they will be severely challenged in their ability to effectively  leverage IT in transforming their operations. Recent steps by OMB  and the CIO Council to assume stronger leadership roles are  encouraging. However, hard work lies ahead to clarify and evolve  the FEA, and to ensure that well-managed architecture programs— ones that produce architecture blueprints that can be implemented  and become integral parts of the fabric of institutional strategic  planning, investment decision-making, and budget execution—are  actually established across the government. These are important  goals, which we support, and we will continue to work with OMB  and the CIO Council throughout the multistep process needed to  ensure that the FEA is appropriately described, matured, and used,  and to advance the state of agency enterprise architecture efforts.
Mr. Chairman, that concludes my testimony. I would be pleased to  answer any questions that you and the other Members of the  Subcommittee may have.
section_title: Contact and Acknowledgements
paragraphs: For further information, please contact Randolph C. Hite at (202)  512-6256 or by e-mail at hiter@gao.gov. Other key contributors to  this testimony included Shannin Addison, Mark Bird, Barbara  Collier, Nancy Glover, Anh Le, Nnaemeka Okonkwo, Randolph  Tekeley, and William Wadsworth.
This is a work of the U.S. government and is not subject to copyright protection in the  United States. It may be reproduced and distributed in its entirety without further  permission from GAO. However, because this work may contain copyrighted images or  other material, permission from the copyright holder may be necessary if you wish to  reproduce this material separately.