Most states have been developing or purchasing stand alone application programs which store their own data internally. When it becomes necessary to link one application with another a special linking program has to be developed so that an application program can share data with another. This obsolete system is more costly to maintain than a Relational Database Management System (RDBMS) using SQL (Structured Query Language). A RDMS has a different architecture, an application program does not store its data within itself but rather stores its data in separate relational databases (RDs). All application programs in the system can access any of the relational databases (RDs) as it needs data for running its application. This means that the amount of stored data in a RDBMS is significantly less since it is not duplicated over and over as it is in the old application programs.

First example: in the obsolete system a resident of a state can have his name and address stored in every application’s data that he has come in contact with. That is in: the state vehicle records, the state income tax records, the voter registration records, unemployment records, state higher education records, criminal justice system records, and others. If the person moves to a new address all of these records are obsolete and need to be updated. This where the cost of maintaining the obsolete systems is much more than the single address data found in the new (RDBMS).

The logic of what should go into a State Centralized Data Center’s new relational databases is not always straight forward. But for this example the first relational database (RD) created I would name the “Resident Household RD”. This RD would contain the unique identifiers of a resident of the state: the name, the address, the age, a physical description (height, hair color), driver’s license, social security number, a picture and the finger prints of the person. If the person is not a US citizen the country of origin should be noted. All the state’s application programs when seeking the name and address of a resident would query this RD first to retrieve the data.

Second example: the state Voter Registration application program would query the Resident Household RD first when updating a resident’s voting status. The voting status of the resident would then be processed in the state’s Voter Registration’s application program and stored under the residents name in the state “Voter Registration RD”. Note that this is one of the best opportunities to process a change of address along with the annual driver’s license renewal application.

Third example: a resident applying for Medicaid assistance would need to identify himself by first filling out an application in a state Medicaid office. If the applicant should supply any piece of information on their application form that is different from that in the Resident Household RD they could be arrested for attempted fraud. If the interview is done on the phone to the state Customer Relations Management service and the applicant is suspected of committing fraud. The applicant should be directed to the nearest state office to fill out an application form and upon the submission of the false information be arrested on the spot. If the applicant submits a valid request the information is entered into the Medicaid application program, processed and saved to the Medicaid RD.

Fourth example: a resident applying to Homeland Security for disaster aid could be quickly identified by accessing the Resident Household RD. If the applicant submits a valid request the information is entered into the Homeland Security application program processed and saved to the Homeland Security RD. Disaster aid could be awarded in some cases on the spot rather than six months later.

Note that in each example the application program is completely separated from the RD. This system is much more cost effective not only because the data storage is smaller but also because the application programs can be run on any vendor computer and the computer can be upgraded with out having to rewrite the application or the RD software.
So why don’t all the states use the RDMS? Cost is the reason, none of the current application programs and their attached databases can be used they must be scrapped and replaced by the new system.

In 2005 the Federal Government i.e. Homeland Security put an unfunded mandate requirement on the states to comply with the Real ID system by linking each state’s driver’s License databases into a nation wide system. This initiative has failed because each state has its own unique proprietary Drivers License application programs resulting in a virtual impossibility to link these to a Federal system. With the Resident Household RD implementations in each state the Real ID initiative becomes a possibility. But this is only one part of a state’s RDMS. This is why I have recommended that the Federal Government pay for the development of all of the new state Application Programs and RDs. I am aware of two states Washington and Colorado that are interested in the development of a Centralized RDBMS. They should combine their efforts with funding from the Federal Government in the development of a Centralized RDBMS which could then be made available to the rest of the states. Each state would implement the new systems by bringing up the new application programs and RDs on their new updated computers in a Centralized Data Center facility. The data from the old systems would then be copied into the new RDs and after all tests are completed the old system is then shut down.

See the following articles:
Article 46. Why some Computer System Implementations Fail.
Article 84. The Failure to Manage State Resources due to Obsolete Computer System
Article 102. Government Reform of California Agencies and Commissions
Article 106. Where do the Government Reform Savings Come From?
Article 118. Examples of Cooperative Innovation
Article 119. Not Just Another Grass Roots Movement to Reform Government
Article 120. Collaborative Innovation between States and Federal Government
Article 138. State Information Technology Centralized Data Centers
Article 142. Huge Savings from State Centralized Services