When I get dropped into a large codebase I like to use a software metrics tool to take a macro look at the organization of the code. Over many years the Object-oriented programming community and others have come up with a suite of metrics that can be computed for most programming languages. Architects and developers can use these metrics to detect bad “code smells”, find code that would benefit from refactoring, or perform an impact analysis before a major refactoring gets underway. Many of these are well described in Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin.

There has been relatively little research into defining metrics for rule-based systems. Here are the only two papers I could dig up - perhaps you know of others?

• Coupling and cohesion metrics for knowledge-based systems using frames and rules
• Applying metrics to rule-based systems

The traditional software metrics I find most useful are those that deal with code responsibility and dependencies (afferent and efferent coupling). These metrics are very useful when trying to understand the potential scope of a refactoring for example. Determining code dependencies is relatively straightforward, because a Java method that invokes 10 methods has a dependency on those methods. Things are trickier in the rules world because a rule may have 10 rules that must fire to set up its conditions (preconditions) and then 5 downstream rules that will fire once its actions are triggered (postconditions). Through Static Rule Analysis we may be able to detect some of these dependencies however.

Rules also have dependencies on the Business Object Model, parameters, variables and the Vocabulary, and these are much easier to determine as they are explicit in each rule.

Below are some ideas for metrics that might be useful for rule-based systems.

Afferent Coupling (Responsibility) : Ca

• The number of rules that will fire when a rule’s actions are executed
• The number of rules that reference a VOC phrase
• The number of rules that reference a BOM member

Efferent Coupling (Independence) : Ce

• The number of rules that are required to fire for a rule’s conditions to be true
• The number of BOM/VOC references per rule

Instability

Instability is defined as the ratio of efferent and afferent coupling. Of course it is easy to create a rule with an instability index of zero — just ensure the rule can never be fired! Instability is therefore a tradeoff between responsibility and independence.

I = Ce / (Ce + Ca)

Large or Complex Rules

The presence of many large or complex rules may indicate a “rule smell”. A few ideas:

• Rules that reference many VOC elements
• Rules that require many bindings
• Number of characters
• Number of conditions
• Number of actions
• Number of variable or parameter references

Packages, Ruleflows and Rule Projects

Zooming out from the individual rules themselves, many of these metrics can also be applied to packages (an average measure for the rules within a package), ruleflows (because they also have pre and postconditions) and Rule Projects (average measures as well as reporting dependencies).

Conclusions

I’ve outlined a few ideas for rule metrics, but what do you think? Is this approach applicable to rule-based systems? Do you have any techniques you use to detect bad “rule smells”?

Today I thought I’d take the opportunity to publicize a Java Developer position I need to fill in my team. The job is based in beautiful Paris and we are looking for a real Java expert to work on our Eclipse-based Rule Studio for Java product. The French job description is available online, and loosely translates as:

The ILOG R&D department is looking for a Java Software Engineer to work on Rule Studio for Java. As a member of the RS4J team you will be responsible for ongoing maintenance and development of a major Eclipse-based Java product. The job is based in Paris, France.

Candidate Profile

• Computer science degree (or equivalent experience)
• 4+ years Java development experience
• Experience of full-lifecycle product development using an agile methodology desired
• Knowledge of XML and XML Schema a plus
• Good English language skills, with fluent spoken French a plus

If this sounds like your cup of tea, please submit your resume/CV through the ILOG website.

Worldwide, ILOG has over 50 positions to fill across 8 countries:

• Australia
• China
• France
• Germany
• Great Britain
• Japan
• Singapore
• United States

The jobs vary from SAP Integration Specialist to an intern for supply chain planning applications, to a Shanghai-based Marketing Executive, and everything in between. Come help us change the rules of business!

Mark Proctor and Kris Verlaenen have posted an interesting description of JBoss’s vision for unifying rules and processes. I have to say that on this debate I think I broadly side with James Taylor, who has also posted a response.

In my opinion this debate involves runtime and design-time considerations.

Runtime

At runtime we are presented with two execution models: a graph execution model for processes, and the pattern-matching model for rules. BPM tools traditionally excel (or struggle, depending on your experience!) to offer state management, allowing long-running processes to be safely persisted and “rehydrated” based on some system event. Most rule-based products offer relatively little in the way of long-lived state and transaction management, concentrating instead on the automation of “point in time” decisions. It is relatively easy to expose a set-of-rules (in the loosest sense) as a procedural function (web service, Java method, asynchronous message driven bean etc.) and invoke the “function” from a higher-level orchestration (Java program or BPM process for example). Loose coupling may, or may not, be preserved, depending on how much model sharing the architect would like between the orchestration and the decision service.

