Hi Everyone,

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 ..)

Michael Krigsman reports some 40 IT Failures caused by Software Bugs from the Software QA Test Resource Center.

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

Rajagopalan N's Blog | Permalink | Comments and TBs(0) | Attachments (0) | Send this via E-mail | Images (0) | +digg | +del.icio.us
Categories: business agility, software maintenance, business rules management system, business rules, bre, brms, business rule engine

Narayan Devanathan from Wipro has this short whitepaper on BRMS and Business Users. It is an interesting read on.

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.

I am happy to announce that that QuickRules.NET 3.1 Beta2 is now public.

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

Please feel free to download and give me any feedback. Otherwise you can leave a comment-request for a download link.

Here is one interesting write-up on Requirements Modeling and Business Rules, http://www.regenerateweb.net/blog/node/19

Enjoy!

Jeroen asks, How maintainable is your Code? He goes on to identify 4 attributes of well written code.

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

Stellan raises some good points about using business rules technologies in automating decisions.His questions are essentially these

• 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.

Scott Sehlhorst talks about Business Rules hidden in Software Requirements. This is something that I have written on before. You can read Business Rules & Software Requirements for a more detailed writeup on this subject.

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.

Gary Sherman writes on SLA Monitoring, and I thought what a wonderful problem to solve using rule engines and business rules technology.

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

While I was reading Small Companies do not have time for SOA and Microsoft’s Just Do it SOA, I was wondering how Business Rules Technology so nicely fits in with this idea.

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!

This is my final post in this series.In part 1, I introduced Decision Services, in part 2, I talked about the challenges in implementing Decision Services.

In this post, I will attempt to come up with a set of capabilities that you need to aim to have when using rule driven Decision Services

The SOA Life Cycle

Before I go into my checklist, here is a small reference to a simplified SOA Life cycle.

The MS SOA Life Cycle.

• In Step 1, you would create a Decision Service.
• In Step 2, you would smoke test and deploy the service
• In Step 3, you would compose a larger service using other (possibly generated) services.

This is a very simple model for illustration purposes only!

What capabilities would you need?

If I was a Project Manager, or an Architect in an Organization that is adopting SOA and wants to use rule driven Decision Services, then these are the questions I would ask to begin with. You can use these questions to begin to formulate your own checklist

• What if you could create a Decision Service from the Business Rules without writing code? How about something simple and neat like a Wizard?
• What if you could deploy the service without understanding the underlying technology?In the Windows world, possible deployment options include an ASMX Web Service, as a Windows Service, as a Stand alone EXE etc.
• How can I make using Decision Services with Workflow tools like Windows Workflow Foundation or BizTalk easier?
• Can you use Decision Services with Workflow tools without bothering to understand the BRMS vendors tools? May be generate a Decision Service on the fly during development & testing from these tools?
• How can I enable quick and instant testing of the generated Decision Service easy for my Business Rules Developer?

Final Words

The objective of this 3 part series was to brush upon the subject of using rule driven Decision Services in an SOA environment. As is always the case, I have only scratched the surface.

More could have been said, further detail is possible. Because of lack of time, and the desire to be brief, I have listed only the top 3-4 challenges and not an exhaustive list, and in the process, might be seen as having missed out certain items. Please feel free to leave a comment if you have opinion on this subject

In this post, I will attempt to cover the implementation landscape including actors and roles, technologies and skill sets. I will attempt to identify the typical challenges that might arise when using rule driven Decision Services in an SOA.

A little Background

Lets take the example of a Pricing Service in a Loan Process. A Pricing Service will determine the cost of a loan for a given applicant. Price is determined by the Property Type, FICO Score, etc, and these rules change very often, some times twice or thrice a day.

Now, lets ask these questions to get started?

• Who will define and control the loan process?
• Who will define the contract for the Pricing Service?
• Who will define the rules that drive pricing?
• Who will write the rules for the Pricing Service? 
• Who will test the Pricing Service?
• Who will provide the test cases for the Pricing Service?

As you can see, the above are basic but very important questions whose answers will have a huge impact on how the Pricing Service is built and maintained.

