Packaged Applications - Not all they're cracked up to be?

Infoworld has a big story this week on packaged applications and their hidden costs.

A NOSTRUM of the late '90s was to dump internally developed, custom applications in favor of packaged applications. But the hidden costs of those packaged apps are coming back to haunt many companies that implemented them too hastily. The motivation behind that lurching, tectonic shift was the horror generated by over-budget attempts to build systems internally. An entire generation of in-house programmers was pulled from projects and thrown at ERP and CRM systems -- or out the door -- because executives believed that packaged apps would fix the problem of hidden costs. "Companies that had been building their own software for 40 years started thinking maybe they didn't need all those people, and that was a sign of something bigger: a crisis of confidence," says Tom DeMarco, a Camden, Maine-based principal at Atlantic Systems Guild and co-author of Peopleware. DeMarco thinks the rush to packaged software was accelerated by organizations losing confidence in their ability to invest wisely in IT and the creeping belief that original works of code were merely a cost, not an investment. But the hidden-costs problem didn't go away with the adoption of packaged apps, which can hide even more expenses.

That's an understatement. Very few companies take packaged applications as-is. Instead, they customize. This has two problems:

1. The application is now forked from your vendor's version, making upgrades harder
2. The application wasn't necessarily written with the kinds of customizations you had in mind

I see this at Cincom - we have an internal bug tracking system that is a heavily customized version of (an external vendor's software) product. We are now 2 or 3 versions out of date, because our internal staff could not upgrade the product and the customizations in synch with the vendor. The vendor can't support our version with normal support, since it's so heavily customized. So we spend precious dollars on support of an out of date application. I'm not beinging this up to embarass our IT group; it's hardly a unique problem. My point is that, in general, packaged applications end up being at least as much trouble to maintain and upgrade as custom ones. While you may become dependent on a particular version of a development tool or set of libraries, upgrading - given source - is typically a resource issue. With a packaged application, you likely don't have source, and API's you depend on could disappear. You can end up just as far down the river. Basically, TANSTAAFL. Here's another interesting snippet from the article:

"If companies were feeling defeated by custom software, then packaged software has proven an even greater defeat. The fiasco with Oracle last year indicates that even upgrading a package isn't affordable," DeMarco adds, referring to the snarled application-migration problems last August that purportedly cost Agilent more than $100 million.

Read the whole article - it's thought stimulating.