Make it 12! Predictions and Snowfall

Might as well start with the snowfall first: another twelve inches on the ground today. We've fallen into a pattern - Thursday = storm starts, Friday = storm ends and some chunk of the day is spent digging out. Only a foot today, so maybe the weekly effect is damping out.

But on to my final prediction for 2007 - the Year of the Software Appliance.

I'm working on Pikaplanner, a lean manufacturing application that's designed to be run in a hosted environment. I have a great setup for it, with custom gems installed and a beta version of a hyper-fast Ruby virtual machine. It works great for me, but moving it to a hosting provider has proved problematic.

At this point in our malware-infested world, installing anything new anywhere is a risky proposition. Installing enterprise software can also be time-consuming: back in the day for a decent-size Oracle apps installation you would want to set aside a full week just to get the software installed.

All of these problems (custom environments, malware, and difficult installs) are remedied by the concept of a software appliance. Illustrative of the SA concept, Digium this week announced the release of it's Asterisk VOIP PBX as a software appliance. Asterisk is a terrific product—an open source (free as in beer) IP switching system. This monumental breakthrough in cheap communications systems has seen rapid growth, limited only by the difficulty of getting linux and telephony setup and configured by mere mortals.

Enter the software appliance - a bundle that includes the operating system, all the extra packages needed, and the VOIP switch software all pre-configured and delivered to be run virtual player environment. A tricky install becomes a simple, 30-minute exercise.

This is revolutionary—VMware (popular maker of virtualization products, recently acquired by EMC) products are generally already well-accepted in corporate IT departments, and encapsulated applications take a lot of the risk out of new software deloyments. SO ... if you want my Pikaplanner (complete with customized environment), all I need to do is package it up, lock, stock and barrel, and deliver it as a software appliance. The "tricky install" and "customer environment" problems are solved in one fell swoop.

A software appliance is completely contained within its virtual environment, so if you're worried about security, just throw the appliance away and start again!

That's really only the beginning. If you write linux-based applications and need to deliver them in a Windows-only environment, just package up an appliance and run it in a virtual space on that Windows machine.

I can barely scratch the surface here, but VMWare turbocharged the software-appliance idea with their VMWare Player, Xen is white-hot in pursuit of the same idea, and the force of it is so powerful that even Microsoft has to conform to it..

Billy on Open Source has some terrific writings on the software appliance idea. There's a lot more to discuss here, so for now I'll leave my final prediction that "2007 is the year of the software appliance."

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.

"Life must be understood backward. But...it must be lived forward." Kierkegaard

Credit Bill Gates and Microsoft with being the first to realize that there was a mass market for software "on every desk and in every home." Software Economics 1.0 said 1) software had high fixed costs of development, 2) software had essentially zero marginal costs of delivery, and thus 3) the first to mass scale would rule all, and throw off incredible free cash flow in doing so.

Software 1.0 was sold by license, delivered on media, where new license sales are good, ongoing support revenue is ok (a necessary evil), and addition services (given that they deliver lower margins than license sales) are bad.

This model drove Microsoft (and to a lesser extent Oracle, SAP and other giants, who were more willing to flirt with independent P/L services businesses, for themselves or their partners). Microsoft still operates essentially this way (waiting for that Vista upgrade license revenue stream) today.

Still, software had no sooner left the garage than two giant holes began to appear in the model. Firstly, upgrading software is painful, and the incentives for the buyer to take and install software shrink as the software grows to meet the business need. Given that Windows XP is pretty good, will businesses really want to absorb the deployment/support costs to adopt Vista?

The second problem with the Software 1.0 model is that fixed costs become so dominant that only the leading players can stay in the game. Prior to all the acquisitions (PeopleSoft/JD Edwards, Siebel, etc.), Oracle needed to maintain a staff of 5,000+ application programmers, not to chase down SAP, but merely to stay credible the applications software business.

Leave it to the Children of the Corn to find a new way...

Welcome to the Pikasoft web log—a friendly resting place for commentary on lean manufacturing and software. My name is John Repko, and I'm one of the primary administrators of the blog. My main area of interest is software, and I'll be posting frequent commentary on this site.

Drop on by often for the latest in lean manufacturing and "insanely great" software.