Background

The FBI was founded in 1908 to serve as the primary investigative bureau  of the Department of Justice. Its mission includes upholding the law by  investigating serious federal crimes; protecting the nation from foreign  intelligence and terrorist threats; providing leadership and assistance to  federal, state, local, and international law enforcement agencies; and being  responsive to the public in the performance of these duties. Approximately  11,000 special agents and 16,000 professional support personnel are located  at the bureau’s Washington, D.C., headquarters and at more than 400 offices  throughout the United States and 44 offices in foreign countries.
Mission responsibilities at the bureau are divided among five major  organizational components: Criminal Investigations, Law Enforcement  Services, Counterterrorism and Counterintelligence, Intelligence, and  Administration. Criminal Investigations, for example, investigates serious  federal crimes, including those associated with organized crime, violent  offenses, white-collar crime, government and business corruption, and civil  rights infractions. It also probes federal statutory violations involving  exploitation of the Internet and computer systems for criminal, foreign  intelligence, and terrorism purposes. (The major components and their  associated mission responsibilities are shown in table 1.) Each component  is headed by an Executive Assistant Director who reports to the Deputy  Director, who in turn reports to the Director.
To execute its mission responsibilities, the FBI relies on the use of IT. For  example, it develops and maintains computerized IT systems such as the  Combined DNA Index System to support forensic examinations, the  Digital Collection System to electronically collect information on known  and suspected terrorists and criminals, and the National Crime Information  Center and the Integrated Automated Fingerprint Identification System to  help state and local law enforcement agencies identify criminals.  According to FBI estimates, the bureau manages hundreds of systems,  networks, databases, applications, and associated tools such as these at an  average annual cost of about $800 million.

		FBI’s Existing IT Environment Has Long Suffered from Known Deficiencies

Several prior reviews of the FBI’s existing IT environment have revealed  that it is antiquated and not integrated. Specifically, the Department of  Justice Inspector General reported that as of September 2000, the FBI had  over 13,000 desktop computers that were 4 to 8 years old and could not run  basic software packages. Moreover, it reported that some communications  networks were 12 years old and obsolete, and that many end-user  applications existed that were neither Web-enabled nor user-friendly. In  addition, a December 2001 review initiated by the Department of Justice  found that FBI’s IT environment was disparate. In particular, it identified  234 nonintegrated (“stove-piped”) applications, residing on 187 different  servers, each of which had its own unique databases and did not share  information with other applications or with other government agencies.  Moreover, in June 2002, we reported that IT has been a long-standing  problem for the bureau, involving outdated hardware, outdated software,  and the lack of a fully functional E-mail system. We also reported that these  deficiencies served to significantly hamper the FBI’s ability to share  important and time-sensitive information internally and externally with  other intelligence and law enforcement agencies.

		FBI Has Initiated a Large, Complex Systems Modernization

Following the terrorist attacks of September 11, 2001, the FBI refocused its  efforts to investigate the events and to detect and prevent possible future  attacks. To do this, the bureau changed its priorities and accelerated  modernization of its IT systems. Collectively, the FBI’s many modernization  efforts involve 51 initiatives that the FBI reported will cost about $1.5  billion between fiscal years 2002 and 2004. For example, the Trilogy  project, which is to introduce new systems infrastructure and applications,  includes establishing an enterprisewide network to enable  communications between hundreds of FBI locations domestically and  abroad, upgrading 20,000 desktop computers, and providing 2,400 printers  and 1,200 scanners. In addition, a new investigative data warehousing  initiative called Secure Counterterrorism Operational Prototype  Environment is to (1) aggregate voluminous counterterrorism files  obtained from both internal and external sources and (2) acquire analytical  capabilities to improve the FBI’s ability to analyze these files. Another  initiative, called the FBI Administrative Support System, is to integrate the  bureau’s financial management and administrative systems with the  Department of Justice’s new financial management system.
Beyond the scope and size of the FBI’s modernization effort is the need to  ensure that the modernized systems effectively support information  sharing within the bureau and among its law enforcement and intelligence  community partners. This means that the modernized FBI systems will, in  many cases, have to interface with existing (legacy) systems to obtain data  to accomplish their functions, which bureau officials said will be  challenging, given the nonstandard and disparate nature of the existing IT  environment. Moreover, bureau staff will have to be trained on the new  systems and business processes modified to accommodate their use.

		An Enterprise Architecture Is Essential to Effectively Managing Systems Modernization

