Since the first enterprises replaced their aging vacuum tube systems with newfangled solid-state technology, modernization has been an expensive, risky endeavor. Over the years, as one generation of hardware and software replaced another, IT executives continued to struggle with the core challenge: leave older technology in place and make do or take the riskier path of rip and replace.


Table of contents:

This dilemma invariably led to the increasing prevalence of legacy—essentially obsolete technology that nevertheless remains in place because IT leadership deems replacing it as too risky and expensive to maintain – assuming the skills to do so are even available.

Today, however, the world has changed. IT is no longer simply a cost center in the enterprise. In the digital era, software has become strategically important as companies reinvent themselves as technology-driven organizations.

Prior to 2020, enterprises could carefully plan and budget modernization projects, with some projects taking years to complete. During such projects, companies would have to put any innovation efforts on hold, stifling the business’s ability to achieve its requirements and in many cases, allowing competitors to steal market share.

No longer can such forward-looking enterprises skewer themselves on the legacy dilemma. There has to be a better way of looking at modernization.

Exploding the Modernization Dilemma

Over the last 20 years or so, one innovation after another has chiseled away at this black-and-white legacy challenge.

Modern vs legacy: Louvre and pyramid 

In the early 2000s, web services brought loose coupling to enterprise integration, easing the task of replacing individual components in complex, interconnected deployments. Toward the end of the decade, REST proved to be more lightweight and easier to adopt than web services, greatly simplifying the task of modernization in a modular environment.

At the same time, virtualization came to the forefront, bringing a comprehensive abstraction layer that isolated software challenges from the underlying hardware. This technology made it possible to separate the question of hardware refreshes from the equally challenging discussion of software updates.

Cloud computing and, in turn, containers and microservices built on the advances of REST and virtualization, further cementing the layers of abstraction that enabled organizations to take an increasingly modular approach to modernization.

The result: modernization is no longer a two-sided dilemma. There are now many options to add to the mix.

In some cases, it’s possible to modernize software in place—for example, on mainframes, as modern mainframe technology enables organizations to continue to use the venerable hardware platform as they modernize its software. In other situations, it’s possible to “lift and shift” and move software from less flexible platforms into the cloud.

Some enterprises initiate lift-and-shift efforts to save on processing and maintenance costs, However, depending on the system, lifting and shifting simply extends existing problems. Many IT leaders soon realize that it’s possible to fine-tune the system to take advantage of the architectural benefits of scalability, elasticity, and on-demand availability as well.

With the rise of microservices comes a third, relatively new trend: modernizing elements of complex, distributed applications while leaving other components alone―or more generally, updating different parts of such applications on different schedules, depending upon the needs of the business.

Today’s businesses require change and innovation. Real-time customer updates and streamlined partner interfaces, all while cutting costs and time to delivery. The business can’t wait for IT to deliver.

Low-Code: Essential to Workload Centricity

From the software developer’s perspective, there is far more going on with today’s modernization than in the old days of the rip-and-replace dilemma.

True, in some cases, the business requires entirely new, bespoke applications, but it may just as likely need to add new user journeys and integrations to existing applications or build new applications by composing capabilities of older apps. And of course, as business processes have changed and the existing technical debt is high, a full rebuild may be necessary to keep the company and its systems competitive. Clearly, traditional hand-coding is too slow and too inflexible to meet such a diversity of software development requirements. DevOps brings greater collaboration and speed to bear but still falls short if the focus remains on hand coding.

It’s no coincidence, therefore, that low-code approaches are becoming increasingly the norm in today’s enterprise modernization efforts, especially when developers use an enterprise low-code platform like OutSystems.

Such platforms support bespoke development and microservices-centric modernization that adds new capabilities to existing systems of record or other legacy assets with a minimum of hand-coding.

In addition, low-code boosts productivity and reduces the mundane tasks for r professional developers, thus increasing the speed of deployment. They can shift their focus from the minutiae of the code to the greater role of each workload, consisting of all the technology elements that support running applications.

The Central Role of the Workload

The increased focus on workloads that low-code facilitates is, in fact, central to the modernization story.

On the one hand, CIOs can breathe a sigh of relief, as they now have more tools in their toolbelt for dealing with modernization. On the other hand, however, the plethora of choices is itself confusing, and IT leaders may still struggle to understand the best course of action for their circumstances.

Fortunately, today’s architectural context for legacy modernization addresses this complexity by focusing on the role of the workload rather than the age of the technology.

We can think of workloads as portable and abstracted from their execution environments, centering on supporting running applications that meet customer needs rather than complex assemblages of software that depend on diverse execution environments.

Such workload centricity simplifies the modernization challenge. Companies can run old applications whenever doing so meets the customer's needs as part of a modern architectural context that takes advantage of today’s cloud-native IT benefits.

At the same time, adding new capabilities to existing applications or running workloads consisting of all-new applications (or any combination thereof) becomes a practical reality. This is especially true when the organization uses low-code to support the variety of application development needs such modernization requires.

The Intellyx Take

At one extreme, legacy modernization means extending or refactoring a legacy app using new technology but preserving its existing architecture. At the other extreme, it means a complete rewrite of the older app.

Rarely if ever are these extreme cases the best answer for meeting the needs of the business. To achieve the right balance, it’s important to understand the desired architectural context. For example, is the goal to have a containerized microservices app? Will it be entirely in the cloud or hybrid?

It’s also important to understand the business’s need for modernization. Does it require new functionality or user journeys? Or new non-functional capabilities like greater scalability?

Given these architectural and business considerations, low-code provides a way to build just what the business needs in terms of the most appropriate architecture, without erring on the side of either modernization extreme.

Copyright © Intellyx LLC. OutSystems is an Intellyx client. At the time of writing, none of the other organizations mentioned in this article are Intellyx clients. Intellyx retains full editorial control over the content of this paper. Image credit: Christopher Dart.