What is most valuable?
We like the BPMN notation because it's BPMN 2.0 compliant. We like the out-of-the-box REST API features so we can build a service with Camunda, and instantly it's accessible using a REST interface, and of course, we like the REST protocol because that's much more advanced than SOAP.
The other feature that's highly advertised is the fact it's open source. We have the ability to modify the product if we need to, and that comes in handy whenever we need to add new functionality and features. One popular one is a year-end mapping feature, which is basically mapping a bunch of URLs to label in the tool, which the services can access. Instead of having to hard-code URLs, you can get the service to use the label. That is, you can configure the label in the administrator. That doesn't come with Camunda, but you can build it yourself.
How has it helped my organization?
The open source factor is a big one because we don't worry about feature customization issues. The problem with proprietary products is, if they're not giving you the features you want there's nothing you can do about it. All you can do is ask them to change it, and usually the product vendor is not interested. Even though you're a big client, it doesn't matter. They're worried about many clients, not just one client. So open source is huge.
Another one is that it's quite lightweight. It's much more lightweight than most other tools, so it's easy to code in, and we don't really have performance issues.
Third, using REST APIs out of the box really improves our productivity. You build it it, you deploy it, it's ready, it's good to go.
What needs improvement?
Like all BPM tools, they're very bad with proprietary UIs. In general, anyone who uses BPM tools should not expect to use their proprietary UI. It just works awfully. It's very difficult to customize. You should just build your own UI and have the UI call the REST services of the BPM service.
I've seen many mistakes made by many users of BPM tools where they just use the whole thing for everything. They use the BPM tool for the service, and then they use the proprietary UI for the UI. Next thing you know, whenever they want to customize the UI, they can't do it, or whenever there's a tool upgrade, it impacts their UI. It's just a big mess, and it gets expensive. Camunda could do an upgrade, and suddenly the UI has got a problem, so they have to spend all these man-hours to fix their UI and convert it.
Whereas, if you had a loosely coupled system where the UI is separated, where you just build it with AngularJS or something like that, then you don't care.
For how long have I used the solution?
My team started using it in 2015, so we're going on about 30 months now in app years.
What do I think about the stability of the solution?
It's very stable. We've run load tests, and the only problem you'll have with Camunda is, sometimes, when you marry it with other technology like MariaDB, and you put it under high load, it seizes up. Then, when you go to the Camunda people, they say, "Well, what we're building is a tool. We didn't design Camunda to work with every little, specific product." But you'll find that issue with many BPM tools.
What do I think about the scalability of the solution?
It's very scalable.
The only time we have a scalability problem is when the application team doesn't use it properly. For example, I've seen many BPM build teams, they didn't set up a separate database for their application data. They just used the schema that's supporting the tool engine. When they do that, the more you load up the database schema that supports the tool, sooner or later, the tool starts to bog down on server startup. Instead, they need to put all their application data in a separate database.
How are customer service and technical support?
They're quite accommodating. I've even seen their offices in Berlin, and they're quite accommodating. They definitely go above and beyond to help you out. But at the end of the day, they're going to draw a line somewhere which is usually, "This is a proprietary UI. There's only so much we'll do for you. If you're trying to integrate this with a certain product, well, we never designed Camunda to integrate with this product."
They'll draw the line some, but it's typical for all teams, all tools.
Which solution did I use previously and why did I switch?
ActiveVOS, but it is not open source. That's one of the reasons we switched.
How was the initial setup?
At Camunda they had a subscription service. It was based on how many flow nodes, I think 4 billion flow nodes, and they would give you a one-time fee. You just had to pay it, and you got internal support.
Of course, you can use them without their support. You can just download it and use it, but any self-respecting entity will get support. Where they make money is not licensing. They get it in support because, sooner or later, you want help.
They have various subscription models. One of them is pay a one-time cost, and they'll support you.
Which other solutions did I evaluate?
We evaluated ActiveVOS and, in the past, we've looked at IBM BPM.
What other advice do I have?
In terms of advice, if you're considering Camunda, you must know how to code Java. If you go on YouTube and type "Camunda", or "intro video for Camunda", the Camunda people will tell you, "You need Java developers."
When you go open source, you start to make the product a little more complex to use because they don't have as many wizards, whereas, some people will get away with only knowing scripting. They were able to use ActiveVOS because they've provided a bunch of wizards. You need Java developers to use Camunda properly.
Overall, it's very flexible and nimble.
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Oct 31 2017