The development, maintenance, and implementation of enterprise  architectures (EA) are recognized hallmarks of successful public and  private organizations and as such are an IT management best practice. EAs  are essential to effectively managing large and complex system  modernization programs, such as the FBI’s. Our experience with federal  agencies has shown that attempting a major modernization effort without a  well-defined and enforceable EA results in systems that are duplicative, are  not well integrated, are unnecessarily costly to maintain and interface, and  do not effectively optimize mission performance.
The Congress and the Office of Management and Budget have recognized  the importance of agency EAs. The Clinger-Cohen Act, for example,  requires that agency Chief Information Officers (CIO) develop, maintain,  and facilitate the implementation of architectures as a means of integrating  business processes and agency goals with IT. In response to the act, the  Office of Management and Budget, in collaboration with us and others, has  issued guidance on the development and implementation of these  architectures. It has also issued guidance that requires agency investments  in information systems to be consistent with agency architectures.
An EA is a systematically derived snapshot—in useful models, diagrams,  and narrative—of a given entity’s operations (business and systems),  including how its operations are performed, what information and  technology are used to perform the operations, where the operations are  performed, who performs them, and when and why they are performed.  The architecture describes the entity in both logical terms (e.g.,  interrelated functions, information needs and flows, work locations,  systems, and applications) and technical terms (e.g., hardware, software,  data, communications, and security). EAs provide these perspectives for  both the entity’s current (or “as-is”) environment and for its target (or “to- be”) environment; they also provide a high-level capital investment  roadmap for moving from one environment to the other.
Among others, the Office of Management and Budget, the National Institute  of Standards and Technology, and the federal CIO Council have issued  frameworks that define the scope and content of architectures. For  example, the federal CIO Council issued a framework, known as the  Federal Enterprise Architecture Framework, in 1999. While the various  frameworks differ in their nomenclatures and modeling approaches, they  consistently provide for defining an enterprise architecture’s operations in  both logical terms and technical terms and providing these perspectives  both for the “as-is” and “to-be” environments, as well as the investment  roadmap. Managed properly, an enterprise architecture can clarify and help  optimize the interdependencies and relationships among a given entity’s  business operations and the underlying systems and technical  infrastructure that support these operations.

		The FBI’s Lack of an EA Has Been Previously Reported

Over the past few years, several reviews related to the FBI’s management  of its IT have focused on enterprise architecture efforts and needs. For  example, in July 2001, the Department of Justice hired a consulting firm to  review the FBI’s IT management. Among other things, the consultant  recommended that the bureau develop a comprehensive EA to help reduce  the proliferation of disparate, noncommunicating applications.
The next year, in February 2002, we reported as part of a governmentwide  survey of the state of EA maturity that the FBI was one of a number of  federal agencies that were not effectively managing their architecture  efforts, and we made recommendations to the Office of Management and  Budget for advancing the state of architecture maturity across the federal  government. In this report, we noted that while the FBI was attempting to  lay the management foundation for developing an architecture, the bureau  had not yet established certain basic management structures and controls,  such as establishing a steering committee or group that had responsibility  for directing and overseeing the development of the architecture.
Later, our June 2002 testimony recommended that the FBI significantly  upgrade its IT management capabilities, including developing an  architecture, in order to successfully change its mission and effectively  transform itself. Subsequently, in December 2002, the Department of  Justice Inspector General reported that the FBI needed to complete an  architecture to complement its IT investment management processes.

		GAO’s EA Management Maturity Framework Provides a Tool for Measuring and Improving EA Management Effectiveness

