Given SID's size, complexity and provenance it is not surprising that people are nervous about fiddling with it, but it is a "work in progress", so it is inevitable that extensions will be required. Having said that I would always challenge the assumption that the SID needs to be changed - more on that later; after I've explained how to make changes I will discuss why these changes may not be necessary.
I've identified a simple set of modelling rules that should keep you out of trouble when you modify SID as the changes you make if you uses these rules should be the same as the rules used by the SID developers themselves, so that when you get the new release which covers the extensions you made you should find the structures are the same, even if the names are (hopefully) slightly different.
As you get to know SID you will start to recognise a number of "patterns" or conventions repeated throughout its structure. All these rules do is list these patterns and explain how to use them.
Rule 1: Specification and instance
Everywhere in SID you see the word "Specification" - I discussed this in a previous blog. When you extend the SID to cover a new concept then you must consider if it could be implemented as a Specification/Instance pair. The Specification describes the properties that apply to all instances of the "thing" and defines their "type" while the Instance defines the life of a particular "thing". I must admit I find it hard to think of an example that is (a) not already in the SID and (b) not trivial...
Rule 2: Role
The recent versions of the SID have extended the use of the Role concept from Party Role (see my previous blog on this) where it uses a Role to separate the objective (real-world) Party from the subjective view of the Party such as Customer. Now SID has extended this approach to include, for example the roles played by Customer Accounts and Resources in a Product (subscription) through the ProductInvolvementRole concept.
This is a highly generic and very powerful approach that if used properly can make the SID very powerful. I must admit that I didn't use this approach when I first started using the SID and modelled explicitly the specific role played by a Resource, Account and Resource in a Product - while this made the model easier to understand through "concrete" instances it could make it less flexible in the future when new roles for accounts, parties and resources are developed as technology and the business evolves. So when modelling in a new area, such as in the Supplier/Partner Domain you will inevitably come up with the concrete roles played by your suppliers and partners. Having done that you must then think if these concrete roles could be made more generic through a role structure.
Rule 3: Composite/Atomic
Not so much an intellectual technique, more of a modelling convention. Recursive relationships/associations are fairly common both in Telecoms in general and in the SID in particular. In some places the SID has a simple "Pigs Ear" relationship from an entity back to itself to show a hierarchy, but elsewhere it subtypes a concept, such as ProductSpecification into AtomicProductSpecification and CompositeProductSpecification and then had the association from the Composite back to the parent giving the hierarchy. This looks a bit weird, and could be considered to be an idiosyncrasy of the SID, but it is widely used (and it does at least allow you to explicitly identify the "leaf" nodes in a hierarchy) and to maintain consistency with the SID you should adopt this approach.
Rule 4: Attributes vs Characteristics
All the above rules cover adding new concepts or entities to the SID. However quite often all that is required is an extra attribute or two. Even here you must be cautious. The SID has a set of extensive, highly generic structures Characteristic and Characteristic value, for example ProductSpecCharacteristic /ProductSpecCharacteristicValue, ServiceSpecCharacteristic/ServiceSpecCharacteristicValue and ResourceSpecCharacteristic/ResourceSpecCharacteristic which can be used to add information about Products, Services and Resources without changing the model.
It is difficult to define a "hard and fast" rule that defines when these structures should be used instead of adding explicit attributes to the associated entities, but as a rule if the attribute is
(a) of significance to the business - i.e. everyone in the business wants to know the weight of a Resource (unlikely) then add it as an attribute, otherwise use a characteristic and
(b) applicable to each and every one of the instances of the Spec, i.e. every Resource has a weight (unlikely again) then add it as an attribute.
If the attribute is particular to a particular type of Product/Service/Resource then it should be a characteristic, if however it is required as a result of a particular business practice or law in your country, then it should (probably) be an attribute.
If you stick to these rules you should be able to ensure upward compatibility with the SID (providing they stick to them too ;-) ).
Now after giving you the rules/tools to change SID I must add the "health warning"...
Ask yourself "Why am I extending the SID?". If the answer is because the SID hasn't yet defined that domain (e.g. the Supplier/Partner Domain) then go ahead. If it is because the SID doesn't reflect the conventions and laws of my country, then go ahead too (have a look at how Australian addresses have been added to the SID), but if it is because "I can't find it in the SID" and "it" is a common business practice, then STOP! Do not extend the SID! It is probably because you don't understand how "it" has been implemented in SID - Ask an expert (like me) before making any changes.
I will discuss a bit more about tailoring the SID in the next blog...
6 comments:
I note your mantra on specification and instance. Makes sense. Do you map his notion into the relational schema?
By that I mean do you have a (for example) tables for
service_specification
service_specification_characteristic
service_specification_characteristic_value
service
service_order
service_order_item -> references a service
service_order_item_characteristic_value
I have kept the names long to be clear on intent.
service_order_item_characteristic_value are the instance values of various service_specification_characteristic's (joined to this table).
Am I on the right track here. I am building provisioning for 3rd party services at a telco, and new to sid.
The plan is to model products and product offerings, services, product to service mapping and service order being the driver for the provisioning workflow.
Any comments on using BPM for provisioning workflow/orchestration. That has been suggested, I am not an expert in BPM; it looks like a candidate for doing as little as possible in the BPM tool and push as much as possible into enabler web services to me.
Yes you are on the right track. The idea is that by using the characteristics and characteristic values you can create new services with different characteristics without having to change the table structure just by adding data to the Service_specification_characteristic and Service_specification_characteristic_value tables.
Thanks for the comment/question. If there is anything else I can help with then don't hesitate to contact me!
Andrew
hey Andrew,
What approach should be followed to model the gsm architecture. The way I have started is explicit modelling ?
Not sure if this post is still alive and Andrew is still working on this blog, but anyway. My question is, what fields does the service table contain, if I add an attribute (instead of characteristic) should I update the service table then?
Xeujun Li, this decision is at the heart of the problem of extending the SID. If you add an attribute to the Service entity (table) then your model is not longer SID compliant, but it will run efficiently. If you create another entity (table) called "Service_extension" that has a 1:1 relationship/association (same key) as the Service entity (table) then you will have to update/read both to get the full data but your core model is still SID compliant but every time someone finds a new attribute you have to change all your code when you add the attribute to the extension entity (table). The most flexible approach is the name-value pair structure used the the Characteristic / CharacteristicValue structure. This is very flexible, but can be very inefficient due to parsing of the Characteristic name to understand the information held in the CharacteristicValue. There is no simple answer to this.
If you want a high performance implementation that is "SID Based" then extend the base entity. If you want a "SID Compliant" implementation then use the Characteristic/CharacteristicValue structure. The extension entity is a middle way.
Hope this helps!
Sam, there is a lot of work going on in the TMForum SID community to make the SID more mobile compliant. My approach has always been to implement concrete sub-classes of LogicalResource for things like IMEI, IMSI, MSISDN and concrete sub-classes of PhysicalResource for things like SIM and Handset. Some purists argue that SIM and Handset are a combination of hardware and software and should be modelled as CompositeResources, but unless you are directly provisioning the software onto these types Resources they can stay Physical. Hope this helps, and sorry for the long delay in replying!
Post a Comment