BPM-Enabled Application Platform as a Service (BPM aPaaS) is a term that’s getting thrown around more and more these days, and given that it’s a relatively recently coined phrase, it may be a good time to define it. First, though, I need to give a quick rundown of some other terms, namely, “workflow,” “BPM,” and “BPM PaaS”
Workflow is simple and most people already understand it—process oriented, custom business apps that integrate with (call activities from) any number of other applications. A workflow, for example, could be triggered by an event in SharePoint—maybe someone adding something to a list—which sets in motion an automated process that could interact with Salesforce, Oracle, OneDrive, and Yammer, to name just a few examples, and have any number of objectives and outcomes.
BPM began as a management theory that viewed an organization as a collection of processes, which, if identified, codified, and measured, could result in improved process efficiency. In other words, improve every process in a company and the company can’t help but be more profitable, or so the theory goes.
The Automation of Business Processes
BPM became a major software classification when vendors began building platforms for the automation, deployment, refinement, and management of processes. BPM was great in theory, but it turns out that not many organizations had the institutional will power to automate every little thing, especially given the organic nature of corporate processes, which in some cases evolve by the day. Put another way, in the time it takes to automate a single process, the process might already have changed, a reality that gives way to band-aid code on top of band-aid code until the whole thing collapses under the weight of itself.
The “Appification” of BPM
The problems and failures of the old BPM model led to the appification of BPM suites, which have morphed in the direction of workflow platforms. In other words, BPMs now tout their ability to build composite business apps that span groups, departments, companies, and line of business systems. And among the huge differences between an enterprise BPM and a workflow platform is this: BPMs enable you to manage instances of workflows mid-execution. Consider, for example, a complex process that takes months, perhaps even years, to complete. Now suppose one or more business conditions change while hundreds of instances of the process are in various stages of completion. An enterprise BPM will provide the ability to manage each instance through the changes without taking the entire application offline for updates.
BPM PaaS, as its name suggests, is the delivery of BPM functionality in a hosted environment. A BPM PaaS will allow you build, refine, measure and manage instances of individual applications entirely within a hosted environment. Many BPM PaaS vendors allow you to run their platforms on premises or in your own private cloud.
BPM-Enabled aPaaS (BPM aPaaS)
Which leads us to the fundamental difference between BPM PaaS and BPM-enabled aPaaS. Gartner defines aPaaS as “a cloud service that offers development and deployment environments for application services.” A BPM aPaaS, then adds BPM functionality—low code app composition and mid-execution application management—to a cloud-based platform for developing applications. Beyond this BPM spin to aPaaS is multi-tenancy, the ability to configure specific applications for individual tenants and to private label a portal for individual vendors.
This capability is especially important to channel players within major vendor ecosystems who are now scrambling for ways to develop and deliver their own IP to their own customer bases, which consist of companies who want custom applications that are readily adaptable to inevitable changes.