This is a slight detour off my anticipated series of blog posts... but I have been inspired by John Reilly’s comment on my last posting and felt that there is an important message that any one new to Frameworx must understand:
“There is no absolute truth in SID!”
This is a bit shocking (at first); after all, the role of an enterprise data model is to provide a single point of "truth"; to define exactly what classes/entities/concepts, the "things are of significance to the business, about which information is held" (to quote Richard Barker ex of Oracle and author of some excellent books on data modelling) are and to provide a
- rigorous,
- unambiguous,
- easy to understand
definition of each concept/entity/class (hmm, the SID could do with some work on some of its definitions which fail, ‘big time’ to meet these criteria).
So how come there is so much debated about what the SID means? As John Reilly pointed out in a comment on my previous blog entry, there are two interpretations of what a Customer Facing Service is, and this is not the only area of interpretation and debate as you can tell if you follow the comments in the TM Forum community.
The problem is not caused by definitions of the classes no matter how good or bad they are. The problem that the SID has got, in common with any other good canonical model, is that, as Abraham Lincoln said:
"You can't please all of the people all of the time"
Canonical, basically means flexible, and the very flexibility of the model allows, and in fact, encourages different interpretations. That is not a weakness, it is a strength and makes the SID a very powerful tool. The SID has to be interpreted because every enterprise is different and operates in a different market with different products/customers/regulations/competition/management. The SID has been defined to support every possible nuance of the Communications industry, and so there is bound to be different ways of using it and interpreting it, again this is a strength and makes SID powerful.
But, the problem with any powerful tool is you need to know what you are doing when you use it, or someone could get hurt. The SID is not a substitute for thought, or experience; you need to think hard about how you are going to implement SID, and what interpretations of model you are going to adopt and then document these and make sure everyone in your organisation understands your interpretation of the SID. To quote an old friend of mine:
"A fool with a tool is still a fool"
You must not be foolish with the SID. If you are you will fail and the systems you build with it will be as complex and as difficult to maintain as the legacy systems you replaced.
So how do you go about being wise? First of all realise that using SID "out of the box" will be difficult, if not impossible. You need to ask yourself "How and why are we going to implement SID?" I have often asked or been asked this, and have even thought about building a SID implementation methodology, but I have always 'run out of steam' or time and, to be frank, experience of enough different SID implementations. However I can share some basic principles based on my experience that anyone starting a SID implementation ought to follow.
1. "Education, education, education" to quote Tony Blair, a former British Prime Minister. Don't even try to understand SID without getting some proper training. I know this to be the case, as I did it the hard way. I struggled with the SID manuals and model for about 6 months before I truly understood all of it, and I’ve had a lot of experience with other Enterprise models. Don’t think because you can read a data model that you can understand SID without training.
2. Define why you are using the SID. What is the SID for in your organisation? Is it a model to be used to define the information in a particular application? Is it the 'language' to be used over the ESB/SOA? Are you focused on the Network side or the Customer side of the business? This will help you make some of the decisions about how SID is being interpreted. For example, if your business focus is Network Management, and perhaps ITIL then the 'bottom up' (2nd) interpretation of CFSs may be more useful than the 'top down' (1st) interpretation.
3. Get some experience. Even the best training course (like the ones from the TM Forum) is only going to be an introduction to the complexity of the SID. It will teach you how to understand the SID, and introduce all the Domains and important top level ABEs as well as drilling into the Party, Product, Service, Resource and Business Interaction ABEs, but when you get back in the office you are going to need an experienced guide to ensure you don't get lost and to help you when you stand at a decision making crossroads to pick the right direction - for your organisation. Where do you go to get this help? From the TM Forum Community! Don't be scared to ask questions! Otherwise think about getting someone in for a few days or weeks to help you launch SID in your business.
4. Concrete the abstract. SID is full of 'abstract classes'. You should review these and where necessary make some local concrete sub-classes. Why do this? Well it helps regulate and document these and allows the less data model minded to understand the model more clearly with concrete examples. There has been a lot of discussion on how to do this in the TM Forum Community postings, around Party Role for example. The bottom line is that you must make the SID your own. Create a new “Acme Telecoms Information Model” for your Acme Telecoms company that is an implementation of the SID model with your concrete classes, your extensions, your new classes. You will be creating new classes and making extensions to existing ones and improving the SID class definitions to meet the three criteria I listed at the start of this post (I hope). You must understand that all of these activities are allowed, expected and are probably mandatory (another blog post on this subject in the future... I promise).
5. "Education, education, education". You must educate the implementers of the SID. The people building the new app, or defining and building the ESB. They must understand SID and how you have implemented it. You should hold formal training for these people. It doesn't have to be a long class you can probably get the message across in a day or less. Then you must of course follow up and help these teams with all the design decisions and the data mappings they are going to have to do (again another blog on this subject in the future, I think).
6. "Education, education, education". The SID is a new way of looking at the business, part of the "New Generation Operation Support Systems" you are implementing. If your business users and managers are still living in the "Old Generation" world then you are going to have significant problems. You must introduce the Frameworx Customer-centric approach, the new product modelling approach, the account focus, the Business Interaction focus all or some of which are going to be very very different from the way your organisation used to work - which is why you have starting to use SID in the first place. Understand you are going to be taking important business leaders out of their comfort zone. They have used the old Billing/CRM/NRM systems for years; the corporate language reflects the way these systems work, and unless you change this language and open the business leaders minds to the new way of looking at their business you are going to have significant problems during the training and acceptance testing phases of your project where they or their staff will say "...but, this isn't how we do things here!".
I'm sure there are other things that must be done... but if you do these things then you are at least moving in the right direction.