If you move beyond functional invocation then you must rely on a shared data context between the orchestration and the rules, such as the rule-engine working memory for example. The coupling naturally becomes tight as your orchestration no longer has a clear interface for decisions but rather throws events into a shared context and side-effects happen. This pattern can be very powerful for certain scenarios, however it is much more sophisticated than the usually idempotent stateless invocation of a decision service. Transactions, clustering, high-availability and replication, scalability and memory usage tend to rear their ugly heads sooner rather than later!

Design Time

On the design-time side of the debate I’d say that things are more complex and nuanced. The primary user of a BPM tool is a human being. A complex business process is being moved through a life-cycle, however that life-cycle typically involves human tasks for approval, review, task assignment or implementation. Business processes therefore tend to evolve rather slowly (months), because human beings have a finite ability to adapt to changing processes. This is in contrast to an automated decision service implemented using rules (eligibility or credit scoring for example). Changes to the scoring algorithm could happen hourly, without causing organizational problems. However, changes to the order fulfillment process are likely to be much more gradual, as it is impossible to retrain staff and suppliers, maintaining job-satisfaction and quality, in the face of business processes undergoing constant change.

So, although there may be value to maintaining referential links between processes and groups of rules (for reporting or drill-down for example), the two entities do not typically serve the same ends, or share the same change-cycle. Therefore the standard pattern is for the coupling between the two to be quite loose, with a formal functional interface defined for automated decisions. This allows the rules to evolve independent of the orchestration, with zero impact as long as the functional interface does not change. It is also very nice to be able to test an automated decision outside of the context of its orchestration, as a standalone (functional) entity.

The Engineer’s View

This is not to deny that there are technologies and challenges that BPM and rules share in common (expression language, IDE concepts, management and monitoring requirements etc), and I suspect that this is primarily what Mark was alluding to in his post - particularly when he says the JBoss BPM and rules teams may merge. However in my opinion this is primarily for the convenience of the product vendor, rather than a direct benefit to the customer. I think the post from Tom Baeyens bears this out. For example, while I was working at BEA Systems we used the core Rule Engine expression language to define Portal security and access control policies, although I suspect few customers knew this.

Process Virtual Machine

As a side-note, I have to admit I have a rather soft spot for Tom Baeyens’ Process Virtual Machine concept. It reminds me of the Virtual Rule Engine Specification I proposed 3 years ago. Clearly the BPM space is faced with some of the same challenges as the rules space in terms of language standardization. However, the goals of the VRES and PVM concepts both appear to be to standardize execution semantics in the face of a fragmented marketplace.

Conclusions

Perhaps one day we will have the unified “business management system” that combines data, rules and processes, with business people defining and managing processes, services, rules and seamlessly moving between them. However based on the current adoption of RDBMS, BPM, BRMS, BI and the rather basic change management and modeling practices in many organizations I fear that day is still rather a long way off. One thing we also hear loud and clear from our business users is that they don’t want to become “traditional” programmers. Within the ILOG BRMS products we strive to “do one thing well” — provide a BRMS that is both powerful and flexible enough to integrate into a wide variety of design and runtime contexts, using out of the box functionality augmented by a rich set of APIs.

Our good friends at Software AG have kindly put a video of my SOA Governance Summit presentation online: Service Registries Are Not Sufficient! Aligning Business and IT Goals using a Business Rule Management System and CentraSite.

For the past week my team has been in the “cool down” phase of a release. The “cool down” analogy comes from physical exercise, but it is equally applicable to the mental strain of getting a product ready for delivery to production. The last couple of months of a product release are invariably very busy as we process the bugs found by our Quality Assurance team and Beta testers. Working on these very detailed bug fixes or micro-features is very mentally demanding, so once the code is stabilized we have a one week period during which team members can work on anything of interest. It’s a very stimulating and productive time, as developers get to zoom out and see the big picture again, and explore synergies with technologies outside business rules.

Most of the developers take the chance to dive into a new technology, such as learning some Ruby or the Google Web Toolkit for example. On my team we’ve been looking at EHCache for performance optimizations, studying some of the scalability patterns in the Eclipse JDT and building a batch-processing prototype using Apache Hadoop.

Of course, after the “cool down” comes the “warm-up” for the next release — which for us is planning user stories and working on high-level architecture and specifications. These occur during our inception/elaboration iterations before we get into the main construction phase of a release.

Do you have an equivalent to ILOG’s “cool down” period? How do you balance individual professional development or technical research with ongoing product development?

One of the fascinating things about ILOG is that you bump into engineers in the hallways with very deep knowledge of specific domains: from the mathematical programming geniuses that work on the CPLEX optimization products, to engineers that have spent 10+ years researching graphical layout algorithms for large-scale visualization, or that have deep expertise in building natural language parsers. One such group, working on the JRules product, are our static analysis experts. This team’s mission is to take a set of rules and automatically detect potential logic errors or warn of suspicious usage of rules.