According to guidance published by the federal CIO Council,effective  architecture management consists of a number of key practices and  conditions (e.g., establishing a governance structure, developing policy,  defining management plans, and developing and issuing an architecture). In  April 2003, we published a maturity framework that arranges these key  practices and conditions (i.e., core elements) of the council’s guide into five  hierarchical stages, with Stage 1 representing the least mature and Stage 5  being the most mature. The framework provides an explicit benchmark  for gauging the effectiveness of EA management and provides a roadmap  for making improvements. Each of the five stages is described below.  1. Creating EA awareness. The organization does not have plans to  develop and use an architecture, or it has plans that do not demonstrate  an awareness of the value of having and using an architecture. While  Stage 1 agencies may have initiated some EA activity, these agencies’  efforts are ad hoc and unstructured, lack institutional leadership and  direction, and do not provide the management foundation necessary for  successful EA development. 2. Building the EA management foundation. The organization  recognizes that the EA is a corporate asset by vesting accountability for  it in an executive body that represents the entire enterprise. At this  stage, an organization assigns EA management roles and  responsibilities and establishes plans for developing EA products and  for measuring program progress and product quality; it also commits  the resources necessary for developing an architecture—people,  processes, and tools. 3. Developing the EA. The organization focuses on developing  architecture products according to the selected framework,  methodology, tool, and established management plans. Roles and  responsibilities assigned in the previous stage are in place, and  resources are being applied to develop actual EA products. The scope  of the architecture has been defined to encompass the entire  enterprise, whether organization-based or function-based. 4. Completing the EA. The organization has completed its EA products,  meaning that the products have been approved by the EA steering  committee or an investment review board, and by the CIO. Further, an  independent agent has assessed the quality (i.e., completeness and  accuracy) of the EA products. Additionally, evolution of the approved  products is governed by a written EA maintenance policy approved by  the head of the organization. 5. Leveraging the EA to manage change. The organization has secured  senior leadership approval of the EA products and has a written  institutional policy stating that IT investments must comply with the  architecture, unless granted an explicit compliance waiver. Further,  decision makers are using the architecture to identify and address  ongoing and proposed IT investments that are conflicting, overlapping,  not strategically linked, or redundant. Also, the organization tracks and  measures EA benefits or return on investment, and adjustments are  continuously made to both the EA management process and the EA  products.

	FBI Does Not Have an EA or the Management Foundation Needed to Effectively Develop, Maintain, and Implement One

The FBI has yet to develop an EA, and it does not have the requisite means  in place to effectively develop, maintain, and implement one. The state of  the bureau’s architecture efforts is attributable to the level of management  priority and commitment that the bureau has assigned to this effort. Unless  this changes, it is unlikely the FBI will produce a complete and useful  architecture, and without the architecture, the bureau will be severely  challenged in its ability to implement a set of modernized systems that  optimally support critical mission needs.

		FBI Does Not Have an Architecture

An EA is an essential tool for effectively and efficiently engineering  business operations (e.g., processes, work locations, and information  needs and flows) and defining, implementing, and evolving IT systems in a  way that best supports these operations. As mentioned earlier, an EA  provides systematically derived and captured structural descriptions—in  useful models, diagrams, tables, and narrative—of how a given entity  operates today and how it plans to operate in the future, and it includes a  roadmap for transitioning from today to tomorrow. The nature and content  of these descriptions vary among organizations depending on the EA  framework selected.
The FBI has selected the federal CIO Council’s Federal Enterprise  Architecture Framework as the basis for defining its EA. At the highest  level of component content description, the Federal Enterprise  Architecture Framework requires an “as-is” architectural description, a “to- be” architectural description, and a transition plan. For the “as-is” and “to- be” descriptions, this framework also requires the following major  architecture products: business, information/data, applications, and  technical components.
The FBI has yet to develop any of these architectural components. In  response to our requests for all EA products, FBI officials, including the  chief architect and the deputy chief information officer, told us that they do  not yet exist. They added that they are currently in the process of  developing an inventory of the FBI’s existing (legacy) systems, which is a  first step toward creating “as-is” architectural descriptions. They also  stated that their goal is to develop and issue an initial bureau EA by the fall  of 2003.
The FBI lacks an architecture largely because it is not treating development  and use of one as a management priority. According to the FBI’s chief  architect, although the FBI launched its architecture effort 32 months ago,  resources allocated to this effort have been limited to about $1 million  annually and four staff. In contrast, our research of successful architecture  efforts in other federal agencies shows that their resource needs are  considerably greater than those that the FBI has committed. Similarly, the  Justice Inspector General reported in December 2002 that limited funding  and resources contributed to the immature state of the bureau’s EA efforts.  Additionally, assignment of responsibility and accountability for developing  the architecture has not been stable over the last 32 months. For example,  the chief architect has changed three times in the past 12 months.
As our prior reviews of federal agencies and research of architecture best  practices show, attempts to modernize systems without an architecture,  which is what the FBI is doing, increases the risk that large sums of money  and much time and effort will be invested in technology solutions that are  duplicative, are not well integrated, are unnecessarily costly to maintain  and interface, and do not effectively optimize mission performance. In the  FBI’s case, there are indications that this is occurring. For example, the  director of the modernization program management office told us that the  office recently assumed responsibility for managing three system  modernization initiatives and found that they will require rework in order  for them to be integrated. Such integration—which an EA would have  provided for—was not previously factored into their development.
To allow for a more coordinated and integrated approach to pursuing its  other 48 modernization initiatives, the FBI has started holding informal  meetings among top managers to discuss related systems. However, such  meetings are not a sufficient surrogate for an explicitly defined  architectural blueprint that provides a commonly understood, accepted  frame of reference against which to effectively and efficiently acquire and  implement well-integrated systems.

		Management Structures and Processes Needed to Develop, Maintain, and Implement an EA Are Not In Place

