Agility, flexibility and adaptability are all aspirational traits for a "modern" business. They are, in part at least, the intended outcomes from digital transformation. They are however, a very difficult and complex set of capabilities to achieve. Some of that difficulty is cultural of course, in general people resist change. Beyond the cultural though, getting underlying technologies that enable the ability to be agile, flexible and adapt to changing market conditions is a challenge for most businesses (and systems). Many business technology systems in use today are still built in ways that inhibit the ability too rapidly adapt business strategy and operations to changing market conditions. System constraints often create impediments to a successful transformation.

There are a few issues that contribute to the problematic system constraints. A couple of these issues are not a surprise, they are "soapbox" issues for me, data and communication silos. I've written quite a lot on each of those though, so for this post, let's move past them. Instead let's look at the core of what a business applications does, the "business process".

Business Process

All business applications facilitate some part of a business process. Some applications provide complete processes, but as an industry we historically break process down into several applications that deliver a portion of the overall "end-to-end" process. The convention of breaking processes down into convenient groups of functionality make it easier for the solution provider to develop, manage and sell applications (to be fair many buyers have this view as well). Take the process "order to revenue (OTR)" as an example. Most companies don't go buy an OTR system, instead they buy several applications that might include a configurator (CPQ), order management (OM), billing, invoicing, account receivable (AR), collections, accounting, etc. All those systems would need to either be pre-integrated from the provider, or integrated during the implementation (particularly if the applications are from more than one provider).

Integrating systems has gotten easier in some respects, but it is not "easy". Service oriented architectures (SOA) are common, particularly from modern cloud-based providers. Integrating to legacy systems is usually somewhat more difficult, but with enough time and resources the issues can be resolved. Integrating a process across several disparate systems can complicate the issues quite a bit. Add to that the need to provide processes that are flexible and adaptable though, and the difficulty is greatly increased.

In the pre-cloud era, characterized by waterfall development and implementation, processes were hard coded into the application. Changing them often required a customization to the underlying system. A waterfall methodology is by its nature inflexible. Okay, maybe that's not completely fair, theoretically the approach was supposed to capture all requirements up front. There are lot's of problems with this concept though, since the requirements and customizations are defined before using the system, which often leads to mismatched expectations. I'm not planning to teaching the whole waterfall methodology in this post so that's probably sufficient to make the point that systems were rigid, often missed the mark in meeting requirements and difficult to change. To help address the broken process problem across applications business process management (BPM) and workflow solutions were developed. At the time they weren't really much of an improvement though, since they were also fairly rigid. They were capable of integrating processes across application boundaries to build end-to-end systems of a sort, which does add significant value.

Modern Process Management

Now that the prevalent methodology for both development and implementation is agile a lot of the misalignment between users and requirements isn't an issue. Because of the minimum viable product (MVP) approach and the continued iteration with the system a kind of flexibility and adaptability are built into the methodology. The question is, is it enough? At its foundation it still requires developers to make the desired changes working off some sort of prioritized backlog of change requests. Depending on resourcing and the size of the backlog, changes can take some time to be implemented. The timing and scope of change is not in the hands of the business user who has the clearest visibility into the changing business needs and requirements. You could argue that this is an inherent flaw in the need for hard coded changes to systems that are out of the hands of users.

The evolution of platforms that enable "citizen" developers, or in other words give users the tools to make modifications to processes, solution extensions and even some limited custom applications is creating businesses with much greater flexibility, agility and adaptability. These rapid application develop (RAD) or "low-code" and "no-code" platforms give users and developers a great deal control over what a process looks like in the system. The platforms address workflow, process and functionality in the solutions. They also enable users and lower experience level developers to accomplish more, while freeing up the most skilled developers to solve tougher issues.

The specific solutions span stand-a-lone to solution sets built on a providers platform. BPM solutions have evolved into no-code / low-code process platforms today that often include workflow and some form of robotic process automation (RPA). In addition stand-a-lone workflow solutions are viable options for process automation. Stand-a-lone RPA has received a lot of attention over the past few years as a tool for automating application to application workflows using bots. There is no shortage of stand-a-lone no-code and low-code platforms as well.

A Complete Solution

As is the normal evolution path for new technologies (or new approaches to solving technical problems) there seems to be momentum to combine the stand-a-lone offerings into more of a single platform. Larger vendors are building and buying component parts in the race to no-code/low-code process enablement and automation. Some of the leading solution providers now provide platforms that incorporate various layers of the necessary tools to enable the needed flexibility, agility and adaptability in their individual offerings and across the complete business digital portfolio. ServiceNow acquired RPA provider Intellibot earlier this year, SAP acquired Signavio and Microsoft bought Softmotive. Salesforce takes a platform approach and incorporates Salesforce Flow as the core workflow engine, and adds Mulesoft for integration / data orchestration, and Salesforce Einstein for automation, bots and AI across the platform. In addition there's a new RPA offering coming next year from Mulesoft.

Zoho also takes a platform approach to workflow and automation. At the core of their offering is Zoho Creator, a low code - no code developer platform. In addition to Creator, Zoho also provides Zoho Canvas (no code design platform for Zoho CRM), Zoho Flow for integration, Data Prep, Zia Developer for conversational AI and automation, Zoho Sigma (low code platform for extensions) and Zoho Catalyst, a serverless dev platform for heavier development.

The complete solution approach like Salesforce and Zoho, offers businesses an extremely flexible way to automate, modify workflows as needed and extend solutions. The presence of a workflow orchestrator is key to providing the needed flexibility, particularly to end users who can leverage the no-code capabilities. Beyond that, adaptable AI platforms and integration platforms to effectively tie solutions together beyond the vendor offerings increases the value to the business. For more information on automation and AI, contact us for a consultation.