A Brief History of the ERP Problem

Last week’s acquisition of Peoplesoft by Oracle is the final example of how badly the original mission of enterprise software–business and technology integration in a box–has failed. Oracle isn’t buying software in this deal; it is buying customers–not just Peoplesoft’s but J.D.Edwards’ as well.

These customers are locked into paying yearly contracts for maintenance and support that they cannot afford to drop. They don’t want to buy much new software anymore because the software model they bought into has failed (we can stop using the economy as an excuse now). But most can’t afford to get out of this mess or even upgrade to a newer release of what they have because it causes too much disruption in their businesses.

So by buying Peoplesoft, Oracle gains a larger pool of people who can’t afford to stop giving the company a steady stream of revenue. Consolidation of this kind isn’t about product or strategy; it’s about owning the water fountains at the oasis.

The New York Times’ Steve Lohr did his usual great job of business analysis in his look at the Oracle acquisition, but he’s wrong about this specific software market when he says that customers have the upper hand. Vendors have their customers by the enterprise software and they are not letting go. Sure, customers can refuse to buy more new stuff, and that certainly helped drive this merger, but they can’t–or won’t–walk away from the maintenance and support for the packages they have. J.D. Edwards users were forced to walk to the Peoplesoft oasis, and now all of them will begin the dusty trek to Oracle’s fountain in the desert.

To understand why these customers are in such a pickle, you have to go back to the surreal days before Y2K.

You remember the marketing drill, right? Mainframes don’t have enough digits and they’re going to destroy your business (really?). Worse, they can’t talk to any other system you have. Buy enterprise software and you will escape the Y2K apocalypse, create seamless technology integration across the company and force your silos of isolated, sociopathic bureaucrats to start working together. It was an irresistible sell to businesspeople.

But the model was broken from the start. These systems really were designed to run a business from end to end in a fully integrated fashion. All your information sits in a single database shared by all. When the landing dock gets a shipment, finance will know it immediately (see the ABCs of ERP for a more thorough explanation). And that was their downfall. Developers who believe they are modeling an entire business in software don’t spend much time thinking about how that system will connect with other systems. Who needs other systems when we’re creating the whole thing right here?

Of course, as soon as companies began buying these products, it became clear that enterprise software was another chunk–a much larger and better integrated chunk to be sure, but still a chunk–of software in a complex architecture of IT systems that desperately needed to talk to one another and exchange information. The vendors created clunky, proprietary methods of connecting their systems with others that have improved over the years, but that misses the point. The architecture of these systems, in a broad sense, was just like the ones that they were intended to save you from–monolithic, highly integrated and difficult to change.

No problem, said the vendors. Some of your maintenance and support fees are going to future R&D. As we develop new pieces to add in to our highly integrated suites, we’ll let you upgrade to the next version for free and you can gradually get rid of all those other troublesome chunks. Again, it sounded great to the people buying the stuff–businesspeople.

But who could afford to install enterprise software as it was envisioned in the vendors’ R&D labs? Very few. CIOs built complex integration links from enterprise software to other systems to keep the business running. Or they chunked up the installation, building dozens or even hundreds of unique installations of the same enterprise software to meet needs of individual departments or businesses that all had to be linked together. The high degree of integration envisioned in the R&D lab was tenuous at best inside most customers.

Meanwhile, CIOs alienated the business by passing on the enterprise software vendors’ absurd vision that the business processes built into the software should be adopted by every customer. Change your business to fit the system. CEOs like the sound of reengineering, but take that logic to the departmental head who won’t be able to serve her customers as well with the process in the software box and things don’t sound so good. CIOs were forced to tinker with the innards of these packages to avoid losing valuable chunks of business processes and it made their lives hell. Vendors ignored this reality for years. Changing the system to fit your own processes meant you were a weak girly man who couldn’t stand up to your business people. Those processes couldn’t be any good anyway if they hadn’t made it into the vendors’ best practice pool when they developed the stuff. It was like turning your Pinto into a low rider. You just voided the warranty, dude. Tough luck.

