If you’ve ever been on a subway, you’ve probably seen or heard “mind the gap.” It’s a reminder that there’s a gap between the train car and the platform – and you want to make sure you’re paying attention to it. It’s a reminder that there is supposed to be a gap. It exists for a reason, but, at the same time, there’s a risk to the gap that must be managed.

I’ve been an IT consultant for nearly three decades. A lot has changed, but there are some patterns that have remained the same. When I first started, it was the PC under someone’s desk that was the server for the entire organization and the Paradox database that kept the entire place running. Today, it’s the “green screen” application that hasn’t been updated. It’s the forms technology that hasn’t been updated yet. (See Using InfoPath Today (Not Just Say “No”) for more.)

There’s always a gap between the state of the art and state of the industry. The state of the art is the absolute best, while the state of the industry is where most people are. It may be state of the art to have responsive websites, but most internal corporate applications don’t meet this standard. Many corporate systems require a specific browser, because they were built with the quirks of that browser in mind. They don’t display well on a tablet, much less a phone.

The state of the art exists to pull people forward, so we build systems that are more effective. “More effective” may mean more secure, more accessible, more scalable, or some other desirable characteristic we expect will make things better in the future. We’re hearing a lot about artificial intelligence and how it will revolutionize the things we do.

It seems like many of the folks I meet are ashamed of the gap. They have the expectation that they must be at state of the art or they’re not doing their jobs. State of the art is necessarily supposed to be ahead of where everyone is. If it’s not, we’re not moving forward. Despite this reality, we somehow feel ashamed that our systems aren’t state of the art.

The truth of the matter is that state of the art is expensive. It’s expensive both because the costs are higher and because there are sometimes missteps, which you’ll never have to take if you’re not on the “bleeding edge.” The leading edge of state of the art has been nicknamed such because of the tendency to get cut up when there’s a rapid shift in where it’s going.

For instance, for a while, if you wanted to be cool doing web work, you were encouraged to use Silverlight. Then Microsoft announced that it was discontinuing support for Silverlight. If you had an investment in Silverlight, your investment was wasted. (There’s an argument to be made that the core XAML lives on – and it does, but it’s not the same.)

There are countless dead ends when you’re trying to remain state of the art. All those dead ends cost time and money – and it’s caused more than a few people to lose their jobs when they made the wrong bet.

Many wise people insist on staying behind the bleeding edge and only doing a technology when it’s proven effective. They may miss out on being case studies for vendors, but they typically enjoy lower overall costs and fewer sleepless nights.

The question then becomes how soon you should upgrade systems. Unfortunately, the answer gets murkier here. Consider the “green screen” application. If it’s on a mainframe, it’s running on 3270 terminal emulation. If you followed the trend, you would have bought a mini-computer and migrated to VT 100 (RISC) or 5250 (AS/400, now called iSeries) emulation. From there, you would have built a client-server architecture application that could have run on a local area network. More recently, you’d build responsive websites and applications that run on phones and tablets as well as desktop PCs.

To be sure, there’s a cost to maintaining an old system, from maintenance costs, to keeping expertise, productivity issues with users, and even the reputation of the organization. However, do these costs outweigh the cost to convert the system three times just for the sake of keeping up with the state of the art? It’s not that clear.

Car Replacement

Some people I know feel compelled to have a new car all the time. The true believers work in the automotive industry. They may sell software to dealerships. They may work at a dealership. They may work for the manufacturer. In any case, their involvement in the industry means they must have a new car.

The second tier of people who feel like a new car is a necessity are sales folks. Having a new car implies success to their prospects, or so the theory goes. I’ve literally had friends in sales told they needed to get a new car. Some of them get a stipend for their car – and some don’t.

If you’re not in either of these two categories, you get to choose how frequently you get a new car. Sure, everyone likes the thought of getting a new car – but not necessarily the cost. This awareness of the cost keeps them from buying a new car every year. Whether you choose to buy a new car after your loan for the previous car is paid off or you decide to keep the car until “the wheels fall off” is personal decision.

Some people don’t like having a car payment and are willing to put up with larger repair bills while the vehicle is relatively reliable. Others have car payments in their budgets and simply maintain a car payment perpetually. For those that run their cars until they fail, they know there are risks to the approach. They know, at any time, they may have to go out and get a new car with little notice – but that’s acceptable for the savings. They know they may have a problem with their car that will transition it from relatively reliable to unreliable, but that’s OK, because it’s not that hard to get a temporary solution for transportation.

Cost, Risk, and Reward

It all comes down to a math problem:

(Cost to operate existing system + risk to operate existing system) – (cost to operate new system + risk to operate new system) = savings

When the savings becomes larger than the transition cost, it’s time to make the change. The problem is that most of these variables aren’t well known. They must be estimated. Typically, the costs are estimated over a year so that there’s some stability in the numbers, and momentary concerns or costs are averaged out.

The cost to operate the existing system has components that are easy. Any maintenance fees, utilities, space, etc., can be estimated. However, the big cost to operating a legacy system is the productivity cost of the users. Over time, these numbers really add up, as labor is the most expensive cost in most organizations.

The risk of operating the existing system isn’t particularly hard to arrive at – but converting that into a number is often resisted. A simple way to approach this is to evaluate the probability (or frequency, if it occurs regularly) of a risk and then the estimated impact. These are multiplied together to establish the cost of a risk. You do this for each of the risks of operating the legacy system and then add them together. The result is the risk cost for operating the legacy system.

Similarly, the cost to operate the new system isn’t known but can be estimated. The risks for the new system are often like those of the legacy system. but the expected probabilities are lower. These are added and totaled.

The final step is the return on investment. That is, comparing the cost to change and seeing how many years (or months) it will take to recoup the investment in the transition. Organizations typically prioritize the projects that will require the least amount of capital to complete and have the shortest payback period and therefore the best return on investment.

There’s one exception to this math problem.

Must Have

Sometimes, replacement becomes mandatory not because the old system is no longer functioning but instead because it no longer meets the needs of the organization. Whether it’s new markets or new ways of operating the business, there are times when the business changes, and it drives the change in the technology systems that support the business.

Invariably, these cause a ripple effect that delay other projects from getting upgraded, but that’s a problem for after the must have changes are done.