An enterprise architecture is a key tool for effectively and efficiently  overcoming the kinds of transformational challenges that face DHS. Within the Management directorate is the DHS Office of the Chief  Information Officer (CIO), which has primary responsibility for addressing  departmentwide information technology integration issues. The CIO released an initial  version of the enterprise architecture in September 2003 and plans to issue  the next version in September 2004. Other frameworks also exist. Our experience with federal agencies has  shown that investing in IT without defining these investments in the  context of an architecture often results in systems that are duplicative, not  well integrated, and unnecessarily costly to maintain and interface. In our view, such descriptions of the agency enterprise  architecture/FEA relationship are not clear, in part because definitions  of such key terms as alignment, mapping, and consistency are not  apparent in the FEA. Initial Version of DHS’s Architecture Provides a Partial Foundation upon Which to Build, but Not a Sufficient Basis to Guide Investment Decisions

The initial version of DHS’s enterprise architecture is missing many of the  key elements of a well-defined architecture. Instead, the architecture is largely the result of combining the architectures  and ongoing IT investments that several of the 22 agencies brought with  them when the department was formed. According to DHS senior  architecture officials, including the chief architect, Version 1.0 was  developed in this manner because it pre-dated completion of the  department’s first strategic plan, only had limited staff assigned to it, and  needed to be done in only 4 months in order to meet OMB’s deadline for  submitting the department’s fiscal year 2004 IT budget. More specifically, a well-defined “To Be”  architecture should provide, among other things, a description of  the enterprise’s business strategy, including its desired future concept of  operations, its strategic goals and objectives, and the strategic direction  to be followed to achieve the desired future state;  future business processes, functions, and activities that will be  performed to support the organization’s mission, including the entities  that will perform them and the locations where they will be performed;  a logical database model that identifies the primary data categories and  their relationships, which are needed to support business processes and  to guide the creation of the physical databases where information will  be stored;  the systems to be acquired or developed and their relative importance in  supporting the business operations;  the enterprise application systems and system components and their   the policies, procedures, processes, and tools for selecting, controlling,  and evaluating application systems;  the technical standards to be implemented and their anticipated life   the physical infrastructure (e.g., hardware and software) that will be  needed to support the business systems;  common policies and procedures for developing infrastructure systems  throughout their life cycles;  security and information assurance-related terms;  the organizations that will be accountable for implementing security and  the tools to be used to secure and protect systems and data;  a list of the protection mechanisms (e.g., firewalls and intrusion  detection software) that will be implemented to secure the department’s  assets; and  the metrics that will be used to evaluate the effectiveness of mission  operations and supporting system performance in achieving mission  goals and objectives. We have previously reported that OMB’s expected relationship between the  FEA and agency enterprise architectures has not been clearly articulated,  in part because OMB has not defined key terms, such as architectural  alignment. Semantic alignment  means that the department’s architecture and the FEA reference models  use similar terms and/or definitions that can be mapped to one another. DHS  recognizes this and has produced an initial architecture in a short time with  limited resources and is working on its next version. Nevertheless, the  department is in the midst of transforming itself and investing hundreds of  millions of dollars in supporting systems without a well-defined  architecture to effectively guide and constrain these activities. It is also important for DHS to ensure that its  architecture includes the necessary content. Key contributors to this report are  acknowledged in appendix V.

Objectives, Scope, and Methodology

Our objectives were to determine whether the initial version of the  Department of Homeland Security’s (DHS) enterprise architecture  (1) provides a foundation upon which to build and (2) is aligned with the  Federal Enterprise Architecture (FEA). Element satisfied? Element satisfied? However, it does list technologies, products, and  standards for EAI.
Why GAO Did This Study

The Department of Homeland Security (DHS) is attempting to integrate 22 federal agencies, each specializing in one or more interrelated aspects of homeland security. An enterprise architecture is a key tool for effectively and efficiently accomplishing this. In September 2003, DHS issued an initial version of its architecture. Since 2002, the Office of Management and Budget (OMB) has issued various components of the Federal Enterprise Architecture (FEA), which is intended to be, among other things, a framework for informing the content of agencies' enterprise architectures. GAO was asked to determine whether the initial version of DHS's architecture (1) provides a foundation upon which to build and (2) is aligned with the FEA.

What GAO Found

DHS's initial enterprise architecture provides a partial foundation upon which to build future versions. However, it is missing, either in part or in total, all of the key elements expected to be found in a well-defined architecture, such as descriptions of business processes, information flows among these processes, and security rules associated with these information flows, to name just a few. Moreover, the key elements that are at least partially present in the initial version were not derived in a manner consistent with best practices for architecture development. Instead, they are based on assumptions about a DHS or national corporate business strategy and, according to DHS, are largely the products of combining the existing architectures of several of the department's predecessor agencies, along with their respective portfolios of system investment projects. DHS officials agreed that their initial version is lacking key elements, and they stated that this version represents what could be done in the absence of a strategic plan, with limited resources, and in the 4 months that were available to meet an OMB deadline for submitting the department's fiscal year 2004 information technology budget request. In addition, they stated that the next version of the architecture, which is to be issued in September 2004, would have much more content. As a result, DHS does not yet have the necessary architectural blueprint to effectively guide and constrain its ongoing business transformation efforts and the hundreds of millions of dollars that it is investing in supporting information technology assets. Without this, DHS runs the risk that its efforts and investments will not be well integrated, will be duplicative, will be unnecessarily costly to maintain and interface, and will not optimize overall mission performance. The department's initial enterprise architecture can be traced semantically with the FEA, which means that similar terms and/or definitions of terms can be found in the respective architectures. However, traceability in terms of architecture structures and functions is not apparent. Because of this, it is not clear whether the substance and intent of the respective architectures are in fact aligned, meaning that, if both were implemented, they would produce similar outcomes. This is due at least in part to the fact that OMB has yet to clearly define what it expects the relationship between agencies' enterprise architectures and the FEA to be, including what it means by architectural alignment.