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.
This rigorous approach gave FCPS confidence in selecting the webMethods Integration Platform. FCPS selected webMethods for its ability to solve FCPS integration problems, the ease of use of the development tools, and the close alignment of the webMethods and FCPS strategic direction.
Before jumping in and implementing a new, integration architecture, the IWG thought it prudent to conduct an integration exercise -- known as Integration One. The purpose was to establish the hardware environment, establish development practices and gain experience with the webMethods technology.
Working with webMethods consultants, the IWG selected the Sun Solaris platform to handle the high-speed communications of an integration platform. The IWG established development, test and production environments.
The use of Sun Cluster was also critical to this hardware configuration. As a hub for applications, the webMethods platform must be highly available. The hardware and software environment could not become a new single point of failure.
The primary software component was the integration server, which executes Web services. The enterprise server handles message (document) communication, queuing and routing. An Oracle database was used for logging.
With the environment in place, the IWG received on-site training on the webMethods platform. They also selected the project to serve as the integration exercise.
The integration exercise needed to be independent of a critical path delivery to enable a learning experience. However, it also needed to prove that the IWG could integrate information from FCPS enterprise applications. The IWG chose to implement a simple Web application to match teacher information from the student information application with employee information from the human resources application.
Through the course of development, the IWG sought to establish standard practices for:
-Data model design
Configuration management in an integration environment proved to be a challenge. Here the IWG needed to recognize that multiple integrations could progress simultaneously. Furthermore, integrations would advance from development to test to production at different milestones. Thus the environment could not be managed as one would manage a single application. The IWG overcame this challenge by controlling the webMethods environment at the package level for packages associated with a specific integration interface.
Another key outcome was the initiation of a universal data model. In an environment with many applications -- most based on commercial products -- the data modeler's dream of a single enterprise data model often goes unrealized. However, with an integration platform, it is possible to define a common representation for enterprise entities, such as student, employee and teacher.
The integration platform enables a universal data model by transforming application-specific representations into the common representation, which is then made available to other applications. This is key to the reuse of services and data.
The IWG developed the Web application in Java Server Pages for an Oracle application server. When a user starts the application, it invokes a webMethods service that retrieves a list of valid schools from the student information application. When a user selects a school, the application invokes a webMethods service that retrieves teacher information from the student information application and another service to retrieve employee information from the human resources system. The information is then matched and presented to the user.
This simple application provided a valuable learning experience. It also provided a valuable utility for preparing data necessary to meet reporting requirements of the No Child Left Behind law.
Now that the fun was over, it was time to deal with the spaghetti architecture. IWG dubbed this phase of the effort "Integration X," which signifies this was a project of many.
To reduce complexity, IWG organized the effort into eight integration projects and began work on three, with primary focus on the summer school project. FCPS was in the process of replacing this outdated application based on the old HP 3000.
FCPS uses the summer school application to register students, collect fees, develop schedules, take attendance and assign grades. It was a good focus for integration since it interfaces with the student information, library, transportation, food services and special education applications.
One application requirement was for a clerk registering a student to enter the student name or student ID. At this point, the registration screen would be pre-populated with the student's demographic information, which resides on the student information application.
FCPS was implementing the summer school application in PowerBuilder and Oracle. To meet the integration requirements, IWG needed to determine how the PowerBuilder application would invoke the services available via webMethods. IWG wanted to standardize on Web services, however, FCPS was using an older version of PowerBuilder that did not understand Web services. Other choices include COM, Java and C++ for the interface development.
To use Web services, IWG had PowerBuilder developers invoke Java-stored procedures in Oracle, which in turn invoked the Web services. The integration developers created the Java stored procedure by creating the service in webMethods, then used webMethods to generate the Web Services Description Language (WSDL) file. They used Oracle JDeveloper to import the WSDL file and build the Java-stored procedure that invoked the Web service.
Birth of a New Architecture
The request-and-reply form of messaging is appropriate for synchronous communications and lends itself very well to Web services. The IWG also made use of the publish-and-subscribe form of messaging, which for example, triggers an update to the Student Information Buffer when a student's data is changed.
This buffer maintains a current snapshot of student data. The webMethods platform detects changes to the buffer and publishes the data, which is available to any application that subscribes to the corresponding message. Not only does this allow the summer school application to be informed of data changes, but any application that subscribes, such as special education, could be updated as well.
Will It Perform?
With functional and system testing complete, IWG knew the architecture functioned as designed. Whether it would scale to the load that FCPS required, however, remained to be seen. To avoid any surprises in production, IWG conducted load testing, whose environment used Mercury Interactive LoadRunner. The environment was designed to simulate registrations on the summer school application, which would invoke the Java-stored procedures, and thus execute the Web services on the webMethods platform.
In an attempt to find the breaking point in the architecture, the test increased the load incrementally until the load was more than 100 times the anticipated production load.
Results show that the webMethods CPU utilization increased from a 25 percent average utilization to a 55 percent average utilization -- very good given the high load. The results also show that the summer school server reached its capacity when the script reached the peak load.
With good test results, the IWG and summer school teams moved forward with the deployment of the new integration architecture and summer school application. During the registration period, FCPS enrolled over 26,800 students -- more students than most public school systems enroll during the regular school year.
An Unexpected Benefit
During registration, the summer school team realized it did not have an effective means for informing regular school principals which students actually registered for summer school. This is critical due to the short time between when standardized test results are released and the start of summer school. Principals must ensure that students in need get necessary remediation from summer school.
The summer school application was deployed to about 40 summer school principals, but the team had no plan to deploy and train the other 200 principals. This left the summer school team considering whether to print and distribute daily registration reports for all schools, until IWG realized there was a better solution -- developing a very simple Web application that invoked a service on the webMethods platform. The summer school team sent the application's URL to all principals via e-mail. The principals could then log in at any time to see which students were enrolled.
This effort highlighted the potential for Web services, and IWG developed the application in a matter of days. It filled a critical need that was not best satisfied via a major application, and it required no training. Though FCPS operates many applications, there are also many gaps, which Web services can effectively fill.
Integration Is Just the Start
Implementation of the new integration architecture in support of the summer school application was a major stride forward, but there is still much to do. IWG is pursuing the other seven integration projects, but their goal is to go much further.
FCPS uses about 700 varieties of forms, of which it distributes about 9,000,000 per year. Though many of these forms are available online, their processing constitutes a significant manual effort.
IWG's long-term goal is to automate the business processes embodied in these forms. Furthermore, they will tie these forms and process into the back-end systems using webMethods Workflow. Achieving this goal requires an effectively integrated application environment.
There may be much work ahead, but the prospects are excellent.
Ted Davis is the Director of Knowledge Asset Management in the Department of Information Technology at Fairfax County Public Schools. His office is responsible for the enterprise information systems that run FCPS. His office is also responsible for paper records, including paper forms. He can be reached at E-mail.