I was recently asked if I like this idea: Handle everything, that is coded in an ERP systems today as Process Patterns and instead design it as process models, that can be adapted to the requirements of the customer. The context of the discussion was if the combination of ERP/BPM/SOA would not have tremendous potential.

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.

Within the 4th European workshop on ” From code centric to model centric software engineering: Practices, Implications and ROI” we had an interesting discussion. After a talk about the question, if or if not MDA is practically usable in industrial projects with positive experiences (Fieber, Regnat, & Rumpe), the discussion was about Return on Investment of MDA. The most interesting part of the discussion for me was that there was a complaint about the fact, that until today it was not possible to model behavior effectively. If it were possible to model behavior – as structures can be modeled with UML – then this would be the big thing missing. However the problem was considered to be very difficult, if not too difficult.

That was when I made my statement, knowing about my yearlong successful experiences in behavior modeling. I said that probably the domain chosen was too broad. In my opinion we should concentrate on a specific domain – business processes – and model the behavior of it. That is because to model, it is necessary to know and describe the laws of nature of the domain – in this example business processes – in advance. Then as a result the modeling method will be very effective and successful. I said that for example in BPMN 2.0 major steps forward have been made recently.

We believed that following this approach it will be possible to achieve much better ROI of MDA than in the past. Practically this will mean that it will be possible to provide an application wireframe within days and an application within weeks instead of month or years. Through this productivity boost Custom Software will be cheap to build – therefore companies do not have the choice between standard software or high cost, but they can have what they specifically need at a low price. This is not out of reach.

Reference

Fieber, F., Regnat, N., & Rumpe, B. Assessing usability of model driven development in industrial projects. In T. Bailey, R. Vogel, & J. Mansell (Hrsg.), 4th European Workshop on “From code centric to model centric software engineering: Practices, Implications and ROI” (S. 1-9). University of Twente, Enschede: Centre for Telematics and Information Technology.

Understanding Modeling Element of a modeling language – like BPMN 2.0 – is a necessary condition for successful modeling, but by no means sufficient.

Models must have a meaning within a context in the end, otherwise they are useless. For example what does a model mean, where there are acitivies like “go to the shop” and “buy some milk” and “pay”? It is a modeled description of what a person sometimes does, if he needs milk. But nothing else. The process model is to be used as documentation only. This is the context of the model. Such a model can not be used as a workflow. There is no need to create a workitem “pay” for buying milk. This is done by the shop’s design anyway. Also it can not be a web service orchestration description, because there is no web service “go to the shop”.

Modeling a process makes sense, if the context is know, in which the process will be embedded. The context is what I call an architecture. An architecture is a set of rules that determine under which boundary conditions a software system is to be designed. As part of such a design the design of a process makes sense. For example the architecture could be to design a system that is capable of performing the functionality of a milk web shop, that milk order and milk delivery are business objects that expose web services like “order” and “pay”, that there will be a workflow system that is able to compose these services – for example. The architecture are the rules that describe the creation of the system, the business objects, the web services and the workflow. These first need to be professionally defined and confirmed. They need to be obligatory for the whole project.

Only after that it makes sense to create models, which then will have a meaning within the context of the defined architecture. And therefore it is of very limited merit to “just model” or to train or coach modeling of a modeling language without a reference to a defined architecture or without the preceding process of professionally defining the reference architecture before. On the contrary – if the architecture is defined, then it perfectly makes sense to coach and govern a modeling process, because then there are the rules, that are needed for coaching and governance.

This is my opinion.