Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 30
Improving State Voter Registration Databases: Final Report 4 Sustainability and Long-Term Funding Because the underlying information technologies will certainly improve significantly over the life-time of a system’s development and deployment, it is desirable to plan for the eventual incorporation of these improvements. Systems designers must thus pay particular attention to three areas: Sustainability of the technological environment selected. Technology selection and migration strategies have significant implications for sustainability. Initial choices of technologies from which systems will be built have long-lasting consequences, because they in effect freeze an enterprise’s infrastructure. It is therefore important to select mainstream, broadly used platforms. But because the information technology industry is so dynamic, even broadly accepted technologies may later be abandoned by the marketplace. As a result, for example, a company that in 1985 had selected CP/M as its basic operating system would have had to convert long ago in order to remain current. Because maintaining applications that run on platforms based on an abandoned technological substrate is in the long run a very expensive task, applications developers must have migration strategies to port their applications to new technological environments when the old ones become too expensive to use. These comments are not intended to suggest that developers should abandon current systems in favor of the very latest technologies—it is prudent to select relatively stable technologies that are achieving widespread adoption and are likely to enjoy longer-term support. Indeed some old but previously mainstream technologies continue to be supported by vendors because their widespread use keeps them a profitable business. Backward compatibility. To at least minimally protect investments in design, applications, and training, and provide at least a limited measure of interoperability across versions, commercial information technologies usually incorporate considerable backward compatibility from generation N to generation N + 1, and usually provide tools to facilitate user transition to the newer generation. However, support for backward compatibility is not unlimited, and at some point, support for the earliest generations is usually abandoned. (Thus, generation N – 3 may no longer be fully supported.) Indeed, given the rate of evolution of the processing and storage capabilities of the underlying commercial technologies—and the advances in applications that these improvements enable—it is unrealistic to maintain backward compatibility forever. Election officials will have to provide guidance to system designers for how long backward compatibility for both platforms (e.g., underlying relational database systems) and applications (e.g., VRD compatibility with nonelection systems, such as DMV or SSA databases)
OCR for page 31
Improving State Voter Registration Databases: Final Report 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
OCR for page 32
Improving State Voter Registration Databases: Final Report Technology renewal and refresh. Given the rapidity with which information technology evolves, voter registration systems will inevitably have to migrate to new platforms, because the cost of maintaining an existing platform will eventually exceed the cost of migrating to a more modern one. As for the magnitude of the funding streams required, one study places the total cost of ownership of personal computers in a work environment at more than five times the acquisition cost,1 suggesting that as much as 80 percent of the initial system procurement cost must be budgeted every year to support nonprocurement expenses not related to data cleanup. Even if the use of more powerful computers and platforms (e.g., virtualized computers) could reduce the total cost of ownership to only twice the acquisition cost (unlikely), it only reduces the annual nonprocurement expenses to 50 percent of the initial procurement cost. These costs do not account for data cleaning, which would add significantly to the total cost of operating the VRD system over time. (Cleaning data to facilitate comparisons with other databases is an essential component of database management. For example, addresses may need to be standardized if jurisdictions are to qualify for certain lower postage rates in their communications with voters—address standardization services are available but are not currently being offered for free. Other kinds of data cleanup may require communicating with individual voters, and so U.S. mail postage is likely to be a significant component of data cleanup expenses.) In short, funding for VRD support will require—every year—a significant fraction of the sums spent for the acquisition of VRDs. The above comments refer primarily to long-term sustainability of existing VRD systems. To implement many of the improvements described in the section on longer-term actions, additional funding may well be required. In some cases, such improvements will require a time-delimited investment associated with initial acquisition and deployment and a smaller stream of funding afterward; in other cases, they will require additional funding on a continuing basis as operating expenses. It is also possible that different kinds of spending will entail different political processes, as budget accounts for computer and system acquisition may well be separate from budget accounts for cleaning election-related data. 1 See John Taylor Bailey and Stephen R. Heidt, “Why Is Total Cost of Ownership (TCO) Important?” Darwin Magazine Online, November 2003, available at http://www.darwinmag.com/read/110103/question74.html.