The last three years of economic turmoil have put many governments under increasing pressure to implement new austerity measures. While this has placed a focus on driving increased efficiency and productivity, departments are also being challenged to make improvements in the level of services they deliver.

As a departmental leader facing choices on how to achieve these conflicting goals, one frequent response is to curtail investments in technology and leverage or extend current systems. Unfortunately, this approach is unsustainable as the costs to maintain and extend these systems grow over time (see sidebar). With 69 percent of IT operating budgets and 54 percent of IT capital budgets now going toward maintaining existing systems, the replacement of expensive legacy applications is critical to any plan focused on reducing the long-term costs of service delivery.

The reliance on legacy applications also creates a significant organizational risk, such as system failures, the ability to respond to new legislative mandates and changing public demands. In Sheila Fraser’s spring 2010 Auditor General’s report on Aging Information Technology Systems, 70 percent of agencies and departments agreed that legacy systems posed a major risk to their organization.

The challenge is how to replace these systems without introducing a new set of risks. To date, the track record of legacy system replacement in the private and public sector has been mixed. While there are successes, there are also many examples of organizations that have embarked on large scale IT renewal projects only to see costs balloon, schedules slip, and in some cases projects cancelled, taking the organization back to where it started from.

Application modernization is the ongoing process of renewing an organization’s application portfolio to better align it with standard technology platforms to support changing organizational needs.

Application modernization principles

1. Application modernization is an ongoing process
Any large organization relies on a broad portfolio of applications. As the highest risk legacy systems are replaced, other relatively new systems will age and become legacy in turn. Even today’s newest applications will need to be replaced one day. This means that application modernization, as an organizational activity, never ends, and as such, must be treated as an ongoing process rather than a sequence of unrelated projects.

2. Application modernization requires discipline
Any ongoing process must be treated in a disciplined manner to ensure repeatability and predictability. Organizations should adopt a framework around how they tackle application modernization projects, including the development of the necessary core competencies needed for consistent delivery.

3. Make vs. buy
Governments around the world deliver similar sets of core services to their citizens resulting in many available commercial solutions. While leveraging internal assets to create custom applications can appear expedient, asking and evaluating “just how truly unique our needs are?” allows departments to look at procuring existing products, or those currently in use within other departments.

4. Avoid “big bang” projects
Since larger projects are inherently riskier, organizations should look at incremental approaches to developing solutions rather than trying to deliver complete functionality all at once. With rapidly advancing technologies, embarking on complex multi-year projects often results in obsolete solutions long before they are delivered. Projects need to be broken into smaller more manageable components.

By applying these four key principles, organizations can begin to think about application modernization in the context of their larger IT portfolio management activities. This makes it a perfect opportunity to more effectively align technology with business objectives and make better decisions when it comes to investment and resource allocation.

 

SIDEBAR
What are legacy applications?
Legacy applications are systems with the following characteristics:

  • They cannot be easily adapted to meet current needs as a result of architectural decisions made during development;
  • They have become “brittle” due to maintenance, modifications, and enhancements. It is difficult to estimate the effort required to make even modest changes; and
  • Skills and equipment to support these systems are becoming rare and costly due to obsolescence.

The term is equally applicable to the 30-year-old mainframe application as it is the five-year-old “quick and dirty” web application.

 

Kelly McDonald is a manager in Deloitte’s Systems Integration, Application Modernization and Technology, Media and Telecommunications consulting practices (kemcdonald@deloitte.ca).