a

GAO

United States General Accounting Office

Report to the Honorable Edward M. 

Kennedy and the Honorable James M. 

Jeffords, U.S. Senate

November 2001 STUDENT 

FINANCIAL AID

Use of Middleware for 

Systems Integration 

Holds Promise

GAO-02-7

Page i GAO-02-7 Student Financial Aid

Contents

Letter 1

Results in Brief 2

Background 3

Middleware Technology Used Successfully in Industry 8

Middleware Implementation at SFA Is in Early Stages; Choice 

Appears Viable 10

Successful Middleware Technology Implementation Requires Right 

People, Right Skills 15

Conclusion 15

Agency Comments and Our Evaluation 16

Appendixes

Appendix I: Objectives, Scope, and Methodology 18

Appendix II: Comments From the Department of Education 19

GAO Comments 28

Related GAO Products 33

Tables Table 1: Major SFA Systems 5

Table 2: Key Milestone Dates, 1992-1999 8

Table 3: Key Title IV IT Modernization Events 12

Figures Figure 1: Student Financial Aid Data Exchange Environment 4

Figure 2: COD Implementation Using Middleware 11

Figure 3: Alternative Approaches to Database Integration 14
Contents

Page ii GAO-02-7 Student Financial Aid

Abbreviations

COD Common Origination and Disbursement 

FDLP William D. Ford Federal Direct Loan Program

FFELP Federal Family Education Loan Program

HEA Higher Education Act

IBM International Business Machines Corporation

IT information technology

NSLDS National Student Loan Data System

PBO performance-based organization

SFA Office of Student Financial Assistance

XML extensible markup language
Page 1 GAO-02-7 Student Financial Aid

United States General Accounting Office

Washington, D.C. 20548

A

November 30, 2001 Letr

The Honorable Edward M. Kennedy

The Honorable James M. Jeffords

United States Senate

Hand in hand with the rapid growth of the Internet is the need for both the 

public and private sectors to provide citizens and customers with real-time 

access to an increasing amount of data and services. To accomplish this in 

its areas of responsibility, the Department of Education spent millions of 

dollars over the past 10 years to modernize and integrate1

 its nonintegrated 

financial aid systems in an effort to provide more information and greater 

service to its customers—students, parents, schools, and lenders. 

However, the department met with limited success. For example, 

Education’s first centralized grant and loan database on student financial 

aid participants, the National Student Loan Data System (NSLDS),2

 which 

was developed to help schools screen applicants for student aid eligibility, 

often does not contain the most recent information from other financial aid 

systems. 

Recently, Education’s Office of Student Financial Assistance (SFA) initiated 

a new approach to database integration, utilizing a software approach 

commonly referred to as middleware,3

 to provide users with a more 

complete and integrated view of information contained in its multiple 

databases. As such, you requested that we provide information on the use 

of this technology, and the viability of SFA’s approach in using it to 

integrate student financial aid information. Appendix I describes our 

objectives, scope, and methodology in more detail.

1

Information integration is defined by the National Institute of Standards and Technology as 

the establishment of the appropriate computer hardware/software, methodology, and 

organizational environment to provide a unified and shared information management 

capability for a complex business enterprise.

2

NSLDS is a 1.5 billion-record database with information on 93 million loans and over 15 

million Pell Grants.

3

A type of software that permits two or more incompatible applications to exchange 

information from different databases.
Page 2 GAO-02-7 Student Financial Aid

Results in Brief Middleware technology has been used successfully by many organizations 

to provide integration solutions and effectively share data across 

nonintegrated information systems and databases. Banks, for example, use 

middleware extensively in dealing with the different systems and databases 

that accompany frequent mergers.

In selecting middleware, SFA has adopted a viable, industry-accepted 

means for integrating and utilizing its existing data on student loans and 

grants. SFA’s implementation of its use of middleware remains in its early 

stages; work has thus far focused on making initial technical modifications 

to five4

 existing systems so they will be able to interact with the new SFA 

middleware. If implemented and managed properly, this new technology 

should help ameliorate some of SFA’s longstanding database integration 

problems—problems that have contributed to slow and inconvenient loan 

servicing and internal control weaknesses. The first use of the common 

record using middleware technology is scheduled for next March. 

SFA, like other organizations, has recognized the importance of having in 

place personnel with the right experience and skills to implement its 

middleware integration strategy. To meet its human capital needs, SFA has 

solicited the help of a private-sector "modernization partner" with 

experience in implementing and managing middleware solutions—

particularly in the financial industry—and has also chosen to use a leading 

middleware software product. 

In commenting on a draft of this report, the Deputy Secretary of Education 

sought clarification on whether our analysis addressed the full range of 

issues that we have raised in the past regarding SFA’s systems integration 

problems, and their relationship to the department’s inclusion on our highrisk list. We clarified that the scope of our review was specifically focused 

on SFA’s middleware strategy.

4

These include four of the 11 major systems and one new system, bTrade, which manages 

SFA’s electronic business processes. In addition, according to SFA management, up to nine 

newer SFA systems will be modified to use middleware technology by December 2001, and 

other systems will not be modified as they are scheduled for retirement.
Page 3 GAO-02-7 Student Financial Aid

Background SFA manages and administers student financial assistance programs 

authorized under title IV of the Higher Education Act of 1965, as amended 

(HEA). These postsecondary programs include the William D. Ford 

