Usually I leave the predictions to analysts and prophets. That’s because it is so much work to achieve, what they already have predicted – or to find out, that it did not work.
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.
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.
Why I am looking at these MDA papers?
It is inevitable in big organizations, that there are central processes that are supported by every part of the organization. But at the same time it is desirable, to support individual processes, that respect local specialties. In this case the local units must be given the possibility to plug into the global processes. This can only be done, if the behavior of the local and the central processes is known – and by this the interaction – the choreography between them – can be defined and described. Therefore it is important to have behavior modeling languages for processes of units and of the choreography. Furthermore sometimes it is necessary to allow a local unit to describe their own processes or aspects of their own processes in their own language – a DSL – and plug them into the central processes.
If this is achieved it is a controlled powerful local flexibility with the integration into centrally controlled processes.
All of these articles and also BPMN 2.0 can help to strife towards this goal.
