5 lessons that software developers can learn from Business Process Model and Notation (BPMN)
Introduction
Business process model and notation is a wildly popular visual language for business automation low-code software. On the other hand there are many successful business application implemented on a text-based programming language like ECMAScript. Python, Java or C#. This article attempts to describe what a traditional software developer can learn from visual coding tools, and how a typical software architecture could be improved by adopting BPMN concepts in the code.
What is BPMN
BPMN is a graphical notation for describing business processes created decades ago. In addition to simply explaining the process, the notation has been adopted by many software products as a directly executable characteristic for low-code software.
BPMN is focused on the implementation of a reproducible, user-oriented pipeline for people and software to work together. The notation defines several node types, connection rules and execution semantics. The overall picture describes a business process from start to finish and quickly shows how employees interact with each other.
1. BPMN best practices
Every successful programming language has its own coding style and best practice guidelines. BPMN is no exception here. Beyond simple syntax rules and name conversions, there is a broad topic of implementing successful business processes that work. It’s a complex problem, but if business analysts follow this approach, the software development specification becomes clean, easy to implement, and helps implement future program modifications.
My favorite rule here — is to model success path only, avoid loops, and get exceptional business situations handled in a separate flow. By describing your process this way, you automatically structure your code into separate, simple modules that are easy to maintain.
2. Agile Coding cycle
One of the great advantages of visual coding is that you always know what state your program is in, how it works, and what paths are being executed. A visual representation works as a software requirements specification . It establishes a clear way to collaborate with customers and discuss software modifications.
The traditional software stack has ways to generate diagrams and flowcharts from code. But it will just be a class diagram of our MVC code or a database domain diagram. But it won’t reveal the implemented business process.
The thing that we need is the flow of controllers components. How they are intertwined with each other and must be executed by the users. This could be accomplished quickly with special comments and generate a graph from them, but you’ll see below how to do it better.
3. Top-level software structure
What if software developers were creatinga horse? They would break it up into layers. Here in the picture you can clearly see the horse frontend implementation details on the right side and the horse backend on the left.
Unlike traditional software design, low-code applications allow you to work on a solution by starting with a skeleton and gradually adding more details. Defining BPMN gives you the bones of software design. And allows you to gradually add new features.
Technically, we cannot avoid separating the frontend and the backend. But we could use the flow definition as a way to structure our code layout, and API naming conversions. Such a structure would help in the future to understand what we need to modify when we change the workflow in a large codebase.
4. CRUD and Workflow separation
Any sufficiently complicated business automation software built around an ad hoc, informally-specified workflow definition. We usually start with a simple CRUD application, then add filters that allow users to list entities to work with, like date_approved is null and moreover add sort of entity status that represent a current work need to be done, like REQUIRES_APPROVMENT Naive implementation scatters the logic of the workflow across the code base, makes it difficult to understand the whole picture and prevents you from adding new functionality.
Workflow is the thing that requires new separate layer in our code. In addition to usual Model-View-Controller separation, the controller code itself could be spitted over CRUD and Workflow parts.
5. Advanced primitives
Business processes have been studied since the 1970s, BPMN standard accommodates a lot of primitives construction, that helps in the concise business process description. Traditional programming languages often don’t have a direct and easy way to implement this in code.
- Split/Join
- Timers and deadlines
- Completed tasks compensation activities, if a flow was cancelled.
- Complex gateways, like continue after one of outgoing tasks was completed and cancels other ways.
Having a clean API that implements the necessary BPMN concepts helps to simplify the code and be open to quickly make new changes.
Conclusion
Pressure of raising low-code software requires a corresponding response from traditional programming languages. Literally, there is no difference in time to write forms.TextField from looking at a pallet of visual designer tools and dragging and dropping the appropriate element onto the form.
Often software developers is burden into technical details, that prevents us to invent good and productive API to construct working products. Studying interaction patterns and emphasizing low-code software concepts, can help invent new and modern software architecture, close to the perception of programming users, reduce the cost and time of software development.
