SID Q&A - Question 5

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.

1. 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.
2. The Customer selects a ProductOffering he/she wishes to purchase.
3. 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:

4. 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:

5. 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:

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

Now we can look at the Order Management Use Case:

1. The use-case starts when the Order Management handler gets one or many Work, Resources and/or Service Orders under the same Order number.
2. 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:

3. The Order Management system asks the Provisioning system to provision the instantiated Physical/Logical Resource(s) and/or CustomerFacingServices.
4. The Order Management system sets the status of the Order to EXECUTED.
5. 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.