What is our primary use case?
Our usual use cases for Flowable involve controlling the workflow and business process components of our customers' operations. For instance, when an inquiry is received, it initiates a process that assigns tasks to individuals. If someone is unavailable, tasks can be reassigned.
Decisions are made within the workflow, leading to further actions based on those decisions. It helps manage standard workflows within our customers' business processes. In the past, we've often handled workflow implementation manually. We aim to transition to a BPM-based process engine for more workflow flexibility.
What is most valuable?
The tool's most valuable feature is the process engine. It allows us to define BPM-based workflows, deploy them into our process engine, and interact with them within our product.
The product's integration into our existing systems has been a game changer. We're excited about how it will help us manage a challenging aspect of our integrations, particularly in customer deployments.
What needs improvement?
In my opinion, areas of improvement for Flowable include the management and creation of forms within the open-source components and the documentation and examples provided. While the cloud-based Flowable implementation with no-code features is attractive, we prefer more control over integration, especially since we deploy our product onto AWS. We also want to avoid additional licensing fees for Flowable runtime user components on top of our software development and implementation charges.
I recall that Flowable deploys the REST API WAF file for deployment within Tomcat, but it lacks certain components like user group management, BPMN design, and forms.
For how long have I used the solution?
I have been using the product for three months.
What do I think about the stability of the solution?
I rate the tool's stability an eight out of ten.
What do I think about the scalability of the solution?
Scalability is not a significant concern, as it might be for those deploying the tool in the cloud and aiming to attract many users for a SaaS solution. In our case, we're deploying around five BPMN models per customer to a customer base of around five staff members, so scalability isn't likely an issue for us.
Which solution did I use previously and why did I switch?
We handcrafted a workflow before using Flowable.
How was the initial setup?
I'd rate my experience with the initial setup of Flowable at about a three out of ten, but for our developers, it's probably closer to a six. I found it challenging due to the complexity of the user and help documents and the fact that much of the Flowable documentation and tutorials are focused on cloud-based implementations.
Since we're primarily interested in basic components like BPMN models and form design, which aren't included in the product, the learning process was more difficult for me. In contrast, our developers are more comfortable diving into the code and technology stack, which allows them to be more proactive in their approach.
The deployment took three months to complete. We're still in the deployment process. Our main challenge is integrating the Flowable process engine into our product, which uses OSGi. This has led to complexity in managing the Java versions and dependencies, as the tool has around 150 Java files. We could have chosen to interact with Flowable via a Docker container and the REST API, which would have isolated the OSGi Java dependencies, but we decided to integrate it directly. This has required resolving Java version control issues and upgrades, leading to various development challenges that must be addressed.
It is a learning process for all of us. As an integrated solutions architect, I would have probably opted for the Docker route rather than the direct OSGi integration chosen by the developers. However, since they went with the OSGi integration, it's taking us longer to complete the deployment.
Currently, we have one full-time developer dedicated to deployment, along with one part-time developer, and my involvement at about a quarter of my time. So, we have about two people working on deployment. As for maintenance, we're not entirely sure yet. Given our direct OSGi integration choice instead of Docker and REST, maintenance may be more challenging. However, we'll have a clearer picture once deployment is complete.
What's my experience with pricing, setup cost, and licensing?
Since the tool is open-source, we don't have to pay anything for it. It's free to download and use, which is great for us. If Flowable hadn't been available as open source and required a license fee for us to integrate it into our product, we might not have chosen it.
Which other solutions did I evaluate?
We evaluated other options before choosing Flowable. Initially, we started with Activiti but ran into issues because it removed OSGi integration, which was essential for our needs. While digging into this, we discovered that the original developers of Flowable had previously worked on Activiti and forked the code in 2017. This led us to choose Flowable over Activiti. Although the two platforms have very similar code bases, integrating them has proven challenging.
What other advice do I have?
It's challenging to pinpoint which specific Flowable feature has improved our process efficiency, as we're still in the development phase and learning from mistakes. However, we rely on the process engine to fulfill our requirements and expect it to meet our needs.
Currently, we're working on the on-prem version. However, we're now in negotiations with two customers who are government organizations. Government restrictions on cloud usage can be quite stringent, which is another reason we're cautious about moving to a cloud-based solution.
As I mentioned, we needed a workflow solution that allowed us to deploy on-premises and within our cloud computing environments, which our public sector customers are comfortable with. Some government organizations have very restricted deployment requirements for the cloud. I rate it a seven out of ten.
My advice would be to consider using the REST API approach for integration with Flowable. Additionally, the Flowable open-source components can be challenging due to lacking a process engine, forms designer, and tools for tasks like user group membership management. While the database structure of Flowable is similar to Activiti, there are some differences to navigate. We've found that certain tools from Activiti are not fully integrated into Flowable open source, even though Flowable is largely derived from Activiti open source.
It seems that Flowable's decision to prioritize its cloud environment and no-code offerings may explain why certain components are not readily available in the open-source version. While this strategy may work well for some users, it challenges businesses like ours. The lack of these basic components in the Flowable open source can be a significant drawback. We want these components included in the product to meet our needs better. Otherwise, we might find that Flowable open source doesn't offer much beyond basic Activiti functionality, which could be a concern for us. Ultimately, we've chosen Flowable over Activiti because Flowable open source supports OSGI bindings, whereas Activiti 7 does not. If Activiti 7 had OSGI support, we might not have opted for Flowable open source.
Which deployment model are you using for this solution?
On-premises
