To quickly wrap it up: It was a good decision. I have built 9 Business Objects in the meanwhile of which the first one was the most difficult obviously. The others quite naturally follow. These are as of now: Workitem, Sprint, Book, Attachment, Note, Payment, Regular Payment, Statement, Transaction. Furthermore I have added Analytical Objects for the purpose of analyzing the Business Objects. I will explain by and by what they do. I will not explain the programming model and architecture of Microsoft Windows Azure in detail. You can inform yourself in public sources, if you want. The UI is HTML – so it’s not worse than salesforce.com. Plus I have added some diagrams in Microsoft Silverlight.

I was able to quickly implement the business logic, that I wanted to have. The programming language I use is C#, which I like. After implementation you press a button (ok, three, four) and then the application is running live in the cloud. It’s just so easy, lean and clean.

So the first Business Object I implemented is the Workitem. In salesforce.com I called it Goal – I am still a little bit indecisive how to call it. I can say so far that it is different from all other Workitems or Tasks that I happen to know. I asked myself what I need for my daily work. My work is that of a Knowledge Worker. It is in good part unpredictable, but not unrelated. Also it is not unplanned. And it has clear goals and a clear purpose. So for this requirement I tailored this Business Object Workitem and I worked with it for many weeks now. I have worked now with at least 3000 instances of it and I am more happy with it than with any other task or project tool that I used so far. I have my work under control now, notwithstanding the fact that many unpredicted events occurred and adaptations of the plan were either necessary or chosen by me.

And: It is served in the cloud. Obviously this means that I can access it from every computer with a browser, which I regularly do. Recently I was in a shop and wanted to buy a memory extension. I did not remember the model. So I asked, if I could quickly use the computer, logged into my Platform and looked it up. Just as easy. In other instances I just pulled out my iPhone, logged into my Platform – using the standard browser, and edited some workitems. I did not even have to write an iPhone App for this. Although I might in the future.

What did I do with the old workitems/goal instances that I had already created in salesforce.com including attachments and notes? Within two days I migrated them completely into my Azure Workstream Platform. How? Salesforce.com offers web services to read the content. So I pulled out the Web Service Description (WSDL) from my salesforce application – which as we remember were custom objects – into Microsoft Visual Studio, generated WebService Proxies for that, mapped them into my Business Object Structure and then pulled the content over. That’s it. From that point on I as productive in my own Azure Workstream Platform. And I am until today.

I will explain more about the functionality of the Business Objects, that I created, soon.

I aswered, that I have experience with that and that I agree that there is a tremendous potential with that. That really was an interesting discussion, because I did not hear such analysis before in the discussions in the public marketplace. I think this is the right direction to think.

I had already governed the design of the process of about 200 or more business objects, creating about 2.000 models including roughly about 5.000 web service operations. I didn’t use BPMN for that, because it was not flexible enough for this purpose, neither any of the existing languages. I used an own Domain Specific Language (DSL) for Modeling the behavior of those Business Objects.

My summary of that exercise is, that I agree to the original question. Only by modeling the process of Business Objects which are part of the ERP system, the ERP system’s web services will as a result have the right granularity. What is the right granularity for web services? Reusability. If web services are reusable, then they pay off most. In order for them to be reusable, they need to fulfil certain conditions. A web service operation should only do one thing at a time., i.e. not trigger an endless chain of activities in the system. It should have clearly defined preconditions. The effects and results of the web service operations must be clearly defined in terms, that can also be preconditions to other web service operations. That are the most important criteria in my view.

A system must be designed for this philosophy from the beginning. I strongly believe that adding web services to an existing system falls short of this goal. Even if it has some value, it would not use the full potential.

In general what I miss in the public standards is a language to describe the behavior of web services. Yes, BPMN 2.0 goes into that direction. But BPMN 2.0 still has to prove that it can fulfil the promise in practice. I think to a degree it can. It will turn out later, if it is possible to simplify the language or if it becomes an inspiration for other approaches (e.g. constraint based instead of workflow based).  And using BPMN 2.0 in itself does not guarantee the success. Additional guidance is necessary, certain quality criteria that each model must fulfil.

