cover The Comeback of Legacy Applications by wdf35610


									The Comeback of Legacy Applications
Requirements Definition for Application Modernization Projects

                                       By Carrie Shaw, Director of Products Blueprint

The Comeback of Legacy Applications: Requirements Definition for Application Modernization Projects | Blueprint Whitepaper


In today’s economic climate a corporate philosophy of thriftiness pervades. IT organizations are mandated
to preserve, protect, and extend their existing investments. Companies are not about to scrap legacy
technology systems into which they’ve invested thousands upon thousands of dollars and man hours; they
will instead attempt to meet new technology challenges by leveraging existing applications. Although it
is often tempting to embrace the latest and greatest technology advances, the desire to do so must be
tempered with the ability to understand how new initiatives will integrate with legacy systems. The days of
considering “legacy” a disparaging term are gone, and in fact, to abandon legacy systems in many cases
would be to lose competitive advantage.

Legacy platforms remain pervasive. Research shows that over $1.5 trillion has been invested in COBOL
applications, and more than 30 billion COBOL transactions still occur daily.1 Furthermore Gartner Group
recently estimated that between 60% and 80% of an average company’s IT budget is spent maintaining
existing mainframe systems and applications. Besides being expensive, legacy applications are time
consuming. 2

Furthermore, software evolves with its company. Companies grow: they create new departments and hire
new people; they reorganize; and they invest in their technology strategies. With this evolution, experience is
integrated into technology, and turns into competitive advantage.

Finally with the increase in business reorganizations, divestitures, mergers and acquisitions, and downsizing
– all in an effort to operate as leanly as possible, the result is a vast increase in projects taking the form of
“application modernization”.

Defined, application modernization is the process of evolving existing software assets, and ranges from
complete replacement of a legacy system that no longer performs adequately, to migration of data off of one
platform onto another, to consolidating multiple systems into one, to extending an existing system with a
new interface. This process is sometimes also referred to as legacy modernization.

For the business analyst, any time a project requires legacy modernization a new dimension is added to
the requirements definition process. Not only do the business requirements for the new project have to be
elicited, but this has to be done in light of the constraints and needs put forth by the existing systems. There
is no blank slate here, and this leads to specific requirements definition techniques that will be examined in
this paper.

The key to a successful application modernization effort is to invest the appropriate amount of time in
understanding the legacy application (or applications) that will be the basis for the project. This will require
some creative detective work on the part of the BA, and we’ll look at how to develop that skill. Once
the legacy system’s raison d’être is truly understood, then the BA has several approaches to defining
requirements for a legacy modernization project, which will depend on the type of modernization being
done. There are also several specific requirements practices that appeal when modernizing applications. We
will look at those too.

                Blueprint Software Systems Inc. 372 Bay Street, Suite 1600. Toronto, Ontario, M5H 2W9
The Comeback of Legacy Applications: Requirements Definition for Application Modernization Projects | Blueprint Whitepaper

It bears mentioning that modernization projects don’t require a different set of BA skills; they require an
augmented set. In other words, all the key best practices still apply; we are simply adding to the toolkit.


Understanding the workings of a legacy application is critical to the success of the project ahead of you.
Think of the legacy system as a constraint within which you have to work: it will more than likely have
limitations you will uncover as you dig deeper. There are several key elements to a legacy system (or systems)
that should ideally be discovered:

     • The application’s purpose (over time this will likely have evolved – can you chart its evolution?)
     • The application’s function (this, too, will have evolved, and the more detail you can accumulate the
       better off you will be)
     • The application’s users, and how they are using it
     • The application’s role within the organization, both politically and practically.

While a legacy application may be tenuously functioning, or perhaps even thriving, its evolution through time
and handling by different development resources, many of whom have left the company or retired, often
results in a system that is not fully understood by anyone in the organization, including those responsible
for maintaining it. A legacy system has likely been around your organization for many years, first built or
implemented at a time when technology, programming languages, frameworks and development practices
were a) vastly different than they are today and b) evolving at a furious pace. Often the code was poorly
documented, and changes were not maintained so as to provide any kind of useful history. A legacy system
typically has many touch points throughout the organization, and centralized management that truly
understands all touch points is rare.

Unfortunately for the BA, that does not preclude having to dig deep to understand what is feasible given the
scope and state of the legacy application. The skills of a detective are required to do this, according to Tony
Higgins in his article How to Maintain, Enhance Legacy Applications:

