This is the first of three blogs drawing from our modernization guide, Accelerating Application Modernization — A Practical Guide. In this post we will take up some of the typical modernization approaches on a high level. To read the full modernization guide, click here.
“Why is it taking so long?”
“Do we really need a 20-person team on this?”
“Why is the changed system misbehaving?”
Whether modernizing applications in place or undertaking refactoring after a massive “lift and shift” to cloud, we’re all faced with questions like these from our business stakeholders and leadership. They know our systems are complex, but have little appreciation for what that means, nor patience or funding for us to modernize. Not to mention the years of cost savings and turnover that deplete the collective knowledge of our legacy software.
We know we must continuously modernize some of our core systems to keep up with “digital” needs or take advantage of a cloud environment. But there’s no pleasure in having to resort to trial-and-error methods, software archeology leading to costly wrong turns, or unwittingly introducing production defects in the process.
Organizations undertake application modernization for several reasons, but the ultimate objective is to remain competitive in the fast-paced digital landscape.
Among all existing motivations to modernize thus far, we’ve seen several modernization archetypes that use five different “flavors.”
Do Nothing
With all the talk about modernization and cloud, it would seem this is not really an approach, but this is the most common modernizing approach taken by most enterprises today. Remember, we’re talking about application modernization here. Wrapping an application up and moving the virtual machine to the public cloud is precisely a “do nothing” approach. If you are accustomed to your enterprise system and are generally satisfied with its performance, you may choose not to make any enhancements. However, this can still be a missed opportunity to gain a competitive edge in the long run. This approach does not require any specific application modernization motions.
The Band Aid
As the name suggests, this approach consists of focusing on problem areas and implementing stopgaps to get the system working in new ways. This approach is also sometimes taken to opportunistically apply modern technology to legacy systems—melding the old and the new to improve the organization’s performance and productivity. These quick fixes are usually low risk as they’re surgical and simply put an end to specific issues. But, if not implemented with a good sense of impact on the integration points to the rest of the existing system, the approach could lead to unresponsive components.
Gradual Replacement
Wholesale application modernization doesn’t need to be done overnight. Some organizations take a planned approach to upgrade legacy systems one piece at a time, perhaps leveraging an open-source UI component to enhance the user experience or a database access framework to improve performance. The benefit of this approach is that you can quickly model future state by using off the shelf components to determine what works and what doesn’t. No need to overhaul the entire system when only certain elements need to be optimized. You can break the system into zones or portions—an advantage for those who want to test the waters when it comes to legacy system enhancements. However, having too many components and integrations may create compatibility and complexity issues.
Rip and Replace
For this approach, transformation is the bottom line. To take this approach there is usually a somewhat urgent need to retire the legacy system and rebuild a new one. Rip and replace is a complete overhaul, which may be very risky from a business stakeholder perspective. This is an aggressive approach to extend your organization’s competitive edge at a cost: it is resource-intensive and time-consuming. Although the solution is “high risk, high reward”, the major changes may create organizational adoption challenges for teams that are accustomed to their legacy processes.
Continuous Refinement
This is the ideal modernization cadence that should be the eventual end state for all critical applications. You can think of it as a thoughtful, intensive maintenance. When in this mode, the organization knows the application well, there isn’t a need to make drastic changes, and the team is comfortable making minor adjustments. These include cleaning, consolidating, and updating code. The system is in a healthy state and merely undergoes modernization to remove problem areas and inefficiencies, or to adjust to performance requirements. There is no urgency, and most changes are highly proactive. This is ideal for organizations whose existing IT systems serve their purpose well. The only danger of this approach is to fall too far behind the curve of the tech landscape, finding it hard to get qualified resources to support and update legacy systems in the future
Successful modernization is part art and part process. Because in many cases you don’t know what you don’t know about your existing systems, modernization projects are hard to predict and force into a specific process.
Stay tuned for part two of three where we'll discuss some of the the common motions of modernizations
SHARE