Because the task of developing, maintaining, and implementing an EA is an  important, complex, and difficult endeavor, doing so effectively and  efficiently requires that rigorous, disciplined management practices be  adopted. Such practices form the basis of our EA management maturity  framework, which specifies by stages the key architecture management  structures, processes, and controls that are embodied in federal guidance  and best practices. For example, Stage 2 specifies nine key practices or  core elements that are necessary to provide the management foundation  for successfully launching and sustaining an architecture effort. Five of the  nine Stage 2 core elements are described below.
Establish an architecture steering committee representing the  enterprise and make the committee responsible for directing,  overseeing, or approving the EA. This committee should include  executive-level representatives from each line of business, and these  representatives should have the authority to commit resources and  enforce decisions within their respective organizational units. By  establishing this enterprisewide responsibility and accountability, the  agency demonstrates its commitment to building the management  foundation and obtaining buy-in from across the organization.
Appoint a chief architect who is responsible and accountable for the  EA, and who is supported by the EA program office and overseen by  the architecture steering committee. The chief architect, in  collaboration with the Chief Information Officer, the architecture  steering committee, and the organizational head, is instrumental in  obtaining organizational buy-in for the EA, including support from the  business units, as well as in securing resources to support architecture  management functions, such as risk management, configuration  management, quality assurance, and security management.
Use an architecture development framework, methodology, and  automated tool to develop and maintain the EA. These are important  because they provide the means for developing the architecture in a  consistent and efficient manner. The framework provides a formal  structure for representing the EA, while the methodology is the common  set of procedures that the enterprise is to follow in developing the EA  products. The automated tool serves as a repository where architectural  products are captured, stored, and maintained.
Develop an architecture program management plan. This plan  specifies how and when the architecture is to be developed. It includes a  detailed work breakdown structure, resource estimates (e.g., funding,  staffing, and training), performance measures, and management  controls for developing and maintaining the architecture. The plan  demonstrates the organization’s commitment to managing EA  development and maintenance as a formal program.
Allocate adequate resources to the EA effort. An organization needs to  have the resources (funding, people, tools, and technology) to establish  and effectively manage its architecture. This includes, among other  things, identifying and securing adequate funding to support EA  activities, hiring and retaining the right people, and selecting and  acquiring the right tools and technology to support activities.
Our framework similarly identifies key architecture management practices  associated with later stages of EA management maturity. For example, at  Stage 3, the stage at which organizations focus on architecture  development activities, organizations need to satisfy six core elements.  Two of the six are discussed below.
Issue a documented architecture policy, approved by the  organization’s head, governing the development of the EA. The policy  defines the scope of the architecture, including the requirement for a  description of the baseline and target architecture, as well as an  investment roadmap or sequencing plan specifying the move between  the two. This policy is an important means for ensuring enterprisewide  commitment to developing an EA and for clearly assigning  responsibility for doing so.
Ensure that EA products are under configuration management. This  involves ensuring that changes to products are identified, tracked,  monitored, documented, reported, and audited. Configuration  management maintains the integrity and consistency of products, which  is key to enabling effective integration among related products and for  ensuring alignment between architecture artifacts.
At Stage 4, during which organizations focus on architecture completion  activities, organizations need to satisfy eight core elements. Two of the  eight are described below.
Ensure that EA products and management processes undergo  independent verification and validation. This core element involves  having an independent third party—such as an internal audit function or  contractor that is not involved with any of the architecture development  activities—verify and validate that the products were developed in  accordance with EA processes and product standards. Doing so  provides organizations with needed assurance of the quality of the  architecture.
Ensure that business, performance, information/data,  application/service, and technology descriptions address security. An  organization should explicitly and consistently address security in its  business, performance, information/data, application/service, and  technology EA products. Because security permeates every aspect of an  organization’s operations, the nature and substance of institutionalized  security requirements, controls, and standards should be captured in EA  products.
At Stage 5, during which the focus is on architecture maintenance and  implementation activities, organizations need to satisfy eight core  elements. Two of the eight are described below.
Make EA an integral component of IT investment decision-making  processes. Because the roadmap defines the IT systems that an  organization plans to invest in as it transitions from the “as-is” to the “to- be” environment, the EA is a critical frame of reference for making IT  investment decisions. Using the EA when making such decisions is  important because organizations should approve only those investments  that move the organization toward the “to-be” environment, as specified  in the roadmap.
Measure and report return on EA investment. Like any investment, the  EA should produce a return on investment (i.e., a set of benefits), and  this return should be measured and reported in relation to costs.  Measuring return on investment is important to ensure that expected  benefits from the EA are realized and to share this information with  executive decision makers, who can then take corrective action to  address deviations from expectations.
Effective EA management is generally not achieved until an organization  has a completed and approved architecture that is being effectively  maintained and implemented, which is equivalent to having satisfied many  Stage 4 and 5 core elements. Table 2 summarizes our framework’s five  stages and the associated core elements for each.
The FBI is currently at Stage 1 of our maturity framework. Of the nine  foundational stage core elements (Stage 2), the FBI has fully satisfied one  element by designating a chief architect. Additionally, the bureau has  partially satisfied two other elements. First, it has established an  architecture governance board as its steering committee. However, the  bureau has not included all relevant FBI stakeholders on the board, such as  representatives from its counterterrorism and counterintelligence  organizational component. Second, the bureau has selected the Federal  Enterprise Architecture Framework as the framework to guide its  architecture development. However, it has not yet selected a development  methodology or automated tool (a repository for architectural products).
The FBI has not satisfied the six remaining Stage 2 core elements. For  example, the bureau has not established a program office. In addition, it  has not developed a program management plan that provides for describing  (1) the bureau’s “as-is” and “to-be” environments, as well as a sequencing  plan for transitioning from the “as-is” to the “to-be” and (2) the enterprise in  terms of business, data, applications and technology, including how  security will be addressed in each. With respect to Stages 3, 4, and 5, the  FBI has not satisfied any of the associated core elements. (The detailed  results of our assessment of the FBI’s satisfaction of each of the stages and  associated core elements is provided in app. II.)
The state of the FBI’s EA management maturity is attributable to a lack of  management commitment to having and using an architecture and to giving  it priority. Indeed, several of the core elements cited above as not being  satisfied, such as having EA policies and allocating adequate resources, are  indicators of an organization’s architectural commitment. According to FBI  officials, including the chief architect, EA management has not been an  agency priority, and thus has not received needed attention and resources.
Without effective EA management structures, processes, and controls, it is  unlikely that the bureau will be able to produce a complete and enforceable  enterprise architecture and thus be able to implement modernized systems  in a way that minimizes overlap and duplication and maximizes integration  and mission support.

	Conclusions

