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

The year we crossed the chasm – Camunda review 2014

If you’re interested in Camunda’s journey as a company, or in tech startup journeys in general, this post may be worth reading.

The beginning: Shift a paradigm, sidestep competition and find a blue ocean

In 2012, we created a software product called Camunda BPM. The core value proposition of Camunda implicates a paradigm shift in what Business Process Management technology should deliver:

Primary Target Group Value Proposition
Most BPM-Suites Companies that are trying to reduce their software development force “Our product allows you to create process applications in a model-driven approach, so that you need fewer software developers.”
Camunda Companies that consider their software development force a strategic asset “Our product makes your software developers more productive when creating process applications.”

You can read a bit more about this paradigm shift in Sandy Kemsley’s Whitepaper “Developer-Friendly BPM” and in my own blog post “The Camunda Hypothesis“.

What we did back then was actually inspired by the “Blue Ocean Strategy“, a business model generation approach that recommends to “adjust” your value proposition in a way that it targets a market segment that the traditional players are unable to serve. So rather than battling your competition, you sidestep them.

As always, the reality is not black or white, but a gray area. Which is why we encountered those tradtional BPM vendors of course (mostly those from the leading quadrant in Gartners BPM MQ). But our primary target group was not really happy with them (wrong paradigm, wrong product for the specific marget segment). In fact, by now more than 50% of our customers replaced a traditional BPM Suite with Camunda.

The Power of Open Source for building credibility

But back in 2012, there was another challenge: For a small and young company it’s difficult to sell a product that is supposed to run your mission critical core business processes. Plus, a value proposition that includes a paradigm shift is more difficult to sell, especially when it’s about empowering software developers who typically don’t make the purchase decision.

According to “Crossing the Chasm“, we first needed the innovators and early adopters, those who are willing to take a certain risk in order to try out sth new they believe in. The fact that Camunda BPM is open source helped a lot here, and it still does. In 2013, we had the additional challenge that we forked the open source project that our product was based upon, and created our own open source project. Running an open source project is an art in itself, and it was mission critical that we succeeded (luckily, we did).

Crossing the Chasm – in a certain context

While jumping that first hurdle, we already knew the biggest challenge was yet to come, the “Chasm”. This year we crossed the damn thing.

How do you know that your product crossed the chasm? One indication can be your numbers.

Some numbers

In 2014, we doubled our “subscription volume” (the turnover coming from subscriptions for our Camunda BPM Enterprise Edition), and increased the total company turnover by 50%. As a consequence, the share of our turnover coming from the subscriptions business grew to 60%. The rest is from consulting (30%) and classroom training (10%). Yes, we used to be a consulting agency, but now we’re a software vendor.

Our staff grew by 60%, while our marketing costs were 8x higher than the year before (once you figured out how to create and sell a disruptive product, you need to rampup your distribution machine).

With a headcount of 30 full-time employees, we’re still profitable, thanks to the increased turnover from the subscription business. This means we still don’t need any external funding.

But to be honest, my conviction about that chasm-crossing is more of a gut feeling, and I think that we only crossed it in a particular sub segment of the market we target.

So far, we only crossed the chasm in the German insurance industry.

The German insurance industry is very conservative and tries to avoid risks whenever possible (makes sense, in a way). Nevertheless, more than 20% of the Top-50 German insurance companies now use Camunda BPM for process automation, and mostly for their core business (sales and claim handling). Once we got our first reference customers and made them happy, we had the credibility we needed to win over the first representatives from the so-called “early majority” in this market.

Of course, this is just a tiny fraction of our overall target market. There are still some chasms left, in other industries as well as other geographies.

However, we have proven now that our product and the paradigm it is based upon are compatible with a relevant and representative mainstream market. The key characteristics of the customers in that market are:

  • Their business model is based on IT, and they therefore consider their software development force a strategic asset (see table at the top of this post)
  • They need to scale up their business models with process automation

I am rather confident that we can find similar characteristics in other industries and geographies…

“What if other BPM vendors claim to be developer-friendly, too?”

Oh, they do already (interestingly, they did not 12 months ago). The good news is that this is a value proposition that the according target group – software developers – can confirm (or unmask) very, very easily:

  1. If you can’t get the source code, it can’t be developer-friendly.
  2. If you do get the source code, download it, try it out (proof of concept, build a prototype, what ever) and you will figure out very soon if it is developer-friendly indeed.

It’s that easy.

OK honestly, it’s a bit more complicated. It’s about core architecture principles (e.g. how to “embedd” process engine technology), and about using software development best practices (e.g. unit testing for process models) and a lot more that is implemented deep inside the core of our product and hard to deliver, if your product is based on a different paradigm (model-driven development) and almost impossible if your product is not open source.

But truly, the best way to confirm what I am saying is to let your developers see for themselves.


There is so much left to discuss and consider. However, this is not the time and place to talk about our next steps. I just wanted to provide a status update for anyone who is interested in Camunda.

I think we made significant progress this year, and we owe it to our customers and partners. Thank you for the trust you have put in us and our beliefs.

Personally, I wish to thank our team. My co-workers are the reason I am actually enjoying this journey.

Here’s to 2015 🙂

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

Leave a reply