Think practically about software modernization
Some businesses start software modernization projects to add sophisticated features, such as artificial intelligence and mobility, but that may be akin to icing a moldy cake. Software teams can add new application architectures, technologies and platforms as separate projects, but experts say they should use modernization projects to address the core weaknesses of legacy applications.
Traverse Clayton, a Gartner analyst, explained the reasons organizations should tackle software modernization projects in a recent interview.
“The primary drivers for application modernization are encroaching obsolescence and massive amounts of technical debt,” he said. If a legacy app doesn’t foster agility, likely culprits are platform, language or developer skill obsolescence.
It’s a mistake to fold mobility and AI adoption into modernization projects, Clayton added. He said that less than five percent of current or in-flight modernization programs mark mobility as a key concern or goal. Likewise modernization has almost zero to do with AI (artificial intelligence).
“You can modernize the data from your application, which is then available for analytics and AI workloads,” Clayton said. But the only time AI and BI rear their heads is when the organization looks to do something different than it’s ever done before, which is a small percentage of companies, he added.
Who’s ready for software modernization?
Typically, large corporations have aging systems and massive amounts of technical debt, Clayton said. Because of that debt, many companies aren’t nearly ready to modernize. Their Agile and DevOps skills are not adequate to support modern architectures.
Some alternatives to software modernization include a rehost (e.g. Lift and shift) or a replace strategy, since those require less of an engineering effort, Clayton said. However, there is some backlash to this approach, as rehost projects often fall short of the goals. Typically, the stakeholder’s goals and expectations are greater than what a rehost can deliver.
Many enterprise DevOps teams go back to the drawing board and assess refactor, re-architect and rebuild strategies to realize better ROI and reap the benefits of cloud, Clayton said. This often involves an assessment of various PaaS options.
Software modernization tactics
In successful software modernization projects, teams prioritize the portfolio and rationalize which initiatives will provide the most value, Clayton said. During this process, project teams should use maturity assessment approaches, such as the Capability Maturity Model (CMM) and PACE (Product and Cycle-Time methodology). These assessments can help organizations create business value heat maps. Gartner features its own maturity assessment methodology called the Gartner IT Score.
When developers and architects modernize a particular platform, somebody needs to understand everything that is in the current environment, Clayton said. This is traditionally called applications rationalization. In software modernization, application rationalizations need to document every data flow, code flow and connection between every application.
“This data, which is normally stowed in a CMDB (configuration management database), needs to be overlaid with the business processes of the organization,” Clayton said.
Once business processes have been overlaid atop the CMDB, the software modernization team must determine which business flow uses particular assets within the company. These are the only assets an organization should move during modernization, Clayton said.
Applications that are not subject for investment or modernization must be consolidated on the remaining platforms which exist in ecosystem today. All of these applications must then be targeted for retirement or replacement or integration into other applications, to prevent having to run legacy platforms in a modern data center.