Telecoms Enterprise Information Modelling

Transformers! Robots in Disguise - Config and RFS

noreply@blogger.com (Andrew McFadyen) — Thu, 23 Feb 2017 14:14:00 +0000

A few versions ago a subtle change was made to the SID and the Config concept was introduced and the RFS was marked as "discontinued"... Being someone who has talked about RFSs extensively many people have asked me to explain the difference between Config and RFS.

To understand what has happened and why you must remember that many low level elements in the network can work in different ways - a router can also act as a firewall or a bridge. Additionally a SIP Port can support multiple different types of numbers and services associated with that number.

The SID's RFS defines the service delivered after the configuration of the Logical Resource that provides the RFS has taken place. The RFS does not describe the process of how to configure that Logical Resource, RFS, or even the corresponding CFS that the RFS and other RFSs support.

To understand the role of Config consider something a lot simpler than a Logical Resource, RFS or CFS, a children's toy, Transformers "Optimus Prime". A single toy can have two configurations - Optimus Prime or a Hino Brandler Fire Engine/Truck. The RFS view of this would define the services delivered by the robot - as a Fire Engine it delivers a set of fire extinguishing services and as Optimus Prime it delivers leadership as Autobot Leader and fighting services. These are useful when defining or understanding the role of the robot in relationship to other Transformers and their role in Earth society.

So the RFS is a "steady state" representation where the services or functions have already been set up or configured and it can be used to describe the service elements being delivered or when something goes wrong the symptoms (eg lack of function or service) can easily be understood.

This view however doesn't tell us how to turn Optimus Prime from his Fire Engine form into his fighting robot form, which is not a problem for most 10 year olds, but for a CSP implementing a Customer Facing Service or Product this is where most of the effort is expended, the transformation of a low level service through the application of certain commands or settings, in other words, the provisioning and orchestration of components in the network.

As I explained in an earlier blog (The Problem with RFSs) some people thought that the RFS defined the provisioning being performed on the network to get a CFS to function. This isn't the role of the RFS and there wasn't anything in the SID that defined this - hence the recent introduction of Config.

Config Specification defines how to change any instance of the transformer robot into a fire engine or into Optimus Prime - which bits to twist and reposition. When the Config has been applied we tend to call the general purpose robot after the config it has just had applied - so we have "Optimus Prime" or "Fire Engine"

So in summary
Configspec = Allocate a port to a number / Turn an Optimus Prime into a Fire Engine
Config = Allocate port xyz to number 12345758 / Turn Andrew's Optimus Prime into Andrew's Fire Engine (be careful when twisting left leg, it is loose).
Instance as a Config spec = "build them like this one" / Look at Andrew's Optimus Prime as an example

Dysdatia: Data Blindness and You

noreply@blogger.com (Andrew McFadyen) — Wed, 18 Nov 2015 12:05:00 +0000

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.

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.

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.

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

What's the difference between a household and a small business?

noreply@blogger.com (Andrew McFadyen) — Tue, 17 Nov 2015 12:16:00 +0000

This post was originally posted on the TM Forum Inform portal on 23 September 2015

Not so long ago retail telecommunications customers had a single telephone number for a single line tied to a residential address with a single product/service associated. As far as the service provider was concerned, the customer and the household were synonymous with the phone number.
But for a small or medium enterprise (SME), the setup was different. There could be multiple phone lines possibly going to multiple addresses, a PBX, and services like hunting groups and call pick-up as well as the more conventional phone services.
Things started to change when retail customers began using the phone line for Internet and email – using technology like DSL rather than the old dial-up modems – in addition to making and receiving phone calls. This slow shift wasn’t too difficult to deal with for the service providers and some even managed to get the two services on a single bill.

The era of the digital ecosystem

Jump ahead ten or so years to the era of the ‘digital ecosystem’, and we have homes that have fixed-line connections capable of delivering high-speed broadband services that are consumed as streaming video and cloud services, as well as the more traditional phone, Internet and email services. On top of that households may also have digital TV set-top box and multiple 4G devices including tablets and phones. Now the cracks in the service providers’ approach to dealing with the household as if it were a single phone number with a single customer begins to show, and in fact are much more like yawning chasms than cracks!
The problems of getting all these services on a single bill the customer is trivial compared to the other aspects of the evolution of the digital ecosystem. ‘Customer’ is no longer synonymous with a (single) phone number, and the users of the 4G and Internet-enabled devices want to be able to seamlessly move services from one device to another. This means that all the devices must be related and integrated in some way, but frankly that’s just a technical problem.

What is a lot more complex for the service provider is the realization that the customer paradigm has to change.

First of all, it is not easy to say who the retail customer is, and she/he certainly is no longer just a phone number. In a typical household, someone plays the role of the primary customer, the person responsible for buying and paying for the services – the CFO of the household, if you like. But there can be multiple customers, each paying one or more bills representing portions of shared services. For example, Dad may pay for the cable TV while the teenage kids pay for the sports channel adding to the complexity.
Secondly, there are also administrators in the household who choose and administer individual products and services, the home-sysadmin, if you like. But this role can change from person to person depending on the product, and often the end users or consumers of the services are allowed to different things depending on the policy set by the home security admin (for example, no Internet after bedtime or access to adult sites) and enforced by services such as smart firewalls and certification/classification policies.

How to manage multiple roles?

Nowadays there is very little difference between a household and an SME but few service providers acknowledge this, and even if they do, how can they manage it all?
I’ve tried to help several service providers tackle this problem. They thought it was all about family and the actual relationships between the members of the household – Who is the dad? Who is the mum? Who are the kids? But what about Auntie Jean and Granny, and what about the au pair? How do these people fit into the picture, and what happens when little Katie moves out to go to college or perhaps when Mum and Dad separate?

The relationships between the people making up the household are in reality about as relevant to a service provider as the departmental structure or the shareholders and members of the board of an SME or large enterprise. What service providers must realize is that these ‘real world’ relationships are irrelevant, or if they are relevant it is not the role of the customer relationship management (CRM) system to manage them; it’s the responsibility of the account manager.

Households are organizations and the roles within the household are as dynamic as in any business. To manage this complexity, the service provider must:

Realize that the actual relationships between the parties are generally irrelevant except perhaps the roles of ‘responsible adult’ and ‘minor’;
Capture the functional roles such as Customer, Bill Payer and User and match these, where necessary, back to named (or even un-named) individuals; and
Record and deliver services in line with the involvement roles such as Chooser, Admin, Consumer that are set at the product level, more often than not by the parties within the household themselves.

The final step is perhaps perceived as the most complex, but in most multi-user products this is already handled by usernames and roles and things like single sign-on. All that needs to be done is to ensure that the customer service assurance and CRM systems have some kind of drill-through to the product so that any problems can be sorted out through a remote login.

Frameworx can help

The Frameworx Information Model (SID) already has all the structures defined that support these advanced concepts. Functional Roles are Party Roles that define the static roles played by individuals or people in relationship to a Customer Account. Involvement roles are also in the Information Model – an Involvement role can be played by a Party Role or a Resource Role, and Involvement Roles can be associated with Products, Services or Resources (customer premises equipment, for example) and these Involvement Roles can be linked to identities (usernames).
So what’s the difference between a household and a small business? The answer is not a lot. They are both complex organizations that need to be managed as such, but Frameworx is already configured to support this complexity.
- See more at: http://inform.tmforum.org/features-and-analysis/featured/2015/09/whats-the-difference-between-a-household-and-a-small-business/#sthash.QiESgSQ2.dpuf

The era of the digital ecosystem

What is a lot more complex for the service provider is the realization that the customer paradigm has to change.

How to manage multiple roles?

The relationships between the people making up the household are in reality about as relevant to a service provider as the departmental structure or the shareholders and members of the board of an SME or large enterprise. What service providers must realize is that these ‘real world’ relationships are irrelevant, or if they are relevant it is not the role of the customer relationship management (CRM) system to manage them; it’s the responsibility of the account manager.

Households are organizations and the roles within the household are as dynamic as in any business. To manage this complexity, the service provider must:

Realize that the actual relationships between the parties are generally irrelevant except perhaps the roles of ‘responsible adult’ and ‘minor’;
Capture the functional roles such as Customer, Bill Payer and User and match these, where necessary, back to named (or even un-named) individuals; and
Record and deliver services in line with the involvement roles such as Chooser, Admin, Consumer that are set at the product level, more often than not by the parties within the household themselves.

Frameworx can help

Not so long ago retail telecommunications customers had a single telephone number for a single line tied to a residential address with a single product/service associated. As far as the service provider was concerned, the customer and the household were synonymous with the phone number.

But for a small or medium enterprise (SME), the setup was different. There could be multiple phone lines possibly going to multiple addresses, a PBX, and services like hunting groups and call pick-up as well as the more conventional phone services.

Things started to change when retail customers began using the phone line for Internet and email – using technology like DSL rather than the old dial-up modems – in addition to making and receiving phone calls. This slow shift wasn’t too difficult to deal with for the service providers and some even managed to get the two services on a single bill.

The era of the digital ecosystem

Jump ahead ten or so years to the era of the ‘digital ecosystem’, and we have homes that have fixed-line connections capable of delivering high-speed broadband services that are consumed as streaming video and cloud services, as well as the more traditional phone, Internet and email services. On top of that households may also have digital TV set-top box and multiple 4G devices including tablets and phones. Now the cracks in the service providers’ approach to dealing with the household as if it were a single phone number with a single customer begins to show, and in fact are much more like yawning chasms than cracks!

The problems of getting all these services on a single bill the customer is trivial compared to the other aspects of the evolution of the digital ecosystem. ‘Customer’ is no longer synonymous with a (single) phone number, and the users of the 4G and Internet-enabled devices want to be able to seamlessly move services from one device to another. This means that all the devices must be related and integrated in some way, but frankly that’s just a technical problem.

What is a lot more complex for the service provider is the realization that the customer paradigm has to change.

First of all, it is not easy to say who the retail customer is, and she/he certainly is no longer just a phone number. In a typical household, someone plays the role of the primary customer, the person responsible for buying and paying for the services – the CFO of the household, if you like. But there can be multiple customers, each paying one or more bills representing portions of shared services. For example, Dad may pay for the cable TV while the teenage kids pay for the sports channel adding to the complexity.

Secondly, there are also administrators in the household who choose and administer individual products and services, the home-sysadmin, if you like. But this role can change from person to person depending on the product, and often the end users or consumers of the services are allowed to different things depending on the policy set by the home security admin (for example, no Internet after bedtime or access to adult sites) and enforced by services such as smart firewalls and certification/classification policies.

How to manage multiple roles?

Nowadays there is very little difference between a household and an SME but few service providers acknowledge this, and even if they do, how can they manage it all?

I’ve tried to help several service providers tackle this problem. They thought it was all about family and the actual relationships between the members of the household – Who is the dad? Who is the mum? Who are the kids? But what about Auntie Jean and Granny, and what about the au pair? How do these people fit into the picture, and what happens when little Katie moves out to go to college or perhaps when Mum and Dad separate?

The relationships between the people making up the household are in reality about as relevant to a service provider as the departmental structure or the shareholders and members of the board of an SME or large enterprise. What service providers must realize is that these ‘real world’ relationships are irrelevant, or if they are relevant it is not the role of the customer relationship management (CRM) system to manage them; it’s the responsibility of the account manager.

Households are organizations and the roles within the household are as dynamic as in any business. To manage this complexity, the service provider must:

Realize that the actual relationships between the parties are generally irrelevant except perhaps the roles of ‘responsible adult’ and ‘minor’;
Capture the functional roles such as Customer, Bill Payer and User and match these, where necessary, back to named (or even un-named) individuals; and
Record and deliver services in line with the involvement roles such as Chooser, Admin, Consumer that are set at the product level, more often than not by the parties within the household themselves.

Frameworx can help

The Frameworx Information Model (SID) already has all the structures defined that support these advanced concepts. Functional Roles are Party Roles that define the static roles played by individuals or people in relationship to a Customer Account. Involvement roles are also in the Information Model – an Involvement role can be played by a Party Role or a Resource Role, and Involvement Roles can be associated with Products, Services or Resources (customer premises equipment, for example) and these Involvement Roles can be linked to identities (usernames).

So what’s the difference between a household and a small business? The answer is not a lot. They are both complex organizations that need to be managed as such, but Frameworx is already configured to support this complexity.

The era of the digital ecosystem

What is a lot more complex for the service provider is the realization that the customer paradigm has to change.

How to manage multiple roles?

The relationships between the people making up the household are in reality about as relevant to a service provider as the departmental structure or the shareholders and members of the board of an SME or large enterprise. What service providers must realize is that these ‘real world’ relationships are irrelevant, or if they are relevant it is not the role of the customer relationship management (CRM) system to manage them; it’s the responsibility of the account manager.

Households are organizations and the roles within the household are as dynamic as in any business. To manage this complexity, the service provider must:

Realize that the actual relationships between the parties are generally irrelevant except perhaps the roles of ‘responsible adult’ and ‘minor’;
Capture the functional roles such as Customer, Bill Payer and User and match these, where necessary, back to named (or even un-named) individuals; and
Record and deliver services in line with the involvement roles such as Chooser, Admin, Consumer that are set at the product level, more often than not by the parties within the household themselves.

Frameworx can help

The era of the digital ecosystem

What is a lot more complex for the service provider is the realization that the customer paradigm has to change.

How to manage multiple roles?

The relationships between the people making up the household are in reality about as relevant to a service provider as the departmental structure or the shareholders and members of the board of an SME or large enterprise. What service providers must realize is that these ‘real world’ relationships are irrelevant, or if they are relevant it is not the role of the customer relationship management (CRM) system to manage them; it’s the responsibility of the account manager.

Households are organizations and the roles within the household are as dynamic as in any business. To manage this complexity, the service provider must:

Realize that the actual relationships between the parties are generally irrelevant except perhaps the roles of ‘responsible adult’ and ‘minor’;
Capture the functional roles such as Customer, Bill Payer and User and match these, where necessary, back to named (or even un-named) individuals; and
Record and deliver services in line with the involvement roles such as Chooser, Admin, Consumer that are set at the product level, more often than not by the parties within the household themselves.