Federal Direct Loan Program (FDLP--often referred to as the "Direct 

Loan"), the Federal Family Education Loan Program (FFELP--often 

referred to as the "Guaranteed Loan"), the Federal Pell Grant Program, and 

campus-based programs.5

 Annually, these programs together provide 

about $50 billion in student aid to approximately 8 million students and 

their families. As a consequence, the student financial aid data exchange 

environment is large and complex. It includes about 5,300 schools 

authorized to participate in the title IV program, 4,100 lenders, 36 guaranty 

agencies,6

 as well as other federal agencies. Currently, SFA oversees or 

directly manages approximately $220 billion in outstanding loans 

representing about 100 million borrowers. Figure 1 provides an overview 

of this environment. 

5

Campus-based programs, which include the Federal Work-Study Program, the Federal 

Perkins Loan Program, and the Federal Supplemental Educational Opportunity Grant 

Program, are administered jointly by SFA and postsecondary educational institutions.

6

State and private nonprofit guaranty agencies act as agents of the federal government, 

providing a variety of services, including payment of defaulted loans, collection of some 

defaulted loans, default-avoidance activities, and counseling to schools and students.
Page 4 GAO-02-7 Student Financial Aid

Figure 1: Student Financial Aid Data Exchange Environment

Source: GAO representation based on data supplied by SFA.
Page 5 GAO-02-7 Student Financial Aid

During the past three decades, the Department of Education has created 

many nonintegrated information systems to support its growing number of 

student financial aid programs. In many cases, these systems—maintained 

and operated by a host of different contractors, on multiple platforms7

—

are unable to easily exchange timely, accurate, and useful information 

needed to ensure the proper management and oversight of various student 

aid programs. Table 1 lists SFA’s current inventory of major systems.

Table 1: Major SFA Systems

Source: SFA.

7

The SFA systems environment includes a variety of operating systems and platforms (e.g., 

IBM OS/390 mainframe, Sun Solaris on Sparc, and Windows NT. SFA’s networks use 

Transmission Control Protocol/Internet Protocol and Systems Network Architecture).

System Purpose

Campus Based System Supports the campus-based student financial aid programs, including the collection and editing of data, 

allocation and distribution of funds, and the update and maintenance of school-related data.

Central Processing System Used in determining students’ eligibility and award levels and passing the information on to students, 

parents, and schools.

Direct Loan Origination 

System 

Used to originate Direct Loans and Direct Consolidation Loans. 

Direct Loan Servicing/

Consolidation Systems 

Supports loan servicing (i.e., handles billings and repayments, and assists with customer service) and is 

used to consolidate existing multiple student loans, held by an individual borrower, into a single loan for 

repayment purposes.

Federal Family Education 

Loan System 

Used to pay interest and claims on defaulted loans to lenders and supports collection activity on student 

loans in default. 

SFA-Financial Management 

System

Provides a single, centralized system where all title IV transactions reside, interfaces with the department’s 

General Ledger, and is used to make payments to guaranty agencies.

Multiple Data Entry System Supports data entry for approximately 10 million applications for federal student aid each year. 

National Student Loan Data 

System 

Contains loan and grant-level information; used by schools to screen student aid applicants to identify 

borrowers who are in default, have reached statutory loan limits, or are otherwise ineligible to receive aid. 

Postsecondary Education 

Participants System 

Supports SFA program integrity by providing software development and supporting detailed information on 

all institutions participating in federal student aid programs, as well as other programs authorized under 

HEA.

Recipient and Financial 

Management System

Used to track Pell Grant awards and distribute and monitor grant funds to institutions and students.

Title IV Wide Area Network Supports electronic telecommunications to link lenders, guaranty agencies, and schools with SFA’s 

information and application processing systems.
Page 6 GAO-02-7 Student Financial Aid

Beginning in 1992, title IV student financial aid systems integration was the 

subject of heightened congressional concern. The 1992 HEA amendments 

required the department to centralize data on student loan indebtedness by 

integrating databases containing student financial aid program 

information. In response to this mandate, in January 1993 Education 

awarded a 5-year, $39-million contract for development and maintenance of 

NSLDS. The system was to provide information on students across 

programmatic boundaries, yet problems persisted. 

Since 1995, because of concerns over Education’s vulnerabilities to losses 

due to fraud, waste, abuse, and mismanagement, student financial aid has 

been included on our high-risk list.8

 Studies had shown that Education had 

used inadequate management information systems containing unreliable 

data, and that inaccurate loan data were being loaded into NSLDS. 

In 1997, 4 years after the initiation of the NSLDS contract, data 

inconsistencies and errors across systems, such as a student’s enrollment 

status or the amount of loan indebtedness, continued to have a negative 

impact on the student’s ability to receive aid. Education still lacked an 

accurate, integrated system for student financial aid data; the 

nonintegrated systems would sometimes provide conflicting information to 

the department’s financial aid partners (schools, lenders, guaranty 

agencies).9

 The department had opted to establish NSLDS as a data 

repository rather than an integrated database; this meant that while the 

system could receive and store information from other title IV systems, the 

lack of uniformity in how the individual systems stored their information—

no common student or institutional identifiers or data standards—

complicated data-matching among systems. Hence, NSLDS could not be 

effectively updated (or update other systems) without expensive data 

conversion programs. As a result, data contained in other systems, 

operated by a variety of contractors, were often in conflict with data stored 

in NSLDS due to differences in the timing of updates among the multiple 

data providers. 

8

