Legacy Systems vs. Camunda

Exploring the Key Differences Between Camunda and its Competitors

What are the main advantages of choosing Camunda over platforms like Pega, IBM, or Appian when migrating from legacy systems? 

That’s a really excellent question. There are a couple of very important takeaways.

First, those systems are sort of unified, right? You do Pega UI, Appian UI or you do the code framework in IBM.  What that means is that if you want to change something simple, for example, you can’t just throw one of your first or second year Angular programmers at it — you have to get an expert in that field. Now, that not only comes at a premium, but it’s very difficult to grow in house. You have to go and make sure that they make the changes because they could inadvertently break something else since it’s all unified. 

The second thing is obviously cost. You’re paying so much more for those systems than you would be paying for an open source system, even if that open source system has an enterprise version like Camunda does. 

Finally, you’re just getting much, much better execution. Camunda is a leaner machine. It’s more performance, faster, scales better, and simpler to maintain. Camunda is an order of magnitude difference. It’s just more performance, and that’s not magic. It is not because the Camunda engineers are so much smarter than everyone else’s engineers. The reason is because Camunda, for the most part, really focuses on a pure execution engine. They make race cars, and those race cars go really fast; they don’t try to become SUVs, boats and planes. There aren’t any better process mapping engine out there. They’re really good at executing BPMN and DMN. That’s what they do. It’s all they do. And that, in itself, is liberating.

That makes sense, but the way I see it, it sounds sort of unrealistic to imagine it being an easy process to move to Camunda. Am I right in assuming that? 

Yes and no. You’re right that there is a lot of complexity involved in interpreting a Pega UI as an Angular front end, or a React front end, and then reimagining all that. However, that’s a place where I can be slightly self promotional and say the CapBPM actually has automated migration tools. We have an entire six-year old product line called Exodus. It actually reads the detailed exports of Pega, Appian, IBM, and it translates them into corresponding command code. And when I say it translates them, I don’t mean that it just translates a BPM diagram to a BPM diagram. I mean, it does the UI, events, rules, logic, and so much more. It does the entirety of the process. Trust me, I know it is a big claim, and I invite anyone who doubts it to test it more. 

From our perspective, we are happy to do this on a success-based model, and we are happy to demonstrate how it works. We think that you should have open borders when it comes to your enterprise software, and if you want to go somewhere else, you should not be practically prohibited from doing so from the complexity that’s built into some of these legacy applications. You should explore business process mapping tools that don’t restrict your capabilities.

So regarding Exodus, how does one typically get started with a process migration? 

Basically, we do an interview with you, and then based on that, we work with you to execute a series of steps to create artifacts for Exodus. For example, if it’s an IBM BPM file or IBM BPM project, our tools can parse through that, translate it into corresponding Camunda, and then even test that Camunda using an AI engine to make sure that it has fidelity to the original process. It’s a really impressive process, and I really love showing it to people. I especially love showing it to people who understand BPM, because they’re the ones who are really educated enough to understand what it is that they just saw.