Modeling Rules – Policy versus Simplicity

I’m back in one of my favorite foodie destinations again this week.  I’ll provide a hint…beef noodles in soup.  Yes, China!  It’s a specialty of Nanjing, which is where I am this week.  Plus, I did have a few JinLing beers, a locally made brew.  I think I have chatted enough about my Chinese food adventures, so have made that part of this blog short.  But don’t worry.  This is not a trend.

One thing (among others) that often has bothered me and others about the SID is the reliance on the policy model to support all pricing rules.  When we first started developing rules for pricing (and charging) in the Information Framework (SID) many years ago, we actually did not rely totally on the policy model.  We developed an additional set of entities to support simple rules, such as quantity-based pricing and tiered-based pricing.  However, we were convinced by some members of the team to not use this additional set, but rely on policy for every type of price rule.  I think I still have that model floating around somewhere on my laptop.

Many members believe that using only policy is a bit extreme.  Although it is quite powerful and useful for many other purposes besides the definition of pricing rules, it can be a challenge to understand.  And one thing I have learned over the years is that there is often a balance that can be achieved between complexity and simplicity.

This balance was introduced into the SID in release 6.0 with the addition of an association between ProductSpecCharacteristicValue and ProductOfferingPrice.  This provided a simple rule that enabled a price to be dependent on value(s) of one or more characteristics.

This balance continued in SID in release 9.0 with the arrival of a new Level 2 ABE (Aggregate Business Entity, a cohesive group of entities) named Pricing Logic Algorithm within the Product Offering Level 1 ABE.  This ABE used Product Specification Characteristics to provide support for pricing that involves parameters which are multi dimensional matrices, in which each dimension is defined by the valid values for a specific characteristic.  For example, a PLA which rates events based on customer type, there is one instantiation in which customer type is either residential or commercial (and in which case the size of the dimension of the matrix is 2) and in other instantiation the customer type can be student, normal and senior citizen (in this case the size of the dimension is 3).

For the next release of the SID we are planning to support content-based pricing and charging, where the rules are a little more complex than the simple association between values of Characteristics and prices of Product Offerings.  But, the rules are still not complex enough to take advantage of the full power of the policy model.  To support the pricing and charging requirements for content, two new entities will be recommended for addition to the Characteristic model along with a few other changes.

This is not to say there isn’t a place for the policy-based price rules that remain in the SID.  Two of its real powers are the support of complex price rules that can’t be modeled with a small number of entities (whose addition does have database and application repercussions!) and complex one-off price rules that would have to be embedded in code.  Examples of these can be found in the SID Product addendum (GB922-3).

So, as you go about modeling, keep in mind that it’s not always a choice between one or the other, but sometimes both.

Home next week and then off to Vienna the following week to do some training.  I won’t be back in China again until October.

As one of my SID associates says…have a good one!