If a Business Process Package is developed for integrated use only, there are difficulties to expose the functionality of the Business Process Package as Services, because the integrated functionalities are often inverwoven so that it is hard to find a service interface that does not have unwanted side effects.

However if a Business Process Platform is built from scratch with the goal of exposing re-usable services from the beginning, then there is a better chance. They need to fulfil certain criteria. The services need to
1) Be fine granular – fulfillig only a small step.
2) Have defined preconditions in terms of the state of the Business Process
3) Transform the Business Process from one defined state into a next defined state
4) Have a clear business semantic

For example, if there is a Business Process Package offering a service to post an invoice, and the Business Process Package would start the payment automatically, then of course this is a very coarse granular service. A service consumer – modeled in BPMN – would rather have two steps
1) collect data for invoice
2) Post Invoice (including all “internal” steps)

But if a Business Process Platform is designed for exposing re-usable services, then it would offer serveral fine granular services, in our example
1) create invoice
2) Submit to approval
3) approve / reject
4) Post invoice
5) Start Payment

If this is the case, it makes sense to have a service consumer – which is modeled for example in BPMN – that contains several steps and conditions, like when (not if !) Approval is started, a workflow for approval / rejection, and so on.

However even in this architecture it is important to design wich decisions need to remain inside of the process platform and which can be outside of it. Sometimes the buzzwording demands, that all services are freely composable and all process relevant decisions need to be done in a process layer. This – of course – is not true.

First of all there are certain constraints, that the Business Process Platform demands, that a Service Client needs to comply to. For example there is no sense in creating a process, which first posts an Invoice and then afterwards does Approve it, if the platform as in most cases would demand the other way round.

Fruthermore not all decisions should be made outside of the platform. For example the decision if an approval is necessecary at all or not should be inside of the platform, not outside. Imagine a BPMN process services consumer where the conditions resides: If amount of invoice > 1000€ demand approval, otherwise not. This is nice but without effect. Because a different service client of the platform (e.g. User Interface) could simply go by the approval, even if the value would be 10.000€, because the condition is not enforced by the platform. To avoid this kind of unwanted behaviour the decision if or if not the approval is necessary needs to reside within the platform. Outside it can only be decided, if approval is given or rejection.

Therefore the platform must not offer a service operation: “Pass by Approval” but only “Check if Approval is relevant” or “Submit to Approval including Check if it is relevant”.

So the granularity and design of the services which are offered is decisive for the success of a service oriented architecture and the goal to make services consumable by a process consumer which is modeled by BPMN.

One improvement may be to automate certain parts of the process or to integrate them better. This can be done in various ways. One way is to develop new software, that does fulfill the specification given in the process models. Another way is to change existing software – especially the exchange of information between it. A third possibility could be to execute BPMN processes as workflows, if they represent workflow relevant parts and after a BPMN execution environment has been established.

But the most visionary possibility is that the BPMN processes are used as web service composition. Either by encasulating the existing or new developed software by web services, or by inclusion of pubic webservices – which can be done in simple cases. However a critical success factor in this approach is
1) the reusability of the web services and
2) the integration of the processes over the web services.

If the integration of processes over the web services is left to BPMN alone, then this can be only applied to simple cases. Standard Business Processes need to be integrated on their own, and the BPMN serves as a layer for automation, i.e. for triggering the next step that would otherwise wait for completion too long. Also it can be used for event correlation and as a result the trigger of a next step.

This approach works good, if the underlying Business Process Implementation follows certain criteria. This is already mentioned 1) and 2) and furthermore
3) the Business Process Implementation itself is modeled and thereby transparent and
4) It is flexible – i.e. Extensible.

If a Business Process Implementation fulfils 1) through 4) i want to call it a “Business Process Platform”.

So in a Business Process Platform BPMN can serve as the means to document the implemented Business Processes for the Purpose of Transparency and an index for Extension Points.

So in essence the Business Process Platform provides the Web Services, which are documented by BPMN. As we said these need to be consumed. If we have an execution environment, that is able to execute BPMN processes for the consumption of these web services, then I would call it a “BPMN Composite Environment”. If we have a Toolset, that allows the integrated model driven development of Composition Content and Platform Extensions, I would call it a Composite Integrated Development Environment. or Composite IDE.

So BPMN can play the role of glue in such a scenario. However also other model types are needed – most obviously WSDL.