Camunda Reviews

Our primary use of ECS is to host all our services in the cloud. We work in the legal sector, and our workloads are often deployed on Fargate containers or Azure containers to abstract the hardware.

EC2 makes scaling horizontally incredibly easy, especially when working under the ECS service. Nowadays, I almost never need to create instances of virtual machines because most workloads can be deployed on Fargate containers. This abstraction of hardware reduces the need to think about it. 

My costs are reduced. Working with ECS and Fargate doesn't require saving processing units for idle services. Previously, using EC2 required keeping entire virtual machines running, however, Fargate eliminates this cost. ECS also allows for horizontal scalability with thresholds that can be configured for CPU or memory.

It is usually used to orchestrate or automate flows of interaction between our systems. It is basically for integration. For example, for a permit that needs to go through several systems, in Camunda, we have a business process that orchestrates all the steps where the permit needs to be processed. All the systems are notified of this permit, and if there are people who need to interact with a specific permit, they get notified. They can then take action. That's the kind of use case for which we use Camunda in our organization.

For myself, the use case is similar, but it is for invoicing. When we receive an invoice, we need to process it. It goes through the business process. There are a lot of business rules that are applied to it. For example, we will check whether the total amount is balanced with subtotals and tax, and if that's not the case, with Camunda, we can create what's called a user task. It allows us to make an agent to take care of this invoice and fix the data that is related to it. These are the use cases that we are trying to achieve with Camunda. The goal is to clean up the invoice and make sure that the information related to it is correct so that it can be transferred to our ERP to pay suppliers.

It is on-premise, and we've been able to put it in a Docker container. It is deployed in Kubernetes in our organization.

The main benefit is automation. When you don't have such a tool, you take a business process and try to interpret it in terms of code. You don't have visibility. Camunda helps an organization to see the process. If you see that something is wrong in your process, you can easily adjust it to fix the issues. There is a tool that comes with the Enterprise version of Camunda that allows you to see where most of the tasks or processes are merging in your business process. So, you can update and optimize that. If your organization uses Camunda to automate processes, you can have enormous gains from that.

It is a great tool. It was our choice to use it. It works well as a universal process orchestrator for complex business processes. It allows us to focus on the business process itself. If you want to orchestrate multiple calls to external systems and you want to be sure that all the systems are notified, it works great. My use case was more business-oriented, and it worked great for that. As a universal orchestration tool, it is good and powerful.

It allows business users to create, update, and execute complex workflows. This is important for us. We are more project-oriented, which is also the way most organizations work. We have a lot of developers during the development, but when we reach a point where the solution is built and we are in an operational state, we prefer to have a tool that can be used by the business. They should be able to configure and personalize their solution without requiring developers to do it. They should be flexible and autonomous in doing that, and we in IT don't necessarily have to have developers for that. We can focus on other projects. There are a lot of benefits to working like that.

Its ease of use is important in allowing us to automate processes. For my personal use case, it simulates a type of virtual agent. It allows us to gain greater value because people don't have to work on basic things. Camunda is doing it instead. We are adding great value by using Camunda for small things.

It has the ability to integrate with a variety of automated and digital systems, which, for us, was a prerequisite. It was important because if it could not interact with our system, it would have been hard to automate anything. It would become just like a business process to orchestrate people instead of the system. Therefore, it was important that we have connectivity with other systems. In the version we have, there are no specific connectors. There are more generic connectors, such as HTTP connectors. This might have changed in the new version, but the ability to interact with other systems was a prerequisite for us. If it didn't have this functionality, it wouldn’t have been interesting to use Camunda.

It helps bridge communication gaps between our development and business departments. Because everything is visible, the developers could see exactly what the client is trying to accomplish. To have something that we can see or even touch was interesting. It reduced the gap between two things. Only connectors were a little bit hard to understand for the business people, but developers were there to assist in configuring the connector. They had to work together, but the main focus was on the business, and it helped the developers in understanding what the business was trying to achieve.

