Assessing and rationalizing the IT applications portfolio

There's nothing like putting out a big hairy number to get media attention, and Gartner has just done that with its new statistic it calls "global IT debt." Gartner defines it as "the cost of clearing the backlog of maintenance that would be required to bring the corporate applications portfolio to a fully supported current release state."

And how big a number is it? According to Gartner's press release, it's approximately $500 billion today "with the potential to rise to $1 trillion by 2015."

A bogus statistic
I first heard about the press release through my associate, Vinnie Mirchandani, who points out that this latest statistic was in keeping with a long-standing Gartner tradition:

Gartner made a name starting in the mid-90s forecasting the estimated cumulative cost of Y2K remediation. I was there – and the big numbers it bandied about helped focus enterprises on the core problem. But it also led to hype, panic buying (and exaggerated market declines on the other side of the peak) and many, many poor IT investments. Since then Gartner has picked on many events – such as the introduction of the Euro between 1999 and 2002 - and piled up potential costs to come up with a single, usually scary, related aggregated IT project cost forecast.

Vinnie goes on to point out five reasons why it may be in an organization's best interest NOT to upgrade applications to the current release. Read Vinnie's whole post.

At this point, the easiest thing for me to do would be to pile on. In fact, my first reaction upon hearing about IT debt was to call the concept "bone-headed."

For example, if IT organizations are incurring a debt, to whom do they owe it? To software vendors? If so, it would betray a very vendor-centric view of IT. Gartner's view also assumes that having a software package up to date on the current release is a desired state--a concept that Vinnie pretty much demolishes.

Rationalizing the application portfolio
But, to be fair, it appears that Gartner is using this statistic to highlight the state of disarray in the applications portfolios of many organizations and to "make the problem bigger."

With that in mind, let's stipulate that application proliferation and unsupported versions is a big problem in many organizations. What, then, should a CIO do about it?

I would recommend a formal process to evaluate the entire applications portfolio and assign them to categories, such as the following:

1. Retirement Candidates: those applications that can simply be retired, as they may have little current usage or the business value is minimal.
   
   
2. Consolidation Candidates: those that duplicate functionality in other applications. For example, combining two SAP instances, or an SAP system and an Oracle system. Pick one and standardize on it.
   
   
3. Freeze Candidates: those older applications that have little business value from upgrading to the current release. Mixing metaphors here, in Gartner's concept this would be "debt forgiveness." This might be a temporary strategy for an application that ultimately is slated for retirement or consolidation.
   
   
4. 3PM Candidates. those older applications that still need to be maintained but have insufficient business value from upgrading. These are good candidates for third-party maintenance. This wouldn't be a full "debt forgiveness" but more like "loan modification." You still need the application but are looking for a cheaper alternative to vendor maintenance.
   
   
5. SaaS Candidates: those that would benefit from moving away from traditional on-premise to software-as-a-service. Such applications do not incur "IT debt" in the future, because the service provider keeps the application up to date at all times, unlike traditional on-premise software that requires customers to upgrade.
   
   
6. Upgrade Candidates: those that do not qualify for SaaS conversion but represent strategic platforms that the customer wants to keep current on some sort of schedule. You should avoid making custom modifications to these applications as much as possible, as it makes them more difficult to upgrade.

Now, this is not an exhaustive list of categories, but you get the idea. You have to know what applications you have and what condition they are in and then come up with a strategy for optimizing the value of each. Of course, the list should also be prioritized to determine the criticality and business value of the proposed changes.

Conducting the assessment
On the other hand, it is not always an easy matter to put applications into the right category. Users may have one opinion on the business value or technical quality of the application, while the IT organization may have another. How to evaluate in-house written systems and modifications to packaged software further complicates the problem, as the IT organization may have considerable pride-of-ownership.

In conducting such assessments, we have found sometimes widely differing opinions about whether the problem is the application itself, how the application was installed or configured, or the business processes that use the applications--or all three. In many cases, therefore, it helps to have a neutral third-party participate in the evaluation.

My consulting firm Strativa has experience in conducting these sorts of assessments. You can also read more on our approach in the blog post I wrote several years ago, Four problems with ERP, and a follow-up post, Solving the Four Problems with ERP.

Email me if this is something of interest to your organization.

Update, Sep. 29. My colleague Dennis Howlett has a good post on ZDnet with further reaction to Gartner's IT debt proposition as well as to Vinnie's and my posts. Read Dennis's entire post.