I am quite honored that the authors of this book asked me if I could write the foreword. They have a long and concrete experience in implementing business processes, and we have interacted together in the context of telecommunication operators, where they delivered successful business process implementation.

What I would like to share here is some practices I came to after driving many business process management and service-oriented architecture projects. Many of my customers are still trying to find how to implement processes and what technology they should use. In fact, the answer is a palette of techniques that need to be applied in the best combination. So let me try to give some clues about ways that succeed.

To BPEL or not to BPEL, that is the question.

There have been long debates about whether agile enterprises could drive the way they do business in an orchestrated fashion, where a maestro drives all of the interactions, or if the enterprise should act as a choreographed dancing team, where each dancer implements their part of the choreography. As such, the partition of the orchestra was used as an analogy for describing the purpose of language that described processes such as the Business Process Execution Language (BPEL).

What has been missed in the orchestration analogy is that BPEL only orchestrates business service requests, but does not preclude the way the services will be executed. In a sense, BPEL is like musicians in an orchestra deciding what they could use to play their part, such as using a recorded musical part. We can easily say that the orchestration analogy does not really fit with services and neither does choreography.

So why use business processes. Agile enterprises delegate business focus to business owners, such as the owner of the customer relationship management or of the supply chain of a given country or market. In agile enterprises, the business owners establish a contract between themselves, where a party defines what services it needs for the other party, with the appropriate service-level agreements. If these services can be automated, they may end up being programmatic services. Within its domain, the business owner can be the maestro or service requests, requiring services from his own teams or from the next business owner. The end-to-end process ends up being a chain of explicit processes, each with a specific business owner, requesting services from other explicit processes.

The overall effect is implicit, where the implicit process is like a train where each wagon has an explicit controller, and connects to the next wagon in a flexible way to build the train. Wagons can be changed based on the business requirements, and the technology that is used within each wagon is left to the choice of the business owner.

There are many ways to implement explicit processes and these can reside in packaged applications, ERPs, or legacy applications. But in most of these examples, the flows are hidden in the application logic and are costly to manage. This is where BPEL helps in separating the flow of explicit processes from the delivery of services, which are finer-grained actions.

A question still remains on how to control the end-to-end process. This is where there has been confusion between explicit process monitoring and implicit process monitoring. The monitoring of an end-to-end process that cuts across different business owners requires the creation of an abstract process view, as defined by the Business Process Modeling Notation (BPMN) categorization of processes. This monitored process never exists as a single executable component in an application or middleware, but is just the representation of a high-level chain. It is just like viewing a train from the outside, where explicit monitoring looks at what happens in a particular wagon. The implicit process monitoring requires an event strategy to capture interactions between the explicit processes so that the monitoring engine can give a high-level image of the chain.

The final question that remains is what is a good size for an explicit process? Industry process standards can give clues in finding explicit process boundaries. There is a process classification framework defined by APQC (http://www.apqc.org). This classification framework models the business of industries in an enterprise decomposition and organizes the enterprise in business categories and then process groups. At level three of the decomposition, it has the processes. Similarly, the supply chain organization (http://supply-chain.org) defines that processes are at the third level of decomposition. Another example is the enhanced Telecommunication Operation Map (eTOM) standard from the TeleManagement Forum organization (http://www.tmforum.org). Again, here the explicit processes are at the third level of decomposition.

So it seems there is a common industry agreement that explicit processes need to be identified by performing a business decomposition of the enterprise, and that they need to be commonly located at a third level of this decomposition.

BPEL then applies for these explicit process and services are the way these processes communicate and interact together.

We should also not forget that processes carry information that is exchanged by services. I have been in projects where changes in the information models are propagated to the service interfaces and then to the business processes, leading to an important test effort. It is essential to create an ecosystem including information, services, and processes where the information model has a natural flexibility so that it can carry different content without requiring a message structural change. If you want to make your processes more agile, it becomes important to think about introducing variability patterns in the information model.

In conclusion, it is important to understand how to implement BPEL for private processes with a definite business owner. This book gives you a complete view of this language and of best practices to use it efficiently with the appropriate performance, and more importantly, value to the business.

Marc Fiammante,

Distinguished Engineer, Office of the IBM Software Group CTO for Europe,

Member of the IBM Academy of Technology