Paul Harmon of BPTrends weighs in on a worthy topic, how many perspectives do we need to describe a business process? He acknowledges that while “alternative approaches” like Role Activity Diagrams or the Flores-Winograd interaction model used by Action Technologies are useful in special cases, most of the time it would be better to standardize on a more conventional workflow perspective such as BPMN or UML Activity Diagrams. Sandy Kemsley expresses her agreement, while Derek Miers (in comments on BPMS Watch) has expressed the opposite view.
I come down strongly on the side of Paul and Sandy, and in fact go farther to say it should be BPMN not UML Activity Diagrams, and in fact it should be an improved BPMN that resolves the inherent conflicts between an anything-goes drawing notation and a “modeling language” with precise execution (and analytical) semantics.
I hope Paul doesn’t mind that I’m using a diagram from his article to illustrate the problem.
Here is an example of what he calls a “high-level BPMN diagram of a supply chain.” Well, it’s certainly a diagram with rectangles and arrows, I’ll grant that, but is it really BPMN? In BPMN, arrows like that are called Sequence Flows and they mean that the activity (which could be a subprocess) at the arrow head starts when the activity at the arrow tail ends. You don’t have to be a supply chain expert (and I’m not) to know that’s not how it works. Source, Make, Deliver, and Return are all in fact running concurrently, although there is communication between them. And BPMN can describe that concurrency (get rid of the sequence flows), and even describe the communication (”choreography”) between them (put each subprocess in a “pool” and interconnect them with message flows).
If BPMN is going to win in the standards game, it has to become more of a design language and less of a cocktail napkin.
July 18th, 2006
InfoWorld just came out with a head-to-head eval of the two leading BRMS offerings, ILOG JRules and FairIsaac Blaze Advisor. To sum it up, Blaze slightly outpointed ILOG overall, with better benchmark performance and documentation, while ILOG rated higher in rule management and developer tools. The new version of Blaze is speedier than the old largely through the implementation of a new RETE algorithm resulting from FairIsaac’s acquisition of RulesPower last year.
Motivated by Gartner’s insistence that a BPMS must “include” business rule management as a ticket to entry to the magic quadrant, BPMS vendors over the past couple years have either partnered with ILOG, FairIsaac, or lesser known vendor, or scrambled to build their own business rule engine and design tool. What I learned yesterday, however, when I met with Alain Gendre, ILOG’s marketing manager for BPM and SOA, is that while these formal vendor partnerships help a bit in integrating the BPMS and BRMS design environments (and of course from a selling angle), SOA is making them much less important. When a ruleset is deployed as a rule service, it can be invoked by any BPMS or indeed by any non-BPM application as well. In other words, just because your BPMS vendor has a partner agreement with BRMS vendor X, there is no reason why you couldn’t use BRMS vendor Y instead… as long as it supports rule deployment as a web service.
In Gendre’s view, rule services belong at the SOA layer, along with other business services, not - as some analysts have described it - at some higher level application or process logic layer. Business rules represent enterprise policies, shared across applications and across business processes, exactly like other business services in SOA. This makes a lot of sense to me.
Gendre believes that ILOG has a leg up on Blaze in this regard, since (he says) it integrates better with common web service infrastructure on both J2EE and .Net. I can’t judge that, but it certainly wasn’t one of InfoWorld’s evaluation criteria. Maybe it should have been.
July 18th, 2006
[Here is my latest BPMS Watch column going up today on BPM Institute]
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 %threshold_amount% 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.
July 18th, 2006
