Do you make decisions? Or just rules?

[Jocelyn_Dart]

The truth is that many people set rules to keep from making decisions. Mike Krzyzewski, American basketball coach and former player

An expert is someone who has succeeded in making decisions and judgements simpler through knowing what to pay attention to and what to ignore. Edward de Bono

Image courtesy of Stuart Miles / FreeDigitalPhotos.net

5 days ago (and counting) the A/V Receiver in my home entertainment  surround sound system died after almost 10 years of faithful service.  My TV, my Blu-Ray recorder, my gaming console, 5 speakers, 1 subwoofer, and a bass speaker are all connected to my A/V receiver, so all of a sudden I was looking at pictures with no sound.  Calamity!  Or as my sister put it: "oh no, you’ve introduced a single point of failure!"

So for the last 5 days (and counting) I’ve had a decision to make. 

As it happens, I had to travel to my project this week anyway, so a few days living in the hotel has given me some time to do the necessary research, work out what needs to go into this decision, i.e. what rules I want to apply/ignore; and coincidentally put together some reflections on the difference between decisions and rules that I have been discussing with my current customer.  Oh and yes this customer has an ongoing project using SAP NetWeaver DSM and BRFplus, although many of the reflections would apply equally to the use of decisions and rules in BRM.  We currently have totals of well over 1000 rules to implement within a dozen decision services.

What’s the difference between a decision and a decision service?

Most people recognize a decision when they see one.  There’s an issue at hand, factors to be considered, and a choice to be made.  As the Oxford Dictionary puts it:

A conclusion or resolution reached after consideration http://www.oxforddictionaries.com/definition/english/decision

We make hundreds of decisions every day: what clothes to wear; what to eat; what to drink; what route to travel to work; what school to send our children to, and so forth.  Businesses make thousands of decisions every day: what price to charge a particular customer for a specific product; where to locate an employee; what work is assigned to each employee; how much we pay our contractors; what suppliers we use; what distribution/carrier companies we use; what servers we build; what software we support; what software we blacklist; what tax we pay and when, and so forth. 

Knowing that there are lots of decisions and choices is fine.  But there are so many decisions that without some guidelines and understanding it can be overwhelming to try and work out which decisions we automate and which we don’t.     

Automated decisions are implemented as decision services. A decision service is a self-contained, callable service for the purposes of making decisions.  A decision service encapsulates one or more business rules that must be executed together, in the correct sequence or order, to make that decision.

Each decision service asks a question, for example “How much discount should this customer receive when purchasing an A/V Receiver?”  Each decision has a specified result (i.e. answer), for example “The discount percentage, and maximum discount amount permitted”.   Making the decision may require one or more business rules to be executed, for example:

• What's the credit rating of this customer?
• What other purchases have they made with us in the past?
• Are they buying the A/V Receiver as part of a Home Entertainment Theatre package?
• Is the price of the A/V Receiver high enough to warrant a discount?
• What's the maximum discount our policy people have decided the business can support?

Contrast this with a manual decision. Manual decisions are those made directly by a person.  When someone makes a decision on behalf of the business it is their responsibility to ensure they know, understand and are current (up-to-date) with the business rules that need to be applied, the result that needs to be determined, and that they apply those business rules correctly in making a decision.    Think of a Home Entertainment salesperson who is on staff at your local electrical appliances store, and who can assess and decide what discount to give a particular customer.   Of course, if they get it wrong it’s often too late to fix it once the purchase has been made or the contract has been signed.

At its simplest: Decision services automate decisions that would otherwise need to be made manually. 

Decision services are particular critical where it would be difficult for personnel to keep current (up-to-date) with the information and knowledge of all the rules that need to be applied, such as:

• There are many underlying business rules that need to be executed
• The business rules change over time, or with different circumstances
  • Where different business rules need to be applied as at different dates based on changes in legislation or policy
  • Where the correct rules need to be re-applied retrospectively, e.g. if a complaint or appeal or objection means the decision needs to be re-evaluated, under the rules that were in place at the time the original decision was made
  • Where rates and factors in the rules change frequently, e.g. changes in thresholds, changes in discounts, changes in inflation factors, etc.
  • Where there are specific situations that change which rules need to be applied, e.g. strategic customers, remote geographical locations, even whether the carrier has to deliver a product to a multi-storey apartment without a lift.