The bureau’s ongoing and planned system modernization efforts are at risk  of not being defined and implemented in a way that best supports  institutional mission needs and operations. Effectively mitigating this risk  will require swift development and use of a modernization blueprint, or  enterprise architecture; up to now, the FBI has not adequately  demonstrated a commitment to developing such an architecture. In  reversing this pattern, it is important that the architecture development and  use be made an agency priority, and that it be managed in a way that  satisfies the practices embodied in our architecture management maturity  framework. To do less will continue to expose the bureau’s system  modernization efforts, and ultimately the effectiveness and efficiency of its  mission performance, to unnecessary risk.

	Recommendations

We recommend that the FBI Director immediately designate EA  development, maintenance, and implementation as an agency priority and  manage it as such. To this end, we recommend that the Director ensure that  appropriate steps are taken to develop, maintain, and implement an EA in a  manner consistent with our architecture management framework. This  includes first laying an effective EA management foundation by  (1) ensuring that all business partners are represented on the architecture  governance board; (2) adopting an architecture development methodology  and automated tool; (3) establishing an EA program office that is  accountable for developing the EA; (4) tasking the program office with  developing a management plan that specifies how and when the EA is to be  developed and issued; (5) ensuring that the management plan provides for  the bureau’s “as-is” and “to-be” environments, as well as a sequencing plan  for transitioning from the “as-is” to the “to-be”; (6) ensuring that the  management plan also describes the enterprise in terms of business, data,  applications, and technology; (7) ensuring that the plan also calls for  describing the security related to the business, data, and technology;  (8) ensuring that the plan establishes metrics for measuring EA progress,  quality, compliance, and return on investment; and (9) allocating the  necessary funding and personnel to EA activities.
Next, we recommend that the Director ensure that steps to develop the  architecture products include (1) establishing a written and approved  policy for EA development; (2) placing EA products under configuration  management; (3) ensuring that EA products describe the enterprise’s  business, as well as the data, applications, and technology that support it;  (4) ensuring that EA products describe the “as-is” environment, the “to-be”  environment, and a sequencing plan; (5) ensuring that business,  performance, data, application, and technology descriptions address  security; and (6) ensuring that progress against EA plans is measured and  reported.
In addition, we recommend that the Director ensure that steps to complete  architecture products include (1) establishing a written and approved  policy for EA maintenance; (2) ensuring that EA products and management  processes undergo independent verification and validation; (3) ensuring  that EA products describe the enterprise’s business and the data,  application, and technology that supports it; (4) ensuring that EA products  describe the “as-is” environment, the “to-be” environment, and a  sequencing plan; (5) ensuring that business, performance, data,  application, and technology descriptions address security; (6) ensuring that  the Chief Information Officer approves the EA; (7) ensuring that the  steering committee and/or the investment review board has approved the  current version of the EA; and (8) measuring and reporting on the quality of  EA products.
Further, we recommend that the Director ensure that steps taken to use the  EA to manage modernization efforts include (1) establishing a written and  approved policy for IT investment compliance with EA, (2) establishing  processes to formally manage EA changes, (3) ensuring that EA is an  integral component of IT investment management processes, (4) ensuring  that EA products are periodically updated, (5) ensuring that IT investments  comply with the EA, (6) obtaining Director approval of the current EA  version, (7) measuring and reporting EA return on investment, and  (8) measuring and reporting on EA compliance.
Finally, we recommend that the Director ensure that the bureau develops  and implements an agency strategy for mitigating the risks associated with  continued investment in modernized systems before it has an EA and  controls for implementing it.

	Agency Comments

