For updated content from Camunda, check out the Camunda Blog.

Making the BPMN Roundtrip real

Sample development approach

Sample development approach

Lately we announced camunda fox and presented some approach for developing process centric applications and especially how to get a technical process model from a business process model. Today I want to give you some more insights and explain how it fits in the world of BPMN 2.0 and Process Engines like Activiti or jBPM. And I want to give you a quick example of a customer project with that approach.

Two aspects make this approach completely different from what BPMNS vendors try to sell you today:

  • We do not believe in Zero-Code programming for every problem! Obviously there are problems which can be solved by Zero-Code-Tools, a lot of them not. Not only that these applications sometimes lack a proper architecture, which makes them at least hard to maintain, sometimes it is just simply harder to graphically develop something instead of coding it right away. I remember one software developer at a customer project: “I spent 2 days trying to model that correctly in his f#*= tool, in Java I could have written the same functionality in half an hour”.
  • We believe, that different roles (read: people) need different tools! For me, this is an important point which especially vendors often forget. There is never a silver bullet. Business people like Excel, Word, E-Mail, Browser and so on. Business Analysts may be able to use special BPMN Modeling tools but not Eclipse. And developers are quite happy with SVN, Maven and Eclipse. Hmm, okay, not sure if I am personally happy with Eclipse and Maven, but that is a different story πŸ˜‰

As you may already feel, I talk about projects where Java coding still plays a bigger role. Not all projects are like that, e.g. ECM or simple Human Task Management maybe not. But a lot of projects still do. And for these projects traditional BPMS-Zero-Code-Approaches do not fit!

But how can this approach look like, where everybody use different tools? Maybe you already guessed right, we “just” need a glue between these tools πŸ™‚ This is something we envision with camunda fox! Basically different tools mean different storages, persistence mechanism, repositories, whatever you want to call it. So with the right tool on top, we can link artifacts, create new ones, map them, track changes between them and so on. This allows everybody to use the tool he likes and gives flexibility in the connection between artifacts. The “glue” adopts to you, not you have to adopt to somehing the vendor built in his Zero-Coding-Tool, because he thought this is the right way to work! This is a first step we currently try to go in the direction of Agile BPM.

Sample development approach

Sample development approach

Let me give an example. On the left you see an example approach we used in a project for a software vendor who wants to make his software customizable. First a business process model is developed in Signavio. We used the approach described in our book and modeled three layers, Jakob already gave an example in his last post yesterday. For now you just have to know, that the business process model contains an own pool, where the real automated process is modeled (around that, a lot of other aspects may be modeled: What the people are doing outside of the engine or what other systems may do to fullfill a request. A lot of things normally serialized into a Word requirements document). This pool now is read from the Signavio Repository and copied into an SVN location, where the developer can access is. The developer get it running in its Eclipse and commits changes. camunda fox keeps track and notifies the Business Analyst of changes.

slides to show camunda fox in action

slides to show camunda fox in action (klick on the picture)

On the left you can check the slideset we created to show that in action. Let me add one remark: In the current projects and the slides we used jBPM as Process Engine, which is still pretty powerful and really rocket stable. In my eyes having a non BPMN 2.0 Engine isn’t a big problem here, because we have a mapping between the business process model and the technical execution model anyway. There it is no problem to translate to jBPMs language jPDL, because it supports everything we need from BPMN (which makes it different to BPEL). And we can even hide a lot of conventions and patterns in the mapping, something I have to blog another day! Ah yeah, but Marketing doesn’t want to hear not using BPMN 2.0. Nowadays it has to be BPMN 2.0 πŸ™‚ Okay, no problem with that, currently we are of course integrating it with Activiti, so the technical process model will be BPMN 2.0 as well.

JAX presentation of 1&1 project

JAX presentation of 1&1 project

The whole approach now leaves a lot of freedom. At 1&1 (a big German telecommunication company) we used it slightly different: We created the process model by Reverse Enginnering! The process was already implemented and running. It was available in an own XML dialect for a home grown process engine which was replaced by jBPM in that project. So we found the truth in this “code” and started to develop a technical process model for jBPM and used JUnit to check, that it was still working as expected. With the Mapping from camunda fox we then created a BPMN business process model. And surprise: It was immediately readable by business folks! It was basically just aligned afterwards to some modeling conventions. Now, technical and business process model are in really in sync! Unfortunately I cannot post the images here, but you can get an impression in the slides we had on a talk at the JAX conference, which are linked on the left.

On top of these experiences we already used this approach in our jBPM 4 trainings. It felt right and we got really good feedback πŸ™‚

I want to sum up with a quote of my colleague Jakob: “Our ambition is to show with camunda fox a new way of BPM, which is both developer- and business-friendly. And this is not about zero-coding, which is actually the old waterfall-philosophy that never worked out. The approach we believe in is an agile one, giving business and developers the appropriate tooling and new possibilities to collaborate with each other. ‘Bridging the gap’ is all about communication, not getting rid of programming or, the real vision of the ‘old’ BPM-fraction, getting rid of programmers”. So I am really looking forward to the first official release of fox and my fingers are itching to write more about it πŸ™‚

Already read?

Scientific performance benchmark of open source BPMN engines

Why BPMN is not enough

Decision Model and Notation (DMN) – the new Business Rules Standard. An introduction by example.

New Whitepaper: The Zero-Code BPM Myth

4 Responses

Leave a reply