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.
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.
4 comments:
if "the linkage of a ProductSpecCharacteristic to a ServiceSpecCharacteristic is a special case", how would the service derive its specification characteristic values during provisioning?
Good point! What I was trying to say was it is a special case where a ProductSpecCharacteristic forces the selection of a CFSSpecCharacteristic. Many CFSSpecCharacteristics can be user/customer selectable irrespective of the ProductSpecChar.
Perhaps not exactly relevant to this blog post, but I’ve been wondering about the following, appreciate to get some help
If I understand correctly, a typical GSM telephony ProductSpecification would be realized (among other CFS's and resources) as an MSISDN LogicalResourceSpecifiction, which will have an "ID" ResourceSpecCharacteristic (ID) - the selected 123456789 phone number would be populated during ordering
tThe question is:
a ProductOffering which will be the base of ordering is created from this ProductSpecification but doesn't have direct reference to the LogicalResourceSpecifiction realizing the this ProductSpecification, to enable the ordering capturing engine to populate the selected MSISDN value characteristic, should the container (if i may say) ProductSpecification have an equivalent characteristic "MSISDN value" for every resource or selective resource characteristics?
Your solution to put the MSISDN as a characteristic of the ProductSpecification is a workable pragmatic approach. In the end it depends how your Order Capture function works. If it can display/accept information relating not only to the ProductSpec/ProductOffering but also the CFSSpec and ResourceSpec then you could use their Characteristics and or Id's to capture this information. However there are good reasons (e.g. loose coupling between the Order Capture and the Order Manager components) why you might just want the Order Capture process to just deal with ProductOfferings and ProductSpecs.
Post a Comment