One might wonder why a public school system would be concerned with application integration. Public schools have come a long way since the "little red schoolhouse."
Providing a quality education while achieving an economy of scale for such a large system requires a significant investment in technology. Fairfax County Public Schools (FCPS) in Virginia has enterprise applications covering every major function. Like any large organization, there are human resources, payroll and financial management applications. However, like other school systems, there are also student information, library, transportation, food services, special education and many instructional applications.
The need for integration among the applications is great. For instance, the student information application maintains information on students, which the transportation application needs so students can catch the bus, the library application needs so they can check out books and the food services application needs so they can pay for meals.
Many school systems are now beginning to integrate applications to reduce redundant data entry. However, at FCPS, enterprise applications have been integrated for many years. The challenge for FCPS is that the integration architecture devolved to a point-to-point architecture, also known as spaghetti architecture.
This article describes the evolution of FCPS applications -- from the spaghetti architecture, to a brokered architecture based on Web services and the webMethods Integration Platform. This effort recently culminated in the deployment of a new summer school application that integrates with five other applications.
FCPS started this re-architecting effort by forming an Integration Working Group (IWG) composed of technical leaders representing the enterprise applications. The goals of the IWG were to:
-Establish a scalable architecture for sharing data and services among applications,
-Provide Web access to integrated data and services, and
-Seamlessly provide data and services to work processes and eliminate dependency on paper forms.
IWG's first task was to gain an understanding of relationships among the many enterprise applications.
To understand the architecture, the IWG analyzed each application, the interfaces among them, the data shared and the application's status.
This analysis highlighted several concerns. At one time, a legacy student application, Central Student Information System (CSIS), was acting as a hub among many applications. However, as time moved on and deadlines passed, FCPS implemented many point-to-point interfaces. The resulting architecture became very difficult to maintain.
A greater concern was that CSIS was based on an old HP 3000 that would no longer be supported. Thus, CSIS must be removed without adversely impacting the other applications.
Based on the understanding gained by this analysis, the IWG could define a solution.
A Better Way
The IWG determined the best approach would be to incrementally migrate toward a brokered architecture.
In the brokered architecture, each application communicates with the broker, who directs communications and transforms data.
The brokered architecture has the additional benefit of isolating the impact of change. That is, an enhancement to one application need not impact the other applications. This was a severe problem with the spaghetti architecture.
The IWG then conducted a market study to learn what leading vendors might have to offer. They prepared a requirements document and proceeded to the competitive selection process.
Adhering to the principle of due diligence, the IWG rigorously evaluated respondents to the request for proposal. The evaluation included an on-site test. The IWG defined the requirements for an integration scenario, created a test environment, supplied the data, and created performance tests. The bidders had five days to implement a solution and execute the performance tests while the IWG observed.