We discussed our findings with the FBI’s Chief Architect and later  transmitted a draft of this report to the bureau on August 22, 2003, for its  review and comment, requesting that any comments be provided by  September 18, 2003. However, none were provided in time to be included in  this printed report.
We are sending copies of this report to the Chairman and Vice Chairman of  the Senate Select Committee on Intelligence and the Ranking Minority  Member of the House Permanent Select Committee on Intelligence. We are  also sending copies to the Attorney General; the Director, FBI; the Director,  Office of Management and Budget; and other interested parties. In addition,  the report will also be available without charge on GAO’s Web site at  http://www.gao.gov.
Should you have any questions about matters discussed in this report,  please contact me at (202) 512-3439 or by E-mail at hiter@gao.gov. Key  contributors to this report are listed in appendix III.

Scope and Methodology

To evaluate whether Federal Bureau of Investigation (FBI) has a  modernization blueprint, commonly called an enterprise architecture (EA),  to guide and constrain its modernization efforts, we requested that the  bureau provide us with all of its EA products. We also interviewed FBI  officials, including the chief architect, to verify the status and plans for  developing bureau EA products, the causes for why none had been  completed to date, and the effects of proceeding with modernization  initiatives without an EA.
To assess whether the FBI was effectively managing its architecture  activities, we compared bureau EA management practices to our EA  management maturity framework. This framework is based on A Practical  Guide to Federal Enterprise Architecture, published by the federal Chief  Information Officers (CIO) Council. To do this, we first reviewed bureau  EA plans and products, and we interviewed FBI officials to verify and  clarify our understanding of bureau EA efforts. Next, we compared the  information that we had collected against our EA management maturity  framework practices to determine the extent to which the FBI was  employing such effective management practices. In addition, we  interviewed FBI’s chief architect and other bureau officials to determine,  among other things, the cause of differences between what is specified in  the framework and the condition at the FBI. We also reviewed past FBI  information technology (IT) management studies and Department of  Justice Inspector General reports, to understand the state of FBI  management practices, including their strengths and weaknesses,  underlying causes for improvements, and open recommendations. Further,  we interviewed FBI division officials to understand the extent of their  participation in the bureau’s architecture efforts. Finally, to verify our  findings and validate our assessment, we discussed with the chief architect  our analysis of the state of FBI’s EA practices against our maturity  framework.
We performed our work at FBI headquarters in Washington, D.C., from  September 2002 until August 2003, in accordance with generally accepted  government auditing standards.

