25 May 2013

SID Q&A - Question 3



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.

24 May 2013

SID Q&A - Question 2



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
name: SIM
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:
name: IMSI
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:
name: MSISDN
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:
name: Country
valueType: string
minCardinality: 1
maxCardinality: 1

ProductSpecCharValue:
value: Sweden
valueType: Country

ServiceSpecChar:
name: Mobile Country Code
valueType: string

ServiceSpecCharValue:
value: 240
valueType: MCC

ProductSpecChar:
name: Mobile Network Name
valueType: string
minCardinality: 1
maxCardinality: 1

ProductSpecCharValue:
value: Acme Telecoms
valueType: string

ServiceSpecChar:
name: Mobile Network Code
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

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.