High-Risk Series: Student Financial Aid (GAO/HR-95-10, February 1995); High-Risk 

Program: Information on Selected High-Risk Areas (GAO/HR-97-30, May 1997); High-Risk 

Series: An Update (GAO/HR-99-1, January 1999); and High-Risk Series: An Update (GAO01-263, January 2001). The former Guaranteed Student Loan Program, now called the 

Federal Family Education Loan Program, was included in our original 1990 list; in 1995 we 

revised this designation to include all title IV student financial aid programs.

9

See Department of Education: Multiple, Nonintegrated Systems Hamper Management of 

Student Financial Aid Programs (GAO/T-HEHS/AIMD-97-132, May 15, 1997).
Page 7 GAO-02-7 Student Financial Aid

As also reported in 1997, large amounts of redundant student financial aid 

data generated by schools, lenders, guaranty agencies, and several internal 

department systems, were being stored in standalone databases, thereby 

increasing the cost to administer the various title IV programs.10 We 

concluded that these data exchange and storage problems, as well as other 

program operation and monitoring difficulties, were partly related to the 

lack of a fully functional integrated database covering all title IV student 

financial aid programs. 

In 1998, in part to address these and other longstanding management 

weaknesses, Congress amended HEA and established SFA as the federal 

government’s first performance-based organization (PBO). Under the PBO 

concept, SFA is a discrete organizational unit within the Department of 

Education, and focuses solely on programmatic—rather than policy—

issues, which remain the responsibility of the Secretary of Education. 

Thus, upon being designated a PBO, SFA was expected to shift from a focus 

on adherence to required processes to a focus on customers and program 

results. Moreover, in establishing SFA as a PBO, Congress gave SFA 

specific personnel hiring authority, including the ability to appoint up to 25 

technical and professional employees without regard to provisions 

governing appointments to the competitive service. Also in conjunction 

with its PBO status, SFA can seek waivers from governmentwide 

regulations, policies, and procedures (e.g., acquisition, human capital, and 

procurement). This flexibility is intended to give SFA greater freedom in 

achieving their performance goals while maintaining accountability for 

operational aspects of federal student aid programs. 

In September 1999, under this PBO procurement authority, SFA hired 

Accenture (formerly Andersen Consulting) as its "modernization partner," 

to help it carry out its Modernization Blueprint.11 Accenture’s role is to 

provide leadership of critical planning activities essential to the success of 

SFA’s modernization. As a result of these and other events between 1992 

and 1999, the management structure of SFA’s postsecondary education 

activities was completely reorganized. Under the partnership between the 

PBO and Accenture, a new systems integration strategy emerged, focusing 

on the use of middleware software technology to achieve database 

10GAO/T-HEHS/AIMD-97-132, May 15, 1997.

11The modernization plan that describes the business requirements, business and technical 

architecture, and sequencing plan that SFA will use to transform the title IV student 

financial aid systems using technology.
Page 8 GAO-02-7 Student Financial Aid

integration and improve access to and use of SFA’s information. Table 2 

lists key events and milestones during the past decade affecting 

Education’s student financial assistance programs and the systems that 

support them.

Table 2: Key Milestone Dates, 1992-1999

Source: SFA.

Middleware 

Technology Used 

Successfully in 

Industry

Hundreds of organizations around the world have found successful 

technology integration solutions through the use of middleware, sharing 

data across different information systems and databases. Middleware is a 

type of software that enables programs and databases located on different 

systems to work together as if they all resided in a single database. Often 

organizations use middleware together with Web-based applications to 

present users with an integrated view of relevant data over the Internet, 

without having to develop new systems or database software. The 

middleware acts as an intermediary that mines data from existing 

databases and performs any necessary data transformation so that the 

existing information can be quickly compiled and presented to the user. 

For instance, middleware is used heavily in the banking industry, 

particularly for those institutions involved in numerous mergers and 

acquisitions, as it allows both banks to keep their existing systems, 

programs, and databases essentially unchanged, while providing users such 

as branch personnel with a composite view of both customer databases.

Date Milestone

July 1992 HEA amendments enacted requiring the Department of Education to 

centralize data on student loan indebtedness by integrating 

databases. 

January 1993 Education awards a contract for development and maintenance of 

NSLDS to integrate student financial aid databases.

February 1995 Student financial aid added to our list of high-risk programs.

July 1997 We report that Education still does not have accurate, integrated SFA 

systems or databases.

October 1998 HEA amendments establish SFA as a PBO.

October 1998 SFA appoints chief operating officer.

September 1999 SFA chooses a modernization partner to provide expertise for 

information technology needs.
Page 9 GAO-02-7 Student Financial Aid

We contacted three major financial institutions that use the same 

middleware product adopted by SFA: IBM’s MQSeries. According to these 

companies, as with SFA, the driving force behind the acquisition of the 

middleware technology was multiple, incompatible platforms. Overall, 

banking industry information technology officials with whom we spoke 

were pleased with the technical capabilities of middleware, but said that 

the major issue in successfully implementing and maintaining a 

middleware-based systems environment was retaining skilled employees—

whether in-house or via an external contract. 

According to SFA’s chief operating officer, by using the banking industry as 

a benchmark for establishing the viability of the middleware approach, SFA 

was better able to identify the strengths and weaknesses of that approach. 

He saw the banking industry as analogous to SFA in that it had to 

successfully address systems interoperability problems and provide users 

with an integrated data view following mergers. Similarly, we previously 

