Legacy software embodies years and years, even decades of compromise between the desirable with the possible. The emergent result of this design activity is not only software but also an organization that relies on it. The organization, the technical system and the people involved form a highly complex joint cognitive system.
When legacy software is done right, it is very much at the core of the business. It forms a sort of DNA or operating system intricately linked with the business. A legacy like that is a wonderful inheritance from our colleagues in the past. Sometimes, it is even a legacy from ourselves.
It is providing value, and therefore we want to keep it and so we work on it.
Is your software landscape a field of onions or a scrapyard of old crap? Those are two fundamentally different ways to look at legacy software systems.
In the video, we discuss the onion theory of system development. In brief, just like an onion starts from a seed, than grows to a first ring and then another and another, so does a software system grow from a sleek, well written core from some long forgotten mainframe system. The rings keep growing with middleware, API:s, service buses, orchestration layers and so on. We have many excuses for doing things this way, but the main reason remains – we do not dare touch the core, that legacy from our long forgotten predecessors.
A lot of the knowledge of our predecessors is hidden in the software. We cannot re-engineer that knowledge. In effect, the system is the specification. We need to keep refactoring, removing parts not needed because they cloud the parts we need to work on. Just like we need to exercise our whole bodies, we need to work the whole system.
A working complex system must emerge from a working simple system. It is naïve to think that there will be any quick fixes to legacy software. Just think about ventilation in new buildings. Have you ever had the experience that a meeting room is not well ventilated? It takes a long time of fine tuning to get the ventilation right in a building, and that is not a very complex system compared to the legacy software that powers your business.
Architecture Corner, legacy software, no estimates, Woody Zuill. Bookmark.
This is not about the software, it’s about the holistic integrated cost of the business processes, now and in the future.
I work a program in another Federal Agency that is spending huge amount of money maintaining legacy systems, when a simple switch of a state of the art ERP system, would cut the M&O spend to ZERO and release large amount of committed cash.
This notion of W’s fails to consider the balance sheet “obligatory cash flow” of the legacy system, as well as all kinds of other issues — Security, interoperability with other systems, cloud computing, declining resource pools.
Since you reposted, I have another observation on legacy systems.
In our domain, legacy means Heritage systems. Trusted sources of capabilities to be used and reused on future programs.
The picture in the post is an example.
The notion of onions may be valid in the absence of a legacy or heritage architecture. This is one of the roles of architecture – to serve as a platform to heritage and current systems integration.
You are correct in there are no quick fixes for legacy systems. But that is not limited to just legacy systems, bit for any complex system.
The notion “A working complex system must emerge from a working simple system” must be tested by the architecture of the resulting system. It may well be that the “simple” systems provide little or no value in the absence of the connectivity to form the complex system.