Mislabeled products
It has become trendy in recent years for software development tool vendors to include "business process" in the names of their tools. Thus we have "business process orchestration" tools, "business process management" tools, etc. This is a pet peeve of mine since these tools often have very little to do with business processes at all. For example, some integration tool vendors suggest that orchestrating a series of web-services together into a single coarse-grained web-service somehow constitutes a "business process". Most business people would beg to differ.
Dealing with the business-IT divide
The "business-IT divide" is the much talked about disconnect between what the business needs and what IT actually delivers. The irony of this situation is that the business-IT divide is the driver for much of the current focus on business processes and yet many IT product vendors have responded in a fashion that only deepens the divide by sowing confusion over the nature of a fundamental concept: the business process.
Business and IT in most organizations are two different and often physically separate communities that communicate poorly if at all, and often seem to be speaking in different languages. Dealing with the business-IT divide starts with understanding the nature of the problem. The business-IT divide is fundamentally a "communication problem", and communication problems are solved by finding ways to communicate better.
A pre-requisite for establishing good communications is establishing a common language or vocabulary between the two communities and an agreement on what the terms in that language mean. Who gets to define the terms? When it comes to business & IT, this is not a two way exchange between equals. We (technologists) are the service providers and they (the business) are our customers. The burden is on us to understand the needs of our customers. We, at a minimum, need to learn their terminology in an effort to communicate better with them and understand their needs better. Perhaps one of the most important terms in this shared vocabulary is "business process".
A "business process" definition
- A business process has absolutely nothing to do with technology whatsoever! Business processes have been around since as long as businesses have existed; long before computers or information technology were invented. And as long as businesses have been around they have sought to refine their processes to gain a competitive advantage over their rivals. For most of human history this had absolutely nothing to do with information technology.
- A business process is a sequence of activities followed by individuals in a business to achieve some business goal. Often these are manual activities executed by employees who play certain roles in the business in addition to others who are external to the business: customers, business partners, etc.
- These processes can be modeled at various levels of granularity in a business process modeling tool like Proforma ProVision. Typically the core elements of a business process diagram include (1) a separate swim lane for each role/person/department that participates in the process, (2) the activities that they perform and (3) directed lines between activities to indicate the order in which things are typically done.
- Information technology can be used to improve the efficiency of these processes. Sometimes this involves making applications (built or purchased) available to one or more of the roles in the process to eliminate manual tasks and even roles (down-sizing). Sometimes this might even involve using workflow engines (aka business process management) technology to automate certain portions of the process. This does not change the fact that the business process itself has nothing to do with technology!
Things that are not business processes
There are at least 3 different concepts that are often referred to when "business process" is used in typical IT communications.
usiness perform tasks for the purpose of achieving a particular business goal. This is the one and only concept to which the "business process" label should be affixed. Beyond the data center this is what people in the business world think you mean when you say "business process".
The other two concepts that IT people tend to affix the business process label to are (1) workflow (a.k.a. business process management) software and (2) web-service orchestration software.
-
Workflows
A workflow is that portion of an otherwise manual business process which is automated via one or more workflow application(s). This typically involves (1) visually modeling workflows in a workflow modeling tool, (2) deploying modeled workflows to a workflow engine and (3) implementing a graphical user interface to initiate and invoke workflows in the workflow engine via an API exposed by the engine.
A typical application might involve, for example changing a process which required circulating paper documents to multiple individuals for manual processing to one in which the paper documents are converted to electronic form and circulated to the appropriate individuals via a workflow-based information system. People sometimes refer to the visual models of these automated process segments as "business processes". However, these almost always represent only a small portion of the real business process and are more appropriately referred to by the traditional name of "workflows". Rule of thumb: if human decision making is needed in a business process then the business process can never be completely automated.
A typical application might involve, for example changing a process which required circulating paper documents to multiple individuals for manual processing to one in which the paper documents are converted to electronic form and circulated to the appropriate individuals via a workflow-based information system. People sometimes refer to the visual models of these automated process segments as "business processes". However, these almost always represent only a small portion of the real business process and are more appropriately referred to by the traditional name of "workflows". Rule of thumb: if human decision making is needed in a business process then the business process can never be completely automated.
One way to conceptualize the difference between a business process and a workflow is to think of the two different kinds of modeling tools that are used to model each, who actually uses each tool, for what purpose and what is actually done with the models produced.
Proforma’s ProVision modeling tool, for example is used by business consultants to model business processes collaboratively with business executives for the purpose of facilitating business discussions on topics like value-chain analysis and/or to run activity-based costing simulations and ultimately to make business decisions. The models are typically at a high level of abstraction and are not intended to be converted into applications. However, that the Process Driven Development (PDD) approach to software development does in fact refine high level process models of this sort to a more fine grained level where process roles (swim lanes) can be mapped to UML actors and process activities to be automated can be mapped to UML use-cases whereby traditional use-case driven development techniques can be utilized to design the appropriate software application.
Workflow modeling tools are used by software engineers for the purpose of generating concrete implementation constructs (source code, xml, database entries) that are then deployed to a workflow engine to support real applications. Visually modeling the workflows involves things like extracting information from scanned documents or user input, processing it (via invoking web-services or other kinds of services), storing information in workflow variables, adding/removing tasks from queues, sending notifications to other users, etc.
Proforma labels their modeling tool as a "Business Process Analysis" (BPA) tool and the later as a "Business Process Management" (BPM) tool.
-
Web-service orchestrations
Using web-service orchestration products typically involves modeling the implementation of an Enterprise Service Bus (ESB) based web-service in an Integrated Development Environment (IDE). The orchestrated service invokes one or more other web-services from potentially multiple service providers in a coordinated fashion. In so doing a single coarse-grained web-service is offered to service requestors relieving them of the burden of having to invoke multiple fine-grained web-services themselves.
A range of ESB products are available with a spectrum of capabilities for web-service orchestration. In general, a modeling tool is used to specify how the orchestration is to be implemented and this executable model is deployed to the ESB which serves as its run-time engine.
In the simplest ESB products approaches like itinerary based routing are used wherein an xml file is used to list the services that should be invoked from service providers in a sequential fashion when a particular ESB-based service is invoked by a service requestor.
Some ESB products support more complex options for orchestrating services. They might allow you to specify, for example, that certain sequences of service invocations should be done in parallel. The modeling tool would allow you to specify where the sequences should branch and aggregate. They might also allow you to specify that a sequence of invocations might halt and wait for an event - possibly user input - at certain stages in the sequence. When this level of complexity is reached, the orchestrations begin to look a lot like traditional workflows and might be expressed in the Business Process Execution Language (BPEL) wherein the initial service that was invoked by the service requestor might be something like "startWorkflow()".
Even if they do begin to resemble workflows, coarse-grained orchestrated web-services should not be referred to as business processes. In a sense they do orchestrate distributed "computing processes" insofar as they invoke different web-services from different service providers utilizing the computing resources (process, memory, disk, etc.) of distributed hardware. However, web-services are purely IT constructs and have nothing to do with the business. These things should be referred to as web-services, composite services, orchestrated services, etc. but by no means should they be referred to as "business processes".
