.webp){kind=logo}
We are all familiar with the classic Five or Seven Rs of modernization—those trusty labels like Retire, Replatform, and Refactor. Every vendor has their own version, and every IT team has debated them at some point. CloudFrame COO Hans Otharsson isn’t convinced they still make sense. This article will explore the reasons why.
The Problem with the Rs
If I remember correctly, it was sometime in the early 2000s when Gartner started talking about the five Rs of mainframe modernization. It was an attempt to simply a very complicated problem by putting things into neatly packaged little boxes, but it was a very technology-centric approach. It made sense at a time when the industry had just gotten out of Y2K, the tech bubble was bursting and people were looking at how to make critical systems less of a liability. Everyone looked at modernization as a technology problem, as technical hurdles to overcome. How to move from A to B, how to emulate or otherwise run the stuff somewhere else. Five Rs quickly became seven Rs, and everyone had different Rs. One person’s Refactor was another person’s Replatform, and so on.
The problem I see with the Rs is that they’re not necessarily the right way to describe what you’re trying to accomplish. If you limit your approach to a technology perspective, then you lose the most important questions. Why are doing this? What are you trying to accomplish? If you just keep bringing up the Rs, you start to sound like a pirate. Rrrrr this and Rrrrr that. Maybe you need a parrot?
A concrete example of this is that everyone who provides a modernization solution wraps that solution around the Rs and it makes it seem like they’re addressing all of the strategic aspects. Without viewing the situation through the lens of business objectives, it may even look that way. But just because two things both fit into the same R, doesn’t mean that they’re equal, or that they deliver the same results.
Take ‘Retain,’ for example. In theory, it means keeping a system as is. And if you’re selling a “lift-and-shift” product, your Retain strategy for applications you can’t or shouldn’t lift-and-shift might literally be to do nothing with them—leave them exactly as they are. “Look, I’ve addressed another one of the Rs!” Cheapest solution ever. But in reality, Retain should never mean do nothing. Retain should be take what you have and make it better—optimize your COBOL, make it run faster, use fewer resources and be easier to maintain. That is what the Retain strategy would look like if you framed your modernization objectives as business needs and goals. After all, businesses that don’t evolve don’t last.
Another limitation of the Rs is that they were devised at a time when there were far fewer options for modernization. The technology is very different today that it was twenty years ago, which expands the possible strategies and gives us options we just didn’t have when the Five R framework was first envisioned.
So, What’s the Answer?
I think every customer that’s going through a modernization exercise should look at each application and understand where they want that application to be in five years. How about ten years? And they should also ask that about their IT infrastructure and business as a whole. For each application, there may be a different answer. Is the need for it ongoing? Can I modernize it or do I need to replace it? These questions—and the answers—should be shaped by business needs, not technology-centric perspectives.
Technology focus has its place. For example you may decide to Retire (another R) some applications because the need for them is going away. And that brings up a technology question—what are you going to do with the old data? How can you store it somewhere so that you can do queries on it when you need it? But technology is how you do the thing, not why you do it, and it’s the why that should shape the what and the how.
Today, I see three main optimization strategies that can either work independently or together as a stepped approach. And which of those is the answer for your organization will depend on your business goals, and they can vary from system to system or even application to application.
1. Optimize what you have – If your system is staying, make it faster, cheaper, and easier to maintain.
2. Move with a purpose – Don’t just replatform because it’s trendy; do it because it aligns with a strategic goal.
3. Rebuild for the future – Sometimes, the best move is to start fresh, but with a clear vision.
You Don’t Need a Parrot
If you want to focus on the Rs, whether there are five, seven or however many, try to do it without losing perspective. The Rs should be a way to broadly categorize your strategy for the sake of easier communication and planning, not a limiting framework to force your objectives into, nor as buzzwords used to sell optimization solutions. Just being able to stuff a strategy into as many Rs as possible isn’t enough. Repeating words, R words or otherwise, is for parrots.
