Nick Carr Was Right!

The following is an excerpt from a note I wrote a while back that was intended to educate investors to the reasons behind SaaS and Open Source.  It was never published and I just stumbled over it recently.  I thought this passage was interesting for the historical parallels.  While it is a strong endorsement of the SaaS model, I am not saying that SaaS will wholly replace traditional sofware delivery - but the trend toward sharing infrastructure that adds zero competitive advantage is economically wise and technically feasible.  Enjoy!

History Repeats Itself

At the beginning of the Civil War, there were 20 different railroad track gauges in the United States ranging from 3 to 6 feet.  The continent had developed several different lines in different geographies as the nation began to expand westward. The wisdom of the time held that railways were only practical where canals were not, and there were no plans made for the standardization of railway gauges. This proprietary infrastructure did not add any value to the freight company that used it, but it was essential for the service.  When freight items had to move from one railway to the next, they had to be manually unloaded from one to the other, due to the incompatible railway gauges.  The inefficiencies of this system gained a desperate quality to them when the Civil War broke out.  Suddenly, the penalty for delivering freight went up dramatically - battles were won and lost, partly due to the infrastructure behind moving armies and supplies.  The battles get the headlines, but the logistics significantly determine who fights who, with what equipment, and where.

With this urgency came the plan to standardize on a single gauge- 4 feet 8.5 inches.  During the war, over 4,000 miles of track was laid to this standard which ended the economic reason for any trains to be constructed for any other gauge.  The common infrastructure was shared by many competing railway firms.  Sound familiar?

Another historical example is the advent of the "Union Station."  First introduced in Indianapolis, Indiana in 1853, this was a common station that consolidated railroad passenger traffic.  By doing so, passengers could easily move from one system to another.  The alternative was having each passenger rail company build a station that would connect only with their own other passenger lines.  The real estate alone made this notion an economic non-starter.  Again, sharing the common infrastructure was the key enabler.  The parallels are obvious: the inflexibility, cost, and inefficiency of proprietary standards versus the ease of integration using agreed-upon standards and shared infrastructure.

Another way that history is repeating itself is similar to the path electricity took.  Thomas Edison's direct current (DC) standard was the format for transmitting electricity in the United   States.  This standard was sufficient for the loads at the time, but lacked the capability to be transmitted distances of over one mile without severe voltage dropoff.  A superior solution for transmitting electricity over distance came from Nikola Tesla, who called it alternating current (AC).  As Edison was loath to give up the royalties accruing to his patented DC system, he began an aggressive campaign to discredit Tesla's AC standard.  Edison went so far as to electrocute to death stray cats and dogs- even an elephant once- to demonstrate the hazards of the AC standard.  Despite this gruesome tactic, AC became the adopted standard for long-distance distribution of electricity.

This example illustrates a time when the standard for energy distribution made headlines, despite the fact that today we could not care less about electricity.  People only care about the services performed using electricity, be they appliances, devices, or whatever.  Electricity became a commodity that is simply thrown on or off as needed.

IT is the next utility

IT started out as something that every company built to support the business.  Today, this model is under considerable strain given that 85% of the IT budget goes to maintenance of the existing system.  Labor is wasted maintaining the current system, not creating innovative applications at the touchpoints with customers, employees, and/or partners.  The center of gravity in the IT shop is maintaining the status quo.  In other words, IT shops are spending the vast majority of time optimizing processes that do nothing to differentiate their business from the competition.

Hardware utilization hovers around 30% as IT purchases need to be prepared for the contingency of seasonal (or random) spikes in traffic.  The rest of the year, the hardware remains idle while costing the company monthly maintenance.  This over-provisioning is wasteful and inefficient.

With significant overlap of basic IT functionality shared by nearly all organizations, it is becoming more sensible to evaluate a shared infrastructure system.  On Demand software is exactly that model- a shared back-end system that allows companies to dial up their services as-needed.  This is the only way to achieve economies of scale in IT.

The notion of a Service Oriented Architecture (SOA) is not new.  Possibly the first book on it was by David Parnas, entitled "On the Criterion for Decomposing Systems into Modules," published in 1972.  The concept of SOA is to develop a technology backbone that allows services to be utilized in a "plug and play" fashion.  The entire system is designed for flexibility and lets all software assets get repurposed into new applications quickly.  A well designed SOA enables a firm to build out automated business processes rapidly, effectively reducing the time and cost of new initiatives.  The reason SOA is happening now is because of the popularity of the underpinning technologies.

The popularity of such standards as XML, SOAP, WSDL, and BPEL (to name but a few) is significantly impacted by the fact that these standards are not owned by any one vendor.  Code designed to these standards flourished and created a virtuous cycle where every addition benefited the entire group writing to these standards.  Thirty four years after David Parmas' book, SOA is hitting the mainstream because of the maturity of these standards.

Standards based communication and interoperability are crucial to SOA, but without an abundance of bandwidth to the home, SOA is restricted to individual firms, and utility computing is not feasible.  But with the surge in bandwidth comes the ability to render services to the market through a browser. Suddenly the software doesn't matter so much as the service does.

The commodification of much of the IT computing stack makes it ripe for outsourcing.  Without effective standards to enable simpler interoperability and communication, the utility model is not practical. But combining mature open standards with the availability of broadband makes it not only practical but compelling. 

The World Has Changed

The ubiquity of these standards and broadband has also greatly loosened another constraint to IT shops, namely the scarcity of qualified development resources.  In a post-internet world, it is possible to tap into software talent in India for development support. The significance of this reality has not been fully realized in the market.  If firms can reduce their operating expense by accepting a utility model and receiving their software as services (a la Salesfoce.com), more money is available to invest in applications and automating business processes.  In short, the doors to innovation would swing wide open but for the lack of developer talent in the US Market.  Bringing online qualified and inexpensive offshore developer talent will creates an opportunity for firms to create more value-added applications which should benefit their partners, customers, and employees.

This excess supply of applications will necessarily result in a slow decrease in pricing, assuming that the applications are written to standards.  This is a safe assumption since writing a proprietary application will be at a disadvantage in the market due to the headaches associated with integrating proprietary applications with other applications.

Comments

[dennis]

IT infrastructure (HW, SW, Network, etc.) I agree is going down the path of a utility / services model and economies of scale will drive differentiation but Packaged Apps, Unique Business Processes and Custom Logic will always be the family jewels that are unique to a business and capture the majority of IT $ spend.

Standards and Interoperability help optimize IT enablementt but everything will not be a model T as businesses will need to differentiate and compete as they get from point A to point B...

SFDC and their Salesforce Productivity app online. Interesting model and yes, more and more apps start to combine software and services over time but I'd bet on a tool that customer-facing people will love to use because it's natural by-product of how they work today. User adoption of these apps by users to retain that IQ when the sales guy leaves is priceless, along with all the other benefits that happens when users adopt and actually use and get value from these solutions.

SEBL UI, SFDC UI, etc. being a glorified data input mechanism for an excel spreadsheet to review your pipeline with your mgr comes to mind. Sales people start their day and end their day in outlook... Extending outlook and office is the model to get people within a company to use these custom applications