BPM Platforms: Standalone & Microservices implementations
Introduction
BPM is a concept of describing, modelling and managing complex business processes. With BPMN, we can easily define the order in the process, orchestrating multiple tasks, decisions and events. There are many IT platforms where the BPMN design can become a working code. BPM models and supporting IT Platforms orchestrating services, systems and business tasks proved to be a reliable source of business processes realization.
And that was when none other than Microservices appeared. That is, loosely-coupled, event-based services, designed to fulfill a specific business function, communicating by events, and implementing choreography messaging model. Do microservices spell the end for BPM Platforms? Or just the exact opposite – can BPM Platforms, like Camunda, play a crucial part in Microservices incorporation of complex business processes?
BPM Implementation Models
When companies are ready for the BPM initiative to start, the very first decision is to choose a proper implementation model and proper BPM Platform.
At first, let us discuss the model, which will define the whole BPM initiative approach itself. This is a key decision and needs to be well thought out as it will define how the whole organization will create and realize business processes. There are the two most popular ways to go with modelling:
- BPM Platform can be a single IT System which will orchestrate and configure rules for business processes in one place.
- BPM Engine can be a part of the Microservice, incorporating particular subprocesses. Those microservices and their subprocesses will be incorporated into the business process using the choreography communication pattern.
Camunda BPM Platform can implement both approaches from the technological and business perspectives. That is one of the main reasons why in BlueSoft we recommend this software as the main BPM tool in our projects and we will use it as an example for further concepts.
Camunda BPM as the Business Process Management Monolith
This approach has been implemented in many organizations since first BPM Platforms appeared. It is commonly used to orchestrate ESB Services in the Integration Layer into well-defined business processes in the Process Engine layer. We can look at such architecture from two perspectives – Business & Functional as well as Technological.
Business & Functional Perspective
From the Business & Functional Perspective, the most important thing is the Business Process itself. Camunda, as a heart of business processes realization, is the first layer where Business defines rules and monitors processes. Each Business Process has its owner responsible for business outcomes and reliability of the process execution. On the top of the Process Engine, as a gateway for end-users, there are usually multiple frontends and portals, where users decide on business process realization. For the Business Perspective, Integration Layer APIs are like ‘black-boxes’ responsible for data provisioning and request fulfillments, where the Business Process Owner is not responsible for their behavior and data management.
As we can see, the cooperation between IT Teams and Business Teams is focused on the Process Engine – while Business Process Owners define requirements and process models and engineers work on their technical realization. Integration and Data Governance Teams support Process Teams, but they are not responsible for the business process and business functionalities.
Technological Perspective
From the Technological Perspective, there is multi-layered, integrated IT architecture that provides functionalities to fulfill the business process realization. On top of that, there are frontends which can be delivered in multiple different technologies (Javascript, PHP, Angular, React, etc.). On lower level, there is Camunda, which is a center of the business process definition. It stores business rules, decision charts and orchestrates backend Integration Layer functions and UI forms in Frontends. The Integration Layer is a center of technical services provisioning. In practice, ESB Platforms, like MuleSoft, WebMethods, Oracle ESB, etc. are often Integration Layers. Their goal is to provision APIs for the Process Engine with standardized data model. This layer is responsible for exposing multiple systems functionalities, integrating data, unifying protocols, managing service governance and orchestrating simple technical processing.
Pros & Challenges
| Pros | Challenges |
| The vital benefit from this approach is simplicity in defining and monitoring the whole business process in one place. Processes, even the complex ones, are easily tracked by Camunda BPM Engine. | Change management – when altering the process, it might be required to coordinate multiple adjustments in Frontends and Integration Layers. Those layers are often the responsibility of different technical (and even business) teams, making such a change a multi-layered initiative between multiple teams. |
| Decision-making rules, tasks and the business processes definition are handled in one platform, where Business Teams can use Camunda Modeler to design the flow and Camunda Task List to fulfill the processing. | Data Ownership and Governance. The Business Process Owner is responsible only for process realization and outcomes, while the Systems Owner and Integration Architects are only concerned with data governance and consistency as well as IT systems reliability from the technological perspective. It can provoke interest conflicts around a stable, reliable platform and launch a drive for business process adjustments. |
| IT Engineers begin with their coding process with the same Camunda Modeler as well, so there is a limited space for misunderstanding between the teams in terms of the whole process design and implementation. | Having one place where all business rules and processes are defined can be a potential risk to handle due to technical failures and security aspects. |
Camunda BPM in Microservices Architecture
Microservice Architectures introduced a different approach to designing IT Systems, where large, single monoliths with a lot of business functionalities are replaced with smaller, autonomic services designed specifically for the business purpose. Such a design has its impact on how business processes are implemented. We can also look at the architecture design from Business & Functional and Technological Perspectives, but they are closely related in one microservice, providing business functionalities for one business area.
Business & Functional Perspective
From the Business & Functional Perspective, it is important to decompose the business process into smaller sub-processes which are focused on providing value and a decision within one Business Object. As there are no centralized business process engines, those sub-processes react to events in the Event Streaming Layer. Then, they enable their own business logic and produce a result event for other sub-processes. Unlike Camunda Monolith BPM Platform, tracking the business process realization is done on two levels: providing specific functionality on the microservice level in Camunda Engine and tracking events between sub-processes in the Event Streaming Layer. Such process management results in different organization models – we still have Business Process Owners, but they have less responsibility in managing and monitoring the whole process itself. Instead, they build their processes like Lego Blocks, using microservices which provide small sub-processes for composition. Microservice Teams have leaders who are responsible for end-to-end data management, integration with legacy and external systems, business sub-process realization and even end-user UI – both from Technological and Business perspectives. Such an approach results in small, agile, independent Teams combined with both business experts and IT engineers.
This concept has a lot more flexibility than classic layered architectures – but also puts more responsibility on teams providing each business functionality. It enables choosing proper technology, language, database and frameworks to fulfill the requirement efficiently. Teams are fully responsible for fulfilling the business service, and are combined with both Technical and Business experts, working closely together – starting with the data definition, through business processing, ending with UI representation to the end user.
Technological Perspective
From the Technological Perspective, any decomposed sub-process becomes a set of functionalities that are implemented in the microservice’s Business Layer– in our example, one for the Customer Data Update and the other for the Risk Calculation Update. Each microservice has its own data storage & structure, own API Layer for integration, own Camunda Engine to implement sub-processes and even own UI representation. Every layer can be written in different technology – however sticking to Camunda in the Business Layer can be useful for building tracking and monitoring outer architecture for the whole Business Process. Sub-processes communication is done by publishing events in one place, where other sub-processes are also publishing and consuming events – in the Event Streaming Layer. What is crucial in this architecture is that the Event Streaming Layer is only a tube for event sharing and does not contain any logic for messaging orchestration. The most common technologies used for that purpose are distributed streaming & queuing platforms like Kafka, Pulsar or Rabbit MQ.
Pros & Challenges
| Pros | Challenges |
| The flexibility of changes in the Business Processes & Technology Portfolio. Business Process implementation is divided into small, independent, functional elements, which are easier to adjust when new requirements are imposed. Teams of experts which are concerned with those functional services have responsibility, knowledge and power to constantly improve them, eliminating a potential conflict of interest between separate technical and business groups in layered architectures. Benefits for engineers and business working together on Camunda BPM are even more noticeable, because, in this pattern, those experts are focused on a smaller part of the business process, so technological and business perspectives can be shared between them even more efficiently. | The business process composed with loosely coupled subprocesses is not that easy to track and monitor. Building business processing with one technology stack – Camunda BPM – can simplify this part, but it is still not as straightforward as tracking in BPM Monolith IT Platform. |
| The flexibility of the technology. In BPM Monolith Platform, when a current solution is getting old from the technological perspective or becomes difficult to use in a specific business need, there is a big initiative to re-write the whole business process implemented there. With microservices and distributed sub-processes, we can plan such an initiative step by step and even experiment with multiple technologies to choose the best. | Business Services Portfolio management. With the Integration Platform, all external system functionalities have a representative ESB service, easy to use by a standardized contract. With Microservices, each one is exposing functional API and it is crucial to have governance rules stipulating not only how to build and use them, but also where to find them. |
| The risk of a bad technology decision, or a human error in re-implementing the whole business process is very low. With this approach, even if you decide that Camunda BPM is no longer fulfilling all needs, it is easy to migrate to other solution in small blocks of functionalities.
| The situation in which legacy systems co-exist with microservices can be challenging. Microservice Teams and Legacy system business teams should work together around Data Consistency and Data Ownership. In fact, having microservices, sooner or later will result in legacy systems decomposition, which is a challenge for the whole organization and the IT Systems management. |
Conclusion
It is important to remember, that not every BPM Platform can implement both microservice and standalone implementation patterns. With no-code platforms, it can be difficult to implement complete business logic inside the microservice, so they will work better as a single platform for Business Process Management. With low-code platforms, we lose a BPMN diagram driven development, relying only on close understanding between the Engineer and the Business Expert. Such understanding occurs only in Microservices Teams. BPM Platforms are the most flexible here. They combine those two benefits together: BPM diagrams modelling tool for the Business Analyst, which becomes a working code thanks to the IT Engineer. Camunda BPM is a platform, which can be used for both implementation models.
In BlueSoft, we managed to incorporate Camunda BPM in both implementation models:
- BPM & Microservices together and Trans.eu architecture as an example: https://bluesoft.com/project/microservices-based-integration-platform-for-trans-eu/.
- BPM as a simple Business Process Management toolset, supporting an online shop and Polarbulk architecture as an example: https://bluesoft.com/project/innovative-one-click-purchase-robot-for-polarbulk/
Are you wondering what working with a BPM solution looks like? Read this article for key best practices that helps to make the most of Camunda BPM and avoid common pitfalls: https://bluesoft.com/camunda-bpm-best-practices/
What Can We Do For Your Business?
