GAO

United States General Accounting Office

Report to the Attorney General,

Department of Justice

August 2000 INFORMATION 

TECHNOLOGY

INS Needs to Better 

Manage the 

Development of Its 

Enterprise 

Architecture

GAO/AIMD-00-212

Page 1 GAO/AIMD-00-212 INS’ Enterprise Architecture

United States General Accounting Office

Washington, D.C. 20548

Accounting and Information

Management Division

B-285590 Letr

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 

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.
B-285590

Page 2 GAO/AIMD-00-212 INS’ Enterprise Architecture

“Agency Comments and Our Evaluation” section and are reprinted in 

appendix II.

Results in Brief 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 bottomup 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, 
B-285590

Page 3 GAO/AIMD-00-212 INS’ Enterprise Architecture

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.

Background 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.
B-285590

Page 4 GAO/AIMD-00-212 INS’ Enterprise Architecture

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. 

Value of an Enterprise 

Architecture 

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 

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).
B-285590

Page 5 GAO/AIMD-00-212 INS’ Enterprise Architecture

development and implementation of agency information technology 

architectures.

INS’ Current System 

Investment Efforts

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. 

Recent Reviews Have 

Identified Weaknesses in 

INS’ Management of 

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. 

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). 
B-285590

Page 6 GAO/AIMD-00-212 INS’ Enterprise Architecture

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.

Framework for Developing 

an Enterprise Architecture

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.

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.
B-285590

Page 7 GAO/AIMD-00-212 INS’ Enterprise Architecture

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.

INS Has Taken Some 

Limited Steps Toward 

Developing an 

Enterprise 

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 

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.
B-285590

Page 8 GAO/AIMD-00-212 INS’ Enterprise Architecture

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.

Current Architecture 

Description Is Not Complete

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). 

Definition of Target 

Architecture Has Not Begun

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 
B-285590

Page 9 GAO/AIMD-00-212 INS’ Enterprise Architecture

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, 

9

A system interface is hardware and software that acts as an interpreter to interconnect 

different systems and allow for the exchange of data.
B-285590

Page 10 GAO/AIMD-00-212 INS’ Enterprise Architecture

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).

INS Does Not Have the 

Management 

Structures and 

Controls to 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. 

10Department 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.
B-285590

Page 11 GAO/AIMD-00-212 INS’ Enterprise 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.

Figure 1: INS’ Initial Target Architecture Development Plan

Source: Immigration and Naturalization Service.

Conclusions 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 

ID Task Name Duration

Nov Dec Jan

Nov Dec Jan

Feb

Feb

Mar

Mar

Apr

Apr

May

May

June

June

July

July

Aug

Aug

1

2

3

4

5

6

7

8

9

10

Pre Planning

Initial Planning

Initial Planning

Develop plan & procedures & M

Establish Domain & Business

Domain & Business teams pe

Review & Analysis

Iteration 2

Iteration 3 (if needed)

Develop strawmen

30 days

30 days

10 days

15 days

20 days

15 days

10 days

30 days

20 days

20 days

SM/I,OIRM

SM/I,OIRM

Architecture Team, SM/I,ORIM

Architecture Team, SM/I,ORIM

Architecture Team, SID,SITD,...

Domain Teams, Business Teams

Architecture Team

Architec
B-285590

Page 12 GAO/AIMD-00-212 INS’ Enterprise Architecture

architecture, INS risks continuing to build and buy systems that are not 

well-integrated, are incompatible, and do not effectively support mission 

needs.

Recommendations 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.

Agency Comments and 

Our Evaluation

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, 
B-285590

Page 13 GAO/AIMD-00-212 INS’ Enterprise Architecture

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 
B-285590

Page 14 GAO/AIMD-00-212 INS’ Enterprise Architecture

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 hiter.aimd@gao.gov or 

rhodesk.aimd@gao.gov. 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
Page 15 GAO/AIMD-00-212 INS’ Enterprise Architecture
Page 16 GAO/AIMD-00-212 INS’ Enterprise Architecture

Appendix I

Objectives, Scope, and Methodology ApendxiI

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.1

 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,2

 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 

1

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.

2

INS’ web-based tool for documenting and maintaining its enterprise architecture.
Appendix I

Objectives, Scope, and Methodology

Page 17 GAO/AIMD-00-212 INS’ Enterprise Architecture

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.
Page 18 GAO/AIMD-00-212 INS’ Enterprise Architecture

Appendix II

Comments From the Immigration and 

Naturalization Service ApendxiI
Appendix II

Comments From the Immigration and 

Naturalization Service

(511176) Letr Page 19 GAO/AIMD-00-212 INS’ Enterprise Architecture
Ordering Information The first copy of each GAO report is free. Additional copies of 

reports are $2 each. A check or money order should be made out to 

the Superintendent of Documents. VISA and MasterCard credit 

cards are accepted, also.

Orders for 100 or more copies to be mailed to a single address are 

discounted 25 percent.

Orders by mail:

U.S. General Accounting Office

P.O. Box 37050

Washington, DC 20013

Orders by visiting:

Room 1100

700 4th St. NW (corner of 4th and G Sts. NW)

U.S. General Accounting Office

Washington, DC

Orders by phone:

(202) 512-6000

fax: (202) 512-6061

TDD (202) 512-2537

Each day, GAO issues a list of newly available reports and 

testimony. To receive facsimile copies of the daily list or any list 

from the past 30 days, please call (202) 512-6000 using a touchtone 

phone. A recorded menu will provide information on how to obtain 

these lists.

Orders by Internet:

For information on how to access GAO reports on the Internet, 

send an e-mail message with “info” in the body to:

info@www.gao.gov

or visit GAO’s World Wide Web home page at: 

http://www.gao.gov

To Report Fraud, 

Waste, or Abuse in 

Federal Programs

Contact one:

• Web site: http://www.gao.gov/fraudnet/fraudnet.htm

• e-mail: fraudnet@gao.gov

• 1-800-424-5454 (automated answering system)

United States

General Accounting Office

Washington, D.C. 20548-0001

Official Business

Penalty for Private Use $300

Address Correction Requested

Bulk Rate

Postage & Fees Paid

GAO

Permit No. GI00