Camunda Reviews

We have an event-based architecture and Camunda works as an orchestrator for our microservices.

Over the last three years or so, we have been using Kafka a lot. We wanted to bring in an orchestration engine to integrate seamlessly with our nesting system. We had a lot of existing applications that are not that old, and we did not want to rewrite software components that we own to get the benefits of orchestration. That was where there was a need. One of the factors that will decide if we will use it for more use cases at our company or not, is the ease of integration.

As an organization, we don't want to reinvent the wheel, so it's important to us that the connectors are available out-of-the-box and reusable. We don't want our developers to write boilerplate code. Having the connectors ensures that we have standardization in the way that we are integrating with other parts of our ecosystem. It also allows us to put some best practices into those standards. For example, we can implement three tries for a connector. That helps us be declarative. It provides a good tradeoff between low code and no code.

It has a ubiquitous language across stakeholders. When we are talking to stakeholders about how a process evolves over time, or about the complexity of a process, it's a lot easier to explain without having to go through Confluence pages or through a lot of sessions with product people explaining to them how a particular system works. They have a good amount of understanding by looking at the process diagram. That really helps me, personally, in communicating with them.

We have also been able to build out dashboards for our asynchronous processes. Those dashboards have been really helpful. Otherwise, we would have to rely on the data analytics team to provide us with any analytics data around the events that are flowing in our system. Now, for some of our purposes, we can build dashboards ourselves using Camunda.

In addition, we have built dashboards that show important statistics about our business process and key changes that happen in our process definition. Those changes communicate a business value to our business stakeholders. For example, in the last seven days, how much traffic have we ingested into our system, and where has most of it gone? That kind of information is now more of a self-service for everyone. The dashboards we have built are giving us a good amount of information about what's happening in our systems. We are also using the BPMN designs for our design discussions with the product team.

We have been more agile because we don't now have to keep the Confluence documentation up to date. When you put something in Confluence, it's hard to keep it updated and make sure that it's up to date with the latest implementation. Now, the business process flows are code. They are modeled as BPMN files, so we don't have to make extra effort to maintain the business process. And while we are discussing our product, we can communicate how the small things that are part of a process could build up and what role they are playing in the overall process. It also helps us find out, if some part of our process were to fail, what impact it would have on the overall process execution. That's something that teams have recently started discussing more.

Since day one, our goal was to build reusable components that can be used in other projects. We recently did a discovery for one of our projects and we found that we could reuse 80 percent of what we had developed on the Camunda platform. The microservices and the connectors were reusable and that really reduced the development effort drastically for that use case.

We are now spending more time looking at the bigger picture, and not just looking at a particular microservice. The developers can now see where their microservice fits into the flow and how their microservice responds, whether in a successful manner or in failure.

The integration with almost any language, product, and even human tasks, is valuable. It's very seamless to integrate into existing systems. It doesn't require you to rewrite a lot of your existing system. That's where it really stands out.

We have used a couple of connectors, including the Kafka connector a lot because we have mostly a Kafka-based architecture. The connectors are really seamless. They just fit in. They don't require you to make a lot of changes to your existing infrastructure. That's what connectors are primarily meant for, to enable enterprise-level integrations. We also build out custom connectors for our use cases.

In addition to Kafka, we can easily integrate it using any microservice or legacy microservice. All you need to do is include their library and put in a couple of annotations on your existing methods, and they can act as Camunda workers. You can transform your existing code into Zeebe components and that requires very minimal coding. We are also working on building more connectors, and that will smooth out further adoption of this technology within our ecosystem. We can orchestrate almost any remote system if it's accessible over the network and it implements any protocol. If it's reachable, we should be able to orchestrate it via the Camunda platform.

In terms of its ease of use for engineers, it's pretty easy. We have an engineer who joined us two weeks back and he has been onboarded. He's able to make changes in the BPMN. That's very important for modifying business processes.

We have been using Camunda Platform for a little less than one year.

We anticipated the load for one year, at least, and we have done load tests. The system is pretty reliable. We have not had even a single issue in production using their product. It's very reliable.

