BPML, along with other business process modeling languages such as Business Process Executive Language for the Web (BPEL4WS), Business Process Executive Language (BPEL) and Business Process Data management (BPDM), were intended to provide a common standard for systems that model and automate business processes. Like the 4GL languages of the 1980s, they promised spectacular gains in productivity and a number of vendors got rich selling multimillion dollar implementations to Fortune 500 companies.
The results, however, have been less than spectacular, and the reason is so simple it is contained in the very name — they are all languages. By their very definition, systems built on these languages require custom coding. And custom code is the cause of several problems. One problem is evident immediately — it is time consuming and expensive to write. But a smooth salesman can gloss this over by painting a picture of how wonderful life will be when the system is finally ready.
Unfortunately, the pain does not end with the go-live. In fact, that is when it really starts. No system is perfect the first time, and as soon as they actually get their hands on it, users request changes. “No problem,” says the vendor. “Just fork over another large check and it will be tuned to their complete satisfaction.” And sure enough, after a few more iterations and months of development, it is working.
But is that the end of the suffering? Not at all. Fast forward a year or two. The business has changed — some functions have been outsourced, others automated and new ones added. The economy has gone from boom to bust and the regulatory environment has shifted. In brief, the business processes need to be changed and now the pain really begins, because these processes are buried in hundreds of thousands of lines of opaque code. The original developers have left and making even a “trivial” change can cost tens or hundreds of thousands of dollars, require a lead time of several months with coordination between the business users, programmers and IT department, and lead to unpredictable side effects — even after extensive testing.
After getting burned a few times, management gives up trying to keep it up to date and instead learns to adjust business processes to the software, rather than the other way round. The system that promised to reduce response times, increase flexibility and eliminate unnecessary work has instead locked them in place. Trapped and immobile, the organization has now entered the ninth circle of hell.
There is an alternative — systems are available that leverage modern web technologies to create sophisticated workflows without manual programming, referred to as a “low-code” platform. And their benefits reverse the drawbacks of custom coding:
- Initial deployment times are much shorter, typically 25 percent of the time.
- The system is transparent, the admin interface shows exactly how it will behave and is fully auditable.
- No custom coding means no custom bugs or security holes
- Updates can be made in a few hours using the admin browser
In fact, the benefits are so compelling that some vendors claim to be code-free, when in fact they have just bolted a graphical front end onto old technology. The result is that they can give a slick demo, but all the simplest changes go right back to custom coding. But buyers can protect themselves in a number of ways:
- Ask the vendor to make some significant changes, such as creating a new table and custom workflow during a live demo.
- Ask whether any custom coding is required to implement the desired system.
- Ask for a fixed-price implementation quote.
In summary, long-term success in rapidly evolving businesses therefore depends on agility — the speed with which processes can be changed to meet changing requirements. And there is no greater barrier to such flexibility than the custom coding. Happily, modern low-code technologies provide an alternative and with a few simple questions, you can ensure that you are not trapped.