Frameworx can help

The era of the digital ecosystem

What is a lot more complex for the service provider is the realization that the customer paradigm has to change.

How to manage multiple roles?

The relationships between the people making up the household are in reality about as relevant to a service provider as the departmental structure or the shareholders and members of the board of an SME or large enterprise. What service providers must realize is that these ‘real world’ relationships are irrelevant, or if they are relevant it is not the role of the customer relationship management (CRM) system to manage them; it’s the responsibility of the account manager.

Households are organizations and the roles within the household are as dynamic as in any business. To manage this complexity, the service provider must:

Realize that the actual relationships between the parties are generally irrelevant except perhaps the roles of ‘responsible adult’ and ‘minor’;
Capture the functional roles such as Customer, Bill Payer and User and match these, where necessary, back to named (or even un-named) individuals; and
Record and deliver services in line with the involvement roles such as Chooser, Admin, Consumer that are set at the product level, more often than not by the parties within the household themselves.

Frameworx can help

The era of the digital ecosystem

What is a lot more complex for the service provider is the realization that the customer paradigm has to change.

How to manage multiple roles?

The relationships between the people making up the household are in reality about as relevant to a service provider as the departmental structure or the shareholders and members of the board of an SME or large enterprise. What service providers must realize is that these ‘real world’ relationships are irrelevant, or if they are relevant it is not the role of the customer relationship management (CRM) system to manage them; it’s the responsibility of the account manager.

Households are organizations and the roles within the household are as dynamic as in any business. To manage this complexity, the service provider must:

Realize that the actual relationships between the parties are generally irrelevant except perhaps the roles of ‘responsible adult’ and ‘minor’;
Capture the functional roles such as Customer, Bill Payer and User and match these, where necessary, back to named (or even un-named) individuals; and
Record and deliver services in line with the involvement roles such as Chooser, Admin, Consumer that are set at the product level, more often than not by the parties within the household themselves.

Frameworx can help

NFV and SID

noreply@blogger.com (Andrew McFadyen) — Mon, 16 Nov 2015 13:06:00 +0000

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?

noreply@blogger.com (Andrew McFadyen) — Mon, 28 Sep 2015 10:51:00 +0000

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

Put PhoneNumber and PhoneNumberSpecification into the SID as concrete subclasses of Logical Resource and Logical Resource Specification respectively
Create an association from Contact Medium (Phone) to this class.
Create concrete subclasses of Product Offering and Product as “Contract Product Offering” and “Contract Product” to identify these key products.
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

noreply@blogger.com (Andrew McFadyen) — Fri, 07 Mar 2014 19:50:00 +0000

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.

Involvement Roles

noreply@blogger.com (Andrew McFadyen) — Tue, 08 Oct 2013 15:02:00 +0000

The class InvolvementRole was introduced in Release 12 of SID and is described in the SID document GB922_1UR_Users_and_Roles_R12-0v_1-3.pdf. It generalised a structure that had been in place in SID for a long time (since V6 at least) the ProductInvolvementRole.

The diagram above is taken from SID V9.

In SID V12 things changed ProductInvolvementRole became a sub-class of InvolvementRole and it is InvolvementRole that either a CustomerAccount, PartyRole or ResourceRole can be associated (not more than one of these – no “arc” notation showing exclusivity on associations in UML unfortunately).

The idea is that there are actors that can take roles in the use cases and life-cycles of Products (Subscriptions), Resources and Services, and these actors can be Parties (through PartyRoles) Resources (through ResourceRoles) and CustomerAccounts.

Looking at this from the PartyRole point of view; this is an excellent idea as it allows the different people involved in a Product, Service and Resource to be defined; the Users, the Administrators, the Engineers etc etc.

A CustomerAccount can have roles, other than direct ownership; the default role, I guess, between a Product and CustomerAccount (note there is no simple association between CustomerAccount and Product). A Product can be paid for by two or more CustomerAccounts as in Split Billing whereby one account pays for, say the monthly recurring charge while the other account pays for any out of tariff charges.

It is not so clear how this level of involvement can get down to the Service level so that one CustomerAccount ‘owns’ a Service while the other pays for it as according to classic SID the payment is for Products rather than Services, but, hey, it’s “symmetrical” and logically and generically pleasing, so let’s leave it there...

The roles a Resource can play and what involvement these can have is not so immediately obvious; however many CSPs use the phone number or MSISDN to identify a Product (subscription) and this can be modelled as a ResourceInvolvement, but a less obvious InvolvementRole is to do with identities – usernames and email addresses. These are logical resources and these are relevant to Products, Services and I guess Resources. For Physical Resources it could be tempting to use this for the BOMP (bill of materials) structure of a Resource, but there are far better ways of doing this within the Resource Domain. I think again this is useful when talking about security – dongles and other security devices could have InvolvementRoles at all 3 levels (Product, Service and Resource). I wonder if this could even be extended to include DRM.

I wonder if this approach could, should be extended to the CustomerAccount itself. There a number of PartyRoles that can be involved in the use cases and life cycle of a CustomerAccount from the SalesRep or AccountManager to the PartyRole that signed the contract, theperson responsible for paying the bill. Then again there can be multiple CustomerAccounts involved in a CustomerAccount – parent account for an account hierarchy, linked account for other more sophisticated split billing – a linking PAYG and Pay Monthly accounts for example, and finally if ResourceRole can be used to provide security through Usernames etc then this is obviously extended to CustomerAccount.

Therefore I believe that the SID should include a new class CustomerAccountInvolvementRole that is defined as follows:

An extension to SID to better model the different involvement roles played by Actors in a Customer Account - examples include "Contract Signer", "Bill Payer", "Account Manager" etc.

CustomerAccountInvolvementRoles can also be played by other CustomerAccounts - allowing a hierarchy of accounts to be set up for example.

CustomerAccountInvolvementRoles can also be played by ResourcesRoles where for example a security device is used to identify a CustomerAccount.

Finally a thought about PartyRoles: You might say “surely we’ve got PartyRoles that define the type of roles played by a party in a CustomerAccount, for example?” And you would be right; we’ve got all these Party Roles defined in SID:

•   Customer
•   Competitor
•   Employee
•   OrganizationPost
•   Partner
•   ProjectPartyRole
•   ServiceProviderEmployee
•   Supplier
•   ThirdPartyPayeeAgency
•   ValueNetworkRole
•   WorkforceEmployeeRole

Which of these roles can be in an InvolvementRole? Well obviously all of them – or perhaps it should be none of them. The User and Roles document GB922_1UR_Users_and_Roles studiously avoids the issue and talks about “Actors” rather than PartyRoles – and perhaps that is right.

First of all the PartyRoles listed above are invariant across Products, Resources, Services and CustomerAccounts – a Supplier is always our Supplier, it doesn’t depend on which Product (subscription) we are talking about. Even Customer is invariant – it is always the Customer across all CustomerAccounts, Products, Resources etc.

What the InvolvementRole allows us to do is to define fine grained roles that are different on different CustomerAccounts, Products, Resources etc. So we can have a PartyRole playing different roles on different CustomerAccounts, Products, Resources etc.

So which PartyRole is playing which InvolvementRole? It still is a little confusing having these different PartyRoles playing different InvolvementRoles – perhaps the SID needs a new PartyRole concrete sub-class called “Actor” and it is the only(?) PartyRole that can play InvolvementRoles.

What do you think?

SID Q&A - Question 10

noreply@blogger.com (Andrew McFadyen) — Tue, 23 Jul 2013 11:32:00 +0000

This is the tenth in a series of questions from SO4IT a Swedish IT consultancy company who are using GigaSpaces technology to build a SID based Order Management system for Communications Service Providers.

In this Q&A we discuss the practicalities of using ProductSpecification to record and manage the configuration of complex Products.

So4It: I'm trying to grasp the correct way of mapping ProductSpecifications and ResourceSpecifications to each other. For example, take SIM-card as the resource in question since this is the resource that creates the biggest challenge for me at this point, and for ProductSpecification I choose the MobileTelephony.

Here is the problem background:

A typical ProductOffering for the MobileTelephony-spec will be shown in external interfaces (webshop) as a Product where you can choose the form-factor of the SIM, since you want to make sure you get the correct form-factor that matches the terminal where you will use this SIM.

This means that somewhere in the ProductSpecification structure there will be a Characteristic and a number of CharacteristicValues that will be translated into an option for the webshop-user.

At the same time the ResourceSpecification holds a REQUIRED field called partNo. And a SIM-card partNo will without any question point out a SIM-card of one specific form-factor.

Actual problem:

For me this means that I can't put a ResourceSpecificationCharacteristic holding a bunch of alternative form-factors on my ResourceSpecification for the SIM since each ResourceSpecification will contain one single partNo, and each partNo corresponds to just one form-factor.

So I can see no other alternative than to put the form-factor Characteristic on my ProductSpecification. But once I've done that I can't see any use for the reference in the MobileTelephonySpecification to the SIMResourceSpecification, rather it just complicates things.

So how would you model this? Skip the ResourceSpecification reference and by that completely sever the link between the Resource-Domain and the Product-Domain when it comes to Specifications (at least for SIM), or keep the link but by doing that be forced to create some kind of mock-up duplicate ResourceSpecification for the SIM, that doesn't contain any partNo that actually means anything and add ResourceSpecificationCharacteristics for the form-factor to this mock-up? Both ways seem kinda wrong to me, is there a third alternative?

Andrew: You have raised an interesting point; however it must be remembered that the relationship between Product Specification and Resource Specification is m:m so that there has to be an association class that "resolves" this m:m. The association class will list for each product specification all the valid Resource Specs part numbers (probably with validity dates). The association class therefore acts like the Product Spec Characteristics that you envisaged.

I do still see a problem though - if there is more than one "type" of ResourceSpec involved with the ProductSpec then you will see all the part numbers from both ResourceSpecs.

But the "terminal" is a Resource which has a ResourceSpec and that ResourceSpec "requires" a particular SIM type (ResourceSpec) given by the part number. There is a m:m recursive (self) relationship on ResourceSpec that needs to be resolved by an association class that would have a "type" (Required, Forbidden, Optional). So the Terminal type needs to be an input on the Product selection process (or part of the Product selection) which would be used to select the correct SIM type part number which would be to display the user.

So4It: So this is what I have today

In the ProductSpecification I have a ResourceSpecificationReference that contains the ResourceSpecificationId and the order (if any) it should be presented in.
In the CompoundResourceSpecification I have a Set of ResourceSpecificationReference's that dictates what ResourceSpecification is included in the CompoundResourceSpecification

Andrew: OK - so you have in data modelling language "denormalised the structure" - that's OK and sensible for an on-line app.

So4It: So the association class sound like the ResourceSpecificationReference that I have. There I can put any information I want to be associated with the association between the ProductSpecification and the ResourceSpecification right?

Andrew: Right.

So4It: It sound like you are saying that in the ResourceSpecificationReference you should always have information about, what is valid to use in the ResourceSpecification it is pointing to.

Andrew: Yes, but this is in addition to the Compound Resource you have created. The new association class on that resolves the "m:m recursive" (self) relationship would say which Resource is compatible with other resources - for example which Terminal devices need Large SIMs and which need Small SIMs.

So4It: So in the case we are talking about below we will have the following,

We have a compound resources specification for PhysicalSimCard that has 2 ReourceSpecification's, 1 for the SimCard with form LARGE and another for the SimCard form SMALL. The compound ResourceSpecificationReference will specify that 1 of its ResourceSpecifications has to be selected but only 1.

Andrew: OK - so you are saying that there are Large and Small SIMs and one must be selected, but the structure I am talking about (that resolves the m:m recursive relationship could be used to say which type of SIM should be used with what kind of Terminal, but of course you may have another way of enforcing this business rule.

So4It: So what you are saying here is that in the CompundResourceSpecification we should have a class describing what included ResourceSpecifications are compatible with each other. How would we do this case?

CompoundResouceSpecification1
      |
      |-------CompoundResouceSpecification2
      |                    |
      |                    |-------------------AtomicResourceSpecification1
      |                    |-------------------AtomicResourceSpecification2
      |                    |-------------------AtomicResourceSpecification3
      |
      |-------AtomicResourceSpecification4

AtomicResourceSpecification4 can only be select together with AtomicResourceSpecification1so in the CompoundResouceSpecification1 I would have a class (what is a good name of r it?) that says AtomicResourceSpecification4 belongs with AtomicResourceSpecification1 for example?

Andrew: To associate AtomicResourceSpec1 with AtomicResourceSpec4 you need a new class ResourceSpecCompatibility, it would have the following attributes

resourceSpec1.id
resourceSpec2.id
compatibiltyType (valid values = Required, Forbidden, Optional)
validFromDate
validToDate

So for your example:
resourceSpec1.id = AtomicResourceSpec4
resourceSpec2.id = AtomicResourceSpec1
compatibiltyType = Required
validFromDate = 01-Jan-2000
validToDate = 31-Jan-2099

and to make sure it can't be combined with others
resourceSpec1.id = AtomicResourceSpec4
resourceSpec2.id = AtomicResourceSpec2
compatibiltyType = Forbidden
validFromDate = 01-Jan-2000
validToDate = 31-Jan-2099

resourceSpec1.id = AtomicResourceSpec4
resourceSpec2.id = AtomicResourceSpec3
compatibiltyType = Forbidden
validFromDate = 01-Jan-2000
validToDate = 31-Jan-2099

So4It: Where is this class stored on the CompositeResourceSpecification ?
In the case I explained where would it be stored in the hierarchy? In CompoundResouceSpecification1 and if not then where?

Andrew: Your structure would remain unchanged - I am proposing an additional structure, but I guess it could be implemented as below

CompoundResouceSpecification1
      |
      |----CompoundResouceSpecification2
      |              |-----AtomicResourceSpecification1
      |              |                   |------Required, AtomicResourceSpec4
      |              |
      |              |-----AtomicResourceSpecification2
      |              |-----AtomicResourceSpecification3
      |
      |----AtomicResourceSpecification4
      |               |------Required, AtomicResourceSpec1

So4It: I'm sorry I don't understand what you mean ere. I understand the class you are proposing but I just have a hard time understanding where to store it. I guess the class

public class ResourceSpecCompatibility{
        private Integer resourceSpecificationId1;
        private Integer resourceSpecificationId1;
        private CompabilityType compabilityType;
        private Date from;
        private Date to;}

obviously has to exist.   What I am thinking is where to store it. There are a couple of options

We store it independent from the ProductSpecification structure and fetch it using the id of the ProductSpecification
We could store it on a CompositeProductSpecification if we assume that compatibility will only exists between ProductSpecification that has a common CompositeProductSpecification parent but can we say that you think?

As I see it 1) is more flexible but makes it less performant when we need to collect the data.