It is very scalable. It's built on a similar architecture to Kafka, which we know is a very scalable platform. The scalability has been one of the most important features that they have designed their product with. They had scalability in mind from the start. 

We have tested it for thousands of process instances per second. There are some blogs from Camunda that show it even goes to millions of process instances per second.

While it's very scalable, it would be great if auto-scaling capabilities were added to it. We haven't seen any issues in production related to scalability, but one area that really could help out would be to have dynamic resizing of the cluster. Right now, you have to do capacity planning. You plan for the capacity that you need in the next couple of years and then size your cluster accordingly.

Having said that, I haven't seen problems with the product so far.

I would rate their technical support a nine out of 10. The one thing that I feel there could be more of is their exposure to AWS. I'm not saying that they don't know about AWS, but I think a lot of their customers are using Google Cloud. I think they, themselves, deployed it on Google Cloud. But AWS is the market leader and there are a lot of customers on AWS.

Positive

We have used AWS Step Functions.

They provided help charts, so it was pretty straightforward. But when you want to tune it or run it on an enterprise level, you will want to try out a few of the parameters they have provided, and play around with them, to ensure that the software components that your cloud provider has can be used smoothly for deploying Camunda. Initially, you might have to make some effort to set things up on your own cluster, but they have good documentation and help charts for deployment on your Kubernetes.

We have different environments, including development, testing, staging, and production. We could even implement a CI process for our workflow instances and BPMN files, as they can be deployed using a CI/CD pipeline. Microservices can be deployed at their own pace in a CI/CD pipeline. That was the strategy for deployment.

We did it in-house, but we did use some consulting from Camunda during some of our initial days. One of their solution architects was really good in terms of technical knowledge. He knows the product really well and he guided us through some of the parameters and tuning of our clusters while we were deploying.

In addition to me, we had one more person doing the deployment. One of our senior people took care of the deployment on our side. I was overseeing things but he did most of the work.

So far, we have been very pleased with what we have achieved with Camunda. We are still within our initial one-year contract but we have seen value from it.

In the use case where we were able to reduce 80 percent of the development effort with reusable code, that equated to man-hours that are directly related to cost. If you reuse code for more use cases, the cost can be justified.

We have an on-premises, self-managed installation because of some internal decisions. There is a bit of scope for improvement in how the licensing and pricing are done. They are based on the number of processing instances you execute on the cluster. They have two modes of deployment, one is their cloud version and the other one is the self-hosted mode. For the cloud version, it definitely makes sense to have it based on the number of processing instances you run, but on the self-hosted mode, the pricing model should be customized. If it were customized a bit more, it would be better for us.

We purchased their workflow engine, Zeebe, and consulting. We also operate the tool with which you can monitor your process instances. There are a couple of more tools available in their product suite, but these three aspects were most compelling for us. If we are running mission-critical workloads, we definitely need support if things go wrong on a given day. We need their expertise, so the consulting is very important for us. The workflow engine itself is also very important, as that is why we evaluated Camunda in the first place.

If data privacy is not an issue, then definitely go for the cloud version of Camunda because then you don't have to worry about managing the cluster and capacity on your own. It's more seamless than having to manage your own cluster. But if you're considering upgrading from the free version, the consulting is definitely important. They also do BPMN consulting as part of the contract. You can ask for BPMN reviews and you can ask for sessions with their solution architects. They also have a 24/7 hotline that you can call in case there are any issues.

They have an excellent open-source community. I have not seen many other forums that have developers who are as active as Camunda's developers are on their forums. The technical advice that we get from Camunda is really helpful. They know best about the product they have built over the last few years. You definitely need to have expertise on a product that you're thinking of using. The people who have built it provide a great additional value.

We did take a look at some of the options available in the market, solutions that allow you to do process automation, including Cadence/Temporal.

We selected Camunda due to a few important reasons. It's a product that solves a problem that many organizations don't even realize exists in their architecture: visibility. It gives us visibility into the complex processes that are often implemented in software or if some of the tasks are done by humans. Camunda, with its integrations and great tools for reporting, like Optimize, allows us to see where the bottlenecks are in our processes.

