It was another working lunch today. I sat in on James’ “lunch and learn” session to hear him sharing feedback from the event and discussing best practices with about a dozen or so customers and ILOGers. Below are a few snippets from the informal discussion.

James was blogging the BRMS track throughout the conference and you can find more insights and commentary in his Live from DIALOG series over on his blog.

James used to work for Fair Isaac until about 6 months ago when he left to set up his own company, Smart (Enough) Systems LLC, which provides research, advisory services and implementation support for the enterprise decision management marketplace. James has been working with business rules and other decision management technologies for many years, and is both a well-known proponent of the approach and a passionate advocate of business rules.

Several customers at the table were looking to make rules more accessible to their business users. Many are still at the stage where developers manage the rules, but there is clear drive towards removing this bottleneck. This certainly fits with ILOG’s BRMS product strategy and these customers came to DIALOG to hear how other users were tackling this problem, and to discover best practices regarding rule governance, change management, and the rule development lifecycle.

James’ main piece of advice regarding rule governance was to avoid having a centralized rule governance team for all your enterprise rule projects. That would just create another bottleneck. Each project team should have its own governance processes built in. The role of the central governance team should be to simply ensure that projects are doing governance correctly.

He explained that when implementing a rule-based system for the first time, you shouldn’t expect to get everything right the first time. If changes are required once an application is in production, the business users should drive this change when they are ready for it, not IT.

He added that it is a far better approach to get good at managing change incrementally. You don’t have to roll out new systems to everyone simultaneously. Better to do so gradually, based on business need rather than IT schedules.

Other issues that had brought participants to DIALOG included enterprise architecture, best practices, performance, and migration to the new version of JRules.

Q: Many implementations don’t seem to be realizing the key benefits of the BR approach (business agility, turnaround, transparency, auditability, etc.) These systems are being implemented without active participation of the business stakeholders. Why is this?

A: There are several possible scenarios here. IT might be implementing a business rules approach as an internal project to optimize their own processes, and therefore the active participation of business users might not be appropriate. However, business rule vendors need to work harder to make things more accessible to business users.

R&D folk love to include cool and powerful features that add unnecessary complexity into their solutions, such as the ability to use the programming construct “++” for incremental additions. If you’re a programmer, that’s great, you save yourself some keystrokes and the system runs a millisecond faster. However, your average business user just won’t get it!

Part of any rule governance exercise is to determine who really cares about the project and to get them involved. Just because you use BAL [Business Action Language - ILOG’s “natural language-like” syntax for writing business rules] doesn’t mean it will be legible. You need to work together with business users on the object model and “verbalization” so that the vocabulary and language constructs you use to write your rules actually means something to the business users, and maps to their business user mindset.

If business users weren’t involved in the beginning, that’s going to be harder. It will also be harder to hand over the project to them later (IT have difficulty letting go and business users are not implicated/engaged in the project). It’s possible to refactor to correct early mistakes, but that might require a lot of additional work.

Q: What are the bottlenecks and pitfalls of moving rules towards an enterprise rule repository?

A: Managing all rules as a corporate asset might actually not be the best approach. You should only concentrate at the corporate level on those key rules that actually drive the business. When rules are reused throughout the organization, the impetus for change must come from the business side, not the IT side. For example, on Jan 1st there may be regulatory or price changes that requires the system to be updated. This is a business driver and may be completed unrelated to ongoing IT revision cycles.

Avoid implementing a project-driven, and technology driven repository structure. It should be business-driven. Rule governance is potentially the biggest bottleneck in any BRMS. Avoid having a centralized governance group. Make sure governance is built into individual projects. If you are sharing rules across different projects, it is better to do so at the ruleset level, not the individual rule level, as that makes things much easier to manage and leeps things modular.

The experience gained in refactoring database systems could be useful here. Several books are available on that topic.

You should definitely plan to refactor because the first implementation of any system rarely reflects the optimum solution. Don’t be afraid of that.

One approach when starting out is to set up your rules application to initially flag major decisions for manual validation, then gradually automate them. This was something that was discussed in the BRMS workshop on Sunday.

With a well-implemented modular business rule architecture comes agility. Agility is the ability to make changes to your systems every day, not be tied into the 3, 6, or 9 month IT project cycle.

If you didn’t make it to James’ lunch and learn session (or even if you did), feel free to post additional comments or questions for James here, or directly over on his Smart (Enough) Systems blog.