“The skills of a forensic detective are required to gain an understanding of a legacy application’s
implementation and its purpose. This understanding is essential to reducing risk and to making development
feasible. Understanding is achieved by identifying the possible sources of information, prioritizing them,
filtering the relevant from the irrelevant, and piecing together a jigsaw puzzle that elucidates the evolution
of the application that has grown and changed over time. This understanding then provides the basis for
moving forward with the needed development and hopefully turning the corner, providing a foundation for
subsequent development.” 3


               Blueprint Software Systems Inc. 372 Bay Street, Suite 1600. Toronto, Ontario, M5H 2W9
The Comeback of Legacy Applications: Requirements Definition for Application Modernization Projects | Blueprint Whitepaper

Higgins suggests the following sources for background information:

     • The application itself and the source code
     • Any user documentation and training materials
     • Users of the software
     • Test Scenarios, Cases, and regression test sets that may still exist
     • Old requirements models, specifications, or flow diagrams
     • Contracts
     • Personal notes

It’s important to note that with very broad systems you can focus your detective work on only those parts
that are relevant to your project. You may have a single system of record that handles your CRM, ERP, and
Supply Chain Management, but it might only be the CRM functionality that is of interest.

What can be very valuable is that over time is that several enhancements throughout your organization
will be done in this manner, and models of the legacy system can be combined to gradually expose more
and more understanding of the whole. This will make future enhancements easier to implement and more
feasible, thereby increasing the application’s longevity. Win points with your organization by suggesting that
all discovery done on a legacy application be documented in a single place, as a valuable resource that will
grow over time.

Let’s look at a hypothetical example: Blueprint Air is a new front end website to an airline reservation system
that resides in a mainframe and was formerly only accessible to travel agents, who had been trained at length
on the application. The new front end is designed to expose Blueprint Air’s airline database to the public. At
a high level, the Website needs to allow users to search for flights, book flights, check in online, and check
the status of a flight. All of this requires access to the data inside the mainframe system.

Although you may not have drilled deep on the business and functional requirements yet, you know at a high
level what the application needs to do. So some of the questions you will want answered when doing all this
detective work include:

     1) Does all the reservation and flight status data likely to be needed by customers exist? Where? How
        can it be accessed? If not, what is the alternative?
     2) What are the limitations on the up/down time of the system? Is there any time at which information
        cannot be accessed? Will this be acceptable to customers?
     3) What are the security constraints of accessing the database, and can you integrate with them without
        distracting users?
     4) What are the performance constraints of accessing the database (knowing that an overall goal is to
        provide quick access to flights to your customers)?
     5) What business rules are baked directly into the legacy application that have the potential to
        conflict with your requirements? (For example, the system may have a restriction on modifying
        existing reservations without administrative access. This may not work for your project).

                Blueprint Software Systems Inc. 372 Bay Street, Suite 1600. Toronto, Ontario, M5H 2W9
The Comeback of Legacy Applications: Requirements Definition for Application Modernization Projects | Blueprint Whitepaper

Getting some of these questions answered sooner will prevent “oops” moments later in the project. In other
words, don’t assume that the legacy system will meet your requirements perfectly, no matter what anybody
tells you. The reality is, it won’t, and the sooner you and your stakeholders make the right tradeoffs, the
better off you’ll be.


While the approach to implementation may not be chosen until after all requirements have been defined, it
is important that the BA understand what is available. Beware a common mistake, which is trying to make
the choice before the requirements are well understood. The company mandates an extension because a
replacement is too expensive, but then it turns out that the legacy application is performing so poorly that a
replacement is the only valid route.

Though you may not, as the BA, be involved in all the technical intricacies of the discussion, it is a good idea
to understand these options because they will have a direct impact your team’s ability to implement the
solution. Furthermore you should ensure that the technical groups have all of the business requirements you
have prepared, so that they are educated to make the best possible decision.

Initiatives can be categorized as follows:

     1) Cloaking – the most common form of application modernization, cloaking involves putting a new
        front end on an older system. Enhancements to the system may also be accomplished with cloaking.
     2) Consolidation – large companies can sometimes fall victim to multiple implementations of the same
        systems (one company recently reported 7 instances of SAP!) Over time the cost of this is
        astronomical and must be contained. At some point, a centralized imitative to consolidate all
        instances of the same application will be necessary.
     3) Replacement – a full replacement of the legacy system to a newer technology, either via a packaged
        application or a new custom build.


With cloaking it is often a web-based front end that gets wrapped around legacy technology, providing a
protective cloak. The bulk of the changes are made to the front end, while the back end, though it remains in
use, does not have to be updated very often.

