Friday, August 30, 2013

The Achilles' Heel of Data Modeling Standards

The benefit of a data standard is obvious - being able to share and exchange information and integrate business processes in both early and later stages of a products lifecycle is a tempting thought. It also addresses challenges that are high on many executives’ agenda.

Taking standards into an everyday perspective you see the benefit of it in for example electrical sockets. It is also a good example of how hard it is to unite around something as there are different standards of it across the globe. The biggest advantage with a standard is not that it is optimized or perfect; it is that it unites.
Data Modeling Standards has one Achilles' Heel - one has to map the clients business models into the standard model in a consistent way. It is actually the purpose of the standard - same thing should be modeled in the same way independent of source or organization. This is key to success for both the standard itself and the actual implementation of it at a customer.
So let’s try to digest that statement.
If we have a standard which is semantically covering the complete definition of a certain thing, leaving no room for flexibility, there shouldn't be any problem, right? This requires that the area of the standard is mature. An example of such a standard would be STEPs AP214/AP203 (ISO 10303) which covers CAD geometry.
But what happens if you look at standards which are more open for interpretation such as PLCS (ISO 10303-239), or ISO 15926? If it is open for interpretation it can be "misused"; missing the goal of the implementation completely as the intent with the standard is to enable data exchange through the use of a neutral format. But if the same thing is modeled differently we suddenly find ourselves in the normal integration trap with multiple mappings to get to a consistent, homogeneous and coherent information set. Standards like these basically requires that you either have a developed agreement how to apply it for a certain item and business process (in PLCS case a DEX) or that one uses people who more or less embodies the standard and knows by experience how it should be. An alternative is to use a more industry specific standard which thereby is more semantically meaningful and less "error prone".
Taking the road towards standardized data exchange is an easy pick if you do it in a mature area, such as CAD geometry, which has a stable foundation in a standard. But when it comes to jumping on (standard) trains less traveled one should really understand the potential pitfalls in that specific area that one is looking to standardize; the maturity of the standard and its usage, and really understand the reasoning behind the standard and also your own initiative.

Robert Wallerblad