Dysdatia: Data Blindness and You

I have dyslexia, what used to be called ‘word blindness’, and so I am dyslexic, or to be precise a ‘compensated dyslexic’. I used to find it very difficult to spell and to understand and remember the rules around spelling, but now I am much better at all of this. That’s because my teachers and I didn’t ignore the problem and hope that the spelling problem would just go away. I had to work hard to get round this disability; I use tools (spell checkers) to help me all the time and I took advice and training to combat dyslexia. Now I can spell (most of the time) and I don’t find it difficult to write; hence this blog (but you know, I still don’t get poetry).

“Very interesting, Andrew, but so what?”, I hear you say. Well I believe there is a problem that I call Dysdatia, or “data blindness”, that is affecting many individuals and as a result the organizations they work for. Unlike dyslexia which affects only the small minority, many people have dysdatia, even seasoned IT professionals.

Dysdatia symptoms

Symptoms of dysdatia include:

• working exclusively with business process models like Frameworx’s Business Process Framework without ever wondering what words like “Customer” and “Product” actually mean,
• thinking “Data models aren’t import because we use COTS”,
• believing that Enterprise Data Models have something to do with databases,
• ignoring the Class diagrams in any document because it makes you dizzy when you look at them,
• thinking that the line connecting two components is just a line,
• thinking that Data Architects are just pedantic

It must be remembered that most sufferers of dysdatia are totally unaware that they are suffering from it. The only symptoms they perceive are that there are a lot of messy diagrams with load of lines and boxes on them called class diagrams, and that a third of Frameworx is incomprehensible.

The prognosis for untreated dysdatia is not good and long-term effects include:

•     complex application integration
•     failed SOA and REST implementations/initiatives
•     tight coupling between applications
•     business change and innovation limited by IT throughput
•     fragmented product catalogs
•     complex provisioning and fulfilment flows
•     significant customer dissatisfaction and operational inefficiencies due to poor data quality.

The preconceptions about, and treatment for, dyslexia when I was a child were unpleasant and unproductive; “lazy” or even “stupid” were the usual diagnosis and endless spelling lessons and tests were the treatment. This was discouraging and, worse, pointless. You can’t cure dyslexia; you just learn to work round it. Similarly with dysdatia, it is wrong to think that those people who are “data blind” are lazy or stupid — obviously they are not. Additionally, endlessly pushing these people to read or write (draw) data models will not help them.
Dealing with dysdatia

It is the responsibility of those of us without dysdatia to help dysdatic colleagues. Dysdatia sufferers need our help to:

•     make them aware that they are sufferers
•     realise how this is impacting their work and
•     know how to get support for their problem.

To bring this about I suggest that dysdatia sufferers receive training and support from the non-dysdatic community. I know this isn’t going to be a popular medicine; dysdatic people don’t like the Information Framework training — to quote an anonymous training manager: “We don’t give much SID training because people find it too difficult”. However, think of this training as problem recognition training; rather than expecting the attendee to become an expert in the Information Framework and data modelling, they will simply understand that data exists, what it is for and how to deal with his problems with it.

After the training the attendee won’t be expected to be able to draw class models, but they will understand that the vocabulary used in the rest of Frameworx comes from the Information Framework. They may even be able to look at a class diagram without getting dizzy and possibly, if they are only mildly affected by dysdatia, even understand it. You are going to have to trick your colleagues into attending this training. Call it “vocabulary training” and even avoid showing class diagrams! Instead focus on the meaning of the classes and their definitions, rather than the class diagram structures.

Data appreciation

Sell this type of Information Framework training as “data appreciation” rather than a course in “data composing” – like the difference between music appreciation and music composition. Explain that like in music, where there are three classes of people – those that are tone deaf, those that enjoy music, and those that can write music, that there are three classes of people in IT – those that have dysdatia (and don’t know it), those that have compensated dysdatia and can read a data model, and those who don’t suffer from dysdatia and can draw data models.

Encourage the dysdatic sufferers — tell them that by becoming a compensated dysdatic they will have the basic tools to work around the problem and avoid many of the difficulties they had in the past with integration and data quality. However, you must explain to them that sadly they can never be fully cured of dysdatia; they still will need an Enterprise Data Architect who is by definition non-dysdatic and can draw class diagrams and even make changes to the business’s Information Framework based Enterprise Data Model.