Andrew: I'm not an expert on physical design, so I wouldn't like to comment further on how to implement the information. I just know that the hierarchy you have defined needs to be augmented with a structure that defines how Resources in the hierarchy (or other hierarchies) can be related.

SID Q&A - Question 9

noreply@blogger.com (Andrew McFadyen) — Sat, 13 Jul 2013 13:49:00 +0000

This is the ninth in a series of questions from SO4IT a Swedish IT consultancy company who are using GigaSpaces technology to build a SID based Order Management system for Communications Service Providers.

In this blog we discuss Buckets and Quotas, extensions need for the SID to support prepay and other complex forms of payment and allowances.

So4It: My CTO has told me about buckets and is proposing to use these to allow us to manage allowances. What does the SID have to say about Buckets?

Andrew: This is an interesting area and I’ve been doing a lot of thinking and work on it over the last 8 or 9 years.

The fact is that most telcos BSS’s are far behind on technology - many are still using billing systems that were developed in-house in the 1990's or earlier and rdbms is everywhere in the BSS side of the business. On the OSS side things are very different. The industry has been fast to adopt new technologies and devices like the IN use very hardware and software to deal with the high volumes.

Below is an excerpt of a document I am working on in my spare time, a “A Rough Guide to SID Implementation for SOA Integration” which together with another document I’ve started writing “A Rough Guide to Using the SID for Application Integration” could, one day, form a sort of “SID for Dummies”.

As you will see from the description and model your CTO is on the right track. The model below (at the moment) doesn’t include Usage classes, but that I believe is fairly straight forward. The Rating and Guiding process first of all examines the UDRs and turns them into CFS Usages with basic pricing information applied and then attaches them to the relevant CustomerAccount(s) and applies the ProductPricing applying the quotas/allowances and product specific rating/discounting to create what the SID calls ProductUsage.

The deduction of the cost of these Usages from the Buckets can either happen in real-time as with IN/PAYG products or monthly as part of the Pay Monthly billing cycle.

----------------------Excerpt begins-----------------------

Prepay classes

The SID has nothing to help with “Pay as You Go” (PAYG, or Prepay). This is a little shocking considering how long SID has been in use in mobile phone companies. There is a little philosophical issue about whether it is the CustomerAccount that it is prepaid or the Products under the account; I favour the latter as this will support convergent billing in the future, or rather the present as it is perfectly technically possible for a Customer to have a monthly postpaid subscription for say talk time, and have a PAYG subscription for data (though few CSPs offer this). Unfortunately most CSPs cannot get their heads around the idea of having just “Customers” (or rather CustomerAccounts) and having the prepaid/postpaid label associated with the Product rather than with Prepaid Customer and Postpaid Customer.

To handle Prepaid (PAYG) customer (accounts), or even better, Product, you need to consider the kind of “refill”/“reloads”/”top-ups” the customer can make. The simplest reload is just money to be credited to the account; however most CSPs offer a range of reloads or “packs”:

Data packs that offer, say 500Mbytes, 1Gbyte or 2Gbytes
Message packs that offer, say 500 messages
iTunes packs that buy a fixed number of downloads from iTunes store
Combinations of the above

Some CSPs have certainly considered prepay packs for post pay customers for example I think some offer overseas calls that pre-pay for calls while roaming abroad.

Each of these types of reloads has its own balance associated with it. A customer can be out of money for talking (a balance of 0 in minutes, or money) but still be able to browse the internet or send messages because he/she has a non-zero balance on these services. In fact some CSPs even let their prepaid customer go “into the red” on some services if they for example pay by credit card.

Each refill/reload/top-up is added to a specific “bucket” that holds the balance for a given service or set of services. This balance, be it in Money, Mbytes, or a count of units is then debited by use of the appropriate service. Some buckets can be very specific; for example if a customer has a “Message” bucket then when he/she sends a SMS or MMS its balance is debited until it gets to zero. Once this balance is exhausted another bucket or balance – say the general “Money Bucket” takes over and it too is debited for messages (and calls) until it also reaches zero. So there can be a precedence or preference between using one bucket over the other.

The SID has introduced the idea of Allowances in a complex structure (see SID class AllowanceProductPriceAlteration) which is OK (if a little clumsy) for postpaid but does not work well for Prepaid or real-time billing where topups would credit the AllowanceProductPrice and usage would debited it.

In line with industry thinking on convergent billing I have introduced the concept of CustomerAccountBuckets. These buckets are used to hold the balances which can be associated with either a Product or set of Products or CustomerFacingService or set of CustomerFacingServices.

Here is a class diagram I created for my new ABE, Customer Account Bucket.

The other new class is an extension class for CustomerAccount, CustomerAccount_AMCF to hold the prepaidPostpaidIndicator a flag to show the type of account (but I still don’t like it).

Eagle eyed readers may have also noticed that I have added a direct link between CustomerAccount and Product that shows which account owns the “subscription”. There is still of course the more generic method of linking the two classes through the CustomerAccountProductInvolvementRole class which this does not replace, but rather ‘specialises’ for the most common relationship between these classes – “ownership”.
----------------------Excerpt ends-----------------------

SID Q&A - Question 8

noreply@blogger.com (Andrew McFadyen) — Mon, 24 Jun 2013 11:14:00 +0000

This is the eight in a series of questions from SO4IT a Swedish IT consultancy company who are using GigaSpaces technology to build a SID based Order Management system for Communications Service Providers.

In this Q&A we discuss start to discuss ProductOfferPrice, the mechanism used in Frameworx SID to apply prices to ProductOfferings as well as ProductCatalogue.

So4It: Now we come to the pricing of our Product Offerings.

As I understand it the ProductSpecificationCost is the cost for the operator to install the product it specifies into their network including maintenance etc. The ProductOfferingPrice is partly based on it (since the price has to cover the cost of cause) but the ProductOfferingPrice is the end price to the customer, right? So in practice one can skip ProductSpecificationCost and just have ProductOfferingPrice right?

Andrew: Correct on all counts. The ProductSpecificationCost is not mandatory and would only be used in situations where you were doing profitability analysis.

So4It: The ProductOfferingPrice includes all types of price including one-time fee, monthly fee etc so when building a complete system the process of creating a ProductOfferingPrice the creator of the ProductOffering would check all the ProductSpecificationCosts, one-time and re-occurring, and create a ProductOfferingPrice that will cover it plus the profit?

Andrew: Yes, theoretically – but practically the complete ProductSpecificationCost isn’t known – R&D costs, overhead costs etc may not be known.

So4It: I can see in the SID that a ProductSpecCharacteristicValue can affect the product offering price and I want to understand this relationship a bit more since I think we have that case.

"The customer selects mobile telephony with X Free traffic + a iPad mini with either 16 GB memory or 32 GB memory"

So of cause the price will be different and the question here is should we model this as 2 different product offerings or as one with the price depending on what ProductSpecificationCharacteristicValue the customer selected, 16 GB or 32 GB.

Can you please elaborate on how the ProductOfferingPrice would be structured for this case? Would these be 2 different ProductSpecifications or will it be one with a ProductSpecCharacteristicValue that decides if it is 16GB or 32GB?

Andrew: I would model this as one ProductSpec with a ProductSpecCharacteristic of “MemorySize” with 2 ProductSpecCharacteristicValues of “16GB” and “32GB”. I would however then create 2 ProductOfferings say “iPadMiniStd” and “iPadMiniDelux” the ProductOfferingProductSpecCharValueUse for “iPadMiniStd” would be associated with “16GB” and for “iPadMiniDelux” it would be associated with “32GB” (in the same way as my example using Widgets had “MonoWidget” associated with “black” and “white” while “RedWidget” was associated with “red”). Then I would create separate prices for “iPadMiniStd” and “iPadMiniDelux”. This of course requires the user of the pricing app to apply some common sense and it would be possible to make the “iPadMiniDelux” cheaper than “iPadMiniStd”.

So4It: One idea I’ve got since the reference between ProductOfferingPrice and ProductSpecification exists is to have a ProductOffering with a CompositeProductSpecification containing one ProductSpecification for the 16GB and one ProductSpecification for the 32 GB and then when the customer selects one we can use the price that is linked to the selected ProductSpecification seem logical ?

Andrew: You could go to the extreme of making “iPadMemory32GB” and “iPadMemory16GB” different ProductSpecs each with its own ProductSpecificationCost and then have these linked to the “iPadMini” ProductSpec with a ProductSpecRelationship type of “alternatives” and then to build in pricing rules to ensure that a ProductOffering cannot have a ProductPrice of less than the sum of the ProductSpecificationCosts of the components without some sort of override – but that makes everything complex – but it is possible.

If you want to do what you are describing then I would use ProductOfferings rather than ProductSpecs and add ProductOfferings to a “basket” that has its price increase as you add options which are driven by the ProductOfferingRelationship rather than ProductSpecificationRelationship, rather than changing the price of the ProductOffering. This would also help where a customer can choose to have multiple sub-component ProductOfferings. Have you seen how Dell does its p.c. configuration pricing on its website? It looks very much like this.

So4It: So a question here is how does the reference between ProductOfferingPrice and ProductSpecification look like? ProductOfferingPrice and ProductSpecificationCharcteristicValue look like? Will this be a ProdSpecCharValueUse maybe?

Andrew: As I said above I wouldn’t use the ProductSpecification to drive the ProductOfferingPrice; if anything use the ProductOffering – but remember you are not changing the “price” you are changing the value of the CustomerOrder as the customer adds ProductOfferings to the order. The unit price of the Product Offerings in the CustomerOrder remains the same (for all customers) but in the CustomerOrder there may be discounts applied as a result of the combination of products in the order or as a result of some sort of negotiated discount. This is modelled on the CustomerOrder through the BusinessInteractionItemPrice.

So4It: I mean how do you model this in real classes?

Andrew: Look at the documentation on ConceptWave’s products and Dell’s and Amazon’s websites for real world examples of how product pricing and configurators work.

In terms of real classes then I believe you should forget the ProductSpecificationCost – it is a “red herring” or something that is leading you off the correct way of implementing the pricing. Use low level ProductOfferings “Options” that can be associated with higher level “EntryLevel” ProductOfferings and use the ProductOfferingPrice to accumulate the price on the CustomerOrder. If discounts are applied then you can use BusinessInteractionItemPrice to record them.

There is a very complex area of the SID call “Policy” which I am sure can be used to define the rule-base for this, but frankly, I’ve never used it and I think it is overly complex, and I’ve not confidence that it has ever been used in practice.

My advice is “KISS” (keep it simple, stupid). The SID makes everything very complex to allow for every possible circumstance. If you are building a specific app for say pricing and configuring end-user products then you can afford to model it in a simpler easier to use manner confident that it would never be used to price complex wholesale network bandwidth pricing products with SLAs and other penalties.

So4It: Then we come to the GeographicArea and DistributionChannel. As I see it a ProductCatalog has a SalesChannel and GeographicArea it is sold in and from that the price inherits them correct?

Andrew: Correct. See the diagram below

The key thing to notice in this diagram is that the ProductCatalogProductOffer which shows which ProductCatalog a Product Offer appears in is linked to the ProductOfferingPrice (though through a m:m association). This therefore allows a ProductOffering to appear in multiple ProductCatalogs with different (or the same) prices in each.

So4It: Why would we then keep these on the ProductOfferingPrice, is it because we might reuse the price in other ProductOfferings?

Andrew: Yes, see my answer above.

So4It: When it then comes to instantiating the product in the order manager I guess that the ProductOfferingPrice structure more or less becomes the same in the install base but as a Product Price instead correct?

Andrew: ProductPrice is the price an individual customer paid, or has agreed to pay in the case of recurring charges or the price for Usage. This can vary from the ProductOfferingPrice because of negotiated discounts etc. So, yes, you are correct the installed base price is reflected in ProductPrice while the current “catalogue price” is the ProductOfferingPrice.

SID Q & A - Question 7

noreply@blogger.com (Andrew McFadyen) — Wed, 12 Jun 2013 06:50:00 +0000

This is the seventh in a series of questions from SO4IT a Swedish IT consultancy company who are using GigaSpaces technology to build a SID based Order Management system for Communications Service Providers.

In this Q&A we explore more about the use of Characteristics and CharacteristicValues to describe ProductSpecifications and then we move on to Usage and then to Promotions.

So4It: Can you please explain the entities ProductSpecCharUse and ProdSpecCharValueUse and how they are used?

Andrew: A ProductSpecCharacteristic defines a generic characteristic that can be used by any Product Spec. In my example there is a ProductSpecCharacteristic called “Colour” and another called “Shape”

ProductSpecCharacteristic: Colour

ProductSpecCharacteristic: Shape

The ProductSpec for “Widget” uses “Colour” but not “Shape” while “WidgetInaBox” uses both of these characteristics – (“Shape” is not relevant to “Widget”)

The ProductSpecCharacteristic “Colour” has 4 valid values as defined by ProductSpecCharValue:

Black, White, Red and Green

But Green is only relevant to “WidgetinaBox” while the other colours are used by both Widget and WidgetinaBox as shown by the data in ProductSpecCharValueProductSpecCharUse. Thus the value in ProductSpecCharValueProductSpecCharUse tells which of the ProductSpecCharValues apply to a given ProductSpec.

So4It: We are now thinking about how to specify usage for a product. The UsageSpecification specifies how usage should be applied to usage of for example a product.