However, if the behavior of web service operations of an ERP system is defined, and if the granularity of the web service operations are so, that they are reusable, then the potential is very big. Because it means, that it is possible to attach own processes to that ERP service and even to interweave own processes in-between ERP processes. For example to add an approval before the release of an order under certain conditions, to add an own method of calculating benefits for the payroll and the like.

However as a limitation to the original question I would say, that not all of the processes modeled could be customized or changed arbitrarily. There are certain core processes, that the ERP system offers, that can not be changed without the danger of losing the consistency of the process. Therefore it is clearly necessary to describe which part of the process needs to remain stable and which parts of the process can change or are open for additions and interweaving. This of course must be part of the model.

Nevertheless this is a conviction, that has grown over time and a goal to which I can even see the path to the solution already now.

My prediction is, that in the future there will not be Applications on the one side and Business Process Management on the other side. But Business Process Management enabled Applications.

My prediction is, that in the future, there will not be the decision “Should I implement it as an Application or model it in a Business Process Management Suite?” any more. Because with BPM enabled Applications this is the same thing.

Business Objects will be Process Objects and Processes will be Business Objects.

And it will solve many of the discontinuities we have today trying to unify the two worlds.

This is my prediction.

Yes, of course we can discuss about business rules and automated decisions. But in the end, the most intelligent entity on earth is still the user. Yes, we can discuss about AI and Deep Blue being Chess Champion. But my statement still holds.

Yes, it is all about decisions. But that does not imply, that the decisions need to be automated. Some can. But often the business process should push the necessary decision to the user.

And to allow for intelligent decisions, it is crucial to allow for enough decision alternatives. This may sound simplistic in the beginning. But it is not. Bare with me for a moment.

So what is as simple as an approval? Approve or Reject. The simplest decision in the world. But not so simple. Of course, if only Approve or Reject is modeled / implemented, then what should the user do, if he wants to do something else? What else could a user do other than Approve or Reject? He might want to send it back to revision for example. Another user might want to change the underlying approval object – what influence does this have on the process? A realignment of the process is necessary. What, if an approver wants to merge several approvals into one or if he wants to split one into several. Partly Approve. Partly Reject. Partly Edit. Define new Followup – Approval. Change the Approval Type. Merge unterlying objects. Split them.  And Realing the Process. Or substitute the Business Process by an equivalent different one. If you only begin to think about it, then you can hardly stop. And if you think, what that means for a process model, then I would say this is a real challenge. Certainly far more than giving only two branches: Approve and Reject.

So in my opinion adding intelligence to business process means also adding flexibility to the business process, that allows for more than simple alternatives for the user and to push decisions to the user. And to allow for automated decisions to be overruled by the user in many cases.

In Procedure vs. Process it is discussed from the angle of if it is a sequence or order of action or not sequence or order. Also Merriam-Webster dictionary is cited to say that a process is

a series of actions or operations conducing to an end ; especially : a continuous operation or treatment especially in manufacture

I fundamentally disagree with this definition. In my opinion the series of action is only one half of a process. The state is the other half. A process must always have a defined state. Either it is not started, it is finished or in the middle – in process. If it is in process, it needs to be further defined, what the detailed state is. So if a process is modeled in terms of actions, then the question is, which state do the individual actions have.

In the Blog Column 2 – links for 2009-02-02 we see the statement that refutes the difference between process and procedure as claimed by Procedure vs. Process . For my taste this is a little bit a too technical discussion.

I rather approach it from a little bit different angle. For me a busines process is the sum of all business objects and process objects that are needed to achieve a common busines goal, their state, their actions and the constraints between the actions and the state.

You might argue, that I define process by process – i.e. business process by process object. But they are different. Process objects are like workflows and have a rather small business goal , but a business process has a much broader scope. All process objects are small business processes, but not vice versa.

By such a definition I exclude such things like interactions with the system, because they do not have a state. So adding a sales order, saving it, adding another sales order and saving it is no business process by this definition, because it has not state and it does not achieve a common business goal. A business process would be to deliver goods which have been ordered by customer orders and bill them, and collect payments for them. This is a common business goal and the whole process has a state which is reflected in the state of it’s business objects, namely the customer order, the delivery, the invoice and the payment.

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.