The obvious reason is that the underlying technology becomes obsolete. There is not much that can be done about that but that is only a small part of the story. Much of todays legacy was written in Java, so what gives?
The reality is there are a bunch of lifestyle choices whose effects arent obvious at the time but seriously affect the systems life expectancy over time, either because they lead to reliability and scalability issues, or the speed of change deteriorates to the point where the system can no longer adapt to changing business needs.
Here are some of the memorable bad habits I have come across that are avoidable (with hindsight) and could significantly improve a systems quality of life as it reaches its golden years.
The worst thing that you can do with software is force it to be built in a fixed timeframe. Even when a timeframe is set by the technology team before the project starts, its usually a good guess at best. When corners get cut to hit dates, its usually the features that are needed to sustain the platform over the long term that go out the window. Doing the work after go-live inevitably becomes the plan, but this can get lost in the wash of post go-live issues and new pressures.
Getting the project sponsors to really understand the importance of investing in testing, scalability, and resilience before it becomes a visible problem is a must for long term health. If this is not established in the beginning, the systems life will be marred with constantly needing to fit a square cost peg into a (much) smaller round budget hole.
Without realizing it, sometimes the system goes into maintenance mode - the build-out is done, the evolution of the new product or sales channel slows, and the required tech investment reduces significantly. This is a vulnerable time. If the funding is not kept above a minimum level, entropy will kick in and the system will go into decline fast.
Its inevitable that when the heavy lifting of building a system is done, talent starts to look elsewhere. This is simply because developers want to architect and build new things, It is harder to attract talent to work on an existing system, and even if you find people the change in personnel can significantly disrupt the productivity of a team.
There is always a strong instinct from the business that using somebody elses tech is going to be harder in the long run than building your own. Thats why safety in numbers is critical. The more a system gets reused around a firm, the better its chances of avoiding a premature legacy tag. But achieving adoption is tough. Yes, it might be quicker in the short term, but will it do the job? Will users have enough control?
When you sit down and design a system it is too easy to think about how to deliver the functionality, while ignoring the focus on the tools needed to make it easy to operate. 40% of budget can be spent on support if it is not done right and much of this is because too much developer expertise and attention is required for too long.
If a system is not designed to be testable and lacks tools that make running tests and evaluating results efficient, it becomes difficult to change the system quickly and efficiently. There needs to be a parallel program to write tests (ideally before writing the code) and keep them updated as functionality changes.
Being able to make assumptions about how a system behaves is important. This is achieved in part by maintaining a consistent implementation approach throughout its lifetime. Proper code reviews are one good way to achieve this. Keeping complexity under control is everything simple systems become complex, not always because of complex features but, because there is no consistency and unused code is not pruned.
Systems dont operate in a vacuum. Often, they depend on surrounding technology to deliver functionality. Systems and the teams that surround them tend to become fortresses, and relationships become combative not co-operative. Borders between teams are frictional by nature, so clean interfaces and data contracts need to be implemented to take the emotion out of things.
With the benefit of hindsight, it can be argued that the right software development tools will help by removing the need to constantly solve many of these common, thorny issues. Making systems stand the test of time is complicated and requires constant management throughout their entire lifetime.
Application platforms, like vCore by Velox, allow you to buy solutions to many of the problems that lead to a system becoming legacy before their time. Unlike traditional third-party vendor solutions, Velox allows you to make your own functional changes as you need them. App platforms greatly reduce the execution risk of building a system and ensure you get the right return on your investment over its lifetime.
At Velox our mission is to provide an application platform to our clients that maximizes their ability to innovate rapidly. Would be great to hear your opinions on factors that you think are missing.