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...