These projects are sometimes referred to as “brownfield deployment,” to borrow a term from environmental
discussions, meaning an upgrade or addition to an existing IT solution that leverages and integrates with one
or more legacy components.

A typical brownfield deployment project might be, for example, to create a new web front end to a Human
Resources or Payroll system that runs on a mainframe. The mainframe system will continue to function as the
data repository, and the new user interface will be the gateway between user and data. Another example
might be a commerce-based ordering system that integrates with existing billing and fulfillment legacy
applications. Our Blueprint Air example is a cloaking example, too.

               Blueprint Software Systems Inc. 372 Bay Street, Suite 1600. Toronto, Ontario, M5H 2W9
The Comeback of Legacy Applications: Requirements Definition for Application Modernization Projects | Blueprint Whitepaper

The Internet is usually the driving force behind this type of application modernization today, and as such,
many modernization approaches include the creation, integration, and delivery of web-based front ends,
which can save a company time and money by extracting functionality “locked” within the legacy application
and delivering it to end users.

Typically, this is accomplished with either screen scrapers (also known as “frontware,”) – non-intrusive tools
that “scrape” a back end application for data, and then present it to the user over the web, without making
any changes at all to the legacy platform. Screen scrapers can be developed and implemented quickly, but
they suffer from a lack of scalability.

Legacy wrapping is a second non-intrusive approach. The technique typically builds APIs around legacy
transactions, providing an integration point with other systems. Wrapping also does not fundamentally alter
the hardwired structure of the legacy system.

A third, more involved approach is EAI – Enterprise Application Integration. This generally includes a
middleware layer consisting of data translation and transformation, rules and content-based routing, and
connectors to legacy applications. These solutions can often be XML-based. They differ from wrapping in
that there is more logic and functionality in the middleware layer.


Consolidation of multiple legacy systems can be complicated, as consolidation must resolve the needs of
many stakeholders, and bring together many development teams. Finding a common set of requirements
that are agreed upon and signed off by everyone is crucial to the success of a consolidation effort.

Consolidation may be around a single platform – such as the case of the 7 SAP implementations noted
above, or it may be around many platforms. A recent study involved an investment bank looking to
implement an Enterprise Data Management platform – a COTS solution, and a survey of each of the groups
within the bank uncovered that there were five disparate EDM systems; some purchased, some homegrown,
already in place. Upon diving in, business analysts realized that each of those systems had been purchased
or developed when those groups realized that existing systems did not meet their requirements, most often
due to disparate data feeds that used different nomenclature to reference the same securities. This resulted
in the need for a highly flexible system based on a transformation language that allowed each group to
specify their own way of expressing a security. The key to the success of this project was accurately capturing
each group’s specific needs, to a very fine level of granularity, and then matching those needs to existing


Older systems – either custom or off the shelf – can be replaced with modern, packaged software and
hardware now available from a variety of vendors. This approach becomes necessary when the code quality
of the original system is so poor that it can’t be reused or leveraged. One of the drawbacks of this effort is
that the cost of customizing the package to suit your needs can be high.

                Blueprint Software Systems Inc. 372 Bay Street, Suite 1600. Toronto, Ontario, M5H 2W9
The Comeback of Legacy Applications: Requirements Definition for Application Modernization Projects | Blueprint Whitepaper

Typically replacement systems are COTS packaged software. Custom builds are more infrequent, due to high
costs of implementation and time to market.

Again, this is an opportunity for business analysts to get in early and help define the requirements for the
initiative, so that the customizations can be appropriately scoped and estimated. Some COTS solutions even
come with requirements definition templates to help business analysts identify areas for configuration and

Customization carries with it inherent risks that the new system won’t adequately duplicate a unique set of
business processes, coded to by the old system, so this is another area where BA work is critical: in modeling
the business processes the new system is to support.

Replacement systems can come with hefty license fees and retraining costs, so organizations should tread
carefully when deciding to adopt them if cost is of utmost importance.

With the combination of deep understanding of the legacy system, and equally deep understanding of the
requirements for the new project, the best approach can be selected with confidence. Once the approach
has been chosen, it is up to the BA to go one more round to ensure all requirements can be accommodated
by the solution.


The classic catch-22 is whether to model the desired state first or discover the legacy application first. If
you discover the legacy application first, you go into requirements design with a good understanding of
the constraints within which you have to work, and you can head off unnecessary feature requests at the
pass, because you’ll know that they are not feasible given your current system. However, if you develop the
requirements first, you will have a better understanding of what the legacy application needs to provide,
resulting in smarter detective work.

