I am closing this blog down because YASU has been acquired by SAP. I have had a tremendous one year blogging here.

My thanks to all those who have been following this blog, especially James from who I have learned quite a bit in the last 1 1/2 years of following his writings.

I expect to be very very busy in the next two months, New company, new job, new colleages .

But, I will be back on the blogging scene some time later through a different blog.

Auf Wiedersehen. Bis Bald . (My german baby steps ..)

What struck me immediately were the following

1. Many of these failures were the result of “software taking bad Decisions”.
2. It took a huge effort in some cases to rectify the total damage, to customers specifically
3. It requires a huge testing effort to validate these systems before rolling them out

Here are some of the interesting ones

1. A software error reportedly resulted in over-billing of up to several thousand dollars to each of 11,000 customers of a major telecommunications company in June of 2006. It was reported that the software bug was fixed within days, but that correcting the billing errors would take much longer.
2. In early 2006 problems in a government?s financial monitoring software resulted in incorrect election candidate financial reports being made available to the public. The government?s election finance reporting web site had to be shut down until the software was repaired.
3. Media reports in January of 2005 detailed severe problems with a $170 million high-profile U.S. government IT systems project. Software testing was one of the five major problem areas according to a report of the commission reviewing the project. In March of 2005 it was decided to scrap the entire project.

Preventing & Recovering from Bad Decisions

BRMS cannot help with all kinds of software problems, but they are best when it comes to software driven business decisions.

As I have maintained in the past, using rule engines and business rules management systems, helps you with exactly these kind of problems.I have talked about this before, here is why

• Using BRMS and rule engines helps you write maintainable applications that lend themselves to change. 
• When Sh** hits the Fan, you need your business guys, and here is how you can involve them using business rules technology
• When you discover errors in your rules, because the rules are externalized, turn-around times for testing is much, much faster.I have discussed this here, here and here

He draws this conclusion in his paper

Implementing a BPM/BRMS system is not merely an application change. It is a change in the way that an organization works.
While it is not as complex as a re-engineering exercise (BPR), organizations use this time to standardize the rules, evaluate the rules present and decide which of these rules to retain etc.
Any change in the way that the organization works results in resistance from people. When implementing these systems, time for training users should also be included.

These are topics I have blogged about before, so I wont go further. I have written about Business Rules & Maintenance and Business Rules for the Analyst and about How a BRMS Promotes Collaboration.

Here are some useful links

1. QuickRules.NET Quick Tour (Video with Audio)
   
2. Product Home Page: http://www.yasutech.com/qrdn
3. What’s New: http://yasutech.com/qrdn/whatsnew.htm
4. Visit http://downloads.yasutech.com to download the Product

If you would like to have a go at the product, you can either download directly, or drop a comment.

Enjoy!

1. Modularity
2. Consistency
3. Simplicity & Conciseness
4. Self-descriptiveness & Understandability

I will go and add one more to this list, Independent Testability. That will determine if the module can be tested independently of the rest.

I liked this topic because, one way to look at the business rules market is to see it as a subset of the software maintenance market itself.

We want to build business applications that can evolve with fast changing business requirements. And the business rules that drive operational decisions change real quick.

So, using a business rules management system to externalize your rules, and to deliver business decisions using Decision Services works very well, for many different kinds of systems(New Product Development, Insurance Claims, Trade Alert Engines etc)

Here are my five reasons why using rule driven Decision Services leads to more maintainable applications

#1 - Modularity

Modeling operational business decisions as Decision Services that internally use a rule engine, immediately provides this advantage.

1. A Decision Service is an independent Unit that can be reused by any number of applications
2. The Business Rules are externally managed using a BRMS, and their life cycle is determined by the Business Rules Life Cycle.
3. Modular and Reusable Services are enforced automatically when using a Rule Engine and rule driven Decision Services.
4. This allows the Architect to think in terms of the Service and its function, and leave the Rule Development to a Separate Team.
5. Because the rules and hence the business logic are so clearly separated, development & integration responsibilities are very clearly defined leading to modular designs.

#2 - Consistency

1. All logically related rules will be organized and maintained by business functions rather than by software module. This lessens duplication chances and improves consistency
2. The Same Decision Called from any number of places behaves in exactly the same fashion
3. Because rule driven Decisions are Independently testable, enforcing consistency is a lot less expensive

#3 - Simplicity & Conciseness

1. It is possible to capture the business rules in a form that is close to how business analysts can understand it.
2. Examples include Decision Tables (Can write them in Excel), or Flow Rules (can create in a form of a Flow Chart, using Visio)
3. There is no need to try and define complex abstractions to model business rules in code.

#4 - Self-descriptiveness & Understandability

1. For example, a Pricing Flow Rule will describe precisely how a Pricing Decision needs to be made. This level of descriptiveness will be impossible with code
2. Pricing Tables locked up in a Database Table will never be able to communicate the complete picture as effectively as a well designed Decision Table
3. Documenting complex System behavior as it applies to Decisions becomes very simple when you use Business Rules Technologies

#5 - Independently Testable

1. One of the main drawbacks with conventional programming techniques to build Decision Services is Testing.
2. When the rules change, as they will, Impact Testing will itself become a huge cost.
3. Using business rules enable teams to develop and test the decision services in parallel saving considerable time and cost

