This is a very interesting article, I think that IT professionals reading this should also bear in mind that implementing and pushing out a rules engine to process owners will bring it's own set of problems to the organisation.

Giving process owners the ability to change rules means that tighter restrictions and monitoring needs to take place. Its like giving a 10 year old an electric drill to help you build a chair. Sure he can probably help you, but all of us know that we need to pay CLOSE attention to what he is doing, else there could be a very unfortunate accident.

It is the same with giving this to process owners. Many of them will not be aware of security requirements, change control procedures or segregation of duties needs. Very close monitoring needs to take place of these process owners, and one could question whether this is really more or less productive from a macro scale. In the long term (provided there is no staff turnover) it could be beneficial, as more reliance could be placed on these individuals as they learnt more about their responsibilities.

This is just something to keep in mind, and to moderate your overwhelming excitement of being able to get rid of this element of development. Caveat Developer.

There is a Rules Engines for the Dot Net platform. I used this product with the Early Adaptors program for the State of Washington in '01. Washington State Uninsurance Adjudication uses this tool for its decisions on UI disputed claims. Fully integrated with .NET and the mainframe.

http://www.rulemachines.com/Default.htm

Tom Vande Stouwe

MCT, MCSD, MCAD, MCP

A timely warning from Geoff - but I don't think Simon was suggesting that rules engines made "proper" development redundant. Simply, that a defined subset of tasks could move out to process owners, with appropriate controls assumed.

And the rules engine better have good configuration management to support all this, as Geoff implies.

But I think that, as with so many "advances" in IT, this will only work for mature, metrics-focussed, process-oriented oganisations - those that measure the results of what they're doing and apply corrections if the results aren't as desired.

Other organisations may achieve short term success with end-user rules and then fall into chaos. But this doesn't mean that no-one should try them - mature process-focussed organisations get that way because it gives them an edge...

The power of business rules management systems is that they allow the business logic (business logic, not all logic) to be exposed to the business owners in a controlled way. The problem with using code to represent this kind of logic is that it will probably never be right - the business users can't read it to verify it and it can't be changed quickly when they need it to so it tends to drift out of alignment.

Yes you can get into trouble with business rules, yes you can expose too much to business users and put too few controls in place. But remember what you are comparing it with - code for which there is no-one who both understands its business purpose and can read it.

Of course, I'm a fan so I would say that wouldn't I...

http://edmblog.fairisaac.com

It's important that any rules-based declarative development requires

a) a strict process to control changes

b) effective testing for all changes

c) configuration documentation (a CMDB would do the job!)

The key components are always going to be people and process, the technology is just a tool...

Well its great to see people that understand and agree with my comments. I can see the people who commented here have a good understanding of the concept of change control. I just hope that people who had not considered this risk pick the ball up now and do some research into IT controls.

A starting point may be the ITGI

http://www.itgi.org/

or alternatively you could just nab your friendly (sic) external auditor (the one that asks you every year for a list of users and a list of changes and for all the paper behind it) and ask him/her to explain what he/she is doing.

Well, if you want the auditor perspective, try this: http://www.regdeveloper.co.uk/2006/07/10/audit_and_developers/.

But, yes, people should be aware of CobiT etc.

What interests me a little bit is that people who aren't aware of governance appear to get away with it, without their careers being affected.

As I implied earlier, I (personally) believe that all this governance stuff only works within the context of a "mature" organisation - and there aren't all that many of those.

What many people overlook is that a level 0 - chaotic - organisation can still be successful (Microsoft in the 1990s eg). It's a risky success, and it may not last, but it makes it that bit harder for those of us that really do believe in "good governance".

Great article Simon. You just wrote what is now my favorite quote about business rules:

"The biggest problem facing anyone wanting to implement a rules engine isn't finding the right technology - there are plenty of tools on the market - instead it's getting the right rules definitions."

There are a few business rule methodologies and frameworks to help you with rule harvesting (rules discovery, definition, and modeling), and with rules-based system design, development, and management. The Business Rules Knowledge Base has more information on these topics:

http://bizrules.info/index.html

There are also a few niche BR consulting firms (shameless plug) that can help organizations document, manage, and automate business rules:

http://bizrules.info/page/websites.htm

As you mentioned, there are many business rule engines (BRE) on the market. See the BRE Family Tree for a snapshot of the major vendors and products:

http://bizrules.info/page/art_brefamilytree.htm

"...rules capture isn't simple - rules are as often implicit as they are explicit, relying on experience as well as defined processes. t's a problem that's been around since the early days of knowledge management and knowledge-based system design."

It's nice to you see your reference to knowledge management and knowledge-based system design. Few people realize that rule-based systems and knowledge-based systems are related. Many of today's rule-based business rule engines were called knowledge-based expert systems back in the 80s, as you can see here in the Business Rules Hype Cycle:

http://bizrules.info/page/art_BRE_HypeCycle.htm

The proven methods and practices for knowledge acquisition, knowledge representation and knowledge engineering, which were used to design and build knowledge-based systems, can also be used for rule discovery and rule definition, and to design rule-based systems. There are important differences between rule-based systems and knowledge-based systems, which are summarized in this blog:

http://www.bizrules.info/blog/2006/08/what-is-difference-between-data-based.html

Rolando Hernandez

http://blog.bizrules.info/

"Few people realize that rule-based systems and knowledge-based systems are related."

Well, you may be right but I'm a bit surprised. I thought that a lot of people associated rules with AI and knowledge-based systems and the rules vendors were trying hard to play this down (because AI is seen to have "failed" - although that is a gross oversimplification).

I wonder if (advanced) rules engines are to AI etc as birds are to dinosaurs?