Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.
NOTE: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
Posted: Wed May 23, 2007 3:50 am Post subject: Refrence Data
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.
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Tue May 29, 2007 12:55 am Post subject:
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.
Joined: Mar 03, 2007 Posts: 33 Location: Minneapolis
Posted: Sat Jun 02, 2007 6:57 am Post subject: Malcolm Chisholm wrote the book
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.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum