So What, Who Cares About SID-Based Interfaces?

I mentioned I would be in St Louis the week of 3^rd January and while there I had planned to visit one of my favorite Italian restaurants on the Hill (famous for its Italian eateries) in St. Louis.  Zia’s is the name.  However, distance and weather prevented me from making the trek.  Next time, maybe, but if you are ever in St. Louis, a trip to the Hill should be in your travel plans.  My traveling companion and co-teacher, Pierre Gauthier, said “so what, who cares about Zia’s?”  My reaction to his statement/question was that he hitch-hiked back to the airport!

Pierre and I taught the TM Forum Frameworks Distilled, Information Framework (SID) Distilled, and the TM Forum Interface workshop at a member’s site.  The students were interested in how all the frameworks fit together and how they could be used. Particularly of interest was how the SID and OSS/J Order Management API could be used to support the interoperability of their order entry application with an application provided by a software vendor.

During the course of the training the “So what, who cares about using SID-based interfaces?” question arose.  Not confrontationally, but the students wanted to know the benefits of using the SID in this way.  This question is often asked and certainly does require an answer that justifies this use.  You may be asked this same question, so I’ll provide some responses you may find useful.

In this case, and what often happens, is that there is more than one application that must interoperate with a given application.  This means each interoperating application must understand the given application’s proprietary interface.  This is in contrast to providing a mapping to the SID or expressing the application’ interface in terms of the SID.  So rather than x mappings there is only one, and that is to the SID.  This saves mapping time (x-1), plus the interoperating applications do not have to learn the proprietary interface’s “language”.  Conversely the given application does not have to learn the interacting applications interfaces, which also may not be based on the SID.

However, the SID only provides a framework, not all the attributes contained in interfaces.  So, how does using the SID help with these?  This is a common question, the answer to which lies in the guidelines that have been defined for extending the SID.  Given a set of information requirements and no guidelines, the structure of the resulting extended model developed by multiple modelers would have a small probability of being similar.  By providing guidelines, the resultant model developed by different modelers would be similar.

Sometimes we forget about the standard entity and attribute terminology provided by the SID.  A lot of time can be spent translating terms and lost by misunderstanding terms.  I, for one, had this happen recently with the terms Product, Product Instance and Product Offering.  Some students in class thought Product was the SID Product Offering and Product Instance was Product.  We had quite a time sorting out the differences and the misunderstanding that resulted.  The same thing holds true for attribute definitions, such as thinking ID is a database key rather than a business identifier.  These examples can go on and on!

There are more reasons to care and benefits to be realized.  For example, the SID is well documented.  Often it is a challenge to find definitions for the content of proprietary interfaces.  Hours can be spent trying to find the definition of a single attribute.  On at least one occasion, the documentation happened to be a database analyst, who had to be tracked down.

After I explained all this to the students, the initial question became the statement “now we know why to care”.

My next trip takes me to back to Johannesburg the second week of January 2010 on two consulting assignments.  Hopefully I won’t miss a favorite food two trips in a row!