It also has companion tools, like Operate, that allow you to visualize the flow of a particular business process. And you can find some really cool statistics about how much of a process is actually done or where it is blocked. Those are some of the really important features that any workflow orchestration or engine should have, and Camunda supports them pretty well.

Take a look at their co-founder and CTO, Bernd Ruecker's, blog. He has a lot of good write-ups about the platform where he explains the technical architecture. He talks about how to do performance benchmarking.

Another good piece of advice is to leverage the Camunda community and forum. Their team is very active on the public forum and they respond to your questions within a day, most of the time. They give very to-the-point answers. That is a really helpful resource. They also have a good set of tutorials on BPMN in what they call the Camunda Academy. It's worth taking a look at that when you are adopting the Zeebe workflow engine, which is their primary workflow engine.

One of the important things that we want to deliver is enabling business, developers, and operations. It's important that our non-technical stakeholders don't have to get into the nitty-gritty details of technical implementations. They can have a bird's-eye view of what's happening in a process, and they can suggest or even extend a process by themselves and then hand it over to us as a requirements document. That's the direction we really want to take. So far, the product team has been very enthusiastic about it. They like it. Camunda uses a language for modeling called BPMN and it doesn't require you to be a coder or an engineer. It's a simple drag-and-drop tool. It's really cool and it helps our stakeholders to be involved in working with workflows.

There is a bit of a learning curve with BPMN. It's an industry standard, not something proprietary to Camunda, but Camunda hosts an online academy where they have tutorials about it. They have videos and free courses on how to use BPMN. That helps out in the onboarding of users.

We have been using it for a little less than a year, so our entire organization is not using it. We are really into building our experience with Camunda by applying it to a few use cases. As we see more use cases in other parts of the organization, what we have built over this past year as templates—as reusable software—can be leveraged so that they don't have to set up everything from scratch on their own.

Our deployment is not live yet. We are in the process of building it.

We make basic use of this solution. It is embedded within a code module that requires workflows. Essentially, Camunda is used to keep track of workflow activity. So, we're not making massive use of it. Rather, we're making use of it as an embedded microservice.

The most valuable features are that it's lightweight, can be embedded in existing Java code, and keeps track of the workflow state and the instances that we need.

The development team had a lot of issues at the start. Guaranteeing the execution times that it will work to is difficult. It's an embedded state machine, although it doesn't give you guarantees of when it will update the state. It can be quite difficult because you can get into timing issues, which is a real pain to sort out. We were able to resolve this by writing a wrapper around it. You have to be very certain that the transactional integrity is provided to the API user.

In the future, I would like to see better transactional integrity.

We have been building the Camunda Platform for approximately two and a half years.

We use it on a daily basis and apart from the timing issues, we haven't had any problems. We have been doing a lot of heavy testing because it's a big, National system.

Scalability-wise, it's fine. It sites within the Kubernetes nodes and scales with those.

I am the technical design authority that chose the product. A whole team of developers is working on it. As it's not live yet, the users are testers and developers, and there are approximately 40 of them.

When it goes live, there will be several thousand users, but that won't be until next year. In terms of expanding usage, potentially, we might because there are a lot of workflows that we could map out of the current one. The one that we are doing now is quite complex and we needed to embed the service. Potentially, it could go across the whole of this business area, which is something that we are thinking about.

We contacted technical support when we had the initial problems with timing, and they were below average. We ended up having to resolve the problem ourselves by writing a wrapper.

We did not use another solution prior to this one. It was all greenfield development.

Camunda is easy to set up. The initial setup was fine until we had an issue with execution times not being guaranteed. That took quite a number of weeks to resolve. 

We developed this platform on-premises and we deploy through AWS.

We brought some people in to assist with our implementation. They were supposed to be experts, but they weren't that great. They wanted us to make much wider use of it, and we only wanted to use it quite in a small way. So, we paid for a bit of consultancy, but then we didn't keep them on.

They were typical London consultants. At £1,800 (approximately $2,400) per day, they were ridiculously expensive.

It is only a small team that maintains it. Right now, we only have one person for that.

We are using the open-source version, free of charge. We didn't bother with the enterprise features. We did look at the enterprise features for the MI component but we ended up writing our own.

More than two years ago, we did a lot of work evaluating Camunda and other products. The two other solutions that we looked at were Pega and Appian.

