Information Technology: INS Needs to Better Manage the Development of Its
Enterprise Architecture (Letter Report, 08/01/2000, GAO/AIMD-00-212).
GAO reviewed the Immigration and Naturalization Service's (INS)
development of an enterprise architecture focusing on the: (1) status of
INS' efforts and; (2) effectiveness of INS' structures and processes for
managing this development effort.
GAO noted that: (1) INS recognizes that it does not have an enterprise
architecture and has taken some limited steps to develop one; (2)
however, it has considerable work left to accomplish before it will have
a complete, and thus useful, enterprise architecture; (3) moreover, its
approach to managing the development of its architecture lacks
fundamental controls; (4) specifically, INS' Office of Information
Resources Management (OIRM), which is the organization responsible for
managing INS' information technology (IT) functions and assets, has, in
isolation from INS business owners, put together a bottom-up description
of INS' IT environment and it has mapped its software applications to
INS' three major business areas; (5) this is a reasonable start to
describing INS' architectural environment; (6) however, important steps
still need to be accomplished, such as linking the systems environment
description to a decomposed view of INS' business areas, including each
area's component business functions and subfunctions, and information
needs and flows among functions and subfunctions; (7) doing this with
any degree of reliability, however, requires business owners to validate
the resultant linkages; (8) also, INS has not begun developing either a
target architecture or a plan for sequencing between its current
architecture and a target architecture; (9) in lieu of the target
architecture, OIRM is developing what it calls an "initial" target
architecture that, according to the architecture team leader, is a
2-year plan for correcting known system-level problems; (10) this plan
will basically describe near-term system maintenance efforts and will
not provide a definition of the business and systems environments needed
to optimize INS' mission performance; (11) INS' limited steps to date to
develop an enterprise architecture are due to the absence of certain
fundamental management structures and processes associated with
successful architecture development; (12) INS has focused on the
technology layers of enterprise architecture, rather than on an agency
wide effort that includes participation by INS business owners; (13)
INS' architecture development efforts are not being managed as a formal
program; (14) also, these efforts do not include performance measures
and progress reporting requirements to ensure that the effort is
progressing satisfactorily; and (15) without these management controls,
it is unlikely that INS will produce a complete and useful enterprise
architecture.
--------------------------- Indexing Terms -----------------------------
REPORTNUM: AIMD-00-212
TITLE: Information Technology: INS Needs to Better Manage the
Development of Its Enterprise Architecture
DATE: 08/01/2000
SUBJECT: Systems design
Information resources management
Systems development life cycle
ADP procurement
Information technology
Strategic information systems planning
IDENTIFIER: DOJ Information Technology Architecture
INS Computer Linked Application Information Management
System
******************************************************************
** This file contains an ASCII representation of the text of a **
** GAO Testimony. **
** **
** No attempt has been made to display graphic images, although **
** figure captions are reproduced. Tables are included, but **
** may not resemble those in the printed version. **
** **
** Please see the PDF (Portable Document Format) file, when **
** available, for a complete electronic file of the printed **
** document's contents. **
** **
******************************************************************
GAO/AIMD-00-212
Accounting and Information
Management Division
B-285590
August 1, 2000
The Honorable Janet Reno
The Attorney General
Dear Madam Attorney General:
Effectively and efficiently investing in new and existing information
systems requires, among other things, an institutional systems blueprint
that defines in both business and technology terms the organization's
current and target operating environments and provides a road map for moving
between the two. This institutional systems blueprint, commonly called an
enterprise architecture, is a recognized hallmark of successful public and
private sector organizations. For this reason, Congress and the Office of
Management and Budget (OMB) require that federal agencies establish
enterprise architectures.1
The Immigration and Naturalization Service (INS), which invests hundreds of
millions of dollars each year in information technology (IT), recognizes the
value of and need for an enterprise architecture and has recently begun to
develop one. Because of the importance of this architecture to INS' ability
to effectively and efficiently invest in IT, we reviewed (1) the status of
INS' efforts to develop an enterprise architecture and (2) the effectiveness
of INS' structures and processes for managing this development effort. The
scope of our review did not extend to INS' efforts to implement its
enterprise architecture because this issue is part of a separate review we
have underway to review INS' information technology investment management
processes. We performed our review at INS headquarters in Washington, D.C.,
from December 1999 through May 2000 in accordance with generally accepted
government auditing standards. Details of our scope and methodology are
contained in appendix I.
We requested comments on a draft of this report from you or your designee.
INS provided written comments that are discussed in the "Agency Comments and
Our Evaluation" section and are reprinted in appendix II.
INS recognizes that it does not have an enterprise architecture and has
taken some limited steps to develop one. However, it has considerable work
left to accomplish before it will have a complete, and thus useful,
enterprise architecture. Moreover, its current approach to managing the
development of its architecture lacks fundamental controls.
Specifically, INS' Office of Information Resources Management (OIRM), which
is the organization responsible for managing INS' IT functions and assets,
has, in isolation from INS business owners, put together a bottom-up
description of INS' current IT environment (e.g., hardware and system
software computing platforms, data structures and schemas, software
applications), and it has mapped its software applications to INS' three
major business areas. This is a reasonable start to describing INS' current
architectural environment. However, important steps still need to be
accomplished, such as linking the systems environment description to a
decomposed view of INS' business areas, including each area's component
business functions and subfunctions, and information needs and flows among
functions and subfunctions. Doing this with any degree of reliability,
however, requires business owners to validate the resultant linkages.
Also, INS has not begun developing either a target architecture or a plan
for sequencing between its current architecture and a target architecture.
In lieu of the target architecture, OIRM is developing what it calls an
"initial" target architecture that, according to the architecture team
leader, is a
2-year plan for correcting known system-level problems. However, such an
approach does not satisfy federal and private sector guidance on the origin,
content, and purpose of a target architecture. Rather, this plan will
basically describe near-term system maintenance efforts and will not provide
a definition of the business and systems environments needed to optimize
INS' mission performance.
INS' limited steps to date to develop an enterprise architecture are due to
the absence of certain fundamental management structures and processes
associated with successful architecture development. In particular, INS'
efforts have been solely an OIRM endeavor, rather than a corporate (i.e.,
agencywide) effort that includes participation by INS business owners. As a
result, INS has focused on the technology layers of the enterprise
architecture (e.g., hardware and system software computing platforms, data
structures and schemas, software applications). This focus is not consistent
with federal and private sector architecture guidance, which advocates that
the target architecture definition process be top-down, beginning with the
institution's mission and a business concept of operations and continuing
with the definition of supporting business functions, processes, and
information needs and flows, and then using the target business environment
to define a target system environment (software, hardware, network, data and
security standards, characteristics, and protocols). Equally important, INS'
architecture development efforts are not being managed as a formal program,
including meaningful plans that provide a detailed breakdown of the work and
associated schedules and resource needs. Also, these efforts do not include
performance measures and progress reporting requirements to ensure that the
effort is progressing satisfactorily.
Without these management controls, it is unlikely that INS will produce a
complete and useful enterprise architecture. Moreover, until INS has such an
architecture, it will be unable to fully ensure that the hundreds of
millions of dollars it spends each year on new and existing information
systems will optimally support mission needs.
The mission of the INS, an agency of the Department of Justice, is to
administer and enforce the immigration laws of the United States. To
accomplish its mission, INS is organized into three core business
areas--enforcement, immigration services, and corporate services.
Enforcement includes, among other things, conducting inspections of
travelers entering the United States as they arrive at officially designated
ports of entry, detecting and preventing the smuggling and illegal entry of
aliens between ports of entry, and identifying and removing people who have
no lawful immigration status in the United States. Immigration services,
which involve regulating permanent and temporary immigration to the United
States, include granting legal permanent residence status, nonimmigrant
status (e.g., tourists and students), and naturalization. Corporate services
include records management, financial management, personnel management, and
inventory management.
In fiscal year 1999, INS removed about 180,000 illegal aliens from the
country and granted naturalization to over 1.2 million legal immigrants.
INS' field structure consists of 3 regional offices, 4 regional service
centers, 4 administrative centers, 33 district offices, 21 Border Patrol
sectors, and more than 300 land, sea, and air ports of entry.
To carry out its responsibilities, INS relies on information systems to
assist staff in (1) receiving and processing naturalization and other
benefit applications, (2) processing immigrants and nonimmigrants entering
and leaving the United States, and (3) identifying and removing people who
have no lawful immigration status in the United States. For example,
Computer-Linked Application Information Management System (CLAIMS 4) is a
centralized case management tracking system, which offers support for a
variety of tasks associated with processing and adjudicating naturalization
benefits. In addition, INS uses its Arrival/Departure Information System
(ADIS) to store arrival and departure data for non-U.S. citizens and legal
permanent residents.
Enterprise architectures are essential for organizations to effectively and
efficiently develop new and evolve existing information systems. These
architectures systematically detail the full breadth and depth of an
organization's mission-based "modus operandi" (1) in logical terms, such as
business functions and high-level descriptions of information systems and
their interrelationships and (2) in technical terms, such as hardware,
software, data, communications, security, and performance characteristics.
If defined properly, enterprise architectures can assist in optimizing the
interdependencies and interrelationships among organizations' business
operations and the underlying information technology supporting these
operations. Our experience with federal agencies has shown that attempting
to define and build major systems without first completing an enterprise
systems architecture often results in systems that are duplicative, not well
integrated, unnecessarily costly to maintain and interface, and do not
effectively optimize mission performance.2
Congress and OMB have recognized the importance of agency enterprise
architectures. The Clinger-Cohen Act, for example, requires that agency
Chief Information Officers (CIO) develop, maintain, and facilitate the
implementation of enterprise architectures. OMB has issued guidance that,
among other things, requires agency information systems investments to be
consistent with agency architectures. OMB has also issued guidance on the
development and implementation of agency information technology
architectures.
INS has multiple efforts underway to develop and acquire new information
systems and to maintain existing ones. For example, INS plans to spend about
$11 million in fiscal year 2000 and another $10.5 million in fiscal year
2001 to continue development of its CLAIMS 4, which supports the processing
of applications and petitions for immigrant benefits and is intended to
fully replace CLAIMS 3. In addition, INS plans to spend about $10 million
and $20 million in fiscal years 2000 and 2001, respectively, to develop its
Integrated Surveillance Intelligence System (ISIS), which includes the
deployment of intelligent computer-aided detection systems, unattended
ground sensors, and fixed cameras along the northern and southern borders to
provide around-the-clock visual coverage of the border. Overall, INS plans
to spend about $300 million on information technology activities in fiscal
year 2000, including about $75 million for new development and the remaining
amount for operations and maintenance. For fiscal year 2001, INS plans to
spend about $288 million on information technology activities.
Information System Investment Processes
In August 1998, the Logistics Management Institute (LMI)3 reported that INS'
investment management processes were ineffective because OIRM
(1) did not maintain accurate cost estimates for the complete life cycle of
projects and (2) did not track and manage projects to a set of cost,
schedule, technical, and benefit baselines.4 Finally, LMI noted that while
INS' System Development Life Cycle (SDLC)5 manual provides a good model for
systems development projects, OIRM did not consistently follow it, often
bypassing key SDLC phases.
Similarly, in July 1999, the Justice Inspector General (IG) reported that
INS had no assurance that systems under development would meet performance
and functional requirements.6 Specifically, the IG reported that INS could
not (1) sufficiently track the status of its information system projects to
determine whether progress was acceptable given the amount of time and funds
already spent, (2) determine actual costs incurred for a project or reliably
estimate projected costs, (3) adequately monitor contracts, and (4) ensure
the integrity and reliability of the data used by its systems.
Recognizing the need to address these weaknesses, INS established an
Operational Assessment (OA) Team to analyze these reported weaknesses and
recommend specific actions to address them. The OA team validated the
deficiencies identified in the LMI and Justice IG reports and identified
additional ones. For example, the team found that system requirements were
not consistently collected, recorded, documented, tracked, and controlled.
To illustrate, of 105 projects reviewed by the team, fewer than 50 percent
had documented functional requirements and most of those that had been
documented were not current. The OA team also reported that INS did not have
an enterprise architecture and that efforts to develop one had been started
and never completed.
Enterprise architectures should be derived through a systematic and thorough
top-down analysis of an organization's target or "to be" operating and
systems environment--including business functions, information needs and
flows across functions, and systems characteristics (hardware, software,
data, communications, and security). Enterprise architectures should also
define in similar terms the organization's current or "as is" operations and
systems environments and specify an implementation plan for transitioning
over time from the "as is" to the "to be" environments. The analyses of the
"as is" and "to be" environments are documented in a current architecture
and a target architecture, respectively.
In 1992, we issued a framework for designing and developing enterprise
architectures.7 This framework divides the current and target architectures
into two principal components--a logical component and a technical
component. The logical component provides a high-level description of the
organization's mission and target concept of operations, the business
functions being performed and the relationships among the functions, the
information needed to perform the functions, the users and locations of the
information, the information systems, and the information flows and
interfaces among the systems. An essential element of the logical
architecture is the definition of the component interdependencies. The
technical component details specific technology and communications standards
and approaches that will be used to build the systems, including those that
address critical hardware, software, communications, data management,
security, and performance characteristics.
Other organizations, such as OMB, the National Institute of Standards and
Technology (NIST), and the CIO Council, have also issued guidance and
frameworks for developing enterprise architectures.8 Each of these models is
generally consistent with our guidance.
Architecture
INS recognizes that it needs an enterprise architecture and it has initiated
some limited efforts to develop one. In December 1999, INS' investment
resources board (IRB), which is chaired by the Deputy Commissioner and
composed of INS senior executives, approved OIRM's project for developing
the architecture. Also, OIRM has selected the CIO Council's Federal
Enterprise Architecture Framework as the template for constructing its
architecture and it has developed an automated tool, called Visual
Information Technology Architecture (VITA), to assist it in documenting and
maintaining configuration control of the architectural artifacts it
produces. OIRM has also made a reasonable start in describing the agency's
current or "as is" architecture; however, important tasks remain to fully
describe its current architecture. Also, INS has not begun to define a
target, or "to be" architecture, or an implementation plan to transition
from the current to the target environment, and it does not have plans for
doing so.
OIRM's approach to describing its current architectural environment is
basically to "reverse engineer" its existing current systems' configuration.
Restated, OIRM has inventoried the agency's current system assets and
populated its VITA tool with this information. Our review of VITA found that
INS' current architecture includes descriptions of hardware (e.g., mainframe
and client server computers); system software (e.g., operating systems and
database management systems); application development standards (e.g.,
programming languages and test tools); some, but not all security software
(e.g., access control and virus protection software for desktops, but not
for network, LAN, and client-servers); the locations of its communications
nodes; and its logical and physical data models. OIRM has also identified
its major system applications and, using VITA, linked each of the
applications to the aforementioned system assets that support the
application and to the physical data models. Relying on available
application documentation (e.g., requirements and design documents), OIRM
has associated the applications with its three high-level business
areas--enforcement, immigration services, and corporate services. INS has
also identified users and locations (e.g., regional office, border patrol
sector, and district offices), but it has not linked these to its high-level
business areas.
While INS has made a reasonable start, it has yet to complete its
description of its current architecture. For example, OIRM has not
identified the relationships among its high-level business areas and their
component business functions and its information flows and users and
locations, nor has it defined the business processes that support these
functions and identified the information needed to support the business
functions. In addition, INS has not identified its communications network
components (e.g., routers, communications switches).
OIRM has yet to begin defining its target architecture and a road map for
moving between its current and target environments and it does not have any
immediate plans for doing so. As described earlier, this target would
specify how INS wants to operate in the future to meet its mission,
including what core business processes will be performed, what these
business processes will consist of and how they would interrelate to
optimally support INS' mission, what work locations will perform the
business processes, what information will be required to optimally support
these processes and work locations, what system applications are needed to
support the business processes, and what technology standards, rules,
protocols, products, etc. will be employed to support these processes.
In lieu of developing a target architecture, INS has begun to define an
"initial" target architecture. According to the OIRM architecture team
leader, this initial target architecture is intended to address existing
deficiencies in INS' systems environment, such as system incompatibilities
that preclude data exchange. These incompatibilities are the result of INS
historically building new systems in a "stovepipe" fashion, independent of
one another and without the use of common standards and rules that an
enterprise architecture provides.
Such system incompatibilities unnecessarily increase the costs of developing
and maintaining systems since they require additional hardware and software
to provide interoperability between systems and extra user time and effort
to access data from multiple, disparate systems. For example, INS is
developing an interface designed to provide a common view of alien
status-related information. Currently, to verify an alien's status for
federal benefits, such as housing, INS personnel must individually log on to
five mainframe applications and traverse approximately 32 screens to locate
the information that they need from different databases. According to INS,
development costs alone for the interface from fiscal year 1998 through
fiscal year 2000 are about $800,000. The more significant but hidden costs,
however, are the reduced productivity of INS personnel who have to access
multiple applications and the reduced quality of service provided to the
benefit-granting agencies.
To overcome these deficiencies, and as an interim step, INS plans to build
interfaces9 between existing legacy systems to allow them to exchange data.
The architecture team leader acknowledged that this initial target does not
represent INS' target architecture. Instead, it is designed to make marginal
improvements to INS' current technology infrastructure. INS plans to
complete the initial target by the end of fiscal year 2000. In defining this
initial target architecture, the architecture team leader told us that they
are employing relevant Department of Justice guidance and standards, such as
Justice's Information Technology Architecture (ITA).10 Justice's ITA is
basically a reference document that specifies departmental architecture
principles, goals, and objectives; required information services (e.g.,
communication services and security management services); and technology
standards (e.g., information infrastructure standards and communications
infrastructure standards).
Effectively Develop Its Enterprise Architecture
Effectively developing an enterprise information systems architecture
requires formal management structures and processes to guide and manage its
development. First, because an enterprise architecture, by definition, is a
corporate representation in both business and technical terms of how the
organization operates today and in the future, it must be approached as an
enterprise endeavor with senior executive management sponsorship. This
requires establishing an entity or individual with organizational authority,
responsibility, and accountability for managing the enterprise architecture
development as an agencywide project and providing the appropriate resources
to develop it completely. Moreover, given the size and complexity of such a
project, it should be managed as a formal program, which includes developing
a detailed breakdown of the tasks and subtasks necessary to develop the
enterprise architecture, developing associated schedule and resource
estimates, and establishing progress reporting requirements and performance
measures.
Even though INS has begun to develop an enterprise architecture, it has not
yet established structures and processes that are fundamental to
successfully developing one. For example, INS is not managing its
architecture development effort as an enterprise program. To date, all of
INS' enterprise architecture development efforts have been conducted within
OIRM and have not actively involved INS' business components. Further, INS'
architecture team, which has been chartered within OIRM, does not have the
authority to secure the participation and involvement of representatives
outside of OIRM, namely business owners. In fact, until recently, business
representatives have not participated in INS' efforts to document its
current architecture.
Also, INS is not managing the enterprise architecture development effort in
a structured and disciplined manner. The architecture team has not defined a
plan for developing an enterprise architecture, including a breakdown of the
tasks and subtasks necessary to produce the enterprise architecture (i.e.,
current and target architectures, and implementation plan), and related work
schedules and resource requirements. Instead, the team only has a very
high-level plan for developing the "initial" target architecture, and this
plan is not sufficiently detailed to be useful. (Figure 1 contains INS'
initial target architecture plan). In addition, INS has not developed
progress reporting requirements and performance measures to ensure that the
development effort is progressing satisfactorily. Without effective
management structures and controls, it is unlikely that INS will be able to
produce a complete and enforceable enterprise systems architecture that
optimizes its systems business value and mission performance.
Source: Immigration and Naturalization Service.
INS officials acknowledge that INS does not have an enterprise architecture,
and OIRM, with the investment review board's approval, has initiated some
limited efforts to develop one. However, INS' limited efforts to date and
plans for the future are unlikely to result in a complete and useful
enterprise architecture. Unless INS establishes the management structures
and processes to effectively develop its enterprise architecture, it has
little assurance that it will be able to produce a complete and enforceable
enterprise architecture that optimizes its systems business value and
mission performance. Without a complete and enforceable architecture, INS
risks continuing to build and buy systems that are not well-integrated, are
incompatible, and do not effectively support mission needs.
We recommend that you direct the Commissioner of INS to designate
development of a complete enterprise architecture, to include both a current
and target architecture and a plan for moving between the two, as an
agencywide priority and manage it as such.
To accomplish this, we recommend that the Commissioner
� assign responsibility and accountability for overseeing the development of
an enterprise architecture to INS' IRB or some other corporate executive
steering committee that the Commissioner may choose to establish;
� establish an enterprise architecture program office and program manager,
reporting to this corporate oversight body, and assign the program office
and manager responsibility, authority, and accountability for developing an
enterprise architecture;
� require that the enterprise architecture be developed in accordance with
federal guidance and relevant Department of Justice policies and guidance;
� require that the program be formally managed, including having detailed
plans, performance measures, and progress reporting;
� ensure that the program office receives the resources necessary to meet
approved plans; and
� submit the complete enterprise architecture to the Department of Justice
Chief Information Officer for approval.
In its written comments on a draft of this report, INS agreed with the
findings, conclusions, and recommendations, with one exception. INS took
exception to our recommendation that the Commissioner assign responsibility
and accountability for overseeing the development of an enterprise
architecture to its IRB. In its comments, INS stated that the IRB is not
best suited to manage the enterprise architecture at INS and that it is
currently evaluating the appropriate INS structure for doing so.
An enterprise architecture, by definition, is a corporate representation in
both business and technical terms of how the organization operates today,
how it expects to operate in the future, and how the enterprise intends to
move over time between the two. As a result, it is essential that it be
approached as an enterprise endeavor with agencywide executive sponsorship
and leadership. Our intent in recommending that INS' IRB be responsible and
accountable for overseeing the development of INS' enterprise architecture
was to enable this program to benefit from agencywide direction and
oversight and that executive ownership of the architecture be established.
Currently, the only such executive body that INS has is the IRB. However, if
INS wishes to establish and charter another executive body with agencywide
representation to guide and oversee the development of its enterprise
architecture, the intent of our recommendation would still be met. We have
modified our recommendation to recognize this option.
Also, INS stated in its comments that it has progressed in developing the
technical layer of its enterprise architecture. While we acknowledge in the
report that INS has progressed in describing the technical component of its
current or "as is" architecture, INS has not yet begun developing its target
or "to be" architecture, including both the technical and business
components.
This report contains recommendations to you. The head of a federal agency is
required by U.S.C. 720 to submit a written statement on actions taken on
these recommendations. You should submit your statement to the Senate
Committee on Governmental Affairs and the House Committee on Government
Reform within 60 days of the date of this report. A written statement also
must be sent to the House and Senate Committees on Appropriations with the
agency's first request for appropriations made over 60 days after the date
of this report.
We are sending copies of this report to Senator Judd Gregg, Chairman, and
Senator Ernest F. Hollings, Ranking Minority Member, Senate Appropriations
Subcommittee on Commerce, Justice, State, the Judiciary; Senator Spencer
Abraham, Chairman, and Senator Edward M. Kennedy, Ranking Minority Member,
Senate Judiciary Subcommittee on Immigration; Representative Harold Rogers,
Chairman, and Representative Jose E. Serrano, Ranking Minority Member, House
Appropriations Subcommittee on Commerce, Justice, State, the Judiciary, and
Related Agencies; Representative Lamar Smith, Chairman, and Representative
Sheila Jackson Lee, Ranking Minority Member, House Judiciary Subcommittee on
Immigration and Claims; the Honorable Jacob J. Lew, Director, Office of
Management and Budget; and the Honorable Doris Meissner, Commissioner of the
Immigration and Naturalization Service. Copies will also be made available
to others upon request. If you have any questions, please call Randolph C.
Hite at (202) 512-6240 or Keith A. Rhodes
at (202) 512-6415 or by e-mail at [email protected] or
[email protected]. Key contributors to this assignment were
Deborah A. Davis, Bryan S. Finefrock, William Lew, and Sabine R. Paul.
Sincerely yours,
Randolph C. Hite
Associate Director, Governmentwide
and Defense Information Systems
Keith A. Rhodes
Director, Office of Computer
and Information Technology
Assessment
Objectives, Scope, and Methodology
The objectives of our review were to determine (1) the status of INS'
efforts to develop an enterprise architecture and (2) the effectiveness of
INS' structures and processes for managing this development.
To determine the status of INS' efforts to develop an enterprise
architecture, we reviewed published architectural guidance, including Office
of Management and Budget memoranda, the Chief Information Officer (CIO)
Council's Federal Enterprise Architecture Framework, and the National
Institute of Standards and Technology (NIST) architecture model to determine
key requirements for developing an enterprise architecture and compared them
to our framework.11 Each of these models is generally consistent with our
guidance.
In addition, we reviewed relevant documentation, including INS' architecture
team charter and meeting minutes, the framework and tools that INS is using
to guide its development efforts (e.g., INS' Visual Information Technology
Architecture,12 project plans and schedules for developing an enterprise
architecture, and contractor task orders that define activities in support
of INS' architecture development effort. We also interviewed INS officials
to discuss INS' plans for completing its enterprise architecture.
We then reviewed VITA and INS' data repository and enterprise data model and
analyzed the information to identify any variances with the published
architectural guidance. We also interviewed INS officials to (1) seek
clarification and explanation of VITA's contents and (2) identify instances
where the architectural artifacts in VITA did not satisfy generally accepted
requirements of an enterprise architecture.
To determine the effectiveness of INS' structures and processes for managing
its enterprise architecture development, we identified INS' management
controls and compared them to industry practices. We also compared INS'
management controls with those of federal agencies that have successfully
developed enterprise architectures, such as the Customs Service.
Specifically, we reviewed INS' architecture team charter, and project plans
and schedules for an enterprise architecture. In addition, we interviewed
INS officials to discuss instances where INS' management controls did not
comply with the generally accepted management structures and processes.
We conducted our work at INS headquarters in Washington, D.C., from December
1999 through May 2000 in accordance with generally accepted government
auditing standards.
Comments From the Immigration and Naturalization Service
1. Public Law 104-106, section 5125(b), 110 Stat., 679, 685 (1996). The act
established CIOs in all federal agencies. We support establishing such CIOs
in agencies' major components and bureaus. OMB Memorandum M-97-02, Funding
Information Systems Investments ,
October 25, 1996, and OMB Memorandum M-97-16, Information Technology
Architectures , June 18, 1997.
2. See, for example, Air Traffic Control: Complete and Enforced Architecture
Needed for FAA Systems Modernization (GAO/AIMD-97-30 , February 3, 1997) and
Customs Service Modernization: Architecture Must Be Complete and Enforced to
Effectively Build and Maintain Systems (GAO/AIMD-98-70 , May 5, 1998).
3. LMI is a private, nonprofit corporation that provides management
consulting, research, and analysis to governments and other nonprofit
organizations.
4. Reengineering Information Technology Management at the Immigration and
Naturalization Service, Logistics Management Institute, August 1998.
5. System development life cycle is a term used to refer to the phases of a
system's development from beginning to end (i.e., from perceived need for a
system extending through systems design, development, implementation,
operations, and maintenance).
6. Follow-up Review: Immigration and Naturalization Service Management of
Automation Programs, Office of the Inspector General, Audit Division, U.S.
Department of Justice, July 1999.
7. Strategic Information Planning: Framework for Designing and Developing
System Architectures (GAO/IMTEC-92-51 , June 1992).
8. OMB Memorandum M-97-02, Funding Information Systems Investments, October
25, 1996, and OMB Memorandum M-97-16, Information Technology Architectures,
June 18, 1997; NIST Special Publication 500-167, Information Management
Directions: The Integration Challenge, September 1989; and Chief Information
Officers Council, Federal Enterprise Architecture Framework, version 1.1,
September 1999.
9. A system interface is hardware and software that acts as an interpreter
to interconnect different systems and allow for the exchange of data.
10. Department of Justice Information Technology Architecture, Architectural
Requirements and Supporting Analyses, Volume I, October 1998 and Department
of Justice Information Technology Architecture, Technical Reference Model,
Volume II, December 1998.
11. OMB Memorandum M-97-02, Funding Information Systems Investments ,
October 25, 1996, and OMB Memorandum M-97-16, Information Technology
Architectures , June 18, 1997; Chief Information Officers Council, Federal
Enterprise Architecture Framework , version 1.1, September 1999; and NIST
Special Publication 500-167, Information Management Directions: The
Integration Challenge , September 1989.
12. INS' web-based tool for documenting and maintaining its enterprise
architecture.
*** End of document. ***