Stephen B. Morris looks at how separating business process code from other business logic improves pluggability and customizability.
Moving process logic higher up the stack
Should a business process just be one more software feature? Not according to proponents of Business Process Execution Language (BPEL). Stephen B. Morris says that separating your business process code, via BPEL, from the rest of your business logic gives you robustness, pluggability, and customizability that's otherwise difficult to obtain.
The vast majority of software producers focus exclusively
on domain-specific solutions. In this way, software is becoming
more customized and correspondingly, less generic. While some
end users (particularly large corporate customers) may be able to
request features that closely fit their business processes, it's
likely that most of us end up with a poor fit between our deployed
software and our business process needs. The end result is massive
cross-vendor duplication of development of software that tries to
implement code as well as business process logic.
An interesting separation of concerns is becoming possible by
the use of BPEL .
BPEL allows for business process logic to be expressed in a
specific language and tied into external software. This reduces (and
potentially eliminates) the need to code business process logic in a
traditional programming language (such as Java or C++/C, etc.). In
turn, this provides a clear separation between software features and
business processes. By taking the business process logic (e.g.,
workflow management) out of the application code, the latter
becomes simpler and more focused.
Let's say you buy a shrink-wrapped package with n
features. If this software is integrated into a BPEL framework,
then it should theoretically be possible for you to swap out any of
the n features and replace them with web service (or
downloaded) code of your choice.
In this article, I'll review the idea and merits of separating
software features from business processes in the context of BPEL.
Along the way, we'll see how this leads neatly to the need for
highly generic software. I believe the latter is a candidate for a
Dynamic 24-Hour Business
The pace of business continues to increase, outstripping the
ability of IT to keep up. I saw this up close recently when I
booked a flight online: I entered all of the flight details, my credit
card number and address, etc., and clicked the Confirm button. The software
chugged away doing its thing and returned with "Error 2, please
ring the reservation center immediately." It was around 9:00 p.m. and
was outside the business hours of the reservation center. The next
day, I made contact with the center and it turns out that the
software allows three minutes to enter all details before leaving
booking mode and transferring to enquiry mode. Credit-card
deductions can't be made in enquiry mode! So the operation failed
with the apocalyptic message! This turned a normal synchronous
(operate until finished) business process into an asynchronous
process with an exception. The latter invariably requires human
A Happy Ending
To their credit, the agency contacted me at 9:01 a.m. the next
morning to resolve the problem. This illustrates the close
relationship such organizations have with their IT infrastructure.
I suggested (amicably) that the software could possibly be improved
by allowing users to enter a date range and have the system return
with the best price, rather than being driven entirely by the
Figure 1 illustrates the existing user-driven workflow, where
the system simply checks availability and books the travel
Figure 1. Flight-booking scenario
Let's identify the business processes and the software elements
in Figure 1. The business process is the overall set of activities
that ultimately results in a revenue flow into the service
provider. This means that the business process is everything that
happens in Figure 1, as well as back-end operations.
The associated software is the code that runs in support of the
business process and comprises:
- Capturing flight details.
- Capturing selected hotel details.
- Calculating price.
- Making the final booking.
Let's now try to separate the business process from the software
elements. The "Journey Management" entity in Figure 2 is a notional
placeholder that may or may not exist in the operational
"Business process and software separation" />
Figure 2. Business process and software separation
The end-to-end business process starts with the instantiation of
a notional Journey Management entity. The latter then creates
entities to support the remainder of the business process. How
might the provider implement the suggested improvement of allowing
a range of dates? Figure 3 illustrates a possibility: adding an
entity called "Enter Loose Details."
"Using business process thinking for a more flexible format" />
Figure 3. Using business process thinking for a more flexible
The loose details entity would allow selection of a date range
and a destination. Then, it would search for the best rate or a
selection of rates. The user could then select one of the returned
options, and we're back to the normal operational mode except that
the system has supplied some critical (business-differentiating)
Where's the BPEL?
Where does BPEL fit into this? Mostly in orchestrating the flow,
starting with the Journey Management entity. In other words, the
Journey Management entity (if it exists) can be expressed in BPEL.
Under user direction, this entity invokes the other elements as web
services. Such an arrangement provides the required separation of
In practice, if you wanted to add a feature (such as the loose
date details above, followed by availability/price calculation),
the programmers would have to start updating web service code,
taking care not to break the containing business process flows. In
other words, the code and business processes are unnecessarily
intermingled. Does it have to be this way, or can organizations use
the current wave of migration towards web services as an
opportunity to improve things? I believe BPEL provides what may be
a golden opportunity for the software industry to place code into a
more generic or utility-centric role with minimal contact with
business process flows.
BPEL: An Integration Framework
BPEL is a programming abstraction that allows for the
business-specific orchestration of multiple web services to achieve
some business computing need. The orchestration results in a
complete or partial business process flow. The flow may be:
- Synchronous: Wait for a result until completion.
- Asynchronous: Completion is notified later.
- Long running: Input might be required from a customer
contacted by post.
- Deferred: The state is stored for later
An important element of BPEL is its support for XML
technologies, such as XPath, XSLT, and XQuery. This means that BPEL
can manage XML documents and make calls to external web
This provides a means of moving business logic out of the
built-to-order area (today's code) and into the generic web
services layer and the BPEL layer as illustrated in Figure 4. The
migration process from built-to-order to web services is happening
today, but there is also an opportunity to add value with the use
"Migration of Today's Built-to-order Code to BPEL and web services" />
Figure 4. Migration of today's built-to-order Code to BPEL and
BPEL can be used to implement the business logic, and the web
services code can provide far more generic services. In effect,
Figure 4 illustrates a means of separating the dual concerns of
expressing business logic and the associated software-based
What does such a separation of concerns give us? To answer this,
let's take a look at separation of concerns (SOC) in other
Separation of Concerns and Business Processes
The notion of separating business logic from presentation logic
is well established in technologies such as J2EE. The
"http://struts.apache.org/">Struts framework provides
separation by its use of the
pattern to avoid duplication of access logic. The software
architecture movement views SOC as a fundamental approach for
creating architecture-driven designs.
In fact, SOC has been with us for a long time. For example, look
at the way networks are designed and built: devices are selected,
configured to run (usually) several protocols, and services are
delivered across the network. SOC also permeates society--if you
want a loan, it's unlikely you'd make much progress by going to the
dentist! Rather, you go to the service provider who can deliver
Software is one of the few remaining areas where most vendors
are still following a one-size-fits-all approach. This is largely
because no widely adopted standard has existed up to now for
expressing business process logic. As we've seen, BPEL now fills
The Advantages of SOC
If we look at Figure 4, an organization migrating to web
services can use this as an opportunity to encourage more generic
software while simultaneously expressing business logic in BPEL.
Such a framework offers scope for organizational
Customization is the key as vendors try to address segmented
markets. For this reason, generic software is not just desirable
but is in fact a business imperative.
Let's take a look at what BPEL has to offer.
<invoke>: Used to call a service
synchronously, such as the Confirm Details element in Figure
<assign>: Used to manipulate XML documents
prior to invoking a web service.
<faultHandlers>: Used to catch and manage
exceptions, e.g., if a customer has bad credit.
<flow>: Used to initiate asynchronous
<receive>: Used to handle asynchronous
callbacks from long-running services.
<switch>: Used to support decision making,
such as booking the lowest price.
The above facilities allow for a combination of flexible
manipulation of business processes as well as a clear separation
between business process logic and software.
Benefits of Generic Software
Removing business logic from software and placing it in a BPEL
"layer" should help to simplify the software. Software for uses
such as flight pricing can then become more generic; i.e., a true
service. The data acquisition and service invocation can occur in
the BPEL layer and the pricing code becomes more of an "engine"
model. The latter is similar to a database engine: a generic
element of a broader database management system product.
If the service code is well-engineered, then we might see a true
software service component market emerge. Examples of such
components could include capital gains tax calculation, flight
pricing and booking (as we saw earlier), etc.
The key benefit for the IT sector in such a trend would be
generic cleanly separated software.
Is Telecom Putting the Brakes on Global Communications?
Let's take a look at a fairly basic telecom business process:
switching on a complex cross-network service.
Figure 5. A typical telecom service
The service (and its customers) illustrated in Figure 1 requires
multiple routers in the service provider network. It could be a
virtual private network (linking geographically distributed sites),
an IPv6 transport, an IP telephony solution, etc. The exact service
isn't of interest to us here; suffice to say the service requires
more than one router in Figure 5 and might also require use of
routers in other service provider networks.
Let's assume the network in Figure 5 is made up of routers from
more than one vendor. How is a service such as the one depicted
in Figure 5 created by the service provider? Normally, this is done
as part of a business process called service provisioning, an often
labyrinthine combination of software, human input, truck rolls, and
customer service. The facility that implements all this is called
the operational support system (OSS). The OSS orchestrates the
overall service provisioning process.
OSS installations are massively complex bodies of software and
business process logic. Many have been built up over 20 or more
years. Again, the business process and software logic is
inextricably interwoven. While there are many OSS vendors, it is a
fragmented inefficient market that serves overly complex
installations. The same principles apply to the OSS area as were
discussed in relation to Figures 1, 2, and 3.
Competition Versus Collaboration
The major software vendors have long competed with each other,
and so it should be! Witness the often bitter struggles between
Microsoft and Novell. The unproductive practice of
extinction-producing competition is diminishing as Microsoft and
Sun Microsystems start to collaborate. This should help end users
get better products rather than just de facto brands that contain
business process logic lumped together with software features.
I often wonder at the extent of duplication in the software
industry: this is certainly the case in telecom where dozens of
vendors slavishly implement products based on ever-evolving
standards (such as MPLS). Each vendor tries to bring some new
wrinkle to their product that will move buyers in their direction.
This model can provide benefits in specific domains, such as
accounting solutions, but it may be less helpful in industries in
crisis (such as telecom) undergoing massive restructuring and
technology upgrade. The latter may need a more fundamental
More collaboration is needed in the software industry to reduce
the level of duplication and to increase the generic
characteristics of products.
Globalization has resulted in overcapacity in a number of core
industries, such as telecom, IT services, retailing, and car
manufacturing, among others. The price transparency offered by the
Web has enabled customers to extract maximum value, a trend that
has led to unprecedented price competition. It seems unlikely that
profits will rise dramatically in the years ahead, even as the
world pulls out of what some commentators reckon was the first
"global" recession. This may well result in cost cutting on an
ongoing basis, and there's no reason to suspect that IT won't be
hit. I think that IT should endeavor to become as streamlined as
possible and BPEL/web services suggests itself as a possible path
By removing business process logic from code, we would see the
potential emergence of generic software for web services use.
Business process logic would then reside in a BPEL layer that would
orchestrate the required service calls. This would help to reduce
the growing complexity of software and systems.
width="1" height="1" border="0" alt=" " />