August 17th, 2007
Ever Wonder Why Upgrades Are So Damn Hard?
It’s no secret that every vendor needs its customers to upgrade early and often. While much of this requirement is centered around support costs – vendors have trouble banking all those big maintenance bucks they’re earning if they have to support too many older versions of the software – long-term strategy is also at play. If a vendor can’t convince its customers to upgrade to the latest and greatest stuff that has emerged out of the R&D labs, then how can it justify those expenses – and the marketing bucks that have to be spent to flack the new stuff – to their shareholders.
Meanwhile, upgrading is hard. And potentially costly. And complicated. How complicated was just driven home by a study recently posted by Helene Abrams of eprentise on the company’s website. eprentise is a software vendor that is commercializing tools to help companies navigate the upgrade process. As such they have an interest in exposing the complexity of the problem – but I can assure you her data is no exaggeration, nor is it unique to the Oracle Applications she specializes in.
What Helene has done is build a hand-dandy little table that shows the growing complexity of Oracle Applications over the last five revs, across four basic parameters: the number of modules, objects, columns in the database, and the number of constraints. These numbers are revealing of a problem that dogs the entire market and its collective user base. Oracle 10.7 had 35 modules, while, four revs later, rev 11.5.10.2 has 258. Meanwhile, the number of objects went from 18,072 to 319,715. And the number of columns in the database went from 156,607 to 2,161,603. (The full chart is reproduced here.)
These are order-of-magnitude changes in complexity that are further exacerbated by the tendency of users to significantly upgrade the number of users in their systems – it’s not uncommon to hear of a 50 percent increase in total number of users during an upgrade. And, with most upgrades – Oracle, SAP, and others – involving a shift to service-oriented architectures, the complexity of linking up external services to the internal enterprise suite adds yet another level of complexity.
I could go on and on about this problem. Helene is especially interested in what impact M&A and other business dislocations add to the problem. Other problems crop up to bedevil the upgrade process: Companies like IntelliCorp sell software tools that help manage the upgrade (or sunsetting) of customizations, as well as provide an understanding of what processes are actually being used or not used, and therefore ripe for sunsetting – in this case in an SAP system. And the vendors themselves keep throwing new tools and services at the problem as well.
But, as Helene’s data show, the tools that vendors are bringing to market are focusing on a very fast moving target. Too fast moving by some measures. But that’s the price of progress. And if you don’t like it, you can always opt to stay right where you are. These data show all too well why so many do.
Joshua Greenbaum's opinions on enterprise software have annoyed enough vendors that he now checks under the hood of his PC every morning before he boots up. For disclosures of Joshua's industry affiliations, click here.
| 08/17/07
