When every change requires a pack of programmers, you can't be nimble. California DMV took a more flexible approach.

InformationWeek Staff, Contributor

December 23, 2004

6 Min Read

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.

To automate as many as 475,000 vehicle registrations a day, the California DMV designed this streamlined process for calculating fees. Flexible, easily changed business rules for the red boxes and blue vehicle types are delivered through Fair Isaac's Blaze Rules Engine. The project eliminated time- and labor-intensive development in two separate legacy systems.

VEHICLE REGISTRATION FEES RULE FLOW

DRIVING FORCE

The Lesson: Too Little Time for Two Big Changes

Project leaders at The California DMV knew they were crossing a new frontier when they chose rules technology to eliminate legacy system programming delays, but in fact they were approaching two new frontiers.

"One major lesson we learned is to allow more time in the schedule," says data processing manager Jerrianne Seitz. "The project was underscoped."

The move to a rules-based approach was challenging enough because it required a new way of thinking. Extracting rules from code buried in two legacy systems proved impossible, so the agency had to create a business rules discovery process. "We brought in businesspeople, who ended up writing the rules from scratch," Seitz says. "IT then did the analysis and design."

The core project team includes two developers, an analyst, a senior programmer/consultant and Seitz on the IT side, and three analysts from DMV's Registration Operations Division on the business side.

Although the original feasibility study addressed only business application issues, the project crossed a second frontier when, in late 2001, the DMV changed architectural requirements and specified a centralized, service-based approach. This introduced the complexities of infrastructure deployment, in this case an IBM WebSphere J2EE application server, on top of the business application efforts.

In hindsight, the infrastructure change could have been handled as a separate project, Seitz says, but the double effort is now paying off in two ways. First, business managers and analysts can change rules quickly to make state-mandated policy and fee changes. Complex, time-consuming programming in the legacy systems is a thing of the past. Second, the centralized, service-based approach brings the DMV that much closer to modern systems that will ease public access via the Internet. (In fact, the DMV has implemented online registration through a separate project that took advantage of the application server.)

"We now have a fee computation service that can be called in many different ways," says senior programmer/consultant Alan Demmin. "In the future, we may implement pieces of the legacy systems in a Web-based architecture, and these services will plug right into that." —D.H.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights