New Rules, Agile Government

Combine two ancient legacy systems, hundreds of thousands of daily transactions and demands for more responsive, open government, and you end up with one ugly, enormous problem. Such was the case at California's Department of Motor Vehicles (DMV), which collects some $4.1 billion in fees a year registering the nation's largest population of autos, trucks, motorcycles and watercraft.

One of the DMV's two legacy systems supports in-person registrations at 167 field offices, and it runs on RS 6000 computers in each office and in Sacramento. The second is a batch fee system that handles renewals sent in by mail, and it's deployed on mainframes at the agency's data center in Sacramento (see "Vehicle Registration Fees Rule Flow" below).

Of course, having two separate systems for the same process created redundancies and risks of data inconsistency. Whenever registration fees or policies changed-as determined by the state legislature-two distinct development efforts and two different analyst teams were required. To complicate matters, some of the computer programs had been in place for more than three decades, and thousands of updates and workarounds had been grafted into the code. Even minor changes required extensive analysis and testing.

By 2000, the DMV recognized it needed to move toward a modern architecture that would help meet a goal of embracing eGovernment and offering public access via the Internet. The data processing manager assigned to research the problem (see "Driving Force") soon settled on rules engine technology as a route to better responsiveness. A rules approach would remove the fee computation business logic from the legacy systems, eliminating the redundant development effort and giving business users and analysts a way to change fees and policies without the aid of programmers.

By the end of 2000, the project had been approved, and the agency had selected Blaze Advisor from Fair Isaac as the rules engine. Launched in 2001, the project's first phase involved vessel registrations, which number only 2,000 transactions per day and involve just 150 rules-a fraction of the vehicle volumes. A rule might dictate, for example, that nonresidents pay $37 or that state residents pay $9.

The project team first tried extracting the rules expressed in code in the legacy systems, but it proved too difficult. "Several of us went to the Business Rules Forum in November 2001, and we learned that we were taking the wrong approach," says senior programmer/consultant Alan Demmin. "We had to design the rules from scratch, and that meant we had to learn how to describe the business and organize the rules in English instead of code."

The team faced more delays in late 2001 when the agency's technical standards group mandated a centralized, service-oriented architecture. This meant the rules would have to run on an application server (in this case, IBM WebSphere) instead of local RS 6000s-the right way to go, says Demmin, but the change required a new approach and a feasibility study, resulting in a five-month postponement.

With a revised plan in place, work progressed throughout 2002, with much of the focus on writing new rules for automobiles and all other vehicle types.

"Good rules design dictates that you be as economical as possible," says Demmin. "As you gain experience, you learn to eliminate intermediate rules and get down to a core set that will be easier to maintain." Some projects involve tens of thousands of rules, but the DMV ended up with a concise set of 2,100.

As the rules writing wound down, testing got underway on the vessel registration project, which went into production in March 2003. The rules developed for watercraft became the guts of a fee computation service that is delivered over the network and used by both legacy systems. In an emergency project, the team then created a second service to handle an increase in penalties for late registrations. The legislature had passed the changes in early 2003, but there was no time to make changes in the legacy systems. In the meantime, employees were using time-consuming manual workarounds. The team wrote 20 rules for the new fees, and within one month, the 60,000 or more daily penalty calculations were automated.

The returns aren't in faster transactions, but in faster response times and savings on IT analysis, programming and testing each time fees and policies are changed by the legislature. What used to take months to do in custom modules developed by two different development teams now takes a matter of days or hours for a few business users and IT analysts.

In the last phase of the project, now nearing completion, a rules-based service will take over all other vehicle-type fee computations. The service has been tested to handle up to 400,000 transactions per day, and it's expected to go into production in January.