App Consolidation: A Strategy That's Always In Style

Application consolidation should never go out of style. Sure, the cost-cutting pressure of the recession has eased a bit, but there are new forces--a Windows 7 rollout, increased M&A activity, new application development--that call for the discipline to cut unnecessary apps. Complexity is every bit as big a problem as cost, and app consolidation helps fight both.

Think it's time to focus on growth and not sweat so much about trimming those software maintenance and support staff costs? Hewlett-Packard CIO Randy Mott doesn't have that one-or-the-other luxury. Mott led a massive, three-year transformation and consolidation of Hewlett-Packard's IT operations, culling HP's apps from more than 6,000 to about 1,500 in late 2008. With the subsequent growth-minded acquisitions of EDS, 3Com, and a few other companies, HP's app count crept up to almost 2,800. So Mott has reset the goal: 1,000 apps by the end of fiscal year 2011 is the new target.

In terms of business justification, the case for consolidating apps is one of the easiest to make but the hardest to implement. Every application has a loyal constituency of users adamant about not losing the perceived unique capabilities of (and their comfort level with) their app of choice. App consolidation often becomes a political nightmare that scares IT away from forcing tough choices.

It's why former General Motors CIO Ralph Szygenda made app consolidation visual. First, he got fellow business unit leaders to buy into the notion that cutting apps is needed to improve business processes, not just make IT cheaper. Together, they agreed on measurements, such as what percentage of apps are common versus unique to a business unit. Then he provided reports that showed who was meeting the app-cutting goals and who wasn't. "If they can't visualize how good or bad they are, it's 'IT guys, go away,'" says Szygenda, who cut about 3,500 systems out of GM's app portfolio in the late 1990s and early 2000s, before retiring last fall. "It's a little bit of embarrassment."

The drivers are pretty clear and revolve around cost and complexity. The more complex the software and systems involved, the greater the return for consolidation. The recurring annual maintenance costs paid to vendors for conventional software can be extensive. Beyond that, internal staff, contractors, and vendor services to keep the lights on and make changes can also be significant.

A catalyst such as the Windows 7 operating system upgrade can be just the spark companies need to take on the application consolidation challenge. So can a data center consolidation project or a hardware refresh--which is what Mott did, consolidating 80-some global data centers to six. Just be careful not to introduce too much change in the environment without proper testing and an appropriate process. Sometimes, the allure of new systems can be appealing and the rush to implement can cause significant business problems.

When developing the business case, first develop then validate your requirements, as some capabilities in existing systems may no longer be required. Be sure to include a wide range of stakeholders representing all aspects of the system. You might pick one of the systems you have, or you may find new options--commercial vendors offering software choices that didn't exist before, letting you decommission custom code, for example.

Or there may be new software-as-a-service and cloud delivery options, and the cost savings from these models may be a big driver to justify the consolidation. Even if you don't consolidate, it's helpful to perform this exercise formally at least annually to ensure you're aligned with the business objectives the application was designed to meet.

That inventory process also might yield some surprises as to the extent of the "shadow IT" in a company. When Mott's team members at HP started their IT transformation, they thought HP had about 3,500 apps. It was more like 6,000. That surprise alone might point to the need to consolidate apps.

The Windows 7 Opportunity

Upgrading to Windows 7 presents a golden opportunity to deal with desktop application sprawl. Most organizations perform only two or three desktop OS upgrades a decade, and a great many skipped Vista, so the move to Windows 7 lets them take a hard look at the apps users are running and see if they still make sense to run and support.

Microsoft doesn't offer any simple option when upgrading XP to Windows 7, which is the move most companies will make. You need to select the Custom option during Win 7 installation, which doesn't preserve your programs, files, or settings. These "clean" installations are even more rare than the run-of-the-mill operating system upgrade. That makes it all the more important before upgrading to perform app analysis--not just if apps are compatible, but if they're needed.

