Working with Legacy Systems

A practical guide to looking after and maintaining the systems we inherit

Robert Annett

• Publisher: Packt Publishing
• Year: 2019
• ISBN:
  9781838988579
• Edition: 1
• Topic: Computer Science
• Subtopic: Computer Engineering
• Index: Computer Science

Understand the crux of legacy systems — their architecture, analysis, and security constraints

Key Features

• Understand what are legacy systems and learn various strategies to maintain them
• Deep dive into the basic and advanced architectures of legacy systems
• Discover how to analyze and secure the legacy systems

Book Description

The latest edition to our range of products is Packt Select - the new range of books with a broad spectrum of information on unique topics. We have identified your requirements, searched for the best books available, and we now offer these to you. With these books, you'll enjoy a smooth learning experience with the usual Packt "must-haves" of real-world examples and best practices.

New technologies are continuously being introduced in the I.T. industry. While learning those is important, maintaining legacy systems is equally necessary to ensure that the I.T infrastructure of your organization functions to its best abilities. Sound knowledge of techniques that can be used for maintaining legacy systems, can help you avoid many pitfalls.

You'll begin the book with a quick understanding of what a legacy system looks like, how it works, and what are some common issues in it. Then, you'll explore the architecture of a legacy system in detail and learn each of its components. You'll learn and use various techniques to analyze a legacy system. After learning about the security constraints associated with legacy systems, you'll explore ways to overcome these constraints and secure the systems. Towards the end of the book, you'll learn how easily make changes in the legacy systems to enhance their performance.

By the end of this book, you'll have skills and confidence to work with legacy systems and efficiently maintain them.

What you will learn

• Perform the static and dynamic analyses of legacy systems
• Implement various best-practices to secure your legacy systems
• Use techniques, such as data cleansing and process cleansing to stabilize your system
• Apply structural changes in your legacy system to make it highly available
• Identify and resolve common issues with legacy systems
• Gain knowledge of various tests that can help secure and maintain your legacy systems

Who this book is for

This book is ideal for IT professionals, who want to understand the working and maintenance of the legacy systems. Prior knowledge of working with legacy systems is not needed to complete this book.

Chapter 1

Definition, Issues, and Strategy

What is Legacy?

For most people, in most situations, being passed a legacy is a good thing. Perhaps their long-lost uncle has left them a stately home filled with antiques. Or a legacy might be a valuable art collection given to a museum or the work of a famous author. However, in Information Technology, it is a dirty word filled with innuendo and often used as an insult. This is a strange situation and we should define exactly what we mean by legacy before addressing how to deal with it – and even if we should deal with it!

When we refer to a system as being legacy what we're really saying is that the system is built in a way that differs from how we'd choose to do so today. Legacy systems may have been written well, using the best technologies and tools available at the time, but those technologies are now out-of-date. A system written in 2001 using Java 1.2 and Oracle 8i may have made perfect sense but if you wrote it now, you'd at least use the latest versions available or even something different entirely (Scala, MongoDB, and so on didn't exist then).

An IT-Centric View of the World

Like most developers, at the center of my working life is the software development process. This might initially involve a business analysis and some support afterward, but this takes up a relatively small percentage of my time.

A software-development-centric view of the world is as follows (this is the Software Development Life Cycle (SDLC) diagram and your own process may differ slightly). There are two parts that interact with the outside world – requirements and deployment (which may be lightweight and frequent) and external interactions are wrapped in those phases.

Figure 1.1: An example software development life cycle

For some businesses (for example, public-facing websites), software is the business and there is no significant period before or after software development – it occurs constantly. These businesses are very interesting to us developers for this very reason (and therefore, these projects are often discussed at conferences); these are the exception. For most organizations, their individual IT systems perform a function that constitutes only a small part of what the organization does.

Systems Development in Context

Therefore, software users view the world differently. The software development phase is a very small part of their business processes, life cycle, and lifespan. They view the world a little more like this:

Figure 1.2: The life cycle in context

Most of the processes the software users execute will originally have been done manually (I include generic software tools such as spreadsheets) and may have been done this way for 6 months to 100 years. (If you think I'm exaggerating with "100 years" then you should speak to someone who's worked for an old insurance company.)

