Innovation Trumps Consistency

During my last days at Red Hat, I recall making a sales call on a very large customer that had completely transformed their customer service costs and application performance by switching from proprietary Unix to Linux on X86. We were laying out the technology roadmap for the next Linux release, which offered yet again more improvements in performance vs. Unix, when a senior IT manager interrupted the presentation:

IT Manager - (loudly) - I really wish we could just go back to the good ol' days of Unix where nothing ever changed. How am I supposed to maintain any consistency when all of these performance innovations keep showing up in the code, and the application developers just can't resist adopting them to rachet up performance.

Red Hat SE - (calmly) - But isn't that the point? When a new innovation makes the customer experience better or the cost of service lower, adopting that innovation into the application just makes sense.

IT Manager - It's just more work for me. I care about performance and cost, but no one measures the cost of our efforts to support innovation. A slow moving, standard OS lowers the costs for the administrators who have to make the applications work with the rest of the infrastructure.

Red Hat SE - Well, I think innovation is always going to trump consistency. I wish there was more we could do to make it easier for you to stabilize multiple streams of innovation in your datacenter.

This interaction came to mind when I read an interview with the CTO of Amazon, Werner Vogels, about how Amazon enables innovation by giving the developers complete responsibility for delivering a working application service. The developer can adopt any innovation that makes their service more effective, but they have to manage the availability of that service in the datacenter. At some level, I am certain Amazon has guidelines, such as server preferences, OS preferences, management utility preferences, etc. My guess, however, is that these are pushed to the lowest possible level to enable flexibility in the upper portions of the stack in order to maximize application performance.

I am sympathetic to the workload of the datacenter staff, and I have high hopes that virtualization is going to separate forever the management of the box from the delivery of the application. Maintaining consistency of the OS across applications at the expense of application performance is simply unacceptable in a hyper-competitive world.

I think it was Ralph Waldo Emerson that said "A foolish consistency is the hobgobblin of little minds." I think Ralph was a closet application developer before application development was cool.

Slaying the Microsoft Octopus

I laughed and I cried when I read Robert Spivack's response to the Microsoft blog entry that announced its intention to enter the hosted CRM space 9 - 12 months from now (scroll to the bottom of the post to see Robert's comments). Here is the quote that made me laugh:

"The intrincate interdependencies between IIS, SQL Server, Reporting Services, Active Directory, and Security (double-hop Kerberos) create an installation nightmare with octopus-like tentacles reaching into every nook and cranny of server infrastructure almost impossible to get running correctly."

I visualized an octopus with a Microsoft branded head wrapping itself around a server and then reaching up and down the rack to torment other servers that had the misfortune of being placed in close proximity to the one that the octopus was intent on destroying. Frightening visualizations that accurately reflect Microsoft application architecture often make me chuckle.

I cried because it seems that Robert's sentiments regarding the complexity of Microsoft CRM application software are becoming generally accepted as the "software condition." All of the software conferences that I have attended in the last 90 days have been dead, dead, dead. It seems that the general wisdom around software these days is that it is a crappy business unless you have an application that fits the SaaS mold, but not all applications lend themselves to an on-demand form factor.

I think software business can be great business, but software application companies absolutely have to abandon the old methods of licensing and distribution. After all, if Microsoft cannot get it right when attempting to deliver their various products on their platform because of the impossible interdependencies that arise when running multiple applications on a single, controlled instance of their operating system, what hope is there for an independent software vendor to get it right when dealing with the multiple OS (short for Octopus, I think) variations they invariably encounter across their customer base?

In a by-line article recently published in Enterprise Open Source Magazine, I elaborate extensively on the benefits of "losing your independence" for the independent software vendors (ISVs). Instead of fighting the octopus at each customer, embrace Linux and open source components to "wrap your application" and create a software appliance. Use virtualization to make the software appliance a virtual appliance in the case where a customer simply cannot bear to remove the octopus from an existing server. Your application will be safe from the octopus because of the protective layer of the virtual machine container.

The software business can be a great business if you have the right weapon to slay the octopus. SaaS is one weapon, but don't discount the software appliance as an approach that is cheaper than SaaS re-architecture, and may indeed be far superior for many types of applications. It is certainly more channel friendly as it allows your partners to add hardware and customer service value when delivering your new, simple to install, simple to maintain software appliance.

But what about that octopus carcass? Serve it up Polvo Frito, but don't overcook it as it can become tough when over-exposed to heat.

Software Lessons from High Fuel Prices

While we were watching the dollar meter spin on the gas pump that was re-fueling the boat after an offshore fishing trip this weekend, a couple of my fishing buddies commented on the devastation of the boat and SUV market brought about by high fuel prices. Buyers that would have jumped into the market for a Chevy Suburban, Ford Expedition, Grady-White, or Boston Whaler just one year ago are now on the sidelines, perhaps permanently, because it is simply too expensive to operate these vehicles and sea going vessels with gasoline prices in the $3/gallon range. The concept of price elasticity of demand applied to the total cost of operating a SUV or boat is obvious to these good ol' boys from South Carolina. Funny that the geniuses that are the executive class of the software industry often don't get it.

It is obvious that rising prices shrink markets. The corollary is that falling prices expand markets. Price is not just the cost to acquire a product; it also applies to the cost to operate that product. The lesson for the software industry is that lowering the cost of integration and maintenance for a product will expand the available market for that product. The on-demand SaaS companies and the appliance companies are currently reaping a windfall from this simple lesson in economics while most software application company executives stand on the sidelines, knees knocking over the prospect of changing their distribution, licensing, and revenue model. It's time to get over it. The invisible hand of Adam Smith is either going to shove these companies forward to embrace the on-demand SaaS or software appliance concept, or that same invisible hand is going to shove them over a cliff into competitive oblivion.

I do not believe anyone questions the turnaround prospects for GM and Ford in the face of $1/gallon gasoline. Funny that this same logic does not lead more folks to the obvious conclusion that the current malaise of the software industry could be cured by a large dose of simplicity.