BPM Ecosystems Need Simulation and Optimization

SOA, BPM & ESB

With service-oriented architecture (SOA), that vision takes a big step closer to being realized.

SOA is an enterprise-scale IT architectural style that develops IT resources as business-aligned services to fulfill business needs. SOA supports service orientation, which is a way of integrating your business as linked services. Service orientation enables applications to invoke each others’ behavior as services, that is, repeatable business tasks that are self-describing and discoverable, meet specified quality of service requirements, and can be managed through governance.

Whereas a component is a unit of code that can be executed to provide functionality, a service is a component that is actually running, often in its own process hosted independently from the applications that are invoking it.

Indeed, the applications themselves can be broken into parts that each run in their own process and invoke each other through services. This is a composite application, a set of related and integrated services that support a business process built on an SOA.

The drivers of BPM and SOA are quite different, though: BPM is a business-driven initiative whereas SOA is an IT-driven initiative.

A related concept is the enterprise service bus (ESB), which enables software applications running on different platforms, written in different programming languages and using different programming models, to communicate with each other, without requiring expensive, time-consuming reengineering.

An ESB enables routing and transformation to be applied to messages during transmission. It is standards-based, which helps facilitate integrating products from different vendors and avoids an SOA requiring vendor lock-in.

One of the main jobs an ESB performs is connecting together service consumers (which invoke services) with service providers (which implement services). The ESB enables a consumer to invoke a service and matches that invocation with a provider that performs the service. In this way, the consumers and providers do not need to know about each other, they just need to all connect to the ESB.

SOA and ESB are not new ideas, but rather the latest version of evolving practices for encapsulating and integrating application functionality.

The real win for an ESB over traditional solutions is its ability to scale well across business unit boundaries. Today’s integrated applications need to work effectively in the extended enterprise, which includes an organization, its business partners and its customers.

That means the ability to leverage business information and utilities across systems:

  • That will use different data models;
  • That will be implemented on different technologies;
  • That will often use different security policies/procedures;
  • That will, for the most part, be hidden behind a corporate or business unit firewall.
  • Such considerations will apply even within a single organization, with different business units having made different solution choices. A centralized hub and spoke architecture (even if clustered) simply does not scale well in such an environment. Even their traditional strength of good centralized management of routing and business rules becomes a weakness when we try to deploy to a distributed cluster of hub and spoke systems.