Great Management Books: The Innovator's Dilemma, and The Godfather

Posted on January 18, 2007 at 11:42 AM by John Repko

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. — Antoine de Saint-Exupery

I've always liked Clayton Christensen's book "The Innovator's Dilemma" as a metaphor to explain product innovation and succession. To vastly oversimplify the main idea, companies get so good at "hammering" that everything: screws, rivets, staples, welds, etc. is either treated as a "nail" or crushed in favor of "nails."

Software is an industry that produces natural monopolies, and so for software The Innovator's Dilemma applies, not just to individual companies, but to the entire industry.

This makes things really hard for software developers today. Microsoft, with Windows started out as a system for non-networked individual devices, and has tried to expand all the way up to clustered 'mainframe' solutions. Enterprise Java started out trying to boil the ocean, boiled it, only to find that ocean-boiling solutions aren't of much use when all you want is a cup of hot water for soup. In trying to solve the same universe of problems, both the Microsoft and Java camps have adopted the same set of ills. One size doesn't fit all.

In this case of two increasingly over-engineered systems, I prefer openness, not because of what you can add, but because of what you can take away. The key ratio for software managers to watch I call the "overhead ratio" which is (Time spent on the solution the customer will pay for) / (Total time spent). The ideal solution would have a quick installation, rapid configuration, and rapid user iterations to a state of solution-ness that is "just right." The ideal development effort will spend all its time on "value-add" components, and none on "configuration."

Both Microsoft and Java development have a pretty onerous overhead ratio - getting all the components right takes an increasingly long time. As I've previously noted, I like "virtual appliances", and the "Convention, not Configuration" mantra of Rails/Grails for just this reason.

But there's more to it that that, a notion that I'll posit as The Godfather's Law: "Technology components that reach a sufficient level of irritation are made to SIMPLY DISAPPEAR." Credit Mario Puzo with this: "As soon as the Corleone Family set up their usual business liaison with the local police force they were informed of all such complaints and all crimes by professional criminals. In less than a year Long Beach became the most crime-free town of its size in the United States. Professional stickup artists and strong-arms received one warning not to ply their trade in the town. They were allowed one offense. When they committed a second they simply disappeared."

Software licensing is a headache? BING - SaaS. MS Shop that doesn't run Linux? BANG - Virtual appliances. No (MS) or overcomplicated (EJB) ORM? - BOOM - Hibernate.

...and so on. As the best software people are "Lazy, Impatient, and Hubristic" (a description that also fit Sonny Corleone), no system of excessive overhead ratio will last long. One key to software success is to figure out when a paradigm is about to get "bumped off", and to move in on all the action when it happens.

There is a great opportunity for software development organizations who can surf the transition. The key is not in choosing the "next Java" or hot development environment, but in identifying all of the barriers to adoption and making them "simply disappear." Even if they might agree on nothing else, the two "C's" (Christensen and Corleone) would agree here.

The New Software - the ten commandments of New Software

Posted on December 19, 2006 at 10:39 AM by John Repko

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.


../themes/pikasoft/views../../themes/pikasoft/views../../themes/pikasoft.