I have finally got around to becoming a member of the TMForum.
I had considered joining for quite some time, but the membership fee was a sufficient deterrent to prevent action and to allow inertia to reign. However the desire to have direct access to the resources, such as the SID that the TMForum offer to its members and the wish to tap into a community who are users of the SID and to see if anyone would be interested to hear what I have to say and, hopefully to pay for it finally tipped the balance.
So far, I must say, the experience has been very pleasant, apart from having my inbox flooded by interesting emails from the TMForum Community. I am sure I will refine my interest group membership in the near future to get around this. The biggest pleasure has been the direct contact I have had with the great and the good of TMForum.
First of all I got a phone call from my TMForum account manager. He phoned me to find out about me, my reasons for joining the TMForum and to tell me how to get the most out of my membership. As a result of that call I got an email from John Reilly, who in the SID world is a giant and a guru, inviting me to have a phone conversation with him.
I had the phone call with John last week. He was charming and provided me with useful information on how to become fully involved in the SID in particular and Frameworx in general. John then suggested I might consider putting this blog on the TMForum website!
This certainly has given me pause for thought. I have a quite lot to say about the SID and its use in 'the wild' but could I find something new and interesting to say on a regular basis?
So that's where you, my readers, come in. It would help me if anyone reading this blog to suggest SID related topics or problems that they would like me to explain or explore in the way I have for things like Customer Facing Service, Product and Resource.
I look forward to any comments and I will let you know if I start blogging on the TMForum website.
04 October 2010
24 June 2010
SID V9 and V9.5
Sorry about the long silence. I am very busy working away on a major NGOSS based OSS/BSS refresh project in Ankara Turkey as the SID Data Architect.
I attended (listened to) the TMForum’s teleconference yesterday (23rd June 2010) where John Wilmes and John Reilly talked about the recently released Frameworx and SID Version 9 and the upcoming SID v9.5.
The key topics of the Conference Call were
It wasn’t clear to me during the conference whether the Business Services were in SID, as a new set of classes, or were new external modelling concepts that just used SID ABEs. I asked a question along those lines and John Reilly answered that they were external to SID – at least that’s what I think he said.
SID V9 changes are predominantly brought about by aligning with and consuming the concepts from MTOSI (TMF608). Again I have to withhold my judgement on this until I’ve had a look at the SID V9 in detail, but it does worry me. Previous alignments had done odd things to the SID like making Software Applications a form of Service, when logically to me (and no pun intended) they are Logical Resources. The other change is that SID V9 does not use Rational Rose anymore; it now is supported by Rational Software Modeller. Quite what that means to those of us, including me, who use neither (I use Sparx Enterprise Architect) is not yet clear.
For me the most interesting discussions were around what is in SID V9.5 which is due to be released in Q4 2010. Several concepts new to SID, but not to me are being introduced for the first time including: “User” – presumably the user of an Application making up the Enterprise and “Subscriber” the user of a Product and its “Customer” Facing Services. I always call this concept “End User” as the name “Subscriber” is “So last century”. I wonder if they are now going to rename Customer Facing Services to “Subscriber Facing Services”?
Other useful, and long needed elements are a Customer Payment ABE and a more detailed Product Pricing structure which is supposed to be a lot easier to use than the current Policy structures.
Given the introduction of the Product Pricing and Business Service I had to have a dig at John Reilly and asked my second question about the horrible overly complex Policy and Contract ABEs asking if they would be removed from SID. John R. unfortunately said that they wouldn’t, and that Policy was being extended to cover a new Enterprise Domain ABE called Security brought in from the USA DoD, by all accounts.
I don’t know whether you have looked at the Contract ABE in SID v8. It isn’t what you would expect. The Contract ABE models the contracts between services on an ESB bus rather than the “Business Contract” between the Telco and the Customer which is still mired in the Business Interaction and Policy ABEs.
Quite why SID models Service Contracts a puzzle to me. Surely that is just too recursive to be useful to anyone. The SID only has real use, apart from being an academic exercise when it is used as the structure or “language” for messages being passed between Services in a SOA based ESB. So why would you want to pass messages over the ESB about the ESB? Especially when industry standard messaging tools like Oracle’s SOA Suite and Tibco already do this automatically for you. It is a bit like modelling the entities Table, Column, Index etc. in an Oracle database – these are already present and don’t require modelling.
Anyway, that’s a very brief overview of what was said. I’ll include a link to the PDF of the seminar material when the TMF put it on their website.
I attended (listened to) the TMForum’s teleconference yesterday (23rd June 2010) where John Wilmes and John Reilly talked about the recently released Frameworx and SID Version 9 and the upcoming SID v9.5.
The key topics of the Conference Call were
- Business Services
- SID V9 changes
- SID V9.5 proposed changes
It wasn’t clear to me during the conference whether the Business Services were in SID, as a new set of classes, or were new external modelling concepts that just used SID ABEs. I asked a question along those lines and John Reilly answered that they were external to SID – at least that’s what I think he said.
SID V9 changes are predominantly brought about by aligning with and consuming the concepts from MTOSI (TMF608). Again I have to withhold my judgement on this until I’ve had a look at the SID V9 in detail, but it does worry me. Previous alignments had done odd things to the SID like making Software Applications a form of Service, when logically to me (and no pun intended) they are Logical Resources. The other change is that SID V9 does not use Rational Rose anymore; it now is supported by Rational Software Modeller. Quite what that means to those of us, including me, who use neither (I use Sparx Enterprise Architect) is not yet clear.
For me the most interesting discussions were around what is in SID V9.5 which is due to be released in Q4 2010. Several concepts new to SID, but not to me are being introduced for the first time including: “User” – presumably the user of an Application making up the Enterprise and “Subscriber” the user of a Product and its “Customer” Facing Services. I always call this concept “End User” as the name “Subscriber” is “So last century”. I wonder if they are now going to rename Customer Facing Services to “Subscriber Facing Services”?
Other useful, and long needed elements are a Customer Payment ABE and a more detailed Product Pricing structure which is supposed to be a lot easier to use than the current Policy structures.
Given the introduction of the Product Pricing and Business Service I had to have a dig at John Reilly and asked my second question about the horrible overly complex Policy and Contract ABEs asking if they would be removed from SID. John R. unfortunately said that they wouldn’t, and that Policy was being extended to cover a new Enterprise Domain ABE called Security brought in from the USA DoD, by all accounts.
I don’t know whether you have looked at the Contract ABE in SID v8. It isn’t what you would expect. The Contract ABE models the contracts between services on an ESB bus rather than the “Business Contract” between the Telco and the Customer which is still mired in the Business Interaction and Policy ABEs.
Quite why SID models Service Contracts a puzzle to me. Surely that is just too recursive to be useful to anyone. The SID only has real use, apart from being an academic exercise when it is used as the structure or “language” for messages being passed between Services in a SOA based ESB. So why would you want to pass messages over the ESB about the ESB? Especially when industry standard messaging tools like Oracle’s SOA Suite and Tibco already do this automatically for you. It is a bit like modelling the entities Table, Column, Index etc. in an Oracle database – these are already present and don’t require modelling.
Anyway, that’s a very brief overview of what was said. I’ll include a link to the PDF of the seminar material when the TMF put it on their website.
02 September 2009
Internal Services and Customer Facing Services
Juhi, a reader of my blog on Customer Facing Services, has asked
My very brief reply to the question was:
"When you've got a new hammer everything looks like a nail".
By this I meant that the idea of CFS is so powerful that it looks like it could be used to solve every modelling problem in the enterprise, but should it?
First of all it is very clear to me that a CFS can only exist as part of a Product, and a CFS Spec as part of a Product Offering. This, as Juhi suggests, takes care of all of the "calling services" but there are a range of "non-calling services" that could be part of the Product Offering - these include, for example, guaranteed response times (with SLAs) to trouble tickets, access to a 24-hour help line, dedicated support engineers, dedicated Customer Service Agents, electronic billing, access to private websites where problems can be logged and tracked etc etc.
If it can be sold/have a price associated with it or an SLA then, yes, it is a CFS - this does seem to broaden the scope of the CFS, but to refer to another of my blogs,
"if it looks like a duck, quacks like a duck, walks like a duck - then it is a duck"
and that is the beauty of generic (canonical) data modelling.
However remember that interactions between customers (Party Roles) and the Enterprise are modelled in the SID through Business Interactions (BI) and that there is a Business Interaction Specification structure that shows how the Business Interaction should be handled. Once again the SID provides more than one way of modelling the same thing - you need to make a decision on where you draw the boundary between CFS and BI and document it as part of your SID Implementation project (I must get around to writing up a draft of a SID Implementation Methodology).
But where should the use of CFS stop? What about important business functions that are crucial to the provision of these CFSs. As Johi asks, what about:
I have discussed with a lot of people the idea of a "Business Facing Service" which would be analogous to the CFS but not bundled into a product. This could then be used to model all the vital internal services in the same way as the customer facing services are with Resources and RFSs to deliver them - allowing, for example, the internal servers and software to be incorporated into SID and ITIL. This is, of course, not part of SID, but would make a useful extension to it.
A word of warning however; coming back to my original response "When you've got a new hammer everything looks like a nail"... the SID is a delight, if like me, you are an Enterprise Data Modeller. It has a little box to but every concept/entity into, or could have with a little adjustment and tweaking - hours, if not days, weeks or months of delight for a serious data modeller...
But to what end? Who benefits from all this modelling? Why/how are you using SID? If it is truly as an exercise to build an Enterprise Data Model of your telecoms company, then go ahead, model away - but if you are using it to provide a language for SOA/EAI type architecture - then STOP!
In a SOA/EAI environment it really doesn't matter how this information is modelled - how often is this information going to be passed between one application to another?
"Can you please broadly cover what all services, you think, form a part of CFS for a telecom company, apart from calling services.. Do you think IT, HR, procurement, finance, network management etc. should be included?"
My very brief reply to the question was:
"When you've got a new hammer everything looks like a nail".
By this I meant that the idea of CFS is so powerful that it looks like it could be used to solve every modelling problem in the enterprise, but should it?
First of all it is very clear to me that a CFS can only exist as part of a Product, and a CFS Spec as part of a Product Offering. This, as Juhi suggests, takes care of all of the "calling services" but there are a range of "non-calling services" that could be part of the Product Offering - these include, for example, guaranteed response times (with SLAs) to trouble tickets, access to a 24-hour help line, dedicated support engineers, dedicated Customer Service Agents, electronic billing, access to private websites where problems can be logged and tracked etc etc.
If it can be sold/have a price associated with it or an SLA then, yes, it is a CFS - this does seem to broaden the scope of the CFS, but to refer to another of my blogs,
"if it looks like a duck, quacks like a duck, walks like a duck - then it is a duck"
and that is the beauty of generic (canonical) data modelling.
However remember that interactions between customers (Party Roles) and the Enterprise are modelled in the SID through Business Interactions (BI) and that there is a Business Interaction Specification structure that shows how the Business Interaction should be handled. Once again the SID provides more than one way of modelling the same thing - you need to make a decision on where you draw the boundary between CFS and BI and document it as part of your SID Implementation project (I must get around to writing up a draft of a SID Implementation Methodology).
But where should the use of CFS stop? What about important business functions that are crucial to the provision of these CFSs. As Johi asks, what about:
- IT - they deliver the websites upon which CFSs are based,
- Procurement - they are responsible for ensuring the spares required to meet the SLAs,
- HR - they ensure that the engineers and CSA's are properly trained to deliver the CFSs
- Finance - responsible for bill payment, fraud detection and debt collection
- Network management - responsible for the provision of the resources upon which the CFSs run
I have discussed with a lot of people the idea of a "Business Facing Service" which would be analogous to the CFS but not bundled into a product. This could then be used to model all the vital internal services in the same way as the customer facing services are with Resources and RFSs to deliver them - allowing, for example, the internal servers and software to be incorporated into SID and ITIL. This is, of course, not part of SID, but would make a useful extension to it.
A word of warning however; coming back to my original response "When you've got a new hammer everything looks like a nail"... the SID is a delight, if like me, you are an Enterprise Data Modeller. It has a little box to but every concept/entity into, or could have with a little adjustment and tweaking - hours, if not days, weeks or months of delight for a serious data modeller...
But to what end? Who benefits from all this modelling? Why/how are you using SID? If it is truly as an exercise to build an Enterprise Data Model of your telecoms company, then go ahead, model away - but if you are using it to provide a language for SOA/EAI type architecture - then STOP!
In a SOA/EAI environment it really doesn't matter how this information is modelled - how often is this information going to be passed between one application to another?
- Never - then just stop now!
- Sometimes - then a "cludge/work around" where the thing to be passed is "shoehorned" into another SID concept will do, so long as both the sending and receiving application are aware of this cludge.
- Often/Always - then model it properly "a la" SID
17 August 2009
Extending SID - Part 2
As promised this is the second part of the Extending the SID.
Actually it might be better entitled "Implementing the SID".
I've noticed that deploying the SID in any organisation is a lot more complicated than many people assume. There seems to be a general belief that the SID can be deployed straight "out of the box" and that any problems encountered must be because of the deploying organisation and its legacy.
I don't think this is the case. I believe that there has to be some sort of deployment project when SID is implemented in any organisation. I am working on a SID deployment methodology which covers a range of topics including
a) tailoring the SID for business alignment
b) mapping the product catalogue
c) identification the domain to deploy first
d) education
This methodology is mainly in my mind rather than on paper and probably could do with some workshop discussion with one or more organisations in the process of deploying SID.
Any takers?
Actually it might be better entitled "Implementing the SID".
I've noticed that deploying the SID in any organisation is a lot more complicated than many people assume. There seems to be a general belief that the SID can be deployed straight "out of the box" and that any problems encountered must be because of the deploying organisation and its legacy.
I don't think this is the case. I believe that there has to be some sort of deployment project when SID is implemented in any organisation. I am working on a SID deployment methodology which covers a range of topics including
a) tailoring the SID for business alignment
b) mapping the product catalogue
c) identification the domain to deploy first
d) education
This methodology is mainly in my mind rather than on paper and probably could do with some workshop discussion with one or more organisations in the process of deploying SID.
Any takers?
23 July 2009
Extending SID - Part 1
Over the last six months I've given SID training and consultancy in a number of different countries and the one question I keep being asked is "How do I add stuff to the SID?".
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...
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...
22 January 2009
SID Training
There are a series of training courses offered by the TM Forum (see http://www.tmforum.org/TrainingWebinars/TMForumTraining/5912/Home.html) that can lead to NGOSS "Knowledge Certification".
These courses are, I believe, excellent, and if combined with a visit to the TM Forum Management World conference can be highly rewarding and instructive experience.
However if you are looking for a 'lighter' and potentially cheaper alternative you may be interested in a 2 training course I am developing in which I introduce the major concepts within the SID and provide practical guidance on the use of the SID based on my real world experience.
This course is not based on the TM Forum courses and uses none of their material, nor will it lead to any sort of certification and is certainly not offered as an alternative to the TM Forum training. Rather I am trying to develop it into something that you might want all your architects to attend, and from their experience and what they learnt on the course you might then select a few to go forward for the full TM Forum training and certification.
This course is still a "work in progress" but if you are interested in more information on pricing and content then please do not hesitate to contact me (email: mcfadyen.andrew @ gmail.com).
These courses are, I believe, excellent, and if combined with a visit to the TM Forum Management World conference can be highly rewarding and instructive experience.
However if you are looking for a 'lighter' and potentially cheaper alternative you may be interested in a 2 training course I am developing in which I introduce the major concepts within the SID and provide practical guidance on the use of the SID based on my real world experience.
This course is not based on the TM Forum courses and uses none of their material, nor will it lead to any sort of certification and is certainly not offered as an alternative to the TM Forum training. Rather I am trying to develop it into something that you might want all your architects to attend, and from their experience and what they learnt on the course you might then select a few to go forward for the full TM Forum training and certification.
This course is still a "work in progress" but if you are interested in more information on pricing and content then please do not hesitate to contact me (email: mcfadyen.andrew @ gmail.com).
CFSs revisited
I see from the hits on my blog that most people find there way to it from Google where they have searched for “Customer Facing Service” (I am flattered and amazed to see that my blog is the first one returned by Google for that particular term”. I have also been asked for my list of CFSs... I am not sure that
a) I could give it out to you as it belongs to the organisation that I created it for
b) It would be particularly useful to you anyway...
However I would say a couple of things on this subject that may guide people struggling with the concept of CFS
1. The SID is a means to an end and not an end in itself. It is highly generic and can be used to solve almost any problem. As a result it is highly complex. It offers you the ability for example to endlessly nest CFSs and to build a complex hierarchy of products and product specifications and offerings. What you need to do is to focus on what you are trying to achieve with your CFS definition.
2. Each organisations list of CFSs is likely to some degree or another be unique to that organisation.
3. Keeping the first point in mind; In Proximus my colleague Eric Borremans and I were trying to simplify a complex mess of services and products that had evolved over the years. We decided to limit ourself to a single level of CFS rather than a hierarchy. We wanted something that
a) the customer (or end user) experiences and recognises
b) is complete and free-standing enough to be packaged up into an Product Offering alone without any other CFSs being necessary to support it.
c) is manageable through a single 'on/off switch' within the Network Management system.
For example we considered Voice Mail. Now when a customer uses Voice Mail he is able to perceive a range of services including deleting messages, listening to messages, recording greetings etc. This would indicate that there are several CFSs that make up the Voice Mail service. However it isn't useful to separate them.
One would never package up a Voice Mail Product Offering containing only the service to delete messages but not listening to them. We therefore decided that we would only have a single CFS service as Proximus had an "all or nothing" approach to Voice Mail and any enhanced services were bundled into the PABX offerings as Office Automation type services. So for Proximus Voice Mail was a single service.
On the other hand we had 2G access and 3G access as separate CFSs. This was despite the customer being potentially unaware which service he was using during a call. The reason for this was that it was mooted that the Telco might want to sell 2G only services to an MVNO and there were 2 "switches" in the network, one to switch on/off 2G and one to switch on/off 3G.
There is no “right” answer to CFS - but if you can define a set of criteria as we did for Proximus that does not contravene the spirit of the SID and NGOSS and makes logical sense for what you are trying to achieve in using SID then you can use these criteria as an “Occam's Razor” to sort out what is a Product Offering, what is a CFS and what is a RFS.
Simply put if a "candidate CFS" was found to be made up of or contains two or more CFSs then it, according to the rules we created in Proximus, is a Product Offering, if it isn't a Product Offering and fails one or more of the CFS criteria (listed above) it must be a RFS.
The list and the rules we created in Proximus reflected our desire to simplify Service Management and to an extent CRM. If our objective had been different then perhaps the CFS rules set and the resulting CFS list would have been different.
By the way the rules we developed allowed a long list of over 400 candidate services gathered from various departments throughout the organisation to be “boiled down” to only some 65 to 70 CFSs. This allowed would have allowed us to (in theory) to load the product definitions and CFSs into the CRM system to aid with problem reporting and ticket creation.
The lesson to be learnt about the SID is that “all things are possible” with it. You can create really complex Products, Product Offerings, CFSs and RFSs - which is fine, if that is really what you want to do. If however you don't need the complexity that SID offers then ignore it!
a) I could give it out to you as it belongs to the organisation that I created it for
b) It would be particularly useful to you anyway...
However I would say a couple of things on this subject that may guide people struggling with the concept of CFS
1. The SID is a means to an end and not an end in itself. It is highly generic and can be used to solve almost any problem. As a result it is highly complex. It offers you the ability for example to endlessly nest CFSs and to build a complex hierarchy of products and product specifications and offerings. What you need to do is to focus on what you are trying to achieve with your CFS definition.
2. Each organisations list of CFSs is likely to some degree or another be unique to that organisation.
3. Keeping the first point in mind; In Proximus my colleague Eric Borremans and I were trying to simplify a complex mess of services and products that had evolved over the years. We decided to limit ourself to a single level of CFS rather than a hierarchy. We wanted something that
a) the customer (or end user) experiences and recognises
b) is complete and free-standing enough to be packaged up into an Product Offering alone without any other CFSs being necessary to support it.
c) is manageable through a single 'on/off switch' within the Network Management system.
For example we considered Voice Mail. Now when a customer uses Voice Mail he is able to perceive a range of services including deleting messages, listening to messages, recording greetings etc. This would indicate that there are several CFSs that make up the Voice Mail service. However it isn't useful to separate them.
One would never package up a Voice Mail Product Offering containing only the service to delete messages but not listening to them. We therefore decided that we would only have a single CFS service as Proximus had an "all or nothing" approach to Voice Mail and any enhanced services were bundled into the PABX offerings as Office Automation type services. So for Proximus Voice Mail was a single service.
On the other hand we had 2G access and 3G access as separate CFSs. This was despite the customer being potentially unaware which service he was using during a call. The reason for this was that it was mooted that the Telco might want to sell 2G only services to an MVNO and there were 2 "switches" in the network, one to switch on/off 2G and one to switch on/off 3G.
There is no “right” answer to CFS - but if you can define a set of criteria as we did for Proximus that does not contravene the spirit of the SID and NGOSS and makes logical sense for what you are trying to achieve in using SID then you can use these criteria as an “Occam's Razor” to sort out what is a Product Offering, what is a CFS and what is a RFS.
Simply put if a "candidate CFS" was found to be made up of or contains two or more CFSs then it, according to the rules we created in Proximus, is a Product Offering, if it isn't a Product Offering and fails one or more of the CFS criteria (listed above) it must be a RFS.
The list and the rules we created in Proximus reflected our desire to simplify Service Management and to an extent CRM. If our objective had been different then perhaps the CFS rules set and the resulting CFS list would have been different.
By the way the rules we developed allowed a long list of over 400 candidate services gathered from various departments throughout the organisation to be “boiled down” to only some 65 to 70 CFSs. This allowed would have allowed us to (in theory) to load the product definitions and CFSs into the CRM system to aid with problem reporting and ticket creation.
The lesson to be learnt about the SID is that “all things are possible” with it. You can create really complex Products, Product Offerings, CFSs and RFSs - which is fine, if that is really what you want to do. If however you don't need the complexity that SID offers then ignore it!
Subscribe to:
Posts (Atom)