noted a gap between the services available to bank customers, and those 

available to students and their families—such as the ability to view 

complete account data and make account changes worldwide, across 

systems, through automated teller machines.12

12GAO/AIMD-97-122, July 29, 1997.
Page 10 GAO-02-7 Student Financial Aid

Middleware 

Implementation at SFA 

Is in Early Stages; 

Choice Appears Viable

SFA’s initiative is in its early stages, and as of July 1, 2001, SFA had made 

the initial system modifications necessary to use the middleware 

technology on five systems. In addition, SFA’s contract programmers have 

been developing software using extensible markup language (XML)13—now 

becoming an industry standard—that will eventually standardize student 

grant and loan origination and disbursement requests into a single common 

record format for all aid programs. Moreover, the enterprise application 

integration architecture plans and documents are in place that are 

conducive to the IBM MQSeries middleware product line being used to 

facilitate data integration across SFA’s different computing platforms.14

The first use of middleware and XML together for loan originations and 

disbursements is expected in March 2002, when a single process for 

delivering Direct Loan and Pell Grant aid to students, called Common 

Origination and Disbursement (COD), is scheduled for implementation in 

time for the 2002-2003 school year. In March, SFA plans to provide at least 

50 schools that participated in testing using COD with the option of 

submitting data via its new common record format for Direct Loans and 

Pell Grants. 

The COD is designed to provide a consistent process—via the common 

record—for requesting, reporting, and reconciling Pell Grants and Direct 

Loans. Now, schools must enter, submit, and reconcile data separately for 

each program, data including name, address, and other pertinent 

information for the same student in different formats—a redundant 

process that can be quite time-consuming. 

For the 5,000+ schools authorized to participate in the title IV program, but 

do not yet utilize the new approach, SFA’s middleware is designed to permit 

submission and receipt of both aid program records in their current record 

formats, using the existing transmission process. The software contains 

rules that are used to convert incoming school records into the new 

13XML is a meta-markup language that provides a format for describing structured data. 

XML is designed to enable the exchange of information (data) between different 

applications and data sources on the World Wide Web and has been standardized by the 

World Wide Web Consortium, an organization that develops common protocols to promote 

the evolution and interoperability of the Web.

14The Enterprise Application Integration Architecture, Detailed Design Document (October 

13, 2000) and the Modernization Blueprint explain the IT architecture that SFA is using to 

plan and build its middleware strategy.
Page 11 GAO-02-7 Student Financial Aid

common record format and outgoing records back to the schools in their 

current record format. Thus, if SFA’s middleware approach is operationally 

successful, it will allow schools to use either method; those schools that do 

not use the new common record format could migrate to the common 

record on timetables that are more feasible for their individual 

circumstances. Figure 2 illustrates the first planned implementation of 

COD for Direct Loan and Pell Grant originations and disbursements using 

either the common record format or middleware.

Figure 2: COD Implementation Using Middleware

Source: GAO representation based on data supplied by SFA.

According to the Modernization Blueprint, COD will ultimately provide the 

5,300 schools that participate in the title IV student financial aid programs 
Page 12 GAO-02-7 Student Financial Aid

with a single process for all aid origination and disbursement. This is 

expected to create a system that facilitates close to real-time sharing of 

data across all of SFA’s partners, and establish a platform that supports 

integrated technical and functional customer service for schools across all 

programs. SFA’s Modernization Blueprint also outlines key projects that 

are scheduled for implementation over the course of several years. Table 3 

lists some of them. 

Table 3: Key Title IV IT Modernization Events

Source: SFA. 

In adopting this approach to better integration and utilization of its existing 

data on student loans and grants, SFA may be able to address, at least in 

part, long-standing database integration problems. Such problems have 

contributed to slow and inconvenient loan servicing and management, as 

well as weak internal controls. 

Date Event

March 2001 COD design complete.

July 2001 Testing completed on five SFA systems to enable transfer of data 

through middleware.

March 2002 At least 50 schools scheduled to begin submitting Pell Grant and 

Direct Loan originations using middleware-created COD 

common record format.

April 2002—

October 2004

SFA modernization continues, e.g., COD initiative, electronic 

commerce initiative, and additional SFA systems retired.
Page 13 GAO-02-7 Student Financial Aid

SFA fully expects that this solution will provide improved customer service 

by permitting its eleven major systems to operate more cohesively in the 

near future and help reduce the total number of needed systems over the 

long term. Some of the problems SFA hopes to eliminate include improving 

the cumbersome process for gaining access to the various SFA system 

databases. This process sometimes requires users, such as an educational 

institution’s financial aid or accounting staff, to continually log in and out 

of different systems for related aid information on students for each 

program. These individuals must sometimes use a different school 

identifier and password to gain access to student information for each SFA 

program, and often do not have the ability to retrieve necessary 

information when they do gain access. As we noted in 1995, this internal 

control problem of not having access to current, accurate information 

sometimes led to loans and grants being improperly awarded.15 SFA 

expects that its middleware product will enable entities to gradually 

upgrade or migrate to new systems and databases while maintaining a 

consistent view for the user. That is, middleware can enable SFA to realize 

short-term, user-level integration, while enabling it to gradually improve its 

older systems over time. 

In short, by adopting a middleware-based strategy, SFA expects that it can 

continue operating some of its existing systems, applications, and 

databases, but in a more homogeneous fashion. Moreover, according to 

