How can you move beyond your first Camunda project and automate hundreds of processes successfully using an agile step-by-step approach? For the last 10 years we’ve been helping businesses to automate workflow processes, migrating from monolithic systems into agile, scalable ways of working. And we’ve discovered that you don’t have to start with a big bang approach – in fact, starting small is the fastest and most effective route to digital transformation.
You can catch up on the previous blogs in the series, if you’d like more background before diving straight into this blog, which is the final one of this series, where we’ll dive into how you can create a rockstar project team by playing to individual strengths, and foster internal collaboration.
- Scaling Camunda Adoption in Your Company
- Phases of Adoption
- Managing, Monitoring and Leveraging the Cloud
- Establishing a Center of Excellence
Roles And Skill Development
I did a lot of proof of concepts in the early days of Camunda and worked with motivated and super-clever developers frequently. Like many other software companies, we mostly dealt with early adopters in the beginning. Then, one day, I had a consulting assignment for one of the largest telecom companies in the world. I talked to a couple of developers who were not excited about Camunda at all. They simply wanted to get the job done and Camunda was thrown into the project by some enterprise guideline. And to be honest, they were good folks, but not exceptionally motivated by new technologies when it came to programming. And that is totally OK! I just had to realize myself, being a nerd and workflow engine addict, that there are normal people too. 🙂
That’s when I learned that you have to differentiate between different groups of developers:
- Rockstar Developers are the early-adopter developers that can sometimes perform miracles. They are highly motivated and passionate. You simply give them the Camunda ‘Get Started Guide’ and get out of their way. They will most probably google their way along. These folks are probably best located in the early projects and probably the center of excellence (COE). But they also come with the challenge that they always want the latest and greatest technology and sometimes tend to over engineer. And please pay attention as they are typically easily distracted — oh look there’s a squirrel!
- Professional Developers are trained software engineers. They are productive in their environment of choice with a very individual selection of tools (programming language, IDE, CI/CD, …). In order to be productive with Camunda they need to learn the basics of BPMN as well as get a solid foundation of Camunda concepts and API. Depending on your architecture and stack, you can choose between Camunda BPM for Java Developers and a more polyglot Camunda BPM and Microservices training course. It is important to give professional developers the freedom they need to be productive.
- Low-Code Developers are not trained software engineers, but often have a business background. They slipped into development using Microsoft Office tools, macros or RPA. They often dedicate their full working time to developing solutions in these environments. For many companies, the key to scaling their process automation efforts is to enable these citizen developers to model executable workflows. Some companies (like e.g. Goldman Sachs) invested themselves in supporting low-code developers to work with Camunda. Camunda will also increase support in future, e.g. by capabilities to step through the workflow directly in the modeler, by allowing users to pick connectors from a worker catalogue or by making expressions easier to define. Low-code developers often need a customized training course in the exact environment they will be working in.
- Citizen Developers are also not software engineers, but typically end-users with some IT affinity, that want to solve an active pain with a technology they can master. You might enable them to use Camunda with the platform you build for low-code developers, but we typically see customers focusing more on the low-code developers than citizen developers with their initiatives.
But of course it is not all about developers:
- Business Analysts need to learn to model BPMN. While they might use different techniques (e.g. around creativity methods) to discover and discuss workflow models, they should be able to create a BPMN model as input for development, as well as understand all models made by developers. We recommend taking the BPMN 2.0 Training Course.
- Operations people need to understand what it takes to deploy and run Camunda as well as how to troubleshoot failure situations. We set up Camunda BPM DevOps for this matter.
- Enterprise Architects need to understand the role of Camunda in the bigger picture and architecture. While I advocated against too much architecture upfront, it is still important to include enterprise architects early in your journey to make sure they are on board. In problematic political situations, we have seen it is wise to wait to talk enterprise architecture until there is a concrete lighthouse project to show.
Some customers also report that they have additional workflow methodology experts that are really good at checking if a certain workflow design is the most reasonable one at hand. They constantly try to get at the bottom of design decisions striving to simplify workflows. These people are typically organized within the COE.
Of course, roles and responsibilities can vary, and every person fulfilling a role will also “live” it in their own way. So while some basic understanding of roles and required skills is important to scale Camunda adoption in your organization, you should also be aware that these are just rough guidelines. I have seen “business folks” that program their smart home themselves and can definitely think like a developer. I have seen developers that are communication geniuses and thus could easily do business analysis without problems.
Note that a good training course can only be effective if you start using the knowledge for a real-life project right afterwards. Try to have the training coincide with the start of your project.
Additionally you should organize some coaching on the job. This can be delivered by Camunda, a partner or probably your own COE. Very often, a remote consulting offering works well for this kind of assignment.
Process Architecture and Landscapes
“Before we can even decide on a process for the POC, we need to capture all business processes in the firm and put them on a process landscape. Otherwise we don’t understand the full picture and are not able to prioritize correctly!”
We are too often confronted with this mindset, which is dangerous. Not only that the effort of capturing these processes quickly explodes and too many people will be pulled into the initiative, but, more importantly, you have not yet gained enough experience with workflow automation methodology and BPMN to produce models in the right quality. This leads to process models that are useless in the best case, or even models that become obstacles.
Sometimes companies want to safeguard past investments: “Hey, we did analyze this process already three years ago for our quality and compliance program. We still have the model around, let’s just use it for this automation project”. Hell no!
Process architectures and landscape have their place, but they have a more high-level view on processes and are only loosely connected to executable BPMN workflows. When you start your journey with Camunda, you should decouple the first projects from any of these initiatives to make sure the project can breathe, learn and make its own decisions, without getting sucked into endless political or methodology discussions. Once you have more than a handful of projects live and have gained experience with BPMN, you can start aligning the different streams within your company.
I have seen lean approaches working best, so for example a simple confluence page can serve as an entry point into the process landscape, showing a basic structure that links to high-level process descriptions. From there, you can directly navigate into executable workflow models, either in the development source control or within Cawemo.
Having a process architect who has an overview on this process architecture makes sense as soon as you scale adoption, but not before.
Foster Collaboration
More important than a shiny process architecture is a practical procedure that allows collaboration on workflow design with all important stakeholders. Tooling-wise this can be as simple as Confluence pages with the BPMN plugin or as customized as bespoke tools leveraging Git and bpmn.io to allow joined modeling. More often, I see models on shared file systems opened with the Camunda Modeler or of course Cawemo, our collaborative process modeling tool. All of this can work if the stakeholders involved have clarity on how this is envisioned. Ideally, your COE can help with this.
Try to avoid rolling out tools just because they are already established in business departments. Very often they don’t support BPMN or cannot be used to collaborate on executable models at all.
Of course, you also need to create a culture that fosters collaboration and open discussion. It will never work to throw models from business analysts “over the fence” to IT to implement them.
Part of this is to make sure that all important stakeholders have access to the process models and respective tooling. Far too often I see companies that don’t want to provide a license to every developer, which will result in a broken process. If license costs are a show stopper, consider a lightweight solution.
Don’t Forget About Project Economics
It is important to focus on delivering business value with workflow projects. Additionally you need some mechanisms to prioritize automation candidates as a basis to decide what to tackle next. I will not go into project portfolio management in this post, as it is quite complex on its own and organized very differently throughout our customer base. Just make sure that you evaluate the potential of projects before jumping right into them.
Note that you might not need such strict rules to select your POC or lighthouse project, as this might be driven more by technical matters. But soon after this is completed, every project should be justified by numbers and business value, not only by technical enthusiasm.
Over to You
I hope you’ve enjoyed this series and that you’ve found practical and useful advice that you can apply to your Camunda projects? I wrote this series to give you a good understanding of what a successful adoption journey looks like. As a rule of thumb you should decentralize as much as possible and favor an agile step-by-step approach, that allows you to learn on the way. Remember, the devil is always in the details and every situation has its unique challenges.
Enjoy your journey and all the best with your Camunda endeavors! Feel free to comment on this blog or get in touch with us if you’d like further material or to talk about how best to get started.
