The click-and-drag enterprise

By providing common tools for business analysts and software developers, BPM promises to revolutionize application integration. But can it deliver on the promise, or is the dream of truly business-driven development too good to be true?

The intersection between business and IT is where the action is. It’s the point where business requirements morph into enterprise systems. It’s where consultants and software vendors make money. And it’s where most big IT problems begin — or dissolve before they gum up the works.

BPM (business process management) seeks to impose order on the chaotic crossroads between business and technology. A BPM system — software that combines graphical process modeling with application development to exploit an existing EAI fabric — encourages both sides to get their ducks in a row. Business analysts must rationalize and ultimately optimize workflow by parsing and describing the processes underlying business functions, and IT must get its EAI act together so that the existing application functionality necessary to create process-based apps can be stitched together across the enterprise.

“In essence you’re kind of creating a godlike program that’s orchestrating hundreds of systems,” explains David Linthicum, CTO of b-to-b integration provider Grand Central Communications and author of three books on EAI. 

The idea of using BPM to build reconfigurable meta-applications is taking on a life of its own, thanks to the increasing popularity of the SOA (service-oriented architecture) paradigm, which advocates exposing discrete bits of important application functionality as services.

“BPM is the brains of your SOA,” says Michael Howell, vice president of architecture and policy at Broadlane, a b-to-b health-care services provider currently in the process of launching a BPM system based on BEA Systems’ WebLogic Integration. “It just makes sense for me to have an independent entity there controlling business processes and business services.”

Many software vendors agree with Howell. EAI vendors such as SeeBeyond, Tibco, Vitria, and webMethods offer BPM products to cap their integration offerings. Monster platform vendors BEA, IBM, Microsoft, and Sun Microsystems offer stacks that feature both BPM and integration systems. And a clutch of pure-plays, including Intalio, Lombardi, Savvion, and Ultimus, are promoting their systems’ capability of crossing any platform and providing an intelligent BPM superstructure for the enterprise. Even the big enterprise application vendors say they’re getting into the act, although BPM-infused versions of major applications from Oracle, PeopleSoft, SAP, and Siebel Systems have yet to arrive.

Predictably, vendors trot out dramatic results from well-implemented BPM systems. In one high-profile example, Covad Communications was able to reduce its support staff head count from 1,000 to 250 by streamlining workflow with Intalio’s BPM system. But the effort involved depends largely on the degree and quality of application integration. In addition, how much of a head start developers can gain from the output of a graphical process design tool varies widely among BPM products. First and foremost, however, successful implementations demand that senior IT and business personnel make the effort to understand what BPM is all about.

Top-down vs. bottom-up

Getting over that conceptual hump may be the hardest part. “It’s a classic thing where you ask five customers [what BPM means] and you get seven answers,” says Steven Martin, group product manager at Microsoft’s business process and integration division, which helped develop the BPM-enabled version of BizTalk Server 2004 that shipped in March.

Perspectives of BPM differ depending on whether you look at it from the IT side or from the business side. IT tends to view BPM from a “bottom-up” perspective — that is, from the data integration layer on up to the top BPM layer, where businesspeople describe processes that map to that infrastructure. Business folk get the penthouse view, as they construct workflows on the BPM layer and help IT determine how everything gets implemented under the hood.

The general consensus is that the business-driven approach works best.

“A business process needs to be completely defined independently from IT,” says Matt Quinn, director of technology marketing at Tibco, which acquired BPM pure-play Staffware last month. “It needs to be a business-focused view of what a business process constitutes. Of course, you can’t simply drive everything top-down — you do need to actually capture business processes at a technology level as well. But if you understand the business process from end to end, without having the constraint of IT initially, you’ve got a much broader context for really understanding what your business is.”

The new imperative that IT must play a strategic role in achieving business objectives supports Quinn’s assertion. So does history. Not too long ago, BPM meant “business process modeling,” which, according to Ismael Ghalimi, chief strategy officer of Intalio, fizzled in the late ’90s because it demanded that business analysts learn principles of software engineering. By contrast, today’s BPM gives business analysts easy tools to map workflows, perform business simulations, rough out GUIs, and so on, yielding value for the business side even if a planned application never actually sees the light of day.

“We believe the business process should start with the subject matter experts,” says Scott Cosby, director of WebSphere Business Integration product management at IBM. But Cosby also thinks the business side should start by modeling and measuring existing processes before planning new ones.

According to Cosby, a company could, for example, gather metrics from an existing inventory system using IBM’s WebSphere Business Integration Monitor, which is based on the Holosofx product IBM purchased in 2002. Armed with that information, the company could then use the WebSphere Business Integration Modeler to re-create inventory system processes and run simulations to discover where to make improvements. This real-time information gathering is known as BAM (business activity monitoring), and depending on whom you talk to, it’s either integral or peripheral to BPM.

“We made a decision two years ago that BPM couldn’t exist without BAM because we found that nobody automates a process for any reason other than to improve it,” says Rod Favaron, CEO of Lombardi Software. “So we spent a lot of engineering time over the last 18 months building an integrated BAM capability. That’s what we’re known for, the really rapid ability to build the process, bring it live, get people using it, measure its effectiveness, and then change it.”

“We made a decision two years ago that BPM couldn’t exist without BAM because we found that nobody automates a process for any reason other than to improve it,” says Rod Favaron, CEO of Lombardi Software. “So we spent a lot of engineering time over the last 18 months building an integrated BAM capability. That’s what we’re known for, the really rapid ability to build the process, bring it live, get people using it, measure its effectiveness, and then change it.”