But most companies aren't using their Win 7 upgrades to aggressively cull incompatible applications. When they find an app that's incompatible with the new operating system, just 12% expect to stop using it and find a compatible one, according to our InformationWeek Analytics 2010 Windows 7 Survey of 699 business technology professionals at companies with 500 or more employees. The most common strategies show IT accommodating the offending apps--using XP mode is the primary or secondary approach for 88% of companies. That might be the right choice, but it shouldn't be the default approach. Only half of survey respondents consider ditching the app for a compatible one as a primary or secondary approach.

In a major project like an operating system upgrade, IT can get dialed into problem-solving mode, including figuring out how to port every app to make everyone happy. Pragmatic IT shops, however, will step back and evaluate the needs of their organizations and determine which applications they can do without.

From My Cold Dead Hands

Most people don't like change. So when you come knocking on their door telling them they have to change their software tools, expect a cool reception. Depending on the scope of the change, it's important to communicate the reasons to the users who are affected. As a general rule, if they can understand the business motivations, they will at least appreciate why the consolidation is occurring.

One of the toughest choices is between overlapping tools in different groups. Here, you may end up in a religious battle, so try to include less fervent members of each group in the decision process. Getting people involved in the requirements process may make people more likely to support the initiative. In cases where the decision on which app to choose is arbitrary, management needs to be up front with the user community. Bring the conversation back to the root causes for consolidation and focus on the savings to the company and benefits that will be achieved overall.

These emotions can multiply when a merger or acquisition is involved, since people already are worried about keeping their jobs. When Wells Fargo bought Wachovia in late 2008 in one of the megadeals of the banking crisis, it essentially had at least two of every system needed to run a bank and brokerage company. So Wells set a consolidation and integration policy: Use the Wells Fargo system unless there's a compelling reason to use Wachovia's (as was the case with its brokerage system). A third option was to bring in a brand new system, but that faced a high bar to prove it was worth the cost and disruption.

When tensions run high, rallying around the moderate users may help win people over, especially if the chosen system actually delivers superior business capabilities and performance.

Szygenda describes his strategy as "chunking"--delivering value that business units recognize from the consolidation effort in chunks, at least every three to six months. Be warned: IT will resist the "three" part and argue that every move will take at least six months. "Be driven by speed," Szygenda says.

How To Consolidate

With the business case approved and users on board, the consolidation process begins. Hopefully, your organization has service transition policies and procedures and perhaps uses best practices (from ITIL, CMMI, SDLC) to introduce and release changes.

One of the areas to pay close attention to is data migration. If you have multiple systems, you may have multiple sources of data. Deciding what to do with that data is a big question; there may be legal or regulatory requirements to retain it.

You need to decide whether to simply archive that data or make it actionable. The data normalization exercise is often the most labor-intensive. A mapping exercise will help determine standard formats that can be used in the consolidated systems. Then, however, the ability to import the data varies widely. Especially in complex enterprise applications, the data mapping can be tough. Working with a small subset of the data is the best way to begin. Then begin mapping data elements and determine how gaps or extra information that may not fit within the consolidated system will be handled.

You also need to set hard deadlines for decommissioning legacy systems. If you don't, users will continue to use both systems and create new sets of data. Carefully consider how you will schedule the transition and rollout. While many make the case that business operations can't be interrupted, so systems must run in parallel, it will be harder than you think to eventually shut the system down.

It will also create additional complexities with data. Especially in cases where the user interface is different--Microsoft Office 2007 was an example--many users will just never switch over until they're forced to. If some process relies on enterprise data from a legacy system you don't want to keep active, some systems allow a read-only mode that can let people see data but not enter new information.

Big-Impact Consolidation Areas

Many companies have overlapping applications, but some areas deliver greater consolidation costs savings than others, so CIOs should focus on those first. Obviously, large, complex applications will show up first on the radar screen. ERP, CRM, and IT service desk tend to be the most common areas of application overlap for large companies. Mostly as a result of mergers and acquisitions, organizations have inherited systems that once worked well for a smaller company but now don't scale to integrate into the rest of the application suite.

