This content is part of the Essential Guide: Essential guide to application modernisation
Manage Learn to apply best practices and optimize your operations.

Companies see growing need for application modernization

Legacy apps don't live up to today's needs. Whether they like it or not, organizations are becoming more aggressive about application modernization.

Application modernization is by no means a new concept. But with the cost of maintaining a growing body of legacy...

applications and the need to deliver IT services to an increasingly mobile workforce, application modernization can no longer be ignored. Whether they like it or not, organizations are getting more aggressive about application modernization.

A "considerable amount of bull" is associated with application modernization, according to Tom Nolle, president of CIMI Corp., a full-service telecommunications, media and technology consulting firm. "The problem is when you talk about application modernization, you're talking about an activity without a driver," he said. "It's essentially a project without a benefit because modernization within itself is not a goal. Modernization is a description of what you're doing in response to some stimulus. You have to go back and look at the question of what's doing the stimulating."

According to Nolle, two primary stimuli are driving application modernization. "One is changing my application because I need to do a better job of productivity enhancement, or I'm changing my application because I need to reduce the cost associated with running it," he said. "On the productivity-driven side of this, by a fairly large margin, the changes we're talking about fit in one or both of two categories: either a mobile worker productivity enhancement or big data utilization. On the cost reduction side, we're talking principally about virtualization and the cloud."

Pressure grows to modernize apps

Professional services firm Capgemini surveyed IT professionals in 2011 and 2014 to identify trends in application modernization. The results echoed Nolle's take on the space. "In 2011, many CIOs were frustrated by the sheer size of their application landscape, which is often complex, outdated, difficult to manage, redundant, overlapping, far too expensive, and very frequently consuming more than 80% of the IT budget to keep it alive," said Capgemini's Ron Tolido, senior vice president, group CTO office, and advisory and architecture lead of the global insights and data practice.

Because of the size of an application modernization project, Tolido said, "Many people are intimidated by it and are thinking, 'Let's wait for the next CIO to pick it up.'" However, the results of Capgemini's more recent survey indicate that businesses aren't giving IT much of a choice in the matter.

"The next gen of solutions -- cloud, mobile, big data-driven -- all of these are obviously very much on the radar screen on the business side, so we found there's much more pressure now to modernize because of this wave of applications," Tolido said.

Three approaches to application modernization

Dale Vecchio, research vice president at Gartner, identifies three approaches to application modernization. Noninvasive modernization involves taking an application that may have been internally focused and exposing it to be consumed in new ways, as through a service or Web front end, he said. Invasive modernization involves rewriting an application from scratch on a new platform. A package migration is what it sounds like: replacing the application with another application altogether.

According to Capgemini's Tolido, extending existing applications with mobile interfaces continues to be a popular option for application modernization. But increasingly, companies are choosing to replace applications with software as a service. "This is remarkable to us," Tolido said, "because if you built an application yourself in the past, you considered it be so special it would be impossible to replace it. In 2014, it turned out to be the most favorable way of modernizing the application landscape. This is a much more radical, extreme scenario that just a few years ago was considered taboo. You simply didn't replace something special with something that's highly standardized."

"The pressure [to modernize] is mounting," Tolido said, "and has obviously increased from just a few years ago. More CIOs are ready to do more radical things to break through the inertia of the existing application landscape."

Cost, skill pressure force hard decisions

Vecchio agreed: Companies "are continually dependent on a declining implementation, and the vendors may not be innovating, or may not be supporting the application, or it may be running on hardware that may not be supported or, depending on skills, that may be associated with baby boomers who are in the decade of retirement, so it's forcing people to make more aggressive modernization decisions than they may have made in the past."

He added that "cost and skill pressure will force people to take different approaches to modernization over the next five years. Why would I wrap a legacy application that's running on a hardware platform and language and old database for which I don't think I can find skills and support? I've put lipstick on the pig, but it's still a pig."

Next Steps

Mobile computing drives modernization

Consider these perspectives on application modernization

Dig Deeper on Application modernization

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

What are some common issues you've encountered during application modernization?
I agree, the stimulus for a change that I have noticed has been more to contain the cost of running such systems. It is true that the next generation solutions (cloud, mobile, big data-driven) do attract the business prompting them to make investments in new capabilities but for legacy applications, most organizations have gone after the low-hanging fruit of migrating legacy applications to some form of bare metal hypervisor. Such infrastructures offering better availability, performance and scalability for a lower cost is hard to ignore.
Fixing the infrastructure layer may not yield long-term results. Retrofit legacy applications for next-gen functionality can only go so far as they were originally designed for any way. Today, I see many legacy applications in-use that were packaged software implementations now obsolete and barely running on some form of assurances of best-effort maintenance support. Complicating this further, customizations made to these implementations prevent a transition to replacement package implementations without a loss of functionality. Far from adding the needs of tomorrow, are they ready for today, I wonder... surely the CIOs have it on their minds. One can only expect more of this with M&A of the software vendors.
I hope to see organizations go for a more comprehensive solution. This makes a true case for an investment in Enterprise Architecture. We need an effort that builds a purpose to change and is driven by the stakeholders. Follow this with a deep understanding of the data and application assets that exist today, their needs and role in the current business process. Add the components that are desired. Now, this should lead to a new technology blueprint. We have a foundation that gives organizations a confidence in building an infrastructure that fits the business needs of today and into the future. Organizations who work with technology agnostic architects tend to be more successful in realizing the benefits of a migration plan rather than tweaking at the technology layer. Building an iterative cycle with these concepts is well documented (e.g. TOGAF to name one). This is something that I hope decision makers at the appropriate levels adopt.
Dale is right, the requirements for core applications are driving different approaches.

For example, we just completed a modernization project with the Metropolitan Transportation Authority in NYC, where they chose to convert just the batch as the first step in their cloud strategy:

Rick O.