My current boss at least acknowledges he is dysdatic. The other day he said to me “I know data is important, but I still don’t get it, which is why I hired you”.

It is going to be hard work fellow non-dysdatics but in the long run it will be worth it!

First published on the TM Forum Inform Portal on 7 Oct 2014

I have dyslexia, what used to be called ‘word blindness’, and so I am dyslexic, or to be precise a ‘compensated dyslexic’. I used to find it very difficult to spell and to understand and remember the rules around spelling, but now I am much better at all of this. That’s because my teachers and I didn’t ignore the problem and hope that the spelling problem would just go away. I had to work hard to get round this disability; I use tools (spell checkers) to help me all the time and I took advice and training to combat dyslexia. Now I can spell (most of the time) and I don’t find it difficult to write; hence this blog (but you know, I still don’t get poetry).
“Very interesting, Andrew, but so what?”, I hear you say. Well I believe there is a problem that I call Dysdatia, or “data blindness”, that is affecting many individuals and as a result the organizations they work for. Unlike dyslexia which affects only the small minority, many people have dysdatia, even seasoned IT professionals.

Dysdatia symptoms

Symptoms of dysdatia include:

• working exclusively with business process models like Frameworx’s Business Process Framework without ever wondering what words like “Customer” and “Product” actually mean,
• thinking “Data models aren’t import because we use COTS”,
• believing that Enterprise Data Models have something to do with databases,
• ignoring the Class diagrams in any document because it makes you dizzy when you look at them,
• thinking that the line connecting two components is just a line,
• thinking that Data Architects are just pedantic

It must be remembered that most sufferers of dysdatia are totally unaware that they are suffering from it. The only symptoms they perceive are that there are a lot of messy diagrams with load of lines and boxes on them called class diagrams, and that a third of Frameworx is incomprehensible.
The prognosis for untreated dysdatia is not good and long-term effects include:

• complex application integration
• failed SOA and REST implementations/initiatives
• tight coupling between applications
• business change and innovation limited by IT throughput
• fragmented product catalogs
• complex provisioning and fulfilment flows
• significant customer dissatisfaction and operational inefficiencies due to poor data quality.

The preconceptions about, and treatment for, dyslexia when I was a child were unpleasant and unproductive; “lazy” or even “stupid” were the usual diagnosis and endless spelling lessons and tests were the treatment. This was discouraging and, worse, pointless. You can’t cure dyslexia; you just learn to work round it. Similarly with dysdatia, it is wrong to think that those people who are “data blind” are lazy or stupid — obviously they are not. Additionally, endlessly pushing these people to read or write (draw) data models will not help them.

Dealing with dysdatia

It is the responsibility of those of us without dysdatia to help dysdatic colleagues. Dysdatia sufferers need our help to:

• make them aware that they are sufferers
• realise how this is impacting their work and
• know how to get support for their problem.

To bring this about I suggest that dysdatia sufferers receive training and support from the non-dysdatic community. I know this isn’t going to be a popular medicine; dysdatic people don’t like the Information Framework training — to quote an anonymous training manager: “We don’t give much SID training because people find it too difficult”. However, think of this training as problem recognition training; rather than expecting the attendee to become an expert in the Information Framework and data modelling, they will simply understand that data exists, what it is for and how to deal with his problems with it.
After the training the attendee won’t be expected to be able to draw class models, but they will understand that the vocabulary used in the rest of Frameworx comes from the Information Framework. They may even be able to look at a class diagram without getting dizzy and possibly, if they are only mildly affected by dysdatia, even understand it. You are going to have to trick your colleagues into attending this training. Call it “vocabulary training” and even avoid showing class diagrams! Instead focus on the meaning of the classes and their definitions, rather than the class diagram structures.

Data appreciation

