What are legacy applications? Legacy applications encumber all organizations, even those using Agile practices. They sit on outdated architecture, bloated from enhancements and often held together tenuously with chewing gum and bailing wire. Over time, IT has started asking these applications to do things they simply weren’t designed to do when originally developed decades ago.
No one likes to deal with these dinosaurs, but they have to. These legacy applications, though old, still support critical processes and information the business depends on. But their stability eventually comes into question. At some point, it’s time to modernize.
Several forces drive this decision. First, IT can’t change these legacy applications as fast as business needs evolve. Organizations are trying to embrace Agile across the enterprise, but these apps hold them back. After decades of enhancements and fixes, they have grown in size and complexity. Design compromises have been made. And the people who designed them are long gone, leaving little, if any, current documentation.
Second, it costs too much to take care of these legacy applications. Their size, complexity, and outdated architecture complicate all aspects of their enhancement and operations, requiring more time – and money – than acceptable.
Finally, and perhaps most importantly, risk grows. Software and hardware become obsolete. It’s difficult to find people with the skills to modify them. IT becomes much less confident in its ability to keep these legacy apps running.
When the decision to modernize legacy applications is made, software requirements become essential to success.
Legacy applications’ lack of documentation means teams start projects with a giant black box overflowing with business processes, information, and technology they need to understand to move forward. Documenting requirements brings order to this chaos, so teams can develop sound approaches.
Many aspects of requirements are unique to legacy application modernization projects, and there are several approaches to using legacy apps during and after project execution. Five, however, are key. Successful teams use robust requirements to:
-
Understand what the business really needs today.
According to the Standish Group’s CHAOS report, organizations never use 45% of software’s delivered features. Consider numerous projects introducing unused functionality into legacy apps over time, and you can see how wasteful it would be to simply “redevelop” them without evaluating what is most important. Good requirements help teams focus diligently on business strategy and value as they modernize legacy systems.
-
Understand and document existing business functionality.
Obviously, it’s important to know what the current legacy systems do. Prioritizing work based on business value optimizes time spent. Reverse engineering requirements iteratively from the top down – starting with major components and drilling down into subsets of functionality – gives teams a clear picture of the features currently in place. Comparing those features to current business needs early helps teams document “just enough” requirements – documenting in more detail only requirements for the features that still matter today.
-
Define non-functional requirements for the new systems.
Non-functional requirements, like those for performance, security, and compliance, often get missed. This is particularly challenging for Agile teams. These requirements, however, are critical to an application’s overall usability and maintainability. Strong requirements help teams ensure applications perform well. Roxanne Miller’s book, The Quest for Software Requirements, is a great resource for understanding and eliciting non-functional requirements.
-
Redesign business processes for simplicity.
Modernization projects give teams the opportunity to harmonize and simplify often over-complicated business processes. Strong requirements documentation, particularly visual models, help teams see opportunities to consolidate and re-engineer disparate processes. And while getting a diverse group of business stakeholders to agree to common processes can be painful, it pays off in improved supportability and lower costs in the long run.
-
Institutionalize the knowledge gained and leverage its value.
When requirements for a legacy modernization project are done well, the information is of great value to the organization. Traditional and Agile teams can both benefit. Forward-thinking teams organize and store them in a central requirements repository where they can be referenced, updated, and even reused by future project teams. Teams gain a powerful source of information describing the modernized applications and the business value they are intended to deliver.
Gaining a strong understanding of where you are and where you want to go sets the stage for a successful legacy applications modernization project. Requirements paint those pictures. Taking time up-front to document them well provides you with the tools needed to improve understanding, prioritize effort, and improve processes.
