InfoQ Article: When and How to Formalize Business Rules

Posted by Deborah Hartmann Preuss on Sep 04, 2006

Sections

Process & Practices,

Architecture & Design,

Development

Topics

Agile ,

Artifacts & Tools ,

Customers & Requirements

Tags

Complementary Practices ,

Rules Engines ,

Collaborative Technologies ,

Business Architecture

The differences between "Agile software development" and "Business Agility" often cause confusion. Sometimes an organization says it needs business agility as a way of giving itself permission to use Microsoft Excel to solve a problem, to use end-user programming tools or otherwise avoid its IT organization. Sometimes business agility is used as a synonym for adopting a Business Process Management System (BPMS) or using a diagramming notation like BPEL. Sometimes there is an unspoken assumption that adopting SOA will result in agility.

For even the most complex systems, however, agile software development can deliver business agility - this is especially true when the practice combined with the right development technology.

James Taylor has written an article for InfoQ on use of business rules engines to enhance Agile teamwork. But aren't business rules the same as requirements? No, not really, he says, and goes on to show how agile development processes can work just as well for business rules as they do for other kinds of requirements. 

Surely every system has rules... how do know when a rules engine is actually justified? He offers several rules of thumb. Look for:

• Lots of rules - hundreds or thousands
• Rules that change often - monthly, weekly, daily or even hourly
• Rules that are very complex or interact in complex ways
• Rules that require domain knowledge to understand - legal rules and medical rules for instance

For teams whose systems have one or more of these characteristics, it might be worth taking a look at Taylors' approach.

• Older >