The best definition of a legacy system: The system that works in production. Unfortunately, I can’t remember from whom I heard this definition.

Your customer or employer runs his company with legacy systems. The technology in use might be very old, but it does deliver business value. That can’t be said for a system that you might be designing right now. The chances are that, if you are lucky as an architect, your system will shortly after hits the production be marked as legacy or ready for replacement soon. If you are even more lucky, the system will be extended and somewhat adjusted for few years to come.

Eventually, the inevitable will happen. IT management decides that operational costs are too high, time-to-market for changes is too long, technology is not supported any more and so on. It seems that nowdays with all the technology changes this problem is only worsened.

But, is it really inevitable that so many large systems are replaced completely?

One of the main causes is tendency to prevent this problem in first place. The main words used by architects are flexibility and generic solutions. If our system is flexible and generic enough, then we can handle our future requirements. The result is usually wishful thinking and just more complex solutions. Complex IT systems are always sooner outdated than simple ones. It is nowdays more and more difficult to predict the future, considering the pace in which business people change their mind.

It is much safer and cheaper to build system which will NOT last very long as it is designed. More precise: defined architecture will not last for long. If you build a system that is designed to be changed, than you are NOT building generic components, but only making sure that specific solution is cheap in case of partial replacement. This goes hand in hand with Scrum where you are always making sure that you are able to embrace the change, no matter how extreme this change might be.

Principles in achieving this:

1. The simplest possible solution is cheapest one to replace.
2. When introducing new system part or technology, you should find out how much it will cost to replace it.
3. Prevent depending on underlaying technology as much as possible.
4. Make sure services / interfaces are based on well defined loosely coupled functions your user and business understands. Do not make generic SOAP interface or some other technical standard interface. Replacing one technical standard with another is much cheaper than changing functionally highly coupled systems.