Automation means lower costs, better performance, and excellent process observability
More and more large companies are choosing solutions that improve their customer service with process automation.
An excellent example of a well-performed automation is the implementation of Camunda BPM in Deutsche Telekom, where the process engine is responsible for orchestrating over 2,500 bots that automatically handle manual processes while opening the way to further automation and scaling. This automation resulted in annual savings of ca. EUR 100 million.
Most common use cases for business process automation
For starters, Camunda is, first and foremost, a complete technology stack with powerful BPMN process model execution engines and DMN decision tables paired with essential applications for analysis, operations, and process course analytics. Read the full description of Camunda BPM full stack possibilities and case studies.
There are 3 standard situations where this technology makes sense in terms of business process execution:
- A system orchestrating the operations of multiple independent systems realising a given process in a discreet or partially discreet manner. In such systems, the process flow logic is implemented in the code of numerous distributed apps responsible for specific parts of the process, without the “big picture” of the realisation of a given business goal. It’s a rather uncomfortable option, as any change in the process requires editing the code of apps affected by the change. Oftentimes, this unintentionally impacts other concurrent processes that use the same business logic.
- A system orchestrating employees’ work, where some parts of manual work cannot be automated (due to legal reasons, the specifics of the tasks, etc.). The system controls the flow of tasks between users, departments, divisions, and makes decisions at the level of process flow, after considering the actions conducted by users as part of their individual tasks.
- A hybrid system responsible for orchestrating users’ work as well as synchronising the systems taking part in a particular business process.
Effectiveness, scalability, and usability of implementation
At this stage, questions may arise about the scalability of this solution and how “fail safe” it is. Camunda itself is a scalable solution. Internal mechanisms of the engine allow you to create a virtually unlimited number of instances, and that number can be increased or decreased depending on the load, with no need for additional configuration.
When it comes to resistance to faults, Camunda allows you to “control the damage” by withholding individual components of the process in case of a failure of any of the dependent systems, which protects all the remaining systems participating in the process. After eliminating the failure in the malfunctioning system, Camunda allows you to “unlock” the processes and continue working on previously withheld tasks with just a single click.
Good Camunda BPM integration is the key to success
Speaking of integration with solutions hosted in existing architectures like Robotic Process Automation systems, SharePoint, or SAP, it is worth mentioning what Camunda integration looks like.
You can integrate Camunda with external systems:
- synchronously — using a REST API
- asynchronously — using a data bus
It is also worth mentioning that Camunda executes “external tasks” using “long polling”, which allows it to execute them asynchronously.
The two communication architectures can be illustrated like this:
Image 1. Example of synchronous communication architecture using the Camunda engine
Image 2. Example of asynchronous communication architecture using the Camunda engine
One of the most frequently asked questions about the architecture of this solution pertain to load balancing, ensuring high availability, and dealing with failures. Each of those three issues is relatively easy to solve. The Camunda engine can be distributed to various nodes in a cluster, and a process engine instance can connect to a common database. Individual process engine instances do not store sessions across transactions. Each time the process engine runs a transaction, the complete state is persisted to a shared database. This lets you redirect subsequent requests operating on the same process instance to different nodes within a cluster. This model is very simple and easy to understand. It’s only slightly limited when it comes to deploying cluster installations. With the process engine, there is also no difference between load balancing and fail-over setups because the process engine does not store session states between transactions. As a result, HA configurations—like active/active nodes —are extremely easy to configure. In-engine process handling is carried out by “job executors”, which can also be clustered within a single engine and run on every node. Due to that, there is no single point of failure as far as the process engine is concerned. The job executor can run in both homogeneous and heterogeneous clusters. Because the process engine is stateless, it allocates a minimal amount of resources, which means you can have billions of process instances in the database, without a necessary impact on resource allocation. Furthermore, this also means that you can run numerous process engine instances per node.
Functional integration, and then what?
It’s worth considering deploying a BPM-based system in a series of steps, each of which should bring practical and measurable benefits to justify the time and resources spent on the deployment.
After selecting a process, you can design, implement, and deploy it to production with the use of a readymade engine in the architecture described below, but you should also remember that until the processes satisfy business needs, their lifecycle never ends.
The “zero code” trap and “vendor lock-in” risk
Business Units sometimes believe that you only need to install a process engine and modelling app, and then the business will simply create processes using BPMN, and that should be enough for those processes to automagically start working and bringing positive results. This approach is known as “the zero code trap”.
Obviously, there are exceptional situations in which this approach works. However, it’s undeniable that one of the most important success factors of any business model is its uniqueness. If there was an off-the-shelf solution that required merely an adjustment of a few small, configurable components, it would not be unique as it could be quickly copied by the competition.
Adapting OOTB solutions by “patching up” their shortcomings with additional components oftentimes turns out to be more expensive and time-consuming than building a dedicated solution from scratch. In many cases, companies end up with solutions that are not only expensive to maintain, but also cause the so-called “vendor lock-in”, where due to the specifics of non-standard “workarounds” of missing functionalities, the company has to use one specific provider. In such cases, the provider can dictate their terms, knowing that they have all the expertise about the solution.
To avoid this, you should choose a service provider that transparently documents implemented processes and integrations. Engines like Camunda BPM make this task easier.
More information about Camunda BPMN you will find in the article "Business Process Automation (BPMN)".
