In the past, business process management (BPM) and workflow technologies have been niche solutions, typically sold from a top-down perspective to business users. Mass-market adoption of these types of technologies requires a standard foundation for orchestrating services. While a variety of application server vendors have Java and J2EE components that are capable of orchestrating services, these solutions are simply too low-level for true business process management.

As a result, we’ve seen the rise of both BPM solutions (typically proprietary so far) and new BPM standards such as Business Process Execution Language (BPEL). Standards such as BPEL will eventually be essential for mainstream adoption of BPM—providing organizations with ways to avoid vendor lock-in and ensure skill transferability, and enabling a wider selection of infrastructure choices for maximizing competition for better price and performance.

BPEL provides a rich semantic for BPM implementations, as well as a potential way to empower service-oriented architectures (SOAs). SOAs encourage loose coupling and flexibility, which is great for adaptability. But what’s needed is a way to compose individual services and coordinate their interactions in a productive and efficient fashion. BPEL is portable and interoperable, enabling organizations to integrate assets from a wide variety of applications. It also deploys easily over .NET or J2EE architectures.

As BPM solutions continue to mature, organizations may start looking to prevent the vendor lock-in associated with implementing their business process models in proprietary BPM products. The pressure for reusability will become more important. In fact, many BPM vendors are rolling out BPEL support either this year or next year in their products. Eventually, organizations may be able to essentially “choose” a BPEL engine and then plug in other BPM-related components such as rules engines, legacy integration, etc. Preventing BPM vendor lock-in can potentially lower the total cost of ownership and provide future flexibility as technologies and products mature. However, this is probably a bit into the future. While I expect that we will eventually see performance benchmarking that enables companies to compare the performance of one BPEL engine to another (much as we have with data speed comparisons today), we’re not there yet.

In the meantime, organizations should continue to track the adoption of BPEL and similar standards. But they may also want to explore Collaxa and its BPEL Server 2.0. A privately held company, Collaxa has had over 5,500 downloads of its BPEL Server since it became available from its Web site in early 2003. Now in its second release, the server embodies a comprehensive and scalable implementation of the BPEL standard, providing an alternative to using proprietary BPM engines. A 30-day evaluation is available for free, while commercial licenses start at $20,000. Collaxa runs on all popular J2EE application servers and uses a relational database for persisting the context of in-flight processes. Developers can use a graphical BPEL Designer, implemented as an Eclipse plug-in, to design BPEL processes with one-click deployment to the BPEL Server. For monitoring, Collaxa includes a Web-based BPEL Console that provides visibility, monitoring, and audit trail for deployed processes.