Author: capbpm

Introduction

“Getting Jobs Done” (GJD) methodology aligns well with Business Process Management (BPM) and Process Improvement methodologies, as they share the goal of making processes more efficient and effective. Both GJD and BPM focus on breaking down complex processes into smaller, manageable tasks and setting clear goals and objectives.

If you’re trying to get your technology portfolio aligned with your business needs, then you need to consider the natural alignment of GJD and BPM. 

In this post, we’re going to explore how these two powerful methodologies can work together to streamline processes and boost efficiency. From the basics of GJD and BPM to real-world examples, we’ll dig deep. 

Understanding GJD

“Getting Jobs Done” (GJD) is a methodology that emphasizes the importance of focusing on completing specific tasks or “jobs” rather than being bogged down by broader, abstract goals or objectives. The idea is that by breaking down a larger goal into smaller, more manageable tasks, individuals and teams can make more consistent progress and achieve their goals more efficiently. GJD is often used in the context of project management, and can be applied to a wide range of industries and fields. Some key principles of GJD include setting clear, measurable goals; focusing on actionable tasks; and regularly reviewing progress and making adjustments as needed.

Understanding BPM

BPM is a management approach that involves analyzing, designing, automating, measuring, and optimizing business processes. It is used to improve the overall performance of a business by making processes more efficient, reducing costs and increasing customer satisfaction. BPM can be applied to a wide range of business processes such as manufacturing, finance, human resources and customer service.

BPM & GJD

In BPM, processes are captured, modeled, automated or not, and then optimized to increase efficiency, reduce costs and to improve the overall performance of the business. This can include identifying bottlenecks, automating repetitive tasks, and eliminating unnecessary steps. BPM methodologies such as Six Sigma or Lean Six Sigma are often used to implement process improvements.

GJD can be used as a tool within the BPM framework, as it helps to focus on specific jobs or tasks that need to be completed in order to improve a process. By breaking down a process into smaller tasks, it becomes easier to identify areas for improvement and measure progress over time.

Both GJD and BPM work well together by providing a clear and defined methodology to identify, prioritize and complete the specific task or job that is needed to improve the process.

A Pragmatic Example of GJD and BPM Together

An example of using the “Getting Jobs Done” (GJD) methodology in a retail checkout setting might involve breaking down the process of checking out customers into specific tasks and setting clear goals for each task.

1. Define the Job – The job is to quickly and efficiently check out customers at the retail store.

2. Break down the Job into Tasks – The tasks involved in checking out customers might include:

• Greeting customers and scanning their items
• Handling payments (cash, credit/debit cards, etc.)
• Bagging items and providing a receipt
• Assisting with returns and exchanges
• Resolving any issues that may arise

3. Set Clear Goals for each Task – For each task, set clear and measurable goals such as:

• Greeting customers within 5 seconds of them arriving at the register
• Processing payments within 15 seconds
• Bagging items and providing a receipt within 20 seconds
• Resolving any issues that may arise within 2 minutes

4. Monitor Progress – Regularly monitor the progress of each task and measure against the goals that were set. Identify areas that need improvement and make adjustments as needed.

5. Review and Adjust – Regularly review the overall process and make adjustments as needed. Continuously look for ways to improve the process.

By breaking down the process of checking out customers into specific tasks, setting clear goals for each task and regularly monitoring progress, the retail store can improve the efficiency of the checkout process and increase customer satisfaction.

Now From a BPM Perspective

In the BPM world, the process might start out looking something like this:

Notice that we’re not talking about technology here: we’re focused on the business conversation. But we’re focused on it with a sense of discipline and progression. We are defining what the steps are, how they lead from to another,, who does them, and, eventually, we’ll start to define the ‘what ifs’ and different paths that might occur. 

That will naturally and organically lead to the discovery of the key metrics of each step, how we can improve and measure them, and where technology can help us. And this is key to providing a pragmatic solution using Service Orchestration. 

Key metrics: bending the technology to the business’s needs