Assessment of FBI’s Enterprise Architecture (EA) Efforts against GAO’s EA Management Maturity Framework

Agency is aware of EA.
The FBI has acknowledged the need for an EA.
Adequate resources exist.
The FBI has allocated four architects and  approximately $1 million annually for the  development, implementation, and maintenance of  its EA.
Committee or group representing the  enterprise is responsible for  directing, overseeing, or approving  EA.
The FBI has established the architecture  governance board to direct, oversee, and approve  the EA. However, not all FBI components are  represented on the board.
Program office responsible for EA  development and maintenance  exists.
The FBI does not have a program office  responsible for the development, maintenance, or  implementation of its EA.
Chief architect exists.
The FBI has designated a chief architect.
EA is being developed using a  framework, methodology, and an  automated tool.
The FBI plans to use the Federal Enterprise  Architecture Framework. However, FBI officials  reported that they are not using a methodology or  automated tool.
EA plans call for describing “as-is”  environment, “to-be” environment,  and sequencing plan.
No EA plans exist.
EA plans call for describing the  enterprise in terms of business,  data, applications, and technology.
No plans exist.
EA plans call for business,  performance, data, application, and  technology descriptions to address  security.
No plans exist.
EA plans call for developing metrics  for measuring EA progress, quality,  compliance, and return on  investment.
No plans exist.
Written/approved policy exists for EA  development.
The FBI does not have a written and approved  policy for EA development.
EA products are under configuration  management.
The FBI has not developed its EA products; thus  no products are under configuration management.
EA products describe or will  describe the enterprise’s business  and the data, applications, and  technology that support it.
The FBI plans to describe its enterprise’s business  and the data, applications, and technology that  support it. However, no completion date has been  established.
EA products describe or will  describe the “as-is” environment, the  “to-be” environment, and a  sequencing plan.
The FBI plans to describe its “as-is” and “to-be”  environments, as well as a sequencing plan.  However, no completion date has been  established.
Business, performance, data,  application, and technology address  or will address security.
No plans exist.
Progress against EA plans is  measured and reported.
No plans exist.
Written/approved policy exists for EA  maintenance.
According to FBI officials, there is no written and  approved policy for EA maintenance.
EA products and management  processes undergo independent  verification and validation.
The FBI has not developed EA products, and  management processes do not undergo  independent verification and validation.
EA products describe the  enterprise’s business and the data,  applications, and technology that  support it.
The FBI has not developed these products.
EA products describe the “as-is”  environment, the “to-be”  environment, and a transitioning  plan.
The FBI has not developed these products.
Business, performance, data,  application, and technology  descriptions address security.
No plans exist.
Organization chief information officer  has approved EA.
There is no approved version of the FBI’s EA.
Committee or group representing the  enterprise or the investment review  board has approved current version  of EA.
The FBI has not developed an EA.
Quality of EA products is measured  and reported.
The FBI has not developed an EA.
Written/approved policy exists for IT  investment compliance with EA.
The FBI has no written and approved policy  addressing IT investment compliance with EA.
Process exists to formally manage  EA change.
No management plans exist.
EA is integral component of IT  investment management process.
The FBI has not developed an EA.
EA products are periodically  updated.
The FBI has not developed an EA.
IT investments comply with EA.
The FBI has not developed an EA.
Organization head has approved  current version of EA.
The organization head has not approved the EA.
Return on EA investment is  measured and reported.
The FBI does not have an EA to determine return  on investment.
Compliance with EA is measured  and reported.
The FBI does not have an EA to measure and  report compliance.