Sell this type of Information Framework training as “data appreciation” rather than a course in “data composing” – like the difference between music appreciation and music composition. Explain that like in music, where there are three classes of people – those that are tone deaf, those that enjoy music, and those that can write music, that there are three classes of people in IT – those that have dysdatia (and don’t know it), those that have compensated dysdatia and can read a data model, and those who don’t suffer from dysdatia and can draw data models.
Encourage the dysdatic sufferers — tell them that by becoming a compensated dysdatic they will have the basic tools to work around the problem and avoid many of the difficulties they had in the past with integration and data quality. However, you must explain to them that sadly they can never be fully cured of dysdatia; they still will need an Enterprise Data Architect who is by definition non-dysdatic and can draw class diagrams and even make changes to the business’s Information Framework based Enterprise Data Model.
My current boss at least acknowledges he is dysdatic. The other day he said to me “I know data is important, but I still don’t get it, which is why I hired you”.
It is going to be hard work fellow non-dysdatics but in the long run it will be worth it!
- See more at: http://inform.tmforum.org/strategic-programs-2/customer-centricity/2014/10/dysdatia/#sthash.S798IGzL.dpuf

I have dyslexia, what used to be called ‘word blindness’, and so I am dyslexic, or to be precise a ‘compensated dyslexic’. I used to find it very difficult to spell and to understand and remember the rules around spelling, but now I am much better at all of this. That’s because my teachers and I didn’t ignore the problem and hope that the spelling problem would just go away. I had to work hard to get round this disability; I use tools (spell checkers) to help me all the time and I took advice and training to combat dyslexia. Now I can spell (most of the time) and I don’t find it difficult to write; hence this blog (but you know, I still don’t get poetry).
“Very interesting, Andrew, but so what?”, I hear you say. Well I believe there is a problem that I call Dysdatia, or “data blindness”, that is affecting many individuals and as a result the organizations they work for. Unlike dyslexia which affects only the small minority, many people have dysdatia, even seasoned IT professionals.

Dysdatia symptoms

Symptoms of dysdatia include:

• working exclusively with business process models like Frameworx’s Business Process Framework without ever wondering what words like “Customer” and “Product” actually mean,
• thinking “Data models aren’t import because we use COTS”,
• believing that Enterprise Data Models have something to do with databases,
• ignoring the Class diagrams in any document because it makes you dizzy when you look at them,
• thinking that the line connecting two components is just a line,
• thinking that Data Architects are just pedantic

It must be remembered that most sufferers of dysdatia are totally unaware that they are suffering from it. The only symptoms they perceive are that there are a lot of messy diagrams with load of lines and boxes on them called class diagrams, and that a third of Frameworx is incomprehensible.
The prognosis for untreated dysdatia is not good and long-term effects include:

• complex application integration
• failed SOA and REST implementations/initiatives
• tight coupling between applications
• business change and innovation limited by IT throughput
• fragmented product catalogs
• complex provisioning and fulfilment flows
• significant customer dissatisfaction and operational inefficiencies due to poor data quality.

The preconceptions about, and treatment for, dyslexia when I was a child were unpleasant and unproductive; “lazy” or even “stupid” were the usual diagnosis and endless spelling lessons and tests were the treatment. This was discouraging and, worse, pointless. You can’t cure dyslexia; you just learn to work round it. Similarly with dysdatia, it is wrong to think that those people who are “data blind” are lazy or stupid — obviously they are not. Additionally, endlessly pushing these people to read or write (draw) data models will not help them.

Dealing with dysdatia

It is the responsibility of those of us without dysdatia to help dysdatic colleagues. Dysdatia sufferers need our help to:

• make them aware that they are sufferers
• realise how this is impacting their work and
• know how to get support for their problem.

To bring this about I suggest that dysdatia sufferers receive training and support from the non-dysdatic community. I know this isn’t going to be a popular medicine; dysdatic people don’t like the Information Framework training — to quote an anonymous training manager: “We don’t give much SID training because people find it too difficult”. However, think of this training as problem recognition training; rather than expecting the attendee to become an expert in the Information Framework and data modelling, they will simply understand that data exists, what it is for and how to deal with his problems with it.
After the training the attendee won’t be expected to be able to draw class models, but they will understand that the vocabulary used in the rest of Frameworx comes from the Information Framework. They may even be able to look at a class diagram without getting dizzy and possibly, if they are only mildly affected by dysdatia, even understand it. You are going to have to trick your colleagues into attending this training. Call it “vocabulary training” and even avoid showing class diagrams! Instead focus on the meaning of the classes and their definitions, rather than the class diagram structures.

