Refrence Data

[dsemeniuk]

This kind of covers Change and Config together but how are people tracking changes to Reference Data?

What type of CI would this be captured under?

We have data that is called Reference Data that helps support some functionality and GUI displays of applications. We know this is data that resides within a database schema within a bunch of tables, which we do have as a CI (Schema) already but we want to separate the Ref Data out into something that can be tracked as well and versioned.

We just don't know how to group or name specific areas of ref data yet.

Anyone else doing this?

Thanks.

[Guerino1]

Hello Dsemeniuk,

We, ourselves, have a very flexibly and powerful metadata design platform, where things like reference data be created and tested, live, in a development metadata database. However, snapshots of the database need to be taken for frozen Releases. Therefore, what we do is automatically extract a frozen view of the metadata, in ".dat" files, that are used to automatically load/initialize the runtime databases that get built in each environment, as the application gets promoted between them for testing or rejected back because of test failures. These ".dat" files are versioned and stored, both, in the DSL and in the Source Code Control System. The build is structured to be versioned, based on our own change tracking solution. When the build is executed, it can create any snapshot of a build version and, therefore, can pull in whatever state of metadata is needed for that build. So, in short, we version our metadata (including our reference data) using files that get stored in our Source Code Control and DSL systems and get leveraged by our Build, Deployment, Installation, Instantiation, and Execution systems.

I hope this helps.

My Best,

Frank Guerino, CEO
TraverseIT
On-Demand ITIL

[alphasong]

It sounds like by reference data you mean 4GL definition data (e.g. Oracle Forms, PeopleTools, the SAP control tables, or the Remedy ARS control tables). That should *definitely* be under change control, as it is essentially a form of scripting language.

Reference data can also include things like lists of codes that are business process critical and infrequently changed. Malcolm Chisholm wrote a good book on this type of reference data, available on Amazon.

Whether this kind of reference data should be under change control is a controversial question. It depends on the scope of your CAB and the expertise represented there; you would certainly want your data architects to make the recommendation.

I remain cautious of expanding CAB scope too far into business functionality. While it is true that changing core reference codes (e.g. for insurance processing) may impact systems negatively, I still see such changes as essentially a business process that should not be handled by the IT-centric change process.

If you have issues with systems being tightly coupled to specific data code values (outside of the 4GL problem domain) that is an architectural issue indicative of poor development practices. Other than 4GLs, deleting a reference value in some database table should *not* cause systems to crash. If it does, the system was very poorly designed.

HTH

charlie
_________________
Charles T. Betz