Why can’t I just use a web service, method or function module?

But hang on a minute, doesn’t that automated decision service sound awfully like a web service or a method or a function module?  Where’s the boundary line between decision services and other automated (encapsulated, callable, coded) services? It all comes down to understanding the degree of change that needs to be supported.

To put it another way, does what needs to be considered (the underlying business rules) in making the decision change more frequently than the need to make the decision (the calling application or program itself)?

Decision services replace traditional automated services where decisions would otherwise be coded in programming languages that the business cannot read, which require significant IT support to maintain, and are constrained by IT change and transport lifecycles to implement those changes.

Or to put it even more bluntly, does the business need to:

• Be able to change how the decision is made more frequently than IT can support
• Be able to change how the decision is made more rapidly than IT can support
• Be able to confirm that nothing has been lost in translation between business and IT.
  • Regardless of how many test cases you run, sometimes testing is just not enough for business experts or policy makers whose careers and peace-of-mind depends on knowing that the rules are correct, complete and true to their intention.

When we are talking about the speed at which IT can support changes, we are not just talking direct coding costs. Don't forget the perennial IT backlog, conflicting IT projects, budget negotiations between business departments and IT, political power negotiations between senior management , and the many other common barriers to getting changes agreed, designed, built, tested and into production.

Essentially what this boils down to is that decision services are critical where the speed of change must be determined by the business and not IT.

That is, it must be possible for the business to update the rules, or the rates or factors on which they depend without being constrained by IT projects or IT change and transport cycles. For example, if a new rate is determined, it may need to be implemented within minutes, hours or days of the new rate being decided, regardless of whether this fits with the current IT transport schedule.

How to decide whether to turn a decision into a decision service

Not all decisions are necessarily suitable as decision services.  When choosing potential decision services, the first step is to check that the decision is suitable as a decision service. Decision services are used where:

• The decision is repeatable
  • There is a pattern to making the decision that can be followed and automated
• The decision is non-trivial
  • It is sufficiently important that the benefit of making accurate, reliable decisions outweighs the cost of automation
• The business process, or business event, that triggers the decision is clearly identified
  • We know when and where the decision needs to be made
• The information needed to make the decision is known
  • We can identify all the data needed to make the decision
• The knowledge of underlying business rules is clear
  • We know the legislation, policy and operational considerations that go into making the decision
• There is a clear sequence or order to applying the business rules
  • We know what rules have to be checked first, and can clearly articulate when we have applied all the rules and can return the result
• The business needs visibility of the decision and the underlying business rules
  • We must be confident that the correct rules are being applied
• The business is accountable for ensuring the underlying business rules, and any rates or factors on which they depend, are correct and current (up-to-date)

Typically the need to make the decision, and the calling applications or other triggers that require the result of the decision, change very rarely; while the underlying business rules, rates, factors, and even the data sources evaluated in making the decision may change frequently.  There may be any number of causes of frequent changes to making the decision; common causes of change include:

• Changes in legislation
• Changes in policy  or operational practice
• Changes in market conditions, e.g. competitive pressures might mean we lower thresholds or raise discounts to give customers a more attractive outcome
• Changes in our business partners or our arrangements with our business partners, e.g.  a change in a carrier’s rates might make it more attractive to ship with them
• Changes in rates and factors that need to be periodically updates, such as inflation factors, discounts,  minimum/maximum thresholds
• Changes due to corrections, e.g. updated formulas

As a second step, many SAP solutions provide for calling of decision services at certain points within a solution. For example, in many SAP solutions these days, such as TRM, CRM Utilities, CRM Social Services, Debt Collection Strategies, etc. , there are often several points where decision services may be called either via configuration – i.e. the rules application that holds or the BRF+ function that represents the decision service can be directly entered in configuration – or via standard business logics slots such as BaDIs – i.e. Business Add-Ins where additional business logic code can be added, including calls to a decision service. Examples include, but are not limited to:

• Decision services for complex validations on data entry forms
• Decision services for determining whether someone is eligible for a benefit, or discount
• Decision services for determining which collection strategies will be used to pay off a debt
• Decision services for determining amounts, such as debt amounts, tax amounts, entitlement amounts

