What does SID mean by Customer Facing Service?

A key element in SID is way it models telecoms products (Product Offerings) and especially
the concept of Customer Facing Services (CFS). A Product Offering (Specification) is made
up of:

• Customer Facing Services

• Resource Specifications
• A Price Plan

A Customer Facing Service is defined in SID as: “A Customer Facing Service is an

abstraction that defines the characteristics and behaviour of a particular Service as seen by
the Customer. This means that a Customer purchases and/or is directly aware of the type of
Service and is in direct contrast to a Resource Facing Service which support Customer
Facing Services but are not seen or purchased directly by the Customer.”

The key point to this definition is the word seen. The Customer (or more precisely the End
User Party Role) perceives the service “Outbound Voice Call”, for example, as nothing more
than that. The End User does not perceive the switching, encryption, error correction, radio
frequency hops, base station transfers, multiplexing and demultiplexing that may go on in
the background.

The Product Offering is thus defined in terms of the Services that an End User perceives,
values, and may be charged for.

The SID does not contain the concept of Supplementary Service, which is after all a network
(GSM) related artefact and should not (in the ideal world) be used when describing or
pricing products and services to Customers and End Users.

Clearly defining a Product Offering, for example “3G Anytime” solely in terms of the services
perceived by the End User will not help when the Product Offering is sold (as a Product
Offering Subscription) to be provisioned in the network or on the Billing System, but that is
precisely the objective of the SID. By allowing an Offering to be defined independently of
how it is implemented as a step in the direction of Service Oriented Architectures Holy Grail
– Loosely Coupled Architecture, where each domain defines what it wants in the way of
services, not how the services are to be implemented or built.

Clearly a Customer Facing Service such as “Outbound Voice Call” has to be provisioned in
the network as a range of low level services managed by dedicated hardware such as the
MSC. These services are defined as Resource Facing Services (and I will be discussing these
RFSs in a later blog).

So, we can define a Product Offering as a collection of Customer Facing Services, the
Specifications of the Resources required by the Product Offering (and the CFSs) such as the
telephone number (MSISDN), type of SIM, type of Handset etc and the Prices to be charged
for the Product Offering and the CFSs it offers (Note: An “Outbound Voice Call” or “Send
Text Message” can be charged at different rates in different Product Offerings).

I hope you will agree that this sounds sensible, but what exactly is a CFS? Is a “Voice Call”
a CFS, or is “Making a Voice Call” a separate CFS from “Receiving a Voice Call”. When one
tries to list CFSs it becomes incredibly difficult to actually decide what is and is not a CFS
and why.

While working with Belgacom Mobile (Proximus) Eric Borremans and I faced this problem.
We needed an objective way of defining what a CFS was and a set of rules to allow us to
determine whether a candidate service was a CFS, and if it wasn’t a CFS, then what actually
it was.

The trick was to focus back on the definition of CFS, and it comes back to the word “seen”
in the definition of CFS, or perhaps more precisely “perceived”. If a End User cannot
perceive the difference between two related services, then probably the two services are
components of the same CFS. If on the other hand the End User can tell the difference then,
probably (as there are other pragmatic criteria to be applied) these two services are
separate CFSs.

For example – can an End User tell the difference between making a voice call and receiving
one? To me this is a definite “Yes”. The phone rings when a call is made and when answered
there is someone on the other end of the line to talk to. On the other hand when making a
call the line has to be activated (by picking up the receiver, or pushing a button on the
handset), the number dialled and then after hearing the ring tone the phone maybe
answered.

On the other hand, can an End User tell the difference between making a voice call to a
fixed line number as opposed to a mobile number? In my opinion, these are the same CFS,
handled by different RFSs (to do the switching). One could argue that a knowledgeable End
User can by knowing something about the numbering plan in the country, but the call is
perceived (heard) in the same way during the call. It is also possible that a call to a fixed
line number terminates on a mobile phone and vice versa through call forwarding, hunting
groups and the like. When it comes to paying for the call the difference between fixed and
mobile voice calls may also be perceived as they may be charged for differently, but that is
after the event (for Postpay customers at least). So it comes down to perception during the
use of the service, not prior or after the event knowledge that counts.

