Agile To The Bone

In business, agility is everything. Mergers and acquisitions, new regulations and heightened customer expectations mean your company must become more responsive to changing demands. Mega-applications such as enterprise resource planning (ERP) and customer relationship management (CRM) have enhanced efficiency, but they have also created new IT stovepipes that reduce a company's ability to cope with change. You must coordinate, automate and optimize the activities of users and diverse business systems scattered across the enterprise in continually changing business processes. In short, you need business process management (BPM).

But to achieve agility without breaking the bank, you can't simply rip and replace. You must break down legacy stovepipes into modular components that can be reused in multiple business processes. That's precisely the promise of a new style of software development called service-oriented architecture. With SOA, applications are no longer built as monoliths. Instead, they're composed by assembling modular services. Think of a service as a single software function, such as GetAccountBalance or CancelOrder, that can be executed on request by any system, regardless of its operating system platform, programming language or geographic location.

SOA isn't new conceptually, but its current implementation in the form of Web services is revolutionizing software development. While previous generations of distributed software architecture promised agility and component reuse, there was always a catch: To allow integration, all components had to use a common object model or programming language. Web services remove these requirements and interoperate across barriers separating Microsoft from Unix or .Net from J2EE. Just as Web page retrieval works the same on any platform, program-to-program interactions can be platform-independent if Web services leverage universal standards.

The Power of SOA

In SOA, developers build composite applications by interconnecting or orchestrating services in a process flow, which itself can be exposed as a service. What a business analyst sees as an executable business process, IT understands as just another composite application supported by the SOA infrastructure. By making process concepts a natural part of application development, SOA is bringing BPM into the IT mainstream, and in so doing it is shaking up the BPM software landscape.

SOA's ability to compose processes by assembling standard service building blocks is central to BPM's promise of agility. Standard SOA design tools make the task of building a service orchestration model as fast and easy as drawing a flowchart of services. The same tools then turn the model into an executable business process.

The XML language for orchestration, called Business Process Execution Language (BPEL), has itself been standardized. BPEL is endorsed, with varying caveats and qualifications, by BPM vendors and most platform infrastructure vendors and enterprise application integration (EAI) vendors. Thus, SOA also implies portability of process models, executable across infrastructure platforms and maintained using vendor-independent design tools.

Orchestration is obviously agile, but where do the services themselves come from?

One way to create services is to code them from scratch. Today, application servers from infrastructure vendors such as IBM, Microsoft, BEA and Oracle compete largely on the basis of their tools for rapidly creating custom code that can be deployed as reusable Web services. An equally important alternative, however, is to "wrap" existing systems with middleware components called integration adapters, exposing their functionality as Web services without custom code. A third way to create services is to buy them from the enterprise application vendors. New versions of enterprise apps such as SAP and Siebel are being packaged as collections of native Web services, ready for out-of-the-box orchestration. Finally, you can access third-party services over the Web using registries. Or you can combine services implemented in all of these ways in an orchestrated business process. That's the power of SOA.

By attracting mainstream IT infrastructure and enterprise application providers to what was once a specialty niche, SOA is changing the BPM vendor landscape. All these vendors now stress service orchestration as a key part of what they offer, but each emphasizes a different source of the services themselves: Application server vendors want you to code them, integration server vendors want you to wrap them and enterprise application vendors want you to buy them.

Three Questions Behind BPM

While all BPM roads today point to SOA, we're not quite there yet. There are obvious gaps in Web services standards for security, reliable message delivery and transaction management. These deficiencies are diminishing as standards mature and are adopted in commercial software. Less obvious and well understood are three fundamental questions: whether service orchestration by itself is a sufficient basis for BPM, whether legacy integration middleware has a role in an SOA world, and whether monolithic enterprise applications such as ERP can really be replaced by reusable Web services. The answers leading vendors are offering to these questions are shaping how BPM will evolve over the next few years.

The first question — the elephant in the room, as far as most pureplay BPM vendors are concerned — is whether human workflow tasks can or should be described within the service orchestration model. In standard BPEL today, they aren't. BPEL omits process attributes such as roles, task priorities and deadlines, even though they are central to human workflow in languages such as the Workflow Management Coalition's Extensible Process Description Language (XPDL).

For this reason, most workflow and pureplay BPM vendors, including FileNet, Savvion and Fuego, assert that BPEL orchestration should be restricted to automated activities, such as "straight-through" processing and application integration. These vendors typically implement BPEL orchestrations as subprocesses embedded in (XPDL-like) end-to-end workflow models. Their process models have been extended to invoke individual or composite Web services, and the models themselves can be encapsulated as composite Web services. In this hybrid approach, the BPEL subprocesses are portable, but they're only part of the total process.