SFA’s chief operating officer, the alternative of developing a new, large, 

central database or student financial aid system was less suitable because 

of the cost and time involved in database redesign and data format 

conversion. Further, he expects middleware to be part of SFA’s long-term 

solution for integrating databases under its Modernization Blueprint and, 

through 2004, allow the eventual retirement of several existing systems. 

Finally, he expects this approach to allow SFA to be more responsive to 

customer needs. Figure 3 shows how the two alternative approaches differ 

in providing data to users. 

15Student Financial Aid: Data Not Fully Utilized to Identify Inappropriately Awarded Loans 

and Grants (GAO/HEHS-95-89, July 11, 1995).
Page 14 GAO-02-7 Student Financial Aid

Figure 3: Alternative Approaches to Database Integration

Source: GAO representation based on data supplied by SFA.
Page 15 GAO-02-7 Student Financial Aid

Successful Middleware 

Technology 

Implementation 

Requires Right People, 

Right Skills 

The experiences of other organizations have demonstrated that critical 

skill shortages must continually be addressed when using middleware as an 

integration solution. According to middleware users, the technology 

requires experienced, highly skilled programmers, with a broad knowledge 

of the entire environment in order to maintain seamless data exchanges. 

Industry officials cite the lack of sufficient numbers of programmers with 

the needed technical skills. According to IBM representatives, extensive 

technical training is needed before an experienced programmer can 

become effective using its middleware product. 

Banking officials confirm that finding people who are highly skilled in the 

use of this technology is difficult. For example, according to a senior 

official at a major bank, an experienced, certified middleware systems 

programmer can command over $100,000 annually, making retention of this 

type of talent challenging even for this bank in today’s competitive 

information technology marketplace.16 

SFA management recognizes that it will face the same inherent human 

capital issues as these organizations and has tried to address them by 

leveraging experiences from the banking industry and by acquiring 

contracted expertise. In addressing the human capital skills issue 

associated with successful middleware implementation, SFA will count on 

the help of its modernization partner, who has substantial experience in 

implementing middleware solutions in the banking industry and the use of 

the middleware product’s vendor (IBM) as programmers.

According to officials of another federal agency using MQSeries, when they 

originally tried to develop similar capabilities in-house, they were later 

forced to switch to the commercial product because of technical 

difficulties in maintaining the system on their own. A MQSeries users 

group also exists; other federal agencies using the MQSeries include the 

Customs Service, the Department of Veterans Affairs, and the Air Force, 

from which SFA may be able to borrow knowledge and technical expertise. 

Conclusion As has been the case with several other organizations, a middleware 

integration strategy is likely a viable technology alternative for SFA in 

16According to IBM, this bank is the largest user of IBM’s middleware product in the 

Northern Hemisphere.
Page 16 GAO-02-7 Student Financial Aid

addressing its long-standing systems integration problems. SFA recognizes 

the human capital issues that middleware presents, and is preparing to 

meet them. While early, if implemented properly, middleware appears to be 

a reasonable approach that could result in improved user-level systems 

integration, while enabling SFA to gradually retire many of its remaining 

systems over time.

Agency Comments and 

Our Evaluation

In commenting on our draft report, the Deputy Secretary sought 

clarification on whether our analysis of SFA’s actions to use a middleware 

integration strategy addressed the full range of issues that we and the 

Education Inspector General had raised in past reports regarding SFA’s 

systems integration problems and rationale for SFA’s programs being 

included on our high-risk list. Specifically, he suggested that we clarify 

whether the middleware strategy adequately addressed our earlier 

concerns about SFA’s lack of an architecture, the costs associated with 

maintaining nine or more separate information systems, and the need for a 

long-term integrated SFA database. Additionally, the Deputy Secretary 

wanted us to clarify whether the new strategy introduced any new 

problems related to costs, increased risk of system breakdown, or 

introduction of errors into the current systems environment.

While these are important issues, the focus of our review was to provide 

information on the use of the middleware technology and its viability as a 

means of integrating student financial aid information. As we note in the 

report, SFA’s middleware integration work is still in development and is 

moving into very early stages of implementation. Although preliminary 

testing and pilot efforts involving the middleware data integration 

capability have been positive, the actual versus expected benefits will not 

be known or measured until planned projects and activities become 

operational. We have concluded that SFA’s middleware strategy itself 

appears to be a reasonable technical approach for improving data 

integration.

The Deputy Secretary also asked whether we took into account several 

previous reports in which we stated that the department needed a sound 

systems architecture before embarking on systems integration. We note 

that SFA has devised an enterprise-wide systems architecture in response 

to our 1997 recommendation and that SFA provided us with requisite 

technical documents that explained the guiding architecture on which it is 

building its middleware strategy. However, the scope of our review did not 
Page 17 GAO-02-7 Student Financial Aid

include an assessment of the adequacy of departmentwide architecture 

implementation and usage. 

Finally, the Deputy Secretary raised several technical questions related to 

the report’s graphics, terminology, and descriptions. We have clarified or 

modified these points where appropriate. Education’s written comments, 

along with our responses, are reproduced in appendix II.

As we agreed with your office, unless you publicly announce the contents 

of this report earlier, we plan no further distribution of it until 30 days from 

the date of this letter. We are sending copies of this report to the Secretary 

of Education, Education’s Office of Student Financial Assistance’s chief 

operating officer, the Director of the Office of Management and Budget, 

and appropriate congressional committees. Copies will also be available to 