Customers use static rule analysis to help ensure the logical integrity of a set of rules, while the rules are undergoing daily edits by a team of Policy Managers. Static rule analysis provides a safety-net, allowing the policy managers to make changes with confidence. It also tends to promote good usage of rules, as it can help prevent common anti-patterns, such as heavily order-dependent rules, or rules that subsume other rules.

The Semantic Query technology is built on top of the results of semantic rule analysis. This is a technology that I find fascinating and is state-of-the-art. Semantic queries allow a customer to use a simple query language to ask interesting semantic questions of a Rule Project, such as “Which rules apply to customers aged 35 or less?”.

Using some simple (contrived) examples I will show the sophistication of the static rule analysis technology shipped in JRules. If you’d like to experiment with these rules you can download the JRules trial, and the Rule Project I created while writing this post.

Rule Project used to demonstrate Static Rule Analysis

Types of Checks

JRules static analysis supports the following checks:

1. Rule never applies
2. Rule may cause domain violation
3. Rule is self-conflicting
4. Rule makes other rule redundant
5. Rules are conflicting
6. Rules have equivalent conditions
7. Rules are equivalent

There are two types of checks, those that operate on a single rule independent of other rules (checks 1-3) and those that operate on a set of rules (checks 4-7). The single-rule checks are applied automatically while editing rules in Rule Studio, whereas the more computationally costly inter-rule checks are accessible through an HTML report in both Rule Studio and Rule Team Server. Details of these checks are available in the JRules documentation. Unlike other vendors, we choose to implement these checks using a deep semantic analysis of the rules, and do not rely on shallow and error-prone syntactic or textual analysis.

I will describe some of the more interesting checks below.

Rule Never Applies

Writing a rule whose conditions are logically false is always a bad idea! Such a rule will never be fired by the rule engine and is merely cluttering the Rule Project. Usually rules that never apply are created by copy/paste errors or other typographical errors. In the example above, the sloppy rule author (me!) probably meant “any of the following conditions…”!

The second rule is never applicable because Customer.age has been specified as a positive integer using a domain (see below).

Rule May Cause Domain Violation

Any attribute in the Business Object Model (the model you write rules against) can have a domain associated with it. A domain can be an enumeration or a valid numeric range for example. In the sample Rule Project I have specified that the Customer.age attribute has a valid range from [0,150] (from 0 to 150 inclusive) and the Customer.salary attribute has a range from [0,1000000]. The domain for Result.score is [0,100]. JRules therefore warns me that assigning Customer.salary to Result.score may result in “unsafe execution”. Not only can JRules detect these cases, but it can also explain when and why they occur:

The rule below shows the deep domain analysis that is occurring — even though Customer.age is assigned to Result.score (and the domain for Customer.age is larger than that of Result.score) no domain violation is reported due to the conditional check for “age < 30" in the rule:

Rule Makes Other Rule Redundant

The first rule makes the second rule redundant. However more complex cases are also possible. As you can see in the examples below, these would be difficult to detect using a simple search or naive syntactic analysis.

Rules are Conflicting

Conflicting rules are defined as two rules whose actions set different values to the same BOM attribute/member. They are very hard to detect manually, especially once you have hundreds of rules.

The natural-language explanation facility is extremely useful in these cases, as they can be tricky to understand by just looking at the rules. For example:

Even people with a programming background find Boolean algebra tricky, and it can take a while to find these cases manually! How about this conflict for example?

Rules are Equivalent

The Rules are Equivalent check detects rules that are exactly logically equivalent — almost always an error. For example, the two rules below are logically equivalent:

Example Semantic Queries

Whereas “checks” are a safety-net and reactive in nature, Semantic Queries allow you to become pro-active in how you manage and evolve your Rule Project. For example, for audit purposes it may be very interesting to determine the list of rules that may fire on customers that live in California, or the list of rules that can cause a Customer’s credit score to be less than 200. Using Semantic Queries the policy manager can perform regular impact analysis to understand the relationships between rules, and the data that cause rules to fire.

May Apply When

The “May Apply When” style query retrieves all the rules that are not prevented from firing for a specific semantic condition (in this case, when “Customer.salary > 20000″). I.e. in this case many rules are returned, even rules that do not check the customer salary because they may fire.

May Become Applicable

In contrast to, “May Apply When”, “May Become Applicable” only returns the rules that will fire for a specified semantic condition, and that tests one of the supplied attributes. In this case a single “Wealthy” rule is returned as this is the only rule that specifically tests the Customer.salary attribute:

May Lead to a State

“May Lead to a State” queries are used to retrieve the rules based on their modifications to attributes - including the values that may have been assigned. In the example above we query for the rules that may be responsible for assigning a customer a score between 50 and 80.