Eric's BizTalk 2004/2006/2009 blog

Lot's of folks ask this question. It's a lot like what folks were asking about unit testing and test-first programing principals. However, over-time, they understood the value.

In a nutshell, a BRMS solves several key problems for developers and architects:

1. Encapsulation--you want your code clean and in one spot using a single point of reference and management.
2. Simplicity--you want to use BRMS technology to simplify your rules so that they are easier to manage from an algorithmic perspective.
3. Visibility--you want to be able to share your rules with non technical folks--they won't understand code.
4. Collaboration--code in reality is a social artifact. Business rules are the most socialized part of a solution and require the greatest effort to express and manage. Rather than trapping this content in requirements documents that have to be manually updated its a better practice to model rules in a toolset that can reuse the model for exeuction...all-the-while translating the rule between the langage of the business with the technical language of the code.
5. Shared Execution (SOA) -- once you have made an investment in rules then you will want to share them across all of their deployed applications. This is the deployment side of encapsulation.

Only recently have folks in the .NET world started thinking critically about code ownership, collaboration and practices from an architectural perspective. The compiler is our friend for sure but it can't solve all of our requirements.

Chris Berg
Product Manager, ILOG
cberg@ilog.com
http://www.ilog.com/products/rulesnet/

See our stuff also at: www.microsoft.com/ilog/

This is good information, I ask the question because I had a hard time finding an answer that I felt comfortable with in a understandable fashion.

Shoo; just did a quick check at the calendar to ensure it was in fact not 1st April. :)

The BRE is a very powerful engine that allows you to create flexible rules that govern your business processes. If you code your logic in C# what happens if that logic changes? The BRE allows you to easily modify the rules that govern your process. Ok, sure you could code the same flexibility using config files or database tables etc. But you could also role your own OS instead of using Windows. :P

I like the fact that through vocabularies I can create English, non-tech person friendly rules that can be modified by somebody closer to the business process. This has inherit dangers, but if managed correctly the process works.

The forward chaining of rules that are available in the BRE is incredibly powerful and I find the BRE to be extremely quick to process rules on even large messages.

I like the fact that I can have multiple processes, systems re-using the same rule without any hassles.

Are you a believer yet? ;)

I love the BRE and hate it when I get to a site without Bts and hence no BRE and have to do business rules the old way.

There is not a lot I can add to previous comments. The way I generally describe the benefits of a BRE to BizTalk people is in terms of the ability to cleanly separate business policies from the rest of your business logic. The motivation for doing this is that business policies tend to change at a different rate to business process definitions. You don't want to have to redeploy your BTS solution every time the company decides to change the terms of its discount scheme. What you really want is some way to externalise policies, store them in some suitable repository, version them as required and then deploy them directly into your live environment without requiring code changes.

Here is a different example. On the project I am currently working on, we are using the rules engine to implement a Service Directory which we use to resolve service requests in order to achieve stronger decoupling of business services. Most BizTalk applications use subscription rules (processed through a form of rule engine) together with (mainly) static configuration on Send Ports in order to route messages on to the outside world. If you introduce a new version of a business service which you need to run side-by-side with an older version, or if you change the location of a business service, retire it or replace it with an equivalent service, you have to change configuration, often in several different places, and you may very well have to deploy new versions of some of your BizTalk artefacts. However, using an ESB pattern, you can use additional rules processing in order to work out what configuration to apply dynamically (i.e., on messages passing through a dynamic port) in order to rout messages. Routing rules are expressed as externalised and centralised policy. This is more flexible, easier to manage and significantly more ‘service-orientated’.

What is a little disappointing about MS BRE is that it doesn't really offer the kind of sophisticated and well designed tooling we need to apply rules processing as widely as we should with the minimum of difficulty. The engine is certainly very powerful (far more powerful than most people realise, though it lacks a couple of features it really ought to have), but the rules composer and repository are very basic. If you are still not a believer, maybe you should look at alternatives like ILog or Blaze Advisor to see what they offer.

Thank you for this. I love this kind of entry is what I am looking for. I am looking for real world cases that will make me (and other blog readers) a believer!

Reasons for using BRE:
1. Versioning and deployment of business rules is much easier 2. Your C# classes and T-SQl table/field names might be too difficult to comprehend by non-technical people. When you create a vocabulary, its easier for them to create and update business rules in a language they are familiar with.

These are the two most compelling reasons in my opinion. There might be more depending ont the application.

Hemil:
Here are my arguments to your points:
1. Versioning; I would like more control of the 'versioning' that is in the BRE. As I am developing I make a lot of mistakes (this blog is a testament to that fact), within the BRC, every thing I do is versioned, so by the time I am done testing I have 30 different versions! Then deploying those to another enviornment is completely confusing, which version am I deploying again, just version 30, or all of the versions? Easier?!?
2. It is easier to create and business rules, aren't these the same people that in the previous sentence did not know about C# and T-SQL logic, now you are asking them to create the vocabularies off of those C# and T-SQL components?
- Again, I want to believe; but this is not too convincing...

intresting thought...

ever believe in centralized repository for business functioanlity?

SQL store procedures are not rules.. they are just procedures..

c# methods are functionality not rules agian..

Rules consist of simple/complex combinations of what action needs to be taken. Terms like RETE algorithm, Facts Assertion and so on have great meaning associated with them when you really need some control over business processes.

if you are basing your decision based on versioning.. think again.. its there to help you.. it is one of the features business users love and not developers....

See my white paper on ILOG Rules for .NET and BizTalk integration:

http://blogs.ilog.com/brmsdocs/2008/06/24/integrating-ilog-rules-for-net-with-microsoft-biztalk-server/

I believe I have addressed the issues regarding when to use BRE and when to use ILOG. Each has its place.

Chris Berg
Product Manager, ILOG
cberg@ilog.com
http://www.ilog.com/dev/brms/rfdn/

That's great, I never thought about Business Rules like that before.

I just wanted to say thanks to all the people who commented on this post. It has really helped me understand the importance of BRE. Great blog!