The SOA Decision Service Lifecycle

The below graphic depicts a simple model of a lifecycle for a Decision Service.

• Step 1: IT Architect Defines the Service Contract
• Step 2: The Subject Matter Expert(Business Analyst) defines the rules
• Step 3: The Business Rules Developer implements the rules
• Step 4: Either/Both QA and the Business Rules Developer test the rules using the test cases supplied by the Subject Matter Expert
• Step 5: The Application Developer Generates the Decision Service
• Step 6: The Application Developer Integrates the Service and deploys the Service into the application/workflow

As you can see, there are distinct stages in the lifecycle, with different roles involved.

• Business Rules Developer (Semi-Technical, domain aware)
• IT Architect (Responsible for the the whole IT process implementation)
• Application Developer - Builds and integrates the application (In this case, may be an L.O.S)
• Subject Matter Expert - Business Analyst (Owns the business process and business rules)

The Implementation Landscape

Now that we have seen what the SOA Decision Service Lifecycle is, and who the actors (roles) involved are, it is time to highlight some of the important things that we need to know to understand the challenges involved in creating SOA Decision Services.

Check out these Fact Bits about for a starter.

• SOA Technologies like WCF or WWF, though much simpler than ever, still come with a stiff learning curve
• The Business Rules Developer is an expert at implementing business rules. This role is knowledgeable in the domain and is semi-technical.
• The Application Developer is trained to use SOA technologies, but will not understand the internals of the business rules or the rule engine/brms used to deliver the rule driven Decision Services
• Because Business Rules are externalized when using a rule engine, it is highly likely that the business rules development is done in parallel with the rest of the Application Development.

The Execution Challenge

So, the challenges as I see can now be formulated into the following points

• How will the Application Developer Generate the Decision Service without understanding the internals of the rule engine, the brms, the business rules and the vendor specific API?
• How will the Business Rules Developer run a Smoke Test of the Decision Service with only a tiny knowledge of SOA Technologies?
• How will the QA Personnel do Integration Testing with a minimal knowledge of both SOA Technologies and Business Rules Technologies?
• How will you realize the benefits of true parallel development when increased co-ordination costs jack up your project costs?

The challenge exists because not having a satisfactory answer to the above will inevitably lead to longer implementation timeframe’s. If not handled correctly, additional personnel will be needed to mediate between Application Development and Business Rules Development that will increase costs and errors

Next Post

In the next post, I will propose a solution that will address the challenges that I have mentioned. I will try and provide a Check List of capabilities that you should aim to have that will help you overcome these challenges

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

I was writing about Loan Processes, Service Orientation and Business Rules yesterday, when I remembered the write-up on the MSDN Architecture Site on an Architecture for a Loan Origination System.

This article explains in some detail about Loan Origination Systems, and explains how you can use the MS Technologies stack to implement a solution. Please read the article, it is a nice write-up.

But as I read it again today, some of the statements that Mike Walker, the author of that article makes, I found very strange. The four main process areas that Mike mentions are as below

• Products and pricing-The process in which personnel at the lender will analyze the secondary market and apply the proper pricing to the products (for example, 30-year fixed) or their portfolio products (products that the bank funds and usually does not sell to other banks or the secondary market).
• Application or registration-When the customer enters the proper qualification information for a loan product.
• Processing or locking loan-When a customer agrees to a specific product and rate, and “locks into a commitment.” This stage kicks off many sub-processes that gather extended information on the customer, to prepare the underwriters to make a decision on the loan.
• Underwriting-The process in which an underwriter makes a decision on the loan.

The article also suggests a architecture stack as a solution. But the interesting statement was this.

A common question is, “Why is there a separation between the business-rules and the orchestration layers?”

This separation is not always necessary, but in complex situations such as this scenario, in which business processes change frequently and rules are somewhat static, this scenario is ideal.

By separating out these two layers, you achieve:

• Agility. The ability to have a base set of rules that can be used in different ways (that is, orchestrations) without development.
• Reduction of code complexity. Now, business analysts or developers can model the process based on rules developed and versioned in BizTalk.
• Reusability. In loan origination, there often are multiple loan-origination systems (LOS) in a lender’s IT enterprise. Lenders are looking to consolidate and leverage a central system.

