As data becomes an increasingly strategic asset, enterprises are turning to legacy application modernization to keep valuable data from being siloed in older databases. They see opportunities to mine their data for insights, reduce costs and reap competitive advantage, but they know they must move beyond their legacy applications first.
What is a legacy system?
Legacy systems, outdated software still in use, have operated for years or decades, relying on older technologies. Despite modern advancements, these systems remain vital in various industries. IBM applications, popular for their robust platform, are crucial in manufacturing, finance, distribution, and healthcare, providing stability and ongoing value despite their age.
Legacy systems emerge when they pose these typical challenges:
- Increased IT costs for maintenance or updates
- Code bloat or integrated hacks can cause performance issues
- Hindered onboarding for new IT staff due to complex code
- Lack of support for third-party components
- Incompatibility with modern systems
- Reduced agility to meet evolving customer needs
- Potential security or compliance risks
What is legacy application modernization?
Legacy application modernization is the process of transforming legacy IT systems, applications and processes to remove data silos and set the organization on the path to data empowerment.
Digital transformation is the organization’s broader effort to improve efficiency, become more innovative and drive growth. As part of digital transformation, a legacy application modernization strategy occupies the technology branch of the people-process-technology triad. You assess the needs of your business, decide what to modernize first, assemble a plan and implement it.
Below we describe eight steps for creating a legacy application modernization strategy. Use them as a structure as you develop your own business case and build out your plan.
Step one: Identify the benefits and build a business case
Any initiative this far-reaching deserves a business case. In legacy application modernization, the point of departure for the business case is to evaluate current applications and dependent systems, then prioritize them according to benefits, costs and risks. In most companies, the business case centers on some combination of the following drivers:
Business case driver #1 – Unlocking the value of data in legacy applications
Especially in established companies, certain business applications tend to impede progress toward digital transformation.
They run on legacy hardware like mainframe computers, or they depend on legacy programming languages like COBOL and FORTRAN that are not lightweight or modular. They don’t take advantage of modern databases and they’re not designed for open APIs and access to other applications. And of course, they pre-date cloud computing by at least a generation.
In assessing the benefits for your company against the costs and risks, focus on how the steep investment in legacy application modernization will drive the business forward. Salient metrics include increased customer satisfaction, lower maintenance costs, more agility and greater scalability (see step six below).
Business case driver #2 – Strengthening security
Security is the other side of the coin.
Legacy or out-of-date applications are notoriously vulnerable to cyberthreats. Consider the Oracle Database, which some companies are slow to upgrade. Eventually, Oracle moves on, as any software company would, discontinuing support for further upgrades to versions 11g and older because maintaining those versions no longer makes good economic sense. Oracle prods its customers to upgrade to the latest supported version and continue receiving the latest security patches.
Security becomes a prominent factor in the business case because vulnerability and exposure are the non-financial cost of sticking with legacy applications and platforms.
Business case driver #3 – Regulatory compliance
Next is the matter of all the sensitive data you’re holding in legacy applications and systems. You’re on the hook for compliance with data privacy regulations like GDPR, CCPA and HIPAA, even if your legacy systems pre-date them.
Do you know how much sensitive data you’re storing and where you’re storing it? Keep in mind that you could be out of compliance. If you suffered a data breach or were audited, you would have financial exposure from fines and penalties.
Business case driver #4 – Protecting your reputation
Beyond your financial exposure from non-compliance is the potential for damage to your reputation and brand.
Think about the companies that have been in the headlines for GDPR non-compliance. How would you feel about doing business with them and entrusting your data to their care? You probably wouldn’t want to risk the exposure of your or your company’s data to an organization that is asleep at the switch when it comes to compliance.
You can impute to your own customers and prospects that same aversion to risk and factor it into the business case you build around legacy application modernization.
Step two – Inventory data and map to business processes
Once the business case is approved and the direction is clear, the next step is to take inventory of all IT assets including applications, systems, business processes and databases.
In a joint effort between the business community and the IT community, you’ll take inventory so you can answer several important questions:
- Where is our data?
- Where are our systems and infrastructure?
- Which applications are we supporting?
- What’s the relationship among our applications?
Data
Of those, we believe that #1 has the least room for error. It’s always important to know where in the organization your data resides. You can know where your applications are, and you can be aware of all the complex interdependencies among them. But most organizations have a certain amount of “dark data,” which they store without knowing exactly what it is, where it is or who has access to it. Dark data often originates with the drive toward big data, when organizations consume all the data they can and store it in data warehouses and data lakes.
But merely having a lot of data doesn’t make you smart. The real business benefit lies in deriving useful information and insights from the data and making smart decisions that drive your business forward. So the trick is to understand where your data is, where it belongs, who has access to it and which applications use it. Then you apply advanced analytics to make the data useful, reduce its time to value and get a return on your investment in harvesting the data.
Inventory – Manual vs. automated
All of that begins with an inventory, and the more you can automate the inventory process, the better. Manual inventory methods rely on the institutional knowledge stored in people’s heads. If those people have left the company, then you end up with servers and databases that no one can access and that are as likely useful as obsolete. The decision about what to do with them becomes a detour on the road to your inventory.
Conversely, by intelligently mining your data and pulling it into a metadata repository, you make it easier for both business users and IT to survey the data landscape. That increases their data literacy and ensures they understand what the data represents, what it’s for and how to get value from it.
Modernize it or not?
Your inventory helps you determine which applications to modernize. But in some cases, you may decide against a legacy application modernization, leaving the application as it is instead.
Security and specialization often figure in this decision. For example, your application may handle highly sensitive data or trade secrets that you don’t want to entrust to a public cloud provider. Or it may be a specialized application that doesn’t lend itself to being re-platformed; the expense of completely rewriting it would be prohibitive.
At that point, the decision is rooted more in finance than in technology, so it’s a call for upper management.
Step three – Consider legacy application modernization strategy options
At this point, the business turns to the enterprise architecture team and says, “We want to modernize these applications. Can you figure out the best way to do that?” The team then makes decisions on issues such as migrating to the cloud, running the applications on a new platform and re-writing them.
Gartner has identified seven legacy application modernization options and ranked them by ease of implementation. A simpler analysis would be to choose among the following common options while taking cost into consideration:
- Re-platform – Change the technology stack and leave the application as is.
- Re-architect – Recreate the application and re-platform the technology stack, which could be very expensive and time-consuming.
- Refactor – Re-design and optimize the application, if the technology stack has already been modernized.
In devising its strategy, the enterprise architecture team works to mitigate any risk from legacy application modernization. Instead of modernizing across the entire organization, they select a project or business unit with limited exposure in case of problems. They look for an opportunity to provide some value to the business while learning lessons along the way that they can then apply to the to the next modernization.
Step four – Determine the architecture
Then, given the chosen strategy, the team figures out the best-suited architecture at three main levels: application, database and platform/server.
- Do you want the platform/server in your data center for greater control, or in the cloud to reduce capital expenditure (CapEx) and increase operating expenditure (OpEx)?
- If the application runs well as it is, do you opt for a less-expensive, open-source database like MySQL or Postgres? That will entail re-platforming the application to run on the new database.
- Do you want to move both the application and the database to the cloud instead of your data center? That entails greater expense in the short term for lower IT headcount in the long term.
- Do you opt for a hybrid cloud, mixing public cloud services and existing data center resources? Or do you distribute your assets among multiple cloud providers?
Although these decisions are in the purview of the enterprise architect, they have ramifications for the business as well. That’s because another element of legacy application modernization is accelerating value for the business — the value of your company’s unique, innovative applications and services, and the value of your company’s data. For that kind of acceleration and value, the architecture you select must support automated processes and technologies like DevOps, DataOps and other pipeline delivery mindsets (see step seven below).
So, you can say, “We need to automate our software delivery and data delivery processes, but let’s automate them in the cloud.” That’s a good idea, but first make sure that the pipeline tools you use for software builds, deployment orchestration and version control work in the cloud.
That’s why legacy application modernization entails more than just putting everything in the cloud.
Step five – Select the team to implement the strategy
The staffing hierarchy of most legacy application modernization projects breaks down as follows:
- C-suite execs — chief information officer (CIO), chief technology officer (CTO), chief information security officer (CISO), chief security officer (CSO) — drive the initiative from the top. They decide which people will staff the modernization effort.
- The enterprise architecture team reports to them.
- The IT teams and the business teams act as contacts for their respective communities.
The enterprise architecture team reconciles the needs of the business community for products and services with what IT is capable of delivering. The team is also responsible for coming up with the details of a legacy application modernization plan that will achieve the overall business strategy.
Step six – Determinine success metrics
The best way to gauge the success of your legacy application modernization is to choose metrics based on your original motivation.
A recent report from Rackspace shows several commonly desired legacy application modernization outcomes, including these top five in descending order of prevalence:
- Improved customer satisfaction (54%)
- Increased employee efficiency and satisfaction (47%)
- Using data-driven insights to improve customer engagement (40%)
- Strategy to enter new markets (37%)
- Security improvements to reduce operational risk (35%)
Success metrics are tied back to the data inventory in step two. The better you understand what data you have, the more likely you can derive data-driven insights for improving your legacy application modernization outcomes.
Step seven – Automate the implementation
As described in step four, legacy application modernization is about accelerating value for the business, which requires automation.
DevOps
To stay ahead of the competition and drive growth, your users need to see your applications improve daily or weekly, instead of once per quarter or per year. That’s why your modernization strategy should include accelerating your software delivery cycle to provide value to the business faster. Ultimately, that depends on automation.
This is the domain of DevOps — using automation and collaboration tools to deliver application and data changes to the business more quickly.
DataOps
The last thing that data analytics teams want is data that’s stale. They need your latest data to make the right strategic decisions and move the business forward. So your legacy application modernization should extend to accelerating your delivery of data for use in machine learning (ML) and advanced analytics. Again, that is possible only with automated processes, this time in the form of DataOps.
DataOps is an automated pipeline connecting the business need for access to high-quality data with IT’s ability to collect that data from sources all over the enterprise. As in software delivery, the goal in accelerating data delivery is to get data from wherever it resides into the hands of analytics teams and data scientists so they can continuously mine it for insights.
XOps
The value of tying various functions to Operations has led to the term “XOps,” indicating an approach to reducing duplication by increasing collaboration. The goal is to combine team collaboration and automation technologies to break down the traditional silos between business and IT. The process brings representatives from those teams to work on common projects together instead of separately.
Consider the example of making application changes and deploying them to a production environment. The software developers make the necessary code changes, which then traverse several different stages, such as code testing, user acceptance testing (UAT) and staging, on the way to production. The process is made slower because the people involved work in different areas of business.
Well-established automation software products exist for:
- high-level orchestration across an entire organization
- building and deploying changes to database code
- version control with limited access and check-out/check-in with full change history
They let you deliver high-quality code that is free of defects and low on technical debt. After each stage in the process, the code moves automatically to the next stage.
XOps applies to accelerating processes from beginning to end, with built-in safety checks that ensure you’re not compromising quality. The automation and collaboration minimize human error, offer more consistency and bring greater agility to your organization. A survey by McKinsey shows that the adoption of DevOps, for example, and increased developer velocity can help drive 20% higher operating margins and 60% higher returns for shareholders.
Step eight – Monitor and optimize
The benefits of legacy application modernization are not always automatic. Nor are they always immediately obvious. So, your strategy should include monitoring and optimizing at the end of the project. Weigh these factors as you study the landscape of available tools:
- Consider how to monitor the performance of your modernized application to ensure that it meets the needs of the business and that it runs within budget.
- With fewer skilled operations personnel and an increasing diversity of platform types, trying to use multiple monitoring tools will be cumbersome. Home in on as few tools as you need — preferably one.
- If the legacy application modernization involves the cloud, plan to monitor not only the performance in your environment, but also the cost of cloud computing. Although many companies turn to the cloud to lower costs, they must be smart to enjoy any financial savings.
- Put in place sound data governance and data protection.
- Promote data literacy, ensuring that data consumers in both the business and IT can find, understand and use data in a meaningful way, given their different perspectives.
Conclusion
The main goal of legacy application modernization is that the business and IT both have a better understanding of the data landscape across the enterprise.
Legacy application modernization also ensures resilience. You want to shield the brand-new application you’ve spun up in the cloud from inadvertent, crippling changes due to a mistake on the other side of the organization.
Finally, legacy application modernization gets the business and IT on the same wavelength, balancing the needs of the business against the ability of IT to deliver on those needs.