I have a lot of questions on how the UsageSpecification and the ProductSpecification are connected. When a customer chooses a produce offering we send the order to the order manager and we provision the necessary entities in the network. The usage data starts coming in and we store it on the product and/or service it refers to, but is this where the usage specification comes into the picture? We will create usage entries using the usage specification and in that case how do we know what usage specification to use for a certain product/service the usage is referring to?

Andrew: Usage is a relatively new part of the SID and probably not as rigorously defined as the other areas. Generally in telecoms companies the usage information in provided as UDRs (CDRs (Call Detail Records) for voice usage and IPDRs for data usage (internet Data Records)). The process of applying the correct charges to these usage records is performed in a set of specialised processes known as Mediation, Guiding and Rating. These processes do not work on data as shown in the SID as they have to process millions and millions of records a minute and the SID’s highly generic and normalised structures would prevent that throughput from happening.

To quote the SID documentation on usage:

“Normally, when a usage event occurs, it is stored in a network element, for instance in a switch, router, gateway or in an application system. Resources (applications, network and computing capabilities) usually store usage data in proprietary formats that are not understood by external systems such as billing systems. Depending on the polling strategy, a mediation engine connects to resources, collects usage data and formats them into a format understood by the billing system. Outputs of a mediation engine are Usage Detail Records (UDRs). Examples of UDRs are call Data Records (CDRs – used to describe usage details of voice call services and Internet Protocol Detail Records (IPDRS – used to describe usage details of Internet Protocol based services). In ...... we will use the Usage abstract business entity to describe any resource- service- or product-based usage that the external system can read update and process.”

The diagram below shows how the UsageSpecification is “theoretically” linked to ProductSpecification:

I say “theoretically” because the SIDs view of the process does not reflect what goes on in reality. In reality the Rating engine processes the UDRs based on Service Usage assigning a cost for the usage of the given service (making a phone call, receiving a phone call) depending on the time of day, day of week, duration of usage, location of usage, source and destination of usage etc etc.

When the Billing system receives the rated UDRs it then looks at the CustomerAccount and Product (subscriptions) and adjusts the costs applied by rating depending on the discounts and allowances provided by the ProductPrice.

So the mapping of Usage to Product is the last step in the process, not the first in the “real world” because of the volume of data involved and historically it wasn’t feasible to do the full Rating and allocating the allowances and discounts in near-real time.

The UsageSpec is a SID specific way of linking the Product Usage to the Service and Resource Usages and it does not reflect the real-world.

I think you should follow the industry standard of mapping the usage to the Service used (Rating) and then apply the allowances and discounts for usage (Billing).

So4It: We are thinking about how to assign cost to a product. As I understand it the ProductOfferingPrice should specify all the costs related to the product for the customer. In that case the product offering has implicit knowledge of what product specification exists in it.

For example if the product offering has "1 modem", "1 mobile telephony" etc the product offering price might be "A one-time fee off 40€ for the modem", "A reoccurring fee of 12€ / hour for the mobile telephony" etc. But shouldn’t we link this to the product specification somehow?

As I understand it from the SID is that the ProductSpecificationCost is the cost for creating and maintaining the product and not the price for the end customer. Which is logical since if we set it on the product specification it will be the same for every product offering using it.

Andrew: You are quite right – there should be some way of linking the price for usage to the usage element of a ProductSpec. In your definition of the product you have decided to put the usage in a separate ProductSpec; this is perfectly acceptable and 100% what SID allows. My personal preference is to align usage to ServiceUsage as it is the services that are getting used not the product. SID has been very vague here; I guess because there are so many different ways of defining the price and so many different organisations have done it differently that the definition had to be vague. This however allows you to implement pricing any way you like.

So4It: In the SID the SalesChannels is relate in a many-to-many relationship with the product offering; is that correct? Somehow I thought it would be on the ProductCatalogProductOffering entity that is the many-to-many class that relates product catalogue to product offering?

Can you please elaborate a bit on the sales channel and marking parts of the SID. We will have “invite” campaigns where the inviter earns credits when he/she gets us new customers. So I am thinking we will have a sales channel that has a marketing campaign we call InviteMarketingCampaign. In some cases we also have existing customers that gets credits from sending invites to friends. We need to record these invites and I was thinking about storing them on the customer account. So do you have any input on how to implement invites in the SID?

Andrew: Product Catalogue is another new area that is evolving; there are working groups meeting every week to discuss it and I guess it will change in the next release. There is definitely some sort of linkage between the Catalogue and the SalesChannel, but it hasn’t been defined yet. The Sale&Marketing Domain has been very under developed for a long time and the relationship between ProductOffering and SalesChannel was defined back in the early days of SID before any work was done on ProductCatalogue. I think you are correct and you can model a linkage between ProductCatalogue to SalesChannel rather than from ProductOffering to SalesChannel.

The Invites are “promotions” and as such are in fact ProductOfferings. When you give someone an Invite you are provisioning a Product on their CustomerAccount if they are an existing Customer or will provision it when they become a Customer if they are not yet a customer.

This promotional Product will add Allowances or Discounts that will be applied during billing.

The modelling of the Campaign area of SID is not good – I did some work in this area a few years ago but it was not submitted to the TMForum, and so is not part of SID.

SID Q&A - Question 6

noreply@blogger.com (Andrew McFadyen) — Fri, 07 Jun 2013 13:49:00 +0000

This is the sixth of a series of questions from SO4IT a Swedish IT consultancy company who are using GigaSpaces technology to build a SID based Order Management system for Communications Service Providers.

This is a long and complex post in which So4It asks some very good questions that get to the heart of using the SID in the real world.

So4It: Looking at the SID model of CustomerOrder I see the following:

A CustomerOrder is compromisedOf CustomerOrderItems
A CustomerOrderItem is-a BusinessInteractionItem
0..N BusinessInteractionItem involves 0..1 ProductOffering
0..N BusinessInteractionItem involves 0..1 Products

This means that we somehow are associating a ProductOffering or a Product with the BusinessInteractionItem e.g. CustomerOrderItem.

So let’s review how a CustomerOrder comes to be: a CustomerOrder is created when a customer decides he/she wishes to purchase a product from our web page. He/she then chooses a ProductOffering and places the order. A ProductOffering will have 0..N ProductSpecifications and with each ProductSpecification there will be 0..N ProductSpecificationsCharacteristic(s) associated. Right so far?

Andrew: Remember Business Interaction Item is a multipurpose class – Product could be referenced on a Problem report. Additionally a Customer Order can alter the state of a Product (subscription).

So far as a ProductOffering is concerned, No a ProductOffering will have 0..1 ProductSpecifications and a ProductSpecification has 0..N ProductOfferings. A ProductOffering is the commercial representation of one and only ProductSpec and a ProductSpec can be sold as one or more ProductOfferings

So4It: Q1: A CustomerOrderItem represents what, aProductOffering? If so it must also hold all the ProductSpecificationCharacteristicValue(s) for all the ProductSpecificationCharacteristic for all the ProductSpecification(s) involved in the ProductOffering. The question is then how do I know which one belongs to which ProductSpecification.

I can see that there are a couple of choices:

In the ProductSpecificationCharacteristicValue I place and id to the ProductSpecificationCharacteristic it belongs to and to the ProductSpecification it belongs to. I am assuming here that 2 or more ProductSpecification might have the same ProductSpecificationCharacteristic so I cannot just assume there is a single ProductSpecification in the CustomerOrderItem
A ProductSpecification and for each ProductSpecification we have the selected ProductSpecificationCharacteristicValue in each CustomerOrderItem.

My question is where does the ProductOffering belong in this hierarchy?

In the CustomerOrderItem, and if so explain how you solve the point 1) above
In the CustomerOrder, what do we then do if it is a BundledProductOffering does it become multiple orders…I know that cannot be the case.

In summary to continue I need to understand how to build the CutomerOrder -->; CustomerOrderItem relationship. And with that I mean what do I place in each of them. I guess there will be a number of sub-classes to CustomerOrderItem.

I can even see that a CustomerOrder might contain both CustomerOrderItem that represents the ProductOffering and CustomerOrderItems that represents the ProductSpecification. If so do we not have to keep the structure between them in any way or can we just say all these order items has to go through.

Andrew: First of all, this diagram is taken from the “standard” SID:

What is showing is that we can say for a given ProductOffering what ProductSpecCharacteristics are being used (shown through the association ProductOfferingDetermines). Note this is a m:m relationship so it needs to be resolved by an association class ProductOfferingProductSpecCharUse which shows exactly which ProductSpecCharteristic is being used by this ProductOffering.

The actual ProductSpecCharacteristicValues being set by the ProductOffering are not shown in SID. This is an omission (the SID has a number of “holes” in it).

We need to extend the model

To explain this: Imagine we have a ProductSpec for a “widget” which can coloured Black, White, or Red. We create 2 ProductOfferings:

“RedWidget” which is coloured Red, only ,
“MonoWidget” which can be Black or White.

So we have the following instances of the classes:

ProductOffering: MonoWidgetBox
ProductOffering: RedWidgetBox

ProductSpec: WidgetinaBox
ProductSpec: Widget
ProductSpec: Box

ProductSpecCharacteristic: Shape
ProductSpecCharacteristic: Colour
ProductSpecCharacteristic: Wrapping

ProductSpecCharValue: Shape:Round
ProductSpecCharValue: Shape:Square
ProductSpecCharValue: Colour:Red
ProductSpecCharValue: Colour:White
ProductSpecCharValue: Colour:Black
ProductSpecCharValue: Colour:Green
ProductSpecCharValue: Wrapping:Paper
ProductSpecCharValue: Wrapping:Plastic

ProductSpecCharUse: WidgetinaBox:Colour
ProductSpecCharUse: WidgetinaBox:Wrapping
ProductSpecCharUse: Widget:Colour
ProductSpecCharUse: Box:Shape

ProductSpecCharValueProductSpecCharUse: WidgetinaBox:Colour : Colour:Green
ProductSpecCharValueProductSpecCharUse: WidgetinaBox:Colour : Colour:White
ProductSpecCharValueProductSpecCharUse: WidgetinaBox:Wrapping : Wrapping:Paper
ProductSpecCharValueProductSpecCharUse: WidgetinaBox:Wrapping : Wrapping:Plastic
ProductSpecCharValueProductSpecCharUse: Box:Shape : Shape:Round
ProductSpecCharValueProductSpecCharUse: Box:Shape : Shape:Square
ProductSpecCharValueProductSpecCharUse: Widget:Colour : Colour:Red
ProductSpecCharValueProductSpecCharUse: Widget:Colour : Colour:White
ProductSpecCharValueProductSpecCharUse: Widget:Colour : Colour:Black

ProductOfferingProductSpecCharUse: MonoWidgetBox:WidgetinaBox:Wrapping
ProductOfferingProductSpecCharUse: MonoWidgetBox:WidgetinaBox:Colour
ProductOfferingProductSpecCharUse: MonoWidgetBox:Widget:Colour
ProductOfferingProductSpecCharUse: MonoWidgetBox:Box:Shape
ProductOfferingProductSpecCharUse: RedWidgetBox:WidgetinaBox:Wrapping
ProductOfferingProductSpecCharUse: RedWidgetBox:Widget:Colour
ProductOfferingProductSpecCharUse: RedWidgetBox:Box:Shape
ProductOfferingProductSpecCharUse: RedWidgetBox:WidgetinaBox:Colour

ProductOfferingProductSpecCharValueUse:
MonoWidgetBox:WidgetinaBox:Wrapping : WidgetinaBox:Wrapping : Wrapping:Paper
MonoWidgetBox:WidgetinaBox:Wrapping : WidgetinaBox:Wrapping : Wrapping:Plastic
MonoWidgetBox:WidgetinaBox:Colour : WidgetinaBox:Colour : Colour:Green
MonoWidgetBox:WidgetinaBox:Colour : WidgetinaBox:Colour : Colour:White
MonoWidgetBox:Widget:Colour : Widget:Colour : Colour:White
MonoWidgetBox:Widget:Colour : Widget:Colour : Colour:Black
MonoWidgetBox:Box:Shape : Box:Shape : Shape:Round
MonoWidgetBox:Box:Shape : Box:Shape : Shape:Square
RedWidgetBox:WidgetinaBox:Wrapping : WidgetinaBox:Wrapping : Wrapping:Paper
RedWidgetBox:WidgetinaBox:Wrapping : WidgetinaBox:Wrapping : Wrapping:Plastic
RedWidgetBox:Widget:Colour : Widget:Colour : Colour:Red
RedWidgetBox:Box:Shape: Box:Shape : Shape:Round
RedWidgetBox:Box:Shape: Box:Shape : Shape:Square
RedWidgetBox:WidgetinaBox:Colour : WidgetinaBox:Colour : Colour:Green
RedWidgetBox:WidgetinaBox:Colour : WidgetinaBox:Colour : Colour:White

Now how do we record the actually selected value for the product on the order? For a RedWidget it is easy as there is no customer choice, as all RedWidgets are red. But for the MonoWidget we need to record that the Customer selected a Black MonoWidget.

There is yet another hole in the SID model. There is no association between OrderItem (or BusinessInteractionItem) and ProductSpec characteristic in SID – again an omission (see below).

Again we have to extend the model and add an association and association class between CustomerOrderItem and ProductOfferingProductSpecCharValueUse. However it would probably be sufficient to put the association between CustomerOrderItem and ProductSpecCharValue, in this case “Colour: Black” as the ProductOfferingProductSpecCharValueUse has acted as a rule base to ensure that we know how the ProductSpecCharValue relates to the ProductOffering which is in turn related to the CustomerOrderItem.

This will allow us to show that our customer has ordered a MonoWidget and the characteristic value is “ColourBlack” – the OrderManager can use the rule base we’ve created to determine how “ColourBlack” is related to the ordered ProductOffering.

In my last answer I showed some (bad) XML linking OrderItem to ProductSpecCharValue by just including the required value in the nested XML – the thing about XML is that it isn’t relational – you can just included classes where appropriate without having the associations defined in the model. Now I’ve extended the model you can just have OrderItem nesting ProductOffering and CustomerOrderItemProductSpecCharValue.