Some of the key metrics that could be used to measure the performance of each of the steps in the process of checking out customers follow. If we can align these with empirical data from the process flow, then we’ve got our hands around something interesting: we can track each of these, align them with profitability and customer satisfaction, and use our creativity to maximize both the experience of the customer, as well as the profitability of the enterprise. 

1. Greeting customers and scanning their items:

• Customer wait time: This metric measures the amount of time a customer spends waiting to be greeted and have their items scanned.
• Scanning accuracy: This metric measures the accuracy of the gatekeeper in scanning items at the checkout counter.

2. Handling payments:

• Payment processing time: This metric measures the amount of time it takes for a cashier to process a customer’s payment.
• Payment error rate: This metric measures the number of errors made when processing payments.

3. Bagging items and providing a receipt:

• Bag packing time: This metric measures the time it takes for the bagger to pack the items and provide a receipt.
• Receipt error rate: This metric measures the number of errors made on the receipts provided to customers.

4. Assisting with returns and exchanges:

• Return/exchange processing time: This metric measures the amount of time it takes for an assistant to process a return or exchange.
• Return/exchange satisfaction rate: This metric measures the percentage of customers who are satisfied with the return or exchange process.

5. Resolving any issues that may arise:

• Issue resolution time: This metric measures the amount of time it takes for a customer service representative to resolve an issue.
• Customer satisfaction rate: This metric measures the percentage of customers who are satisfied with the issue resolution process.

These metrics can be tracked and analyzed to identify areas of improvement and optimize the process of checking out customers at the retail store. The diagram might evolve to look like this.

So, in conclusion, we discussed the natural alignment between the Getting Jobs Done (GJD) and Business Process Model and Notation (BPMN) methodologies. We explain how these two powerful techniques can work together to streamline processes and improve efficiency in a business. 

GJD and Business Process Management share the goal of making processes more efficient and effective. This was an in-depth look at GJD and BPMN, including the basics of these methodologies and real-world examples of how they can be applied. Overall, the goal is to show how you can use GJD and BPMN together to achieve business goals.

Science teaches us that if you magnify matter deeply enough, zoom into the object and past the molecules, past the atom, past the electron and neurons and photons and electrons, and even the quarks, and you zoom in even further, you find like strings of energy. This is String Theory.

These strings hum. They vibrate. And the frequency of that vibration determines if you have an electron, or a neutron, or a quark, or whatever else. So your body, for example, is a symphony of billons of these humming strings, uniquely creating you.

I believe processes are those little strings of energy for the enterprise. Whether written, documented, automated, or just tribal knowledge, those processes, great and small, are the ties that bind a company together.

Processes define how the company operates, and its character. The quality of those processes is what ultimately predicts the success or failure of that enterprise.

And this is where I think an engine like Camunda shines its unique capacity.

Camunda can help you model and automate the smallest processes within your organization, and scalable enough to support the most complex, overwhelming, overarching workflows that the enterprise needs.

Camunda’s unique focus on performance, scalability, and clarity can be the gift that keeps on giving, wherever we find a critical process, large or small, that needs to be formalized, automated, or, monitored.

So, do yourself a favor. Reach out to us info@capbpm.com, or to the folks at Camunda, and start getting informed about what Camunda can do to help you aligned with the larger harmony of your organization.

Testing BPM applications requires that you change your testing mindset. Unlike most conventional applications, which we tend to think of as two-dimensional, BPM applications are n-dimensional.

With your traditional applications usually, there is just a UI and multiple integrations. Workflow applications, on the other hand, are a lot more powerful, but harder to test. You’ve got business rules, dynamic roles, security, multiple integrations, the workflow itself, timers, events, and retries. It can be overwhelming.

What are some of the problems you’re seeing out there?

First, with a lot of BPM engines, you’ve got an auto-generated UI, meaning that the ID elements for the various UI elements are automatically generated. Ok, good. Now, you can create Selenium or Cyprus tests for all of that, but the minute a change needs to be made, all of the elements on every page can be regenerated, meaning that the IDs are automatically regenerated, meaning that your QA team has to recalibrate their tests.

Now, Camunda applications don’t typically do that, because Camunda doesn’t really do UI, but there is a new form builder, even in Camunda, that might be taking things in that direction. Time will tell.

