One of the core promises of BPMS is that it lets process owners on the business side model, monitor, and maintain their own process implementations. While chronically backlogged IT is hypersensitive to the charge that they take too long to respond to the changing demands of business, it still resists ceding to the business the power to maintain business process solutions themselves, much less build them from scratch. In fact, for many architects and developers the mere suggestion of business-driven implementation taints the whole BPMS concept. Yet business rule management systems (BRMS), facing similar issues, seem to have achieved a win-win for business-IT collaboration. How they’ve done it provides three valuable lessons for BPMS vendors.
Lesson 1: Make executable design more “business-oriented.”
In BPM, we make a basic distinction between modeling and design. Modeling is done by business, and design – the executable implementation – is the province of IT. Modeling begins with process capture and documentation. More methodology than tools, it starts with getting process participants in a room. How does the current process work? What are exceptions handled? How do you measure success? How could it be improved? Who owns it, i.e. determines when it needs to change?
Then comes analytical modeling, putting all that captured knowledge in a standard notation like BPMN, and adding parameters that allow performance metrics to be projected through simulation analysis. That’s also done by “the business,” but usually only by an analyst trained in the notation and tool.
In BPMS, modeling and executable design have traditionally used separate tools, languages, and graphical notations, oriented respectively to business and IT. A modeling language and its graphical notation, it is widely believed, cannot possibly hold the technical detail required to allow the implementation to be robust, secure, and scalable. Much better to let the model just define “requirements,” and let IT build the implementation in a completely different language and tool. It doesn’t matter that process owners and business analysts can’t understand it. In many ways, that’s even better.
With business rules there is a similar methodology-based knowledge capture and documentation phase up front, but the analytical rule modeling and executable rule design are combined into a single toolset shared by business and IT. In fact, BRMS vendors like ILOG, Fair Isaac, Corticon, and Pegasystems go to great lengths to make executable rule design tools “business-friendly.” They may offer a separate developer-oriented tool or notation as well, but underneath both the friendly and geeky versions create the same thing, an executable ruleset.
Even rule simulation and testing, at a base level at least, is moving over to the business side. IT generally applies a second level of testing, and always manages deployment to production servers, but rule maintenance is offloaded as much as possible to the business. For some reason, with rulesets maintained by non-developers you never hear the hand-wringing complaints from IT that the resulting implementation is bound to be slow, brittle, and generally unsafe. It is simply assumed that in most cases, the BRMS architecture takes care of those worries.
Lesson 2: Actively manage the entire lifecycle.
BRMS vendors understand their tools need to actively manage the entire rule lifecycle, from capture and documentation to analysis, review and approval, executable rule design, test, deployment, and maintenance. Thus they provide an enterprise rule repository with versioning, role-based access, enterprise search, and extensive lifecycle state management. They treat rules like enterprise information assets.
BPMS doesn’t do this. Some BPMS vendors provide an enterprise repository for analytical models. Most also allow connection to an enterprise business services repository managed by some external SOA infrastructure, but executable processes are typically managed at the project, not enterprise, level. In BPMS, an enterprise repository combining process models, executable business services, and entire processes – with lifecycle management and cross-referencing between them all – would do wonders for business-IT alignment.
Lesson 3: Let process owners tweak the logic on the fly!
Perhaps the most obvious way BRMS products differ from BPMS is their ability to parameterize rule logic using templates that can be tweaked by authorized business users at runtime, enabling maintenance on the fly without redeployment. Rule templates specify business rules in terms of template variables that can be changed through a web interface:
If Order.amount is greater than then …
When a process owner changes the value of threshold_amount on the fly, you don’t hear IT worrying that it’s inherently unsafe. It might be a bad business decision, but that’s not IT’s worry anyway.
In BPM, Lombardi TeamWorks offers similar functionality, parameterizing selected process logic using special variables that can be tweaked by process owners at runtime, usually to keep performance metrics on track. But that’s the only BPMS I’m aware of that does this. In contrast, all BRMS products support rule templates and web-based rule management applications that allow template parameter values to be adjusted on the fly.
BRMS enjoys a certain benefit of the doubt that BPMS still does not. It is that the design tool and underlying runtime engine are engineered so that business analysts and process owners can specify executable logic, with a reasonable degree of flexibility, without the risk that they will “break” backend business systems. There will always be cases where getting critical performance scalability or exception-handling capability requires skilled developers. No one is denying that. But those cases should be the exceptions, not the rule. BRMS vendors have focused with success on enlarging the scope of logic that business people can safely maintain themselves. BPMS vendors would be wise to do the same.