So4It: Let’s see if I get what you mean. The BusinessInteractionItem is indeed a multipurpose class and the CustomerOrderItem is a specialization of that. Can you explain when the CustomerOrder and CustomerOrderItem is used since it seems to be a specialization of the BusinessInteraction and BusinessInteractionItem but it doesn't seem to introduce something new it is just an abstract class to the more specialized classes like ASR, LST, DSR and PSRs?

What I mean is do you create a lot of specialized order and order item classes for different type of orders or do you keep the more general classes like BusinessInteraction and BusinessInteractionItem?

In my API I’m thinking of having method like

place(CustomerOrder) cancel(CustomerOrderId)

but maybe it is better to have

place(BusinessInteraction) cancel(BusinessInteractionId)

What do you think?

Andrew: I would forget the classes below CustomerOrder - these are specialised Orders for the USA.

If you want to create a very generic set of services, then yes you could create a place(BusinessInteraction) service and then specialise it into place(CustomerInteraction) - but it sounds like a lot of hard work, unless you are going to do things like Call-Centre management that would be handling all sorts of BusinessInteractions. I would stick with Place(CustomerOrder).

So4It: Looking at the relationship ProductOffering to ProductSpecification what it really is saying is SimpleProductOffering to ProductSpecification, but the problem there is that ProductSpecification can be either a ProductSpecificationAtomic or a ProductSpecificationComposite right?

In that case we get the problem I am saying that we might need multiple ProductSpecificationCharacteristicValue(s) but are you saying

That never happens? What I mean is that you are saying that it always is a SimpleProductOffering always pointing to a ProductSpecificationAtomic OR
Even if it is a SimpleProductOffering pointing to a ProductSpecificationComposite we just store one set of ProductSpecificationCharacteristicValue(s) no matter if 2 of the ProductSpecificationAtomic in the ProductSpecificationComposite has the same ProductSpecificationCharacteristicValue.

I remember you saying something about keep it simple one SimpleProductOffering to a ProductSpecifictionAtomic and I will I am just wondering if the thing I am describing can/will happen.

The ProductSpecificationCharacteristic has a 1..N relationship to the ProductSpecificationCharacteristicValue but it seems to be a uni-directional relationship from ProductSpecificationCharacteristic to ProductSpecificationCharacteristicValue.

This introduces a problem with the list of ProductSpecificationCharacteristicValue I have in the customer order since how do I know which ProductSpecificationCharacteristicValue belongs to which ProductSpecificationCharacteristic when there is no relationship from ProductSpecificationCharacteristicValue to ProductSpecificationCharacteristic.

Or maybe I should introduce the ProductSpecificationCharacteristic id in the ProductSpecificationCharacteristicValue to be able to map them together when I start the provisioning, or?

Andrew: Yes, if you can keep it simple with a SimpleProductOffering related to a SimpleProductSpec that would be wonderful, but it probably won't work out that way and you will have SimpleProductOfferings for CompositeProductSpecs. But don't worry about the Characteristics.

Extending my example: imagine we have 2 more ProductSpecs - a WidgetinaBox - a composite ProductSpec made up of Widget and a new ProductSpec called Box. The Box has just one Characteristic Shape which has 2 values "Square" and "Round". The WidgetinaBox has a Characteristic of Wrapping which has the two values of "paper" or "plastic".

Now we can create our 2 new product offerings of MonoWidgetBox and RedWidgetBox - the customer can choose the shape of the Box and whether the composite WidegetinaBox is wrapped in paper or plastic - the characteristics all work out OK - I think.

Life might get more difficult if you reused the Characteristic Colour for the WidgetinaBox which could be say "white" or "green", but I think it still works...

So4It: Ok, just to make it clear; this I understand. What I am trying to figure out now is how I send the selected values with the customer order.

If I look at the ProjectSpecifictionCharacteristicValue it has a "value" attribute and a valueFrom and valueTo.

So if I decide to use a Set of ProjectSpecifictionCharacteristicValue in the CustomerOrder it means the ProjectSpecifictionCharacteristicValue that was "selected" by the user. But in the case of a ProjectSpecifictionCharacteristicValue that says it is a range value from -to the value won’t be set. Would we then expect the caller to create the ProjectSpecifictionCharacteristicValue keeping the default settings and set the value to what he/she wants it to be.

Do we just allow him/her to set a number of name/values that he/she expect to be used during provisioning.

I’m just very hesitant about to how these values are set and how I map them to the ProjectSpecifictionCharacteristic in the provisioning module if there is no relationship to its owning ProjectSpecifictionCharacteristic.

Andrew: Let's see if I can make this clearer using the WidgetInaBox example.

In trying to make this clearer I discovered that I need to make a change to the model and moved the association class CustomerOrderItemProductSpecCharValue to link CustomerOrderItem to ProductOfferingProductSpecCharValueUse, but it really doesn't make a difference to the XML describing the Order.

A Customer orders a MonoWidgetBox he selects a Green Paper covering for a Round Box that contains a Black Widget.

So we have:

A ProductSpecCharacteristic defines a generic characteristic that can be used by any Product Spec. In my example there is a ProductSpecCharacteristic called “Colour” and another called “Shape”

ProductSpecCharacteristic: Colour

ProductSpecCharacteristic: Shape

The ProductSpec for “Widget” uses “Colour” but not “Shape” while “WidgetInaBox” uses both of these characteristics – (“Shape” is not relevant to “Widget”)

The ProductSpecCharacteristic “Colour” has 4 valid values as defined by ProductSpecCharValue:

Black, White, Red and Green

But Green is only relevant to “WidgetinaBox” while the other colours are used by both Widget and WidgetinaBox as shown by the data in ProductSpecCharValueProductSpecCharUse. Thus the value in ProductSpecCharValueProductSpecCharUse tell which of the ProductSpecCharValues apply to a given ProductSpec.

This is the end of this rather long and complex blog.

SID Product Model and eTOM process for Product Management and Delivery

noreply@blogger.com (Andrew McFadyen) — Tue, 04 Jun 2013 12:43:00 +0000

As a slight detour from the recent series of posts I thought I would share a diagram I drew on a whiteboard while in India for a week last year helping Reliance Jio Infocomm with SID and eTOM.

The people on the project were mainly focused on eTOM and could, like most people grasp Business Processes much more easily than abstract data classes embodying the SID.

I explained the SID Product model to them in the way that I've detailed elsewhere in this series of blogs but while they could understand the difference between a Product Specification, a Resource Specification, and a Service Specification they couldn't really see how all this worked in terms of their business and when it came down to Customer Facing Services and Resource Facing Services they were completely lost.

It was on my last day with them that I drew this diagram on the whiteboard.

I had been going through the product model for the nth time and then suddenly I remembered an old piece of advice I had been given years ago "when explaining a data model talk process and when explaining a process model talk data".

I drew in the blue and red lines and talked about the eTOM processes they represented in terms of the SID classes and I saw the Reliance staffs' eyes light up. They got it!

The diagram shows that when performing the eTOM processes of Selling, Customer Subscription, Catalogue Management, and Marketing and Sales we move from Product Spec to Resource Spec, particularly the CPE (Customer Premises Equipment) such as handset, dongle, SIM, MSISDN etc and from Product Spec to Customer Facing Service Spec. When we are talking about Product Delivery we start in the Provider Equipment where the Resource Facing Services are provisioned to the delivery of the Product instance for the Customer.

I was so pleased with the effectiveness of the diagram I took a photo of it.

It is moments like this that make my job worth doing.

By the way, dear reader

If you've got a comment on this or any of the other blogs please post it and I will try to reply to it as fast as I can (though some get lost in the flood of spam this blog garners)
If you want ask a more detailed question then please email me using the address that can be found by clicking on the "view my complete profile" in the right hand panel
If you would like me to provide more detailed help then there a range of solutions to fit most pockets, from email support through to site visits, just ask. My consulting rates are not outrageous; don't be scared to ask for a proposal.

SID Q&A - Question 5

noreply@blogger.com (Andrew McFadyen) — Tue, 04 Jun 2013 09:16:00 +0000

This is the fifth of a series of questions from SO4IT a Swedish IT consultancy company who are using GigaSpaces technology to build a SID based Order Management system for Communications Service Providers.

So4It: This is the summary of how I intend to implement Customer Ordering all the way to Provisioning. I have added questions along the way.

The use-case starts when a Customer enters the web and wishes to order a product. The web displays all the products offerings that are active.
The Customer selects a ProductOffering he/she wishes to purchase.
The web shop sends a request to the Order Management system that the Customer with a CustomerAccount.id wishes to purchase a product described by the ProductOffering

Andrew: Ok this is going well, but I'm going to interrupt with a philosophical point. You could use a CustomerOrder for this request which would be a nice and loosely coupled design and SID compliant. This would mean that the Order Management system could receive CustomerOrders from any system (internal or external). However that may be “overkill” – it would be OK to just have a XML message called something like “Web Shop Request”. Are you going for a SOA design or are you just simply passing messages around. If SOA you need to think about the services offered by the Order Management and other systems.

So4It: This is how I interpret the usage of the ProductOffering and ProductSpecifications:

A ProductOffering has the commercial data on it and an Atomic or Composite ProductSpecification assigned to it. We will sub class the ProductSpecification so it will contain a fixed set off attributes and additionally to these we will also add a number of ProductSpeccficationCharacteristics to it.

Andrew : I always think of it as being the other way round – the Spec has one or more ProductOfferings assigned to it (the same ProductSpec) can be sold at different prices). So the Product Offering should be linked to one ProductSpec – or be a composite ProductOfferings have sub ProductOfferings below it. The atomic sub ProductOfferings must be linked to a ProductSpec but the ProductSpec itself could be a composite. For example: imagine you are selling iPhones (some complete with SIM cards and a “tariff plan” and others just an iPhone but without a subscription or SIMI). There would be a composite ProductSpec representing the iPhone with SIM and there would be ProductSpecs ‘below’ it representing the basic iPhone and the SIM card,. There would also be other ProductSpecs representing the network services you get as a customer of the phone company. You would have a series of ProductOfferings that would offer the iPhone without a SIM card and the iPhone with a SIM card and the relevant network ProductSpecs. You would do it this way to be able to reuse the network ProductSpec for Android phones for example. There would be multiple ProductOfferings linked to the composite iPhoneSIM ProductSpec and network ProductSpec each with different commercial terms.

So4It: In my interpretation the attributes on a sub class of a ProductSpecification are really constants for that ProductSpecification. This means that for these attributes the Customers will not be able to change the values of these attributes but instead we set them to values that are constant for this particulate ProductSpecification. Additionally we have other attributes that are something the customer can choose from and they become ProductSpecificationCharacteristicValue(s). Then when we instantiate the product we use both types of values for the final product. Correct?

A ProductSpeccficationCharacteristicValue can for example be "color of the cover on the iphone" and the ProductSpecificationCharacteristic is "cover color" and the possible values are "red","green","blue" etc. In the web this will be displayed as a drop down box and the customer chooses a value. Is this the correct idea of how it is used?

Andrew: OK – this will work.

So4It: The Use Case continues as follows:

The Order Management system receives the request that the CustomerAccount wants to Order the ProductOffering. It also receives the selected ProductSpecificationCharacteristicValue(s) for the different ProductSpecification the ProductOffering contains.

Andrew: Yes, good work. It is interesting that the PSCVs don’t have to have a direct association (relationship) with the OrderItem line – they can just be quoted in the against the relevant ProductSpec in the XML structure. If you were designing a database to hold this structure you would have to worry about how to model the relationship between the OrderItem and the PSCV.

So4It:

The Order Management system inspects the ProductOffer and extract the WorkOrder, ResourceOrder and ServiceOrders from it. It then stores each of them separately but with a common Order number and sets the status to PENDING

Andrew: The OM system will look at the ProductOffer and the ProductSpecification and will drill down the ProductSpec to the ResourceSpecs and CFSSpecs to work out how to provision them. Work orders are for work to be done by a human – like dig a hole, install a device etc

So4It:

The web shop receives the Order number and a confirmation that the Order has been received.
The use-case ends

Now we can look at the Order Management Use Case:

The use-case starts when the Order Management handler gets one or many Work, Resources and/or Service Orders under the same Order number.
The Order Management system inspects the Order and decides how to instantiate it as a Physical/Logical Resource(s) and/or CustomerFacingServices. It sends a request to the Customer Management system to add the instantiated Physical/Logical resource(s) and/or CustomerFacingServices to the CustomerAccount.

Andrew: The CFSs and Physicall/LogicalResources will be linked to a Product that is linked to the CustomerAccount (in pure SID, that is).

So4It:

The Order Management system asks the Provisioning system to provision the instantiated Physical/Logical Resource(s) and/or CustomerFacingServices.
The Order Management system sets the status of the Order to EXECUTED.
The use-case ends

When it comes to the instantiation of the Physical/Logical Resource(s) and/or Service/ CustomerFacingServices I'm thinking about how to do it. I mean we have a number of ProductSpecificationCharacteristicValues and a number of constants we got from the ProductSpecficaition. We will also most likely have values we get from the provisioning layer that all of them should be stored on the Physical/Logical Resource(s) and/or CustomerFacingServices in the Customer Management system.
The question is, if I store it as ProductSpecificationCharacteristicValues (that will keep it general and we can easily add new values) but at the same time if we have concrete sub-classes like SimCardResource that has attributes it is easier to understand. What way do you prefer when you do it?

Andrew: You must instantiate the selected or allocated attribute values as ProductCharacteristicValues, ResourceChacterIsticValues and ServiceCharacteristicValues to show the values chosen/allocated to this particular instance of each of the product, the resource and the service. You cannot point to the ProductSpecCharacteristicValue or the ResourceSpecCharacteristicValue etc as this will cause huge problems in the future if someone changes one of these values.

So4It: Maybe there is no right way but I also see that it is harder to do the usage and stuff if everything is so damn general.

Andrew: I agree things are very generic in the SID, but you are doing a great job implementing it - the key to the whole thing is the Product definition or Product Modelling. Get that right and the app will be flexible and easy to use - get it wrong and you've got a nightmare on your hands, but I think you are moving in the right direction - you expose the correct level of detail in the Web Shop to allow the Customer to select and tailor the Product he/she wants and then hide the detail of provisioning down in Order Management and what you call the Order Management Handler - I would call Provisioning Orchestrator or "Provisioning Conductor".

