Posts Tagged 'MDA'

Why not Petri Nets?

I have read the excellent article by Johan den Haan “The Process Centric vs. Information Centric approach to SOA”. It strengthen my idea that BPM must go beyond its current boundaries and explore new languages that better fit business process modeling.

I am not sure that an event-driven model can fit every requirement for modeling, in some case (see my previous post) when the process is driven by a complex data (i.e. product structure) some hierarchical model could be more effective and complementary to an event driven model.

Turning to event-driven I have tried to model a process using Petri Nets. I started from a process that I found hard to model with BPMN. When you have different asynchronous user data entry BPMN does not allow to have a simple vision of the end-to-end process.

Petri Nets allow to design a more flexible model taking into account exceptions in a seamless way. Moreover CEP configuration languages are very close to Petri Nets concepts and allow to quite straightforwardly translates Petri Nets into execution models.

Example of Petri Net (order to production process)

Advertisements

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.