Data appreciation

Sell this type of Information Framework training as “data appreciation” rather than a course in “data composing” – like the difference between music appreciation and music composition. Explain that like in music, where there are three classes of people – those that are tone deaf, those that enjoy music, and those that can write music, that there are three classes of people in IT – those that have dysdatia (and don’t know it), those that have compensated dysdatia and can read a data model, and those who don’t suffer from dysdatia and can draw data models.
Encourage the dysdatic sufferers — tell them that by becoming a compensated dysdatic they will have the basic tools to work around the problem and avoid many of the difficulties they had in the past with integration and data quality. However, you must explain to them that sadly they can never be fully cured of dysdatia; they still will need an Enterprise Data Architect who is by definition non-dysdatic and can draw class diagrams and even make changes to the business’s Information Framework based Enterprise Data Model.
My current boss at least acknowledges he is dysdatic. The other day he said to me “I know data is important, but I still don’t get it, which is why I hired you”.
It is going to be hard work fellow non-dysdatics but in the long run it will be worth it!
- See more at: http://inform.tmforum.org/strategic-programs-2/customer-centricity/2014/10/dysdatia/#sthash.S798IGzL.dpuf

I have dyslexia, what used to be called ‘word blindness’, and so I am dyslexic, or to be precise a ‘compensated dyslexic’. I used to find it very difficult to spell and to understand and remember the rules around spelling, but now I am much better at all of this. That’s because my teachers and I didn’t ignore the problem and hope that the spelling problem would just go away. I had to work hard to get round this disability; I use tools (spell checkers) to help me all the time and I took advice and training to combat dyslexia. Now I can spell (most of the time) and I don’t find it difficult to write; hence this blog (but you know, I still don’t get poetry).
“Very interesting, Andrew, but so what?”, I hear you say. Well I believe there is a problem that I call Dysdatia, or “data blindness”, that is affecting many individuals and as a result the organizations they work for. Unlike dyslexia which affects only the small minority, many people have dysdatia, even seasoned IT professionals.

Dysdatia symptoms

Symptoms of dysdatia include:

• working exclusively with business process models like Frameworx’s Business Process Framework without ever wondering what words like “Customer” and “Product” actually mean,
• thinking “Data models aren’t import because we use COTS”,
• believing that Enterprise Data Models have something to do with databases,
• ignoring the Class diagrams in any document because it makes you dizzy when you look at them,
• thinking that the line connecting two components is just a line,
• thinking that Data Architects are just pedantic

It must be remembered that most sufferers of dysdatia are totally unaware that they are suffering from it. The only symptoms they perceive are that there are a lot of messy diagrams with load of lines and boxes on them called class diagrams, and that a third of Frameworx is incomprehensible.
The prognosis for untreated dysdatia is not good and long-term effects include:

• complex application integration
• failed SOA and REST implementations/initiatives
• tight coupling between applications
• business change and innovation limited by IT throughput
• fragmented product catalogs
• complex provisioning and fulfilment flows
• significant customer dissatisfaction and operational inefficiencies due to poor data quality.

The preconceptions about, and treatment for, dyslexia when I was a child were unpleasant and unproductive; “lazy” or even “stupid” were the usual diagnosis and endless spelling lessons and tests were the treatment. This was discouraging and, worse, pointless. You can’t cure dyslexia; you just learn to work round it. Similarly with dysdatia, it is wrong to think that those people who are “data blind” are lazy or stupid — obviously they are not. Additionally, endlessly pushing these people to read or write (draw) data models will not help them.

Dealing with dysdatia

It is the responsibility of those of us without dysdatia to help dysdatic colleagues. Dysdatia sufferers need our help to:

• make them aware that they are sufferers
• realise how this is impacting their work and
• know how to get support for their problem.

To bring this about I suggest that dysdatia sufferers receive training and support from the non-dysdatic community. I know this isn’t going to be a popular medicine; dysdatic people don’t like the Information Framework training — to quote an anonymous training manager: “We don’t give much SID training because people find it too difficult”. However, think of this training as problem recognition training; rather than expecting the attendee to become an expert in the Information Framework and data modelling, they will simply understand that data exists, what it is for and how to deal with his problems with it.
After the training the attendee won’t be expected to be able to draw class models, but they will understand that the vocabulary used in the rest of Frameworx comes from the Information Framework. They may even be able to look at a class diagram without getting dizzy and possibly, if they are only mildly affected by dysdatia, even understand it. You are going to have to trick your colleagues into attending this training. Call it “vocabulary training” and even avoid showing class diagrams! Instead focus on the meaning of the classes and their definitions, rather than the class diagram structures.

Data appreciation

Sell this type of Information Framework training as “data appreciation” rather than a course in “data composing” – like the difference between music appreciation and music composition. Explain that like in music, where there are three classes of people – those that are tone deaf, those that enjoy music, and those that can write music, that there are three classes of people in IT – those that have dysdatia (and don’t know it), those that have compensated dysdatia and can read a data model, and those who don’t suffer from dysdatia and can draw data models.
Encourage the dysdatic sufferers — tell them that by becoming a compensated dysdatic they will have the basic tools to work around the problem and avoid many of the difficulties they had in the past with integration and data quality. However, you must explain to them that sadly they can never be fully cured of dysdatia; they still will need an Enterprise Data Architect who is by definition non-dysdatic and can draw class diagrams and even make changes to the business’s Information Framework based Enterprise Data Model.
My current boss at least acknowledges he is dysdatic. The other day he said to me “I know data is important, but I still don’t get it, which is why I hired you”.
It is going to be hard work fellow non-dysdatics but in the long run it will be worth it!
- See more at: http://inform.tmforum.org/strategic-programs-2/customer-centricity/2014/10/dysdatia/#sthash.S798IGzL.dpuf

NFV and SID

NFV and its sidekick SDN are getting a huge amount of attention and I’ve been wondering how these fit into good old Frameworx Information Model (SID).

There is a suggestion (http://blog.cimicorp.com/?p=2352) that NFV has been modelled as a Logical Resource at the bottom of the Resource stack by some NFV vendors and that surprised me and I'll explain why.

If you look at the acronym’s components, the word Function is, I believe, the key to understanding how NFV and SID fit together.
Let’s consider a Network Function such as "Firewall" which is often used as an example of something that NFV can deliver without having to deploy a dedicated “box” or firewall device.
I wonder, is it the firewall device that has been virtualised or is it the function that the device offers that has been virtualised? In this case is it that there is a virtual firewall device in the cloud or is the cloud providing a firewall service?

Network Elements are in the network to perform functions, or in SID terms provide services...
So a physical (actually, compound) resource such as a Juniper box provides the service of “Firewall”.
SID (used to) models Resource Facing Services being provided by Logical Resources installed on Physical Resources.

So is NFV/NVF just RFS in another guise?

Should Resource Facing Service (a terrible name see my blog "The Problem with RFSs") be renamed to Resource Functional Service to highlight the connection between NFV and RFS?

This blog was originally published on LinkedIn on 13 Oct 2015.

It has been pointed out to me by John Reilly, no less, that in the latest release of the Frameworx Information Framework (SID) that RFS is being dropped and is only in the release for backward compatibility.  RFS is being replaced by Config - perhaps I will comment on this in a future post.

What is a Phone Number?

Do you know what a Phone Number is? 

Are you sure?  Did you say something like?

“It is a number used on one phone to connect to another phone”.

As far as it goes, that is correct, but that is only one of several correct answers. You could have answered the question by saying any of the following and also be right because phone number pops up all over the CSP’s business, but spotting it can be a bit like playing “Where’s Wally” (or “Where’s Waldo”, if you are American).

What is a phone number?

a)    A phone number is a string of digits and is not, in its truest sense, “a number” because any leading zero is significant.

b)    A phone number is something that can be bought or sold and quite significant amounts of money can be paid for phone numbers.  According to The Register (www.theregister.co.uk) the world's most expensive phone number was auctioned for charity on 22 May 2006 in Qatar.  The number, 666 6666, sold for 10m Qatari riyals or £1.5m.

c)    A phone number is asset allocated to the Communications Service Provider (CSP) by the telecoms regulator that is then allocated, sold, lent or in some other way given for the use of a customer (see (a) above).  The customer can, often, take the phone number with him when he leaves the CSP; he can “port” it out.