You are correct in having the OM decompose the CustomerOrder into Resource, Service and possibly Work Orders based on looking at the decomposition of the ProductSpec into ServiceSpecs and ResourceSpecs and it is also right to have a separate process "orchistrate" the Service/Resource/Works Orders.

Did I give you my analogy of the restaurant? The WebShop is the waiter with the menu (ProductOfferings) and his note pad (the CustomerOrder) - the head chef (OM system) takes the Order and decomposes that order into different dishes that need to be cooked at different times - he allocates these sub-orders (Service/Resource/Works) (and now he is acting as the Provisioning Orchestrator) to the sous-chefs who cook the meat/vegetables/soup/sweet at the correct time and in the correct quantities and flavours.

SID Q&A - Question 4

noreply@blogger.com (Andrew McFadyen) — Tue, 04 Jun 2013 08:30:00 +0000

This is the fourth of a series of questions from SO4IT a Swedish IT consultancy company who are using GigaSpaces technology to build a SID based Order Management system for Communications Service Providers.

So4It: The Order Manager application will look something like this

CustomerOrderDetail place(CustomerOrder customerOrder)
CustomerOrderDetail cancel(final OrderId orderId)
CustomerOrderDetail get(final OrderId orderId)

Inside the order manager I know have to decide how to implement the flow of the order. I will not use a complicated rule engine I will just have a simple mechanism for it. But the question is how this mechanism will work.

I guess that you create CustomerOrderItems that are context aware. I mean we can have a ProductOfferingCustomerOrderItem that will have the product offering with its ProductSpecifications and the selected ProductSpecificationValues. Correct?

Andrew: The CustomerOrderItem is linked to the ProductOffering through BusinesInteractionItem (see below)

So the XML (and I’m so hot at writing XML but I hope this gives you an idea) will be something like

So the OrderItem just refers (indirectly) to the Id of the ProductOffering, the Price (in BusinessInteractionPrice) and the quantity ordered. The Order Manager will use the ProductOffering.Id to find the ProductOffering and its related ProductSpecification and ResourceSpecs and ServiceSpecs. If the customer has selected ProductSpecificationValues then they would be in the XML as shown.

So4It: What do you suggest I do to get the order manager to select the right "Provisioning Conductor" for the CustomerOrder? The alternatives, as I see it are:

I could split the CustomerOrder into all the items and have a different "Provisioning Conductor" for each. If I do that I could have a simple registry for the "Provisioning Conductors" that checks the type of the CustomerOrderItem and returns the correct "Provisioning Conductor" based on that or maybe one or more values inside the CustomerOrderItem. OR
I could choose a "Provisioning Conductor" based on the CustomerOrder, which will be the ProductOfferingCustomerOrder or something.

I guess it is a matter of granularity here and I could do both but I was hoping you had some advice here, for example: how does the functionality in a OrderManager look like usually, I guess it is a rule engine or...? Just give me your views on this if you have some. The most important thing is how do you model the CustomerOrders and CustomerOrderItems in a real system using the product offering.

Andrew: A Provisioning Conductor per Order Item is the correct solution if you mean by “Provisioning Conductor” the actual service that provisions the order. The Order Manager must decompose the Order into individual items for provisioning – probably equating to individual OrderItems, but a really sophisticated Order Manager might group together similar order items before passing them off to other services for Provisioning. The Order Manager must also think about sequencing – there may be items on the order that need to be provisioned first – for example sending out the handset (and waiting for an acknowledgement of receipt) before getting a Provisioning Conductor to provision phone number on the network.

A single order can have many different products on it – keep the granularity at the order item level. There is a form of rules engine that understands the Product structure and the dependencies on the provisioning steps.

SID Q&A - Question 3

noreply@blogger.com (Andrew McFadyen) — Sat, 25 May 2013 10:32:00 +0000

This is the third of a series of questions from SO4IT a Swedish IT consultancy company who are using GigaSpaces technology to build a SID based Order Management system for Communications Service Providers.

SO4IT submitted a file full of questions to which I responded by putting my replies (labelled "Andrew:") into the text.

So4It: How are the *SpecificationRelationship entities used in the domain model (where * could be Product or Service or Resource)?

As I understand it from the SID the *SpecificationRelationship is:

EITHER exists for a Composite*Specification and specifies how the containing Atomic*Specification are related to each other. That is the relationship itself never keeps a reference to the entities it is describing a relationship between it just says *Specification of type A has to be unique in this composite product specification" or something similar?

OR it is intended to express order, priority etc between Atomic*Specifications. If this is the case it seems natural that they either are *Specification or that the Composites*Specification has them instead of the AtomicSpecificaiton as reference dependency.

In the Order Management "Provisioning Conductor" I will detect if it is a Composite*Specification and then check for other Atomic*Specifications either directly in the list of Atomic*Specification or in the list of *SpecificationRelationship. Or do you always keep them in a list of *SpecificationRelationship and just have a "no-meaning" relationship if there is no relationship between the atomics? Or is there always an "order" relationship between child specifications in a composite specification.

Andrew: Let’s focus on Product: the ProductSpecificationRelationship is what is called in UML an association class and as such it is used to resolve the recursive (self) many to many relationship (association) on ProductSpecification (see the data model below).

For example if you have 3 ProductSpecs (atomic or composite) A, B, C

A can be related to B and C through this relationship while
B can be related to C and A and
C can be related to A and B

So each of A, B and C has multiple relationships with each other.

The ProductSpecificationRelationship could hold

A - B
A - C
B - A
B - C
C - A
C - B

The attribute ProductSpecificationRelationship.type holds information on the type of relationship that each ProductSpecification has with the other

To extend my example imagine that B was an upgrade option for A but it is then replaced by C

A - B, "upgrade to",01-Jan-2010 to 31-Jan-2012
B - A, "downgrade to" 01-Jan-2010 to 31-Jan-2012
A - C, "upgrade to", 01-Jan-2013 to null
C - A, "downgrade to", 01-Jan-2013 to null
B - C, "replaced by", 01-Jan-2013 to null
C - B, "replaces", 01-Jan-2013 to null

Note: The ProductSpecificationRelationship has nothing to do with the Atomic/Composite structure of ProductSpecification and is probably not of direct us in the Provisioning Conductor unless there are some issues to do with availability of Products

For example if we introduce ProductSpecification D which is an alternative for C then this would be recorded in the ProductSpecificationRelationship as follows

D-C, "alternative", 01-Jan-2013 to null
C-D, "alternative", 01-Jan-2013 to null

then during provisioning the instances of C is found to be out of stock then the Provisioning Conductor could provision D which is in stock in its place.

Reading the documentation I see that it says for ProductSpecificationRelationship "Some examples of such ProductSpecificationRelationships would be migration, exclusivity, dependency and substitution" i.e. B is replaced by C (migration), if you have product X you cannot have product Y (exclusivity) but to have product Z you must have product W (dependency) and if you have got C you can swap it with D (substitution).

Of course there is no limit set by the SID for the use of the type of ProductSpecificationRelationship and these are just examples of how you can use it

So4It: OK I understand that, but do you know how these would be represented in the real domain model? For example when I display the ProductOffering on the web page I need to display these relationships, but where are they stored?

I mean in the ProducOffering instance I need to get hold of these when I generate the XML or JSON, so I guess I get it from the product Management API and then generate the response.

But wouldn't that then say that yes there it is a CompositeProductSpecification that has all these, old and new in the relationship, ProductSpecifications and then the relationship explains what the relationships are. That is why I say that somehow, I need to store, a list of ProductSpecificationRelationships when I generate the XML.

Andrew: We are getting into application architecture here - which is OK.

I imagine you would have some sort of Product Catalogue app that is used to set up the ProductSpecs and ProductOfferings. In that app you would define the ProductSpec hierarchy using Composite and Atomic ProductSpecs and navigate through the hierarchy using the association ProdSpecCompositeComprisedOf.

Another thing you need to do in a Product Catalogue is to say which products are compatible or incompatible and which are being replaced by what - this is what the ProductSpecificationRelationship is for.

I would expect the Product Catalogue app to provide a number of services - the simplest would be "get current products" - this would read the ProductOffering and ProductSpecs checking lifecycleStatus attribute (The condition of the product specification, such as active, inactive, planned.) is equal to "active". Another service might be "Check compatibility(product1,product2)" or "Get compatible products(product1)" these 2 apps would use ProductSpecificationRelationship to check compatibility. Another service might be "Upgrade options(product1)" etc etc.

All these services would return ProductSpec and ProductOffering information.

SID Q&A - Question 2

noreply@blogger.com (Andrew McFadyen) — Fri, 24 May 2013 14:15:00 +0000

This is the second of a series of questions from SO4IT a Swedish IT consultancy company who are using GigaSpaces technology to build a SID based Order Management system for Communications Service Providers.

SO4IT submitted a file full of questions to which I responded by putting my replies (labelled "Andrew:") into the text.

SO4IT: The first product offering and product specification I am trying to finish up is shown below. I got this from the CTO at the telecoms company I am developing the application for and this is what he thought the structure would be in SID terms. I don't agree with him so I added mine interpretation in the bottom of this.

ProductSpec:

name: Mobile Subscription (this product requires a Mobile Data Access in the same network)

ProductSpecChar: //PhysicalResourceSpecificationAtomic

valueType: string

minCardinality: 1

maxCardinality: 1

ProductSpecCharValue: //LogicalResourceSpecification part of the value: dynamic assigned ICCID

valueType: ICCID

(SIM is a physical resource and contains one or more IMSIs)

ProductSpecChar: //LogicalResourceSpecification part of the value:

valueType: string

minCardinality: 1

maxCardinality: 1

ProductSpecCharValue:

value: dynamic assigned IMSI

valueType: IMSI

(IMSI is a logical resource. IMSI must be assigned from a valid IMSI in the range available on SIM. Only IMSIs available in same MCC+MNC as the Subscription are valid. IMSI also holds as a resource a lot of additional 1:1 parameters, like PIN/PUK-codes, encryption-keys, OTA keys etc)

ProductSpecChar: //LogicalResourceSpecification part of the value:

valueType: string

minCardinality: 1

maxCardinality: 1

ProductSpecCharValue:

value: dynamic assigned MSISDN

valueType: MSISDN

(MSISDN is a logical resource. Only MSISDNs available in same MCC+MNC as the Subscription are valid.)

ProductSpecChar:

valueType: string

minCardinality: 1

maxCardinality: 1

ProductSpecCharValue:

value: Sweden

valueType: Country

ServiceSpecChar:

valueType: string

ServiceSpecCharValue:

value: 240

valueType: MCC

ProductSpecChar:

valueType: string

minCardinality: 1

maxCardinality: 1

ProductSpecCharValue:

value: Acme Telecoms

valueType: string

ServiceSpecChar:

valueType: string

ServiceSpecCharValue:

value: 01

valueType: MNC

Andrew: The use of ProductSpecCharacteristic and its mapping to ResouceSpecChar and ServiceSpecChar is not how these associations were intended to be used.

To quote the SID documentation (GB922 Addendum 3, Page 16) ”There are cases when an instance of a ProductSpecCharacteristic and/or a ProductSpecCharacteristicValue must be translated to a corresponding ServiceSpecCharacteristic and/or ServiceSpecCharacteristicValue. For example, there may be a ProductSpecCharacteristic that represents the level of service provided as defined by associated Platinum, Gold and Silver instances of ProductSpecCharacteristicValues. Each of these values may be translated into specific upload and download bit rates as defined by ServiceSpecCharacteristicValues.”

This means that the linkage of a ProductSpecCharacteristic to a ServiceSpecCharacteristic is a special case, as in the example for a “Platinum” product to have the ServiceSpec implemented with a high bandwidth while “Silver” product has an associated Service implemented with a low bandwidth.

The diagram below shows how the Product Characteristics are modeled as being related to Service Characteristic and Resource Characteristics

SO4IT: I interpret this as the following:

SimCard - is a PhysicalResourceSpecficationAtomic. Question there is how you guys usually model this do you create a PhysicalResourceSpecficationSimCard that inherits from PhysicalResourceSpecficationAtomic or do you use ResourceSpecificationCharacteristic for all the necessary values it needs? As a follow-up question is then how do you realize this to a PhysicalResource later on in the service that does it? I mean somehow we have to know how to instantiate it to SimCard later or do you just create a PhysicalResource.

Andrew: I am continuously amazed that the SID has not yet got MSISDN, IMSI, IMEI etc implemented as standard “concrete” sub-classes of the LogicalResourceSpecification. One of the first things I do when using SID in a mobile phone company is to create these sub-classes. I think the reason that these classes are not (yet) in SID is almost political as SID is trying to align with other mobile phone standards and to put these classes in would preempt the discussions/decisions.

So, yes, implement all the required mobile resource classes as subtypes of LogicalResourceSpec and PhysicalResourceSpec (for handsets and SIMs). In these atomic classes then implement the attributes like PUK1 PUK2 etc.

SO4IT: IMSI - is a LogicalResourceSpecificationAtomic. To be honest the TMForum documentation is kind of hard to follow here so I would appreciate a word about how to interpret this.

BusinessInteractionItem

_businessInteractionItem

ResourceSpecVersion

_resourceSpecVersion

ResourceSpecification

_resourceSpecification

ResourceSpecification

_resourceSpecification1

ResourceSpecType

_resourceSpecType

Resource

_resource

What does this mean that it has a relationship to the resource(s) it creates? As I see it is some sort of weak reference only used in the documentation to mention that resource(s) are instantiated from it or?

CompoundResourceSpec

_compoundResourceSpec

ResourceUsageSpec

_resourceUsageSpec

ResourceFacingServiceSpec

_resourceFacingServiceSpec

This is also strange in my eyes isn't the relationship the other way around. The service specification has one or more resources it specifies

ProductSpecification

_productSpecification

NetworkAddressSpecification

_networkAddressSpecification

ResourceSpecCharacteristic

_resourceSpecCharacteristic

PerformanceSpecification

performancespecification

SapSpecification

sapSpec

ResourceCapacity

resourceCapacity

ResourceCapacityDemand

resourceCapacityDemand