BPM applications will change over time

The main reason we do BPM in the first place is that we know and expect that our applications will change over time. That’s the whole point of BPM: you observe, modify, measure, and improve. Well, if your QA team has worked hard to figure every possible path for your application, and then you go and change it, they’ve got to start all over on that. One additional gateway at the beginning of the process can double the number of possible paths. There’s a cost to that, both in terms of money, but also in terms of time.

How to deal with change from a Testing perspective?

The answer is automated testing. You need a system that automatically tests every path in your process, every integration, every business rule, every subprocess, every timer and every event. You need it to bulk & load test, you need it to stimulate intelligent data, and you need it to be integrated into CI/CD pipeline because Process Applications are part of a larger picture.

Enterprise integration has to deal with multiple heterogeneous applications running in different locations. These applications are typically part of complex and long-running business processes. These Business Processes involve both Application-to-Application data flow and human interaction to enter/review/update data in the flow. Along with these heterogeneous systems, these humans have multiple roles that need to co-coordinate together in order to achieve a goal. I.e, a boss has to approve an expense. An underwriter needs to talk to an appraiser in order to create a loan for Loan Officer. Somewhere in most business processes, you need support for multiple roles.

Challenges of building a non-trivial application that has workflow-like elements

Typical business processes include the need for task tracking, routing, timers, conditional loopback, integrations, retries, etc. but why are workflow capabilities also needed and thus a platform such as Camunda?

1. The learning curve with Camunda is ridiculously easy: I’ve seen people become effective in one week. It’s wireframing process applications together. Good programmers have been doing that since the 1960s.
2. The tech stack is really just Spring Boot and Postgres (or the DB of your choice). You can bundle your camunda solution as a Spring boot application, throw it on the docker image, and you’re good to go.
3. Reinventing the wheel every time you won’t drive to the grocery store is *not* a good idea, nor is it good architecture. You wouldn’t build your own database every time you build a new application: you’d spin one up, customize it to your needs, and use it like the utility that it is. The same is true with your workflow. It’s a utility. It does the coordination and orchestration of your steps, so you, as the programmer, can focus on the perfection of each of those steps. This is tying your team down: it’s liberating them from having to build mundane things again and again and again.

What about Rules? How do they fit into this picture?

Business Rules are a huge part of this, Camunda supports DMN 1.1, and the Camunda modeler supports DMN 1.2 & 1.3 as of April 2020. There are going to be business rules that need to be explicitly captured and model, DMN is the agnostic notation designed for it. Camunda rules are not as easy to manage and change, from a non-technical perspective, as Rules features from solutions such as Appian, ODM, Pega, etc. You need business rules that are easily changeable by business units/processes, Camunda can provide this capability.

You do need to have rules that are easily changeable by the business

You’ve got three choices here:

1. Train your business folks in DMN and let them use the Camunda Modeler. It’s not nuclear science, but it can be a little off-putting for people who don’t have a technical background.
2. Build your own UI that drives rules changes. It’s hard but rewarding.
3. Buy a prebuild Camunda rule management and governance system from Capital Innovations!

What are the top five things you need to know when considering Camunda BPM?

This podcast discusses 5 things you need to be aware of as “Best Practices” when considering the usage of Camunda BPM. Stuart and Max discuss the top key criteria for consideration, workflow tracking needs, Camunda learning curve, Camunda’s tech stack, and utility computing using Camunda.

There are many techniques to migrate your workflow to Camunda. By using the tips in this article, you can optimize the most common process types to run efficiently as possible.

What process families do we generally run into?

1. Transaction Processes: These are high-volume, small, directed transactions. This can be visualized by thinking of a bunch of very busy ants doing very discreet functionality. Essentially, this is what Camunda was built for.
2. Bulk Processes: This consists of processing millions of transactions without much variance, and often without a lot of human iteration. Camunda can easily tackle this as long as it is configured correctly and given enough horsepower.
3. Heterogeneous Processes: This can be a mix of transaction and bulk processing, and needs to be optimized on a case-by-case basis.
4. Management Processes: This requires human intervention to manage the flow of follow-on processes. Those follow-on processes can, and often are, a mixture of transactional, bulk, or heterogeneous processing.