The reality is you’ll probably do a little of both at the same time. Start with some high level requirements
elicitation sessions, working with your stakeholders and textual requirements, and then start diving into the
legacy system for feasibility. In this age of multi-threading, you’ll likely go back and forth between the two
tasks. The trick is to keep good, open communication lines with stakeholders, co-project participants, and all
those you rely upon to give you information about the legacy system.

The importance of interviews

With legacy projects, you will need to do more interviewing than usual. You will spend a lot of time with the
line of business, as usual, eliciting their business needs and goals.

You will interview end users (either of an existing system you are modifying or a new system you are defining)
in an effort to capture user scenarios and user interface requirements.

               Blueprint Software Systems Inc. 372 Bay Street, Suite 1600. Toronto, Ontario, M5H 2W9
The Comeback of Legacy Applications: Requirements Definition for Application Modernization Projects | Blueprint Whitepaper

And as we saw earlier, as part of your detective work, you will also interview staff within the organization
who have been involved with the legacy application’s evolution: users, administrators, developers, testers,
business owners, and more. As a result of this legwork, you can create:

      •    Integrated Business Process Definitions
      •    Use Cases
      •    User Interfaces, and
      •    Data, Business Rules, and Decision Trees

And provide your development team with comprehensive, detailed deliverables.

Tag requirements with impacted legacy systems

When modeling the desired state, it’s a good idea to pinpoint those requirements that have a specific
reliance on the legacy application with as much accuracy as you can. For example, while requirements for
creating an account on Blueprint Air and logging in have nothing to do with the legacy application, accessing
flight schedules for availability most certainly does. Flagging these – with a custom property or other type of
user interface pattern – allows you to later group all requirements that can only be met if your legacy system
cooperates. Of course this works with multiple dependencies on multiple legacy systems as well.

An implementation specialist at a big consulting firm, for example, follows this procedure:

“Our general process… is to use functional requirements or business scenarios that are in place and for each
one identify the Impacted Legacy Applications, and Integration Latency (Sync/Async/Batch). Then you can
group them by Legacy Application into a conceptual design and/or develop the interface agreement. We
generally use the interface agreement as the detailed requirements for integration with a trace back to the
functional requirements or business scenarios.” 4

In other words, for projects where multiple legacy systems are impacted, this team tags certain requirements
as being relevant to a particular legacy application. They also identify the type of integration required with
the legacy application: synchronous, asynchronous, or batch. Then, across projects, requirements with the
same tags can be grouped together to begin to paint a bigger picture of the integration required to the
legacy application. This is a form of componentization that saves time and keeps everything in one place.

Validation and acceptance: bringing it all together

The fruits of your labor are about to pay off, as you combine your detective work, which helped you to
uncover integration points and touch points, and your desired state, which will meet the needs of your
stakeholders. During the review process of your requirements model, you will tell a story of how the user
navigates the new application and where the legacy system is touched. To use an example from our Blueprint
Air application:

[4] Interview, anonymous partner at consulting company.

                Blueprint Software Systems Inc. 372 Bay Street, Suite 1600. Toronto, Ontario, M5H 2W9
The Comeback of Legacy Applications: Requirements Definition for Application Modernization Projects | Blueprint Whitepaper

      Step 1. User enters search criteria for flight
      Step 2. System accesses legacy application
         Step 2a. System provides credentials if necessary
      Step 3. Data is passed to Blueprint Air and presented to user
      Step 4. User evaluates data and either selects flight for booking or performs a new search.

To the extent possible, screen shots and flows can be validated here as well.


Organizations today understand that if their technology is stagnant they are falling behind in their business,
and with equal conviction they realize they have neither the time nor the inclination to develop new
applications from scratch. The modernization of legacy systems is crucial to maximizing IT value, reducing
the total cost of ownership, and meeting corporate objectives.

Once the decision to modernize is made, the success path of a legacy project is placed firmly into the
hands of the business analysts. BAs must take into account from day one the boundaries implied by legacy
applications and must do the diligence to reverse engineer the application until they feel they’ve discovered
enough about the past. They must then go about modeling the desired state with the legacy application in
mind. With critical best practices of organizational agility, and early and often communication, BAs will be
well positioned to succeed with application modernization initiatives.

               Blueprint Software Systems Inc. 372 Bay Street, Suite 1600. Toronto, Ontario, M5H 2W9

To top