It’s a system, not a family member

A funny thing happens to some people when they become involved with software: the system becomes something more than just work and an emotional bond forms. Like many loved ones, there are times when it generates pride and times when it causes you to cringe. Some relationships are nurturing, some dysfunctional and others abusive. Regardless, it is your system.

There is a definite upside to this phenomena. Those responsible for the care and feeding benefit by having a committed user base. Likewise, users benefit when those maintaining the system are invested. After all, who wants their livelihood in the hands of someone who is indifferent to the outcome?

The downside, however, is that people forget that lifecycles have an end. Technology changes. Business processes change. Better things come along. Unfortunately, too many companies are overrun with vampire systems that refuse to die, sucking up resources that could be put to better use.

Capgemini’s 2011 Edition of their Application Landscape Report contained some very bad news: 85% of the IT executives surveyed reported that they had redundant applications and 17% felt that ten percent or less of their applications were mission critical. Maintenance of obsolete and/or redundant systems represents time and money lost to those systems that do provide business value.

The Application Landscape Report identified four culprits:

  1. Mergers and acquisitions result in many redundant systems with duplicate functionality.
  2. Custom legacy applications are becoming obsolete and are difficult to maintain, support, and integrate into the new, modern IT infrastructure.
  3. Companies continue to support applications that no longer deliver full business value and do not support current business processes.
  4. Most organizations have a data-retention and archiving policy, but in reality the majority of companies are not willing to archive application data for fear of violating industry and government retention requirements.

Mergers and acquisitions will, of course, lead to duplicate systems (if only in common back office functions like accounting). How long that situation is allowed to last is key. Identifying redundancy and planning for its remediation should be accomplished as soon as possible (ideally as part of the acquisition planning). It should be noted that the acquired system need not always be the victim. A post from November advocated periodic re-evaluation of processes. This is an example of when that should take place, with an eye toward keeping the system that provides the best value and best matches the current business process.

The Application Landscape Report also identified reasons why nothing is done about applications accumulating:

  • Cost of retirement projects. IT budgets are typically allocated based on the costs of maintaining existing applications or continuity costs and new projects. Finding additional funding for application retirement can be challenging – especially in difficult economic times.
  • Lack of immediate ROI. It is often difficult to get buy-in for application initiatives because time horizons for investment decisions tend to be short term and rarely over one year. Many businesses expect to see ROI on projects in six months or less.  With rationalization initiatives, it is not easy to show quick ROI – especially if rationalization projects involve different types of applications. “In the last two years, we have reduced the number of data centers from 20 to five,” says an IT executive from a global French telecom company. “Data center rationalization takes much longer than changing small applications.”
  • Company culture and behavior. Employees are often resistant to change. People become comfortable using certain technology and processes, and as a result, become reluctant to any changes to the familiar and consistent environment.
  • Differences between regions. Different regions, subsidiaries and even groups within an organization may have different opinions regarding application retirement. Without their buy-in, any retirement initiative is likely to fall short, as IT would still have to support redundant and de-centralized applications.
  • Lack of qualified developers to migrate retired application data and functions. This is especially true for custom-designed systems. The people who were involved in building them are no longer with the company, and nobody fully understands the underlying processes and complex relationships between application components to successfully migrate the data and safely decommission an application.
  • Some companies do not consider retirement a priority. As we mentioned earlier, some IT leaders simply do not see the value in application retirement and therefore choose to focus efforts on other areas.

The bullet points on cost, ROI, and priority are inter-related. In order to get a true picture of the costs of maintaining versus retiring, you need to go beyond the obvious costs of hardware and application maintenance hours. Other costs associated with redundant and/or obsolete systems include:

  • Platform maintenance:  Hours spent maintaining the OS, database and other plumbing for the system must be added to the cost of the hardware.
  • Backups:  Time and storage costs add up as well.
  • Reporting:  Whether you have scheduled ETL  jobs feeding a data warehouse or run ad-hoc data query scripts when questions arise, those costs need to be assessed.
  • Licensing:  Not just for the system itself, but also for the OS, database, and other components and utilities needed to keep it running.
  • Training and Experience:  Each system supported represents a need for experienced personnel (with appropriate backstop for vacation, illness, etc).  Developers are the obvious source of cost here.  Additionally, help desk staff and infrastructure support staff have to be accounted for.
  • Productivity:  How many inefficient processes exist to work around the limitations of the current application landscape?

In addition to cost, risk needs to be taken into account. Parts for legacy hardware can be difficult to find, regardless of what you’re willing to pay. If a company is resorting to acquiring boxes via auction sites in order to cannibalize them, there is a significant risk to their ability to maintain operations. Likewise, as technologies age, those with experience become harder to find and more expensive to engage. Just parts shortages pose a risk, so do shortages of experience.

Differences between regions and other groups within an enterprise can lead to redundancy. Careful analysis must take place to determine how significant those differences are and whether consolidation can make sense. Function, cost, and risk all must be taken into account.

Resistance to change is the hardest factor to deal with in that quantifiable factors like cost and risk aren’t the issue. Emotional, cultural, and political factors are more likely the problem. Additionally, you need to be aware of your own investment in the systems under examination. A healthy dose of soft skills, as much engagement as education, will be needed to overcome others’ attachment to the old system. Self-awareness and objectivity are needed on your part.

After all, it’s a system, not a family member.

Advertisements

2 thoughts on “It’s a system, not a family member

  1. Pingback: Application Lifecycle Management and Architecture « Form Follows Function

  2. Pingback: What do you do when you find yourself in quicksand? « Form Follows Function

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s