Where SAP provides for the calling of specific decision services, often the signature (i.e. the inputs and result) of the decision service are predefined.   But of course you can create your own decision services too, which is especially useful when you want to call decision services from custom programs or BaDIs for your organization-specific or industry-specific decisions. Once the potential decision service has been identified as available and suitable for use, the decision service needs to be logically decomposed into the underlying business rules, and the information needed to support the decision, i.e. the rates and factors, and data sources which underpin the business rules.

What’s the difference between a decision service and a business rule?

I find the simplest way to think of business rules is as subcomponents of a decision.

Let’s take my A/V Receiver decision as an example.  If I was to turn the choice of A/V Receiver into a decision service, there are a number of business rules I might want to include, such as:

• Is the price of the receiver within my budget?
• Is the receiver in stock from a supplier I trust?
• Will the receiver support my current and desired future surround sound requirements? Because I’m thinking of moving from a 5.1 channel to a 7.2 channel system later this year.
• Did the receiver rate in the top 5 recommended receivers at review sites I trust?
• Will the receiver fit in my current entertainment unit cabinet?

Isn’t a business rule just a decision service in itself? Certainly sometimes it is. But here’s the thing - most of the time I don’t care whether any of the shelves in my entertainment unit are sufficiently high, wide and deep enough to hold a different A/V receiver, and although I could have measured the shelves at any time, there was no value and no reason in doing so. In other words, unless I have a decision to make, I'm not all that interested in the rules that go into making that decision.

So this is where I take issue with those who suggest that a business rules engine should be some sort of massive re-usable bottom-up designed repository of all the possible business rules in an organization, which are then assigned to the relevant decision.  Where’s the cost benefit in documenting a whole heap of rules that you may never map to an automated decision service? It’s usually better or at least far more pragmatic to work top-down, i.e.

• What decisions do I need to make?
• How do those decisions map to decision services?
• What rules underpin those specific decision services?

What about reusability?  Sure, some rules are re-usable - checking if the price of a product falls within my budget for starters.  But again here’s the thing – when you are adding that next decision service, it’s a lot easier for the business to identify rules they want to re-use, and upgrade them to a re-usable version, if they can see all the rules in the first place.  Actually what we find in practice is that underlying rules are often less re-usable than you might think, it’s more often the data sources or the rates and factors that you want to re-use.

What isn’t a business rule?

I don’t have to specify that a date is a valid date, any more than I have to specify that my entertainment unit has height and depth and width.  It’s an entertainment unit – height, depth, and width come with the furniture – literally.  It turns out that with SAP solutions you tend to get quite a lot of built-in rules that come with the furniture: data typing rules, data validation rules, standard configuration, process flows, business objects, etc.  The beauty of DSM/BRFplus for many decision services is that those furniture rules can be treated as instant data sources whenever I want to call on them.

Decision services, business rules and effort estimation

There's another useful aspect for project effort estimation when you consider decision services vs. business rules.  Speaking as someone on a very large project involving well over 1000 rules to build, it's a lot easier, and far more effective to break effort estimation by our into our dozen decision services rather than our many many many business rules.  Plus it makes a lot more sense from a testing perspective, because while I *can* individually test most of those rules, in practice it's shows more progress to my business people if I can show a whole decision is working, and show it being called by the relevant calling application.  Granted some of our decisions hold only about 20 rules, and one has more than 400, but then from a testing perspective we can also break ourtesting into checking a decision service makes the correct decision for each business scenario, without the business person who's testing it having to worry about how many rules this particular execution of the decision requires.

Oh and don't forget to include your Rules Catalogs, i.e. the business view of the rules where they will adapt, simulate, and deploy future changes, as a part of your effort estimation.

Final thoughts

Would I put my A/V receiver decision in DSM/BRFplus? Well not for myself, I’m seriously hoping this is not a repeatable decision, but if I was a company selling home entertainment theatre equipment … then it might well be worth automating decisions about best or recommended A/V receivers based on typical rules my customers apply.

In the meantime I’ve made my decision, ordered my A/V receiver, and I’m off to pick up my new A/V receiver in the morning.   Wish me luck with connecting all those cables…!