Posts Tagged 'Business-IT alignment'

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)


The flavours of SOA

SOA has two “flavours”. Both are valid and fit specific business needs.

1. Vertical (multichannel):

  • several channels share the same data and business logic (services) on a common layer
  • communication is usually synchronous – request/reply
  • the business analysis that brings to services starts from use cases (UML style: use case -> sequence diagram -> class diagram -> services)

2. Horizontal (event-driven / long-running transactions):

  • An applications triggers a business event (i.e. purchase order) and calls an asynchronous service to sink the event. The service is actually a long running process (i.e. order to delivery) implemented on a BPM engine. The BPM engine calls several services in order to execute the process
  • communication is both asynchronous/reliable/one way and synchronous request/reply
  • the business analysis that brings to services starts from a process model (BPMN -> BPEL -> services).

      The choice of which flavour to use depends on the business model of the organization.

      Often Financial services need to implement short running transactions with high interactions with customers (i.e. Internet Banking) and prefer the multichannel flavour.

      Manufacturing and logistics are more concerned in long running transactions and prefer the second flavour.

      Often Telco companies stay in the middle and need both.

      I think that every organization should explore the use of both styles, putting in discussion the internal culture (transaction-oriented or process-oriented) and evaluating the benefits coming from a different approach.

      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.

      SOA has a bad friend: EAI

      One of the typical mistakes regarding SOA is to consider this approach just a new kind of Enterprise Application Integration (EAI) solution.

      I will try to analyze the main differences between SOA and EAI.

      • Scope: EAI is typically an IT only project, SOA should involve business people and IT specialists
      • Goal: the goal of an EAI initiative is to solve the application integration problems. The  goal of a SOA initiative is to better execute, track and monitor business processes that use business services.
      • Means: EAI employs a bus (integration broker) in order to integrate the existing application silos – that remain at their places. SOA aims to break the walls of applications silos that hinder the flow of business processes and to create composite applications.
      • Benefits: EAI unifies the message transport middleware and brings simplification and reduction of technical latencies. SOA brings to agility in the creation, execution and the modification of business processes through the reuse of functional capabilities (services),
      • Topology: EAI has – conceptually – an hub & spoke topology (it aims the unification of the integration tools, although some integration brokers have a distributed technology). SOA has a distributed, enterprise-wide conceptual model (although many vendors push to a centralized, proprietary solution).

      Unfortunately many managers treat SOA as a technical project, this bring to EAI solutions based on the SOAP protocol and do not gain the business benefits of SOA.

      SOA projects should be considered strategic initiatives, obtain some senior management buy-in and involve business people, as well as middleware experts, software analysts and data administrators. Their success should be measured by business KPI, like shorter time-to-market for new products or shorter execution time for end-to-end processes.


      Bridging the gap between Business and IT

      In many organizations a “communicative gap” exists between Business and IT. The two teams use different languages and conceptual models. This brings to latency times due to the need to translate Business concepts and requirements in the IT language and vice versa. Moreover, often the translations are poor and bring to misunderstandings and loss of information.

      Sometime Business people learn the IT language and express their requirements in terms of applications and file transfers. Perhaps this is the worst scenario in which the real business needs are totally hidden and IT looses opportunities to enhance its solutions.

      The communication latency prevents an immediate information exchange between Business and IT and slows down the overall reactivity of the organization in its operations in the market.

      In a figurative language we can think to Business as a car driver and to IT as its vehicle that respond some second late to turn, accelerate or brake commands.

      the gap between Business and IT

      the gap between Business and IT

      Moreover business processes “disappear” (get implicit) when passed to IT. Often, important business rules have their IT counterpart in a bunch of Java code lines hidden in millions of other code lines that manage web pages or DB accesses. The changes of business rules require time and money because they require to modify the software analysis documents, to search the IT counterparts, modify the code and test the whole application.

      SOA represents a way to bridge this communicative gap. If services have a real meaning for Business you can create a one-to-one mapping between business processes and their “electronic images” that can be explicitly executed in IT systems by BPM or workflow engines. No semantic intermediations between the two models are needed




      SOA+BPM bridge the gap

      SOA+BPM bridge the gap

      The new processes are modelled by Business people composing functional capabilities (Business Services). From the IT side the development of the new processes will be obtained by composing the correspondent technological capabilities ((Web Services, IT Services).

      Business processes must be able to execute the activities offered by IT regardless the applications that actually have in charge those activities. The Business Services must have a clear meaning for the business experts that design the process and hide to them all the technical details that could blur a sharp representation of business processes.

      Business process representations should make use of very few components:

      • Business services – actions executed by IT systems that have a clear business meaning (i.e. “check the client’s credit”, “create a new order”)
      • Human interactions – solicited or unsolicited man-machine conversations (i.e. “ask the manager for the authorization”, “enter the order data”)
      • Flow controls, like conditional routing or termination.

      Somebody talks of a Process-View-Service (PVS) pattern that will progressively substitute the popular Model-View-Control (MVC) in the development of new applications, actually the proposed representation follows that pattern. BPMN models, as well as BPEL models enriched with human workflow, can be candidate formalisms.

      A hidden component in this view are the data that flows inside the process being used as input and output data for the invoked services.

      I believe that the vision described above represents the real nature of a Service Oriented Architecture and unify the disciplines of service orientation and Business Process Management (BPM). The technical aspects of SOA, like ESB or WS-* standards should be covered by another discipline, i.e. Web Services technologies.

      The very nature of SOA

      One of the most critical challenge for organizations is to enhance their effectiveness and efficiency in the execution of “end-to-end processes”.  E2E processes are sequences of business activities triggered by a business event which terminate when the event is handled in all its aspects.
      customer-centric organizations must enhance their E2E processes

      customer-centric organizations must enhance their E2E processes

      Every obstacle (technical or organizational) to the straightforward execution of the process and to its traceability reduces the quality of service perceived by the customer.

      Customers are not the only external interface that triggers E2E processes: other stakeholders can be citizens, partners or authorities.

      Business processes are progressively integrated in longer and longer value chains that create an unbroken line linking the internal (or externalized) activities with the external terminal interfaces. In this way is much easier to measure the capacity of the organization to stay successfully in the market.

      This trend has progressive and radical impacts on the enterprise application’s architecture. The following picture shows a possible evolution in this sense.

      horizontal processes vs. vertical application silos

      horizontal processes vs. vertical application silos

      In order to better execute, control and track horizontal E2E business processes, IT systems have to break the vertical walls, or silos, that software applications build at their borders.