In contrast, infrastructure vendors such as IBM, BEA, Microsoft and Oracle view the complete, end-to-end process as a BPEL orchestration (or a set of collaborating BPEL processes), and all have developed vendor-specific ways to implement human workflow within the Web service orchestration paradigm. But this approach to human workflow leads to process orchestrations that aren't portable across vendor platforms. To bridge the gap, the Business Process Management Initiative (BPMI.org) is beginning work on a BPEL extension layer (BPXL), with standards-based integration of human workflow as one of the key extensions.

The second question is whether the standard HTTP communications of the Internet are appropriate for orchestration. HTTP is implicit in the oft-hyped "service discovery" paradigm, in which businesses search in a UDDI yellow-pages-like registry to find and bind Web service providers across the firewall. But discovered services don't yet play a significant role in BPM. Today, communications attributes such as reliable delivery, security, transaction recovery and performance scalability are more important than having a firewall-friendly protocol. For this reason, established integration middleware vendors including Tibco, Vitria and IBM offer their own high-performance, reliable message bus backbones as alternatives to HTTP for service orchestration. Implemented as plug-ins to a multivendor standard such as Java Messaging Service (JMS), these transports offer the benefits of proven architecture without the vendor lock-in. Competing with these plug-ins are enterprise service bus (ESB) offerings from new vendors including Sonic, Cape Clear Software and Fiorano. Based on J2EE and Web services standards, ESBs provide a less expensive communications backbone specifically designed for service orchestration, without any taint of proprietary integration architecture.

All of these middleware vendors are leveraging their strengths in messaging infrastructure, essential in automating enterprise-class transactional processes, to offer high-performance BPM suites, rounding out their integration capabilities with features like human workflow and graphical BPEL design tools. Tibco, for example, recently acquired workflow provider Staffware, and it's integrating that software with its own BusinessWorks service orchestration engine.

The third question is whether service orchestration can really match the functional richness of monolithic enterprise applications such as ERP, or conversely, whether enterprise applications can effectively be repackaged as collections of reusable Web services. SAP, the largest enterprise application vendor, thinks the answer to both questions is yes, but it maintains that individual Web service operations are too fine-grained to serve as the building blocks of enterprise business processes. The seemingly simple CancelOrder function, for example, may require sending a customer confirmation, removing the order from the production plan, releasing materials allocated to the order, canceling the invoice and changing the order status in multiple business systems. SAP would call this function an enterprise service, a business-level building block of an end-to-end process, built by orchestrating multiple low-level services.

SAP is now rearchitecting its formerly monolithic applications as enterprise services on its NetWeaver platform and is creating packaged composite applications, called xApps, based on enterprise services. SAP's Enterprise Services Architecture provides the tools to create enterprise services, to orchestrate them in business processes using the SAP Composite Application Framework and then execute those processes on the NetWeaver application server. Leveraging NetWeaver and enterprise services, SAP too now offers BPM solutions. Human workflow is usually implemented as part of an SAP application, such as R/3 or CRM, using SAP Business Workflow. BPEL-based service orchestration, which SAP calls cross-component BPM, is used to integrate enterprise services with SAP and non-SAP applications, including their respective workflow domains, in end-to-end business process solutions.

SOA and BPM: Perfect Together

The latest moves by BPM, integration and application vendors point to the rapid incorporation of SOA into BPM software. And acceptance of BPM is accelerating within IT departments as infrastructure software vendors embrace the approach. (See Listening Post for Web services surveys.) Sources of services are multiplying — whether by coding them, wrapping existing systems, buying them as application software or discovering them on the Web. Similarly, alternatives abound for the communications backbone: Legacy EAI middleware, new ESBs or plain old HTTP all work with Web services orchestration.

BPEL has near-universal acceptance as an orchestration standard even if vendors disagree about how to incorporate human workflow. A final draft of the BPEL standard should surface in the first part of 2005. The draft will reflect progress on related standards, including XML Path Language (XPath) and Web Services Description Language (WSDL). In implementing BPEL, infrastructure vendors will focus on application integration, while the BPM pureplays will emphasize their richer human workflow features.

No matter where you turn for a BPM solution, the influence of SOAs is creating better tools, extending process automation across functional boundaries, promoting reuse of existing systems and reducing vendor lock-in through industry standards. Most important, SOA allows BPM to deliver on its basic promise: agility in the face of continual change.

Bruce Silver is president of Bruce Silver Associates. Write to him at [email protected].