The topic of legacy systems is something of a contentious one. In most cases, a legacy is understood to be a good thing. What makes a system “legacy”? Is it a technical or business decision?
A little over a year ago, Greger Wikstrand took a stab at clarifying the term with his post “Legacy systems, a definition”. In the post, he looked at different definitions of what constituted a legacy system, ranging from “any code that is in use” to “outdated technology” to “high technical debt”. The definition he went with, in my opinion, is the most useful:
It should be clear that legacy systems are not about technical considerations. It is about how well the existing system meets and is able to adapt to business needs.
A pair of tweets from Joanna Young that I saw yesterday brought this to mind:
https://twitter.com/jetpack/status/872880714542219266 https://twitter.com/jetpack/status/872881197428477957Whether or not a system has crossed the line into legacy territory is not a technical decision but a business one. As Greger and Joanna both noted, it’s about fitness for purpose. Technical considerations absolutely have immense bearing on whether the system is able to meet needs. However, they are not the sole determinant.
The standard narrative is for a system to start out “clean” and then rot via neglect and/or ad hoc enhancement. This is certainly a common scenario, but it overlooks the obvious. While failure to maintain a system and its platform will certainly degrade it, keeping the technology components up to date does not ensure that the system will continue to match the needs of those who depend on it. For that matter, it’s easy enough to build a brand new system using the latest and greatest technology that is a legacy right out the gate due to its failure to meet the needs of its stakeholders.
Age of the platform is not a problem; an inability to get support or find people knowledgeable about the platform is a problem. Technical debt in and of itself is not a problem; being impeded or prevented from maintaining/enhancing the system due to technical debt is a problem. This works for any given technical issue – substitute the tangible, stakeholder-oriented result of that technical issue and the point becomes clearer to those with the ability to address them.
The key is not to focus solely on functional aspects nor quality of service and/or technical aspects, but the system as a whole. This requires the participation of the entire set of social systems involved in the creation, maintenance, and usage of the software system. Communication and collaboration across all elements of those social systems is critical to effectively maintaining the software system and the social systems that it enables.
A critically important part of promoting that communication and collaboration is maintaining the cohesion of the social systems involved in creating and maintaining the software system. Where those social systems are ad hoc and episodic, the potential for forming the relationships necessary for effective situational awareness is minimal. IT won’t know about functional gaps until too late and the stakeholders won’t know what their options are for addressing them nor will they have advance notice of impending technical issues.
Social systems create, maintain, and use software systems. Systems that are designed to work together have a better chance of doing so than those that are just thrown together and wished well.
Form Follows Function 
Interesting points, but doesn’t “legacy” imply that a system has been superseded by something that is newer – and by extension then also a better fit for purpose? If something isn’t terribly fit for purpose (perhaps because the business context has changed over time) but you have no immediate alternative, is the system then still “legacy”?
LikeLike
I wish…that would be a lot easier decision.
Legacy systems can run the gamut from those that are no longer really fit for purpose at all, but still required (in which case you get lots of shadow IT systems to enable the real work and the legacy becomes an extra administrative overhead) to those that are fully fit for purpose from a functional standpoint but fatally flawed from a technical/QOS view. The latter are particularly dangerous because, with a traditional IT setup operating under the “if it’s not broke, don’t fix it” doctrine, you might be continuing to shove valuable data into a system that cannot be maintained (although the end users don’t find that out until too late). In a previous job, I’ve seen things like people using a 3rd party imaging system that was 5+ years out of support and IT buying broken equipment on eBay to cannibalize for spares because the manufacturer no longer sold them – scary to say the least.
LikeLike
Thanks for a nice read at 6 am on a Sunday morning. I have always held that as soon as code was installed it represented a legacy. However, my big take away is the need to recognize and integrate the social systems into how we work.
LikeLiked by 2 people
Thanks Tom. I think the most important factor in how quickly something becomes a legacy system is the traditional practice of considering a system to be “done” on deployment. It seems that people believe systems to be both static and impervious to entropy. It doesn’t work that way with anything else (house, car, appliances, etc), so it’s a little unrealistic to expect software to be different.
In my opinion, the system isn’t “done” until it’s been decommissioned. Thought has to be given not only to the cost of initial development, but also ongoing maintenance (not to mention the inevitable enhancements, the need for which will emerge as the system gets used). Accepting and addressing these concerns early on is necessary to avoid the “let it rot, then sprint to fix it” pattern that so many organizations are locked into.
LikeLike
Agree that ALM is important, and actually also for a different reason – a financial one:
First of all, the cost of operating the system though the full Application Life Cycle (up to and including decommissioning) needs to be incorporated in the investment calculation. Some organisations will invariably get this wrong – by accident or by (poor) design (of processes).
But secondly (and this is where I have seen things go really wrong): If you invest a capability in the form of a new system then once that system is no longer viable to maintain, you probably still need the capability. Which means that if you are adding new capabilities to your system landscape, some form of accruals to sustain the capability ad infinitum will probably be required.
LikeLiked by 1 person
“Which means that if you are adding new capabilities to your system landscape, some form of accruals to sustain the capability ad infinitum will probably be required.”
Absolutely! This is the heart of the whole “organizations as systems” concept that I’ve been harping on for a while now. The “standard” seems to be adding capabilities (including redundant ones, which isn’t always bad, but…) in an ad hoc manner and not managing the portfolio very well. Grady Booch has a quip about systems resembling “spare parts flying in formation” that IMHO very aptly describes too much of the enterprise architecture/enterprise IT architecture landscape.
I suspect you’ve given me the theme for my next post, because responding adequately to your comment deserves much more than a quick reply!
LikeLiked by 1 person
Pingback: Holistic Architecture – Keeping the Gears Turning | Form Follows Function
Pingback: SPaMCAST 454 – Iteration Planning, QA Leads, Trash or Treasure | Software Process and Measurement
Pingback: Form Follows Function on SPaMCast 454 | Form Follows Function
Pingback: The cost of capabilities… | businessandarchitecture