other interested parties upon request. This report will be available on our 

Web site at www.gao.gov. If you or your offices have questions regarding 

this report, please call me at (202) 512-6257 or David B. Alston, Assistant 

Director, at (202) 512-6369. We can also be reached by e-mail at 

mcclured@gao.gov and alstond@gao.gov, respectively. Other individuals 

making key contributions to this report included Nabajyoti Barkakati, 

Michael P. Fruitman, and Glenn R. Nichols.

David L. McClure

Director, Information Technology 

Management Issues
Page 18 GAO-02-7 Student Financial Aid

Appendix I

Objectives, Scope, and Methodology ApApenednxidexiIs

Our objectives were to provide information on the use of middleware 

technology, and to evaluate the viability of SFA’s approach to using it to 

integrate student financial aid information. To achieve these objectives, we 

examined SFA documents, including the Modernization Blueprint and 

updates and information technology target architectures. We assessed how 

critical information technology integration issues are being addressed at 

SFA, including the merits and risks of the blueprint, and assessed agency 

documentation to determine whether SFA’s systems environment lends 

itself to a technically feasible middleware solution. In addition, we 

analyzed several technical documents on the general function and use of 

middleware, and interviewed officials from SFA and Accenture, its 

modernization partner. We also interviewed officials from the Advisory 

Committee on Student Financial Assistance1

 to obtain their perspective on 

SFA’s use of middleware.

Further, we spoke with officials from IBM, the developer of the middleware 

product (MQSeries) being implemented by SFA. We analyzed technical 

documents describing the operation of the MQSeries in general, as well as 

design documents addressing the implementation of this middleware 

product at SFA. 

To independently document the success of this middleware product in the 

public and private sectors, we consulted with users from the U.S. Customs 

Service, Bank of America, Chase Manhattan Bank, and First Union Bank. 

We analyzed documents relating to the implementation of this middleware 

product in two of these organizations. 

We performed this work at SFA headquarters and Accenture offices in 

Washington, D.C.; IBM’s office in McLean, Virginia, the U.S. Customs 

Service office in Springfield, Virginia; and Bank of America offices in 

Charlotte, North Carolina. We also conducted telephone interviews with 

officials from Chase Manhattan Bank and First Union Bank. Our work was 

performed from February through August 2001, in accordance with 

generally accepted government auditing standards.

1

The Congress created the Advisory Committee on Student Financial Assistance when it 

enacted the HEA Amendments of 1986. The Advisory Committee serves as an independent 

public advisory committee to the Department of Education and the Congress.
Page 19 GAO-02-7 Student Financial Aid

Appendix II

Comments From the Department of 

Education ApendxiI

Note: GAO comments 

supplementing those in the 

report text appear at the end of 

this appendix.
Appendix II

Comments From the Department of 

Education

Page 20 GAO-02-7 Student Financial Aid

See comment 1.

See comment 2.

See comment 3.
Appendix II

Comments From the Department of 

Education

Page 21 GAO-02-7 Student Financial Aid

See comment 4.

See comment 5.

See comment 6.
Appendix II

Comments From the Department of 

Education

Page 22 GAO-02-7 Student Financial Aid

See comment 7.

See comment 8.

See comment 9.

See comment 10.
Appendix II

Comments From the Department of 

Education

Page 23 GAO-02-7 Student Financial Aid

See comment 11.

See comment 12.

See comment 13.

See comment 14.
Appendix II

Comments From the Department of 

Education

Page 24 GAO-02-7 Student Financial Aid

See comment 15.

See comment 16.

See comment 17.
Appendix II

Comments From the Department of 

Education

Page 25 GAO-02-7 Student Financial Aid

See comment 18.

See comment 19.

See comment 20.

See comment 21.
Appendix II

Comments From the Department of 

Education

Page 26 GAO-02-7 Student Financial Aid

See comment 22.

See comment 24.

See comment 25.

See comment 23.
Appendix II

Comments From the Department of 

Education

Page 27 GAO-02-7 Student Financial Aid

See comment 26.

See comment 27.

See comment 28.
Appendix II

Comments From the Department of 

Education

Page 28 GAO-02-7 Student Financial Aid

GAO Comments 1. We changed the report title to clarify that the scope of our review was 

focused on determining if SFA’s middleware systems integration 

strategy was a viable approach.

2. Given the scope of our review, we believe the report adequately 

addresses this concern. In drafting our report, we took into 

consideration previous GAO, Education’s Inspector General reports, 

and the department’s internal reports, particularly those relating to 

Education’s lack of a guiding enterprise architecture and the 

department’s pressing need to integrate its student financial aid 

systems and databases. For instance, we have already credited the 

department with defining a departmentwide systems architecture in 

response to our 1997 report on this topic. Further, in reviewing SFA’s 

middleware strategy, we confirmed that enterprise application 

integration architecture plans and documentation existed and was 

conducive to the IBM MQSeries middleware product line being used to 

facilitate data integration across SFA’s current computing platforms. 

However, the scope of our work did not permit us to assess the 

adequacy of departmentwide architecture implementation and usage 

issues. 

3. The commitment indicated by the Secretary and SFA to resolve 

longstanding problems mentioned in our previous reports can go a long 

way towards providing the catalyst to solve many of Education’s data 

integrity problems. These problems have contributed to the inclusion 

of SFA’s programs on GAO’s high-risk list. However, neither the 

