Telecoms Enterprise Information Modelling: SID Q&A

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.

Telecoms Enterprise Information Modelling

07 June 2013

SID Q&A - Question 6

No comments:

About Me

Links

Blog Archive