alphaspirit - Fotolia
To be successful, and stay in business, CIOs and the companies they support must find a way to constantly adopt new technology while modernizing their infrastructure and application library.
In the past, this "future proofing" was a nice dream, but we couldn't do it. Moreover, many of our attempts to modernize our environments by adding technology platforms, languages, operating systems and more made them more complex and fragile.
But the issue is important and for many CIOs, the challenge remains: Companies need agile IT systems so they can adapt to market changes in real time; but they also need an IT architecture strategy that helps them adapt to the next 20 years of technology breakthroughs and market changes. The first step is to understand that agility and stability are not mutually exclusive concepts -- and that if either one is missing, the company will likely fail.
The path to stability and agility, in my view, is a business process management suite (BPMS) architecture: It provides the ability to quickly and effectively build a hybrid orchestration operation that controls operational execution, application generation and the use of any new or old technology that is needed. This composite environment must support very rapid change, be technology-agnostic, support automated application generation and allow applications built in any platform to be seamlessly integrated into the solution. Tall order!
But it is now doable.
BPMS as driver of digital transformation
Business process management suites have evolved over the past 15 years to become foundational technologies for the new digital enterprise. The more comprehensive BPMS tools are designed to be used as more than an application generation platform. They serve as transformational platforms that orchestrate the use of legacy applications and applications written in modern technology, such as robotic process automation (RPA) and AI tools.
I have been looking at modernizing IT architectures to support digital transformation and writing about this issue in many of my columns for close to two years (see "More advice" below.) More recently, I have chronicled the work I am doing on a major transformation project for a client. Over the eight months of the project, the approach has evolved considerably, but the vision of stable and agile IT systems has held true. Here are some of my findings.
BPMS architecture for stable, adaptable systems: The broad outlines
One of the first things we realized was that by using BPMS technology creatively, we could build an environment that mixed applications built in different languages and make them accessible through APIs. We use the BPMS models to control activity and orchestrate the execution of the process, calling these external ancillary applications as needed. If the execution of these systems remains external to the BPMS architecture, their language and environments become irrelevant.
We also found that cobbling new technology into the old wasn't going to do the job -- it would just make things more complex. This led us to the belief that creating a new capability based on BPMS architecture is actually more important to the longevity of the company than building any application or function in the overall solution.
The reason for this is that with the right technical combination of infrastructure, data management and modern tools, we can evolve any solution design quickly and make it an integral part of the business and its support systems. The BPMS architecture gave us the ability to control process execution, using proprietary legacy applications where needed, rebuilding them quickly where needed, and using new technology such as robotic process automation, voice interaction, and AI to allow the business and process designers to be creative and try innovative solution approaches.
Making this happen
The new BPMS architecture acts as both a typical BPMS environment and as an orchestration layer calling external applications as needed and transferring processing control back and forth to govern execution: It provides both process and execution control.
The BPMS architecture also allows the generation of low-code applications, and the integration of legacy technology and applications, with applications built in different modern technologies, such as RPA or AI tools. The better BPMS vendors have relationships with these other vendors and have built links into their tools, so they are effectively combined, making the use of these modern tools in creating what I call ancillary applications much easier than it would otherwise be.
The project is now in a proof-of-concept phase. The design and approach have been widely reviewed and all agree that it will work. The next step begins with bringing in a BPMS and, in a controlled environment, build a part of the solution -- enough to test all the concepts and theory. This will be in place shortly and the construction/testing phase will be initiated.
We anticipate that the new BPMS architecture will provide the company with the ability to change fast. Supported by API-based interfaces, ancillary applications can be plugged in, or unplugged and replaced at will from the BPMS supported by the central process environment. Through this easy-to-change central process, we can continually keep the business operations up to date. Because these ancillary applications execute externally to the BPMS core, they can be in any language or tool: All that matters is their ability to take in and send data and to accept a command to execute on demand.
The BPMS architecture enables the company to modernize legacy applications while keeping up with market and customer demands. The flexibility in adopting new technology and applications by treating them as ancillary components of a process frees companies to use the best technology for the job and still help alleviate many of the legacy issues CIOs deal with every day.