ResourceCandidate

resourceCandidate

SO4IT: The table above is what the SID documentation says about the ResourceSpecification and as you can see in the comments in the third column I have a bit of a struggle to interpret it? What does a _resourceFacingServiceSpec and _compundResourceSpec mean in this context? My interpretation is that it specifies an inverse relationship, but I am not sure.

Andrew: You are, I’m afraid, getting confused by the UML method of modelling “foreign keys” – while in an Entity Relationship Diagram you would only show the foreign key at the “many end” of the relationship many UML modelling tools show the “foreign keys at both ends”. I think the diagram below may help you understand Resource Spec.

You will see if you examine this diagram that many of these relationships/associations are “many-to-many” and require a “resolving” or “association class” to be inserted on the relationship to make the relationship work.

SO4IT: MSISDN - is a LogicalResourceSpecificationAtomic. Others - The country, country code, Network name and Network code. I guess these should be ProductSpecifcationCharacteristic with ProductSpecifcationCharacteristicValues. Do you then specify a ProductSpecifcationCharacteristicValues type called COUNTRY that allows the value to be any of countries the operator is running in or do you just use a string?

Andrew: This is your decision as the Architect – is it important to the business to record the country (i.e. are there going to be different products for different countries) or is this just documentation?

SO4IT: After we agree on how to interpret this from a product-management perspective comes the next question how do we instantiate this? I mean all this will lead to the following as I see it

Product = Subscription. I see this as the subscription belonging to the customer account or how do you use the term subscription? I state something we create independently from the SID model? In the place I have worked the subscription IS-A product but at the same time it needs things like EndUser and maybe agreement terms etc. So would we then describe the subscription as a ProductOffering or have a requirement that before any product offerings can be realized a subscription has to exist?

Andrew: Product = Subscription for a specific ProductOffering/ProductSpecification.

If the business has a more general type of “subscription” that has a life of its own – its own set of agreements etc then you can (a) implement it as a ProductOffering as you suggest, or as a type of CustomerAccount.

The PartyRole of User has just been implemented (not well in my opinion). I always create a PartyRole sub-class called EndUser and then associate the EndUser with the Product (subscription) through PartyRoleProductInvolvement

SO4IT: PhysicalResource = SimCard. Will this be concrete class called SimCard or will it be an instance of the PhysicalResource or maybe a PhysicalComponent sub-class?

Andrew: See above

SO4IT: Then comes the question about the IMSI and MSISDN. These are LogicalResources tied to the PhysicalResource of the SimCard. So this could be mapped to a LogicalPhysicalResource but how does that look like in real code. Is it a list of LogicalResources in the PhysicalResource or do you have a CompositeLogicalResource or something?

Andrew: See above

SO4IT: ProductSpecificationCharacteristic - These becomes attributes on the final product I guess but since we don't want to extend the model with a million different products we will use the ProductSpecifcationCharacteristicValue concept here or? So does that meanthat a Product has a list of ProductSpecifcationCharacteristicValue that it can have. Does it also mean that a ProductSpecifcationCharacteristicValue has to have the id or some other reference to the ProductSpecifcationCharacteristic it specifies so that when the customer wants to look at what products he/she has we use the "installed base" from the subscription products together with the product specification it came from. Does that also mean that the product always has to have a reference back to the ProductSpecification it came from?

Andrew: There are two schools of thought about how to interpret SID and the product model. I will try to dig out the other description, but I interpret the model as saying that a Product needs Resources to make it work and that the Product allows the use of CustomerFacingServices (CFSs) which deliver such things as Incoming Voice Calls, Outgoing Voice Calls, Voice Mail, Internet access, SMS, MMS etc etc. These CFSs are delivered by aggregations of ResourceFacingServices. A “user” of a Product is aware of the CFSs and may be charged for their use but is not aware of the low-level RFSs (and is not charged for their use). The RFSs are services delivered by LogicalResources (software) that either is running on the customers/users hardware or in the network (both physical resources).

A final note on Resources – there are two types of resource not represented (directly) in SID – there are the CPE (Customer Premises Equipment) that the customer may own and may have even bought off someone else – these include handsets, modems, dongles, SIMs etc, and there are the Provider’s (telco’s) equipment that make up the network and/or the access to the network. Until the provision of smart phones it was easy to say that RFSs only ran on the Provider’s equipment but this distinction is now blurring.

SID Q&A - Question 1

noreply@blogger.com (Andrew McFadyen) — Tue, 30 Apr 2013 09:35:00 +0000

This is the first of a series of questions from SO4IT a Swedish IT consultancy company who are using GigaSpace technology to build a SID based Order Management system for Communications Service Providers.

SO4IT: A ProductOffering contains all the commercial parts of a product or products we offer to our customers. It has a relationship to a ProductSpecification which has 0 or more ProductCharacteristics. I understand that we will define common attributes on the ProductSpecification and others, not common to all Product Specifications, as ProductCharacteristics.

Andrew: This is all correct: the ProductSpecification is a form of template or formula used to create ProductOfferings. If we were talking about selling soap-powder then the ProductSpecification would be the list of chemicals that make up the soap-powder and the ProductOffering would be cover the branding, the size of the box the soap-powder is sold in, and words written on the box

SO4IT: The Product Offering + Product Specification + Product Characteristics in the Product-Management module is like the template for the Product. When we create a Product from this we create a Product with CFS, RFS and Resources. What information do we duplicate and what information do we just reference from the Product Specification? In a very basic set-up I would guess that it would be the ProductCharacteristicValues and in that case each ProductCharacteristicValue would link back to the ProductCharacteristic it belongs to. Whenever looking up what Products a Customer has we would need to access both the Product and the Product Specification it comes from to give the Customer the full picture, right, and when we instantiate a Product from this what information do we carry with us to the Product?

Andrew: The ProductSpecification is linked to the CFSSpecs it needs and these will be instantiated as CFSs when the product is purchased/provisioned. The RFSs on the other hand are the network or low level “technical” services needed to make the CFSs work and are not directly linked to the Product. The Resources are more complex; most telco products have hardware and software associated with them and these, at this level, are represented by the ResourceSpecifications relationship with the ProductSpecification and the Resource that the customer buys or already owns and its relationship with the Product – this can be a little confusing because SID mainly talks about the other kind of Resources: the Resources that make up the telecom’s companies network.

The values in the ProductCharacteristic would be the things that can be tailored for a Customer or the Customer may alter. Things like Weight, Height, Width, and Frequency cannot be altered and therefore would not be duplicated, but something like Language, or Password which the Customer can select would be stored in a ProductCharacteristic. The ProductSpecification and its characteristics are the technical spec for the product – the Product and its characteristics are the define the properties of the particular instance of the Spec – the things the Customer can change or that changes over time – perhaps battery charge (though I think that is going a little far).

SO4IT: I would like to understand something about pricing. In SID I can see ProductOfferingPrice and ProductSpecificationPrice. So how do we decide the final price, will it be a combination of all these then? And how do you then model dependencies like the price will be this in case he chooses the ProductCharacteristic A with ProductCharacteristicValue AA etc?

Andrew: There is no ProductSpecificationPrice in SID only ProductSpecifcationCost which is meant to be used to record things like the raw material cost or R&D cost of developing the product. The price is based on the ProductOfferingPrice and can be varied by using DiscountProdPriceAlteration.

End of Q1

SID Q & A - A new series of posts...

noreply@blogger.com (Andrew McFadyen) — Tue, 30 Apr 2013 08:49:00 +0000

Over the last month I've been helping a client, SO4IT (http://www.so4it.se/) with their understanding of the SID. We both thought it could be a nice idea to share their questions and my answers to help other people to understand the SID.

The SO4IT is developing new applications based on the latest technology Gigaspaces XAP, and while they are technically very competent they are "newbies"when it comes to the SID. They found me through this blog and asked me to mentor them as they learnt the SID and used it to develop Customer, Order and Product Management applications.

Watch this spot!

A Year in the Life...

noreply@blogger.com (Andrew McFadyen) — Tue, 15 Feb 2011 09:15:00 +0000

I am coming near to the end of my assignment as a Data Architect at Türk Telekom. I have been in Ankara, Turkey, for just over a year now and it has been quite a year; not only because I have experienced and greatly enjoyed the rich Turkish culture, wonderful food and amazing heritage sites, but also because of the work I’ve been doing on Türk Telekom’s “Program Bir” (Programme One).

When I arrived in December 2009, Program Bir, a multi-year, multi-release, complete top-to-bottom re-engineering of Türk Telekoms OSS/BSS, was in the definition phase and the contract for the development and integration of the first release (Release 1) had yet to be let. My new colleagues had done great work with the application architecture and business processes using the TAM and eTOM, but for the data they had done little more than stating that Program Bir would be using the SID (Frameworx Information Model).

The first thing I had to do was “Install SID”, and I don’t just mean downloading SID from the TM Forum and loading it into a modelling tool. Installing SID is lot more complicated than that; some of the steps involved are:

Define how the SID is to be extended, and identify using the eTOM and TAM those ABEs that will need to be extended.
Educate the architects and analysts in the SID vocabulary and important structures.
Guide and negotiate with them and the SI on the interpretation of the SID (see my previous blog entry, No Absolute Truth)
Tailor the SID and its interpretation it to fit the role it is being used for which includes defining concrete subclasses of some of the abstract classes such as PartyRole.
Extend the SID to take into account the Turkish environment, such as ID cards and Turkish addresses and state structure as well as providing structures to cover the gaps in SID and to store important business information that have no attributes defined in SID.
Define the Master Data Management for all SID ABEs within the scope of the Release.
Define a set of design principals to be applied by the architects, analysts and especially the SI in their use of and changes to the SID covering all the above and giving guidelines on simplify the physical implementation of the model.

When the “Installation” was complete Türk Telekom’s version of SID, called the Common Data Model (CDM), was ready for use, and my job as the Data Architect could get underway.

Program Bir (Release 1) is all about integrating new COTS applications for CRM, Order Management, Network Inventory and Network Management with the many legacy systems that currently make up the OSS in Türk Telekom. All the applications, both new and legacy, were to integrate through a new SOA architecture and an Enterprise Service Bus (ESB).

So, rather than implementing (or reusing the legacy) point-to-point interfaces every application, old and new, is now to communicate over the ESB. New SOA Services were defined by the SOA Architect, and my opposite number in the SI and I pulled the information for each service from the SID (or rather the CDM) and mapped it to an XML structure. As each application that was to be a user or provider of that Service has to map their API, or legacy interfaces to the XML message structure I was fully involved in workshops and meetings throughout the long hot Ankara summer.

The mapping method we used was an Excel spreadsheet projected on the wall showing the basic XML structure. This was a pretty low-tech approach, but it worked, and was well suited to the mass data mapping meetings which seemed to work in the Turkish culture. It would have been simpler to use a tool like Progress DataXtend to do the mappings, but that wasn’t available and everyone was comfortable with Excel, even if its use required a lot of manual effort cross-checking and cutting and pasting mappings and was fraught with version control issues.

Once the two rounds of mapping meetings with each of the major systems owners were over, all the mappings had been issued and approved, and every application had defined how it mapped to the SOA Services’ XML message structure the work of the Data Architect might have been considered to be complete. But there was a vital step still to be undertaken, and one unfortunately, didn’t appear on the SI’s project plan.

I call this step “Business Value Mapping”. We had mapped the attributes in the API’s and legacy systems’ databases to the XML model, but we hadn’t talked about the meaning of the data in these attributes and values that the data could take, and what these values meant. The SI said they usually did this in the integration phase, but I insisted it was done before the detailed design was signed off. There were a lot more very hot (not just because of the climate) meetings as everyone got to grips with this problem. This pain has paid off, I believe, as the integration of the applications over the ESB during integration testing went very smoothly.

Also during detailed design stage a lot of work was done on the Product Catalogue. This was a very satisfying task as marketing and the product managers got to love the SID Product Model. They quickly learned how to use it and how to build reusable Product Specifications that can act as building blocks for future products.

During coding and testing stages of Release 1 I was often required to act as referee on the interpretation of the model and the mappings to the message model. Now as we enter Acceptance Testing I am helping to define Release 2.

But, now it is just about time for me to go and find another project somewhere else, and I can leave Program Bir and possibly Turkey sure that I have helped built a firm foundation for the data architecture of subsequent releases.

They did it “My Way”!

No Absolute Truth!

noreply@blogger.com (Andrew McFadyen) — Wed, 05 Jan 2011 07:44:00 +0000

This is a copy of a blog I posted on the TMForum Online Community website.

This is a slight detour off my anticipated series of blog posts... but I have been inspired by John Reilly’s comment on my last posting and felt that there is an important message that any one new to Frameworx must understand:

“There is no absolute truth in SID!”

This is a bit shocking (at first); after all, the role of an enterprise data model is to provide a single point of "truth"; to define exactly what classes/entities/concepts, the "things are of significance to the business, about which information is held" (to quote Richard Barker ex of Oracle and author of some excellent books on data modelling) are and to provide a

rigorous,
unambiguous,
easy to understand

definition of each concept/entity/class (hmm, the SID could do with some work on some of its definitions which fail, ‘big time’ to meet these criteria).

So how come there is so much debated about what the SID means? As John Reilly pointed out in a comment on my previous blog entry, there are two interpretations of what a Customer Facing Service is, and this is not the only area of interpretation and debate as you can tell if you follow the comments in the TM Forum community.

The problem is not caused by definitions of the classes no matter how good or bad they are. The problem that the SID has got, in common with any other good canonical model, is that, as Abraham Lincoln said:

"You can't please all of the people all of the time"

Canonical, basically means flexible, and the very flexibility of the model allows, and in fact, encourages different interpretations. That is not a weakness, it is a strength and makes the SID a very powerful tool. The SID has to be interpreted because every enterprise is different and operates in a different market with different products/customers/regulations/competition/management. The SID has been defined to support every possible nuance of the Communications industry, and so there is bound to be different ways of using it and interpreting it, again this is a strength and makes SID powerful.

But, the problem with any powerful tool is you need to know what you are doing when you use it, or someone could get hurt. The SID is not a substitute for thought, or experience; you need to think hard about how you are going to implement SID, and what interpretations of model you are going to adopt and then document these and make sure everyone in your organisation understands your interpretation of the SID. To quote an old friend of mine:

