are to be maintained, if at all, and indicate a strategy for defining, batching, and sequencing system upgrades. In general, configuration control is required to provide operationally required interoperability and minimize deployment and training costs. The problem is made more difficult when the rate at which enterprise-wide upgrades take place is much slower than the rate of progress in the underlying technology.
Uneven rates of modernization. Technology renewal and refresh for a widely deployed system rarely take place at a uniform rate at all installations. For example, County A in a given state will obtain funding for such purposes 3 years before County B, and thus will upgrade its configuration much sooner than County B. Depending on the nature and extent of the county configuration upgrade, there may be no impact on the county-state interface—this, of course, is ideal. If the upgrade does affect the county-state interface, there emerges a deeper technical issue than backward compatibility—managing and handling a new county-state interface with County A and the old county-state interface with County B means that everything from help desks to software interfaces to operating procedures may need to account for the differences in these interfaces, thus entailing greater support costs than if these differences did not exist.
In this context, configuration refers to the combination of the VRD application and the underlying platform on which it runs. Simultaneous technology renewal/refresh avoids these operational problems and the expense of supporting multiple configurations in the field. But it is very difficult to ensure the simultaneous deployment of a new configuration across a large organization. In states that provide counties with VRD applications (call these states Type 1 states), coordination of the deployment of new VRD applications is likely to be possible. But in states in which counties develop VRDs on their own and feed data to a statewide VRD (call these states Type 2 states), statewide coordination is likely to be virtually impossible. Furthermore, all counties face the question of when to upgrade the base platforms that run applications—and states rarely provide support for such upgrades.
As a practical matter, these observations suggest that all statewide VRD designers will have to support multiple underlying platforms. Also, in Type 2 states, statewide VRD designers must publish clear and complete standards for data exchange that provide guidance to county VRD designers so that new versions of county VRDs are compatible with the statewide VRD. Type 1 states would be well advised to roll out VRD upgrades simultaneously to the extent possible. (These comments are not intended to suggest that it is desirable to deploy for immediate use a new version of a VRD all at once in a “big bang.” Indeed, rolling out a new version of a system on a small scale (e.g., in a few jurisdictions) in order to shake out operational problems is often a sensible step to take before large-scale deployment. But at the very least, operational testing and shakedown in such an environment should be part of a deliberate plan to introduce a new version widely. Such a plan might require simultaneous support for two versions for a short period of time, but at least simultaneous support would not need to be continued indefinitely.)
The Help America Vote Act provided a substantial one-time infusion of money for states to acquire modern information technology for supporting election administration, including the statewide voter registration systems that have been deployed. However, all experience with information technology suggests that the initial acquisition cost of information technology is a relatively small fraction of its life-cycle costs. Indeed, after initial deployment, funding streams will be required to support:
Maintenance and system upgrade (keeping the systems running, installing operating system and applications patches to fix bugs);
Applications upgrade (introducing new functionality and capabilities into existing applications in the VRD system, such as those needed to improve functionality or comply with federal or state rule changes);
Training (both for end users of these systems and for new generations of system maintainers trained in the internal operations of the system); and