At the end it will be decided that it is cost-effective to develop bespoke software (or spend a lot of effort configuring BPM/CRM software, and so on). This process may be iterative and deliver value quickly but will be mostly complete after a relatively short period of time (compared to the organization's lifespan).

The software is now fully live, and a software team will consider it to now be in its maintenance phase. From the organization's point of view, this is where the real value is extracted from the system. Very little money is being spent on it, but it is being used and is either helping to generate revenue or increasing the efficiency of a process.

As time goes on, there will be a decreasing number of changes made to it. Eventually, it will be considered legacy. Ultimately, the system will reach end of life and be replaced when it is no longer fit for its purpose.

Systems Development Scaled with Time

If we were going to scale the diagram to indicate time, then it might look like this:

Figure 1.3: The life cycle in context and scaled with time

These are typical life cycle times that I've experienced and yours may differ – this will depend largely on the industry you work within.

Therefore, legacy should be viewed as a phase in the life cycle of the process. Note that I have a small arrow going back to Software Development from the maintenance/legacy phase, as it may have upgrades or additions many years after being deployed.

Line-of-Business Systems versus Others

It was pointed out to me (thanks to Robert Smallshire) that the life cycle I've described best fits line-of-business software development and other types of systems that may vary greatly (for example, the control systems for embedded devices). This is true and reflects my personal experience but the statements on differing perspectives still hold.

I wrote a blog post covering much of this and someone commented that they refer to legacy systems as mature, as this has a more positive connotation. I think it also accurately reflects legacy as being a stage of a life cycle rather than any indication of quality.

A system maintained by professional programmers would be periodically upgraded and migrated to new technology when required, so it may never be mature/legacy. However, this is rarely a decision for programmers – it's a management decision. To be fair to management, does it really make sense to spend large amounts of money continually upgrading a system if it works? If the programmers and systems team did a good job, then no changes may be needed for many years. This indicates a high return on investment and a good quality system – a legacy!

Of course, when you do have to make changes or additions, you have a very different set of issues compared to modifying a system that is being continually developed.

Examples of Real Legacy Systems

Giving an example in a publication is dangerous as, in five years, it might be hopelessly out of date. However, considering the subject matter, I shouldn't make this argument. Look at the following:

Figure 1.4: © Dave Ross sourced from Wikimedia

Is this a legacy system? It's a museum piece. This is an IBM360 and was once the most popular computer on the planet. However, there are no commercially working examples left and they can only be found in museums.

This shouldn't surprise us, given the example timeline and arguments from earlier. Systems will be end-of-life or modernized eventually and it's very rare for a working system to be this old. So, what are the types of legacy systems you're most likely to come across? This will obviously change with time (and depends on the organizational areas you work within), but they are most likely to be:

• Between five and fifteen years old
• Without maintenance for two years
• Using out-of-date APIs or technologies

If they don't meet these criteria, then you are unlikely to consider them to be legacy. Some examples are:

• Java 1.2/1.3/1.4 running under Solaris 8 on an Ultra Sparc III server using Oracle 8i
• C# 1.0, Windows server 2000 using SQL Server 2000
• Objective C on NeXT server
• J++/J#, VB6, FoxPro, Brokat Twister
• A combination of spreadsheets, macros, and shell scripts

I'll cover common issues in the next section, but the preceding examples have different problems even though they are technologies from between 10 and 15 years ago. The first two (Java/Oracle and the .net stack) are very out of date but are all supported technologies. These should be simple to upgrade and support but are likely to be challenging to modify. The next two involve hardware and software that are discontinued. This will be much more challenging. Lastly, we have the very common situation of a system being bolted together from 'office tools.' In this book, I'll be covering these kinds of legacy systems.

Note

I worked for an investment bank that had made a large investment in systems written in Objective C and running on NeXT servers. These systems worked well, but were complex and hard to replace. They ended up being run for so long that they had to start buying hardware spares off eBay.

Common Issues

In this section, I'll be identifying common issues with the types of systems discussed in the previous section. Depending on previous experience, these might appear obvious (you've seen it before) or surprising (you'll see it eventually). I would suggest that when you take on a new legacy project, you go through these and see what applies. Being aware of and expecting these issues will help you deal with them. I have included an Issues Checklist in the appendix to help with this.

No Documentation

When a system has been running for a long time, it is not unusual for supporting artefacts to be lost. The users of the system will notice if it stops working and will complain, but will anyone notice if items, such as documentation, are lost? This can happen for several reasons:

• Support systems may be retired, and information removed. This can happen when there is no obvious link from the documentation to the system it concerns.
• Documentation still exists but no one knows where it is or if it has been moved and the links/locations are not valid. This is a common problem when migrating document management systems.
• Information is in an uncommon or unknown format. It's amazing how many files end in .doc.
• Information was only ever stored locally (and the machines have been wiped) or not stored at all.

The agile manifesto says we should favor working software over comprehensive documentation, but it does not say we should not document anything. There are various types of metadata about our system that can make supporting it very difficult if missing. For example:

• Usernames and passwords: The direct users of the system and its administrators may know their access details but what about the system's sub-components? What about administrator access for the database or directory server? If these are lost, then performing maintenance actions can be incredibly difficult.
• Release instructions: Maybe you have the source code, but do you know how to build and release the software? Data is more likely to be kept than a running, unused service so your build and deploy server probably won't be present after 10 years. Was your build configuration in the source control system?
• Last release branch details: Which one of the multiple code branches or labels was released?
• Communication protocols: This is one of my personal bugbears. Many systems have been designed over the last 10 years to communicate with each other via XML messaging. Whereas developers used to document binary message formats, they've often not done so with XML as it's deemed to be 'human-readable' just because it's text-based. XML data blocks are rarely obvious, and they have so many optional elements that they are very difficult to reverse engineer. This is especially true if you only control one side of the communications, for example, receiving a message from an external source.
• Licenses and other legal agreements: I'm going to talk a little more about licenses later, but can you track down the legal information about how you can use the third-party software and hardware elements in your system? They may be more restrictive than you think.
• Users, including external systems: Do you know who your users are? What external systems rely on the one you control?

It is always worth tracking down and cataloguing all relevant documentation as a first step to maintaining a legacy system.

Lost Knowledge

There is an overlap between lost knowledge and a lack of documentation. You could argue that no knowledge would be lost if everything was documented but this is unrealistic and incredibly time-consuming. It's likely the reasoning behind design decisions has been lost. You have the artefact (the system) but not the how and the why as to its creation.

Note

Many years ago, I worked on a system that, once a day, collected some customer information and emailed it to some users. As part of the process, a file was created (called client-credit.tmp in the /tmp folder on a Unix machine). The next day, this file was overwritten. When we began upgrading it, we moved the process into memory, so no temporary files were created. I received a very angry phone call a few days after go-live from someone whose system was broken. It turned out that another system (in a totally different part of the organization) was FTP'ing onto the server, copying client-credit.tmp from /tmp and using it. At some point, there must have been a discussion between the two departments about giving access to this information and how to do it. Howe...