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