A CIO’s Guide to Legacy Transformation

As a CIO, if your enterprise relies on solutions that look like something out of the 1990s, it's often because that's exactly what they are. These applications - ERPs and home-grown core operations systems met an immediate business need at the time, then layer upon layer was built on top and entrenched into the foundational processes of the business. Now you are at a catch-22: pressure to modernize to meet the growing digital needs of the enterprise, while at the same time not risking the legacy software that is vital to day-to-day operations. 

How do you prioritize legacy transformation as part of a digital transformation roadmap?

Step 1: Where would change result in the highest ROI?

Do you know what specific IT functions would yield the highest return on investment (ROI) if you updated them? There are typically 3 drivers for legacy transformation:

1. Improving enterprise processes that are closely tied to revenue or business value, for example through enhanced usability or automation.
2. Updating process bottlenecks to improve operational efficiency and save costs
3. Modernizing systems that are at end-of-life

Surface high-ROI opportunities for process improvement. Has your enterprise documented its core processes with process maps? Is it clear which processes tie directly to revenue or business value, or which are a bottleneck to operational efficiency? Often it's the usability and flow of screens such as dashboards and main pages that in-house users or customers interact with on a daily basis to accomplish their primary tasks. 

Back it up with usage data. Of course, stakeholders will point you to potential areas for improvement: replace the ERP system that is nearing end-of-life, or update the home-grown customer portal with a new off-the-shelf solution that offers a fresh user interface and more self-serve automation. Whatever recommendations you hear, be sure to back up the claims with data. Does the helpdesk ticketing system indeed show that these are the biggest areas of frustration? Have customers indeed been asking for an updated portal? Use hard data to separate pet project ideas from real-ROI digital transformation opportunities. 

Assess system lifespan. It is usually not hard for a CIO to learn which systems are nearing end-of-life, however it’s important to distinguish which of these are truly in need of an immediate transformation. Developers who spend a lot of time with an old system will naturally tell you all of its shortcomings, but do you have an objective cost assessment of what will happen if the system stays in place for another 5 years? Tally up the cost of specialized staff, licenses and support to maintain the legacy system and the opportunity cost of projects you can’t take on because the system is holding you back. If those support costs are far higher over time than a legacy replacement, now you have an objective case to consider a system replacement. 

Consider what will happen if you don't change: Examine the risks of updating your product, and factor in the risks of not making improvements into the equation. Staying with the status quo might look like the safe option, but your ROI analysis must also take into account opportunity cost. 

An enterprise CIO should be constantly updating a spreadsheet of opportunities with rigorous data that make the case (or not) for investing in transformation. Once certain opportunities bubble up to the top with a clear ROI, that’s when it’s time to start planning the roadmap.

Step 2: Define your evolution path based on rigorous user research

Once you are considering a potential digital transformation, it’s important to conduct the appropriate user research - such as a series of usability tests, contextual interviews, or ethnographic studies - to understand how to make it a success. Unbiased research should guide the evolution path, not just internal management’s opinions.

Define the target personas. Enterprise IT portfolios are often large and complex because they serve so many types of users -- sometimes 20-30 different groups -- without prioritization. One you have a sense of which areas represent the greatest opportunity for improvement, we recommend clearly defining user personas within the enterprise that would be most impacted by the transformation.

Make part of your research observation-based: Talking to end users is necessary to glean true customer insight, but it's not enough by itself. You need to put the ideas you get from talking to customers into a wider context. You do this using data from other research techniques, particularly observational research -- watching users work with the product in their real-world environment and understanding their unspoken needs. Often, what users say they want and what they actually need are different. Proven user observation techniques are the key to discovering the latter.

Any improvement you make is likely to affect someone who pays for your current product. Long-time users become so engrossed in the processes they know that they feel any change disrupts their way of doing business. They're likely to be irritated and very vocal about things they feel affect their bottom line, even if it benefits them in the long term.

Step 3: Get a technical analysis to determine your options

One of the biggest constraints product teams face is the existing code base and software architecture. The code base is often a tangled mess of legacy "spaghetti" code, silos, and stateless protocols that are not aware of what is happening in different parts of the screen. The plan you put together to evolve this code base is critical. 

Assess your ability to develop an API. One of the first things your team should examine is the ability to put all the system's business logic into a separate code layer and wrap it with a clear API, if not done already. In a legacy system, the business logic is often the biggest opportunity for code encapsulation and re-use because it contains rules and exceptions that have evolved over the history of the product. Once you have a well-formed API, it can power new features, design changes, and extensions of the product onto new platforms.

This is easier said than done. Frequently, the UI code is intertwined with the business logic. Plus, if the code structure doesn't use proper relational database design practices, data manipulation code may also be intertwined with the business logic -- and that's assuming it's a relational database in the first place.

Your unit test or automated test framework is where your investment will pay off as you update the code to a more structured format with an API.

To COTS, or not to COTS?

For virtually any enterprise process, there is a plethora of off-the-shelf products offering the benefits of cloud, automation, AI, security and compliance, and continual upgrades handled by the vendor. Do your homework: read analyst reports, talk to other enterprise CIOs in your vertical about their experiences, and conduct an RFI to better understand vendors and how they compare. 
Important factors to keep in mind for COTS:

• Vendors promote a sprawling menu of options and possibilities to entice buyers, and it’s easy to get derailed from the actual goal of your transformation. Make sure you are clear on what you need the COTS piece for - a prioritized list of objectives - and rigorously ensure that the vendor best ticks off those boxes.
• A COTS implementation is still a custom implementation. Be sure to select a vendor whose implementation team you feel confident in, as this is often a bigger differentiator compared to product functionality and architecture.  Also make sure you have the right internal resources or consultants to work with the vendor.

On the other hand, enterprises that are looking to innovate, especially with customers, may prefer to create a custom portal, mobile app or voice app that more closely meets their objectives and represents their brand. This is usually best done with a digital acceleration partner.  

Step 4: Be clear on the objectives

You have identified your top transformation opportunities, the potential high ROI, the users impacted, and the options for “how” you could implement it. At this stage, before committing to the project on your roadmap, it is vital to get alignment on the objectives of the transformation: 

1. What it must achieve (the critical success factors). These are the most important outcomes you must achieve. Is it cost savings? Improved customer retention? Future-proofing a particular technology for the next 10 years? There should only be a few critical outcomes, and you will constantly check in on them during implementation. If the list is more than 2 or 3, this is a red flag that you may be promising too much, or not confronting stakeholders with the real-world trade-offs.
2. Nice-to-have outcomes. These are additional benefits that may or may not be realized, for example things that a COTS vendor might bring to the table (e.g. AI-driven features that might be tapped into in a phase 2)
3. What the project will NOT do. As Michael Porter says, the essence of strategy is choosing what NOT to do. So it is with digital transformation, where the CIO must set expectations on what the program will not achieve.