What do we need to know about Transaction Processes?

1. If you have third-party integrations use the trigger or the Job Executor. As it builds, it will allow for grateful retires which enables you to optimize execution.
2. Do not increase maxJobsPerAcquisition too high. You don’t want one node to be hogging all the work while the others sit idle. A lower maxJobsPerAcquisition, and more Nodes, are the way to go here.
3. I’d set the maxPoolSize between 100-150. You’ll want all your nodes to be utilized and productive. It’s important that you make sure you monitor your throughput.

What do we need to know about Bulk Processes?

1. When you set the start event on all such processes as Asynchronous it is important to immediately trigger the Job Executor afterward. That’s a good thing because it allows you to optimize your Job Executor exactly for this purpose.
2. Punch up the maxJobsPerAcquisition and queueSize pretty high. This will increase your job acquisition but could end up starving other jobs, thus, you’ll need to actively monitor that.
3. Punch up the maxPoolSize too, as long as your JVM can handle it. In order to make sure, the JMeter is still a good option.

How do I optimize Management Processes?

The way we optimize management processes is similar to heterogeneous processes. Both need to be treated on a case-by-case basis. A tip for optimizing these processes is to break up the bulk and transaction processes into fully discreet sub-processes. This is so that if you need to power through them, you can deploy them to their servers, each super optimized for either bulk to transaction processing. This is usually only done for critical systems where every nanosecond counts.

What else should we know about optimizing with Camunda?

As an engineer, It’s important to get to know your machine. With Camunda, the heart is the job executor. It needs to be repeatedly measured, tested, observed, and refined. It may be beneficial to find an experienced partner and treat them as a resource. The construction and maintenance of this are not as much of a science as it is an art. A few other things you may want to do are:

1. Watch your average resource utilization per job
2. Watch your throughput and try to profile the applications that perform well. It is helpful to know what a “good process” looks like by working backward from results to characteristics.

Robotic Process Automation (RPA) is a technology that allows us to configure a software ‘robot’ to emulate the actions of a human interacting with a computer system. The robots are really just software programs that are typically installed on a user’s desktop System that can then record and then playback the actions of people, with some intelligence/AI thrown in.

The Camunda Platform is a complete process automation tech stack with powerful execution engines for BPMN workflows and DMN decisions paired with essential modeling, operations, and analytics applications.

How does RPA tie into a workflow, which typically has multiple roles working together?

For example, you might have someone who opens an email with the subject line “Request,” looks for the word “Invoice Number” in the body of the email, copies that invoice number, looks it up in another system, and marks it as ‘paid.’ An RPA robot could do that 24/7, with no breaks, interruptions, or inconsistencies.

Let’s take an example. Imagine that Allan starts the process of opening and parsing the Excel File described above. Then Barry does another set of steps once the invoice is marked as Paid. And perhaps Charlie conducts an audit for all invoices over $50,000. Now you’ve got three roles working together to achieve a task. That’s a process, or, if you prefer, a workflow.

Don’t RPA tools already have a workflow capacity? And if so, why do I need a process engine?

This answer is two-dimensional.

1. First, while those tools have a workflow modeling capacity, those capacities are not nearly as mature as what you can articulate with a BPM engine like Camunda. You don’t want to paint yourself into a corner like that.
2. RPA robots are, by definition, fragile. Going back to the example above, if someone were to change the Excel sheet format that Allan receives, the entire workflow would break down. To really do this the right way, you’d want to write an integration to whatever system was used to generate that excel sheet and use that as the input source, so you don’t have to deal with cosmetic variance.

Writing that integration for all the steps would take a lot of time, right?

Absolutely! It might take 3-6 months before you’re done with the technical work, not to mention the political jiu-jitsu required to get access to all the systems you want. So, in the meantime, the smart money uses RPA to automate Allan, Barry, and Charlie’s work, sets a BPM process to choreograph those Bots, and concurrently writes the connect to your integrations ‘the right way’ so you can eventually replace the Bots.

Use RPA to realize value from automation quickly

