Camunda Team Blog

The camunda Hypothesis

Written by Jakob Freund on , under Execution category.

Scott Francis has written an excellent post about the core message of our presentation at bpmNEXT. He called it the "Zero Code Hypothesis". Though Scott's summary is completely right in its essentials, I would like to put some details straight:

  • We don't think that "Zero Code BPM" does not work at all - Zero Coding and our approach are both reasonable, depending on what you have and what you need. The real problem is that most of the zero coding BPM vendors claim that you should use their solution for situations where you actually shouldn't.
  • We do not condemn the ideas and ambitions often associated with the term "ACM". Quite the contrary, we even believe that our approach is very well suited to create the according process applications (basically because we already did it).
  • I would not consider our standpoint a counter-point to the movement to make BPM "more accessible" to the business. We just don't belive that zero coding is the right approach to realize that enhanced accessibility. There are other instruments (most of them based on BPMN), that we already successfully validated and incorporated in our approach. But still, just like ACM, this is a field of research. I don't think that anyone could seriously claim to have found the "silver bullet" yet.

But even given these relativizations, we are pretty much off the BPM mainstream with our "camunda Hypothesis":
While there are reasonable use cases for zero code BPM Suites, they are not the right approach for automating business processes that execute an IT based business model. 

A business model is "IT based", if IT is the core infrastructure to create and/or deliver the customer value. Financial Service providers, insurance companies etc. execute IT based business models, while most manufacturing companies, but also doctors etc. don't (though the relevance of IT for business models in any industry is rapidly growing).

business processes execute your business model  (image:

One critical success factor of a business model is its uniqueness, which leads to the differentiation from competition and therefore to the leadership in the respective market (segment). The obvious conclusion is, that an IT based business model requires a very high degree of flexibility in the underlying IT infrastructure. Otherwise, the unique idea behind the model could not be implemented, or, if there would be a (customizable) "off-the-shelf" IT solution for it, it could very easily be adopted by competition - and actually could not have been really unique in the first place. The second dealbreaker criterion is, that the company must be able to create, adjust and maintain that executing infrastructure independently from external parties: A company with an IT based business model must recognize IT as their core competence (which, by the way, also means that outsourcing IT resources would be a pretty bad idea).

Zero-Coding BPM suites (including most of the BPM suites currently available) cannot meet those criteria, but an open BPM platform like camunda BPM does, for the following reasons:

Accurately fitting solutions

"The open architecture of camunda BPM allows us to implement our very individual requirements in a way that a traditional BPM suite just cannot provide." (Zalando, fashion e-commerce)

In Zero Coding BPM, you would implement your process application using certain forms, wizards etc. The inavoidable consequence is, that you can implement anything... that the BPM vendor has imagined beforehand. But as soon as you have a requirement, that does not map to a checkbox, dropdown or what ever in the Zero Coding Wizard, you're lost. This would not necessarily be an issue - as I said, there are reasonable use cases for this approach. But implementing an unique IT based business model is certainly not amongst them.

Since camunda BPM is a (Java-based) open source framework rather than a black box product, you have the exact same freedom during implementation you always have when developing in Java. You can implement everything in the exact way it is needed for executing your business model.
"camunda BPM allows a seamless integration of process automation with non-procedural Use Cases for the case management, so that we are able to interlock optimally structural and non-structural processes." (flightright, debt collector)
The ability to seamlessly combine structured and semi- or unstructured processes is another advantage of this approach, and a critical foundation for any process application that should be considered "ACM-like".

No vendor specific learning curve

"Additionally we can use our existing Java know-how combined with camunda BPM to build quickly and easily lightweight process solutions." (Freenet, Telco Provider)

There are ~10 mio. Java developers worldwide. Think of any available BPM suite and tell me, how many according developers you would find on the market.

Besides the restrictiveness described above, this is the biggest issue with traditional BPM suites: Your IT staff has to learn how do develop your process applications in a vendor specific way. This takes time, and most certainly your staff will never really master the vendor stack, because they cannot completely focus on it while also working on other projects with other technology stacks. In other words: It will be a huge effort to learn that vendor specific way, and if they don't continuously work with it, they will soon forget what they have learned.

As a consequence, you will always depend on the know how resources (consultants etc.) the specific vendor or their partners provide. Not the smartest way to execute your business model, is it?

With camunda BPM, there is no vendor specific way. You know Java? You know camunda.

Zero Coding BPM vendors like to claim that you don't need your IT staff any more, because it's so easy to implement the process applications that the business users can do that on their own. I can just repeat myself: The more individual your requirements are, the more flexibility your BPM solution must provide. The more flexibility your BPM solution provides, the more complex is it to implement your process application. You won't gain anything with a form wizard instead of programming code, if that wizard consists of 25 elements your business user is expected to understand.

The force is with you

"camunda rocks." (Plexiti, IT solution provider)

OK, I am getting carried away. What I really mean is this: If your business model is IT based, your software developers are probably your most valuable assets. And actually they are not just "assets" or "resources", but human beings. They can be incredibly creative and productive, but only if they have the opportunity to flower. Have a look around, at GitHub, at Devoxx etc. There is a whole global movement of extremely talented, enthusiastic software developers who just love to create great value.

You can benefit from that enormous force, if you let them create your process applications in an open, lightweight, developer-friendly environment, that can be enriched with any emerging technology or method (HTML 5 or what ever), and actually makes fun to work with.

"It took only a few days to highly inspire the whole project team (consisting of people from both IT and business departments) for process mapping with BPMN 2.0" (LVM Versicherungen, insurance company)
As I said at bpmNEXT, Business-IT-Alignment is not about getting rid of IT, but a successful collaboration between partners. We know that BPMN assumes a key role here. I would never consider camunda BPM a pure "framework for techies". We strive to inspire both Business and IT, to bring them together and enable them to collaboratively create the process applications they need to execute their IT based business models.

The "camunda Hypothesis" is already proven

"camunda showed true roundtripping between third-party business-oriented modeling tools and a BPMS, the first I’ve seen to do that well." (Bruce Silver, BPMN Super Hero)

A this point, I should probably make clear that our "hypothesis" has already been validated. As a consulting agency, we are in the BPM field for 5 years now (the two founders Bernd Rücker and me even for 10 years). Personally, I used to work for a well-known BPM Suite vendor before I joint forces with Bernd, and working for them as a PreSales Consultant I experienced exactly the problems I have described above.

When we (camunda) finally entered the BPM software market in 2012, we quickly won way more clients than we had expected ourselves. Since March 18th, this product is open source, and there are several clients that agreed to be quoted what they like about it (you have found some extracts in this blog post, but there's more).

We hope that by open sourcing not only our technology stack, but also our know how (we started by publishing half of our best-selling BPMN book, but there is way more to come), we can help others to recognize what actually has gone wrong in the last years of BPM, and how we could bring BPM to the next level of success (or even "crossing the chasm" Paul Harmon has mentioned at bpmNEXT).

I suppose this is some hard piece of work, but I know it's worth it.