"A fool with a tool is still a fool"

You must not be foolish with the SID. If you are you will fail and the systems you build with it will be as complex and as difficult to maintain as the legacy systems you replaced.

So how do you go about being wise? First of all realise that using SID "out of the box" will be difficult, if not impossible. You need to ask yourself "How and why are we going to implement SID?" I have often asked or been asked this, and have even thought about building a SID implementation methodology, but I have always 'run out of steam' or time and, to be frank, experience of enough different SID implementations. However I can share some basic principles based on my experience that anyone starting a SID implementation ought to follow.

1. "Education, education, education" to quote Tony Blair, a former British Prime Minister. Don't even try to understand SID without getting some proper training. I know this to be the case, as I did it the hard way. I struggled with the SID manuals and model for about 6 months before I truly understood all of it, and I’ve had a lot of experience with other Enterprise models. Don’t think because you can read a data model that you can understand SID without training.

2. Define why you are using the SID. What is the SID for in your organisation? Is it a model to be used to define the information in a particular application? Is it the 'language' to be used over the ESB/SOA? Are you focused on the Network side or the Customer side of the business? This will help you make some of the decisions about how SID is being interpreted. For example, if your business focus is Network Management, and perhaps ITIL then the 'bottom up' (2nd) interpretation of CFSs may be more useful than the 'top down' (1st) interpretation.

3. Get some experience. Even the best training course (like the ones from the TM Forum) is only going to be an introduction to the complexity of the SID. It will teach you how to understand the SID, and introduce all the Domains and important top level ABEs as well as drilling into the Party, Product, Service, Resource and Business Interaction ABEs, but when you get back in the office you are going to need an experienced guide to ensure you don't get lost and to help you when you stand at a decision making crossroads to pick the right direction - for your organisation. Where do you go to get this help? From the TM Forum Community! Don't be scared to ask questions! Otherwise think about getting someone in for a few days or weeks to help you launch SID in your business.

4. Concrete the abstract. SID is full of 'abstract classes'. You should review these and where necessary make some local concrete sub-classes. Why do this? Well it helps regulate and document these and allows the less data model minded to understand the model more clearly with concrete examples. There has been a lot of discussion on how to do this in the TM Forum Community postings, around Party Role for example. The bottom line is that you must make the SID your own. Create a new “Acme Telecoms Information Model” for your Acme Telecoms company that is an implementation of the SID model with your concrete classes, your extensions, your new classes. You will be creating new classes and making extensions to existing ones and improving the SID class definitions to meet the three criteria I listed at the start of this post (I hope). You must understand that all of these activities are allowed, expected and are probably mandatory (another blog post on this subject in the future... I promise).

5. "Education, education, education". You must educate the implementers of the SID. The people building the new app, or defining and building the ESB. They must understand SID and how you have implemented it. You should hold formal training for these people. It doesn't have to be a long class you can probably get the message across in a day or less. Then you must of course follow up and help these teams with all the design decisions and the data mappings they are going to have to do (again another blog on this subject in the future, I think).

6. "Education, education, education". The SID is a new way of looking at the business, part of the "New Generation Operation Support Systems" you are implementing. If your business users and managers are still living in the "Old Generation" world then you are going to have significant problems. You must introduce the Frameworx Customer-centric approach, the new product modelling approach, the account focus, the Business Interaction focus all or some of which are going to be very very different from the way your organisation used to work - which is why you have starting to use SID in the first place. Understand you are going to be taking important business leaders out of their comfort zone. They have used the old Billing/CRM/NRM systems for years; the corporate language reflects the way these systems work, and unless you change this language and open the business leaders minds to the new way of looking at their business you are going to have significant problems during the training and acceptance testing phases of your project where they or their staff will say "...but, this isn't how we do things here!".

I'm sure there are other things that must be done... but if you do these things then you are at least moving in the right direction.

Resources and Service – Part 2

noreply@blogger.com (Andrew McFadyen) — Fri, 22 Oct 2010 10:35:00 +0000

In part 1 of this post I discussed the lifecycle of a Resource. Now I want to discuss the difference between Services and Resources and help you understand the beauty and elegance of the SID model in describing these things.

As I stated in Part 1 Services delivered by LogicalResources. If you are familiar with UML modelling this is very easy to understand, the LogicalResouceSpec is the “component” in a UML component diagram. The balls (or cups) on sticks that are drawn on the box representing the component in UML represent the Services that the component offers.

So, for example, if you have a low level component, such as a ActiveX component to handle, say Customer data and it supports two interfaces, GetCustomer() and SetCustomer() then it would look something like the picture at the start of this entry.

The two interfaces services this component offers other components in an application. These other components are themselves LogicalResourcesSpecifications (if they are on the UML diagram), so the services are ResourceFacingServicesSpecifications (RFS Specs).

When all the components are implemented they can be put together to support one or more Use Case, for example these RFSs could support a Use Case called “Process Customer Order”, or “Update Customer Details”. As I’ve argued before in this blog (I think), a Use Case is often a specification of a Customer Facing Service (CFS), so a UML Use Case (and/or Sequence Diagram) is a CustomerFacingServiceSpec.

When you code and build the component then you create an instance of the LogicalResourceSpec, a LogicalResource offering services, ResourceFacingServices.

“Hey Presto!” as the magicians say when they pull a rabbit out of a hat, I hope you can see how Resources, RFSs and CFSs all fit together... A CustomerFacingServiceSpec is a Use Case and/or Sequence. A ResourceFacingServiceSpec is the interface provided by LogicalResourceSpec, a component on a UML Component Diagram.

It was suggested in a Blog on the TMForum Community pages, by no less than John Reilly, that it might be a good idea to get rid of ResourceFacingServices at some time in the future. To quote John’s Blog:

The discussion often then leads to the difference between the two types (subclasses) of Service, Customer Facing Service (CFS) and Resource Facing Service (RFS). Some of us think that if the Service Configuration Aggregate Business Entity, for which there are two long-standing but unimplemented contributions, was developed, then RFS would meet its demise. This would then negate the need for a CFS since it would be a solitary subclass of Service, simplifying the SID quite a bit.
The reason for this thought is that those of us who work in the provisioning world believe there is a lot that must be added to RFS to support the configuration and activation of Services. Service Configuration would fit satisfy these requirements.

To be fair to John, and I did challenge him on this issue, he was intentionally being contentious.

However I can follow John’s argument: how a Resource behaves can be defined by a configuration that is applied to a Resource to tell it how to deliver a particular (Customer Facing) Service. For example, the HLR can be configured not to allow a given Product (subscription) to use the CFS ‘Make Voice Call’, but I would argue that the CFS itself has been disabled. There certainly will be a step in the sequence diagram for “Make Voice Call” where the status of this service is checked by the HLR, but surely this is just a RFS?

Anyway. For the time being RFSs and CFSs are safe and I hope they remain so, particularly if more people understand how they work!

As ever, comments, ideas, criticisms and calls for help or assistance are always welcome. I am trying to write this blog a little more frequently and external inspiration is always welcome.

Resources and Services - Part 1

noreply@blogger.com (Andrew McFadyen) — Fri, 22 Oct 2010 10:28:00 +0000

Recent postings on the TMForum Community pages about the lifecycle of a modem a discussion on the difference between a logical resource and a service made me think it was time for me to describe to the wider world my thoughts and interpretation of the SID in these areas.

First of all, what is a Resource?

For physical resources it is pretty obvious because you can see them, hold them in your hand, put them in your pocket, or as I always say in my training course, put a ribbon round it if it is too big to hold. The really big resources are usually the Telecom’s Service Provider’s own equipment, be it a base station, the DP, or the switch, but of course PhysicalResources include things like the phone, the modem, the mobile, the SIM card, the memory card and the copper pair in the DP that belong to a Customer’s Product (subscription)1 Additionally a physical resource will always be located somewhere, at an address, a geographic location, or perhaps in a local location (e.g. a room in a building).

A logical resource is therefore something that cannot be touched. Generally LogicalResources are numbers, like the phone number, MSISDN, IMSI, IMEI, PIN, PUK etc. One realisation I made a few years ago is that anything that is a number is a LogicalResource, from π (which is an instance of the LogicalResouceSpecification of “Irrational Number”) through to a binary string. Really large binary strings are often programs, or perhaps a JPG picture or a MP3 music clip. So programs, images, and music files are all LogicalResources too. This realisation is useful in many ways; not least in understanding how a LogicalResource can have a location. For example, Firefox. The ResouceSpecifcation for Firefox belongs to Mozilla. I have an instance installed on my p.c. ( a PhysicalResouce), so a LogicalResource can installed in a PhysicalResource. But consider an MSISDN it is installed in the HLR (a logical resource itself) which in turn is installed in the Switch. So a LogicalResource must either be installed in (located in) another LogicalResource or a PhysicalResource and the PhysicalResource has a location. My p.c. is on my desk in my study in my apartment in Ankara.

Another thing about Resources is that they have lifecycles outside a Product (subscription) and this is where the question about the lifecycle of a modem came in. The TMForum Community member posted a question about a home internet product (specification) that could deliver a free modem, or a modem that is rented to the Customer or be used by a Customer who already owned a modem (as different ProductOfferings) The complex validation rules about what happened if a Customer subscribes to the ProductOffering that delivers the free modem and then cancels the subscription only to come back later to take out the ProductOffering that could use the Customer’s own modem.

Consider it from the modem’s point of view. It was born (manufactured) in a factory in Taiwan or PRC and shipped through a number of warehouses and Suppliers until it ended up in a box on a shelf in a Supplier’s shop together with a CD-ROM that had its driver software, a cable to connect the modem to the telephone point, another cable to connect the modem to a p.c., an instruction manual and a piece of paper with an activation code on it. All of these are Resources, and each will have had its own life to get to this point. The box all these Resources are in represents (as near as damn it) the ProductOffering. The ProductOffering also includes a number of Services which are (usually) the reason the Customer purchases the ProductOffering. These services are not to be found in the box, directly, but ultimately are delivered by software, either running on the Customer’s computer, in the modem, or in the Service Provider’s network... but I am getting distracted, I was talking about the modem’s life.

One day someone (a Customer) buys the box and takes it home (the new location for the modem). He follows the instructions and plugs in the modem correctly to the wall socket and his p.c., loads the software and activates the service through entering the activation code and establishing a username and password (again logical resources) with the Service Provider to set up the Product (subscription). Each of these Resources have a ResourceRoleProductInvolvement (a type of ProductInvolvementRole) that link and show the role of the Resource in the Product.

The Customer uses the modem and the Services provided by his Product (subscription) for a year or so and then cancels the Product (subscription) for some reason. He can no longer use the Services provided to him by the Product (internet access, email etc) and he gives up the username and password 2. However the modem and cables, CD-ROM and even the software on his p.c. are still all at his house, but not associated with an active Product. This seems to scare a lot of people. A suggestion was that the Modem should be associated with a bundled Product so that when the Internet Product was cancelled the relationship between the Customer, the Resource and the Service Provider could be maintained, just in case the Customer ever came back. You could do that, but if you do that then you should also do that for things like Phone Numbers, MSISDNs and anything else the Customer can purchase from the Service Provider and carry away.

In my mind the Resource still exists; it hasn’t disappeared just because the Product has been cancelled. Just like the Person playing the role of Customer still exists even after the Product (subscription) is cancelled and the Party is no longer playing that role. It is no co-incidence that Parties play PartyRoles that in turn play PartyRoleProductInvolvement (roles) and Resources play ResourceRoleProductInvolvement (I think SID has got the name wrong it should be ResourceProductInvolvementRole).

Once this is accepted then the whole problem that the TMForum poster was struggling with disappears.

And now to the difference between a Service and a Resource. In Telecoms at least, a Service is provided by a Resource, and as I have explained earlier, the Services are nowadays delivered by software, or LogicalResources (old-fashioned Strowger switches delivered the service of connecting a call mechanically). OK there are service delivered by the telco that may involve Human Resources, like an installation service, but this is not directly modelled in SID (I wonder why?) but is considered something covered by the likes of a WorkOrder or ServiceOrder.
I will cover how Services differ from Resources in Part 2 of this post.

Footnotes:
1. I put subscription in brackets because in SID the subscription is referred to by the word Product. Product is an instance of a ProductSpecification
2. The username and password seem to be, interestingly, Resources that don’t have a lifecycle outside the Product.

TMForum membership

noreply@blogger.com (Andrew McFadyen) — Mon, 04 Oct 2010 11:39:00 +0000

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.

SID V9 and V9.5

noreply@blogger.com (Andrew McFadyen) — Thu, 24 Jun 2010 11:45:00 +0000

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

Business Services
SID V9 changes
SID V9.5 proposed changes

Business Services have been introduced to show how Level 4 processes in eTOM use SID Level 1 ABEs, something that has been missing from NGOSS/Frameworx from the beginning. I think this will help in SOA Service developments, but I reserve my judgement as SID Level 1 ABEs are very high level concepts and may be too high level to be useful.

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.

BusinessInteractionItem	_businessInteractionItem
ResourceSpecVersion	_resourceSpecVersion
ResourceSpecification	_resourceSpecification
ResourceSpecification	_resourceSpecification1
ResourceSpecType	_resourceSpecType
Resource	_resource	What does this mean that it has a relationship to the resource(s) it creates? As I see it is some sort of weak reference only used in the documentation to mention that resource(s) are instantiated from it or?
CompoundResourceSpec	_compoundResourceSpec
ResourceUsageSpec	_resourceUsageSpec
ResourceFacingServiceSpec	_resourceFacingServiceSpec	This is also strange in my eyes isn't the relationship the other way around. The service specification has one or more resources it specifies
ProductSpecification	_productSpecification
NetworkAddressSpecification	_networkAddressSpecification
ResourceSpecCharacteristic	_resourceSpecCharacteristic
PerformanceSpecification	performancespecification
SapSpecification	sapSpec
ResourceCapacity	resourceCapacity
ResourceCapacityDemand	resourceCapacityDemand
ResourceCandidate	resourceCandidate