So the paper proposes, that for the purposes of service validation, (automatic) service construction, service composition and service replacement there is not yet a represenations, that allows for a closed theory – i.e. a structured solution in all cases. Actually it is an opening paper that will be later completed by describing “operating guidelines”, which are intended to fulfil this purpose.

My personal opinion is, that is it a good endeavor. Such work is needed to complete the foundation for modeling tools, that allow for more comfortable modeling consistency checks and functionality.
I especially see much benefits in consistency checking. I also have one or two patents in this area. Important in my view in consistency is a clear definition of the goal of the check and a good method to explain consistency errors to the tool user. Consistency checking is in most cases useful. One needs a little bit of patience, to make a service definition fit to another, because there is always this one unwanted execution that needs to be eliminated. But it is worth the effort, because it is better to eliminate these errors in modeling time than in runtime.

Service construction is in my personal opinion difficult. In my view there are always abiguities in such an endeavor. So I prefer “human” design plus consistency check.
Service composition promises some benefit – especially if there is a skeleton composed, which can be further edited by the human designer. Also here it is important to formulate clear goals of the service composition and to have a complete – i.e. without gaps – description of the underlying services. Especially if there is a Business Process Platform that offers services, that need to be composed, and that is model driven, this is very promising. There are also other projects working on this. I may come back to this some other time.
Service Replacement is certainly an interesting application. If a service is changed, then it is certainly worthwhile to know potentially which consuming services might be affected and which not. This may be the outcome of this part of the research.

So good work – keep it going!

The business processes are reflected by business objects themselves, which are linked with each other. Events are correlated to the business objects. This makes sense, because the business objects are clearly identifiable, because they are related to a concrete business transaction. There are concrete customers related with it, suppliers, products, dates – the things that make them easy to identify and find.

In contrast, if there are process instances, which have only an anonymous ID, like a Globally Unique Identifier (GUID), then the relationship to a concrete business transaction is rather loosely. Therefore it is hard to manage them. Furthermore if there are business attributes inside of the process instance, typically they are in generic containers (not always) and therefore difficult to use in queries.

So which process instances are needed within a Business Process Platform beside the business objects themselves? Probably some for approval. Some for ad-hoc processes. Not much more comes to my mind.

Monitoring a business process itself is a different story. For this not process instances are needed, but chains of business objects that are actually process objects and some process instances – that I already mentioned.

• structured,
• unstructured and
• semi-structured

processes, that I like. It is interesting, that in the definition of process the emphasis on the post is less on the sequence of activities, but more on the business goal to reach. That was, what I proposed earlier. And it makes sense. In the end it is more important, what the result of a process is, than what has been done or should be done in which order to try to (!) achieve it. I said “try to” because sometimes just doing a thing can not guarantee that the desired result is achieved. That’s why I say that the result is more important than the doing of an activity or task itself.
Of course it is inevitable that when a business process is implemented in an business process platform, that it is structured. Otherwise it is impossible to implement the business functionality that transforms the business objects that are part of the business process from one state to another. That is said modulo that there may be some generic functionality like a process engine for workflow or generally for execution of modeled process parts of course.
BPMN supports some Ad-Hoc modeling cababilities. There are Ad-Hoc tasks where the sequence is not defined or where it is not defined if none, one or all of them are executed. However one would expect, that any task that can be executed is modeled – at least if it is not, it can not be system supported. Also it is a difference, if the Ad-Hoc cababilities are on the process type level, or on the instance level, meaning that a concrete process instance can be adapted to a new, unexpected flow, sequence or even new Ad-Hoc Tasks.
However the more the tasks become Ad-Hoc the more they become an empty shell. What do I mean by this?
Create an Ad-Hoc task “Calculate stock losses based on financial crisis”. Of course if this is done the first time, there is no busines logic implementation for this. Even if there is a SOA service offering the solution, there needs to be some implementation of calling the service, which means gathering and providing the needed parameters and using the result in other processes.
So – as soon as a process is implemented in a business process platform it has at least some constraints.
Which is ok – because it has been formalized, because it’s execution is more repetitive.
On the other hand especially in times of crisis the importance of Ad-Hoc processes grows to account for the need to compensate unforeseen difficulties in the daily “business as usual”.
The important thing is, that the structured, the unstructured and the semi-structured processes can be integrated as seamless as possible. This is only possible, if there is a common notion of result of a process or of an activity in the process. Furthermore it is an interesting question – especially in semi-structured processes – how much constraints are desribed.

• None Constraints: Unstructured.
• Some Constraints: Semi-Structured.
• All Constraints: Structured.

What are the elements of this business process space context? A comprehensive answer is too long for this post, but it should include process metrics, process design, business semantics, and process governance [...] Kiran Garimella

