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. 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, 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. 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 platforms— 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. 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. 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). 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. 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. 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. 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 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. 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. 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. 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. 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. XML 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. 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. According to the Modernization Blueprint, COD will ultimately provide the 5,300 schools that participate in the title IV student financial aid programs 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. 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. 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. 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. 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. 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. As has been the case with several other organizations, a middleware integration strategy is likely a viable technology alternative for SFA in 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. 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 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. 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 Assistance 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. 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. 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. 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. 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. 28. We modified the report to delete any reference to the availability of 24- hour customer support. 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/HR- 97-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). 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). 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. 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.” Web site: www.gao.gov/fraudnet/fraudnet.htm, E-mail: fraudnet@gao.gov, or 1-800-424-5454 (automated answering system).

Summary: Although the Department of Education spent millions of dollars to modernize and integrate its nonintegrated financial aid systems during the past 10 years, these efforts have met with limited success. Recently, Education's Office of Student Financial Assistance (SFA) began using a software approach known as middleware to provide users with a more complete and integrated view of information in its many databases. In selecting middleware, SFA has adopted a viable, industry-accepted means for integrating and utilizing its existing data on student loans and grants. 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.