Frank Michael Kraft's Blog

This is my BPMN 2.0 Overview Map.

It shows a Choreography model in the middle, Orchestration with public Processes and private Processes, that belong to the public Processes.

Systems integration is the realization of the underlying business processes. This sounds so simple. But in reality there is often a misalignment between the business process design and the systems design. It is the wrong way to just implement business processes, that are as they are today or that are designed without discretion of the principles of loose coupling.

Often system designers need knowledge about how business processes work, but on the other hand business process designers need knowledge about how system integration works. As long as both sides are willing to learn and willing to share the knowledge, it is possible to come up with common principles of modeling, that avoid the most common mistakes, that lead to project cost overrun or failure.  I say it clearly what I mean: using BPMN 2.0 choreography modeling language in itself is no gurantee for success. But: It is a VERY useful tool for the communication between the business and system experts, which is a necessary condition of success.

So in other words, it is necessary, that the process design follows the principles of loose coupling of business processes. That is no design task, that can be solved by system designers alone, if the business process is modeled in a tightly coupled way. In other words: If the business process is designed in the right way – in the loosely coupled way – then the system design is without a hitch. If the business process is designed in the wrong way – there is no way to save the project on the system design level.

So are business experts forced to design business processes different, just to make the job of system designers easier? No. If it is designed that way, it is a better business process. It would work even better even if there was no system, but just paper and phone. It is more tolerant to errors. It gives the individual more freedom to decide. It makes it easier to reach the goal. Yes, it requires a little bit more brain power than just modeling the sunny day case. But in the end it pays off abundantly.

And in my eyes this is good news. It is NOT the system programming that dominates the design and dictates the constraints. It can be the business process needs again, that prescribe the way to go. And that is why BPMN 2.0 is so helpful, because it starts with the business process model.

Some words about the BPMN 2.0 process as I personally percieved it.

I found the collaboration between the companies very productive. Often some have a hidden agenda or have prejudices. In this case I can testify, that I personally did not perceive such a thing.

Of yourse every company has it’s worldview. I found IBM had the strength in workflow technology and metamodeling. I found, that Oracle had an especially deep knowledge in message exchange. And SAP had extensibe experience in business processes and their modeling.

There were strong contrary positions, due to the fact, that there were two different consortiums that prepared a submission.

• Adaptive, Axway Software, Hewlett-Packard, Lombardi Software, MEGA International, Troux, Unisys.
• IBM, Oracle, SAP AG, and Unisys.

There was a collaboration of project management level and the assessment of a common submission. On the concept level there was the discussion of BPDM (Business Process Definition Metamodel) should be the unterlying meta model or not, a 2007 OMG standard for a general exchange format for processes.For IBM, Oracle, SAP a native BPMN metamodel with possible mapping to BPDM was the course we chose.

But there was a very productive part in this controversy. Because members of the other submission team joined also our discussion, our discussion was much enriched. Especially the contributions of the NIST (National Institute of Standards and Technology of the US) revealed many special cases that can happen during message exchange, that were not previously in the discussion. I found that especially inspiring, because I had encountered many of these special cases previously in my architecture projects. That was about the same time that I joined the discussion in more detail. However within the BPDM approach I found some pre-determinations that I definitely could not follow. For example I could not agree, that temporal relations (i.e. that message has to be earlier/later than that messate) should be the main way to describe relations, because in my opinion mere temporal relations do not sufficiently describe cause/effect relationship or constraints between exchanged messages. However there was a significant openness in the discussion that allowed us to find compromises that could achieve very good advances to adress use cases. I personally had significant objections to the choreography modeling. However they could also be resolved – not so elegantly as I had wished – but resolved.

However this was a very interesting discussion, that was not fully completed within the scope of BPMN 2.0 and that I hope I can follow up in the near future.

In the next blog post I will go into details of the my view on BPMN 2.0 and the new modeling possibilities that it offers.

Some reflections about the WfMC Thought Leadership Summit that I was invited to attend.

Suddenly I felt like in a lively discussion about what I thought for some time about the inflexibility of BPM models (what if the approver is on leave?), the ad-hoc nature of real processes (like in a court trial) and the small amount of system support for these.

Yes, Business Process Modeling to a degree rests on the assumption, that there are repetitive procedures that are triggered by a business transaction, and which is described in terms of which steps to execute as a result of it. Like a machine.

Did you ever wonder why there is so little standard software for startups – or business process models? If it where a standard process, it were not a startup. The driver in the seat hopefully is the founder of the startup, not a process.
I agree to the observation, that there are much more processes like this all over the place. And maybe there should be even more again, reverting the feeling to be but a cogwheel in the engine, but a responsible contributor – even for the benefit of the whole.

Still, what we need to work effective is system support for

• our information
• Collaboration and Communication over the information
• a clear status of all of the process and all parts of it
• Decide about next steps as you go
• Decide about required information as you go
• Decide about groups and access policies as you go
• Decide about information structure as you go.
• Overview and Tracking

Only to mention the most important ones.

This is not what you can to with BPM . Therefore we need a new breed of software which is not BPM, even if it is related to it.

I want to mention two things, that were not or not deeply discussed in the meeting as an additional contribution and defence of what I said.

First: Even with all the ad-hoc type of processes it is clear that over time some of them evolve in standard processes, which is a good thing. Because that is the time to earn money for the process owner. So there must be ways to

• pick best practices and develop them into standard processes
• re-design a bunch of local best practices into a global standard process.
• impose constraints of a standard process on the business

All of that as you go – i.e. without interfering the running processes.
Which is easily said – sounds a little like marketing buzz – but certainly challenging in terms of technology. But I wouldn’t say it, if I didn’t think it’s possible.

In Process design and re-design I disagree here with Max J. Poucher’s more philosophical statements about evolution. I do not believe as much in evolution as an unguided process as he seemingly does. I believe that redesigning processes as a whole makes them more effective, and more rewarding to everybody if done right.

Second, I think that we need is a seamless integration (A word that you first learn in marketing) with structured processes – be they classical workflows or classical ERP processes. In my opinion there is much ROI to be found.

Related Blog Posts

Adaptive Case Management by Max J. Pucher

Complex Adaptive Business Process by Max J. Pucher

Ad-Hoc Processes by me

Intelligence in Business Processes by me