Involvement Roles

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

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

1. We store it independent from the ProductSpecification structure and fetch it using the id of the ProductSpecification
2. 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

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

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

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.