The Half-Way House

When I was a kid, I spent some of my summertime vacations at the rural home of a friend of my parents. The home had a history; it had been the "stopover" spot for stage coaches, at the top of a long, steep hill that would wear out the horses. People would stop there, rest and water the horses, and eat a meal before going down the other side of the hill. When I visited there, it was just a family home.

The home had never been put on the electric grid, and so the power to the house was supplied by a generator. I remember when evening fell, and we switched on the light over the dining table, hearing the generator kicking on behind the barn. We had to use the power sparingly, because the generator was old, and also would require a gasoline refill once it had run a long time.

The owner had thought of putting in a windmill to drive the generator, but he was not sure it was worth it. Would the need for electricity, which was minimal at first, grow enough to warrant the up-front cost and effort of building an entire windmill? If he didn't put in the windmill, however, would he find that his needs for electricity had outgrown the capacity of the generator?

You and I typically have no such decision to make. Our homes are hooked up to an electric grid, and if we need a little electricity then that's all we pay for. If the need grows, the grid will supply more, and the only difference for us is the size of the bill. We never have to endure a capital expenditure on the off chance that we may need more power, or to suffer because we did not invest in something we ended up needing. We don't have to predict.

Such is not the case, traditionally, in building a web-based business. When you have an idea you think may be a hit, like the next Twitter, how much capacity should you invest in? Do you buy one server, or a hundred? Do you invest in a DSL line, or buy direct access to the backbone? How much disk space will you need for your customer load?

My recent thinking on design emergence (which led me to write Emergent Design) has focused on the critical aspects of eliminating the waste of over-design while reducing the risks of insufficient design.  This is also part and parcel of the thinking on Lean that Al and others at Net Objectives have been investigating and promoting (elimination of waste, deferring commitment, optimizing the whole, and so on). 

But I must admit I've missed this aspect; not only should your design emerge, but so should your infrastructure and in fact your business model.  As my thinking matures here, I suspect the principles of an "Emergent Business" will be either the same or remarkably compatible with those that drive design.

For instance, the concept of "Refactoring to the Open-Closed" is an essential point of view when doing a just-in-time design.  What if you could "refactor" your server load, bandwidth, load-balancing, and so forth, when you have a literal proof of your business case (in the form of business).

Or, consider the notion of "Encapsulating Construction". One of the main reasons we focus on this in Emergent Design is to separate the users of a thing from the builders of that thing, in an effort to limit the concrete coupling in a design as much as possible. This is just as critical in infrastructure, however; when you set up a web-based business in the traditional way, you invest in discreet hardware, technology, provisioning, and so forth. What if you could separate the use of the infrastructure from the actual purchase/install/deploy of that same infrastructure?

Stay tuned for part 2…