Another view: Don't expect SOA to fix ERP quagmire

ERP, or enterprise software systems, have gained little for companies, and SOA is too slow to make a dent in the complexity these systems have wrought.

Abandon all hope, all ye who run ERP or enterprise software....

That's the dour message from Cynthia Rettig, writing in MIT Sloan Management Review. Rettig says that ERP, or enterprise software systems, have ultimately provided little gain for companies, because they have become too complex and overbearing. SOA, seen as a workaround to this complexity, is too slow to make a dent, she added.

Things weren't always this glum, Rettig said. The original vision for ERP and enterprise software was that it was part of the evolution to the online, always-on, intelligent digital enterprise. Rettig says few companies have realized this vision to date:

"The triumphant vision many buy into is that enterprise software in large organizations is fully integrated and intelligently controls infinitely complex business processes while remaining flexible enough to adapt to changing business needs.... Whole systems march in lock step, providing synchronized, fully coordinated supply chains, production lines and services, just like a world class orchestra. From online Web orders through fulfillment, delivery, billing and customer service — the entire enterprise, organized end to end — that has been the promise. The age of smart machines would seem to be upon us."

What went wrong? Rettig points out that buying into ERP and enterprise software kept companies up with the Jonses, but in the end, processes were standardized to the point where any competitive advantage was zeroed out.

The alternative to the plain-vanilla standardization offered by ERP -- customization -- is worse, however. "...as many companies learned the hard way, customizing the already complex ERP software created yet more complexity and even larger risks. Without intimate knowledge of how the integrated pieces of these modular software packages actually worked, customizing could lead to in-house bugs and glitches that were hard to foresee and expensive to fix. Perhaps even worse, customization made changing the software later — or upgrading to a newer version — far more difficult, and in some cases prohibitively expensive."

In the process, Rettig observes, IT departments have grown enormously, from consuming about three percent of corporate budgets in the 1970s to 22% by 1999. In addition, she also notes that "IT departments spend 70% to 80% of their budgets just trying to keep existing systems running."

There's really nothing new here in this analysis. We could all write volumes (and have, actually) on the issues around big ERP and enterprise systems -- their cost, complexity, and lack of flexibility. But Rettig goes a step further and says there's no hope for the future.

In fact, while Rettig doesn't offer any remedies for her gloomy prognosis, she does quash one that gets discussed quite a bit on this blogsite -- SOA.

We've often discussed the possibilities of SOA serving as a workaround to ERP quagmires at this blogsite (here and here, for example) -- for both customers and ERP vendors themselves. Fellow ZDNet blogger Michael Krigsman also recently made the point that SAP and ERP are alive and well and thriving, thank you.)

However, Rettig doesn't offer any encouraging words about SOA as an ERP workaround. SOA may take years to come to full fruition, not in enough time to help beleaguered companies, she says. "The timeline itself for this kind of transformation may just be too long to be realistically sustainable and successful."

SOA may simply be too slow to keep up the dynamic business environments of today, Rettig observes. This fast-paced environment "makes it questionable whether companies can actually maintain a focused strategy long enough to align their core business processes with IT."

Not too mention technical challenges. Rettig says that SOA increases complexity, as it becomes "additional layers of code superimposed on the existing layers." In addition, Rettig doesn't buy the Lego-block concept that underpins much of the thinking about SOA. "The Lego dream has been a persistent favorite among a generation or more of programmers who grew up with those construction toys," she sniffs, noting that Lego-style reusable software may work on a small scale, but may break down as a system grows more complex.

But there are inherent issues with the Lego-block approach:

"Unfortunately... software does not work as Legos do. For one thing, a unit of software code is not similar to other software code in terms of scale or functionality, as Legos are. On the contrary, code is widely various and heterogeneous. It contains different numbers and types of connections to other code, more like fractals ...than Legos, with their uniform connections."

Rettig does not offer an alternative to suffering with the complex, legacy systems that now populate today's enterprises.

Let's put it this way: aside from SOA, what is the alternative? No one is willing, or can afford to, to stay with the rigid, stovepiped systems in their current form. One solution is just throw the entire mess out, and buy a huge, well-integrated, modular application. (That's what happened with many ERP migrations, as a matter of fact.) But no one has the time or budgets. The only workable approach, then, is gradual integration between systems, and gradual, greater agility.

If not through SOA, then how? SOA, pure and simple, is the first step to software industrialization -- creating massive, adaptable systems in an automated and modular fashion through greater economies of scale. ERP was a step in this direction, since it modularized, and brought many vital pieces of the business together into a single standardized system. SOA takes it to the next level, beyond the domain offered by a single vendor. That's the core value proposition of SOA.