Frank Michael Kraft's Blog

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]

[ad]
A SOA consists of Process Components, each of which fulfil a certain business functionality, that interact with each other. One possibility is that a Composite Application does call Services of an underlying Business Process Platform – be it synchronously or asynchronously. Another possibility is, that Process Components of an unterlying Business Process Platform communicate with each other by mainly asynchronous web services. Examples for the first were mentioned above while examples for the second could be a Process Component for Supplier Relationship Management including Purchasing and a Process Component for handling the Delivery, that exchange asynconous XML messages with each other. Another example is the message exchange between a seller and a buyer.
The modeling of a choreography can adress both purposes. It does focus on the exchange of the messages alone – i.e. internal details of the process components are not modeled in such a model.
However it can server as a Top-Down Design methodology – if new Process Components will need to be designed, or – it can serve as a contract between two communication participants, that are adapted to the message exchange.