d)    A phone number is a way of contacting people and/or organisations (the “simple” answer); so it is a type of address.

e)    A phone number is information on how to connect two phones during a call.

f)     A phone number is a service identifier; a phone service is identified by the phone number used by that service.

g)    A phone number is an account identifier; the customer's account or sub-account is identified by the phone number, after all it appears on the bill.

I’m sure there are other answers too, but the list shows that there are quite a few different definitions a phone number and that it should be found in quite a number of different “pictures” that illustrate the CSPs business.

In the CSP world we have the Frameworx Information Model (aka the SID) that provides definitions of important business concepts and provides lots of “pictures” or data models that show how these concepts interrelate.  So let’s start searching for Phone Number in the SID.  The SID is full of entities and relationships so looking for a particular entity really can be a bit like reading “Where’s Wally/Waldo”; looking for what should be something really easy to spot, but that just doesn’t stand out from the crowd.

SID experts know, even though the SID but doesn’t explicitly show it, that Wally (the phone number) can be found disguised as a Logical Resource and as the Logical Resource can be provided through a Product we can claim to have found him for pictures (a), (b) and (c).

The SID actually has phone number in it as (d), a “Contact Medium”, used to contact Customers, so this time Wally wasn’t even disguised but because it doesn’t relate this phone number with the (Logical Resource) phone number of the Product the Customer is using to make phone calls on the CSPs network it wasn’t particularly easy to find.

So can we find the Phone Number in the SID doing the job defined in (e), providing information on how to connect two phones?  Mr Strowger’s mechanical exchange invented about 125 years ago used a phone number to automatically route the call from one phone to another.  Mr Strowger was an undertaker who became convinced that the telephone operator who was the wife of a competitor undertaker was forwarding calls to her husband when people called for an undertaker, and so he dreamt up a way cutting out the operator in connecting two phones together. CSPs still use this fundamental mechanism in one way or another to route calls using the information imbedded in the phone number to work out how to find the phone that is being called.  This is very important for OSS/network operations but it also has a direct impact on the amount charged to a customer for the call and the profit made by the CSP (on net, off net, roaming, roaming partners, etc, etc). 

So we would expect to find Wally/Waldo (the Phone Number) somewhere around the network picture even if it seems to be bit of an obscure area to find him/it.  But, actually, how obscure is this picture?  Let’s face it, the two of the most important fields on a CDR are the “A Number” and the “B Number” – phone numbers and Billing wouldn’t work if these didn’t identify the product/service being used and ultimately the pricing, discounting and allowances to be applied to the customer’s account for the usage of the network. 

Search as you may, you won’t find Wally/Waldo here in the SID.

