Some have speculated that a significant part of the existence of software professionals is to rewrite existing systems. Kind of like every 5 or 10 years, or more frequently, a family will toss out the old car and buy a new one. After a while a car shows its age, and perhaps that is some of the reason why software systems get replaced too. There are many reasons why a system might need to be replaced:
- Shows its age, to the point that it makes it difficult to derive value from the system.
- Was developed for a different purpose than it now needs to serve. Accordingly, the way the system was designed doesn’t lend itself to current needs. This may be due to a shift in what a business does. Old markets have faded and new markets have come to fruition.
- The system wasn’t designed well to begin with. The system may not do a good job doing what it was originally desired. This may be because those that built the system weren’t privy to what the system was meant to accomplish and were instead given a laundry list of specifications to implement.
- The system is incredibly difficult to adapt to even small changes in the way the business works, let alone new markets of opportunity.
- The system was designed with an old organizational structure in mind. Through the process of reshaping an organization, or mergers and acquisitions, it is possible the system no longer suits the current organizational structure.
I’m sure you can think of many more reasons. It’s common, when these problems arise, to consider replacing the system with a new system. To literally rewrite the system and then at some point transition to the new system, like flipping a light switch or buying a new car. This is a plausible approach but there are a lot of risks in the process.
- It’s necessary to ensure all the existing functionality that is still necessary is retained.
- It’s necessary to continue to support and change the existing system while it’s still in use, so those changes also have to be migrated to the new system.
- It can take years sometimes, to rewrite a system. Remember how much time it’s taken to develop the current system and to continually evolve it, add all of that up.
- Existing data likely needs to be migrated as well. Of course the migration process must be well validated.
- The process of cutting over is fraught with uncertainty. It’s often an all or none approach to moving across. Once you move, you may not be able to easily move back. It’s one giant leap.
Instead of taking a giant leap, there are many other possibilities. And understanding these possibilities first start with understanding why the existing system is insufficient. Insufficient to do what it already does, or insufficient to do new things that the organization needs it to do. And then, understanding what those new needs are worth. What the new needs are worth can help determine alternative approaches to a wholesale, all at once replacement.
If it seems like new needs justifies replacing the existing system, in other words the value of replacing it far outweighs the potential cost, then I would also consider the following alternatives.
Consider incremental replacement
Instead of hunkering down for months and years to rewrite the existing system, ask yourself, is there a way that we can partially replace the system, bit by bit. An incremental approach to replacing the existing system. Martin Fowler refers to this as strangling the old application. You wring old functionality out of the old system and move it into a new system, but you allow the two to co-exist. This can significantly decrease the risk of transitioning to the new system because you get feedback about each incremental replacement as you develop it. You don’t wait years for feedback, you can get feedback in a matter of weeks or months.
I would recommend prioritizing what you migrate first, based on what is most worthwhile. Balance the value of the subsystem you are migrating, with the potential cost to migrate and see what’s most worthwhile. Don’t just pick the easiest thing to move. And don’t just pick the most valuable thing to move. Pick the thing that’s the right mix of value and simplicity. This also establishes a cadence of success that you can continue to build upon. Early success predicates future success.
So what does this look like in the long term? Well, say a system is comprised of five subsystems: A, B, C, D, and E.
After careful analysis it seems like subsystem B is the best combination of value and simplicity to move first:
A new system is established to replace the necessary purpose of subsystem B. It communicates with the existing system so that the two work together to provide the composite, necessary functionality. This communication is overhead versus a rewrite. But, it also supports the ability to incrementally replace the old system, getting valuable feedback in weeks and months instead of years. The overhead in communication is the tradeoff to reduce the risk in waiting years to replace a system. Also, you start reaping value from the new system sooner. In many cases the risk in waiting years is 10s or 100s of times the cost of this overhead in communication.
When B is sufficiently migrated, then you can move on to another subsystem. It’s important to re-prioritize the value of what comes next. In the time it took to move B, you’ve learned a lot and you should use that to your advantage. Then move on to the next subsystem, say C, that best combines value and simplicity:
In time you can move more and more of the old system to the new system. And one of the best things about this approach, at some point, it might make sense to stop moving functionality. Say a more important project arises. If you have moved B and C successfully, perhaps that other project outweighs the value of moving A, D or E. You can put the migration on the back burner and come back to it when it makes sense. Go tackle the new opportunity. Then, come back when the time is right.
But also realize, you may get to a point where it just doesn’t make sense to move anything else over. Say you get B, C and D moved. But A and E are administrative subsystems that aren’t frequently used and your customers and users don’t interact with, they might be for your IT operations staff only. Perhaps it doesn’t make sense to move these, instead it makes sense to leave them as is because there’s no value in moving them. That’s another nice benefit of this incremental approach, you can stop at any time while still having reaped something of value in the process.
Consider enhancing value
In addition to migrating incremental functionality, it may also make sense to consider how you can enhance the value of an existing system. In other words, is there a new opportunity that we could tackle. This might be like a new subsystem F. If F would provide significant value to the organization, you could start by creating a new system with a new subsystem, that still communicates and depends upon the existing system. In the process of creating F, you can also begin to lay the foundation to replace existing subsystems when the time is right.
By tackling new value first, then out of the new value created you can capture a budget for replacing existing functionality that alone you may not have the budget to replace. This is especially helpful if your initial analysis leads to the conclusion that a rewrite is simply too costly to undertake. Now by expanding the value you capture in creating a new system, you can use the profits of that new value to fund rewriting the old system. And in the process of laying the ground work for the new system, you already cover some of the costs in building a new system so that it’s more viable to replace the old portions.
In fact, I often recommend that when a system is undesirable enough to garner a rewrite, to seek out the potential areas of new value. New, substantial value. Because these are often the impetus of the rewrite and are a fantastic spot to start. To start reaping value early, and new value too, not just replacing a system with a new one that accomplishes the same thing. New value is much more likely to get the attention, support and buy in of others in the organization. To motivate them to chip in and help see things through to success. It also gives people something to be proud of as software professionals, instead of just thinking of their job as building new cars that do the same things as the old cars do.