BPM and SOA seem to be an inseparable love couple. Though I will not deny that the combination is powerful, I do see a lot of confusion arising because people do not really get what a business process is and use the words "business process" and "orchestration" as if they were synonyms. So what are we talking about when we are talking about business processes? Well, let's start with a bit of history. Probably the first man to describe a business process was the philosopher and economist Adam Smith in his book "The Wealth of Nations" (1776). No fancy diagrams yet, but just plain old text:
”One man draws out the wire, another straights it, a third cuts it, a fourth points it, a fifth grinds it at the top for receiving the head: to make the head requires two or three distinct operations: to put it on is a particular business, to whiten the pins is another … and the important business of making a pin is, in this manner, divided into about eighteen distinct operations, which in some manufactories are all performed by distinct hands, though in others the same man will sometime perform two or three of them.”
After the Taylorist scientific management the notion of business processes became real popular in the 90s. At that moment the hype was called "Business Process Reengineering". People like Hammer, Champy, and Davenport proposed the idea of fully redesigning a company’s business processes to become more effective and efficient. The main idea was not to consider the current way of working, but to start out with a tabula rasa. Of course there were successes, but this way of thinking posed a huge risk. At that time Hammer and Champy defined a business process as follows: ”a collection of activities that takes one or more kinds of input and creates an output that is of value to the customer”. The flowchart became more and more popular for describing business processes. So far, so good. Nothing about IT yet (though IT can play an important role in performing the activities).
Nowadays we have many notation techniques for describing business process, such as ARIS, BPMN and UML activity diagram. Too many to choose from actually. But since these standards are only notation techniques, these standards are in fact suitable for modeling any discrete process and not only business processes. One of the few methodologies that actually states how to define activities within a business process is DEMO (www.demo.nl).
Then SOA came along.... Exposing IT functionality through services has some major advantages. The implementation can easily be replaced without affecting the service consumer, services can be used by multiple service consumer thus enabling reuse of IT artifacts, and the concept of orchestration makes it possible to easily change the order of services or to add/remove services. The de facto standard for orchestration is the Business Process Execution Language (BPEL). But are we still talking about business process like the name suggests? BPEL is meant for orchestrating web services. Web services are XML-based standards which can be used for the implementation of SOA. Please take into account however that these web service standards are not the only type of standard that can be used for implementing services. One could also, for instance, use CORBA, REST, or DCOM. Orchestration is concerned with the order in which and the conditions under which the services are called. These services are usually fully automated, but BPEL4People (a new extension to the BPEL standard) also makes it possible to include human activities. So summarizing, BPEL makes it possible to determine the order in which and the conditions under what services are called and it also supports human workflow.
Services and human workflow are, however, not the whole story. Though BPEL can be quite suitable for making the IT environment more flexible, it does not focus on the business process as a whole. The main idea is that process logic is no longer implicit in the underlying applications that perform the services. Instead it is made explicit and can be monitored. The orchestration look very much like a ‘real’ business process in, for example, the quotation of an insurance policy. Many steps of this process can be automated and also humans perform well-structured tasks (that can be easily captured in user interfaces of computer applications). Now have a look at my work as an architect for Ordina. My activities vary from writing proposals, writing articles, working for clients, organizing events, lecturing to mentoring junior consultants. Is orchestration useful here? Well, maybe for reminding me to book my hours each month, but that’s it. Meanwhile all of my activities are part of the business processes of Ordina. They are, however, not IT-centered and not structured enough to put them into an orchestration.
Linda Terlouw is a solution architect for Ordina, SOA solutions. You can read more of Linda's work on her blog at http://www.servicespecification.com.