BPM and SOA: How They Drive Business

Business process management (BPM) is a paradigm that allows enterprises to model, automate, execute, control, measure and optimize the flow of business activities. This happens across the enterprise’s integrated systems, employees, customers and partners, and both within and beyond corporate boundaries. Service-oriented architecture (SOA), on the other hand, is an architectural approach for constructing software-intensive systems from a set of universally interconnected and interdependent services.

BPM and SOA are separate paradigms – SOA is an architecture approach whereas BPM is about modeling, implementing and monitoring business processes. However, the two are closely aligned because one of the many possible ways to implement business process is through SOA design. Here we'll take a look at how BPM and SOA can work together and what benefits each offers when used separately. (For background reading, see Enterprise Computing: What's All the Buzz?)

The Umbrella Governing BPM and SOA

Enterprise architecture is the organizing logic for an organization's business processes and IT infrastructure. It is also the umbrella that governs both these paradigms. Service-oriented architecture is an architectural style for realizing or creating an enterprise architecture just like client-server, n-tier, mainframes, etc. The primary goal of service-oriented architecture is to align the business with information technology in a way that makes both more effective.

SOA and BPM can exist on their own, but the combination is what makes enterprise architecture complete. BPM fits into the SOA jigsaw as one of the key components providing the business process dimension. Service orientation enables applications to invoke each other’s behavior as services, which is a repeatable task within a business process. Business processes within enterprises are realized by stringing together services offered as part of the SOA stack.

The figure below is an SOA reference architecture that pinpoints where BPM fits into the SOA stack. As you can see, BPM sits right on top of the solid foundation provided by SOA and inherits significant integration capabilities from it.

Figure 1: SOA Reference Architecture

Note: Layers of the reference architecture above from bottom to top are: database layer, application layer, component layer, integration layer, business process layer, presentation layer, channel layer.

Approaches and Tools That Support BPM and SOA

There are various approaches to realizing BPM and SOA:

• Traditional Application Development
  One option is to develop a completely new application in-house. Most companies have the capability to do this, so it isn’t uncommon for these companies to evaluate whether they can use their traditional application development instead of using business process management software (BPMS). The decision-making parameters center around whether skill sets exist internally to meet requirements and time to market.
• Extending an Existing Application
  Most organizations are already using applications in their business processes. Obviously, making use of an existing application gets major consideration. If an existing application is in place, some companies evaluate whether to extend that application to help drive improvement in key process areas. Here, the decision parameters center around cost, complexity and immaturity.
• Buying a Packaged Application
  In many cases, you can buy a packaged application that’s supposed to be designed to address the needs of a particular process or function. Decision-making parameters include time to value, risk of adoption, responding to change and expanding scope.

The following tables show a comparison of the major tools from the two paradigms.

Table 1: Tools for BPM and SOA

The Benefits of SOA

SOA has some key benefits for enterprises. Let's take a look at these, as well as the benefits provided by BPM. For its part, SOA provides:

• Improved B2C communications
• A service-oriented architecture for the organization. A business organized around SOA is generally more flexible and can respond to business changes more easily and rapidly.
• The ability to reuse code to reduce development costs. Services make functionality more reusable, which decreases costs by avoiding the need to repeat the same functionality.
• Improved integration of existing e-business/CRM/ERP initiatives. SOA is not an alternative to approaches