The curse of replacement projects

I was at a Meetup the other day with Eric Evans. I liked the talk even if it was very similar to the one he gave at the last JavaZone. Eric makes the same point as I do in respect to replacement projects. They are more expensive than you think and have a high risk of failure. Even those that succeed often fail to produce more than nominal value. The project barely manages to produce a new system on a new platform that does the same things as the old one did. Eric’s advice in the face of these obstacles is to avoid replacement projects completely. Why start something that is bound to either fail or provide minimal value? But is this the right conclusion? I do not think so.

Eric is half right

Many replacement projects are started for the wrong reasons. People seem to make up these reasons more as rationalizations than as real arguments. They will also base their decisions on impossibly optimistic estimates of the costs involved. These projects should be converted into enhancement projects that build on the legacy system in an intelligent way.

Eric is half wrong

But there are also many replacement projects that are necessary. The reasons vary but one stands out in my experience: a core architectural design parameter has been invalidated since the system was built. Two common examples of obsolete design parameters are:

• The system was built around the notion of not overloading the computing power of the server. Data is collected during the day but most of the processing is done at night in batch operations. With modern servers this design has become superfluous. People have come to expect that systems process information immediately.
• The database is designed with the primary goal of using as little space as possible. The design tends to be inflexible and cryptic. Fields are often used for multiple purposes. With the costs of storage plummeting there is no reason to conserve disk space in this way.

In these kinds of situations it can be exceedingly difficult to align the system with the way one wants to do business. The system becomes a constraint that prevents the business from exploiting new possibilities. Customers start to notice that you are operating in an outdated manner: “You will have to wait until tomorrow before your changes will be visible”, “Describe your problem in 200 characters”.

An alternative approach

The interesting question to ask is “How do you plan a replacement project so that it stands a chance of succeeding?”. The answer is in the strategy you use. The core mistake most replacement projects make is that they try to replace the legacy system in a “big bang” style. This leads to a “at least as good as the old system” mentality. Scope is contingent on an unknown quantity, the full feature set of the legacy system. In addition, the project has no way of getting real feedback since nothing is released before “everything” is completed.

There are two general approaches (and an infinite number of combinations of these) that are far superior to the big bang approach:

• Treat the replacement project as an enhancement project for as long as possible. Build new components that cooperate with the legacy system. Gradually replace enough of the legacy system until the business can bear the pain of retiring it.
• Create a completely separate system and use it for a small subset of the business. A common way to do this is to route new business of one type to the new system. Grow the system so that it gradually can handle more and more types of business.

There are many possible ways to pursue these approaches. Each legacy system provides a unique context that heavily influences how you should tackle the problem. The Agile Release Strategy wiki describes a large number of possible approaches together with their inherent strengths and weaknesses.

The hard truth

There are some core truths that you must face if you want to succeed with a replacement project:

• Pain is a necessary and useful part of a replacement project. Make sure that the business understands and accepts this from the outset.
• A certain amount of investment in the legacy system will be absolutely necessary. Do not see investments in the legacy system as waste, see them as insurance.

Replacement projects are hard, but with the right strategy you can lower the risk of failure to an acceptable level.

Posted on 2010.01.26 at 21:01

Comments are off for this post.