I find it strange because, I would have said exactly the same things, but for the completely opposite reasons.Here is why.

1. It is necessary to manage the business process, and you can choose to use a BPM to do this.
2. But, as I understand what a Business Process represents, it details how things work in an Organization, and these are never as volatile as rules are.
3. In the Loan Origination Scenario, I am not sure if it is the process that is volatile, but rather it is the business rules that are volatile
4. Pricing Rules, for example will change up-to 2-3 times a day because the prices are determined by the capital market
5. Every new product will typically have its own underwriting & eligibility rules. To support new products, he system Must allow for these new eligibility rules to be added quickly

Mike Walker’s somehow seems to imply that Agility is always the ability to change the process quickly.I disagree completely there.

In scenarios, where business decisions are automated, how quickly you can change the rules that will determine how quickly you can respond to a change request from the business

Related Reading

1. Extreme Mortgage - Generating a 1 Billion $ Pipeline in 6 Months

I have found myself explaining Service Orientation to members in YASU these last few days, and it seemed to be a perfect opportunity to get back into my blogging ways once again.

Here is a simplified version of a Loan Process. I’ll use this to talk about Service Orientation , and where a Business Rules driven decision service can fit in.

So, here is what the model says

1. Step 1: Loan Application for a specified Loan Product is created either online or through a Sales Agent
2. Step 2: Validate the Application
3. Step 3: Determine whether the applicant is eligible for the given Loan Product or Not.
4. Step 4: For a Valid Application, the system generates an approximate Loan that the applicant might get
5. Step 5: Underwrite the Loan and determine how much loan can be granted and at what interest?
6. Step 6: Disburse the Loan.

Now here are two ways you can implement this Process

Design Option One

1. Step 1 will be a Website that either a Sales Agent or a Customer will use. This is a simplified model, remember !
2. Step 2 will be realized using a Validation Module
3. Step 3 will be realized using an Eligibility Module that will know how to determine eligibility for every Loan Product
4. Step 4 will be a PreQual module that will know how to compute Pre-qual loan amounts
5. Step 5 will be a global underwriting module
6. Step 6 will be a fulfillment module.
7. All these modules will run as one application with appropriate web front ends
8. Let us assume that the system is impleemnted using java/j2ee or using .NET

Now, that is perfect, is it not?

Well, think again. Will conventional ideas abot how we achieve process automation really work and scale over time?

(more…)

QuickRules.NET 3.1 Beta 1 is now officially Out!

The Product now has its own minisite with much more product information than before. The fun with web sites is that you can keep on updating them as frequently as you want and that is exactly what I expect to be doing.

The QuickRules.NET Product Mini-Site

http://www.yasutech.com/qrdn

Here are some quick links to important Items in the site

• QuickRules.NET 3.1 - Whats New?
• The QuickRules.NET Rule Engine
• The QuickRules.NET Rule Builder
• The QuickRules.NET Rule Repository
• The QuickRules.NET Web Editor

And Finally

1. A brief History of QuickRules.NET

Check it out!

A perfectly valid question, and Karthik Hariharan asks this question and further discusses it here. Here is his argument in effect.

Development teams often have to write custom wrappers for their platform

Mapping English sentences to objects can often become a nightmare that requires a dedicated team of professionals whose sole purpose is to make sure the business objects have the supporting structure to be related via Business Rules.

And as many other developers have recently stated, changing business rules through non-programmers can create system instabilities that often make it to production systems due to the lack of good testing capabilities within the BRE.

I would agree with many of the points actually, as I have seen and heard of so many BRE failures in my career.

The main issue seems to be with data models and with involving business personnel into rule development and maintenance.

I have covered these discussions in detail in my Seven Tips for your first Business Rules Project.

Here is my advice (from my 7 Tips post) on how to think about data models and business users for your business rules project.

Never forget your data models. Rules finally apply on Business Information

Keep this in mind always. Business Rules Management Systems are also software that work in your application.

