ng the project leave the DMV? And is there a silver lining in the DMV's current business-process-reengineering project?
On-Ramp to Comp
uterization
The California DMV started computerizing in the late 1960s. Its terminals, located at central headquarters, 172 field offices, and three telephone centers, are all linked to the state of California's IBM 3090-600J mainframe via the state's closed CalLink/CalNet system. Since now-standard transaction monitors, such as IBM's CICS, weren't available in the 1960s, the DMV developed its own, calling it Real Time Control (RTC).
At the same time, the DMV was also running applications on IBM Series/1 minicomputers. The core DMV applications are Vehicle and Vessel Registration, Driver Licensing, and Occupational Licensing. Additional applications interact with other agencies and DMV partners (e.g., insurance companies and car-rental firms). All applications are written in Event Driven Language (EDL), a proprietary DMV language, and all use the mainframe as a back end.
The back-end applications are written in assembly language and COBOL. The database itself is written in VSAM,
and the DMV customized the database index structure in-house to accommodate its evolution from older database structures.
Using EDL and RTC, DMV programmers computerized the DMV's business rules of the 1960s; this included all the paper flow and manual steps required. What may seem a short-sighted way of developing applications today was standard practice then.
Nineties Business, Seventies Computers
Today the DMV is a big business. Its 1993/1994 fiscal-year revenue of $5.2 billion would have ranked it in the Fortune 100. It handles more than 25 million registered vehicles, 24 million driver's licenses, and 94,000 occupational licenses; processes more than 1 million on-line transactions a day; and has business "partnerships" with public and private organizations. One such partnership authorizes auto clubs to issue license plates, stickers, and registration cards to their customers.
The IBM Series/1 computers now represent a functional-but-obsolete technology. They are
no longer sold by IBM, are difficult to get parts for, and have dwindling technical support. Not surprisingly, as the DMV grew, it started shopping for replacements that would continue to deliver subsecond response times.
Growth may be the biggest challenge that the DMV has ever faced. Says DMV spokesman William Madison, "The legislature hands projects to the DMV: driver safety, voter registration, collecting Social Security numbers for the Absent Parent Program [child-support enforcement]. We're the agency that contacts the customer first." The DMV keeps files on 87 percent of the adult population in California. And the numbers keep growing.
Why is growth a concern? Because applications that computerize paper processes don't allow for growth and change. For example, information about a motor-vehicle accident is added as a subrecord to the main record, so separate reports about the same accident (done by the highway patrol and insurance companies) create two accident subrecords instead of one.
Another problem: Since the DMV database is not relational, developers must create any cross-references, such as those between a driver's license number and a vehicle-registration number, with "keys." Some key-handling "overlays" run every time a record is open. For example, if you change the address on your driver's license, overlays run to change your vehicle-registration number, notify your voter registrar, and update the California Law Enforcement Telecommunications System (CLETS). Growth is a big problem for a system not explicitly set up for growth or change.
Shopping for a New Computer
The DMV's technology department, known as Electronic Data Processing (EDP), had been in maintenance mode for years when the time came to find a new system. An EDP group started evaluating and testing new minicomputers and databases. With several technical challenges (listed below), the group arrived at what seemed a logical solution.
Challenge 1:
An in
flexible database structure.
Fixed-length records and subrecords make accurate record-keeping tremendously labor-intensive.
Challenge 2:
Maintenance worries.
Business rules in the Driver Licensing application and VSAM database were in undocumented, unstructured, customized assembly language programs. Modifying, updating, and integrating applications were all slow.
Challenge 3:
Development difficulties.
Software development environments on the front-end IBM Series/1 minicomputer and the back-end mainframe system were dissimilar. The result: new applications were developed outside the Driver Licensing system.
The one sterling quality of the current system was its fast response time. When the project started, response times had increased slightly, but they were still at subsecond speeds. With all the customers at DMV field offices, all the phone calls the DMV handled, and all the business partners that were accessing
the system continuously, maintaining fast response time was critical.
A logical solution: Build a system to replace the Series/1 minicomputers and provide database services, too. The EDP group projected the redevelopment to cost $30 million. After testing several systems, the group settled on a new minicomputer from Tandem: a new system with an untried OS and a proprietary database. The Tandem benchmarked twice as fast as the Series/1, a result of doing fetches against its own database.
In 1987, the DMV awarded Tandem the computer and OS contract, with the stipulation that EDP would create all the applications with the aid of consultants. In 1990, the DMV took delivery of the new Driver's License (DL) systems from Tandem. The DL application is on-line and interactive, and it accesses the mainframe database in real time. The DL system has 14 modules and subsystems, with many interfacing with other systems in U.S. and Mexican states, as well as in Canadian provinces.
The Road Map
Things then began to fall apart. One goal had been to set up a relational database between driver's license numbers and vehicle-registration numbers that law-enforcement officers could check with one query. EDP began by transferring the Address Search module of the DL system to the Tandem computers.
Two hitches quickly became clear. Changing the application and the database without changing the business rules would not support the increasing complexity of the DMV's activities at the desired response rate. And it was going to cost more money to make it work.
Simply moving the subrecords, overlays, and spaghetti code had increased the average response time to 4 or 5 seconds, five times slower than the speed of the old system. In 1992, Tandem and the DMV assessed the cost to complete the DL project properly. The answer: $73 million -- over twice the original estimate.
DMV director Frank Zolin was not happy. He assembled IT (information technology) experts, including Glenn Wilson,
chief of the division of EDP services, to find a fix that would let the Tandem systems outperform the current system and enable the rest of the project to move forward.
Five months later, in March 1993, the team found the fix. However, it would cost $175 million -- more than five times the original estimate. Zolin chose to stop the Tandem development and start looking elsewhere. But his decision called in the government watchdogs. The investigators then called in independent auditors to account for money spent. The auditors found no wrongdoing by EDP and put the project's cost at $49 million.
A Total Loss?
So what happened to the $49 million? Some of it went to pay the people working on the project -- sharp people who discovered a problem that no one had previously known about: You cannot make a new system with antiquated business rules.
The $49 million also paid for computers performing a useful purpose at the
state's Teale Data Center
, where law-e
nforcement agencies can search for addresses and related information. With daily updates from the mainframe database, this system improved the average inquiry-response time from one month to one day.
That $49 million also bought new high-tech driver's licenses, with a magnetic stripe on the back encoding all the information from the front. The new DL application, when deployed, will read card information into the system. Meanwhile, the information is available to anyone with a three-line magnetic-stripe reader. According to Wilson, several California employers now use driver's licenses for employee security badges or time cards.
Rearview Mirror, High-Beam Headlights
"Data is a resource, not a driver, for business,"
says Janis Saxon, newly created
DMV strategic-business officer and liaison between EDP, IS (information systems), and field offices and customers. "We have to look at the big picture. Not only is it technically feasible, but will it make a busin
ess benefit? Will it reduce response time?," she adds.
Saxon and Wilson both point to one beacon -- business rules. Before a new DMV system can come into place and make a difference, the DMV has to redefine its 1960s business practices. The task force for this job is a mix of personnel from different divisions within the DMV. Many members are longtime DMV employees who know what it's like to stand behind the counter and talk to the customers.
In May 1995, The Warner Group consulting firm suggested to the DMV a standard business-reengineering plan consisting of three phases. Phase 1 is to analyze current business processes and identify target processes for redesign. Phase 2 is to do detailed analysis and redesign of those processes identified in Phase 1. Phase 3 is to implement the redesigned process.
To reduce risk and costs, the DMV is
committing to one phase at a time
. Phase 1 will last from six to eight months, with some small, but critical, projects to prove that
it's the right approach.
Road Fork: Technology or Business Rules?
The DMV's decision to forestall technology and redesign its business is unusual, if not risky. The DMV has many business partners; can it afford to stand still as its partners update their own technology and the total computer environment changes?
"Architecture doesn't matter to me," says Saxon. "What I care about are the benefits." Benefits are important goals for Wilson, too. And EDP has started working to deliver a big benefit-oriented service: making the DMV more accessible.
Currently, most contact with the DMV is done through the mail, and the system is amazingly efficient. By color-coding and routing, the DMV handles mail rapidly and deposits most checks the same day it receives them. But mail requires manual handling. The DMV now has an Internet location, accessible from the state of California home page (
http://www.ca.gov/dmv/
), where you can find information and even download the
DMV Hits Pothole
