BPMS architecture modernizes legacy tech, makes IT more strategic
The technology of the past put humans on the moon, but it's bringing businesses to a breaking point. Here's why CIOs should consider a BPMS architecture to modernize legacy systems.
IT is at an architectural crossroads. CIOs face a choice that may well determine the success or failure of the company they work for. Dramatic? It is meant to be.
The technology of the past produced great things. It took humans to the moon and soon to Mars. We have better medicine and better scientific capabilities than have every existed. In addition, hugely successful businesses were built on these technologies.
But the evolution of technology has resulted in an IT house of cards.
New and old technology is mixed to the point where no one really knows the probable impact of any change, how data really flows or transforms as it moves across the organization, what really interfaces to what, how many special-purpose Excel applications or unique Access databases are in use or what they really do, and the list goes on and on.
My mission here is to explain how business process management software (BPMS) architectures can get you out of this mess.
BPMS architecture organizes apps around work
A much underused technology, BPMS offers a new way to structure and create applications. It allows you to determine and model how applications align, providing a technology-agnostic view of application interactions.
The breakthrough advantage of BPMS technology is that it allows you to create a type of three-dimensional hierarchical model of all the business functions and the application systems that support them. This allows you to align how the applications interact with one another and how they support business operating functions. Because of this capability, you can now better control the use of legacy applications, and for new solutions, better control how they are mixed with new special-purpose tools like RPA and AI-based applications.
A BPMS architecture supports decomposition at the functional workflow level, breaking down components into work steps and -- at an even lower level of decomposition -- into the tasks that make up a work step. Because of the alignment, the applications that support each level of the work breakdown are clearly shown. Notwithstanding that the nomenclature of these various layers differs from company to company, the result is that the hierarchy is created around work, not organizational structure -- although it is aligned to it. This creates a model of the integrated business and application architecture in increasing levels of detail.
At the solution level, a BPMS architecture is used to orchestrate business activity, with the model showing how all work fits together, how it is executed, and how it is supported by applications. The organization of applications around work creates a new way to look at a business -- as an amalgam of activity and application support that cannot be separated. In this model, the BPMS controls the execution of activities and presents applications. Through interfaces (APIs), the BPMS architecture allows you to link to any legacy application or to an application in any other technology -- RPA, AI, voice recognition, et cetera. This makes the solution fairly technology-independent.
BPMS architecture key to expanding IT as strategic business partner
With a BPMS architecture, the IT organization becomes a key player in defining how the business needs to run, rather than be viewed as just the deployer of the next generation of solutions.
With a BPMS architecture, the IT organization becomes a key player in defining how the business needs to run, rather than be viewed as just the deployer of the next generation of solutions.
Here's why: Because any BPMS-supported business activity is executed within the BPMS environment, the BPMS applications can be designed to support a defined part of the Business model. This is itself hierarchical and can kick off the execution of any part or parts of the overall business hierarchical model in any order, so long as it is below the point the BPM developer or business end user enters it at. This creates a design or architecture that depicts and organizes all the activity in a company, while controlling both the execution of work at the lowest level in this hierarchical model, as well as the way the specific rules that govern these small components of work are applied. Everything has its place and everything is organized -- including data use and data flow. Developers can now find anything quickly -- the BPMS will tell them where it is.
Future change
Now, let's look at the future and the tremendous flexibility provided by a BPMS architecture.
Change today is difficult and the introduction of new technology is not an easy thing. But, in this model, each execution level in the application hierarchy can tie into any application in any technology by treating the applications as separate executable applications.
Because the BPMS controls the order that any generated or external application is executed in, it will either execute an internally generated BPMS application or -- using a BPMS application program interface (API) -- it will pass data and control to an external application. The BPMS-generated application will then wait, and when the external application completes its work, it will accept the result back and continue on. This makes the BPMS application open to tying to an application built in any new or old technology -- thus providing limitless flexibility. In this way, not only can applications be built using the best technology (BPMS, AI, RPA, etc.), they can also incorporate any new technology in the future and continue to orchestrate the work that is done and the way it is supported.
More insights to come
In the upcoming months, I will continue to write about BPMS architecture and its advantages. As I mentioned in recent articles, I am working with leadership across a variety of organizations to implement this architecture now and I will share evolving concepts and approaches as work continues.
A special thanks to my partner, Keith Leust, who helped with this article.
