[ad]
The one critical success factor of a Business Process Platform is the design of re-usable services.
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.