department’s or SFA’s efforts to address critical data quality and 

internal control issues related to its high-risk designation were included 

in the scope of this review. We do note, however, that SFA expects to 

reduce the number of total systems needed in the long-term in 

conjunction with its middleware implementation.

4. Past problems as well as rationale for better integrated program and 

financial data across SFA’s existing databases are explained in the 

background section of our report rather than in this brief opening 

paragraph. As such, we made no changes to the report. While 

middleware provides a means for better user integration, sound 

business practices and disciplined internal management controls will 

be needed for any organization to achieve mission improvements and 

financial benefits from its information systems investments. 
Appendix II

Comments From the Department of 

Education

Page 29 GAO-02-7 Student Financial Aid

5. Our discussion of integration in this context is based upon SFA’s most 

recently released Modernization Blueprint, which states that SFA’s task 

is to create:

" . . . an integrated enterprise that meets our PBO goals of improved 

customer and employee satisfaction, and reduced unit costs. Part of 

that task is to modernize key systems and processes to create an 

enterprise that meets our customers needs. We can view some of these 

key processes and systems as major pieces of an overall integrated 

solution.”

Given SFA’s description of the goals they wish to achieve through 

integration, we did not modify our report. 

6. We agree with the descriptions of the additional shortcomings of 

NSLDS, but timeliness of updates remains a major issue. The objective 

of our review also was not to review and critique the problems of 

NSLDS as we did previously, rather, to focus on looking forward and 

assessing middleware as a suitable technology solution in the future for 

integrating SFA’s systems. Thus, we only provided one example of the 

negative consequences stemming from the lack of integration but 

provided numerous references to previous reports that describe these 

and other problems in greater detail. Accordingly, we did not modify 

our report. 

7. SFA’s Chief Operating Officer (COO) clearly considers the use of 

middleware part of a long-term systems integration solution. 

Therefore, we did not modify our report.

8. We concur that the scope of our review was to determine whether 

middleware technology is viable and feasible in SFA’s system 

environment and that other issues were not covered in our work. 

Accordingly, we did not modify our report.

9. We updated our report to reflect that SFA now plans to have about 14 

systems connected to middleware by December 2001.

10. We updated our report to clarify that some legacy systems, according to 

SFA’s Modernization Blueprint, will not have to be modified for 

middleware because some will be retired in the future. 
Appendix II

Comments From the Department of 

Education

Page 30 GAO-02-7 Student Financial Aid

11. We modified our report to reflect that the first planned use of 

middleware for Direct Loan and Pell Grant originations and 

disbursement would occur next year.

12. We updated our report to reflect the change in the implementation date. 

13. We did not modify our report. Education’s Central Automated 

Processing System (EDCAPS) included in figure 1 and table 1 in our 

report is not the same as the Central Data System (CDS), which has 

been retired. EDCAPS is the primary accounting system for the 

department. The department’s Management Improvement Team 

Accomplishments document, dated October 30, 2001, describes 

EDCAPS as Education’s “financial records and accounting system.” 

CDS is not discussed in our report.

14. We modified our report to reflect that the PBO was established in 1998.

15. We modified our report to clarify responsibilities of SFA under the PBO 

legislation. 

16. We modified our report to indicate SFA’s participation.

17. We believe the appointment of SFA’s COO was a relevant milestone. 

Several sections of the HEA Amendments of 1998 creating the PBO 

address the functions of the COO, including the requirement to have a 

PBO performance plan. Likewise, the selection of the SFA 

modernization partner also was a relevant milestone, especially in light 

of the important role that the partner plays in SFA’s systems 

modernization, which is described in the report. Therefore, we did not 

modify our report.

18. We modified our report to clarify that there are additional users of the 

MQSeries product.

19. We did not modify our report. The figure displays only the COD 

process, which will initially include only Direct Loan and Pell Grant 

origination and disbursements. All Direct Loan and Pell Grant funds 

are federal and ultimately come from the U.S. Treasury. We purposely 

omitted the Federal Reserve and other intermediary systems for 

simplicity. Schools will follow the COD process described in the figure 

when originating loan and grant applications on behalf of students.
Appendix II

Comments From the Department of 

Education

Page 31 GAO-02-7 Student Financial Aid

20. We modified our report to better reflect that middleware will also 

convert disbursement records back to each school’s current record 

format.

21. According to SFA’s most recently released Modernization Blueprint 

(page 13), the COD is expected to be able to provide all schools that 

participate in title IV financial aid programs with a single process for 

aid origination and disbursement. SFA staff confirmed the accuracy of 

this statement. Therefore, we did not modify our report.

22. According to SFA’s Modernization Blueprint, COD is expected to be 

capable of handling all aid distribution. The first use will be for Direct 

Loan and Pell Grant origination and distribution. Therefore, we did not 

modify our report.

23. We did not modify our report. The internal control problems identified 

in the 1995 report focused on the need to have timely, accurate student 

eligibility data. Also, see comment 6.

24. As noted in the report, we are attributing the choice between two 

options -- developing a large central database or maintaining several 

integrated databases using middleware -- to SFA’s COO. By 2004, SFA 

does expect to retire several existing systems that should result in 

fewer databases than currently exist.

25. We modified our report to note that SFA plans to retire systems through 

2004. 

26. We did not assess the capabilities of Accenture, as this was not 

included in the scope of our work. Therefore, we did not modify our 

report.

27. As noted, we point out that SFA is attempting to address its human 

