Service-oriented architecture lets you respond quickly to demands for new and improved processes

InformationWeek Staff, Contributor

January 20, 2005

12 Min Read

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

Executive Summary

Struggling to overcome process inefficiency caused by "stovepiped" applications and the expensive integration problems they present, organizations are beginning to apply service-oriented architecture (SOA) standards and technology. SOA exploits networks and the Internet to deliver application functionality through loosely coupled, shared services. With SOA, application integration happens at a much higher level of abstraction, enabling service providers to shield underlying complexity from applications or users that deploy the services.

SOA is gaining momentum in part based on acceptance of open standards, including eXtensible Markup Language (XML). SOA promises more modular software development and easier integration of legacy systems, which would be accessed and integrated as services. Modular software development offers greater reuse of application components-a long-held dream of many in the software community and a key goal for IT departments trying to bring down application management costs. Reusing services means organizations may not have to discontinue legacy systems, rewrite software or buy new packaged applications.

For all these reasons, SOA could be a catalyst for business process management (BPM). Building on XML and related standards is the OASIS Business Process Execution Language (BPEL), which defines how to assemble and orchestrate services into a process flow, including one that can support transactions. However, questions remain about whether standards can truly support service orchestration, whether that orchestration can fully express the richness of enterprise applications, and whether it makes business or IT sense to expose such applications as Web services.

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.

MATURITY METRICS: SOA Support for Business Process Management

Technology
Few organizations have implemented the full capabilities of BPM tools because the enterprise application integration required has been difficult, expensive and proprietary. With SOA, BPM can take advantage of open integration standards, in particular BPEL. Application server and integration middleware vendors compete to support and implement the standards.

Demand
Demand for BPM comes from a range of applications where automation and end-to-end integration promise greater efficiency and business agility. Supply chain management, order fulfillment, customer self-service and regulatory compliance are typical uses. Organizations are discovering that SOA widens the range to include new business opportunities with Web services, which BPM platforms could link together to produce component applications.

Market
SOA is a major software infrastructure focus. Thus, the market includes nearly all the application server and integration vendors, including BEA, Computer Associates, IBM, Microsoft, Oracle, SAP, Sonic, Tibco and WebMethods. Specialized BPM vendors, such as FileNet, Fuego, Intalio, Lombardi, Savvion and Vitria, are rapidly incorporating SOA. Model-driven development tools are also important to driving SOA implementation of BPM.

Final Analysis
"SOA" became a buzzword in 2003 as the initial excitement about Web services began to fade for lack of substance. SOA development methods and integration standards have a long history; however, the current wave of technology is young. SOA support for BPM is still evolving and is somewhat dependent on new approaches to application and business integration middleware. Proven applications are beginning to show the way toward competitive advantage.

Analysis focuses on SOA's supporting role in BPM initiatives rather than development tools and middleware.

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

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights