The Dimensions of 'Legacy Systems Transformation' Explained

The challenge of legacy systems has, until recently, been viewed as a liability with soaring costs attached to finding solutions. However, it is becoming evident that system modernization strategies can be built off of legacy systems in ways that will save the enterprise money.

The challenge of legacy systems has, until recently, been viewed as a liability with soaring costs attached to finding solutions. However, it is becoming evident that system modernization strategies can be built off of legacy systems in ways that will save the enterprise money. The most substantial obstacle is the strategy is different for each enterprise based on their current system architecture and their growth needs.

By forcing ourselves out of the “all-or-nothing” perspective with system modernization, some fantastic things can happen. In this article, we will discuss the challenges of legacy systems, how these systems have changed over time and the multiple dimensions of implementing modernized software systems in today's environment of technological demands.

The Challenges of Legacy Systems

Many elements of legacy systems contribute to the challenges of modernizing software systems. Their age, construct, and function all have a part. Difficulties can often define the types of systems they are, such as: programming languages that are predominantly out of use; monolithic architectures that allow for little to no connectivity between system layers, UI and application parameters; and systems designed for specific applications, maintained on-premise.

Enterprises with similar software systems to the ones described struggle between supporting current clients that rely on the obsolete systems and growing their client base by investing in new customers who demand a more modern approach.

There are strategies the enterprise can put together that can be used to bridge the gap between the old and the new, sacrificing little to accomplish their goals.

How Systems Have Changed Over Time

Software systems on the enterprise level differ from others due to their complexity. Structural requirements and differing business models all factor in on how systems have changed over the years. Gartner, a research and consultation group in the IT field, have been able to explain the changes to software systems over time in what they call the Pace-Layered Application theory.

In a Gartner report on Pace-Layered theory, it describes each layer as: Systems of record — established packaged applications or legacy homegrown systems that support core transaction processing and manage the organization's critical master data, with the longest life cycle at 10 or more years, since the processes are well-established and often subject to regulatory requirements. Systems of differentiation — applications that enable unique company processes or industry-specific capabilities, with a medium life cycle of one to three years that need to be reconfigured frequently to accommodate changing business practices or customer requirements. Systems of innovation — new applications built on an ad hoc basis to address new business requirements or opportunities, typically short life cycle projects of zero to 12 months using departmental or outside resources and consumer-grade technologies.

While implementing the Gartner pace-layers within enterprises for a software project, certain elements move swiftly and some slow. It is a balancing act that leadership must take on to ensure that transitions are taking place with a focus on both the short term and the long term. We cannot provide a roadmap that is a “one-size-fits-all” for all organizations though, because the magnitude differs depending on the nature of the software systems being used as part of the modernization efforts.

Varying Dimensions of Implementing Modernized Software Systems

The need for modernization is coerced predominantly by changes in technology and business models as well as the change in how the systems are being used and to what extent they are rooted in the system's architecture. It is beneficial that each dimension is defined and understood during the creation of transformation strategies. Other factors, including emerging technologies, current market conditions, budget demands, and application architectures, should also weigh heavily in addition to the four modernization dimensions defined below.

Modernized Deployment: in a modern deployment environment, it is essential to have a modern and capable deployment infrastructure of reliable and scalable implementation.

Forced Technology Enhancements: some modernization deployments go beyond the software level and require parts of technology to be upgraded for the modernization to work. Alternatively, perhaps the hardware is at End of Life (EOL), and future-proofing is necessary. In either case, prepare to analyze all technology holistically to ensure that the modernization process can be deployed as intended.

Modernized Applications: the goal in modernizing applications should represent a two-tiered approach, with a focus on moving away from on-premises, monolithic application stacks to feature a new design and hybrid (Cloud + on-premise) architecture with SaaS capabilities. Moving to a migratory center for subsequent implementations that are modular and services-based remains the key to having modernized applications.

Changing Business Models: as indicated in Gartner's pace-layered theory for Systems of Innovation, some require ground-up systems that perform specific tasks. In this case, ensure the long term with technology, including AI/ML and VR/AR. Additionally, limit the focus on a modular approach to the design and maintain all design within the agile discipline.