Pega and Appian were much larger than Camunda, so they didn't meet the criteria of being lightweight. They had a lot of features, which is something that we took into consideration. However, if we were going to extend it to all of the other workflows then these other products were not quite right.

My advice for anybody who is implementing Camunda is to pay attention to transaction integrity. The biggest lesson that I have learned from using it is to do a little bit more architectural spike work before committing to all of the development.

Overall, it is a pretty good product but there is room for improvement.

I would rate this solution a seven out of ten.

Camunda has streamlined our automation processes, particularly in decision-making and BPMN modeling, reducing manual intervention.

The platform's approach to BPMN modeling is straightforward and versatile, making it easy to adopt and use effectively.

I've been using Camunda for about three to four months.

We haven't encountered any software bugs so far in terms of product stability. 

The platform is capable of scaling from small to complex applications.

We previously used Bizagi but switched to Camunda due to its superior BPMN and DMN modeling capabilities and better integration with other applications.

Initially, installation was challenging, but recent improvements have made it much easier. Following the Camunda website's instructions, we completed the setup in less than an hour.

We implemented the platform in-house without involving third parties, but we're considering future integrated applications with external software like UiPath and chatbots.

The product's robust toolset and integration for BPMN and DMN modeling makes it a worthwhile investment for our organization.

The product integration between BPMN and DMN is a standout feature. It eliminates the need for additional software and simplifies decision tool development.

We used the solution in quite a simple manner. We were disappointed that the dictionary was missing. The hierarchy could not be shown, defined, or structured the way we like. We did not use all the features. I have used BPMN Modeler.

Camunda is really useful. That is why my colleagues and I use it in the company. The solution is useful for small projects.

The product does not have a dictionary. The tool must enable users to build or design sub-processes. It must provide a more convenient and easy way to define sub-processes.

I have been using the solution for five years.

The tool is always stable. We have no troubles. I rate the stability an eight to nine out of ten.

I rate the tool’s scalability a five out of ten. We have ten users. The product is used once or twice a week.

I rate the ease of setup seven to eight out of ten.

We use a community version.

All the business process management tools are quite similar. We have to get used to each application's individual ideas, thoughts, and intentions. We use BIC for our organization and Camunda for the projects. It is easier to use Camunda for small projects. Signavio is also a competitor.

It's not possible for us to define a process as deep as it is necessary to automate it. We tested but did not use DMN capabilities. I will recommend the solution to others. I just finished studying business process management. Overall, I rate the product an eight out of ten.

We use the solution for various application workloads, including the workflow for account management applications.

Process BPMN is an important feature where you can write your code.

The latency of API could be decreased.

I have been using Camunda for two years.

The product is stable.

The solution does not have high scalability. It can be useful for complex types of projects.

I rate the solution’s scalability a seven out of ten.

The initial setup is difficult to adapt. It takes two to three days to complete.

Camunda has saved around 30-40% of developers’ time, increasing their productivity.

Overall, I rate the solution a nine out of ten.

We use the Camunda platform for workflow management.

The architecture is good because it's a headless workflow. I can create my own frontend, and it's fully API-based. Our approach is more flexible, so I can use the Camunda API to generate my own workflow blueprint. 

Additionally, it's cloud-ready as we have deployed it on the Kubernetes container platform, which aligns with our cloud-first architecture. These are the aspects we like about Camunda from the IT side.

Camunda lacks sufficient dashboards for operations and reporting. Although I can create dashboards and reports using the provided framework, it's not as enterprise-ready as some of the competitors in the market. They offer ready-made dashboards that are easier to create compared to Camunda. That's an area where Camunda can improve.

So, in future releases, I would like to see better dashboards.

I have been using Camunda Platform for a year. 

I would rate it around seven out of ten. We haven't encountered significant issues or unavailability of services.

In my organization, at least 100 users are using this solution. I would rate it an eight out of ten in terms of scalability.

It requires maintenance such as patching and other regular tasks.

I would definitely recommend it. 