Camunda actually has a pretty excellent white paper on this topic, linked in the comments. I don’t agree with every point they’ve made, and I know they might not agree with every point I’ve made, but it’s an insightful, thoughtful read written by smart people.

https://page.camunda.com/wp-beyond-rpa-success

What are the Top 5 things to know when combining RPA and Camunda?

This podcast discusses 5 things you need to be aware of as “Best Practices” when combining RPA and Camunda. Stuart and Max discuss the need for BPM-driven overall process control, integrations, RPA limitations, long/short term benefits of combining the two technologies.

Although the definition of a microservice has evolved over the last few years, it is generally accepted that Microservices is a software architecture style. It is based on small building blocks that focus on a single responsibility and function and uses a modular approach to become combining into large complex applications. There is no doubt about it; Microservices are the apex of agile software development.

Microservices provide an alternative to software monoliths and solve many of the issues and bottlenecks caused by the limitations of the monolithic architecture. One major differentiator, from monolithic architecture style, with microservice it is possible to make changes to one part of the application without having to upgrade or redeploy the entire suite of application components. Each microservice module has firm boundaries, can be written using a different programming language, and can independently be managed by different teams.

These abilities of microservices, at execution time, also allow them to be choreographed by an overall Business Process that is managed by a BPM platform solution.

What is the problem with trying to choreograph microservices?

One problem with microservice-based systems is that often use peer-to-peer communication between microservices which can cause a lot of signaling, which when trying to manage these communications, we tend to lose sight of the bigger process picture. This becomes especially problematic when the applications and sub-systems change and grow.

Localized changes that support a tactical solution can fall out of the context of the bigger process, causing a lack of visibility. If you miss the big picture because you’re so focused on the details: that big picture can get real ugly, real fast.

What is the “Microservice Death Star”?

It is exactly that….a lack of visibility, no overall “configuration management”. We lose track of application versions and microservice versions. We need a way to manage the changing way we develop, build, and deploy and execute software, especially the execution of microservice-based software.

The Camunda Process Engine

There are ways to walk around this danger. One Elegant solution is to use the Camunda Process Engine, part of the Camunda Platform, with its support for external tasks which can be used to coordinate these microservices. Each microservice executes as it previously did, you use Camunda to choreograph the sequencing, as well as the signaling. This way, you can get a True Picture of what’s actually happening in the live process instances at runtime by examining the history, which is automatic in Camunda but also use the modeling capabilities of Camunda’s BPMN support to make changes to the interplay between those processes. And when you do make changes, those will be tracked, versioned, etc.

It is estimated that the number of Java developers in the world was 7.1 million as of September 2018 that number was projected to will reach 7.6 million during 2019 and increase to 8-9 million during 2020s.

During 2020, Java turned 25 years old, Java continues to transform, while there are numerous reasons why Java continues to be a leader in the world of development and remains a programming language worth learning in 2021.

As a Java Developer, the chances of needing to interact/integrate with a Workflow or Process Engine are very high, fortunately, the open-source Camunda Platform has been designed to make that an easy task.

Who is the intended audience here?

The intended audience for this podcast and I may extend this into a series, is basically my geeky brethren. Java Developers who want to start using Camunda.

So, in order to follow along, you should probably be at least two years into your career as a Java developer, and be comfortable with Java, Spring, maven, etc. I’m not going to be teaching those, because better teachers than me have already created excellent free content on that.

If you’re looking for a recommendation, I can’t praise The Java Brains Series on YouTube enough. That guy is an excellent teacher, and very generous with his knowledge. I’ve provided a link below.

https://www.youtube.com/user/koushks

An overview of the context for someone who’s brand new to Camunda

Camunda allows you to visually draw the sequence in which your application code is executed, along with branching logic, timers, decision tables, etc. These drawings are interpreted as XML by the Camunda engine and executed. The executing engine provides optimized performance, as well as automated logging, versioning, and so much more. The idea is that you can use a tool to control the orchestration of your code, and thus free developers up to focus on the raw excellence of what happens at every step.

How does the Camunda Process engine know what step you want to execute at any given point?

