Those of you who have used PeopleSoft or any of its related on-line functions know that the new system is not performing adequately. Now that most of the critical financial aid and tuition billing modules have been implemented, the Enterprise staff has been able to make improved performance their top priority.

While ESP technical staff is identifying and fixing problems that will bring relief in the short-term, we need to work closely with our vendors (PeopleSoft, Oracle, Sun, IBM) for long-term solutions that will be satisfactory for users.

Staff is confident that the hardware requirements to run our various applications is more than adequate at this time. Problems occur, however, when "bottlenecks" develop -- when the demands of the software overwhelm the ability of the hardware to comply.

A good example is the Web Registration system. One bottleneck appears to come from the process of "querying the database" (SQL). When a user asks for a report on UMD enrollment by class, for example, the application performs a lengthy and unnecessary scan of millions of rows of data. Technical staff are working on a solution which will be tested until the process works satisfactorily, a process that takes about six weeks.

Bottlenecks can occur in several places in the system -- the Web, PeopleSoft panels, batch jobs, Oracle database. That's one of the big problems; there's literally thousands of places to look. So the technical staff must first find the bottleneck that's causing the problem, trace it back to its source, analyze the source of the problem, develop possible solutions, test the preferred solution, and rewrite and rework until the solution works in production.

A good example is the batch process. A batch process enters hundreds or thousands of updates, changes, or additions to the data base at one time. Usually batch processes run at night, but some run during the day because they are integral parts of our business process. An example is a report that is run to assist in cleaning up duplicates in the system. This batch process became another "suspect" for causing poor performance, and to check this hypothesis users were asked to refrain from running it during the day. Performance improved somewhat during this test. Now that analysts have identified the problem, they are re-writing the report program to use fewer system resources.

There are many ways to measure improved performance, some objective and some subjective Staff is developing evaluation strategies that will allow us to objectively measure the impact of our efforts. Right now, our users -- both students and staff -- call Help Desks to report performance problems. Monitors placed on selected PCs, network "sniffers," and various other monitoring devices will give us more accurate and detailed information about nature and location of the problems that users are reporting.

Not all solutions are technical. The Office of the Registrar broke the queue into five daily segments rather than the past three to even out student use of the Web Registration system. Staff knew that most students registered at the very beginning of their queue; now there are more "queue beginnings."

Progress is likely to be incremental rather than dramatic. More dramatic change will occur as a result of some intensive work with our vendors. Over the next weeks, however, we hope to see our users less stressed and our students less frustrated.

Questions? Contact Jude Poseley, ESP Communications, at jposeley@umn.edu or (612) 624-3879.