Job Trend Leader's

Here is an interesting analysis of job trends for three major Rules Engines for Last year. (this is a analyis of jobs posted on internet with the keywords mentioned in the charts - source is indeed.com)

Looking at the charts it seems like Pega is gaining marketshare overall in the job market and ILOG is losing. It is quite sad that ILOG does not publish its numbers in comparision to BPMS vendors , while it does keep on claiming that it is 800 pound gorilla in the BRMS space.

Note that the BRMS space itself might be 5 by 5 square foot space. After 20 years of effort and 250 ISV's its revenue is 100Million only.No wonder its market cap is only a tiny fraction of that of its customers.

I will publish a post in the coming weeks highligthing the problems with ILOG and its business model Look out for it.



A few other charts of interest.

The Java technology chart is not surprising to me. Spring is the clearly the choice for application development and I am not suprised at the trendlines. The steady decline of EJB's and the steady rise of hibernate are also not surprising.


The Chart of particular interest to me is the GWT chart. Note the sudden burst in job postings for GWT in Jan 2007. This is a technology to look out for.I will not be surprised if GWT takes over struts in an years times.

Also note a comparision of salary levels of various skills

java $76,000
.NET $67,000
GWT $78,000
Spring framework $79,000
hibernate $80,000
jboss $76,000

View Larger Salary Graph

What is a Business Rule - Part 2 Three Cases

Following my earlier blog entry regarding what is a business rule. I thought about elaborating this further by describing three cases of rule development.

1. Case 1 : Sure shot rule

Consider the following requirement:

The Work Allocation of the claims file happens based on the following set of rules.

If the type of Policy is a personal auto with no driver on the policy below 25 years of age and the claim amount if less then $1000 the allocate the claim to a claims rep

If the claim amount > $10,000 allocate the claim file to a supervisor

If the insured vehicle was parked in open parking lot allocate the claim to claims rep and notifying the supervisor. The claim has to be approved by the supervisor

………………
………………


The above set of rules describes allocation of a claims file to a role in the claims organization of the insurance carrier. This is a clearly a business rule set that needs to be in the BRMS tool. These are a set of rules that the business is interested in knowing about, viewing and potentially maintaining. This is a classic case of why someone purchases a rule engine.


2. Case 2 : Grey Area

Consider the following two requirements
a) Verify that the claim number or the policy number entered by the user on the screen is a valid number. If the number is valid then create a Claims file in the system with the information provided. If the claim is invalid then notify the customer to re-enter with a valid number

b) If a customer has as an excluded driver on the policy then shown the driver exclusion screen.

Requirement 2a) above is really business process requirement and describes how the system needs to be implemented. This is a scenario where some business users of the carriers organization might be very interested in knowing about it while others might not care about it at all saying that all that they care is that the claims file should be created and going to detail of error conditions in business process is not their problem.

The rule text could potentially be something like the following if we choose to write this as a rule in BRMS tool.

If
The claim number entered is “valid”
Then
Create a new Claims File
Else
Re-Enter the claim



Case 2b) is a screen navigation rule, generally implemented by the technologies used in developing the screens – example Structs web framework OR Flex based UI tool. But I have also seen cases (in large P&C carriers) where the architect has chosen to implement such rules in the BRMS tool.

In my opinion , these decision’s really boil down to the guidelines I had described in my earlier blog. There is frankly no right or wrong answer in this case. It is joint decision of the organization.


3. Case 3: Not really a business rule

Consider the following functional requirements
a) The Date entered by the user should be in the format dd/mm/yyyy
b) If the premium displayed to customer is less then the current premium paid then display the premium in Bold Green with blinking text.

These are clearly not business rules and should not be maintained in BRMS tool.

Rule Based Systems : Why use a rules engine

I have been working with Rule based systems for quite sometime and I have moved from a non-believer to a believer and now a business rules envangelist over the years.

Over the years I have been asked several times the question?

Why Do I need to spend $100,000 buying a rule based system ?

The arguments I get (and frankly the arguments I use to give 5 years ago) for not using a rule engine in a project included:

1. Why are we adding one more layer of complexity to the project ?
2. Most of the rules we have dont change so often then why do we need a rules engine ?
3. I can write rules in Java in a similar modular fashion as an off the shelf rules engine just by by definining a clearly defined interface and putting all the rules in a seperate package.
4. Why should I learn more language for writing rules.

Over the years I have relialized that there are broadly 4 categories people use Rule Engines.

1. Flexibility :
This is one of the biggest sales pitch from the tool vedors. They basically sell the idea of the ability to make changes to rules and not make code changes. They also sell the idea of making realtime rule changes and these changes taking effect immediately in production.

While this is a very important reason to buy the product. In my experience this is something that has been overemphasized and have not really seen getting used a lot. With the SDLC procedures in a lot of places requiring UAT before anything moves to production , this feature that does not get often used.

But their is still value in this and I have seen this working in some environments like .com or retail.


2. Seperation of Concern :

This is really a best practice in software development. It is always good to seperate concerns like Database interations , Logging , Rules , etc to seperate areas.

So the question that comes is : I can do this by structuring my rules in a seperate package and have a clearly defined interface for rules interactions. This is true and this can be done by having a diciplined approach in SDLC but when using a BRMS tool the dicipline comes from the top and gets enforced easily , this might not be the case when using pure java interfaces.

3. Centralized Rules repository and a visal interface (most modern BRMS give this) :
Having a central knowledge repository that details out every fine grained business rule is a dream for most IT organizations.

This is possible with todays BRMS tools like ILOG or Fair Issac. Both the tools have excellent visual cabilities. This feature in iteself will recover the full cost of the BRMS tools. But the word of caution is that just the tool will not lead to keeping all the rules in the BRMS tool. It requires diciplined project management to achieve this

4. Closing the Business IT GAP
This in my opinion is the most compelling reason to buy the tool. In my experience the biggest problems facing the IT organization is the ITness of it. i.e the business view's IT as rocket science and what IT engineers do is a black box . Having a tool like Ilog and Blaze removes the barrier between IT and business.

The business analyst now can view and play with rules that effect business and hence get very close to the implementation.

An Analogy : About a two decades ago , there was a very important profession of a steno person. Someone who would take dictation and then type it in print , there was also the notion of proof reading and that whole excersice was a highly skilled activity. As computers became popular and more user friendly , the job of the steno disappeared as the authors got a tool that was so easy to use that using it themselves was more efficient as compared to dictation and proof reading. The promise of BRMS tools is similar for IT


Fig 1


In the above diagram I have tried to put the value of each feature along two axis