Overall, I would rate the solution a six out of ten because Camunda does not provide a prebuilt interface. I have to develop it myself. To provide a comprehensive product to my business users, I need a frontend. The frontend provided by Camunda vendors is very basic. Most of the vendor's customers develop their own UI or frontend using technologies like React, React Native, or JavaScript frameworks. 

So I rate Camunda Platform a six out of ten due to the incomplete delivery of a frontend. Without a proper frontend, the business cannot effectively use the platform. This is an area where I'm still exploring how well the competition performs. That's why I'm giving a slightly lower rating. However, in terms of orchestration, API capabilities, and cloud compatibility, Camunda is very good.

I have used IBM BPM and Newgen in the past. We are still using IBM BPM alongside Camunda.

We're using Camunda as an SI integrator. We are currently working on becoming partners with Camunda but for now, we're customers.

Camunda provides an easy way to integrate with the architectural environment and it offers us flexibility.  

I'd like to see a number of preset features and configurations included in the solution to make it more of a plug-and-play kind of product. That would help us in terms of our customers. 

We've been using this solution for six months. 

The solution is stable. 

Camunda is not a huge company and they haven't yet reached a critical mass of users but the customer service is good and efficient. 

In my previous job, we used Appian and I've also used IBM BPM. When I switched jobs I chose Camunda because I found the initial setup to be easier and it's very user-friendly for the projects I'm working on. In some instances, it might not be suitable such as in a bank where there are over 300 processes. In that case, IBM BPM might be a preferable solution, but I don't see much advantage. 

I was responsible for the deployment; we had one person dealing with the structure and another for the implementation. The initial setup was straightforward and fast. Everyone in the company uses it, we have around 200 employees. 

We've seen a return on investment in terms of processes and that was apparent quite quickly.

There's a community version where you only pay for the support or you can choose the enterprise version depending on your needs. 

We evaluated Appian for my current job but it's less beneficial if your aim is to have your customers at the front end. We took the middle road when we went with Camunda and the flexibility it offers is a big advantage for us. Appian and IBM don't provide a community version and for the enterprise version, Camunda is an affordable solution. 

If you're looking for flexibility, this is the solution. There's no super bullet that does everything but the flexibility Camuna provides is a good start. 

I rate this solution eight out of 10. 

We ran two proofs of concept, but it was on internal processes. Both processes were related to the human resources area. Right now, the IT central area is working on a service to optimize using Camunda.

We use the community version, and we use Cawemo Platform to start modeling and involving the areas. We pass the models to the IT central area, and they go on with the job. I work for the government of my state. I work in a central area, and we work with BPM, so we were trying to find a solution for automatization. That's when we found Camunda.

We are trying to transition the environment and trying to see the use for it in the future, but right now we are running one project specifically.

When we ran our first proof of concept, we had some aid from an external company called Memora, which is a representative here in Brazil. They have high-quality technicians. The first project was really a success.

We don't have specific key users because we are trying to understand how to use the solution in order to provide public services for the citizens of our state. They are solving some technical issues and trying to integrate the solution with our internal IT environment.

The idea is using the community version in order to provide public services, but not all services, because we have a traditional program system development. They are considering buying a local tool, and they are considering Camunda Platform.

We are using the newest version of the solution.

We like the idea of working with Cawemo because it enables us to keep on working, remotely or not. It allows us to collaborate between areas. It's easy to model and easy to use. It's a great tool for communicating at the beginning of a project.

The business model could be easier to understand.

We started using Camunda at the beginning of 2020. We started researching and using the Cawemo solution for modeling, getting the idea, and knowing the environment. That's when we decided to run a proof of concept. It happened in the middle of 2020.

During 2021, we had some issues concerning coronavirus, so things stopped for a while. Right now, the central area responsible for IT restart is considering running another proof of concept on Camunda.

It is stable.

The solution is scalable.

I tried to get some information about buying the license for the solution, but I found it kind of hard to understand the business model. That's why we're currently using the community version.

I would rate this solution 10 out of 10. 

My advice is try to understand and use it because it's really an amazing solution. I only have nice words to say about it. I really hope our central IT area runs this proof of concept, and that it becomes successful in the near future so that we really start offering public services on Camunda Platform. It's easy to use, stable, it integrates areas, and you can use the community version.