The New Software - The Ten Commandments of New Software

As I mentioned when this little monograph began, Larry Ellison was way ahead of everybody on the whole idea of Software as a Service. Working in proximity to him was one of the great pleasures of my work career, and it's no surprise that the orbits of many of the SaaS pioneers (Salesforce.com, NetLedger, with ex-Oracle managers at all kinds of other tech companies) revolve around Larry. He is the soul of the New Software, and he "got it" before everybody else.

Starting with the iron and moving out to the spirit, here are the immutable laws -the ten commandments of The New Software:

1. You have to relentlessly remove all the costs of delivery. Hardware, installation, support, patches, and mostly PEOPLE - costs anywhere violates the Web model
2. Little/cheap/slow hardware is more economical than big/expensive/fast hardware. We started on relative big Sun servers, and worked our way down to clustered small machines because the economics were better.
3. Multitenancy is a must. Turn-of-the-millenium Oracle Apps weren't designed for multitenancy, and this put a floor under our costs. One environment per customer is expensive -- one environment per everybody is cheap.
4. Take costs out of the software stack. We got the database and the applications "for free" from Oracle, so our quest was to take costs out everywhere else. Linux, Apache, and a slew or open-source tools were/are essential to making the economics work.
5. Microsoft is not your friend. This would have been true even if we weren't at Oracle. Microsoft makes money selling license software, and MS costs violate Rule #1 above. I still believe that history will show that the only company that can be long-term successful on a Microsoft platform is ... Microsoft.
6. Parallelism in layers - minimize single points of failure. Modern web architectures make it easy to layer load balancers, web servers, apps servers and database servers to add capacity incrementally.
7. Strive to be good - you can't afford to be great. Modern web architectures make it pretty easy to reach 3 to 4 "nines" of availability (99.99% uptime). It was diminishing returns to go higher, and most of the systems we were replacing were internal monstrosities that ran at barely two-nines of availability.
8. Be prepared for the worst-case scenario - it will eventually find you. We had a big storm that knocked out power for our big CA datacenter in the first year of the program. We had auxiliary power and survived the external outage fine, but ran into trouble when the tech turned off auxiliary power before the transition to regular power was complete. We had a "worst nightmare" plan in place, and fate found a way for us to use it.
9. Systems fail predictably -- PEOPLE fail unpredictably. It's pretty easy to prepare good redundancy/failover plans for hardware - the modes of hardware (and to a lesser extent software) are known and understood. Only people can provide the random factor that turns a simple failure into a complete disaster. Therefore - ruthlessly eliminate human intervention from your delivery.
10. Support both your wins and your losses. Not all your wins will stay wins, so provide for giving the data back. This is something 37signals (the company behind "Campfire" and "Basecamp") has handled beautifully - if you ever want to leave you get an XML file with all your data back. Not that you want an XML file, but just being able to exit takes a lot of the buyer-risk out.