IE 11 Not Supported

For optimal browsing, we recommend Chrome, Firefox or Safari browsers.

Utah Courts Reengineer Case Management

Reengineering their case management system helped Utah courts improve performance and efficiency.

Nov 95 Level of Govt: State. Function: Court Management. Problem/situation: Utah needed to improve the performance and efficiency of its court system. Solution: Hard work, careful planning and a new case management system. Jurisdiction: Utah. Vendors/Products: Pentium, Wang, Hewlett-Packard, Informix, Oracle, Novell, PowerBuilder, Intel, Sybase, Contact: ?

By Bruce Gavin Contributing Writer Some folks may not believe that hard work and careful planning will get them into the winner's circle. But when the Utah state courts used these methods, they crossed the finish line way ahead of second place. In January 1992, the mandate came down for the courts to "do more with less." The data processing (DP) group began the task of reengineering the Courts' Case Management system. The main objectives were to improve the performance and efficiency of the system and reduce computational costs. In February 1992, just one month into the Case Management system overhaul, a new priority developed. The Utah state Legislature passed a bill that centralized the creation and maintenance of the juror selection list. The law shifted juror list responsibility from the individual counties to the Utah Courts' System. Due to miscommunication, the new requirement wasn't given to the DP group until April, two months later. The law required the juror processing system be in operation by July 1, 1992. This left only two short months to create and implement the new system.

Making it Happen To meet this critical deadline, MIS Director Rolen Yoshinaga brought in the heavy artillery. His development staff called upon PowerBuilder and its Rapid Application Development (RAD) technology to create the initial juror list databases. These interim files served as design models for the Informix database. When development was complete, the final Informix 5 database was constructed from voter registration and drivers license data. It runs on Hewlett-Packard 9000 series UNIX-based servers connected with a TCP/IP network. The entire database migration from PowerBuilder to Informix was completed in a week. "With the PowerBuilder application, we just switched the xBASE hooks for Informix hooks," Yoshinaga noted. "We configured our application to work in the new environment in one week. That's a process of changing our DBMS and network system that usually takes months. The PowerBuilder application came right up, never missing a beat." Yoshinaga expressed a high level of satisfaction with PowerBuilder. Combining a PowerBuilder client with the Informix server eliminates the "fat client" that requires a Pentium-class machine. Most of the processor-intensive work is done by the Informix back end. A modest 486 client is fully capable of handling the front end presentation chores with the database. Yoshinaga estimates 70 percent of the business rules reside in the Informix back end. The remaining 30 percent are in the PowerBuilder client. Because of its many enhancements, the DB group plans a direct migration from Informix 5 to release 7. Although Sybase and Oracle also bid on the project, Informix received the contract. When asked about the deciding factor, Yoshinaga summed it up in a single word: "service." He was very satisfied with the support he received from the Informix consultants.

Rewriting the Old After successfully meeting the July 1 deadline, the DP group turned its attention back to rewriting the case management system. The old system was a network of Wang minicomputers installed at 40 court locations throughout the state. The COBOL-based application processed every administrative aspect of both civil and criminal cases. The system maintained date scheduling, judge assignments, and records of court proceedings and sentences. Payment and fine collection histories were kept for every type of violation, from child support to parking tickets. The old case management system was very time-intensive. It required seven to eight minutes of clerical time to file each of the 400,000 cases handled every year. Another shortcoming was the inability to share data between the different counties. Each county was an island of information, known only to itself. A study called Justice in the Twenty First Century provided design suggestions for the new system. One of the primary points was enhancing the court as a service institution by improving its efficiency. It also recommended increasing the public's access to the court system. Voice mail, e-mail, electronic funds transfer, and remote scheduling were other key points. The courts designed their statewide system similar to the branch banking concept. All business not requiring a specific appearance could be handled from any local office. For example, a Salt Lake City resident who received a citation in Provo can take care of it locally. The Salt Lake City office can clear the ticket, conduct any fine payments, and update the records.

Power-Building The old system contained over a million lines of stable COBOL code. The new development tools had to be easy to use for the COBOL programmers. They were familiar with the business needs of the existing applications, and would use that knowledge to design the new system. The development tool chosen was PowerBuilder. With almost 1,000 users, a sensibly priced runtime licensing structure was required. PowerBuilder was the winner in every category. The development team used PowerBuilder's object oriented technology for the maintenance of the look-up database tables. By using inheritance, the window attributes are only defined once, in the initial window. Each of the twenty-five descendent windows inherit the defined attributes of the parent. This saves coding time and ensures the uniformity and quality of the code. As of this writing, the production code contains more than 350 transaction windows. Despite the many windows, the system is very nimble. The most frequently used transactions are the fastest. The most infrequently used functions are much deeper into the window stack. Participating in the joint application design discipline was one of the difficult decisions Yoshinaga made. The design committee consisted of judges, clerks and other regular users. In November 1992, these users locked themselves away for five days and hammered out the design. The programmers' role was restricted to implementing the users' design. The users designed the system, rather than the person who signs the check. The old joke about a camel being a horse designed by committee didn't apply here.

A Solid Platform A good application isn't worth its bits unless it runs on a solid hardware platform. Several mainstream vendors bid on the project. Although pricing was highly competitive, the contract went to Hewlett-Packard. During the 1991-92 bid cycle, HP presented the most clearly focused vision for the project's direction. They were judged to have the most complete integration of hardware and software. HP OpenView network management software was a big influencing factor in awarding the contract. Fourteen HP 9000 UNIX servers configured with an Ethernet-like topology make up the statewide backbone. HP also supplied the non-switching hubs, routers, and the 100VG-AnyLAN high speed NICs used in the network. Instead of using frame relay, the designers opted for multi-channel T1 lines. T1 was chosen because Frame Relay is bursty, and not suited for continuous video transmission. Out of twenty-four T1 channels, data transmission uses sixteen. The remaining eight channels carry video transmissions. Utah Courts use 30 frame-per-second video conferencing for both cost savings and security issues. Transporting inmates between a secure facility and the courtroom is costly. Physical transportation requires additional staffing, wages, and vehicle expenses. The risk of a security problem is much greater. Video arraignment from the secure facility eliminates these problems.

The Beta Version A beta version of the new case management system is operating today. The fourteen servers handle more than 800 Windows-based clients. Windows 3.1 is predominate, with only a few users running Windows for Workgroups 3.11. The average client is a 386-class machine with 8MB of RAM. The Informix database contains more than one hundred tables on 14 gigabytes of disk space. The clients run dual protocol stacks of TCP/IP and IPX that connect to both the WAN and local servers. Novell Netware 3.12 is the NOS of choice for the local file servers. To date, there are no plans in place to upgrade to Netware 4.1. Its NDS services aren't required for this project, and version 3.12 is a solid work horse. Initial testing of Novell's Unixware indicates it works well with both the Informix databases and HP's version of UNIX.

DATA WAREHOUSING Looking to the future, the DP group is exploring data warehousing as a business analysis tool. Data warehousing is different from regular online transaction processing (OLTP). Data warehousing does not use normalized data and is analysis oriented. OLTP is task oriented, and due to its normalized data, is less suited for data analysis. Its strength is record updating and other pre-defined tasks. Data warehousing's non-normalized data makes it ideal for business analysis using deep queries. Using data pivot points, it allows analysis of data from many different viewpoints. Today, the new system is in place and runs well. Now, Yoshinaga's biggest worry is over "things that go bump in the night." From early 1992 to now, it's been a long ride. Hard work and careful planning is indeed the ticket to the winner's circle.