Related Reading >>

1. 10 Steps towards the Agile Enterprise
2. Real World SOA & Decision Services- One, Two & Three
3. Concurrent Development & Ease of Testing

• Rules are normally tied to the underlying data model and therefore difficult for business analysts to work with
• Tools make rules look too techie for business analysts to consume.
• Tools are very difficult to use
• Business Rules Tools come with a lot of baggage that are unnecessary for business analysts.

Many vendors including my company will be guilty on many counts for all these charges. However, there are some points that I wanted to make. Based on what I have seen, here are some of my own observations.

• Non-technical users like business analysts are most comfortable with Decision Tables.
• They are also comfortable defining decision making sequences using Flow charts
• They are not very comfortable with writing If Then Rules or Named Action Sets or Named Condition Sets (Decisions Branches)

The example that Stellan uses to illustrate his point is this one.

One of your analysts suddenly discovers that a competitor has lowered the levels for being eligible for a discount and you think that this will impact your business if you do not do the same, so the analyst needs to quickly adjust your current discount levels in the system.

Here, the rules we are talking about are Adjustment Rules for Pricing. And typically these kind of rules change often.

These kind of rules are mostly Decision Tables. Other scenarios where rules will be modeled as Decision Tables will be Rate Calculations, Eligibility Criteria, Pricing Rules etc.

As I had mentioned in my Seven Tips for your first Business Rules Project, how rules are designed is a critical aspect. You need to keep business analysts in mind when a rules enabled system is architected. Good tools by themselves are useless, if they used incorrectly.

Here are some suggestions on how to involve your business users

• All things start small. So, don’t push your business analysts into business rules too early
• Involve them in the rule capture phase, and get your IT Developer to write the rules under their eyes. You can consider Pair Rule Development for a small period of time.
• Involve your business users in the rule design phase. Here organizing the rules into logical units is the deliverable, and their inputs will be invaluable
• Let them discover how easy it is to update decision tables and Flow Rules. Do not expect them to do anything more than Decision Tables and Flow Rules.
• If you are using Inference Rules and Rete, things can get complex. So, use expert judgement as to whether you want them to do this at all.
• With If Then Rules, they can probably begin with making parametric changes, and with experience go into adding new rules themselves.

In short, here is what I think.

• Business Rules ARE NOT Requirements
• Software Requirements Must refer to Business Rules, and NEVER the other way round
• Business Rules evolve independent of Requirements
• Business Rules changes are driven by the Business, and not IT
• Business Rules Cannot be Managed using a conventional Requirements Management tools. You need a BRMS provide those capabilities.

Both Scott and James share the same perspective, and they have my complete agreement on this.

Example of SLA’s (Extract from Sherman’s write-up)

• All cases must be responded to within 2 business hours
• All Urgent priority cases must be responded to within 1 hour regardless of business hours
• All cases must be responded to within the phone response time as stated on the contract
• All cases must be closed within 5 days.
• All sub-cases of type “Hardware Upgrade” must have a technician onsite within 36 hours.
• All new cases for a Gold level customer must get a call back from a senior tech within 1 hour.
• An initial response must occur within 8 business hours

The problem is essentially this

1. How do you ensure Support Level Agreements for each customer are met with?
2. Each Customer might have a slightly different SLA. By default companies might provide defaults like Gold, Silver etc.

A Rule based Solution

• A rule engine will essentially decide response depending upon a SLA for a given customer whenever a issue comes from a customer
• And each SLA will become a rule set, in my opinion in the rule repository

For example, you will have rules like below

• If Issue Severity is Level 1, Then Response Must go within 2 Hours
• If Issue Severity is Level 1, Then Updates Must go every 2 Hours
• If Issue Severity is Level 1, Then a Resolution Must go within 8 Hours

Why should you do this?

• The reasons are that the SLA and the contract will be visible and in a form that is easily changeable.
• It will be easy to get a semi or a non technical user to enter the SLA contract details into the System
• The SLA’s will be automatically externalized from the system, and adding new SLA’s will become much simpler that with code.
• The system can be programmed to determine the response based on the SLA by calling the rule engine (So much service like)
• Additional quality reports like if 3 responses violate the SLA, then escalate issue to Account Manager etc can be modeled much more easily than with conventional approaches like Stored Procs.

Final Words ..

The solution will of course me much more involved, and there are a lot more use cases, but the intent was to illustrate that this is a problem that can use a rule engine based solution.

Related Reading> Business Rules and Complex Event Processing

Personally, I am normally careful about any big bang approaches to change, and the popular SOA philosophy seems to be propounding exactly that. I like the MS SOA story, though others have been blasting MS over their SOA definition.

When you use a Rule Engine, and a BRMS, you will realize instant SOA nirvana. Not only are your rules automatically separated from the rest of your application, your Decision Service becomes a reusable service.

This is especially true, when you bring new MS technologies like WCF into the picture.

1. Creating a Web Service or a WCF Service is a No-brainer.
2. Creating a Decision Service is a No-Brainer, as long as you have addressed some important challenges
3. Using these Services with any .NET technology is a breeze.

At least in the .NET Universe, the road ahead is clear.

1. SOA is here to stay.
2. Business Rules Technologies are here to stay.
3. WCF based rule driven Decision Services will kick off

So, people, Just do it!