Model, Database, and API Conformance to the SID

Back from the hugely successful Nice Management World conference, sitting here thinking about Pizza Coco.  It is where, over my last eleven conferences, I experienced some of the best thin-thin crust pizza that has ever made its way into my mouth!  Two ingredients, often missing from pizzas I have had, are a good dose of oregano and an egg broken into the middle of the pizza just before it is taken from the oven.  Pizza Coco doesn’t forget these, egg on demand, however.

Before getting into the main topic of this promised second blog that continues the saga of implementing the SID (here’s the link to the first blog on this subject… http://www.tmforum.org/community/blogs/tmforum_training/archive/2010/05/10/sid-and-database-design.aspx), I forgot an ingredient in the last blog.  It can be essential to a successful implementation of “Characteristics”.  Specifically, it’s about the CharacteristicValue entity.  This entity only has two attributes, value and validFor (from and to effective dates).  Conceptually, the value attribute is only populated when a value is entered for the Characteristic that does not have enumerated values specified.  For example, a userId associated with an email account.  From an implementation perspective, queries are often made on CharacteristicValues.  For performance and simplicity reasons, de-normalizing key attributes from CharacteristicSpecification entities should be considered.  Typical candidates for de-normalization are name, value (from enumerations in CharacteristicSpecValue), and unitofMeasure.  This enables queries to be made on the name attribute and eliminate the need to navigate to CharacteristicSpecification implementation of the SID.

Now, on to helping ensure conformance to the SID, which applies no matter which of the design choices discussed in my last blog are chosen.  Conformance is about equivalence to SID entities and attributes.  You can find out more details about this topic at the TM Forum web page…http://www.tmforum.org/ConformanceCertification/7450/home.html.  Note that the formal certification process deals with APIs, not models or databases.

But, the key word is “equivalence”, whether conformance of a model, database, or APIs is being measured.  While it is good to use SID entity and attributes names, this is not always practical or possible.  For example, suppose the BusinessInteraction entity is collapsed into the CustomerOrder entity.  The interactionDate is now an attribute of CustomerOrder.  However, it can be shown to be equivalent to the interactionDate attribute of BusinessInteraction, from which it originated.  Take the example further, by changing the name of interactionDate to customerOrderDate.  This newly named attribute is still the equivalent of interactionDate, maintaining conformance to the SID.

So, maintaining conformance does not a have to be a complex process.  Remember, though, that it is good to publish a mapping from an implementation perspective back to the SID, particularly for APIs used to integrate applications.

I’ll off on my world travels again the week of May 30^th, so look for the next blog when I return.