Don't underestimate the amount of change involved in swapping one ERP system for another. The acquiring IT team may be familiar with the ERP or CRM system they're bringing in, but to the end user, it's all new. From a change management perspective, it needs to be treated like any ERP implementation.

With acquisitions, there's a big incentive for application consolidation. However, the purchaser may not want to initially disrupt business operations, so the acquired entity is permitted to continue using its applications for 12 to 18 months. Without a lot of discipline, these systems will linger much longer.

Letting large enterprise applications, such as IT service desk, hang around has a significant downside. Without the ability to centrally report and manage incidents and problems, it's hard to improve the IT operations environment. While federated reporting can alleviate some of these challenges, the real value is through using a centralized management.

Enterprise management applications, such as network and application fault and performance monitoring, are another prime area for consolidation. These tools are often costly, and the polling of devices can slow down overall system performance. Since these apps are also difficult to support, consolidating them also frees up staff time.

Any type of productivity software, such as e-mail and other collaboration systems, is also a good candidate for consolidation. The nature of these products requires interoperability, and few of them have differentiating features.

Custom-developed applications should also get a hard look. Unless they offer truly unique business capabilities that can't be replicated with commercial software, custom products cost more to maintain than commercial alternatives, if they exist. However, application consolidation of custom systems can be especially challenging. Their capabilities have been closely crafted for business processes, and developers often put years of their sweat into them, so expect a revolt against discarding them for an off-the-shelf option.

GM's Szygenda recommends putting a "fence" around those big legacy systems early in an app consolidation--freeze changes to them, and focus on systems where the benefits won't take $500 million and a couple of years, as legacy replacement can. At Bell Atlantic, where Szygenda was CIO before GM, the company created a policy that changes to certain legacy systems it had inherited from AT&T required a formal request to an executive VP. "Eventually, nobody sent in a change anymore," he says.

Information security systems are a final area for consolidation. The rush to solve specific security problems can spawn sprawl--standalone intrusion-detection systems, firewalls, anti-spam and antivirus software--when similar tools may exist as features in network infrastructure or e-mail systems you already have. Innovations usually show up as point products before they're built in as features in broader-use tools such as infrastructure or e-mail management. To consolidate, it might mean expanding the role of those tools as capabilities grow.

With all these systems, it's important to know what they really cost to support and maintain. HP's Mott created a rule when it comes to IT budgeting: no "enhancement" of an application. Either it's a new development project, with a revenue goal and a business unit supporter, or it's maintenance. That keeps the focus on innovation and new projects, and the pressure on cutting legacy support. And having that real cost data makes it easier to make unpopular decisions, like eliminating an app and changing the processes related to it.

In the process of app consolidation, IT can drive other efficiency goals. Virtualization is one. Dell tackled a massive application consolidation effort under CIO Robin Johnson, slashing the portfolio from about 8,000 apps to less than 2,800 in about two years. In parallel, Johnson drove a "virtual first" agenda. As IT and business units assessed each app, they also considered whether to run it on virtual machines--with a presumption that it would be virtualized unless there was a good reason not to. Dell virtualized about half of its servers in the process. Wells Fargo took a similar approach with its post-acquisition consolidation with Wachovia.

Eventually, the major app consolidation effort will be done. Congratulations. Unfortunately, you're just one purchase order or merger or growth initiative away from starting over. A clear process to evaluate systems on a regular basis is critical.

How do you know when your app consolidation has gone far enough? Johnson at Dell offers this rough guideline: "I don't know that there's an end goal. I think you just drive that continuously until the screaming's unbearable."

Johnson's point: No one's going to thank IT for consolidating apps. It's part of what he describes as the CIO's constant mission to attack fixed costs.

The gains of app consolidation come from those lower fixed costs, yielding savings that business units can pour into new development. They also come from reducing complexity. Whether you're in cost-cutting mode or a growth cycle, app consolidation needs to stay on your agenda.

-- With Chris Murphy

Michael Biddick is president and CTO of Fusion PPT, a consulting and IT services firm.

You can write to us at [email protected].