Versioning data models; it's not just the model that counts!

At the risk of repeating things I've covered in previous posts, one things that I'm often involved in is the question of versioning policy for UML data models and XML schemas. Now, the policy "question" is usually about how you can make changes (usually additions) to a model/schema with minimum impact on applications which use the model/schema, and ideally with zero impact on applications which can legitimately ignore the changes.

This all sounds reasonable, but the problem is that when these policy decisions are made, they are often done is a way that is almost sure to fail. Why? Well, the problem is that people often treat this as a model/schema issue only, as though some particular versioning approach in the model/schema alone is going to be the silver bullet that smooths out all of the potential downstream issues related to model/schema changes. However, it just doesn't work that way.

You can't have a workable policy on managing data change unless your applications are part of that same policy. There is no silver bullet that can work regardless of how your applications have been written. To go back to the relational database example that I sometimes use, in the bad old days when code generators wrote code that was tightly bound to each table and column in a database, database changes almost always broke the applications that used the database. The situation with databases is very different now, because most people follow the policy of interacting with their relational database via SQL (often using ODBC/JDBC), and that SQL layer (when properly used) provides sufficient decoupling to help avoid a lot of potential downstream issues, especially when all that has happened is an addition to your data model.

By contrast, with XML, most applications do not routinely access the XML via an XQuery or an XSLT transform, or via some other layer which would provide the same level of indirection and decoupling that SQL does for relational databases. Instead, a lot of use is made of XML schema compilers, which do the same tight binding that the old relational database schema compilers used to do, with all of the same downstream data change problems.

This is why versioning policy has to apply right along the data processing chain. You need to have good versioning policies for your models, but that alone isn't enough. You also need to have application design policies that match your model/schema policies so that the sum of the two is a robust approach to data change management.

After all, there's no point in building a bridge that only goes half-way across a river, is there?