GAO Contact and Staff Acknowledgments

	GAO Contact

	Acknowledgments

In addition to the individual named above, key contributors to this report  included Nabajyoti Barkakati, Katherine I. Chu-Hickman, Barbara Collier,  Michael Fruitman, David Hinchman, Mary Beth McClanahan, Paula Moore,  and Megan Secrest.

	GAO’s Mission

The General Accounting Office, the audit, evaluation and investigative arm of  Congress, exists to support Congress in meeting its constitutional responsibilities  and to help improve the performance and accountability of the federal government  for the American people. GAO examines the use of public funds; evaluates federal  programs and policies; and provides analyses, recommendations, and other  assistance to help Congress make informed oversight, policy, and funding  decisions. GAO’s commitment to good government is reflected in its core values of  accountability, integrity, and reliability.

	Obtaining Copies of GAO Reports and Testimony

The fastest and easiest way to obtain copies of GAO documents at no cost is  through the Internet. GAO’s Web site (www.gao.gov) contains abstracts and full- text files of current reports and testimony and an expanding archive of older  products. The Web site features a search engine to help you locate documents  using key words and phrases. You can print these documents in their entirety,  including charts and other graphics.
Each day, GAO issues a list of newly released reports, testimony, and  correspondence. GAO posts this list, known as “Today’s Reports,” on its Web site  daily. The list contains links to the full-text document files. To have GAO e-mail this  list to you every afternoon, go to www.gao.gov and select “Subscribe to   e-mail alerts” under the “Order GAO Products” heading.

		Order by Mail or Phone

	To Report Fraud, Waste, and Abuse in Federal Programs

	Public Affairs

Summary:
Why GAO Did This Study

The Federal Bureau of Investigation (FBI) is in the process of modernizing its information technology (IT) systems. Replacing much of its 1980s-based technology with modern system applications and a robust technical infrastructure, this modernization is intended to enable the FBI to take an integrated approach--coordinated agencywide--to performing its critical missions, such as federal crime investigation and terrorism prevention. GAO was requested to conduct a series of reviews of the FBI's modernization management. The objective of this first review was to determine whether the FBI has an enterprise architecture to guide and constrain modernization investments.

What GAO Found

About 2 years into its ongoing systems modernization efforts, the FBI does not yet have an enterprise architecture. An enterprise architecture is an organizational blueprint that defines--in logical or business terms and in technology terms--how an organization operates today, intends to operate in the future, and intends to invest in technology to transition to this future state. GAO's research has shown that attempting to modernize an IT environment without a well-defined and enforceable enterprise architecture risks, among other things, building systems that do not effectively and efficiently support mission operations and performance. The FBI acknowledges the need for an enterprise architecture and has committed to developing one by the fall of 2003. However, it currently lacks the means for effectively reaching this end. For example, while the bureau did recently designate a chief architect and select an architecture framework to use, it does not yet have an agency architecture policy, an architecture program management plan, or an architecture development methodology, all of which are necessary components of effective architecture management. Given the state of the FBI's enterprise architecture management efforts, the bureau is at Stage 1 of GAO's enterprise architecture management maturity framework. Organizations at Stage 1 are characterized by architecture efforts that are ad hoc and unstructured, lack institutional leadership and direction, and do not provide the management foundation necessary for successful architecture development and use as a tool for informed IT investment decision making. A key for an organization to advance beyond this stage is to treat architecture development, maintenance, and implementation as an institutional management priority, which the FBI has yet to do. To do less will expose the bureau's ongoing and planned modernization efforts to unnecessary risk.