This is the first of my 3 part series on real world SOA and rule driven decision services. I am going to essentially talk about the following items

  1. What you need to know about a Decision Service ?
  2. The implementation landscape including actors and roles, technologies and skill sets. What are the typical challenges that might arise when using rule driven Decision Services in an SOA
  3. What Kind of a Solution should you need to look for when you need a Decision Service?

Decisions and software Automation

There are many business decisions that can never be automated, like say a hiring decisions. But many others can be. Some examples of business decisions that can be automated are

  • What is the Severity Level of a Support Request?
  • Is an applicant eligible for a Loan?
  • What is the risk factor for a specified loan applicant?
  • How much discount to give a specific buyer?
  • How should a marketing campaign be structured for best results?
  • How much commission should be given to sales force personnel

Some of the ways to automating these decisions

  • Write a java/j2ee/.NET module that will provide the decision making functionality.
  • Keep decisions close to data and implement them as stored procedures in the database
  • Use a scripting language like Ruby, and build a DSL
  • Use a BRMS, externalize the business rules that drive the decisions, and use a rule engine to execute these rules

When it comes to Decisions, plain Automation is not enough

Plain vanilla automation is not enough when it comes to automating business decisions. The reason being that

  • The rules that drive decisions change because of business requirements change
  • The rules might change often and follow a different change cycle than the rest of the system1
  • IT personnel maintaining the software system will not be knowledgeable in these rules.

So, a Decision Automation design must be built to accommodate these regular changes to the rules. As you can see, managing changing requirements and accommodating changes quickly must be a design criteria.

So, the assertion here is that what we need is Decision Change Management, and not just Decision Automation

Introducing the Rule Driven Decision Service

Using a rule engine can be the best solution for many situations to implement Decision Change Management. Please refer to Automating Decisions using a Rule Engine for a better treatment of the subject.

So, this is how you do it with a rule engine.

  • Step 1: Define a Service interface for the required decision.
  • Step 2: Implement the Service such that it internally uses a rule engine
  • Step 3: The “how to take a decision” criteria, you implement as rules
  • Step 4: Manage your rules using a business rules management system

The Service interface can then participate in any kind of an orchestration.An example of a Decision Service could be a Discount Service

  • A Discount Service will compute and return a discount for a given buyer based on his past history
  • The Discount Service will internally use a rule engine to deliver the decision
  • Users of the Discount Service will see it it as a Stateless, and Reusable Service/Module
  • The rules will be managed using a business rules management system

In the Next Post

The implementation landscape including actors and roles, technologies and skill sets. What are the typical challenges that might arise when using rule driven Decision Services in an SOA

Share and Enjoy! These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Netvouz
  • DZone
  • ThisNext
  • MisterWong
  • Wists
  • BlinkList
  • Furl
  • Ma.gnolia
  • NewsVine
  • Spurl
  • TailRank
  • Reddit
  • SphereIt
  • StumbleUpon
  • Technorati
  • YahooMyWeb

No Responses to “Real World SOA and Decision Services - Part 1”  

  1. No Comments

Leave a Reply