Last updated at Mon, 06 Nov 2017 21:42:21 GMT
Have you found that your organization is developing new applications that are cloud-based, but unable to move away from some established legacy systems? You aren’t alone. This legacy/cloud hybrid environment is far more common than you would expect. And when you look at the history behind these apps it does make sense. Any organization that has been around for more than a few years probably has some investment in at least one legacy application. Organizations that have been around longer may have software that was developed under models that are several generations removed from today’s demands. Cloud-based applications, (at least those that are designed well), can offer agility and flexibility, but what about legacy apps?
First off, what is a legacy app? In short, it is any app that is designed using techniques that precede current technology. That’s a nice way of saying that legacy apps are outdated. But that’s not really a fair assessment. Although the access and delivery model of legacy apps may be outdated, legacy apps often contain invaluable tribal knowledge, and hopefully provide critical functionality. Complete replacement of a legacy app often comes at the cost of discarding many “lessons learned” throughout the development, deployment, and maintenance phases of the apps themselves. In fact, since many legacy apps no longer have ongoing documentation, training, or perhaps patching efforts, it may not be possible to know how much rich knowledge such apps possess. These apps generally have grown and perhaps mutated over the years to meet the changing organization’s needs.
On the other hand, legacy apps are often monolithic and relatively static. They are tightly coupled with respect to both UI and data storage. They are often very difficult to decompose and transform into loosely coupled components or layers. And that’s exactly what’s required to modernize a legacy app and move to a cloud-based solution. But modernizing isn’t the only solution. According to the Software Engineering Institute, there are three primary approaches to handling legacy apps: Maintenance, Modernization, and Replacement. Let’s look at each approach.
Maintaining a legacy app is only a temporary solution. A legacy app requires infrastructure and personnel to keep it running. It is possible to virtually outsource legacy apps using Infrastructure as a Service (IaaS) or perhaps Platform as a Service (PaaS) cloud deployment models, but the core issues remain the same. That is, the underlying infrastructure may be version locked or may rely on physical controls (i.e. assumption of physical separation of servers in a data center) for ts security model. Even if a legacy app appears to be easily “transportable”, it was designed under a security environment that no longer exists. One common characteristic of legacy apps is that they require additional controls to provide security. Just moving a legacy app to a virtualized cloud environment generally requires adding additional layers of controls.
Modernizing a legacy app is often the most difficult option, but the one with the highest success opportunity (as long as you make it through the whole process). Although there is substantial effort required to modernize, the process has several compelling advantages. First, the process can minimize downtime. The modernization process is a multi-phase process of identifying business services, exposing them to external consumption requests, (i.e. new types of clients), and then eventually migrating the service to a new environment. All the while, the critical business services support ongoing use. If done well, users shouldn’t even know that their core business services are being moved. Additionally, the iterative process of identifying and handling business services helps retain the most important tribal knowledge. It sounds simple, but modernization efforts require substantial analysis, planning, development, and testing. Additionally, making legacy apps “play nice” with newer, loosely coupled applications and services can be difficult. Since many legacy apps don’t include rich APIs, exposing necessary services or data to external apps often requires new development on old platforms to create a service layer.
And lastly, an organization can simply replace legacy apps with a modern app that aligns with its service delivery model. This option appears easier, but relies on two crucial assumptions: 1) legacy data is accessible and can be migrated with minimal effort, and 2) existing legacy functionality can be replaced with minimal effort. Data conversion and functionality coverage are not trivial concerns. Before you decide to just replace legacy apps, ensure that you can convert existing data and provide sufficient replacements for each functionality requirement.
So, if your organization decides to either maintain a legacy app or engage in the process of modernizing, you’ll find yourself with one foot in each environment (legacy and cloud). Managing this hybrid footprint well is important to keeping your users happy. That means monitoring how well each environment services client requests. Don’t lose sight of supporting your users as you embark on a modernization project. If managed well, you can one day say goodbye to the legacy apps that have served you so well – and move forward with more agile and flexible apps.