And finally, and perhaps most importantly, all the CSPs I’ve worked with all talk about the phone number as being the identifier for the user/the subscriber (a legacy concept that isn’t in the SID) or the product (the subscription or price plan (two more legacy ideas quite rightly excluded from the SID).  But this isn’t just a bit of “legacy thinking” which is how I used to dismiss this definition.  There is an important idea here – not all Products are equal – there are the “subscription products” or the “contract product” that define the overall (basic) services (e.g. voice, messages and data) and their prices and allowances while there are other add-on products that are then associated with or ‘bolted on’ to the main product – and the main product, nine times out of ten, is identified by the Phone Number by both the Customer and the CSP. 

The SID doesn’t draw Wally/Waldo into this picture either, though the ever-flexible SID experts (like me) can claim he is there, you just can’t see him!

I don’t think we should let Phone Number hide in Logical Resource whilst also living secret lives as Contact Medium, Product, Service Identifier and Network Address – these different nuances of the phone number’s role need to be explicitly stated. 

We should be able to see Wally/Waldo wherever he is, then when someone who has never seen the SID before says

“Wow!  That looks complicated… Let’s start with something easy; show me where in these diagrams Phone Number is”,

you can point confidently to the model and say

“There!”

rather than waving your hands around talking about rather complicated things called Logical Resource, Resource Role, Involvement Role etc etc and conducting the “Where’s Wally?” hunt.

You may ask,

“How can I make the SID representation of Phone Number a little closer to the business view of Phone Number?”

or perhaps, if you will,

“How can I put Wally in SID?”

If you make the following enhancements to your own in-house implementation of the SID then it will reflect the business realities and define phone numbers in a way that everyone can recognise and relate to and you will able to point confidently to the SID and say “There’s Wally/Waldo”.

1. Put PhoneNumber and PhoneNumberSpecification into the SID as concrete subclasses of Logical Resource and Logical Resource Specification respectively
2. Create an association from Contact Medium (Phone) to this class.
3. Create concrete subclasses of Product Offering and Product as “Contract Product Offering” and “Contract Product” to identify these key products.
4. Create an association from Contract Product to Phone Number “identified by” to acknowledge that this is important relationship.

I know that the last step is a little controversial for “dyed-in-the-wool” SID practitioners as this is information is already provided by the multipurpose ProductInvolvementRole.  This is a sub type of InvolvementRole that is played by a CustomerAccount, or a PartyRole, or importantly a ResourceRole.  As an alternative to step 4 the creation of a concrete subclass of ResourceRole called “IdentifyingPhoneNumber” would keep the purists, if not the business and “Wally hunters” happy.

So Phone Number is a lot of things to a lot of different people and many of these are already in the SID if hidden from view – but one thing is for certain it isn’t just a string of digits or just a Logical Resource.

So, now, where are Wally’s friends IMSI, IMEI and MSISDN hiding in the SID?

The Problem with RFSs

CFSs are difficult to understand and have caused a huge amount of debate in the TMForum Community and beyond, but RFSs that lurk beneath CFSs are even less well understood.

A recent training and consulting assignment to a telco in Canada revealed a number of issues that they had with RFSs and I suspect many other people have similar problems.

The first issue was the name - Resource Facing Services.  "Resource Facing" makes it sound as if the RFSs provide services to the Resources in the same way as the "Customer Facing" services provide services to the "customer" (or rather User, so perhaps CFS should be renamed UFS, but that's another story). But RFS providing services to Resources doesn't make a lot of sense!  If we have a set of services made up of CFSs on one side and RFSs on the other each servicing its own community and the RFS are supporting the CFSs - what provides the Services themselves?  The problem lies in the name Resource Facing Service and in particular the word "Facing"; it is the wrong word.  A better name would be "Resource Exposed Service" or "Resource Hosted Service" or "Resource Provided Services" or "Resource Fronted Services" (to preserve the acronym) as these types of service don't "Face" the Resources, rather they are exposed or provided by the Resources.

My view is that the RFSs are services that run "in the network" (or perhaps in the end user device, if you are talking about a smart phone or advanced set-top-box).  I think of them (and they used to be defined in SID) as interfaces or Services implemented by software running on hardware.

A second issue, that took me a little while to understand when talking to this group of enthusiastic Canadians, was that they were erroneously assuming that the RFSs (at least, if not CFSs as well) were objects involved with the provisioning of a Product on the network.   This I assured them was not correct.   The Service is the service used when using the Product, not the provisioning process used to create a Product in the network.

A third issue was how to describe the provisioning process for RFSs.  Logically you provision a Product by breaking it down into its components - Resources that the Product delivers (i.e. CPE - so we provision by Logistics delivering (and optionally Workforce management installing the

resource) or by giving the resource to the customer in the shop) and CFSs which we provision decomposing the CFSs into RFSs and provision those on the network... 

But, I hold that you don't usually directly provision RFSs.  With intelligent Network Elements you pass commands (Resource Orders?) to the NE and it internally does some magic in its "black box" to provision the RFS, and therefore from a provisioning perspective we can (usually) ignore RFSs.

Nevertheless when provisioning we need to understand how a CFS decomposes into RFSs and which "boxes" in the network support/provide these RFSs but practically we can jump from CFS Spec (via the RFS Spec) straight to Resources that deliver the RFSs.  Practically we rarely provision a CFS or RFS directly (I guess the exception might be something like a VPN where the service has a number of parameters that can be altered after the VPN has been created, but again I would argue this is done by talking to (a) a supervisor service or application (Logical Resource) that manages the VPN or (b) a VPN "box", or resource that provides the VPN (front end).

So, RFSs are as tricky as CFSs - someone recently asked me why we bother with these Services and I replied that before them things were even trickier.  The SID has really helped Communications Service Providers describe their products in very generic manner using CFSs and RFSs.