Camunda automation has freed up our staff's time to focus on other valued tasks. When we are developing our solution, we have sprints of two weeks. We organize our work for two weeks, and regularly, we have tasks related to the business process and how we need to update it to adjust to some reality. Now, we have people from the business who are doing it, but it is still visible to the developers. It has saved the time of at least one developer for the two weeks because the business is able to work on that alone. We have five or six developers, and now, they can focus on the technical side of the solution.

Before Camunda, we had a lot of people interacting with the invoice daily. We had, for example, an agent who was doing 300 invoice checks and validations per day. With Camunda, those people are now handling only more complex checks and validations. Our processing time for an invoice is reduced from about 30 days to 10 days. There is about 70% saving of time.

We use it in telecom service management to automate and orchestrate our service order flows.

There is DMN (Decision Model and Notation) on the flows, but it depends on how the user interprets the question. If it's purely decision-making, then not really. It's a feature of the platform we use but not the main one. 

The main feature is the BPMN orchestration workflow engine.

We had to look for a replacement because our old tool didn't evolve anymore. Camunda is a further evolution or branch of activity. There are certain branches of workflow engine tools, and Camunda seems to have a lot of traction, maturity, and stability. It also matches the need for agile development. 

In terms of efficiency and execution, we're satisfied. In terms of design, you still need to create the design and give it to someone else, but the graphical user interface is fine.

We only use the engine, and we have implemented our solution around Camunda Cloud.

We have a lot of use cases. In the past, the major use case was related to infrastructure ordering. If users wanted to onboard their applications to the cloud, the whole process was run by us. They would go to the ITSM tool that we have, and from there, the whole process of onboarding the application was run by us. For example, if you required certain access, all these accesses were provided by us. So, mainly, it was related to the infrastructure processes where you order something and have to talk to AD, Exchange, or other kinds of infrastructure products and systems you have in the company.

When I compare the old legacy platform to the current one, the number of incidents has reduced massively. Our platform is much more stable. We don't have the issue of any bottlenecks. In almost a year since we migrated all the workflows, there have been a limited number of incidents with regard to the platform.

It has definitely saved time. Due to the fact that we have fewer incidents, people were able to concentrate on platform improvements and automation of the platform itself. We are trying to automate as much as possible from our side. We could focus on improving Dev backups or CI/CD. We also improved a lot also with regard to implementing or POC'ing new features. We have much more time now to focus on new solutions that we can offer to our customer base.

Our team is called Oasis, which is a short form for Orchestration and System Integration Service. It's sort of our core that we want to integrate all the systems and orchestrate on the system. That's one of our key selling points. We have a team that has knowledge of most of the systems and how to integrate them. Camunda enables us to integrate, but the actual work is done by our team. All the brain power comes from the team.

We were able to cover all the use cases we had in the past. We were able to integrate with legacy systems, and we are also working on cloud-based solutions, such as Azure Functions, and other cloud services. I usually say to my customers that if their application or end system provides a proper interface such as REST, we will be able to integrate with their system. So far, we have been able to integrate with all the systems. We always try to find a solution, and so far, we have been successful in that part. With regards to RPA bots, we have not yet tried out the use case. It's yet to be proven from our side. We are currently testing out the decision engine and trying to promote that in the business areas. Depending on the success or basically on how people are adapting to that, we might also extend that, and it would probably be a new use case.

It can cover everything through code. That's really beneficial. In the past, you had to do certain configurations and things that usually were hidden in configuration, sub-configuration, and so on. So, only the ones who implemented the process would understand it, but now, due to the fact that everything is as code, everyone is able to read what's going on in the process. It's easy to see how the process is configured. It's more transparent for us to see how to change things, and it's easier to transfer tasks from one person to another. In the past, you had to deal with the subject matter expert on a specific process and the handover took much longer. Nowadays, it's much more fluid to understand the process and its implementation.

