Internal Services and Customer Facing Services

Juhi, a reader of my blog on Customer Facing Services, has asked

"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

How are these service delivered by these organisations to be mapped/modelled onto SID - especially when there may be internal SLAs or OLAs (Operational Level Agreement) placed upon these services? The SID doesn't seem to have a structure for this (if you know better then share it with me please) and this is particularly difficult when trying to implement ITIL alongside SID.

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

I hope this helps answer the question Juhi - if anyone would like to discuss this (or any other SID related topic) further with me - then please get in contact. I can't promise a detailed answer like this to every question - but I do promise an answer to all (sensible) questions...

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?

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

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

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!