The term “business process management” or BPM is often encountered in conjunction with the concept of Six Sigma and other similar initiatives. It encapsulates key concepts of a business such as the identification of core business’s processes, assignment of process ownership and definition of measures (and perhaps benchmarks). Ideally, the processes are organized in a way that makes them independent from the business they are applied to and can be seen as a simile for the concept of Docker images, the famous container platform. Just like a Docker image can be configured once and then is used infinite times while retaining its original principles and functionality. Thus, BPM software should aim to do the same.
An out-of-the-box BPM software should be able to perform efficiently while running in any type of organization, varying from employee size to core product.
Chapter 1: Why out-of-the-box solutions rarely work, today
In computing, the term “compatibility” is a big-time player. Every application and every platform has its own key characteristics and thus either allows or prohibits the collaboration between the two. A familiar example to all of us may be the concept of a system’s processor architecture and the way the applications are written in order to be functional; not all applications work on all CPU architectures.
A BPM solution finds itself into the same “compatibility” loophole that eventually renders the development of custom components a “must” in order to allow an organization to mold the functionality into its needs.
This can lead to bottlenecks in the development lifecycle that eventually result in delays for a feature to reach production. Also, bug hunting time is seriously elongated and thus renders human resources unavailable for functionality development.
Because of the fact that organizations have such complex and unique characteristics, just like a system’s processor, the application of a universal solution, currently seems dubious.
Walk into an engineering room and you might hear the buzzword of “monkey patching” or “guerilla patching”. This technique, in short, allows calling program function during runtime of an application in order to avoid a bug that resides on the code or add a small feature that is crucial for the application.
So, while the BPM software is in runtime it manages thousands of processes for both organizations. In order to avoid functionality collisions between them, patches are applied.
Developing custom solutions for BPM should be considered as a form of “monkey patching”, just because they are used to override a bug or implement a feature in a way that is, in fact, “guerilla”. A bug for one’s organization may be considered as a feature in another’s and vice versa.
Monkey patching hides some problems and adds some functionality but does not solve the problem of growing needs and does not respond to the diversity of an organization’s characteristics.
That’s where empowering each and every organization to develop solutions while operating on a universal BPM software comes in hand.
Chapter 2: the concept of low-code development and why everyone should become a maker
BPM solutions should, in fact, become a universal platform that each organization uses in order to automate its functionality. The concept of custom BPM software in order to fit each organization’s needs should be rendered obsolete.
In order to accommodate functionality that a specific organization may need, it’s useful to implement a system that allows expanding of functionality in-house, with low-code tools. In this case, anyone with an understanding of a flow chart is able to implement.
Such a system would let the developers focus on improving universal feature functionality, translating business problems into machine language, on researching into new technologies and frameworks, on making applications more secure and robust, while avoiding the process of intricate bug fixing for the whole spectrum of the clientele.
Custom features, that an organization may need, should be seen as a subject of an in-house development by the organization itself, using low-code techniques such as drag & drop or simple scripting languages that everyone is able to manage.
Decongestion of developers from the time-consuming implementation of custom features should be a key business directive of every BPM solution provider while allowing every organization to easily create their own solutions, just if they were making an Excel file.
Chapter 3: Epilogue and why the future of custom solutions is shaking
Businesses and organizations are becoming more and more complex in the way they handle data and flows. Each and every one of them has different needs, different expectations, and different demands. Because this level of complexity doesn’t seem to go away any time soon but it rather becomes more intricate day after day, allowing organizations to build their own features should be considered as the only viable option.
Software engineers are great at solving technical debt issues. The problem is that they are not so good at developing business logic features. Developing a feature for an exact corporation may result in wasted hours of researching just to understand the data flow. Developers should focus on platform features and not industry features. The last one should be left onto the corporations themselves, that can benefit from BPM solutions.