That’s fine for some, says Neal Novotny, director of product marketing at Intalio. But Intalio is of the “old school,” which holds that BPM is the process and execution engine that helps manage already defined processes and that BAM should take place after the fact.

Seeing the process for the trees

The classic procedure for creating process models begins with some soul-searching on the business side.

“The first challenge of business process management is just discovering which processes exist in a company, within a system, within the combination of workers and systems, and externally to the company,” Novotny says.

For those with particularly complex process challenges, specialists such as IDS Scheer can provide software and consulting to help with the hardcore analysis. So how does the business side choose which processes to target first?

“There is a class of processes out there in the operation of the business that is really dynamic,” Lombardi’s Favaron says. “They’re stressed all the time, and they need to change — because organizations change, or product mixes change, or workflow changes, or partners change, or the rules about the business change. So we set out to build a set of products integrated together that would allow a cross-functional team of IT and business folks to work together and automate dynamic and highly changing processes.”

For example, Broadlane’s Howell — an Intalio customer — realized his company’s contract management system needed greater flexibility. So rather than “rip out the guts out of it,” Howell says he has marshaled existing business objects around it.

“For the things we wanted to do around [contract] approval, … we could’ve put them in the application and rewrote it, but looking at it as a business process, those were the things that changed so often we decided not to touch the application,” Howell says.

Instead, the additional logic necessary to provide added flexibility is maintained within the BPM system, where it can be changed easily.

From pretty pictures to meta-apps

After business analysts isolate the sweet spots for BPM, they use a BPM system’s Visio-like tool to model processes and fit them together. When modeling processes specific to a vertical industry, vendor-provided templates often prove to be a good starting point. When this business design stage is complete, the model reaches the hands of developers, who map business processes to a development environment that takes into account the details of EAI.

That handoff is key. Most vendors offer two modelers: one for business analysts and one for IT that actually describes the details of how the application will be created and integrated. Lombardi claims to be the only vendor that provides a single, unified environment for business and IT. But the fact remains that business analysts create models governed by business rules, whereas IT must create and maintain a parallel model governed by the capabilities of existing software and where low-level messages can go.

The notion that business analysts can actually build working apps using a BPM modeler without the aid of developers is a common misconception. After all, as Chet Kapoor, vice president and general manager of BEA’s WebLogic Integration group, says, “The ultimate vision of software has always been to draw pictures and hit run.”

We may still be light-years from that reality, but today’s BPM modelers for the business side typically produce some code that can be quite useful in the IT development phase.

That code sometimes takes the form of UML (Unified Modeling Language), which has been used since the mid-’90s to describe the behavior of object-oriented software systems. But today, the buzz is over BPEL (Business Process Execution Language), a standard for orchestrating the way Web services interact. Most BPM modelers generate BPEL code, and all major software vendors have endorsed the standard, even though the BPEL spec is immature and BPM systems must use other means to fully orchestrate processes (see A developer's perspective on BPEL).

Business processes to go?

“The power of BPEL is not that it’s a robust orchestration language but that it’s portable,” Grand Central’s Linthicum says. In other words, just as the J2EE specification provides marginal portability for Java components, BPEL will eventually open the possibility of transporting business processes from one BPM platform to another. Customers want that kind of investment protection, Linthicum says, even though it’s a long way off.

“You’re selling a concept without reality. It’s the same way we sold Java and C++ in the early days,” Linthicum says. But with the enormous momentum behind the standard, Linthicum gives it an 80 percent chance of success.

“We like BPEL from the point of view that it does provide us with some very nice constructs for orchestrating Web services,” Tibco’s Quinn says. “And at some point, when more vendors start to support it, portability will become a little bit easier at a high level. But when I look at the problem of business process automation and integration in general, BPEL addresses maybe 3 percent of the total effort.”

The rest, Quinn says, lies in making application functionality available as Web services — because BPEL can orchestrate processes composed of Web services alone — and in filling in orchestration functionality that the BPEL 1.0  (and draft 1.1) specification lacks.

The generally accepted estimate is that it will take approximately 18 months before BPEL matures into a robust orchestration language. Meanwhile, enterprises will have time to build out their SOAs, making the whole BPEL proposition more viable.

In the interim, BPM vendors tend to use other means to describe the interaction of processes at a technical level. Intalio, for example, employs BPML (Business Process Modeling Language), a much more robust specification that predates BPEL, but one not designed to orchestrate Web services.

The other up-and-coming BPM standard — although it lacks the traction of BPEL — is BPMN (Business Process Modeling Notation), which seeks to standardize the way BPM modelers graphically depict processes.

“We think BPMN is interesting,” Lombardi’s Favaron says. “The idea is that it would be portable and consumable and integrated into everybody’s modeling environment. There’s really no good way to take a high-level business modeler and translate that into the actual working process today.”

Ultimately, Tibco’s Quinn and others doubt whether process portability will be truly practical, given that vendors always differentiate by adding proprietary functionality.

But portability is a secondary benefit. The promise of BPM for IT is in providing the missing organizing principle for SOAs, enabling ultrafast application development and change management with minimal new coding. For the business side, the payoff is a new ability to conceptualize, deploy, measure, and reconfigure business processes quickly, without getting lost in the no-man’s-land between business and IT.

Copyright © 2004 IDG Communications, Inc.