A few years ago, re-writing so called legacy applications was often considered as the main method for IT modernization. Some global Enterprises reached the unfortunate decision that in order to reduce the risk of maintaining their core business applications and to embrace technical trends du jour, applications needed to be re-written in a ‘modern language’.

The results of those huge and predominantly unsuccessful projects were published every now and then (like this one, or this) but generally, it became clearer and clearer that this approach is often not the right way to modernize business critical systems.

I won’t bore you with the statistics, the cost calculations or with our own customers that considered or even started re-write projects only to realize that better solutions exist.

Today, analysts and experts are leaning away from rip-and-replace and towards continuous modernization. Gartner, IDC and Forrester all discuss this in their research papers.

Recently, we’ve started to encounter the term: Refactoring. But is refactoring actually just another word for translating legacy languages such as COBOL or PL/I to different languages like C# and Java?

What is refactoring?

Refactoring consists of improving the internal structure of an existing program’s source code, while preserving its external behavior according to agilealliance.com. The noun “refactoring” refers to one particular behavior-preserving transformation, such as “Extract Method” or “Introduce Parameter”.

Splitting large programs to smaller pieces of code is a good example of refactoring, renaming enigmatic data items into meaningful, self-documenting names is another. Calling the conversion of millions of lines of proven COBOL code into another language, with the obvious risks of losing the logic and business rules, refactoring is a stretch at best.

The agilealliance.com continues with listing the common refactoring pitfalls. The first is that refactoring does not mean rewriting code. Or as Wikipedia warns in its code refactoring entry:

‘This article is about a behaviour-preserving change. It is not to be confused with Rewrite (programming)’

But real refactoring is a good practice, so how can we use it when modernizing core business applications?

Knowledge is key – Application Intelligence to the rescue

When we go about modernizing core business systems, we first need to assess what we have and plan what would good looks like. Basically, we have to answer 3 questions:

1. What is the business logic that the system implements?
2. What do we need to modernize?
3. What is now redundant?

Using advanced tooling (like this one for distributed COBOL apps  or this one for mainframe apps) allows us to get those answers much quicker than traditional, manual methods. We can build or update our documentation and business glossaries, or even use special techniques that help capture business rules.

With that information, we are now able to start considering our new architecture. Will it be Application as a Service (AaaS)? On premise or on the cloud? Microservices or the more traditional SOA? Will it be virtualized? Containerized?

A large NA transportation organization is currently taking this approach to break their application up into a set of services which they are making available to other groups within IT.  They are “re-branding” their application internally and positioning their environment as an AaaS or Application as a Service type setup. With today’s modern COBOL support, the sky (or the cloud) is the limit.

Refactoring as a way to break a monolithic application

While refactoring is not a modernization silver bullet, it does help for most applications.

There are many good materials and courses on this subject, but I chose to focus on 3 examples of good refactoring practices that will help smooth any modernization project:

- Breaking large programs to smaller units - This will help in maintaining the code and allow reusing business logic more easily:

- Separating IO and business logic – This will make it easier to replace data stores and de-couple from specific platforms (VSAM to relational database, DB2 to cloud service etc.) (More on that here)

- Removing ambiguous names – Programs, paragraphs and data items are just a few examples. Renaming them with meaningful names helps with code readability and lowers the learning curve for new developers (Here’s a blog on how to do that in COBOL)

Starting with those 3 examples will take you a long way forward. So, what’s next?

Continuous modernization – A safe and cost-effective path

Armed with application knowledge, refactoring techniques and a clear vision of our target architecture, genuine application modernization can begin.

Just like any other software project, we can leverage the latest methodologies, embrace DevOps, adding an automation testing infrastructure and implementing a modern Software Development Lifecycle (SDLC) for starters.

We can begin to identify the tasks, prioritize them by business value and effort and define the expected outcome (sometimes referred to as Definition of Done or DoD).

Adding automated tests to every modernized component and utilizing code analysis for maximum efficiency are highly recommended components.

Summary

With customers testifying that 85% of their COBOL applications are critical for the business, modernizing them should not be taken lightly.

Unlike automated conversion tools, real refactoring can help with modernizing legacy applications. And with today’s modern COBOL and application intelligence tooling (See this recent case study), you can safely take your core business systems to the digital era.

For further reading about core business systems modernization, I highly recommend the recently published Modernization Maturity Model which is a new Micro Focus framework for planning and executing such programs.

If you want to try out the products that were mentioned in this blog, we now have our leading development and analysis tools available for trials on the Azure marketplace.

And lastly, for additional information, contact your local Micro Focus office to ask about our complementary Value Profile Day where our modernization experts will explore the multiple options that are now available for your organization.