capital challenges associated with the use of the new middleware 

technology by leveraging the experiences from the banking industry as 

well as acquiring recognized contractor expertise. These are prudent 

steps, but the adequacy of specific measures being taken both by SFA 

management and its modernization partner in addressing workforce 

management and planning needs go beyond the scope of this review; 

therefore, we did not modify the report. 
Appendix II

Comments From the Department of 

Education

Page 32 GAO-02-7 Student Financial Aid

28. We modified the report to delete any reference to the availability of 24-

hour customer support.
Page 33 GAO-02-7 Student Financial Aid

Related GAO Products

Financial Management: Internal Control Weaknesses Leave Department 

of Education Vulnerable to Improper Payments (GAO-01-585T, April 3, 

2001).

High-Risk Series: An Update (GAO-01-263, January 2001). 

High-Risk Series: An Update (GAO/HR-99-1, January 1999).

Student Financial Aid Information: Systems Architecture Needed to 

Improve Programs’ Efficiency (GAO/AIMD-97-122, July 29, 1997).

High-Risk Program: Information on Selected High-Risk Areas (GAO/HR97-30, May 1997).

Department of Education: Multiple, Nonintegrated Systems Hamper 

Management of Student Financial Aid Programs (GAO/T-HEHS/AIMD-97-

132, May 15, 1997).

High Risk Series: Student Financial Aid (GAO/HR-97-11, February 1997).

Reporting of Student Loan Enrollment Status (GAO/HEHS-97-44R, 

February 6, 1997).

Department of Education: Status of Actions to Improve the Management of 

Student Financial Aid (GAO/HEHS-96-143, July 12, 1996).

Student Financial Aid: Data Not Fully Utilized to Identify Inappropriately 

Awarded Loans and Grants (GAO/T-HEHS-95-199, July 12, 1995).

Student Financial Aid: Data Not Fully Utilized to Identify Inappropriately 

Awarded Loans and Grants (GAO/HEHS-95-89, July 11, 1995).

Federal Family Education Loan Information System: Weak 

ComputerControls Increase Risk of Unauthorized Access to Sensitive Data 

(GAO/AIMD-95-117, June 12, 1995).

High-Risk Series: Student Financial Aid (GAO/HR-95-10, February 1995).

Financial Audit: Federal Family Education Loan Program’s Financial 

Statements for Fiscal Years 1993 and 1992 (GAO/AIMD-94-131, June 30, 

1994).
Related GAO Products

Page 34 GAO-02-7 Student Financial Aid

Financial Management: Education’s Student Loan Program Controls Over 

Lenders Need Improvement (GAO/AIMD-93-33, September 9, 1993).

Financial Audit: Guaranteed Student Loan Program’s Internal Controls and 

Structure Need Improvement (GAO/AFMD-93-20, March 16, 1993).

Department of Education: Management Commitment Needed to Improve 

Information Resources Management (GAO/IMTEC-92-17, April 20, 1992).

(310403) Letr
GAO’s Mission The General Accounting Office, the investigative arm of Congress, exists to 

support Congress in meeting its constitutional responsibilities and to help improve 

the performance and accountability of the federal government for the American 

people. GAO examines the use of public funds; evaluates federal programs and 

policies; and provides analyses, recommendations, and other assistance to help 

Congress make informed oversight, policy, and funding decisions. GAO’s 

commitment to good government is reflected in its core values of accountability, 

integrity, and reliability.

Obtaining Copies of 

GAO Reports and 

Testimony

The fastest and easiest way to obtain copies of GAO documents is through the 

Internet. GAO’s Web site (www.gao.gov) contains abstracts and full-text files of 

current reports and testimony and an expanding archive of older products. The 

Web site features a search engine to help you locate documents using key words 

and phrases. You can print these documents in their entirety, including charts and 

other graphics.

Each day, GAO issues a list of newly released reports, testimony, and 

correspondence. GAO posts this list, known as “Today’s Reports,” on its Web site 

daily. The list contains links to the full-text document files. To have GAO E-mail 

this list to you every afternoon, go to our home page and complete the easy-to-use 

electronic order form found under “To Order GAO Products.”

Order by Mail or Phone The first copy of each printed report is free. Additional copies are $2 each. A check 

or money order should be made out to the Superintendent of Documents. GAO 

also accepts VISA and Mastercard. Orders for 100 or more copies mailed to a single 

address are discounted 25 percent. Orders should be sent to:

U.S. General Accounting Office

P.O. Box 37050

Washington, D.C. 20013

To order by Phone: Voice: (202) 512-6000 

TDD: (301) 413-0006 

Fax: (202) 258-4066

Visit GAO’s Document 

Distribution Center

GAO Building 

Room 1100, 700 4th Street, NW (corner of 4th and G Streets, NW)

Washington, D.C. 20013

To Report Fraud, 

Waste, and Abuse in 

Federal Programs

Contact:

Web site: www.gao.gov/fraudnet/fraudnet.htm,

E-mail: fraudnet@gao.gov, or

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

Public Affairs Jeff Nelligan, Managing Director, NelliganJ@gao.gov (202) 512-4800

U.S. General Accounting Office, 441 G. Street NW, Room 7149, 

Washington, D.C. 20548

United States

General Accounting Office

Washington, D.C. 20548-0001

Official Business

Penalty for Private Use $300

Address Correction Requested

Presorted Standard

Postage & Fees Paid

GAO

Permit No. GI00