Homeland Security: Efforts Under Way to Develop Enterprise Architecture, but Much Work Remains
Published: 2004-08-06T00:00:00

Fast Facts:

Highlights:
section_title: Why GAO Did This Study
paragraphs: 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.
section_title: What GAO Found
paragraphs: 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.

section_title: Letter
paragraphs: Following September 11, 2001, homeland security emerged as a more  prominent federal mission. To improve the federal government’s ability to  fulfill this mission, Congress passed and the President signed the  Homeland Security Act of 2002. Among other things, this act created the  Department of Homeland Security (DHS) by merging 22 separate agencies,  each specializing in one or more interrelated and interdependent aspects of  homeland security, such as intelligence analysis, law enforcement, border  security, transportation security, biological research, critical infrastructure  protection, and disaster recovery. The effective interaction, integration,  and synergy of these agencies are critical to homeland security mission  performance.
Because of the importance of the department’s mission operations and the  enormity of the challenges associated with creating the federal  government’s third largest department, we designated the implementation  and transformation of DHS as a high-risk area in January 2003. We also  reported in June 2002 that DHS needed to, among other things, develop and  implement an enterprise architecture to aid in optimizing departmentwide  operations and its supporting systems environments. As we have repeatedly reported, a well-defined enterprise architecture is essential to  an organization’s ability to transform its operations and supporting systems  in a way that eliminates duplication, promotes interoperability, reduces  costs, and optimizes mission performance.
Recognizing the pivotal role that an architecture will play in successfully  merging the diverse operating and systems environments that the  department inherited, DHS issued an initial version in September 2003. The  department also stated its intention to improve on this initial version and  issue a second version in September 2004. You requested that we determine  whether the initial version of the architecture (1) provides a foundation  upon which to build and (2) is aligned with the Office of Management and  Budget’s (OMB) Federal Enterprise Architecture (FEA). We performed our  work in accordance with generally accepted government auditing  standards. Details on our objectives, scope, and methodology are in  appendix I.
subsections: section_title: Background
paragraphs: The creation of DHS in November 2002 represents the most significant  transformation of the U.S. government since 1947, when the various  branches of the U.S. Armed Forces were combined into the Department of  Defense (DOD) to better coordinate the nation’s defense against military  threats. In January 2003, we cited numerous management and leadership  challenges facing DHS as it attempted to merge 22 separate federal  agencies, and we designated the department’s transformation as high risk.  Shortly thereafter, the department stated that it faced significant  transformational challenges, such as (1) developing new business  processes, (2) unifying multiple organizational structures, (3) integrating  multiple border-security and interior-enforcement functions, (4) integrating  information technology (application systems and infrastructures), and  (5) improving information sharing. The magnitude of these challenges is  enormous. For example, DHS reports that it has redundancies in such  business processes as human resources management, financial  management, and procurement—including about 300 application systems  that support inconsistent and duplicative processes. DHS also reports that  it plans to invest about $4.1 billion during fiscal year 2004 in IT for both  new and existing systems, to more effectively and efficiently support its  mission operations and business processes.
An enterprise architecture is a key tool for effectively and efficiently  overcoming the kinds of transformational challenges that face DHS. In  short, it is a business and technology blueprint that links an organization’s  strategic plan to the program and supporting system implementations that  are needed to systematically move the organization from how it operates  today to how it intends to operate tomorrow. As we have repeatedly  reported, without an enterprise architecture to guide and constrain IT  investments, it is unlikely that an organization will be able to transform its  business processes and modernize its supporting systems in a way that  minimizes overlap and duplication, and thus costs, and maximizes  interoperability and mission performance.
subsections: section_title: DHS’s Mission and Organizational Structure: A Brief Description
paragraphs: According to DHS’s strategic plan, its mission is to lead a unified national  effort to secure America by preventing and deterring terrorist attacks and  protecting against and responding to threats and hazards to the nation.  DHS also is to ensure safe and secure borders, welcome lawful immigrants  and visitors, and promote the free flow of commerce. As part of its  responsibilities, the department must also coordinate and facilitate the  sharing of information both among its component agencies and with other  federal agencies, state and local governments, the private sector, and other  entities.
As illustrated in DHS’s organizational structure (see fig. 1), to accomplish  its mission it has five under secretaries with responsibility over the  directorates or offices for management, science and technology,  information analysis and infrastructure protection, border and  transportation security, and emergency preparedness and response. Each  DHS directorate is responsible for leading its specific homeland security  mission area and coordinating relevant efforts with other federal agencies  and state and local governments. The department is also composed of  other component organizations, such as the U.S. Coast Guard and the U.S.  Secret Service. Table 1 describes the primary roles of these five  directorates and several of these component organizations.
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. According to  the CIO, this office’s responsibilities include developing and facilitating the  implementation of such integration enablers as the department’s IT  strategic plan and its enterprise architecture. The CIO released an initial  version of the enterprise architecture in September 2003 and plans to issue  the next version in September 2004. According to the CIO, updated releases  of the architecture will be issued on an annual basis. To provide the  necessary leadership, direction, and management to create the  architecture, the CIO established various entities and assigned specific  responsibilities to each. Table 2 describes the key architecture entities and  individuals involved in developing and maintaining the architecture, along  with their respective responsibilities.
section_title: Enterprise Architecture: A Brief Description
paragraphs: Effective use of enterprise architectures is a trademark of successful public  and private organizations. For a decade, we have promoted the use of  architectures to guide and constrain systems modernization, recognizing  them as a crucial means to a challenging goal: establishing agency  operational structures that are optimally defined in both business and  technological environments. Congress, OMB, and the federal CIO Council  have also recognized the importance of an architecture-centric approach to  modernization. The Clinger-Cohen Act of 1996 mandates that an agency’s  CIO develop, maintain, and facilitate the implementation of an IT  architecture. This should provide the means for managing the integration  of business processes and supporting systems. Further, the E-Government  Act of 2002 requires OMB to oversee the development of enterprise  architectures within and across agencies.
Generally speaking, an enterprise architecture connects an organization’s  strategic plan with program and system solution implementations by  providing the fundamental information details needed to guide and  constrain implementable investments in a consistent, coordinated, and  integrated fashion. An enterprise architecture provides a clear and  comprehensive picture of an entity, whether it is an organization (e.g.,  federal department) or a functional or mission area that cuts across more  than one organization (e.g., homeland security). This picture consists of  snapshots of both the enterprise’s current or “As Is” operational and  technological environment and its target or “To Be” environment, as well as  a capital investment road map for transitioning from the current to the  target environment. These snapshots further consist of “views,” which are  basically one or more architecture products that provide conceptual or  logical representations of the enterprise.
The suite of products and their content that form a given entity’s enterprise  architecture are largely governed by the framework used to develop the  architecture. Since the 1980s, various frameworks have emerged and been  applied. For example, John Zachman developed a structure or framework  for defining and capturing an architecture. This framework provides for  six windows from which to view the enterprise, which Zachman calls  “perspectives” on how a given entity operates: the perspectives of (1) the  strategic planner, (2) the system user, (3) the system designer, (4) the  system developer, (5) the subcontractor, and (6) the system itself. Zachman  also proposed six abstractions or models that are associated with each of  these perspectives: these models cover (1) how the entity operates,  (2) what the entity uses to operate, (3) where the entity operates, (4) who  operates the entity, (5) when entity operations occur, and (6) why the entity  operates.
Other frameworks also exist. Each of these frameworks use somewhat  unique nomenclatures to define themselves. However, they all generally  provide for defining an enterprise’s operations in both (1) logical terms,  such as interrelated business processes and business rules, information  needs and flows, and work locations and users and (2) technical terms,  such as hardware, software, data, communications, and security attributes  and performance standards. The frameworks also provide for defining  these perspectives for both the enterprise’s current or “As Is” environment  and its target or “To Be” environment, as well as a transition plan for  moving from the “As Is” to the “To Be” environment.
Our research and experience show that for major program investments,  such as the development of an enterprise architecture, successful  organizations approach product development in an incremental fashion,  meaning that they initially develop a foundational product that is expanded  and extended through a series of follow-on products that add more  capability and value. In doing so, these organizations can effectively  mitigate the enormous risk associated with trying to deliver a large and  complex product that requires the execution of many activities over an  extended period of time as a single monolithic product. In effect, this  incremental approach permits a large undertaking to be broken into a  series of smaller projects, or incremental versions, that can be better  controlled to provide reasonable assurance that expectations are met.
The importance of developing, implementing, and maintaining an  enterprise architecture is a basic tenet of both organizational  transformation and IT management. Managed properly, an enterprise  architecture can clarify and help to 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 management  controls—such as portfolio-based capital planning and investment control  practices—architectures can greatly increase the chances that an  organization’s operational and IT environments will be configured to  optimize mission performance. 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.
section_title: Our Prior Work Has Emphasized the Need for a DHS Enterprise Architecture
paragraphs: For the last 2 years, we have promoted the development and use of a  homeland security enterprise architecture. In June 2002, we testified on  the need to define the homeland security mission and the information,  technologies, and approaches necessary to perform this mission in a way  that is divorced from organizational parochialism and cultural differences.  At that time, we stressed that a particularly critical function of a homeland  security architecture would be to establish processes and information/data  protocols and standards that could facilitate information collection and  permit sharing.
In January 2003, when we designated DHS’s transformation as high risk, we  again emphasized the need to develop and implement an enterprise  architecture. In May 2003 testimony, we reiterated this need, stating that,  for DHS to be successful in addressing threats of domestic terrorism, it  would need to establish effective systems and processes to facilitate  information sharing among and between government entities and the  private sector. We stated that to accomplish this the department would  need to develop and implement an enterprise architecture.
In August 2003, we reported that DHS had begun to develop an enterprise  architecture and that it planned to use this architecture to assist its efforts  to integrate and share information between federal agencies and among  federal agencies, state and city governments, and the private sector. In  November 2003, we reported on DHS’s progress in establishing key  enterprise architecture management capabilities, as described in our  architecture management maturity framework. This framework  associates specific architecture management capabilities with five  hierarchical stages of management maturity, starting with creating  architecture awareness and followed by building the architecture  management foundation, developing the architecture, completing the  architecture, culminating in leveraging the architecture to manage change  (see table 3 for a more detailed description of the stages).
Based on information provided by DHS, we reported that the department  had established an architecture management foundation and was  developing architecture products, and we rated the department to be at  stage 3 of our maturity framework. In particular, we reported that it had  (1) established a program office responsible for developing and  maintaining the architecture; (2) assigned a chief architect to oversee the  program; (3) established plans for developing metrics for measuring  progress, quality, compliance, and return on investment; and (4) placed the  architecture products under configuration management. According to our  framework, effective architecture management is generally not achieved  until an enterprise has a completed and approved architecture that is being  effectively maintained and is being used to leverage organizational change  and support investment decision making. An enterprise with these  characteristics would need to satisfy all of the requirements associated  with stage 3 of our framework, and many of the requirements of stages 4  and 5.
In addition, we reported in May 2004 that DHS was in the process of  defining its strategic IT management framework for, among other things,  integrating its current and future systems and aligning them with the  department’s strategic goals and mission. We also reported that a key  component of this initiative was the development of the department’s  enterprise architecture. Accordingly, we recommended that, until the  framework was completed, the department limit its spending on IT  investments to cost-effective efforts that  take advantage of near-term, relatively small, low-risk opportunities to  leverage technology in satisfying a compelling homeland security need;  support operations and maintenance of existing systems that are critical  to DHS’s mission;  involve deploying an already developed and fully tested system; or  support establishment of a DHS strategic IT management framework,  including IT strategic planning, enterprise architecture, and investment  management.
section_title: Prior DHS Testimony Has Recognized the Importance of an Enterprise Architecture for Departmental Transformation
paragraphs: In May 2003, the department’s CIO testified that development of the  homeland security enterprise architecture had begun in July 2002 and that  the department expected to complete the “As Is” and “To Be” architectures  by June and August 2003, respectively. The CIO also stated that the  department would develop a migration or transition strategy and plan by  fall 2003 in order to achieve its target environment. Moreover, the CIO  testified that DHS had coordinated its architecture development efforts  with other key federal agencies (e.g., the Departments of Justice, Energy,  and Defense), the intelligence community, and the National Association of  State and Local CIOs.
In October 2003, DHS’s CIO testified that the department had completed  the first version of its target architecture in September 2003 and was  beginning to implement the objectives of its transition strategy. The CIO  stated that the department had designed and delivered a comprehensive  and immediately useful business-driven target architecture in under 4  months and that the architecture was enabling DHS to make IT investment  decisions.
section_title: OMB’s Federal Enterprise Architecture: A Brief Description
paragraphs: On February 6, 2002, OMB established the FEA Program Management  Office and charged it with responsibility for developing the FEA. According  to OMB, the FEA is intended to provide a governmentwide framework to  guide and constrain federal agencies’ enterprise architectures and IT  investments and is now being used by agencies to help develop their  budgets and to set strategic goals. The FEA is composed of five reference  models: Performance, Business, Service, Data, and Technical. To date,  versions of all but the data reference model have been released for use by  the agencies. More information on each reference model follows.
Performance reference model. The performance reference model is  intended to describe a set of performance measures for major IT initiatives  and their contribution to program performance. According to OMB, this  model will help agencies produce enhanced performance information;  improve the alignment and better articulate the contribution of inputs, such  as technology, to outputs and outcomes; and identify improvement  opportunities that span traditional organizational boundaries. Version 1.0  of the model was released in September 2003.
Business reference model. The business reference model serves as the  foundation for the FEA. It is intended to describe the federal government’s  businesses, independent of the agencies that perform them. 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.
Thirty-nine lines of business, which together are composed of 153  subfunctions, make up the four business areas. Examples of lines of  business under the “services for citizens” business area are homeland  security, law enforcement, and economic development. Each of these lines  of business includes a number of subfunctions. For example, for the  homeland security line of business, a subfunction is border and  transportation security; for law enforcement, a subfunction is citizen  protection; and for economic development, a subfunction is financial  sector oversight.
Version 1.0 of the business reference model was released to agencies in  July 2002, and OMB reports that it was used in the fiscal year 2004 budget  process. According to OMB, Version 1.0 helped to reveal that many federal  agencies were involved in each line of business and that agencies’ proposed  IT investments for fiscal year 2004 offered multibillion-dollar consolidation  opportunities. In June 2003, OMB released Version 2.0 which, according to  OMB, addresses comments from agencies and reflects changes to align the  model as closely as possible with other governmentwide management  frameworks (e.g., budget function codes) and improvement initiatives  (e.g., the President’s Budget Performance Integration Initiative) without  compromising its intended purpose. OMB expects agencies to use the  model, as part of their capital planning and investment control processes,  to help identify opportunities to consolidate IT investments across the  federal government.
Service component reference model. The service component reference  model is intended to identify and classify IT service (i.e., application)  components that support federal agencies and promote the reuse of  components across agencies. According to OMB, this model is intended to  provide the foundation for the reuse of applications, application  capabilities, components (defined as “a self-contained business process or  service with predetermined functionality that may be exposed through a  business or technology interface”), and business services, and is organized  as a hierarchy beginning with seven service domains, as shown in table 4.
These service domains are decomposed into 29 service types, which  together are further broken down into 168 components. For example, the  customer services domain is made up of 3 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 online help and online tutorials.
Version 1.0 of the service component reference model was released in June  2003. According to OMB, the model is a business-driven, functional  framework that classifies service components with respect to how they  support business and/or performance objectives. Further, the model is  structured across horizontal service areas that, independent of the  business functions, is intended to provide a leverageable foundation for the  reuse of applications, application capabilities, components, and business  services.
Data and information reference model. The data and information  reference model is intended to describe the types of data and information  that support program and business-line operations and the relationships  among these types. The model is intended to help describe the types of  interactions and information exchanges that occur between the  government and its customers. OMB officials told us that the release of  Version 1.0 is to occur imminently.
Technical reference model. The technical reference model is intended to  describe 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 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 examples of 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,  followed in August 2003 by Version 1.1, which reflected minor revisions  that were based, in part, on agencies’ comments. Version 1.1 was used  during the 2005 budget process. The model is intended to help agencies  define their target technical architectures.
In May 2004, we testified that, through the FEA, OMB is attempting to  provide federal agencies and other decision makers with a common frame  of reference or taxonomy for informing agencies’ individual enterprise  architecture efforts and their planned and ongoing investment activities  and to do so in a way that, among other things, identifies opportunities for  avoiding duplication of effort and launching initiatives to establish and  implement common, reusable, and interoperable solutions across agency  boundaries. We testified that we supported these goals. However, we also  recognized that development and use of the FEA is but the first step in a  multistep process to realize the promise of interagency solutions. In  addition, because the FEA is still maturing both in content and in use, we  raised a number of questions that we believed OMB needed to address in  order to maximize understanding about the tool and thus facilitate its  advancement. Specifically, we asked the following:  Should the FEA be described as an enterprise architecture? As we  discussed earlier, 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 it is more akin to a point-in-time framework or  classification scheme for federal government operations. 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 their  systems.
Is the expected relationship between agencies’ enterprise architectures  and the FEA clearly articulated? Among other things, the FEA is to  inform agencies’ 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 services component  reference model and the technical reference model will enable each  agency to categorize its IT investments according to common  definitions.
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. As with any endeavor, the more ambiguity and  uncertainty there is in requirements and expectations, the greater the  use of assumptions; the more assumptions that are made, the higher the  risk of 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 our research into 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 refers  to as a “security profile” to be added to the FEA. However, OMB could  not comment on the profile’s status or on development plans for it,  beyond stating that the CIO Council is taking the lead in developing the  profile.
section_title: Initial Version of DHS’s Architecture Provides a Partial Foundation upon Which to Build, but Not a Sufficient Basis to Guide Investment Decisions
paragraphs: The initial version of DHS’s enterprise architecture is missing many of the  key elements of a well-defined architecture. Further, those elements that  are in the initial version are not based on the department’s strategic  business plan, as architecture development best practices advocate.  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. They also stated  that this initial version was intended to mature the department’s approach  and methodology for developing the next version of the architecture, rather  than to develop a version of the architecture that could be acted on and  implemented. As a result, even though Version 1.0 provides a partial  foundation upon which to build a well-defined architecture, DHS has spent  and continues to spend large sums of money on IT investments without  having such an architecture to effectively guide and constrain these  investments. Our experience with federal agencies has shown that this  often results in systems that are duplicative, are not well integrated, are  unnecessarily costly to maintain and interface, and do not effectively  optimize mission performance.
subsections: section_title: Initial Version of Architecture Is Missing Important Content
paragraphs: As previously discussed, the various frameworks used to develop  architectures consistently provide for describing a given enterprise in both  logical and technical terms, and for doing so for both the enterprise’s  current or “As Is” environment and its target or “To Be” environment; these  frameworks also provide for defining a capital investment sequencing plan  to transition from the “As Is” to the “To Be” environment. However, the  frameworks do not prescribe the degree to which the component parts  should be described to be considered correct, complete, understandable,  and usable—essential attributes of any architecture. This is because the  depth and detail of the descriptive content depend on what the architecture  is to be used for (i.e., its intended purpose).
DHS’s stated intention is to use an architecture as the basis for  departmentwide and national operational transformation and supporting  systems modernization and evolution. The CIO stated that the department  was already using the architecture to help guide IT investment decisions.  This purpose necessitates that the architecture products provide  considerable depth and detail, as well as logical and rational structuring  and internal linkages. More specifically, it means that these architecture  products should contain sufficient scope and detail so that, for example,  (1) duplicative business operations and systems are eliminated;  (2) business operations are standardized and integrated and supporting  systems are interoperable; (3) use of enterprisewide services is maximized;  and (4) related shared solutions are aligned, like OMB’s e-government  initiatives. Moreover, this scope and detail should be accomplished in a  way that (1) provides flexibility in adapting to changes in the enterprise’s  internal and external environments; (2) facilitates the architecture’s  usefulness and comprehension from varying perspectives, users, or  stakeholders; and (3) provides for properly sequencing investments to  recognize, for example, the investments’ respective dependencies and  relative business value.
While the initial version of the architecture does provide some content that  can be used to further develop it, it does not contain sufficient breadth and  depth of departmentwide operational and technical requirements to  effectively guide and constrain departmentwide business transformation  and systems modernization efforts. More specifically, we found that DHS’s  “To Be” architecture products (Version 1.0) do not satisfy 14 of 34 (41  percent) key elements and only partially satisfy the remaining 20 (59  percent), and that its transition plan only partially satisfies 3 of 5 elements  (60 percent) and does not satisfy the remaining 2 (40 percent) (see fig. 2.).  This means that while Version 1.0 does provide some of the foundational  content that can be used to extend and expand the architecture, it does not  yet provide an adequately defined frame of reference to effectively inform  business transformation and system acquisition and implementation  decision making. Our specific analysis of the “To Be” and transition plan  products follows. “To Be” Architecture: According to relevant guidance, a “To Be”  architecture should capture the vision of future business operations and  supporting technology. That is, it should describe the desired capabilities,  structures (e.g., entities, activities, and roles), and relationships among  these structures at a specified time frame in the future. It should also  describe, for example, future business processes, information needs, and  supporting infrastructure characteristics, and it should be fiscally and  technologically achievable. 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.
Architectures that include these elements can provide the necessary frame  of reference to enable the engineering of business solutions (processes and  systems) in a manner that optimally supports departmentwide goals and  objectives, such as information sharing.
Version 1.0 of the department’s “To Be” architecture provides some of the  descriptive content mentioned above. For example, it contains (1) a high- level business strategy that includes a vision statement and a list of projects  that may become future technology solutions; (2) a list of systems to be  acquired or developed; (3) a description of the enterprise application  systems and system components; (4) the technical standards to be  implemented; (5) a description of the physical infrastructure (e.g.,  hardware and software) that will be needed to support the business  systems; (6) definitions of security and information assurance-related  terms; (7) a list of protection mechanisms, such as firewalls; and (8) high- level performance metrics.
However, the business strategy does not define the desired future concept  of operations, the business-specific objectives to be achieved, and the  strategic direction to be followed. Such content is important because the  “To Be” architecture must be based on and driven by business needs. In  contrast to this, the DHS “To Be” architecture is primarily focused on how  to employ technology to improve current mission operations and services,  instead of on identifying and addressing needed business changes through  the use of technology. In addition, the systems listed are not described in  terms of their relative importance to achieving the department’s vision  based on business value and technical performance, and the application  systems and system components are not linked to the specific business  processes they will support. Further, the technical standards are  incomplete (e.g., do not specify standards that support narrowband  wireless access) and do not include the anticipated life cycle of each  standard. The physical infrastructure description is too high level (e.g., it  does not define networks and their configurations or relate the technology  platforms to specific applications and business functions). The  architecture also does not define certain security and information  assurance-related terms (e.g., security services) and, in some instances, it  defines other terms (e.g., authentication and availability) differently than  do the department’s homeland security partners. For example, DHS’s  definitions of authentication, availability, confidentiality, and integrity  differ from DOD’s definitions of these terms. In addition, the list of  protection mechanisms is neither complete, nor does it describe all of the  mechanisms shown and the interrelationships among them.
Other key elements that are not included are (1) a description of future  business processes, functions, and activities that will be performed to  support the organization’s mission, including the entities or people that will  perform them and the locations where they will be performed; (2) a logical  database model; (3) the policies, procedures, processes, and tools for  selecting, controlling, and evaluating application systems; (4) common  policies and procedures for developing infrastructure systems throughout  their life cycles; (5) the organizations that will be accountable for  implementing security and the tools to be used to secure and protect  systems and data; and (6) explicit metrics for the department’s primary  (e.g., identifying threats and vulnerabilities and facilitating the flow of  people and goods) and mission-support (e.g., human resources and budget  and finance) business areas. Detailed results of our analysis are provided in  appendix II.
Transition Plan: According to relevant guidance and best practices, the  transition plan should provide a temporal road map for moving from the  “As Is” to the “To Be” environment. An important step in the development  of a well-defined transition plan is a gap analysis—a comparison of the “As  Is” and “To Be” architectures to identify differences. Other important steps  include analyses of technology opportunities and marketplace trends, as  well as assessments of fiscal and budgetary realities and institutional  acquisition and development capabilities. Using such analyses and  assessments, options are explored and decisions are made regarding which  legacy systems to retain, modify, or retire and which new systems to  introduce on a tactical (temporary) basis or to pursue as strategic  solutions. Accordingly, transition plans identify legacy, migration, and new  systems and sequence them to show, for example, the phasing out and  termination of systems and capabilities and the timing of the introduction  of new systems and capabilities, and they do so in light of resource  constraints such as budget, people, acquisition/development process  maturity, and associated time frames.
Version 1.0 of DHS’s transition plan generally does not possess any of these  attributes. Specifically, it does not (1) include a gap analysis identifying the  needed changes to current business processes and systems; (2) identify the  legacy systems that will not become part of the “To Be” architecture or the  time frames for phasing them out; (3) show a time-based strategy for  replacing legacy systems, including identifying intermediate (i.e.,  migration) systems that may be temporarily needed; or (4) define the  resources (e.g., funding and staff) needed to transition to the target  environment. The result is that DHS does not have a meaningful and  reliable basis for managing the disposition of its legacy systems or for  sequencing the introduction of modernized business operations and  supporting systems. Detailed results of our analysis are in appendix III.
A DHS contractor responsible for evaluating the quality of Version 1.0  reported weaknesses that are similar to ones that we identified. For  example, the contractor reported the following:  The “To Be” architecture did not address the reality that the  department’s systems would be a federated combination of legacy and  new systems for many years. Rather, it assumes that its systems will be  transformed into an ideal future state in the near term.
The “To Be” architecture did not consistently address topics at the same  level of detail, and it contained inconsistencies (i.e., some topics were  addressed in more detail than others).
The architecture did not sufficiently address security (i.e., network,  data, physical, and information).
DHS’s senior enterprise architecture officials, including the chief architect,  agreed with the results of our analysis and stated that considerable work  remained to adequately address all of the key architectural elements.  According to the CIO and these officials, this initial version was prepared in  4 months, with limited resources (i.e., three DHS staff and minimal  contractor support), based on the information available at that time.  Further, it was prepared primarily to meet OMB’s fiscal year 2004 IT budget  submission deadline and to help educate DHS’s senior executives about the  importance of this architecture in the department’s overall transformation  effort. Senior architecture officials also stated that a transition plan was  not intended to be part of the scope of Version 1.0, and that the  department’s initial focus was on maturing its ability to execute an  approach and methodology for developing the next version of the  architecture.
Notwithstanding these reasons, constraints, and intentions, the fact  remains that Version 1.0 is missing important content and, without this  content, the department—as well as homeland security stakeholders in  other federal agencies, state and local governments, and the private  sector—will not have the sufficiently detailed, authoritative frame of  reference that is needed to provide a common understanding of future  homeland security operational, business, and supporting technology needs.  Such a frame of reference is important to effectively guide and constrain  the transformation of mission operations, business functions, and  associated IT investments. Without it, DHS and other homeland security  stakeholders will be challenged in their ability to effectively leverage  technology to affect the kind of logical and systematic institutional change  needed to optimize enterprisewide mission performance.
section_title: Content of Initial Architecture Is Based on Strategic Business Assumptions and Existing Agencies’ Architectures Rather Than Departmental Strategic Vision
paragraphs: The various architecture frameworks and architecture management best  practices recognize the need to define the “To Be” environment using a top- down, business-driven approach in which the content of the organization’s  strategic plan (mission, goals, objectives, scope, and outcomes) drives  operational processes, functions, activities, and associated information  needs, which in turn drive system application and services and supporting  technology standards. The architecture development methodology being  employed by DHS also calls for this top-down, mission- and business- driven approach, which engages mission and business area subject matter  experts. It specifically states that an architecture should be based on a  functional business model that reflects the nature of the operational  mission, the business strategy, and the information to be used to  accomplish them.
DHS did not follow this approach in developing Version 1.0 of its  architecture, primarily because the department did not issue a strategic  plan until February 2004. Specifically, the department released its initial  architecture in September 2003, approximately 5 months before it issued  its strategic plan. Without an explicit strategic direction to inform the  architecture, the architecture’s business representation was derived from  the existing architectures and the ongoing and planned IT investments of  some of its component agencies (i.e., Immigration and Naturalization  Service, Customs and Border Protection, Coast Guard, and the Federal  Emergency Management Agency). As a result, Version 1.0 did not contain a  departmentwide and national corporate business strategy that described  such things as (1) the desired future state of its mission operations and  business activities, (2) the specific goals and objectives to be strategically  achieved, and (3) the strategic direction to be followed by the department  to realize the desired future state. Rather, the architecture’s strategic  operational and business content is basically the sum of its component  agencies’ business strategy parts. Moreover, although the department is  using generally accepted architecture development techniques, the  architecture artifacts that have been derived using these techniques (i.e.,  the value chain analysis, CURE matrix, conceptual data model, and  sequencing diagram) do not provide a consistent view of the scope of the  department’s mission. In some instances, the vision focuses internally on  departmental activities only, while in other instances, it focuses on  homeland security at a national level (i.e., addresses other homeland  security stakeholders, such as other federal agencies and state and local  government). The architecture’s business strategy also does not identify  corporate priorities and constraints to be considered when making  departmentwide and national decisions about future homeland security  activities. The DHS contractor responsible for evaluating the quality of  Version 1.0 made similar comments concerning the architecture’s business  strategy. Specifically, the contractor reported that the scope of the  architecture was unclear, at times being internally focused on only the  department, while at other times being more broadly focused on national  homeland security. Further, the contractor reported that the business  strategy did not include all DHS mission activities.
According to the chief architect, the fiscal year 2004 IT budget submission  deadline did not allow the department to delay development of the  architecture until the strategic plan had been completed. A senior  architecture official also stated that this time constraint (i.e., 4-month  development period) did not allow subject matter experts (i.e., both  internal and external DHS stakeholders) to be consulted and to participate  in developing Version 1.0. According to the CIO, subject matter experts are  now participating in the department’s architecture development activities.
As stated above, having a mission- and business-driven enterprise  architecture is a fundamental principle. Until the department uses an  enterprisewide understanding of its mission operations and business as the  basis for developing its architecture, its architecture’s utility will be greatly  diminished, and it is unlikely that changes to existing operations and  systems that are based on this architecture will provide for optimization of  mission performance and satisfaction of stakeholder needs. Moreover,  because DHS did not base Version 1.0 on such an understanding, the  content of this version may prove to be invalid if future work shows that  the strategic business assumptions used to develop it were inaccurate. This  in turn would limit the value of Version 1.0 as a basis for building the next  version.
section_title: Initial Architecture Can Be Partially Traced to the Federal Enterprise Architecture, but the Extent of Alignment Is Unclear
paragraphs: OMB guidance does not explicitly require agency enterprise architectures  to align with the FEA. However, a requirement for alignment is implicit in  the OMB guidance. For example, this guidance states that agencies’ major  IT investments must align with each of the FEA’s published reference  models (business, performance, services, and technical), and that agencies’  nonmajor IT investments must align with the business reference model.  Since an agency’s enterprise architecture is to include a transition plan that  strategically sequences its planned IT investments in a way that moves the  agency from its current architectural environment to its target  environment, this means that the agency’s investments would need to align  with both the FEA and the agency enterprise architecture, which in turn  would necessitate alignment between the FEA and the agency architecture.  Aligning agencies’ architectures with the FEA is also an implied  requirement in recently released OMB guidance for its enterprise  architecture assessment tool. According to this guidance, agency  enterprise architectures are “a basic building block to support the  population of the FEA.” Further, OMB states that one of the purposes of the  FEA is to inform agency efforts to develop their agency-specific enterprise  architectures.
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. In the absence of clear definitions, we also reported that  assumptions must be made about what alignment means, and that the  greater the use of assumptions, the greater the chances of expectations  about these relationships not being met and intended outcomes not being  realized. For the purposes of this report, we have assumed that alignment  can be examined from three perspectives: functional, structural, and  semantic. Functional alignment means that the architecture and the  reference models have been decomposed to the same level of detail to  determine if the business operations, services, and technology components  are similar in nature and purpose. Structural alignment means that the  architecture and the reference models are both constructed similarly, for  example, they may share the same hierarchical construct whereby  information is grouped by common levels of detail. 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.
The FEA and Version 1.0 of DHS’s enterprise architecture are not aligned  functionally or structurally. Specifically, we could not map Version 1.0 to  the FEA from either of these perspectives because the DHS architecture is  not decomposed to the same level of detail as the reference models and  thus does not permit association of the respective functional components  and because the DHS architecture is not structured in a hierarchical  fashion as the reference models are.
However, the terms or definitions used in the business, services, and  technical components of Version 1.0 could be mapped to similar terms in  the FEA business, services, and technical reference models. The results of  this mapping are discussed below.
We mapped all 79 of the high-level activities that we found in the  business view of the DHS architecture to similar terms in the FEA  business reference model. To achieve this degree of mapping, however,  we needed to trace the 79 high-level activities to multiple levels of the  reference models, including business areas, lines of business, and  subfunctions. For example, for the DHS high-level business activity  “stockpile and deploy supplies” (defined as including managing  immunizations, as well as identification, acquisition, development,  maintenance, and distribution of other pharmaceutical and medical  supplies) we needed to go to the reference model’s subfunction level to  find “immunization management.” In addition, we were not able to map  any terms in the DHS architecture to several areas in the business  reference model that would appear relevant to DHS, such as the  business area “mode of delivery” or the line of business “defense and  national security.”
We also mapped Version 1.0’s applications/services view to the FEA  services reference model. In this case, the initial architecture contained  terms that could be associated with all of the FEA reference model’s 7  service domains, 29 service types, and 168 service components.
We also mapped terms used for technical services in the Version 1.0  technical view to the FEA technical reference model. However, this  mapping was again based on associating high-level descriptions in  Version 1.0 with lower-level descriptions in the FEA. Moreover, some  terms for technology elements in Version 1.0 could not be mapped to the  FEA technical reference model, such as “narrowband wireless and  broadband wireless.” Conversely, some technical services and standards  in the reference model that should be applicable to DHS were not  evident in Version 1.0, such as software engineering (including test  management services) and database middleware standards,  respectively. In those instances where we could not semantically  associate Version 1.0 to the FEA reference models, we found no  associated explanations. As a result, we could not determine whether  future alignment is envisioned or not.
According to the CIO and the chief architect, the steps that DHS took to  align the initial architecture with the FEA reference models represent the  most that could be done in the time available. The architect also stated that  changes would be made to the technical views of the architecture to more  closely reflect the content within the FEA’s technical reference model.  However, given that what is meant by agency architectural alignment to the  FEA is not well defined, the degree to which DHS and other agencies can  establish the intended relationship between the two is both challenging and  uncertain. This in turn will constrain OMB’s ability to meet the goals it has  set for the FEA.
section_title: Conclusions
paragraphs: Having and using an enterprise architecture that reflects the department’s  strategic operational and business needs and enables it to make informed  decisions about competing investment options is critical to DHS’s business  transformation and supporting system modernization efforts. 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. Following  this approach is a risky proposition, and the longer DHS goes without a  well-defined and enforced architecture the greater the risk. Therefore, it is  important that DHS ensure that the next version is based on a top-down,  strategic business-based approach that involves key stakeholders, as  advocated by best practices. It is also important for DHS to ensure that its  architecture includes the necessary content. Until this is done, it will be  prudent for the department to limit new system investments to those  meeting certain criteria, as we have previously recommended. To do less  puts the department at risk of investing hundreds of millions of dollars in  efforts that will not promote integration and interoperability and will not  optimize mission performance.
Further, the relationships that OMB expects between the FEA and agency  architectures, including DHS’s are not clear. Until OMB clarifies what it  means by architectural alignment, it is unlikely that the outcomes it  envisions and desires through architectural alignment will result.
section_title: Recommendations for Executive Action
paragraphs: To ensure that DHS has a well-defined architecture to guide and constrain  pressing transformation and modernization decisions, we recommend that  the Secretary of Homeland Security direct the department’s architecture  executive steering committee, in collaboration with the CIO, to (1) ensure  that the development of DHS’s enterprise architecture is based on an  approach and methodology that provides for identifying the range of  mission operations and the focus of the business strategy and involving  relevant stakeholders (external and internal) in driving the architecture’s  scope and content; and (2) develop, approve, and fund a plan for  incorporating into the architecture the content that is missing.
In addition, we are recommending 39 actions to ensure that future versions  of the architecture include (1) the six key elements governing the business  view of the “To Be” architectural content that our report identified as not  being fully satisfied, (2) the three key elements governing the performance  view of the “To Be” architectural content that our report identified as not  being fully satisfied, (3) the seven key elements governing the information  view of the “To Be” architectural content that our report identified as not  being fully satisfied, (4) the five key elements governing the  services/applications view of the “To Be” architectural content that our  report identified as not being fully satisfied, (5) the six key elements  governing the technical view of the “To Be” architectural content that our  report identified as not being fully satisfied, (6) the seven key elements  governing the security view of the “To Be” architectural content that our  report identified as not being fully satisfied, and (7) the five key elements  governing the transition plan content that our report identified as not being  fully satisfied.
In addition, to assist DHS and other agencies in developing and evolving  their respective architectures, we recommend that the Director of OMB  direct the FEA Program Management Office to clarify the expected  relationship between the FEA and federal agencies’ architectures. At a  minimum, this clarification should define key terms, such as architectural  alignment.
section_title: Agency Comments and Our Evaluation
paragraphs: In DHS’s written comments on a draft of this report, signed by the Director,  Bankcard Programs and GAO/OIG Liaison within the Office of the Chief  Financial Officer (reprinted in app. IV), the department agreed that much  work remains to develop both a target enterprise architecture and a  transition plan to support business and IT transformation, and it stated that  it would ensure that the architecture criteria that we cite in our report,  which our recommendations reference, are addressed to the extent  possible in Version 2.0 of its architecture. Notwithstanding these  statements, the department also stated that it took exception to several  aspects of our report, including our criteria and recommendations. In  particular, it stated that (1) the criteria were not realistic and assumed the  existence of a comprehensive enterprise architecture, the development of  which was inconceivable in the time available, (2) the criteria had not been  provided to the federal community and were not available when Version 1.0  of DHS’s architecture was being developed, and (3) the recommendations  did not take into consideration the department’s limited resources. DHS  stated that it had accomplished one of the most important goals of  Version 1.0, which was “positioning the department to more actively  engage with our business representatives, with a strategic plan in hand and  a greater awareness of the need for and value of an enterprise architecture  generally on the part of our senior and executive management.” DHS also  provided specific comments on our findings relative to each criterion that  we assessed Version 1.0 against. These comments fell into two general  categories: agree that content is missing but content was not intended to be  part of Version 1.0, and do not agree that content is missing (i.e., factually  incorrect).
We do not agree with the department’s comments concerning the criteria  and our recommendations. In particular, our report does not state that DHS  should have ensured that Version 1.0 of its enterprise architecture satisfied  all of the criteria that we cite. We have long held and reported the position  that enterprise architecture development should be done incrementally,  with each version of an architecture providing greater depth and detail to  an enterprisewide, business-driven foundational layer. We provide in the  report an analytical assessment of where Version 1.0 stands against a  benchmark of where it will need to be in order to be an effective blueprint  to guide and constrain major investment decisions for organizational  transformation. In doing so, we have provided the department with a road  map, grounded in explicit criteria, for incrementally developing a mission- derived blueprint.
In addition, the criteria that we used in our review and cite in our report  came from published literature on the content of enterprise architectures,  which we structured into categories consistent with federal enterprise  architecture guidance and have used in prior evaluations of other agencies’  enterprise architectures, the results of the first of which we issued in  September 2003. We shared these criteria and categories with DHS at the  time that we began our review, and we shared the results of our review  relative to each criterion with DHS enterprise architecture program and  contractor officials over a 2-day period after we completed our review. At  that time, both the DHS and the contractor officials agreed with our results.  While we acknowledge that we had yet to publish our categorization of the  criteria at the time that Version 1.0 of DHS’s architecture was being  developed, the criteria that we drew from and used were both well  established and publicly available.
In addition, we recognize in both the report and its recommendations the  point made in DHS’s comments about the initial architecture development  effort being constrained by resources. It is because of this that our  recommendations call for DHS’s architecture executive steering  committee, which is composed of those department business and  technology executives who collectively control billions of dollars in  resources, to develop, approve, and fund a plan for completing the  architecture. In our view, the resource point cited in DHS’s comments is a  departmental funding allocation and prioritization decision, rather than a  resource shortage issue.
Also, we do not question the department’s comment concerning the intent  and goal of Version 1.0, or whether its goal has been accomplished. Rather,  the purpose and scope of our work was to determine the extent to which  the initial architecture version contained the building blocks of a well- defined blueprint and to thereby identify what, if anything, remained to be  accomplished. If more needed to be done, our objective was to determine  whether the initial version provided a foundation upon which to build any  missing content. As we previously stated, development of a well-defined  enterprise architecture is by necessity incremental, and our report is  intended to provide DHS with a criteria-based road map for incrementally  accomplishing this. To avoid any misunderstanding about the need to  develop the architecture incrementally, we have added further detail on  this topic to this report.
With respect to DHS’s specific comments on each of the findings and  recommendations that acknowledged missing content, we support the  department’s statements indicating that it will address this missing content  in the next or subsequent versions of the architecture. However, we do not  agree with DHS’s comments when it stated that our findings were factually  incorrect or when it disagreed with the criteria. Our responses to DHS’s  comments for each of these areas of disagreement are provided in  appendix IV.
In their oral comments on a draft of this report, OMB’s Office of  E-Government and Information Technology and the Office of General  Counsel officials stated that OMB’s Administrator for Electronic  Government, Information and Technology had recently testified that  additional work was needed to mature the FEA. In addition, the officials  stated that OMB is committed to working to evolve the FEA and agency  enterprise architectures, and that this work will clarify many of the issues  raised in our report.
As agreed with your office, unless you publicly announce the contents of  this report earlier, we plan no further distribution until 30 days from the  report date. At that time, we will send copies of this report to the Secretary  of Homeland Security and to the Director of OMB. We will also make  copies available to others upon request. In addition, the report will be available at no charge on the GAO Web site at http://www.gao.gov. If you  have any questions on matters discussed in this report, please contact me  at (202) 512-3439 or hiter@gao.gov. Key contributors to this report are  acknowledged in appendix V.
section_title: Objectives, Scope, and Methodology
paragraphs: 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).
To address the first objective, we followed the approach that we have  previously used to evaluate the content of an agency’s enterprise  architecture. Specifically, we first segmented Version 1.0 of the  architecture into the three primary component parts of any architecture:  the “As Is,” the “To Be,” and the transition plan. We then further divided the  “As Is” and “To Be” architectures into five architectural components similar  to the Office of Management and Budget’s (OMB) architecture reference  models and defined in our enterprise architecture maturity framework:  business, information/data, services/applications, technical, and  performance; we added security as a sixth component because of its  recognized importance in the various architecture frameworks and its  relevance to the other five architectural components. Because the  department is currently investing about $4.1 billion in fiscal year 2004 for IT  systems and supporting infrastructure, we focused our evaluation on the  “To Be” architecture and the transition plan and did not analyze whether  DHS’s “As Is” architecture satisfied relevant “As Is” guidance. For each of  these six architectural components, we used the key architectural  requirements that we previously reported as necessary for a well-defined  “To Be” architecture. We also used the key architectural requirements that  we previously reported as necessary for a well-defined transition plan. We  then compared the “To Be” architecture and transition plan (Version 1.0)  against the key elements. In doing so, we used the following criteria to  determine whether the key element was fully, partially, or not satisfied.
To assess the extent to which the architecture was aligned with the FEA,  we compared the “To Be” architecture with the FEA business, services- and  technical reference models, Versions 2.0, 1.0, and 1.1, respectively. We did  not select the performance, information/data, and security models  because department officials told us that these models were not part of the  scope of their effort in developing Version 1.0. We, therefore, focused on  the business, services, and technical models and attempted to map the  architecture and FEA reference models at three levels: semantic,  functional, and structural. However, we were unable to do so from a  functional or structural standpoint because the DHS architecture was  neither decomposed to the same level of detail, nor constructed in a  hierarchical fashion like the reference models. We therefore mapped key  elements of the DHS architecture (e.g., business activities, target  applications, and services) to the reference models by identifying similar  terms and/or definitions. To augment our documentation reviews and  analyses of the architecture, we also interviewed various officials,  including the chief information officer and chief architect to determine,  among other things, these officials’ comments on our detailed analysis.
We also met with OMB officials to discuss its process for reviewing  agencies’ enterprise architectures and the results of its review of DHS’s  architecture. According to OMB officials, its review of DHS’s architecture is  still ongoing and thus we were not provided a copy of the review results.
We conducted our work at DHS headquarters in Washington, D.C. We  performed our work from November 2003 to May 2004 in accordance with  generally accepted government auditing standards.
section_title: Detailed Results of GAO’s Analyses of Version 1.0 of DHS’s “To Be” Architecture
paragraphs: Element satisfied?
A business assessment that includes the enterprise’s  purpose, scope (e.g., organizations, business areas,  and internal and external stakeholders’ concerns),  limitations or assumptions, and methods.
The architecture does not contain a business  assessment or gap analysis results.
A gap analysis that describes the target outcomes and  shortfalls, including strategic business issues,  conclusions reached as a result of the analysis (e.g.,  missing capabilities), causal information, and rationales.
However, the architecture recognizes the need to  perform a business assessment and project- specific gap analyses. It also identifies possible  concerns (e.g., inefficiencies in business function  and technology) that may be addressed by the  department.
A business strategy that describes the desired future  state of the business, the specific objectives to be  achieved, and the strategic direction that will be followed  by the enterprise to realize the desired future state.
The architecture does not have a business  strategy that adequately describes the desired  future state of the business, the objectives to be  achieved, and the strategic direction to be  followed.
However, the architecture does address to a  limited degree the characteristics of a business  strategy, as discussed below.
A vision statement that describes the business areas  requiring strategic attention based on the gap analysis.
The architecture does contain a vision statement;  however, this statement does not highlight  opportunities for strategic change to business  processes, nor does it present a consistent view  of the national responsibilities for homeland  security at the various levels (i.e., federal, state,  local, and international).
A description of the business priorities and constraints,  including their relationships to, at a minimum,  applicable laws and regulations, executive orders,  departmental policy, procedures, guidance, and audit  reports.
The architecture recognizes that homeland  security processes, procedures, and decisions  about IT management should comply with  applicable laws, regulations, and guidance,  particularly those associated with privacy  requirements. The architecture also specifically  mentions the National Strategy for Homeland  Security. However, the architecture does not  explicitly identify, reconcile, prioritize, or align the  applicable laws, regulations, and guidance. As a  result, business priorities and constraints are not  identified.
Element satisfied?
A description of the scope of business change that is  to occur to address identified gaps and realize the  future desired business state. The scope of change, at  a minimum, should identify expected changes to  strategic goals, customers, suppliers, services,  locations, and capabilities.
The architecture does not explicitly identify what  will be changed in the “As Is” environment. It also  does not explicitly identify key customers,  suppliers, products, services, locations, and  capabilities for homeland security at the national  level.
A description of the measurable strategic business  objectives to be met to achieve the desired change.
The architecture does not describe measurable  strategic business objectives; however, it does  contain objectives in the transition strategy that  may be used to develop strategic business  objectives.
A description of the measurable tactical business  goals to be met to achieve the strategic objectives.
The architecture does not describe measurable  tactical business goals; however, it does describe  some high-level performance measures for  several of its business areas.
A listing of opportunities to unify and simplify systems  or processes across the department, including their  relationships to solutions that align with the strategic  initiatives to be implemented to achieve strategic  objectives and tactical goals.
The architecture does not align all opportunities  for change with strategic initiatives and potential  investments. However, the architecture does  identify conceptual projects and opportunities to  address inefficiencies in systems and processes.
Common (standard and departmentwide) policies,  procedures, and business and operational rules for  consistent implementation of the architecture.
A description of key business processes and how they  support the department’s mission, including the  organizational units responsible for performing the  business processes and the locations where the  business processes will be performed. This description  should provide for the consistent alignment of  (1) applicable federal laws, regulations, and guidance;  (2) department policies, procedures, and guidance;  (3) operational activities; (4) organizational roles; and  (5) operational events and information.
A description of the operational management processes  to ensure that the department’s business transformation  effort remains compliant with the business rules for fault,  performance, security, configuration, and account  management.
X Element satisfied?
A description of the organizational approach (processes  and organizational structure) for communications and  interactions among business lines and program areas  for (1) management reporting, (2) operational functions,  and (3) architecture development and use (i.e., how to  develop the architecture description, implement the  architecture, and govern/manage the development and  implementation of the architecture).
A description of the processes for establishing,  measuring, tracking, evaluating, and predicting business  performance regarding business functions, baseline  data, and service levels.
The architecture does not describe these  processes.
However, the architecture recognizes the need  for such processes and identifies a conceptual  project and a business activity that will be used to  establish these processes.
A description of measurable business goals and  outcomes for business products and services, including  strategic and tactical objectives.
The architecture does not describe explicit  measurable business goals and outcomes for  any of the department’s primary and secondary  business areas (e.g., identify threats and  vulnerabilities; and prevent, prepare and recover  from incidents).
However, the architecture does provide a  description of customer-focused, measurable  business goals and outcomes (e.g., the average  time taken to resolve customer inquiries) for all of  the department’s primary and secondary  business areas (e.g., human resources and  budget and finance), with one exception (i.e., the  architecture does not contain customer-focused,  measurable goals and outcomes for the primary  line of business entitled “facilitate the flow of  people and goods”).
Element satisfied?
A description of measurable technical goals and  outcomes for managing technology products and  services for the “To Be” architecture that enables the  achievement of business goals and outcomes.
The architecture does not contain measurable  technical goals and outcomes for managing  technology products and services that enables  the achievement of business goals and outcomes  (e.g., identifying threats and preventing terrorist  attacks).
However, the architecture does contain  performance measures for managing technology  (e.g., percentage of data or information shared  across organizational units and time to produce,  create, and deliver products or services). The  architecture also lists conceptual projects  focused on improving technology management  performance with respect to information sharing  (e.g., infrastructure consolidation).
A description of data management policies, procedures,  processes, and tools (e.g., CURE matrix) for analyzing,  designing, building, and maintaining databases in an  enterprise architected environment.
The architecture does not describe or reference  enterprise data management policies,  procedures, or processes.
However, the architecture does contain a CURE  matrix. The utility of this CURE matrix for  planning purposes is questionable because the  relationships among business functions and  applications are ambiguous—not uniquely  identified or defined.
A description of the business and operational rules for  data standardization to ensure data consistency,  integrity, and accuracy, such as business and security  rules that govern access to, maintenance of, and use of  data.
A data dictionary, which is a repository of standard data  definitions for applications.
The architecture does not contain a data  dictionary.
However, the architecture does contain an  information dictionary that, while incomplete,  does identify some data objects (e.g., cargo,  incident, and weapon). As a result, this  information glossary could be used to facilitate  the creation of a data dictionary.
Element satisfied?
A conceptual data model that describes the  fundamental things/objects (e.g., business or tourist  visas, shipping manifests) that make up the business,  without regard for how they will be physically stored. A  conceptual data model contains the content needed to  derive facts about the business and to facilitate the  creation of business rules. It represents the  consolidated structure of business objects to be used by  business applications.
The architecture does not provide a conceptual  data model that contains the content needed to  derive facts about the business and to facilitate  the creation of business rules to build databases.  The content is at such a high level (e.g., labels  and terms) that it can be interpreted in numerous  ways.
However, the architecture does provide a high- level conceptual data model that identifies  “super-classes” or groupings of objects without  the required business context, such as (1) the  complete definitions for information categories or  classes and (2) concrete business objects. This  information can be used to build the conceptual  data model.
A logical database model that provides (1) a normalized  (i.e., nonredundant) data structure that supports  information flows and (2) the basis for developing the  schemas for designing, building, and maintaining  physical databases.
A metadatamodel that specifies the rules and  standards for representing data (e.g., data formats) and  accessing information (e.g., data protocols) according to  a documented business context that is complete,  consistent, and practical.
A description of the information flows and relationships  among organizational units, business operations, and  system elements.
X Element satisfied?
A description of the services and their relationships to  key end-user services to be provided by the application  systems.
The architecture does not specify all the end- user services to be provided by application  systems (e.g., the use of e-mail as an end-user  service for various applications), nor does it  provide a rationale for this exclusion. It also does  not specify the various relationships between the  end-user services and the entities that will  provide these services.
The architecture also contains inconsistencies in  the descriptions of the relationships between  user services and application systems, which  affect its utility. For example, in one instance, the  architecture notes that correspondence  management may involve “maintaining logs and  references to pieces of correspondence that are  of interest to the enterprise for tracking purposes  and that these pieces of correspondence may be  e-mails, paper letters, phone conversations, etc.”  In another instance, the architecture does not  recognize the use of this e-mail service for  managing correspondence.
However, the architecture does contain high-level  descriptions of the types of application systems  that will be needed (e.g., a financial management  application that can manage all financial aspects  of general accounting, budgeting, capital assets,  and investment control). It also notes that “To Be”  applications will be derived and created based on  how each user class uses data while performing  business activities.
Element satisfied?
A list of application systems (acquisition/development  and production portfolio) and their relative importance to  achieving the department’s vision, based on business  value and technical performance.
The architecture does not identify the  applications’ relative importance to the overall  vision. For example, it does not explicitly identify  and describe application systems that support  functionality across organizational boundaries  (e.g., local, state, and federal agencies). In  addition, priorities are not explicitly defined for  the target applications.
However, the architecture provides a list of the  types of candidate applications (e.g., financial,  grant, and property management) and links  these application types to business functions by  providing an application-to-function cross- reference matrix.
In addition, it identifies conceptual projects that  may provide target capabilities or applications  and it prioritizes these projects according to  scheduled completion times. For example, some  conceptual projects are placed within a category  labeled “Rationalize,” which means they are  scheduled for completion within 6 months.
A description of the policies, procedures, processes,  and tools for selecting, controlling, and evaluating  application systems to enable effective IT investment  management.
A description of the enterprise application systems and  system components and their interfaces.
The architecture does not describe applications  in terms of the business process flows that each  application will support (e.g., how to identify and  report threats and vulnerabilities), nor does the  architecture describe the business process flows.  The architecture also does not reflect how  application selection decisions can or will be  made without this information. Further, it does  not identify human/machine boundaries, inputs,  outputs, controls, and standard application  programming interfaces.
However, the architecture contains a list and  graphic depictions of the types of application  systems that would satisfy the department’s  business needs, including a brief description of  the functionality to be provided by these systems.  For example, it describes a generic “financial  management” application that could be satisfied  by many application packages or development  components.
Element satisfied?
A description of the system development life cycle  process for application development or acquisition and  the integration of the process with the architecture,  including policies, procedures, and architectural  techniques and methods for acquiring systems  throughout their life cycles. The common technical  approach should also describe the process for  integrating legacy systems with the systems to be  developed/acquired.
A list of infrastructure systems and a description of the  systems’ hardware and software infrastructure  components. The description should also reflect the  system’s relative importance to achieving the  department’s vision based on constraints, business  value, and technical performance.
The architecture does not provide a complete list  of the “To Be” infrastructure systems, nor does it  describe the functional characteristics,  capabilities, and interconnections for the  infrastructure projects listed. It also does not  reflect the systems’ relative importance to  achieving DHS’s vision. For example, the  relationship between the department’s vision for  infrastructure projects and their value in  preventing terrorist attacks has not been defined.
However, it does identify a conceptual project  (i.e., OneDHS) that may be used to consolidate  the infrastructure. It also identifies a list of  conceptual applications (e.g., a communications  management application to manage connectivity  between networks) that may provide certain  infrastructure capabilities and functions for  OneDHS. Further, it identifies associated  subprojects, such as a secure network, server  and storage consolidation, and a standard  desktop environment, and it associates them with  the business areas.
The architecture also lists several existing  infrastructure systems, such as the Department  of Defense’s (DOD) Secure Internet Protocol  Routing Network, which may be used by the  department and its homeland security partners.
The architecture outlines an approach for  establishing a framework to enable DHS to  sequence the delivery of capabilities over time  based on homeland security priorities.
A description of the policies, procedures, processes,  and tools for selecting, controlling, and evaluating  infrastructure systems to enable effective IT investment  management.
X Element satisfied?
A description of the technical reference model (TRM)  that describes the enterprise infrastructure services,  including specific details regarding the functionality and  capabilities that these services will provide to enable the  development of application systems.
The architecture does not contain a TRM that  describes all enterprise infrastructure services.  The list of technical services is likely incomplete  because the architecture does not identify all  DHS organizations and its homeland security  partners that supply and consume technical  services. For example, the architecture indicates  the use of DOD’s Secure Internet Protocol  Routing Network, which is a Global Information  Grid (GIG) enterprise service, to exchange  information among homeland security  organizations. However, it does not list the  technical services that are provided by this  network. The architecture also does not show  whether these TRM services are common or  reusable.
In addition, the architecture does not describe  the functionality and capabilities that will be  provided by the services that are identified.
However, it does contain a high-level TRM that  provides a structure and vocabulary that can be  used to describe DHS’s enterprise infrastructure  services. It also contains application principles  (e.g., there will be only one enterprise application  for each function area, to be used by all  departmental organizations) and technology  patterns (e.g., use of commercial-off-the-shelf  software for implementing relational databases)  that can be used to guide technology  development and acquisition decisions.
Element satisfied?
A description in the TRM that identifies and describes  (1) the technical standards to be implemented for each  enterprise service and (2) the anticipated life cycle of  each standard.
The architecture does not contain a complete  standards profile (i.e., it excludes technical  standards that support a number of the services  reflected in the TRM). For example, the profile  does not identify standards that support  “narrowband wireless access,” even though there  are applicable homeland security applications  that require this service (e.g., Land Mobile Radio,  Air to Ground Communications, Mobile  Operations IT). It also does not list the actual life  cycles (e.g., “sunset” dates for current products  and standards, and dates for when new  developments will use target technologies) of  many of the standards and products identified in  the architecture.
However, it does contain a list of technical  standards that the department and/or its partners  may implement.
A description of the physical IT infrastructure needed to  design and acquire systems, including the relationships  among hardware, software, and communications  devices.
The architecture does not provide a description  of the physical IT infrastructure that will be  needed to support future operations. Specifically,  it does not fully describe networks and their  topologies and configurations for the  department’s internal and/or shared spaces. For  example, the architecture does not identify the  component parts of the DHS consolidated  network. It also does not relate the technology  platforms to applications and business functions.
However, the architecture does provide a vision  for the technology environment, such as a high- level diagram that depicts information sharing  among user groups. It also identifies  telecommunications backbone options for  exchanging data, such as use of the Internet for  sensitive but unclassified data. The architecture  also identifies types of technology platforms,  including computing, storage, and  communication devices and software.
Common policies and procedures for developing  infrastructure systems throughout their life cycles,  including requirements management, design,  implementation, testing, deployment, operations, and  maintenance. These policies and procedures should  also address how the applications will be integrated,  including legacy systems.
X Element satisfied?
A description of the policies, procedures, goals,  strategies, principles, and requirements relevant to  information assurance and security and how they (the  policies, procedures, goals, strategies, and  requirements) align and integrate with other elements of  the architecture (e.g., security services).
The architecture does not describe the policies,  procedures, goals, strategies, principles, and  requirements that are relevant to information  assurance and security, nor their alignment and  integration with other architecture elements.
However, it does contain (1) a high-level diagram  that depicts a data classification schema to  facilitate information sharing (e.g., sensitive but  unclassified or top secret); (2) a security pattern  that can be used to provide capabilities to secure  and protect IT resources (e.g., confidentiality via  encryption, authorization and access control via  single sign-on, and intrusion detection and  prevention using firewalls); and (3) a security  principle that reflects the requirement for sharing  information contained within nonclassified  systems. This information could be used to  develop a strategy.
Definitions of terms related to security and information  assurance.
The architecture does not define all key terms  that are listed (e.g., “information assurance” and  “security services”). In addition, there are  discrepancies between DHS’s security terms and  others involved in homeland security, such as  DOD. For example, DOD’s definitions for  authentication, availability, confidentiality, and  integrity differ from DHS’s definitions for the  same terms.
However, the architecture does contain  definitions for some security-related terms (e.g.,  “identification and authorization” and “audit trail”).
A listing of accountable organizations and their  respective responsibilities for implementing enterprise  security services. It is important to show organizational  relationships in an operational view because they  illustrate fundamental roles (e.g., who conducts  operational activities) and management relationships  (e.g., what is the command structure or relationship to  other key players) and how these influence the  operational nodes.
A description of operational security rules that are  derived from security policies.
X Element satisfied?
A description of enterprise security infrastructure  services (e.g., identification and authentication) that will  be needed to protect the department’s assets and the  relationship of these services to protective mechanisms.
The architecture’s TRM does not explicitly  identify the security services, making it difficult to  ensure that there are no redundant services, nor  does it clearly define what constitutes a technical  security service. In addition, the architecture  identifies DOD’s Secure Internet Protocol  Routing Network, thereby implying the use of a  GIG enterprise service, but it does not reconcile  how or whether these services will be used by  DHS and other homeland security entities.
However, the architecture does provide some  guidance on security services, and it lists several  services to be used to secure and protect  resources, such as confidentiality, data integrity,  authentication, and policy enforcement.
A description of the security standards to be  implemented for each enterprise service. These  standards should be derived from security  requirements. This description should also address how  these services will align and integrate with other  elements of the architecture (e.g., security policies and  requirements).
The architecture does not contain a complete list  of standards. For example, it does not include  standards for several security services (e.g.,  network security/intrusion detection systems and  single sign-on) nor does it provide a rationale for  excluding them.
Further, the architecture does not explain how  DHS will communicate with other extended  architecture systems (e.g., DOD and Department  of State) if those systems require certain  standards to support DHS systems.
However, the architecture does contain a list of  several security standards that may be  associated with security services.
A description of the protection mechanisms (e.g.,  firewalls and intrusion detection software) that will be  implemented to secure the department’s assets,  including a description of the interrelationships among  these protection mechanisms.
The architecture does not contain a complete list  of the protection mechanisms needed, nor does  it describe all these mechanisms and the  interrelationships among them. For example,  protection mechanisms have not been identified  for monitoring and auditing activities, biometrics,  control and protection, computer forensics tools,  and computer intrusion and alarm. Moreover, the  architecture indicates that security requirements  have not been analyzed, thereby bringing into  question the validity of the protection  mechanisms identified.
However, the architecture does contain a list of  protection mechanisms, such as firewalls.
section_title: Detailed Results of GAO’s Analyses of Version 1.0 of DHS’s Transition Plan
paragraphs: Element satisfied?
Analysis of the gaps between the baseline and  the target architecture for business processes,  information/data, and services/application  systems to define missing and needed  capabilities.
A high-level strategyfor implementing the  enterprise architecture.
The architecture does not have specific milestones  for any actual projects that will deploy systems.
However, the architecture does identify specific time- phased milestones for conceptual projects. For  example, it notes that projects categorized as “Quick  Hits” will be completed within 6 months, projects to  consolidate duplicate systems within less than 2  years, and projects that optimize systems after 2  years.
The architecture does not contain explicit metrics  that can be implemented or assessed, but it  recognizes the need for such metrics.
However, the architecture does contain high-level  metrics, such as “the percent of data/information  shared across organizational units” that may be  used to establish detailed metrics.
Financial and nonfinancial resources needed to   A listing of the legacy systems that will not be   A description of the training strategy/approach  that will be implemented to address the changes  made to the business operations (processes  and systems) to promote operational efficiency  and effectiveness. This plan should also  address any changes to existing policies and  procedures that affect day-to-day operations, as  well as resource needs (staffing and funding).
Element satisfied?
A list of the systems to be developed, acquired,  or modified to achieve business needs and a  description of the relationship between the  system and the business need(s).
A strategy for employing enterprise application  integration (EAI) plans, methods, and tools to, for  example, provide for efficiently reusing  applications that already exist, concurrent with  adding new applications and databases.
The architecture does not contain a strategy for  employing EAI plans, methods, and tools, nor does it  describe how EAI will be used to integrate legacy  and future systems.
However, it does list technologies, products, and  standards for EAI. It also contains a vision for a  service-oriented architecture that may be  developed into an EAI strategy.
A technical (systems, infrastructure, and data)  migration plan that shows  the transition from legacy to replacement  systems, including explicit sunset dates and  intermediate systems that may be temporarily  needed to sustain existing functionality during  the transition period.    an analysis of system interdependencies,  including the level of effort required to  implement related systems in a sequenced  portfolio of projects that includes milestones,  time lines, costs, and capabilities.   a cost estimate for the initial phase(s) of the  transition and a high-level cost projection for the  transition to the target architecture.
A strategy that describes the architecture’s  governance and control structure and the  integrated procedures, processes, and criteria  (e.g., investment management and security) to  be followed to ensure that the department’s  business transformation effort remains  compliant with the architecture.
The architecture does not include an architecture  governance and control structure and the integrated  procedures, processes, and criteria to be followed.
However, the architecture recognizes the need for a  governance structure and contains a high-level  discussion of governance that focuses on identifying  the most critical governance issues and challenges,  making general recommendations for dealing with  these, and establishing the context in which  appropriate managers, process owners, and subject  matter experts will develop process details.
section_title: Comments from the Department of Homeland Security
paragraphs: The following are GAO’s comments on the Department of Homeland  Security’s (DHS) letter dated July 23, 2004.
subsections: section_title: GAO Comments
paragraphs: 1. See the “Agency Comments and Our Evaluation” section of this report. 2. We agree that Version 1.0 included a high-level (or overview) business  model that offered some descriptive information on weaknesses, such  as potential areas of inefficiencies or overlaps in current departmental  business functions and technology. However, the underlying business  assessment that would form the basis for a clear statement of the  enterprise’s purpose, scope, limitations, assumptions, and methods for  successful business transformation was not present, and DHS provided  no evidence that such an assessment had been performed. For  example, for the areas that the business model overview identified as  potential areas of inefficiency or overlap, the architecture did not  provide the supporting analysis. The architecture also did not provide a  time frame for completing such an assessment or state that one would  be performed. Further, when we concluded our analysis and shared our  findings with senior DHS architecture officials and supporting  contractor personnel, they agreed with our finding. 3. We acknowledge the department’s comment that the business strategy  and vision statement were not within the scope of the initial  architecture description. However, we note that this comment is  inconsistent with DHS’s intent to describe the top two rows of the  Zachman framework, because these rows include this information.  Moreover, as stated in our report, best practices require that the  architecture be based on the business strategy and states that to do  otherwise negatively affects the architecture’s utility and makes it  unlikely that changes to existing operations and systems will provide  for optimum mission performance and satisfaction of stakeholders’  needs. In addition, while we do not question that the business strategy  and vision statement are included in DHS’s strategic plan, we did not  evaluate this plan because it was issued 5 months after the approval of  Version 1.0. Further, when we concluded our analysis and shared our  findings with senior DHS architecture officials and supporting  contractor personnel, they agreed with our findings. 4. As stated in the report, we do not question the department’s intent for  Version 1.0 of the architecture or whether these goals have been  achieved. However, our analysis shows that important architecture  artifacts that would be expected to be included in this version and that  are associated with the top two rows of the Zachman framework were  not included in the architecture description. 5. We acknowledge the department’s comment that Version 1.0 of the  architecture did not contain measurable strategic business objectives  or tactical business goals, as evidenced by our finding that this  information was missing. In addition, while we do not question that this  information is included in DHS’s strategic plan, we would note that we  did not evaluate this plan because it was issued 5 months after the  approval of Version 1.0. With respect to the governance strategy and  plan, the former outlined the steps to be taken to develop such a  strategy, and the latter was not contained within Version 1.0, nor was it  provided separately. Further, as previously noted, we do not question  the intent of Version 1.0. Further, when we concluded our analysis and  shared our findings with senior DHS architecture officials and  supporting contractor personnel, they agreed with our findings. 6. We disagree. While we acknowledge that there are high-level business  functions and activities in the business model, the model did not define  business processes. Business process descriptions have a definitive  beginning and end and reflect the interrelationships among business  functions and activities. The functions and activities described in  Version 1.0 had not been decomposed to a sufficient level of  operational detail to describe routine tasks (e.g., develop mitigation  strategies to minimize the impact of the threat). Further, when we  concluded our analysis and shared our findings with architecture  officials and supporting contractor personnel, they agreed with the  criteria and with our findings. 7. Version 1.0 of the architecture did not include a communications plan,  nor was such a plan provided separately. However, we do agree that  effective management reporting will depend on DHS’s ability to collect  the right information for the architecture program. 8. The organizational chart referred to in this comment was not provided  to GAO. 9. We disagree. While we acknowledge that the architecture contains a  high-level or abstract conceptual data model, we found that the model  lacked the information for the business owner’s view of data and for the  creation of a conceptual data model that can be used to develop the  logical database model as required by the Zachman framework, which  DHS has acknowledged that it is following to develop its architecture.  Specifically, this would require that the conceptual data model  (1) include concrete business objects, (2) enable facts about the  business to be derived, and (3) facilitate the development and  validation of business rules. Further, when we concluded our analysis  and shared our findings with senior DHS architecture officials and  supporting contractor personnel, they agreed with the criteria and our  findings. 10. The focus of our review was the content of Version 1.0 of the  architecture. We did not evaluate the “OneDHS” initiative as part of this  effort because it was identified in the architecture as a conceptual  project. 11. We disagree. While we acknowledge that the architecture indicated the  need to perform project-specific gap analyses, these analyses were not  included in Version 1.0, and DHS did not provide any evidence that such  analyses had been performed. In addition, the department did not  provide a time frame for completing them. Further, when we concluded  our analysis and shared our findings with senior DHS architecture  officials and supporting contractor personnel, they agreed with our  findings. 12. We disagree. While we acknowledge that conceptual projects were  linked with proposed IT investments (i.e., exhibit 300s), the  architecture did not show the correlation among the projects and the  potential investments. To show this correlation, DHS would have  needed to reflect the extent to which the identified business need— which should be based on a gap analysis—would be addressed by the  proposed investment, and this explanation would be documented  within the architecture. However, the architecture did not contain this  information or a time frame for when it would be provided. The  architecture also did not include information on the approval status of  these proposed investments. Further, when we concluded our analysis  and shared our findings with senior DHS architecture officials and  supporting contractor personnel, they agreed with our findings. 13. We disagree. Version 1.0 of the DHS architecture does not provide  sufficient information to differentiate between existing and new  systems. In addition, the architecture did not include an analysis that  identified existing systems that would be terminated. Further, when we  concluded our analysis and shared our findings with senior DHS  architecture officials and supporting contractor personnel, they agreed  with our findings. 14. We disagree. The architecture does not contain detailed training  approaches, strategies, or plans. Instead, the architecture contains  high-level briefings that refer to planned activities to determine the  needs for training based on anticipated changes. These needs, once  identified, may be used to develop a business-specific plan for change  management and training. Further, when we concluded our analysis  and shared our findings with senior DHS architecture officials and  supporting contractor personnel, they agreed with our findings. 15. We disagree. While we acknowledge that the architecture listed the  names of both existing systems and several systems under  development, it did not identify which of these systems would be  developed, modified, acquired, and/or used as intermediate systems  until the target system has been deployed to meet specific future  business needs. Further, when we concluded our analysis and shared  our findings with senior DHS architecture officials and supporting  contractor personnel, they agreed with our findings. 16. We disagree. We acknowledge that the architecture included a  sequencing diagram that graphically associated the components and  the conceptual projects. However, the architecture did not provide  either an explanation of the graphically depicted relationships or an  analysis of the interdependencies. DHS also did not provide evidence  that such an analysis had been performed. Further, when we concluded  our analysis and shared our findings with senior DHS architecture  officials and supporting contractor personnel, they agreed with our  findings.
section_title: GAO Contact and Staff Acknowledgments
subsections: section_title: GAO Contact
section_title: Staff Acknowledgments
paragraphs: Staff who made key contributions to this report were Joseph Cruz, Joanne  Fiorino, Anh Le, Randolph Tekeley, and William Wadsworth.
section_title: GAO’s Mission
paragraphs: The Government Accountability 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.
section_title: Obtaining Copies of GAO Reports and Testimony
paragraphs: The fastest and easiest way to obtain copies of GAO documents at no cost  is through GAO’s Web site (www.gao.gov). Each weekday, GAO posts  newly released reports, testimony, and correspondence on its Web site. To  have GAO e-mail you a list of newly posted products every afternoon, go to  www.gao.gov and select “Subscribe to Updates.”
subsections: section_title: Order by Mail or Phone
section_title: To Report Fraud, Waste, and Abuse in Federal Programs
section_title: Congressional Relations
section_title: Public Affairs