Every step in your process can be tied to a Java class, and that class’s ‘execute’ method will be called when the sequence flow leads you to that step.

What’s the significance of the fact that it’s on Spring Boot?

So that’s a really big deal. It means that your process has a bundled BPM process engine, and Tomcat engine, as an intrinsic part of it. These, in turn, can be super optimized for your particular process, which is really the way the “Camunda Gods” intended for your engine to work. It’s a game-changer, and something we’ve talked about before.

What are the top five things you need to know about using the Camunda Decision Engine work?

This podcast discusses 5 things you need to be aware as “Best Practices” when starting with Camunda as Java Developer. Stuart and Max discuss how Java and Camunda were designed to work together, usage of the visual sequencing feature in Camunda, how Camunda interfaces with Java code, step management with Camunda and the importance of Spring Boot support within Camunda.

A business Rules Engine is a software system that executes business rules in a runtime production environment. The rules might come from legal regulation, company policy, or other sources. A business rule system enables these company policies and other operational decisions to be defined, tested, executed and maintained separately from the application code.

The Camunda Platform, an Enterprise Platform for Workflow and Decision Automation, includes the Camunda Decision Engine (AKA Rules Engine), which is used to execute business-driven decision tables. The Decision Engine executes Decision Model and Notation (DMN) Decision Tables and Decision Requirements Diagrams. With DMN, business stakeholders can define and maintain executable business rules, thereby providing great flexibility and convenience. The Camunda Decision Engine provides pre-built integration with the workflow engine to execute decision tables as part of an automated workflow, or you can use the decision engine completely standalone.

Why do we need a Rules Engine?

Business need to be able to evaluate business expressions as their processes execute, for example, let’s say you need to create a process that looks at your customer’s income, credit history, purchase history, age, and location to give a list of incentives they might be interested in.

You could write a bunch of if-statements in your code, but that’s a spectacularly bad idea. You’d need a developer to interpret the business rules from a business SME, you’d have to hard code all of those, and you’d need to go through your full SDLC when you wanted to make a change.

How are Business Rules captured?

Business folks can write the rules themselves in a format that’s not unlike Excel and invoke that rule at the right time in your process. That’s where DMN, or Decision Model and Notation, comes in. It’s a standard notation that allows non-technical people to write business rules. That DMN notation is interpreted by the Camunda engine, which efficiently executes the code, applies the rules, and returns the result. Google “Camunda DMN” if you want a tutorial on how to get started with them.

Example DMN table showing how inputs are mapped to outputs for decision-making

What is the best way to expose captured Business Rules to your processes?

There is Operational Decision Manager (ODM) by IBM, Drools by Redhat, Pega BPM, and many, many, many others. If you need business rules that can be fully managed and governed by non-technical users, these options will not meet requirements. If you need support for fairly small, tactical rules, then Camunda will fit the bill. And there are many other excellent engines out there. The best part of Camunda is, it’s simple, it’s lightweight and friendly.

How does the Camunda Decision Engine work?

Using an Excel table, you would describe the input that results in the output. For example, the first row might be the credit score, the second row might have income, and the third might have a debt to income ratio. These would be inputs. The Fourth row might be the output, which is the loan interest rate we’re offering, and the fifth row might also be output, indicating how long the term of that loan is.

Abstract

Setting up a Camunda production environment can be a very different experience from traditional BPM applications. In this paper, we’ll discuss why and how you can avoid common pitfalls, optimize your environments for your applications, control resource constraints, and why controlled breakage is a great thing.

https://1c6dba4e-4803-4443-a0a9-c9b19dea5066.usrfiles.com/html/db9376e69cfa487ea0fa0b912ae51a4f_v1.html

Background

The single environment approach is pervasive in legacy systems like IBM, Pega, Appian, etc. In these systems, a single environment is used for all of your BPMN applications. There’s a single logging system to maintain, a single integration layer, and single UI layer, etc.

In other words, it’s monolithic. Everything gets deployed there. It’s simpler to deliver to, simpler to maintain, and requires less interdepartmental jujitsu to reach the databases, environments, etc., that you need.

