For well over a decade, business process management, optimization, and automation platforms have played a critical role in digital transformation. These platforms allow organizations to modernize their infrastructure and applications without sacrificing the core business logic the organization depends on for its day-to-day operations.
This is why research firm MarketsandMarkets forecasts the BPA market to double from $10B in 2020 to $20B by 2026. "The BPA market will continue to grow post-COVID-19 as more enterprises across the globe plan to migrate their IT infrastructure to cloud, boost business continuity, and improvise business operations," the report said.
Today's platforms are flexible, reliable, scalable, and integrate well via APIs with a host of popular third-party software, as well as legacy applications running on everything from mainframes to the cloud. These integrations make BPA platforms valuable tools for organizations to adopt and adapt to digital technologies across their activities.
A very large drawback
As useful as these platforms are, they come with a significant drawback. Having been designed in the era of application servers and n-tiers architecture, BPA platforms are built on a set of shared services, data, and frameworks. Any newly created or modified business workflow or process uses these preconfigured services to automate both common and mission-critical processes, such as onboarding a new employee or company-specific customer transactions. Most BPA platforms come pre-packaged with hundreds of these services and frameworks.
The challenge for IT architects and operations personnel, application developers, and business users is that services run on any BPA platform all use the same system resources and application runtime engine. Because multiple business workflows depend on the same platform service, all processes and workflows are impacted if the platform or any of its services go down or are taken offline for any reason: for maintenance and update, for example. In very large organizations with thousands of concurrent workflows, this can create large-scale operational roadblocks and expensive downtime until the service is restored.
With digital transformation continuing to impact how organizations operate, this potential single point of failure poses real challenges for developers and IT as they work to integrate new technologies into the organization’s DNA.
A common example of this dynamic in action is when a business process in one part of the organization needs to be modified or transformed to incorporate new technologies, such as a smartphone app or streamlined customer-facing UI. When the underlying shared services that support that business process need to change to incorporate the newly modified business process, it can cause unwelcome cross-departmental ripple effects. Every other department will have to modify how they do business if they want to keep using the newly modified shared service.
There is a better way
With the current approach, the platform does everything. Developers must implement applications following all of the platform’s constraints. Likewise, those applications’ deployment, administration, and operation are further constrained by the platform’s runtime environment.
Even though most, if not all, BPA platforms are designed around this shared services model, there is a better way. For years now, virtual machines and containers have been used to break apart siloed application stacks into more loosely-coupled components that run independently of each other. These microservices architectures are, in large part, responsible for the massive scalability and reliability of today's cloud-based services, such as Netflix, Facebook, Twitter, and many others. But you don’t need to go that far to make your business process automation apps grow with your business.
Following the same logic, BPA could generate applications that would behave like a service in a microservice architecture. Unlike microservices, which still allow shared services, the BPM service in this new architectural approach would not be shared. Instead, these services would become a dedicated resource supporting an individual workflow or business process. Other workflows and business processes that need the same BPM service would, likewise, have a dedicated resource. This approach means that each business process runs in isolation, separate from the other business processes in the organization. For the business, this means each process can be managed, modified, updated, and scaled independently – increasing overall uptime and availability across the board.
The benefits are many
From a technology perspective, container base deployments allow IT and developers to create and run infrastructure-agnostic apps--freeing up time and resources for more value-added activities. It also fits nicely into today’s agile software development methodologies.
By allowing developers to work on individual BPM apps, they can do so without shutting down large portions of the overall platform. Likewise, microservices are well understood by the developer community, so the learning curve for working with redesigned BPA platforms should be substantially reduced and streamlined. IT benefits by being able to manage, monitor, access, and backup each BPM app independently.
More importantly, the business value of this approach is material. Most organizations today are highly reliant on technology for everything they do. When their business processes are interrupted, the business itself can grind to a halt. Decoupling applications from the underlying platform creates less business disruption by giving organizations the freedom to modify business processes quickly and efficiently on short notice--an ability that, post-COVID-19, is a top-level business priority.
By placing customers’ needs front and center, we believe this approach will allow customers to pursue their digital transformation goals unimpeded by the technical constraints existing BPA platform architecture imposes upon them.
Nicolas Chabanoles is CTO at Bonitasoft.