Camunda can be used in various workflow scenarios, such as policy administration systems, onboarding, account management in telecom, insurance products, policy issuance, claims management, and loan management. 

It is also suitable for customer service center activities where customers' accounts are created. Camunda can manage any workflow that requires customer interaction with the system. It is a competitor to other BPM solutions like Pega.

The architectural part of Camunda for workflow design is highly valuable, especially the Camunda Modeler, which allows quick process design and implementation. Camunda's DML is a competitor to the implementation of business rules. 

It integrates well with Java, making it suitable for various technology stacks. Camunda facilitates microservices integration. Its SaaS model provides scalability, automatically managing and scaling implementations.

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.

We are a fintech company located in Argentina, and most of our use cases are related to transferring money from one account to another and doing the orchestration with financial institutions. 

It is also used for the orchestration of all the documents for onboarding. We have electronic onboarding where you give some information about yourself, and then you take a selfie and provide photos of the front and back of your document. We have to orchestrate all this information in order to validate it with a third-party bureau of data. When we receive an okay from the bureau, we know that you are an active customer, and we can give you an account.

In terms of deployment, it is a public cloud. We have Amazon Web Services running inside a Kubernetes cluster. 

We are a startup with less than 200 people. We first started doing orchestration using code, but after two sprints or about a month and a half, it became very clear that we are just generating spaghetti code. No one could understand the code after one month because it had difficult logic based on what an engineer thought would be a good idea, such as creating a new branch of decision, and if it wasn't very well documented, you wouldn't understand what was going on. Another drawback of having such a code was that we couldn't make the business understand what was going on there. So, it was very difficult to do things faster. That's why we decided to look for an orchestration tool, and we decided on Camunda as a solution. The way we could orchestrate everything was transformative. We went from having to code to drawing our processes. As of today, Camunda is used for every process here.

It is very good as a universal process orchestrator for complex business processes. We are using it for microservices, not for a human process. We had thousands of processes happening per hour, and the tool was able to capture the data for this throughput. The thing that wasn't aligned was the pricing structure. Camunda On-Premises is more designed for a human process where you have to have some kind of manual processing. We had a lot of back and forth with the commercial team because of the price of the licensing due to the volume that we had to process. That's because every time we wanted to send $1, we had to start a new process or several processes. This was a drawback, but in terms of the project, the product was very good and robust. Process heatmaps show the process steps that are hanging or taking significantly longer. You can go there and see the values and debug those. So, it was very useful for not only orchestrating what we have but also in understanding where we have made a mistake with a production process.

When it comes to integration, because we are a startup, we don't have any legacy systems, but we use it to connect with the legacy systems of the general payment system in Argentina. It was very instrumental for this use case. We had our own logic for how to connect and how to do the interface inside our microservices, and we used Camunda to verify the correct logic and sequence of calling different microservices, getting the response, and handling the response.

The dashboards are helpful in making the business understand what we are talking about and what can we do in certain situations, such as, if the money doesn't arrive at its destination. We had the drawings, and we used them to ask, "For the arrow here, what should we do?" We were able to have the conversation in a clear way. If we had just the code, it would have been very difficult. To have the conversation with the business, we would have had to create a drawing on a whiteboard and hope that this drawing is exactly what is happening in the code.

It freed up the time of our technical leaders working on this part of the system. By using Camunda, we could have the application process design, and we could quickly deploy the system to production and have the product early on the market. That was our biggest gain. We didn't have engineers struggling to orchestrate microservices.

Since I completed the courses at my workplace, I have only used Camunda for testing and practice. We had assignments to create a flow for pizza delivery and another one for an electronic shop. This practice was verified by our professor.

We have one process that was migrated from our RPA department. It used a series of UI elements for client cases, but now it is streamlined using API calls in the background. The process is more stable and efficient because it processes cases faster without being affected by UI changes like new buttons or pop-ups.