Inter-Model Change Management

I am very excited to be part of the new expert blog for CA. My goals will be to explore the governance and metadata aspects of data modeling. These areas present a series of challenges that we will have to overcome in order to move data management to higher levels of maturity. In the previous stages of data modeling the challenges were different, as I remember from playing a small part in the early days of ERwin. During that period we had to establish the value of data modeling and, indeed, data management as a whole. Today there is a realization that data represents huge potential for enterprises, but is mired in problems that are difficult to understand, let alone solve. I am convinced that data modeling is one of the competencies that will get us out of the present difficulties, and in this first blog I would like to begin with a brief overview of change control for models.

Inter-Model Change Management

As enterprises move to integrate their data assets, so there is an increased need to integrate data models. Once upon a time data models were as stand-alone as the silo databases they were being used to design. Today, there is much more of an expectation that there will be integration between data models, and this means that if one model changes, others will probably need to be changed too.

One way in which this is fairly obvious to see is down the hierarchy of Subject Area Model, Conceptual Model, Logical Data Model and Physical Data Model. There is usually one Subject Area Model per enterprise, and if this changes it will likely impact at least one Conceptual Model. My preference is to have one Conceptual Model per Subject Area, but even then I have found that a change to a Subject Area Model may sometimes impact several Conceptual Models. If a change occurs to a Conceptual Model, then one or more Logical Models will be impacted. Finally, if a change to a Logical Model occurs then a corresponding Physical Model will have to change too. Personally, I prefer to combine the Logical and Physical in one model, but I realize there are many modelers who do not like this. However, there should only be one Physical Model per Logical Model.

For changes to flow down from Subject Area to Conceptual to Logical to Physical it is necessary to have some kind of traceability for each data object in a model lower in the hierarchy to a corresponding data object in a model higher in the hierarchy. The problem is that modelers often tend to produce the models as stand-alone and do not include this traceability. Of course, not every data object will have such a linkage. For instance, an attribute in a Logical Model will very rarely be directly related to a concept in a Conceptual Model.

I do not think that it is a huge amount of additional work for modelers to include these linkages, and they make the task for change management between models a great deal easier. This is particularly true if metadata can be extracted from the models and put in a repository where reports can be run to list out the linkages. Today this is fairly easy to do.

Besides the hierarchy just mentioned, there are others. A particular favorite of mine are the linkages between ER models for operational databases, ODS's, MDM hubs, and even data warehouses, and the dimensional designs that are used for data marts. If a change occurs in an "upstream" ER model it is important to know what "entities" will be affected in the models for data marts. It is much more effective to work this out in the models than to put the changes into production databases and see what happens next. Again, therefore, what the modelers need to do is maintain the linkages between the data models concerned.

Many years ago the promise of the single Corporate Data Model was held up as a major reason for doing data modeling. It did not live up to its promise, and there was a tendency to fall back to standalone models. I still think that the Corporate Data Model is a difficult exercise to carry out, but we need something to answer the very strong demand for data integration in today's enterprises. Carefully maintaining linkages between data models to meaningfully federate them and facilitate accurate change management would seem to be an option that should be carefully considered.