This content is part of the Essential Guide: Get up to speed with BPM news, apps, tools and strategies

Use a BPM strategy to modernize legacy applications

How viable is a BPM strategy to modernize legacy applications? Tom Nolle takes a critical look and provides a step by step explanation of how it can be used effectively.

Business process management has been proposed as a pathway to application modernization by some and criticized by others, but using a BPM strategy can be a smart way to modernize legacy applications. Tom Nolle explains.

The biggest problem when it comes to modernizing legacy applications is that "modernization" doesn't imply any specific technical or functional change. Both of these should be a part of any application design and development project. Here we explore how business process management can help provide a modernization framework.

Enabling an effective BPM strategy

Correct BPM use starts with careful identification of the real business processes, not their current implementations; considers business processes and application tools as interactive elements; and keeps the process and application dimensions of a strategy as parallel coequals even in implementation.

A smart approach to BPM-driven application modernization recognizes the fundamental interdependence of tools and processes.
Tom NolleCIMI Corporation

BPM is used to break out the specific activities that combine to serve the goals of their business. In many cases, and probably in most cases where a BPM strategy is implemented well, it's properly an element in an enterprise architecture. In terms of application design and development, BPM is a source of requirements.

Keys to BPM-driven modernization

Application modernization is the process of restructuring applications to incorporate the design principles and technologies that have proven to offer the greatest agility and efficiency. It looks primarily at implementations that support business processes and, in most cases, will use the existing implementations of applications as the functional foundation.

A smart approach to BPM-driven application modernization recognizes the fundamental interdependence of tools and processes. Workers do what they do with what they have, and so the availability of applications and data tend to frame the way they work. This interdependence creates an enormous risk in application modernization because it's all too easy to carry tool-based restrictions of the past into the applications of the future. That means you have to step back from the details of the current applications and recapture the real business processes.

Here, as is nearly always the case, enterprise architecture may provide an easy path if an "EA model" is available. It would be fair to say that for a major enterprise to modernize legacy applications on a large scale, it should never proceed without first developing an EA model according to one of the established standards such as TOGAF. Where the scope of application modernization projects is more limited, it's possible to recover business process definitions from current applications. Where you have no EA framework for direct BPM mapping, take application workflows and "abstract" them by grouping application features into the business processes they support.

Determining "work models"

When you have a proper BPM framework, the first step to modernize legacy applications is to assess the workflow implications of that framework. The goal in this exercise is to determine the work model applications should optimally support. Look for the following models:

  1. Simple transactional flow: Business processes are driven by transactions, and when a process is initiated, it proceeds on an orderly path through completion. Most of the legacy applications work this way, whether the businesses do or not.
  2. Stream computing model: Business processes are driven by activity streams that may involve multiple events and sources, and a process requires interactive support through these streams.
  3. Transaction-plus-analytics: Business processes are largely transactional, but big-data collection and analytics drive a parallel set of processes.

Each of these models will have an optimum application structure that will then drive the selection of middleware tools and application program interfaces (APIs). Transactional applications, particularly the simple ones, are easily linked with SOA application models, and SOA can also be used for primary transaction flows in the transaction-plus-analytics approach. Stream computing models should be based on complex event processing and stream/flow APIs, particularly microservices. CEP might also be useful for transaction-plus-analytics models where the analytic needs approach real time.

This model becomes an overlay on your original BPM process map, showing how applications would relate to the workflows that the processes naturally create. Processes are both the source of the transactions or streams the model defines and guiding forces as to how activities are ordered. Keep this mapping at hand to ensure you don't break your BPM workflows when you structure applications.

Mapping application components

The next step in a BPM-driven application modernization project is to map both current and prospective application components into the model you've selected. If an application component fits in the flow defined in your overall map, it is suitable for use providing that the interfaces can be accommodated. Note the API and information model needs; they will aggregate to form the requirements for your middleware choices.

This is the point where the interactivity of business processes and application tools has to be considered. The tentative workflows through your model may not align in a logical way with application components, or a suitable component may not have the information it needs at the point in the flow where you hope to use it. If this is the case, then consider a trial remapping of the flow to change component order and gather the information where needed. What you're doing is changing presumptive business processes to optimize specific applications' usage, so it's wise to start this process with the most valuable components, based on your past experiences.

Plot your implementation

When all the applications and components have been mapped to the model, you're ready to plot your application modernization and implementation strategy. What is important here is to retain the separation of function (BPM) and structure (technology), so the new composite application map and workflows should be built over the BPM process map you built at the start. Remember that you may have modified this map slightly to accommodate the specific information needs of some application components.

It's true that to modernize legacy applications, as a technology evolution, doesn't seem a natural subordinate to business process management, which is why many don't see a connection. Without a BPM strategy, though, you can't incorporate the application model changes, including stream computing, that are really the foundations of next-gen application architecture. Don't make technology choices with BPM, but let BPM dictate requirements, and you'll win.

Next Steps

Study our guide to modernizing your legacy apps.

Legacy apps on cloud-hosted desktops: To migrate or not to migrate?

What are your options when modernizing apps for mobile devices?

Decide which container orchestrator is best for your company

Dig Deeper on Application modernization