It will be called an accomplishment, if an organization is able to create data standards (refer domain value and data model standards) and the new applications follow those standards. Beyond this accomplishment, there is a question on what to do of the data (like customer master as per the old Customer ID structure) and applications (having data validation rules as per the old rules) which exist and are working on a scattered set of old standards?

Creating a big-bang project of changing the existing portfolio as per the new data standards is not an option many organizations would like to choose. As a data steward, one needs to create a funded road-map for this purpose. Here is the mix of tricks which this road-map can use to make it cheaper and faster:

Ride on the IT business portfolio plan

An IT organization has a list of business application initiatives to be delivered, and they have a budget for it. One can ride on these initiatives. Business which is funding the IT initiative will challenge every penny which is being spent on the purpose other than direct benefit to the initiative. Therefore one has to work on the business case. Our experience says that it is not difficult to create a business case as the benefits are compelling. Other trick is to piggy-back on mega IT initiatives. If the project budget is in millions of USD, the data standards related needs will be a miniscule part. You also should ensure that you are not placing all your needs on a single project.

Identify and focus on the key data elements which are having widest impact

Identify top 5-6 data elements which are most crucial for conversion. You will also see a mention of this principle as we publish our master data management and data integration sections. The criticality is defined on the basis of:

1. The number of applications which are using this data element (product master and customer master are obvious examples).
2. The time and effort overhead to manage the diverse data standards. For example- if you have the same data standard across the applications, you can use a common routine to do that validation. Another example- different offline capture systems to handle different data standards.
3. The data elements which are crucial for your BI environment.
4. Data elements which have greater implications for your business processes. For example- maintaining separate set of data entry forms.
5. Data elements having regulatory implications.

These crucial data elements should be fitting well in your business case, because the criticality is being driven by time and effort saves.

Use BI environment to enforce the standard

Sometimes it does not make a cost benefit sense to do the conversion as per the data standards. For example- many legacy systems, which are built on the proprietary or complex languages, can be costly candidates. In such scenarios, it makes sense to use the extraction and transformation routines of your business intelligence/data warehouse environment for enforcing that standardization. You will not be able to use this standardization for managing your production work, but your analytics and reporting objectives will be met.

Try one go change for an application

As much as possible, try to do the conversion in one go for an application or a set of linked applications. Data conversion is a tough subject and it takes testing and change management overhead for each cycle of conversion. As mentioned above, the best is to club it with the conversion done as part of implementing a new business enhancement on the existing application.