BPM is a too tight dress on SOA

In my previous posts I stressed the fact that BPM and SOA together brings many benefits in terms of business-IT alignment, agility, time-to-market and reuse of business capabilities.

BPM and SOA cooperate in a symbiotic way:

  • BPM design-time tools model the business process to implement
  • BPM run-time tools (engines) execute the process instances calling SOA services
  • SOA offers the “execution environment” for BPM engines

SOA services (together with user interaction forms in case of human workflow) are the building blocks for modeling and executing Business Processes.

With this approach you can change your processes just changing the graphical model.

Of course sometime you will need to develop extra SOA services. In other words you will need to expand your process execution environment. If no extra service is needed the time required for your change is minimal.

This is a perfect scenario. If every Business Process could be implemented this way the promised benefits would be easily achieved.

Unfortunately the world is more complex.

Let’s take an example from a Telco company. One of the typical processes for a Telco is the “Order-to-Delivery” one. When a new purchase order has been issued the company has to provision all the components related to that order.

You can model the O2D process using a BPMN or BPEL model. However the O2D process is strictly related to the purchased product and its components (ADSL line, cellular phone, modem, IP TV). You have two choices:

  1. Model a generic O2D process that fits every product.
  2. Model a very detailed process in which to specify every dependence among the components to provision (“B must be provisioned after A”) and the exceptions to handle. A complex model, “flow-chart like” is obtained.

In the former case the model is quite useless. Clearly the logic about the provisioning of a specific product is outside the BPM model.

In the latter case you get a complex and algorithmic model just less complex to maintain than a Java program. BPMN and BPEL reminds too much the procedural languages, it’s very easy to trespass the limit and use them as old fashioned flow-charts diagrams.

If you modeled other aspects, like billing or pricing you could have the confirmation that BPMN and BPEL are not able to represent every aspect of a business process. They are languages specific for high level business processes and for simple orchestrations.

Let’s imagine to have different formalisms that help to model different aspects of a business domain.

For example the provisioning dependencies could be easily described in a non-procedural way using a Pert model.  Billing rules could be described with some hierarchical model derived from the product’s bill of material. Specific engines, similar to BPM engines shall be developed in order to interpret the run time instances derived from these non-BPM models. Of course the SOA environment is still valid also for these specialized engines.

I do not propose a classic Model Driven Architecture (MDA) approach since the MDA brings to the automatic generation of programming code while I think to a non-procedural graphic model directly interpreted by specialized SOA based engines. Model-Driven SOA is a better term.

I believe that this “Domain-Specific, Model-Driven, SOA-Based” (DOMOSO) approach is a pragmatic and promising solution in many scenarios. Particularly when business domains are stable in time and changes effects specific aspects of business processes only.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


%d bloggers like this: