Posted by: Jack Vaughan
business process management, middleware
When driving school instructors go to action films like “Fast and Furious” you can bet their impression differs from that of would-be race drivers in the same audience. “They should fasten their seatbelts,’’ says one. “Vroom-vroom,” says the other. That split often plays out similarly today in business process management.
There, the business side may buy the tools and model the processes, but then leave it to developers in the application integration team to make it all work with enterprise software services.
The business side sees the cool power slides and money in the bank; the development team sees the dangers in impedance mismatch between services and processes. The business side has the vision; the development side cleans up the mess. That is a bridge that must be crossed.
In fact, people have been looking to bridge this divide for many years. Certainly, business process modeling tools have improved enough for business analysts to do more of the modeling work in BPM/SOA situations. But the work – and the hand-off of business process models – must be approached carefully. Developers still usually need to create a useful sandbox for the business model users up front, so that the business modelers don’t end up creating processes that crash and burn when they are implemented on SOA infrastructure.
This comes to mind when considering the recent advent of BPMN 2.0. The BPMN 2.0 notation came into being to improve the ability of business-side modelers to create standard business process descriptions that can in turn be executed via BPEL or other means.
But how easy is BPMN 2.0 modeling, really? Is it ready for business users? The BPMN notation quite resembles a flowchart, so it is no more easy or difficult than a flowchart diagram from the original computing era. (Anybody remember green plastic flowchart template rulers?) Certainly there are people on the business side that can think in terms of flowchart symbols. But they may not be the majority. And their ranks may thin even more if they try to plow through 500-plus pages of BPMN standards documentation.
BPM modeling tools may have improved, but it is fair to say that the business architect and the software architect will still have to continue to collaborate in order to achieve business visions that are successfully executable.
We recently spoke about BPM, BPMN, SOA and BPEL issues with Michael Rowley, CTO, Active Endpoints who was a contributor to BPMN 2.0 and editor of the BPEL4People OASIS standards. There are both effective and ineffective ways to pursue cross-team process/development architecture, he suggested.
“When BPMN 2.0 first came out, some people thought this was going to be well suited to somebody that was familiar with Visio. Then they discovered there is a lot to it. There are a lot of icons to learn, and they are very specific,” he said.
“People were surprised at how detailed BPMN 2.0 came out to be. But it is a natural thing, given its goal to allow you to design anything, any kind of process, and have it be executable,” said Rowley. “That requires a lot of technical detail.”
“You can’t make BPMN simpler without changing the goals of what it is trying to accomplish,” he said.
BPMN, of course deliver benefits. Its support is broad enough that one can envision a growing pool of skilled practitioners. It can precisely describe processes. It is executable. Its notation can be shared by IT and the business side. But the amount of sharing may be better if tempered.
Constant collaboration, in Rowley’s view, is not a necessarily a good thing. “Every time the business side changes something in a drawing they shouldn’t have to go back to the development side,” he said. Nor should the business side be burdened with learning about programming issues such as WSDLs, he said.
“We believe the right way to get the business and IT user to collaborate is to do it less frequently,” he said. This can be done successfully, he said, if the development side pre-configures service activities. These in turn become safe modeling elements that the business side can use to describe their process workflows. – Jack Vaughan