When a new version of the highly integrated suite arrived with cool new features, customers literally could not afford to install them. CIOs had built so many different links to the enterprise systems to get them working with other systems in the company that an upgrade was akin to starting over. Many of the old links had to be torn apart and rewritten to fit with the new version. And many of those rewrites were completely pointless. The new suite might have one new piece and nine others that had changed little since the last version. But it was all so integrated together that every custom link had to be redone, even to the pieces that didn’t change. Talk about IT not mattering.

Gradually, enterprise software vendors came to realize that to serve customers better, they needed to break up their suites into application components and create complex ways to link to them over the Internet so that customers would not have to rewrite connections to pieces of the suite like financials, which didn’t change much.

But when they broke up the suites, they broke up the value proposition that had been so enticing in the first place–“free” upgrades. Freed of the suite model, enterprise software vendors started charging fresh license fees for the new components they developed. And CIOs stuck with the suite began wondering where all their maintenance fees had gone. They couldn’t afford to upgrade to the newer, componentized version of the vendors’ software models and if they could, they’d pay a new license fee for their trouble.

The final death knell for the original enterprise software architecture model came earlier this year when the major enterprise software vendors all announced that they were offering packages of integration middleware–tacitly acknowledging the reality that had been clear since middleware was first invented decades ago: Integration happens best outside of specific software applications, not inside them. The enterprise software vendors have been conspicuously absent from the Web services standards movement, looking ever more like the Dark Princes of Lock-In while the originators of the lock-in concept, IBM and Microsoft, looked like white knights for doing the lion’s share of work to create free (so far, anyway) standards for integration in Web services. And it’s great stuff. How ironic that those companies that were going to save your CEO from integration in 1999 have been the laggards in developing truly useful enterprise integration.

If this all sounds like ancient history, don’t kid yourself. I talk to CIOs every day who are struggling with enterprise software suites they installed long before Y2K was a dollar sign in consultants’ eyes. They don’t want to change much, or any of it. It is commodity stuff and there is very little difference between one vendor’s enterprise software and another’s, except perhaps in scope. So why are CIOs paying maintenance and support fees that are being used to pay for R&D on products that they don’t need or can’t afford to integrate with what they have? They don’t want to pay the same money for something that is legacy, doesn’t require support or upgrades as they did when the stuff was new. Is that so unreasonable?

Look, I don’t want anyone to get the impression that enterprise software itself is bad. Most of the vendors have had some big bumps in the road, but most of it works well. CIOs I talk to are especially happy with it when it gave them new business capabilities that they didn’t have before. But I talked with many CIOs in 1999 and many since then who talk about replacing systems that had more and better functionality than the enterprise software they were installing. We’re going to be more integrated, more efficient when this is done, they said. For the few companies that could afford to install enterprise software in the manner envisioned in the vendors’ R&D labs, they may have gotten there. Most are still maintaining the custom code they had to write for outraged business users.

So why are companies saying they want fewer and fewer software vendors, according to the IDC analyst quoted in the recent New York Times story? If it’s true, it makes no sense. They must still be in the throes of their integration hangover from the Y2K party. They still believe that enterprise software vendors are going to solve their integration problems somehow. They think it’s better to have fewer software contracts to manage than it is to have the best technology for the business problems they face. Companies should buy the best software for the job, not because it’s software from the vendor they already use. That’s just plain lazy and bad business.

Companies whose products are expressed in IT (like telecom and financial services) have already left this software model behind. They have invested in building an independent integration layer in their companies, whether it is homegrown, from a proprietary vendor, Web services standards, or some combination of the above, that gives them independence from vendor consolidation. They can afford to buy software from a no-name, risky vendor because they can isolate the stuff in their architecture and make communication to it and from it cheap and flexible. If the vendor goes away, they can make a rational decision about whether to plug something new in or support it themselves. They’re not biting their nails waiting to see which of their vendors merged this week and whose support lines they’ll have to call to keep their businesses running.

Companies that have invested in enterprise software need to take some of that money and invest it in integration that makes them independent of the machinations of their software vendors. Until they do, they will be at the mercy of those vendors, not the other way around.