It is over half a year ago that Opitz Consulting became a Camunda certified System Integrator. A lot of time passed since then. In this post, I will share some experiences around the certification as well as the topics of process modeling and architectural decisions.
Camunda Partner Program
The Camunda partner program for system integrators provides three partnership levels: Basic, Certified, and Advanced. Opitz Consulting graduated from level basic to level certified . One might ask for the advantage for our customers and ourselves. I think the subtitle of the certified level on the Camunda website provides the best description: Proven Camunda skills. That’s also why Opitz is a Camunda Certified partner. The knowledge allows us to provide a high quality service to our customers.
“Proven” means that the partner has at least three certified consultants, developers, or engineers that passed the exam. I also took the exam and have to say that this exam was not the easiest I ever passed. The exam covers the whole Camunda ecosystem. The most important area is of course the BPM platform. Another important area comprises questions about BPMN, CMMN, and DMN. Finally, some questions cover the BPM Life cycle from modeling to monitoring. In other words, it touches every relevant field of a Camunda project. As a candidate, one is forced to deal with the whole range of Camunda’s features, even if they’re not part of your daily project work. This ensures a consistent quality level, if working with any Camunda Certified Engineer.
From time to time, I am asked how we support customers to introduce and operate BPM and Camunda. Of course, there is no clear answer to that as we adapt our approach to the client and the project. Nevertheless, there are also subject areas that are at least touched in each project and these will be discussed below.
Based on our long-lasting project experience we can guide our customers through all project phases of a BPM project. Even though we are doing a lot of implementation work, there are also other important fields of work, in which we support our customers. Two of them are especially important when starting a BPM project: architectural decisions and process modeling.
The beauty of Camunda is that it can be used in many architectural setups. It’s possible to integrate the Camunda engine with a lot of architecture styles. We see applications based upon a microservice architecture as well as applications based upon a monolithic architecture. I don’t want to judge on architecture styles in this post but we see sustainable, evolvable architectures basing upon different styles. Even if they are modern, microservices are not the holy grail of architecture. I would propose to decide based on context, constraints, and requirements which style to use.
This flexibility, however, requires careful architecture work. One of the most important decision to be taken is the integration of the engine with the application. For example, one can use a Shared Engine that can be used by a bunch of applications in parallel or one can use an embedded engine configuration that provides the engine for the application exclusively. In my view it’s important to make such decisions explicitly. That helps one to estimate the risks and consequences of the decision. For example, a consequence of using embedded engines for an application is that one doesn’t have a unified task list containing all the tasks from the different applications out of the box. In this case, one has to come up with a custom integration solution that provides the unified task list. In such cases we can provide our customers with a rich set of architecture decision which must be taken. That allows to speed up architecture work and ensures a certain level of quality.
Based on our experience we created a catalog with generic architecture decisions that came up in a lot of projects. From the catalog we have derived a questionnaire that can be used at a new project. The questionnaire helps to speed up the initial project phase and also improves the quality of the decisions.
It is highly recommended to document decisions. This helps to track the decisions over the entire course of a project. At the moment we experiment with Architecture Decision Records (ADR) to further formalize the documentation . Furthermore, we pursue current efforts to place the decisions directly in the source code: The Embedded Architectural Decision Records (E-ADR) .
As soon as I come to a customer, I ask about the processes that we should automate. In most cases if the processes don’t match the level of quality, we need to run the process with Camunda. Most process models I see at customers only reflect the happy path, i.e., they lack in showing alternative paths or error handling. Furthermore, we ask the customers about metrics and SLA, because these are also important topics for process modeling. Hence, we help our customers in a first step to model better processes, by providing guidelines, conventions, patterns, and examples to improve process modeling. My advice is not to underestimate the effort to model business processes, as high quality process models, in my experience, lead to a significantly more reliable execution and more meaningful monitoring.
In most companies, process knowledge is spread over the whole organization. In order to gather the knowledge we help the customer by doing interviews or organizing workshops. The difficulty lies less in the organization than in the different perspectives that different stakeholders have on the process. These different views must be combined to one executable view that covers the engines perspective.
Data flow is also an underestimated dimension of process modeling. We observe that the data flow is at least as complex as the control flow. Furthermore, a lot of complex transformations are necessary, while integrating existing services within a process. Therefore, the data flow should already be considered during the modeling. Otherwise, there is a risk that too many almost identical transformations will occur during the implementation.
We also give our customer the advice not to observe a business process as static. The assumption that a process is modeled once and remains valid for ever simply doesn’t hold. In contrast, the process will evolve. In my current project, we deploy up to three process versions a year. This must also be reflected in the (project) organization. I quite often recognize the pattern where processes are modeled from a business perspective upfront and the people who modeled the processes aren’t available later during the refinement phases. Besides organizational impact, changes of process models also have a technical implication. Long running process instances must be migrated to the new model possibly. Therefore, migration of process instances is an area in which we support our customers.
Finally, we help our customers to implement their own modeling method and convention. A list of basic methods is listed in .
Process management is a broad and exciting field of work. Getting started may be a bit complex, but this is exactly where we come in: making process management easy for our customers. I hope by reading this blog post you got an impression what problems we are solving together with our customer and what advantages you have in working with a certified partner: proven knowledge.