The goal of BPM is to make an organisation run more efficient. The first step is analysing and describing how work gets done in an organisation. Let's define a business process is a description of the way that people and systems work together to get a perticular job done. Once business processes are described, the search for optimisations can begin.
Sometimes business processes have evolved organically and merely looking at the overall business process shows some obvious inefficiencies. Searching for modifications that make a business process more efficient is called Business Process Reengineering (BPR). Once a large part of a business process is automated, statistics and audit trails can help to find and identify these inefficiencies.
Another way to improve efficiency can be to automate whole or parts of the business process using information technology.
Automating and modifying business processes are the most common ways of making an organisation run more efficient. Important is to note that those are parts of business process management in general.
Managers continiously break down jobs into steps to be executed by their team members. For example a software development manager that organises a team-building event. In that case, the description of the business process might be done only in the head of the manager. Other situations like handling an insurance claim for a large insurance company require a more formal approach to BPM.
The total gain that can be obtained from managing business processes is the efficiency improvements times the number of executions of the process. The cost of managing business processes formally is the extra effort that is spent on analysing, describing, improving and automating the business processes. So that cost has to be taken into consideration when determining which processes will be selected for formal management and/or automation. This explains the focus on procedures with a high recurrence rate.
The main goal of BPM systems is to facilitate the automation of business processes. In building software for business processes, two roles can be distinguished: The business analyst and the developer. In small teams, these two roles can of course be fullfilled by one person. The business analyst studies and describes the business process and specifies the software requirements, while the developer creates executable software.
Traditional BPM suites try to start from the business analyst's model and work their way down towards executable software. They try to minimize the need for technical skills so that the business analyst can produce executable software. All of this is centralized around the graphical diagram so inevitably, technical details ripple through in the analyst's world.
In our vision, the central idea is that the business analyst and the developer communicate in a common language with the help of the graphical view of the process. Technical skills will always be necessary when developing software. The business analyst is responsible for the graphical view and should not be forced to deal with technical aspects of the process. Without those technical aspects the process will not be fully defined and hence it won't be executable. The developer is responsible for the technical implementation aspects. Technical aspects should not require diagram changes.
The most recognized name in service orchestration languages is BPEL. Service orchestration is to be seen in the context of an Enterprise Service Bus. An enterprise service bus is a central communication backbone on a coorporate level. It integrates many diverse systems and it is based on XML technology.
Suppose you have services A, B and C on your enterprise service bus. Service orchestration is a graph based execution language fror writing a new services as a function of existing services. E.g. A new service D can be written as a function of existing services A, B and C in an orchestration script.