Recently, I was cleaning out my basement and found a giant box of Legos that I used to play with when I was a kid. Since I have kids of my own now, I thought they would like to play with these Legos as well. Here is a picture of the box:

Legacy Software and Legos

My kids were super excited and started playing with the Legos as if it were Christmas morning. Soon enough they were asking me to put back together this Lego set:

Broken Lego and Legacy software

I tried the best I could, but the original instructions are long gone. Some of the pieces were also missing either buried in the big box of Legos or lost somewhere along the way. I did the best I could and fixed them up:

Fixed Lego and Legacy Software

During this process, I starting thinking that finding two giant boxes of Legos in the basement is similar to getting “assigned” to maintain legacy software. You might have some documentation and all the pieces of the software, but how do you update it or fix parts that get broken? One way to do this to get a better understanding of the structure (dependencies) of your software and understand what parts impact each other. This is where a tool like Lattix can help. It will visualize your software architecture and dependencies. Once you understand the architecture you can clean up (refactor) the software. By refactoring the software (ie- reducing the dependencies between components), you can reduce the build and testing overhead which will make the software easier to maintain.

Lattix and Legacy software

Gartner defines a legacy system as an information system that may be based on outdated technologies but is critical to day-to-day operations. Maintenance costs on legacy systems can exceed the original development budget after just 5 years of deployment. Legacy systems are usually quite large, contain a lot of functionality and typically have a monolithic architecture. Often one change to the system results in rippling impact across many areas of the system. This requires large amounts of time and effort to make changes and updates. Lattix can help with legacy software in the following ways:

Understand and maintain poorly documented legacy code (visualization and metrics)

One of the keys to understanding poorly documented code is to visualize the dependencies. Typically, legacy codebases have a lot of external dependencies and unnecessary complexity in their design. A great place to start is with the existing artifacts. The file/directory structure or the package/namespace structure is a good guide to how previous developers wanted the code structured. With Lattix, you can apply partitioning and clustering algorithms to identify the hierarchy (or layers) and independent components. If the architecture has eroded over time, identifying cycles and tight coupling can lead to an understanding of the intended hierarchy or layering.

Define and Refactor source code architecture to optimize software design

A legacy codebase may be organized in thousands of independent files and a key goal of supporting a legacy application is to organize these elements into modular groups. With Lattix, you can experiment with ‘what-if’ architectures. Create different logical modules and examine their dependencies. If you want to componentize you can create logical components in Lattix using the current source code as a guide. Once you have the logical components the way you want them, you can go about eliminating unnecessary dependencies this can lead to improve build times and improve testing all of which makes maintaining the code easier.

Maintain applications architecture

The reason that you keep legacy software around is that it is critical to the business, therefore, development on the legacy software can never really stop. As a result, while your source code is changing, your architecture is also changing. There are a number of ways to make sure that you do not introduce new defects into your source code (static analysis, dynamic analysis, unit testing, etc). But how do you know if the changes violate your intended architecture? To solve this problem, Lattix has come up with a concept of design rules. These are rules about what dependencies or relationships are allowed in an application. This will allow you to maintain and control your architecture over the life of the development process.

Conclusion

Architecture is one of the most valuable artifacts to emerge from a legacy application. It contains the learning of how to tackle your complex business problem. Even when a decision is made to end-of-life the legacy application, the architectural knowledge left over from the project will be vital for creating the next generation application. If you are interested in understanding the architecture of your legacy system, sign up for a free trial of Lattix Architect.