These thoughts represent very high-level, CIO-ish thinking. I say this out of respect for Gov. Gavin Newsom's DMV Strike Team, who are just starting to engage and make plans. They may well be way ahead of me here.
There is a general feeling that modernizing the DMV is a colossal task. I’ve heard folks suggest that it is a problem that will take years and cost half a billion dollars or more. I do not see it that way.
The reason it is seen as a giant, expensive problem is that it has historically been so. Building it in the first place was a huge endeavor, and attempts to extend and modernize in the late 1990s were risky and expensive. Still, technology has advanced dramatically.
In 1990, building a 1 TB database was at the edge of what was possible. Today a 100 TB high-volume database is not difficult to deploy. In 2000, to build a system that could handle the transaction workload of the DMV was technically challenging. In today’s Web-scale and cloud-enabled world, systems this size are commonplace. The historical perspective is just not relevant if we utilize modern software engineering and cloud infrastructure. The technical risk associated with the scale of the DMV applications is significantly reduced, even eliminated.
Still, we can read in the papers of struggles in moving the DMV technology forward. There are two reasons for these struggles.
First, we need to see the systems that drive the DMV as at least three significant applications: a driver's license application, a vehicle registration application, and an identity management application. I understand that there are other applications including law enforcement, but these derive from the three fundamentals.
It is the ID management application that is currently at issue, as the state works to securely and accurately recognize and identify citizens and provide them with a tamper-proof means of proving who they are. We need to recognize right up front that identity management is not an integral part of the DMV mission. The DMV requires identity management, as do many other state agencies. I believe that the state needs to develop a general, trusted identity-management system that will be shared and used by all of the agencies that store data about individuals. If you look at places like Estonia, where the government strives to deploy extremely modern systems, identity management is at the core of every digital service.
I have no strong opinion as to whether the DMV should own the development and operations of such a statewide service; there are some solid arguments for and against this.
It is worth noting that the federal government has multiple extensive initiatives ongoing to try to solve this problem across all federal applications. The Centers for Medicare and Medicaid Services (CMS) is implementing identity management to manage access to health-care applications. The General Services Administration (GSA) is building Login.gov to control access to all federal websites. These examples reflect the requirement for a general capability. They also suggest the opportunity to borrow and build upon existing software.
The second issue is related. If we see identity management as a DMV-only requirement and tack it on to legacy DMV applications, we miss an opportunity to modernize and build it right. I recognize that time constraints are driving the implementation of Real ID and that a tack-on may be the expedient path, but if we utilize existing public code and build a digital service that can be used by the DMV's Real ID application, we may end with a better result.
This second issue is part of a much bigger problem associated with all IT modernization. If we try to extend our legacy systems incrementally, then at each step of the way we have to take on significant technical risk and expense to integrate the modern systems and modern architecture to old legacy systems and batch architecture. Please do not underestimate the challenge here. Often, modernization fails not in the development of a new system, but in the attempt to integrate the new system with the legacy. Often the smallest risk comes with the least amount of integration and not in incrementally modernizing in small pieces.
To summarize: We need to realize that the business processes of vehicle registration and driver's license administration are no longer giant engineering problems. Modern software architecture and cloud computing make the problems tractable. Identity management is a third, separate process, one that needs to be developed for use across many state applications, and not embedded in the DMV application portfolio.
The cost of modernizing the DMV portfolio is not $1 billion. Modern technology has made the hard problems tractable. We need to avoid the risk of complicating the job of modernization through a long and risky series of small projects, each of which must interconnect the new to the old. This incremental integration adds expense and risk.
In the next post, I'll suggest an innovation. The reason for the suggestion will be to introduce how open source software plays a role and to show once again an example of how software engineering best practices might change the costs and risk associated with modernization.