However if one extends this simple rule to a complex service like “Voice Mail” things become
complex and uncomfortable. Clearly an End User can perceive the difference between
“Listen to a Voice Mail Message” and “Delete a Voice Mail Message”, but then Voice Mail
decomposes into about 10 or more CFSs that are never ‘unbundled’ – one could never
imagine selling a Product Offering that allowed someone to “Delete a Voice Mail Message”
but not to “Listen to a Voice Mail Message”. An additional rule needs to be defined to allow
these type of services that are perceived differently to be bundled together into a pragmatic
CFS.

Actually Eric Borremans and I came up with 3 rules and a method to apply these rules that
allowed Eric to draw up a list of 60 or so CFSs that described every Service that Belgacom
Mobile sold and managed. This list has been successfully implemented within Belgacom
Mobile in the area of service management and has been used to define all of the Product
Offerings they sell.
Unravelling the enigma of resource-facing service

Users of the Information Framework’s (SID) Customer and ResourceFacingService (CFS/RFS) typically
consider that one or more ResourceFacingService(s) associated with a CustomerFacingService specify
how a the latter will be configured within an enterprise’s resource infrastructure. They also tend to
assume that the association between ResourceFacingServiceSpecifications and one or more
ResourceSpecification(s) themselves define the types of Resources that will be used, in some way, to
support a CustomerFacingService. Here is a figure from the Information Framework’s training course
which illustrates this, including how a Product, such as a smart home door lock, managed via Wi-Fi, is
directly realized by a Resource.
So far so good, but let’s dig a little deeper into how this applies. Here is an example from the definition of
a ResourceFacingService: “A [virtual private network]VPN is an example of a customer-facing service.
This particular type of VPN may require border gateway protocol (BGP) to support it. Customers don’t
purchase the BGP, and hopefully aren’t even aware that BGP is running. Therefore, BGP is an example of
a resource-facing service.”

Now the enigma begins to surface: BGP is a Logical Resource, Protocol Service,v Routing Protocols
business entity. At this juncture, users of the Information Framework wonder why BPG in needed in both
the Service and Resource domains. One solution is to refer to the ResourceFacingService as a BGP service,
but is this enough?

The enigma grows when Information Framework users try to use the simple association from a
ResourceFacingServiceSpecification to one or more ResourceSpecification(s) to define all aspects of how a
ResourceFacingService, in this case the BGP, is configured. For instance, as the BGP is part of the
configuration of the VPN, what is the sequence of configuring it within the overall VPN? Which properties
of BGP can be selected and which are fixed? What other resources must be configured as part
of configuring the BGP?
There has been a solution to this since release 14.0 of the Information Framework. Let’s back up a bit. The
solution has been present since the early days of the framework as a set of Product, Service, and Resource
Configuration Aggregate Business Entities (ABEs). However, they had not been developed, other than by
some members for their own use, until a large number of members participated in developing an
extensive set of configuration requirements as part of the Profiles and Templates work group. The
requirements were satisfied with the development of the SID Configuration and Profiling ABE in the
Common Business Entities domain and companion ABEs in the Product, Service, and Resource domains.
Here is an update to the figure depicting this.

Notice that the CustomerFacingService and ResourceFacingService have been removed.

ResourceFacingService is represented by ServiceConfiguration. And because CustomerFacingService is
the only subclass of the service, it has been collapsed into Service. Bearing in mind that many Information
Framework users employ CustomerFacingService and ResourceFacingService, here is an alternative to
this rather radical approach.
Notice that it retains the current view shown earlier and enables users to take advantage of the new
Configuration ABEs.

Find out more by taking a look at the SID Configuration guide book which can be found here.