from http://www.ebizq.net/blogs/bpmblog/2007/03/the_death_of_bpm_it_aint_over.php
That is an concise list of what is important within BPM, although I to not share the view of the author, that BPM is a kind of proces operating system. ImhO it is a design principle and a management paradigm. It must be supported by system design, to become effective, but it is not an operating system, upon which higher level solutions will be developed. Yes, it is an architecture – and the Business Process Platform architecture that I already mentioned is one important part of it. But it is not merely a separate software layer.
Now let us look a little more into detail of these elements:

Ad 1) Business Semantics.
It is obvious, that it is inevitable to take into accound the process, that is realized by Business Objects (Ordering, Selling, Payment, Stockkeeping, Billing, …) if the process semantics is important. Each of the Business Object types have a business semantics. Each of their states has and the actions, that can be performed with them (like release). It is not possible to ignore them, if an holistic view on the process semantics is necessary. The other way round said: It is often necessary to realize the process semantics by means of implementing Business Objects, because it is so sophisticated business semantics – if I mention prices calcuation for example.
Ad 2) It is impossible to do process design and not take into account the process, that has been implemented in Business Objects already – if it is not a very simple case like a very simple workflow. But even with a simple worflow, there often is a Business Object (Invoice, Project, Order, …) behind it. So the process can not be designed completely free, but within the limitations of the Business Objects, that are going to be used. Or the other was round: if the Process is Designed completely free, then Business Objects need to be implemented or extended to realize such a behavior.
Ad 3) Process Metrics.
Is it possible to think of process metrics and not take into account the state of Business Objects? Plainly said: No. It is relevant, if orderes are Released or not, if Invoices are posted or not and how long it takes from ordering an Order (i.e. reaching the state ordered of the Order) and posting an invoice (i.e. reaching the state posted of the Invoice). So process metrics need a tighter integration with Applications – in the form of a Business Process Platform BPP.
Ad 4) Process Goverance
Process governance can only be realized, if the necessary process metrics is provided. As a result of process governance, the process needs to be adapted. This can – in certain limits – be done by changing some modeled workflows. But often it is needed to utilize different functionality which is implemented in Business Objects or to adapt Business Object functionality. This can only be done, if the application has been built in a way, which makes this possible cost effectively – i.e. by conforming to a BPP architecture.
So the different elements of BPM can better be reached, if BPM is tighter integrated into applications – i.e. if applications are BPM enabled – and if a Business Process Platform (BPP) programming model is followed.

“By the year 2012, BPM will be subsumed into major applications.” Simon Hayward

See also:
http://www.ebizq.net/blogs/bpmblog/2007/03/the_death_of_bpm_it_aint_over.php
An interesting statement. Especially in the light of the remarks about “What is a Process?” that I made earlier:
http://www.bpmnforum.net/blog/bpmn/bpmn-in-research/what-is-a-business-process/
I suggested, that there are commonalities between Process Objects (Workflows) and Business Objects (like a Sales Order). They have a state, they have actions or activities, they have constraints. There are differences, but as long as we focus on the commonalities, we can think of utilizing this common ground for common frameworks.
Applications are made up of business objects and their relations. Very often these business objects are programmed. In contrast workflows are modeled. So if we can achieve modeling business objects in an application, then the business object model is the foundation for better integration of BPM functionality with the application. I call such a modeled application Business Process Platform or BPP.
To not remain too abstract, I make a concrete example.
Think of a Project Management Application, that has a Business Object “Project”. Now, a Project BO is created. Before the Project is released, there must be an approval. So – when does this Approval start? It needs to start, if the Project business object has reached a certain state – for example “Data Entry finished”. Only then a workflow or task needs ot be started. The workflow or task is what we traditionally understand as being part of BPM and what we model by BPMN for example. But if the state “Data Entry Finished” of the Business Object “Project” is also modeled, then the foundation has been created to use it in a generic framework, that enables BPM – for example by providing events to the workflow to start.
Furthermore if the Approval is finished, a subsequent step (action, activity) must be performed with the Project business object: Release, changing the state to Released.
That is a very simple example, but often difficult to achieve if not these preconditions are met:

1. The state of the business object is modeled.
2. The action of the business object is modeled.
3. The action is provided as web service
4. There is a generic framework utilizing it to make the integration of the workflow and the business object happen.

This can only be achieved, if an application is designed from the beginning to provide such modeling information. This had not been completely done in the past. But there is no reason why this should not work. However if an application fulfils 1-4 it should be called a Business Process Platform or BPP.

So with the upcoming advent of BPP, the Applications will be BPM enabled.

[ad]

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.