But this sort of thinking doesn’t work with Camunda and can end up painting you into a corner. This article will explain how to break old paradigms in order to unlock new potential.

Problem Statement

It’s difficult to know how the Camunda Production environment should be built. You have two basic options to start with.

1. A single environment for all applications
2. An environment for each BPMN application.

The first one is what this article will refer to as the “Big Machine”: a single environment to house all of your process applications. The second one will be referred to as a “Micro Machine”, which assumes that every Camunda application gets it’s own server. There is also a middle ground, which will be referred to as a “Fractional Big Machine”, which supposes that multiple Applications will share a Camunda Server. For the purposes of this paper, the Fractional Big Machine and the Big Machine have the same challenges.

Problems with the Big Machine

1. The single environment approach poses issues with optimization. It explicitly limits the ability to provide changes to the server without the possibility of significant adverse impacts to other resident applications.
2. You can’t socially distance one application from another. If you do not establish boundaries for the individual applications, you simply cannot systematically develop in a clean environment and force proper integration practices. For example, a BPM application serves different business functions and units, and those business units have other goals, different leadership, different tolerance for risk, and different evolutionary cycles. What happens when one application wants to embrace a change, and another wants stability? They are separate for a reason.
3. Application evolution becomes more difficult in a single server.
4. Fault tolerance is not inherently designed in a single server environment, requiring extensive root cause analysis when issues arise. When a neighboring department’s application has an infinite loop, for example, they won’t bring you to your knees. Using a multi-server approach can reduce risk, increase adaptation, and generally act as a circuit breaker in case disaster strikes.

The Solution, Build Micro Machines

Every Camunda Application should have its own environment, preferably as a Clustered Spring Boot Application. These can be a cluster of one or bigger clusters. Do not build a single monothetic environment. This is not going to solve your legacy BPM problem. At best, it’s going to move your legacy BPM problem into the cloud but leave it essentially unchanged. That is the opposite of what you need.

Camunda’s literature calls this the micromachine, where each node only has one application, but there is a shared database, as in Fig 1.

Fig 1

I’d go a step further and actually give each application its own database, as in Fig 2.

Fig 2

Optimization Each application

Camunda is designed to be optimized per application. For example: by configuring the Job Executor Thread or configuring External Tasks. The problem is, the heuristics for those optimizations have to do with the nature of your process. Elements such as

1. How often does it execute?
2. How many integrations does it have?
3. What’s its average load?
4. What’s the time to live for processes?

When you cram all your processes onto a single-engine; optimization, by nature, focuses on the lowest common denominator, which is the absolute opposite of what optimization is designed for. Worse, you’ll only get slower and less performance over time since the working model requires making a bad situation worse by adding in new models.

Utilizing the single server approach, risk often arises with competing areas. For example, the Invoice Process can’t take advantage of the new features of Camunda 7.15 because the Accounting Department doesn’t want to risk the steady flow of business that they are experiencing. Both have a legitimate, sincere argument, but they are now in conflict because the architecture has been technically structured. This issue is entirely avoidable and should be.

Customize Resource Constraint

Standing up multiple instances may seem daunting with limited resources, but it’s just a different way of doing the same task.

For example, it’s the difference between serving off the countertop or having a bunch of small plates. The surface area is the same.

The net amount of memory, compute, etc., is essentially the same. Scaling a given application horizontally without having to scale *every* application horizontally, so you’re setting yourself up to save resources. We generally recommend having a clustered Spring boot application for each process, even if it’s a cluster of one running on a container, along with a DB clustered to support each one.

Embrace Reusability

When you reuse a process, you’ve reused the BPMN definition: not its instance. So you can have and reuse a library of shared assets that are deployed to each machine so that you still get reuse, but not at the expense of flexibility. This gives you the benefits of reusability without saddling you with its negative side effects.

Conclusion

Camunda BPM applications are meant to be customized, optimized, scaled, and managed on a per-application basis. Any other usage is unnatural and bound to paint you into a corner. When you start hearing people complain about how the multi-tenancy tables aren’t working as expected, or that the performance can’t be boosted with horizontally scaling, you know you’re headed down a dark path. We invite you to step into the light and do it the easy way.