Micro Focus is now part of OpenText. Learn more >

You are here

You are here

App modernization 101: Understand your options—and how to get started

public://pictures/davidweldon.jpeg
David Weldon Freelance Writer and Research Analyst
 

To effectively grow, compete, and differentiate themselves, organizations need peak performance from their core business applications. That is especially true in the age of digital transformation.

But many organizations are working with legacy systems that don't always play nicely with modern software applications. If that sounds like your organization, it's time to explore application modernization.

Application modernization is the process of taking old applications and the platforms they run on and making them "new" again by replacing or updating each with modern features and capabilities that better align with current business needs.

This can be done by updating older systems and software with desired new features (rewriting the code), replacing the older system in a rip-and-replace process, or rehosting the applications (moving them off the off the mainframe).

The decision might seem simple enough, but it often isn't. As Derek Britton, Director of Application Modernization and Connectivity Strategy at Micro Focus wrote, "After all, no two applications are the same, and the requirements for change are many and varied: functional improvements, new user experience, integration with other apps, new data feeds, new access points, new architectural or object/service models, new delivery tool chains … the list goes on."

There can also be confusion on which course of action is the best choice for any organization due to the wide array of descriptions assigned to the modernization process. Consider: Gartner describes seven options for application modernization. Computer Associates narrows the field to five choices. But CSC describes no fewer than 10 different approaches.

Here are key app modernization paths you can take, plus steps to get started.

Rearchitect/refactor or rewrite (rebuild)

Rebuildin applications involves rewriting portions of the applications from scratch while preserving the original scope and specifications. If an organization alters the original code for it to access a new application architecture with more desired capabilities, that process is said to be rearchitecting the application.

If the process restructures and improves existing code without changing external behavior, that is said to be refactoring the application.

Rearchitecting is known to have a moderate risk and cost, but it will produce positive results. As an example, contemporary COBOL technology is available that includes several features intended to simplify and accelerate changes to original applications. The result is that rapid changes can be made to original COBOL code.

Rip and replace

As the name implies, this option eliminates the original application completely and replaces it with a new application better suited to an organization's current business needs. The image suggested is that of quickly ripping off a bandage in one rapid move.

If business considerations are driving the effort, as opposed to technology reasons, an organization may quickly decide that total replacement is too risky and expensive and may not produce the desired technical changes anyway.

Rehost/replatform (move off the mainframe)

Rehosting simply means that an application is moved to another infrastructure, whether physical or in the cloud, without altering the original code or changing its features. If minor changes are made to the original code or the application features in order to migrate it to a new runtime platform, that is known as replatforming the application.

As with moving any application to the cloud, one of the primary concerns is always data security, where core business process applications may be entrusted to a third party. Many organizations may not be prepared to make this journey.

Steps to start the journey to application modernization

To aid organizations in their journey to application modernization, Forrester vice president and principal analyst David Bartoletti recommends the following steps:

  1. Create a compelling business case. Ask: Why modernize an application now, who benefits, and what new opportunities does it open up?

  2. Evaluate if and where you can find the skills needed to start refactoring or migrating an application.

  3. Consider whether the modernization effort should include migrations to the cloud; many do today.

  4. Determine which metrics should be used to determine success.

  5. Conduct a risk assessment of each option, since applications are often core to an organization's most important business processes.

Here's how to put these into direct action.

Take stock of your applications and their value to the organization

The best way to start an application modernization strategy is to conduct a full application assessment, taking inventory of each application, the anticipated ease or difficulty of modernizing it, the value of each to business processes, and, perhaps most importantly, the role of each in addressing customer experience.

Those applications that are determined to have high value and low modernization effort should be the first ones tackled. For high-value applications that are determined to be difficult to move, some approaches to modernization don't involve an all-or-nothing strategy.

For organizations that decide to update applications, it is important to note that many applications don't need to be completely rewritten from scratch. Instead, the organization can take the core "DNA" of an original software program and modernize it to better address current business needs.

Make COBOL applications ‘new’ again

Another possibility is rewriting existing COBOL code written in a more modern and user-friendly language, such as Java or C#. It is often necessary with COBOL to decouple the business functions from the rest of the program logic in order to make changes to it, which programmers know is not an easy task. A microservices approach enables an organization to break the application apart by function.

One way for organizations to avoid costly and often disastrous rewrite efforts is to modernize COBOL applications and train programmers to use modern COBOL as part of their overall development environment.

As Micro Focus' Britton wrote, cross-training those already knowledgeable in Java or C# in older languages such as COBOL or PL/I systems is "a relatively straightforward and cost-effective solution, compared to recruiting and training mainframe professionals skilled on traditional tooling."

If mainframe technology is made available to this new breed of IT professionals in the same way other technology is, through modern integrated development environments, then "embracing agile development processes also becomes not only possible, but very straightforward."

Many younger IT professionals may associate COBOL with dead languages, but Mark Conway, a director in the Micro Focus CTO Office, said that COBOL isn't going anywhere anytime soon.

It really doesn't make sense to keep rewriting things over and over, because "rewriting isn't the best value of the intellect of our software engineers," Conway wrote. COBOL supports many of the features from C# and Java, and it can run directly on .NET and Java platforms and compile to respective byte code representations.

"This allows in-process mixing of languages, and the ability to naturally exploit the power of these ecosystems," Conway wrote. "COBOL is far from the island you might think it is."

Read more articles about: App Dev & TestingApp Dev