IT to flow like electricity?

TalkBack 21 of 21:

« Previous

• Thread View
• Flat View

Be Careful What You Wish For

This idea that the evolution of electric utilities is a predictor of how IT will evolve into a services business ought to scare the heck out of Sun?s shareholders, if the analogy were valid. If "public" data centers gradually displaced private data centers to any significant degree, state governments would move in to regulate the service and its providers just as with electricity. They'd do it "for the common good" and certainly to the detriment of Sun's shareholders.

Fortunately, that's extremely unlikely because the basic analogy between computer processing and the distribution of electricity isn't valid. The basic driver of the evolution of the electric utility industry has been the "regulatory pact" between regulators and electric utilities. It was originally developed to force ubiquity because market forces weren't enough to cause a power company to build distribution capability 20 miles further out to serve the next new customer. A private company wouldn't build it because it would be a thousand year payback. So the regulatory pact allowed the utility to charge their average costs to serve plus a negotiated profit. In return for the guaranteed profit and the service area monopoly, the utility was required to serve every customer, no matter how unprofitable. Not a bad solution at the time, because that was the only way to get that distribution line built 20 miles outside of town. And without that, no electricity.

Utility computing, however, has a fundamentally different cost model. Distributing electricity has a fairly high incremental cost per customer, but utility computing has a very low cost to serve the next customer. That low incremental cost is the reason investors loved the ASP model in 1998 and it's one reason you talk up the idea today.

But there is no need to force ubiquity with computing because it already exists and is readily available. The evolution of the electric utility industry would have been drastically different had distributed generation been readily available in 1910s. There would have been no need for the regulatory pact that drove the development of the industry.

Imagine a monolithic electric utility under those circumstances trying to displace existing distributed generation. It would have to pitch economies of scale that flowed to the customer. It would have to subsidize the switching costs and sign long-term contracts with serious availability penalties with lots of small customers. It would NOT be easy money. Wow, that does kind of sound like what you?re up against pitching utility computing today!

I?ll comment on your Salesforce.com example only because I ran a BSP in the CRM space for three years. SF.com is successful in part because its sales force automation functionality, the very essence of which is gathering data from distributed users outside the enterprise in close to real time, is well suited to a distributed delivery model. ERP, on the other hand, with its more complex processing and its user community inside the enterprise, would be an example of functionality that is not inherently suited to a distributed delivery model. SAP has offered ERP as an ASP to down-market prospects for years in its Philadelphia offices and it hasn?t taken off. So the distributed characteristic of the sales force automation business model itself is why the SF.com approach works, but that does not mean processing capacity in general is well suited to the distributed delivery model.

Actually an analogy with the electric utility industry in the 1920?s and IT in the 1970?s is apt, because computer processing itself had very high fixed costs but phone lines were ubiquitous in the 70?s. As companies found they needed computer processing and it was very expensive and risky to buy, renting became an obvious choice. So conditions were excellent for utility computing then, only we called it time-sharing.

Remember GEIS? That standalone piece of GE became the market leader in time-sharing and was hugely profitable during the 70?s and the mid-eighties because of it. But the advent of distributed computer processing, the PC, made time-sharing obsolete and it all but vanished within five years. As distributed computer processing ? . . . moved from customized to standardized to utilized, two things happened: Its ubiquity rose, and its cost plummeted.?

GEIS survived only with a mid-eighties transformation to EDI, making its living (to torture the electricity analogy) from transmission and distribution of IT value rather than the generation of it. And ten years later Sun?s own Scott McNeely was able from his position on GE?s board to watch GEIS struggle to get paid for adding value to IT as bandwidth (transmission and distribution) costs made even EDI look expensive.

So the fundamental problem with the utility computing paradigm is that it?s too late-- distributed computer processing is already ubiquitous and getting more so. The value proposition of doing computer processing centrally and delivering it remotely as though it were electricity, no matter how cheaply today?s broadband could do so, is just not there.

Posted by: powerindustry   Posted on: 04/22/05 You are currently: a Guest | Members login | Terms of Use

Alert moderator to an offensive message

Subscribe to this discussion via Email or RSS

SponsoredWhite Papers, Webcasts, and Downloads

• Three Steps You Need to Know to Stop Data Loss Varonis Sensitive data exposed to misuse or loss... it is the stuff of nightmares ... Download Now
• Breaking DB2 Platform Barriers Quest Software Are you supporting DB2 on multiple platforms? In this Quest white paper ... Download Now
• Five Steps to Determine When to Virtualize YourServers VMware Server virtualization isn't just for big companies. Entry-level ... Download Now