If you have stable data models, like say MISMO or your own in-house object model, then go ahead and write your rules directly on your data model.

If your data model is also evolving and you want to allow your rules and data models to evolve independently, then,

1. Identify your Business terms and capture them using the BRMS. In QuickRules, for example, you can capture business terms as Definitions.
2. Write your rules on these business terms.
3. As and when you believe your data model is ready, you can map it to these business terms and your integration is done.
4. Many times you require special functions. Many vendors including QuickRules.NET provide a lot of pre-packaged functions to get around this problem
5. You can keep on re-mapping them as and when you want to test for a milestone or whatever.

Get business scenario test cases. Get the business to give them to you.

You are writing executable business policies. Remember that! You MUST do this!

1. Get Test cases for the business decision that you are trying to automate.
2. If you can, you could even get test cases for each ruleset, which will be best.
3. You can do one better. Capture the test cases as Excel, and teach your business analysts how to test using their data.
4. This is an absolute MUST. DO not rely only on application level testing. That is late in the cycle. Test early and upstream, not downstream.

Business Rule Design. Keep your Business users in mind when writing the rules.

Once you understand your business policies and how they apply, it is time to start your Business Rule design using formats offered by your BRMS.

1. Identify and group your rules logically by use case. Keep them modular! Sets of logically related rules are referred to as Rulesets. Identify rulesets first.
2. Then identify how you would apply the policies in a Ruleset to arrive at the decision that the ruleset applies for. You MUST be able to state it!!
3. You can capture this rule sequence either using a Flow Rule (sequential & graphical) or as a Rete Ruleset (where the rule execution sequence is determined using the Rete algorithm.
4. First do Step 2#. You can always change it as you learn more !
5. Then identify and write the If Then Rules, Decision Tables etc.

NOTE
Business Rules represent your business policies. Your Business owns them. When you write them, keep in mind that the people who need to see them are not techies.

In all organizations, business rule implementation always begins with IT. With experience and maturity, you can hand over rule development, and maintenance over to your business analysts. But that mostly will not happen if this is your first business rules project.

Many authors believe and write about how Business Decisions are just Diamonds in a Process Model. I have made that mistake myself in the past.

But are your Business Decisions just diamonds in your process flow?

Just because some BPM tools make you believe it is, would you settle for something that obviously is not the case.

All are business decisions just diamonds on a process diagram? Lets see.

These are diamonds

• Is Applicant Eligible (Eligibility Rules)
• Is Valid Application

These are not Diamonds

• Compute Tax (Tax Calculation Rules)
• Compute Claim
• Compute Agent Score
• Compute Loan Price
• Compute Rental

So, when you are modeling your business processes, how would you model and account for such business decisions in your process?

I have argued many times about how process automation != decision automation.This is a very important difference to remember because how you take your decisions(business rules) are more volatile than your business process

And it is critical that you recognize this early and adopt an appropriate methodology to operationalize your business decisions such that you can change the rules as often as the need arises.

On a related note, here is a good introduction to Business Decision Automation using Rule Engines.

George Van Antwert writes about thinking of BPM as Topware.

And he differentiates between an application that embeds a workflow like an HR Performance Appraisal System, and a system that ties together multiple, potentially disparate systems into one larger deprtment wide or company wide business process(The TopWare).

So, the Topware essentially sits on top of your existing applications and coordinates the correct execution of your larger business.

Now, of course the Top ware could be a full blown very expensive BPM solution, or it could be a home grown SOA initiative.

Now, talking about “Wares “, we have seen middle ware, now we have Top Ware. So, what is left is just the “Under”. He He !!

Now, jokes apart, where do business rules and decisioning systems fit in? SOA architects might argue that the Decision Service is just another service, and I am interested in orchestration.

But, as I have argued many times in the past, managing business decisions in a digital enterprise is a very specialized activity and needs the full support of sophisticated business rules management systems.

So, to take this post to a logical conslusion, I would say the Business Decision Automation, Management systems like a BRMS would fall into the category of DecisionWare, along with other Decision Support Systems.