"Low-Code BPM" vs "Developer-Friendly BPM"

Quick Intro

I started in Business Process Management (BPM) in 2005. Since then I’ve worked for several BPM platform vendors and competed against many others.

In this article I’d like to describe the overarching differences I’ve seen between two classes of BPM platforms: “Low-Code BPM” vs what I’ll call “Developer-Friendly BPM”

What’s the Same?

About 10 years ago Gartner introduced the moniker “Low-Code BPM.” It presumes ease of use, which naturally correlates with faster development lifecycles. While true in some ways it is not true in all ways, nor is it necessarily appropriate for all projects.

To understand what is different between Low-Code BPM and Developer-Friendly BPM we need to start by describing what is the same.

Almost all BPM platforms include these core features:

Of course there are extra features such as packaged frameworks, packaged connectors, artificial intelligence, and machine learning, etc., but they come at a cost (e.g., higher user licenses and more professional services to customize and maintain).

So the question becomes, if you don’t need specific features and/or functionality, or if you can find them in other tools, then why get them in BPM. You will pay more in terms of licensing and implementation.

Where Low-Code is Found?

“Low-Code” can be found in all the above features.

In my post about BPMN-enabled BPM, you’ll read how BPMN-based Modelers greatly simplify both workflow design and automation. You can graphically diagram workflows while simultaneously coding events, tasks, and gateways with associated routing, escalations, KPIs, etc. DMN does likewise for decision modeling and automation.

What’s the Big Difference?

The big difference between Low-Code and Developer-Friendly platforms are in the front-end, or rather forms and UI/UX.

Low-Code BPM platforms offer drag-and-drop forms development functionality and configurable user interfaces (UI). Together they enable organizations to create common user experiences (UX).

These types of functionality often attract business users who want to create UX themselves with an emphasis on analytics. However, business users often find they need training and expertise to properly use, and true configuration and execution (testing, QA, production release) require seasoned developers.

Quick story, years ago I worked with a large organization using Low-Code BPM software. I was surprised to find them ditching the inherent forms development and UI configuration capabilities. But then I learned users logged into existing systems, so they really needed BPM for its execution engine and operational monitoring. 

Other differences include data modeling, testability, and architectural fit.

Regarding data modeling, process instance business and/or payload data often correlate with UI forms, restricting how developers approach modeling and storing domain data in Low-Code platforms. In contrast, Developer-Friendly BPM offers software engineers full flexibility in data modeling best practices.

For testing, Low-Code platforms are often workbench or UI-driven which typically limit how “coding” is done, especially in writing test scripts and integrating them into CI/CD-pipelines. With Developer-Friendly BPM, developers and QA teams may leverage many test automation frameworks.

Concerning enterprise architecture, Developer-Friendly BPM is inherently cloud-ready (AWS, GCP, Azure, PCF) and naturally fits into multiple tech stacks (e.g., Java, .NET).

NOTE: Low-Code may or may not be a true representation of agility and speed. It's inherently heavier, proprietary front-ends and more sophisticated back-ends often require significant time and highly trained resources to install, configure, deliver, and maintain. As a result, organizations pay more both in licensing and professional services. However, organizations can achieve significant ROI with both Low-Code BPM and Developer-Friendly BPM based on realistic requirements and trained, well managed resources.

What’s Driving Developer-Friendly BPM

There are four notable and important trends contributing to the rise of Developer-Friendly BPM:

1. Open Source - With the availability of proven open source software, Product Owners want to use agile, flexible, and scalable tools to create highly custom UI/UX experiences with a very low cost of ownership, little to no vendor lock-in, support network, and strong and active user community
2. Cloud-Native - With the huge shift towards cloud computing, Enterprise Architects want workflow platforms that inherently run in the cloud (AWS, Azure, GCP, PCF) and naturally dovetail with cloud-friendly application frameworks like Spring Boot, lightweight containerization like Docker and Kubernetes, message and event streaming like RabbitMQ and Kafka, and standardized authentication and authorization like OpenID, etc.
3. Microservices Orchestration - With the rapid adoption of microservices, Developers need workflow platforms that support invoking components (or services, activities, functions) in specific sequences as well as ensuring sequences run effectively (retrying services invocations when services are not available or not responding, waiting for asynchronous responses or events, resolving timeouts, or correlating several messages into one action).
4. Open API - With a need to integrate with multiple systems to enable straight through processing, Software Engineers want a specification that defines a standard, language-agnostic interface to RESTful APIs enabling humans and systems to interact without much coding (and code maintenance).

All of these trends enable Enterprise Architects and Developers to use their inherent skill sets with commonly available tools, use them within their scrum and CI/CD methodology, and, integrate their newly build apps with existing and 3rd party systems to meet their unique UI/UX requirements at massive scale.

Why Organizations Buy Developer-Friendly BPM

So ask yourself:

• Are we going to leverage an existing UI? Or do our specs require a custom UI? And if so, can we build it using Angular, React, Node, .Net, etc.?
• Are we going to use a microservices architecture?
• Are we deploying to the cloud?
• Are we moving toward containerization?
• Are we comfortable with tools such as Spring Boot, Docker, or Kubernetes?
• Are we open source friendly?
• Do we want to use standards such as BPMN and DMN?
• Do we need bot orchestration?
• Do we simply need a state engine?
• Do we need flexibility in deployment (embedded, shared, standalone)?

If the answers to the above questions are Yes, Yes, and Yes, you likely don’t want Low-Code BPM but would be better off with Developer-Friendly BPM.

Developer-Friendly BPM enables Enterprise Architecture and Software Engineers (aka “citizen developers”) to use their native skill sets (e.g., Java, Angular, React) with familiar tools such as Spring Boot and Docker. They can leverage built-in, standards-based functionality (BPMN, DMN) simplifying modeling, deployments, and change management. They can develop using common CI/CD methodology and tools (Git, Jenkins).

Developer-Friendly BPM also provides OOTB functionality for version control and migrations and deployment to the cloud. With it, developers create executable and visual models enabling business stakeholders to understand visual workflows and discuss underlying business processes and related requirements. Business Users gain workflow context while developers inherit a workflow engine which doubles as a persistent state machine and service orchestrator. And all get access to both process and operational data for troubleshooting, improvements, and migrations.

In summary, Developer-Friendly BPM enables organizations to avoid spending on unneeded functionality and unwanted overhead (additional hardware, computing power, and people). They also have access to a larger pool of resources making hiring easier, development faster, and change quicker.

The Upshot: You have choices. Take time to evaluate BPM tools in the context of your business and technical requirements.