What is Activiti Cloud?
The BPM discipline was created to provide a better understanding of how organisations do their work and how this work can be improved in an iterative fashion. BPM Suites were designed on the basis that a company will host a central BPM Server which will be in charge of automating and monitoring their business processes. This approach caused several frustrations in modern organisations, and the following list highlights some of the pain points that adopting a BPM Suite represent for medium-sized org:
- BPM Suites are built on top of a technology stack that the IT Department (Software) inside the organization doesn’t otherwise need to know
- BPM Suites often don’t integrate nicely with other ecosystems
- Users need to learn a whole new toolset to do the work
- The department in charge of the infrastructure where the BPM Suite will run doesn’t know about its requirements. Same applies for DBAs that need to understand how the BPM Suite works to tune their Databases.
- User Interfaces provided by BPM Suites are often not flexible enough. Many BPM implementations end up needing multiple re-implementations of their UIs
- BPM Suite adoptions are usually pushed from the business and not backed up by the internal software development teams inside the organization
Most of these pain points arise because BPM Suites impose a whole set of technologies, pushing organisations to adapt to them. This, of course, causes rejection, pain and frustration.
With the rise of cloud environments and tools that facilitate the adoption of such environments (such as microservices, containers and service orchestrators) BPM Suites are nowadays forced to redesign themselves to fit nicely in these environments.
Containers help to ease the pain on the technology side. We are now responsible for containers that hide whatever software is running inside. But containers are not enough. The main problem of BPM Suites is that most of them were designed as monoliths, pushing the adopters to go for all or nothing. On the other side of the spectrum, you will find Open Source BPM Frameworks which aim to be as generic as possible to support a wide range of development and deployment scenarios. By doing this, these projects are troublesome to use, to maintain and to fit into different architectures. Because of this generic approach, Open Source BPM frameworks delegate too many decisions to the one implementing the solutions, pushing them to not only learn about the internals of the framework but also to make complicated decisions that only experts can make accurately.
Activiti Cloud is an attempt to strip down the Activiti Process Engine to its bare minimum and to keep it as single-focused as possible. At the same time, Activiti Cloud provides a set of well defined and focused services required for most BPM implementations. Each of these services is ready to be used, but they are all independent of each other. You can choose what you need and what you don’t or even replace implementations if the one provided doesn’t fit your needs.
The primary objective of the Process Engine from the Activiti Cloud perspective is to understand (parse) BPMN 2.x business process definitions and automate their executions (runtime / process execution).
The Process Engine shouldn’t worry about:
- Where the process definitions are stored
- Dealing with process versions and changes
- Identity Management
- Single Sign-On
- Job executions
- Timer mechanisms
- Providing System to System integration mechanisms
- Sending Emails
- Storing History / Audit information and providing a way to query this information
- Performance of the clients consuming data generated by the engine
Based on this list of things that the Process Engine shouldn’t do, we have created different Activiti Cloud components and adopted 3rd party components that will interact with the process engine to provide all these functionalities that are required 90% of the time when we want to implement a BPM project.
Activiti Cloud is designed to support zero-downtime deployments (e.g. kubernetes rolling updates) and to scale using production-ready components from the moment you start your implementation. Activiti Cloud makes it natural to use Activiti in modern cloud-based platforms.
We are also making sure that using our tools feel natural for different personas (developers / DevOps / end users):
- Spring Boot / Spring Cloud: if you are already using these technologies, adding Activiti Cloud to the mix should be straightforward
- If you are looking into technologies such as Kubernetes and Docker, all our components are ready to use and aligned with the requirements of these environments.
- If you want to change/customize some of the provided out of the box components you can use our * -cloud-starters.
- If you want to change the underlying technology stack, for example switch RabbitMQ to ActiveMQ or Kafka, you can because we rely on Spring Cloud abstraction layers.
- If you worry about process/application migration and updates, you can rely on industry standard ways of dealing with container versions and data migration, instead of dealing with complicated migration tools explicitly written for the Process Engine.
- If you already have a Continuous Integration / Deployment pipeline you can integrate BPM specific builds with those tools.