To build or to buy IT applications?

It’s a question of Shakespearean proportions. Should you license a commercial enterprise application that will meet 75 percent of your needs, or would it be nobler to build your own application, one that will track as closely as possible to the task at hand?

Decades of trial, error, and egghead analysis have yielded a consensus conclusion: Buy when you need to automate commodity business processes; build when you’re dealing with the core processes that differentiate your company.

But reality isn’t quite so orderly. Creaky, complicated systems developed in-house may handle mundane tasks, but astronomical switching costs may make them impractical to replace with commercial software. And in some instances, packaged software -- even SaaS (software as a service) offerings --may fit the strategic plans of an enterprise hand in glove. “Buy to standardize, build to compete” may be terrific as an ideology, but the choices that real companies face are a lot messier … and more interesting.

As enterprises from MCI to Motorola to Visa weigh the build-or-buy decision in their projects, two overarching trends emerge. First, as vendors saturate the market from general-purpose CRM to the narrowest vertical solution, the economic pressure to buy and consolidate (or subscribe and let a SaaS provider deploy and maintain) continues to mount. And when companies decide to build, they strive to ensure that the functionality created is as reusable as possible across the organization.

“Everybody knows that the more standardized you are and the more you buy off-the-shelf, the more cost effective it will be for both implementation and ongoing maintenance,” says Mark Lutchen, former global CIO of PricewaterhouseCoopers, now head of the firm’s IT Effectiveness practice.

On the other hand, executives such as Bob Laird, IT chief architect at MCI (now part of Verizon Business), sing the familiar refrain of in-house development: “Where we tend to invest is where we can get incremental revenue … or competitive advantage,” he says.

As with many modern enterprises, Laird and team have recast their in-house development efforts within an SOA, enabling them to reuse rather than build from scratch. “Part of the decision is to look at your legacy applications and analyze what legacy you have that still has business value,” he says.

Build-versus-buy decision points remain the same: cost, time to market, politics, architecture, skill sets, and strategic value. Additionally, vendor consolidation has led to new pricing models and bundling options that give customers much greater leverage.And finally, open source is delivering the best of both worlds, with hybrid approaches that combine purchased and custom-built components. Pop the hood on any large IT organization, and you’ll likely find a wild mix of all these approaches.

Pulling out the checkbook

Most IT execs say they evaluate commercial software first, particularly when time-to-market and money are top priorities. The rule of thumb, PricewaterhouseCoopers’ Lutchen says, is to buy applications to the maximum extent possible to cut costs -- freeing up resources for whatever really needs to be built in-house.

When evaluating whether to buy or build, it’s critical to thoroughly understand total costs during the software lifecycle -- typically seven or eight years. This step is important, Lutchen says, because 70 percent of software costs occur after implementation. A rigorous lifecycle analysis that realistically estimates ongoing maintenance by in-house developers often tips the balance in favor of buying.