In this blog

Why modernize?

As a leader of technology, often you find yourself at some stage of modernizing your data center. You've done a good job embracing newer technologies like containers, serverless and microservices for your new applications. Your developers may even have some DevOps maturity. But then there are those other applications. They are on older platforms. They can be expensive to maintain. Perhaps the source code or the original developers are no longer available. Or perhaps they are COTS applications that have been so heavily customized, that you avoid applying patches and updates for fear of breaking something. Yet despite these difficulties, you preserve them because they are perceived to be essential to your business.

You'll quickly understand that there's no magic GPS that will tell you every turn to make.  Potential decision points, exhaustive investments, and overwhelming resource depletion are around every corner.  By now, most of us have heard of the Six Rs for rationalizing legacy applications. But when firms undertake such an analysis without a) having a clear business objective in mind, or b) not having the right information about their application portfolio to apply the Six Rs effectively, they run into problems. Time, money, and effort are spent trying to change applications for the wrong reasons or based on faulty assumptions about the applications' target future state architecture or platform.

Business drives results

As technologists, we are prone to viewing the world through the lens of technology features or the latest shiny object. Without consideration of how a particular technology change aligns to a business need or goal, we can all too easily head down a path for the wrong reasons. A better approach is to start with the business objectives, and then evaluate the suitability of technical solutions to meet those objectives. For example, a large financial institution wanted better access to more and more data to enable better decision-making, and their infrastructure could not meet the demand. By understanding the business purpose of the data and why it needed to scale faster and be accessible faster, the company was able to focus on which applications needed attention, where they were deficient, and what the technical alternatives were.

Half the battle

If you are clear on your desired business outcomes, you have won half the battle. To successfully plan your application transformation roadmap, you need to know the starting point for your applications. Consider these questions:

  • Do you know the relative importance of your applications to your organization and what business processes they support? Understanding their business value is key to evaluating ROI for a transformation effort.
  • Do you have the source code or access to the original developers?
  • Has any application been extensively customized?
  • Do you know the application's dependencies?
  • Are the application's components discreet and well-understood?
  • Do you know how frequently the application is used, and by how many people?
  • Do you know how often developers must work on maintenance or bug fixes vs. feature requests?
  • Do you know the ongoing costs to operate and maintain the application?

Next steps

Answering these questions will help you determine which of the 6-R's are worth further consideration to determine an application's go-forward architecture. In addition, you're also solving for the application's go-forward platform. There are economic, performance, and regulatory considerations for selecting on-premise, co-location, or cloud as the physical location where the application will execute. All of these should factor into your ultimate decision.

Here are some examples of when to use each approach, and where things can go sideways.

Final words

Armed with the right strategy and data, you can avoid the above pitfalls and apply the Six Rs effectively. Be sure to also consider whether you will have the right team and skillsets to support any new technology. As you begin to transition applications, it will be important to show ROI. 

Not making a decision for your legacy applications is a decision that could put you on a path to continue technical debt and, we all know, technical debt only grows with time.