Saturday, October 28, 2006

Rules and Business Processes

It has been raining like crazy in Boston today, so I've had an excuse to sit and catch up on some blog reading that has been a little sidelined since I started my new job at Global 360.

So I was really pleased to run across Bruce Silver's analysis of Where Rules Engines and BPM meet. Business Rules Management Systems (BRMS) are something that I am getting more contact with now, and Bruce really summarizes them well:
In fact, the heart of a business rule management system is in the rule repository, which supports rule discovery, governance, versioning, traceability and reuse across the enterprise. The business rule engine executes business rules defined in a structured rule language supported by the BRMS rule design tool.

Corticon is the system that I have been looking at, with its integrations with the Global 360 enterprise BPMS products. Before moving seriously into this space I believed that most of the value of BRMS came from the rules engine and a user's ability to powerfully define rules in a fairly understandable manner. Now I'm starting to understand the potential of the modeling, central rules repository and rules 'lifecycle management'. This really allows customers to define their policies and rules for decision making and guiding processes in one place, enabling their reuse and consistent application across multiple processes.

BPMS can really benefit from the rules engine, and centralized rules repository during execution of processes. Pulling the remaining rules management seamlessly into place alongside process management is more of a challenge than just integrating the process and rules engines, but is essential to ensure that there is a seamless enterprise view of the way IT systems are managing the way the business runs. Pulling systems together for seamless modeling is always hard - especially when much of their value can also come from them working independently. This is something I need to spend more time concentrating on.



Technorati tags:

3 comments:

Anonymous said...

My 2 Cents, Additionally !
1. Rule Repositories allow Standardized Policy Deployments across the enterprise.
2. Many organizations need to be able to replay scenarios as on a given date. Without a Rules Repository, invoking historical rules would be extremely difficult (eg: Loan Lock scenario in a Mortgage firm)

Phil Ayres said...

Good points. So for organizations that may need regular updates to rules to accomodate their 'agile' operations, it is essential for audit, litigation and maybe financial compliance purposes to be able to replay scenarios.

In combination with business or process intelligence it seems that the ability for rules management systems to easily link back to previous rules enables business users to adjust their rules based on the goals of their business backed up with hard data.

I need to keep researching to understand how all this stuff fits together better.

Anonymous said...

Great! Now we are talking Business Rule Analysis, as being separate from Business Data Analysis.
Let me try and express your ideas in my own words for my clarity!

Objective
Analyze rules to improve and optimize them to deliver precise intended business performance

What If?
1. A Business User is able to simulate best case, worst case scenarios?
2. A Business user is able to test run rules against historical data to study policy change impact?
3. A Business user is able to "get out of the guessing game" and write rules that provide results?

Very Interesting!