Wednesday, July 07, 2004


Centralization of assets is a good defensive strategy when you want to keep an enemy from accessing certain resources. However, it's a bad strategy when you want to protect everyday resources like water, energy, information from destruction by the enemy. In the latter case, decentralizing those assets is the correct strategy.

I'm surprised that I have seen very few references to decentralization as a strategy since 9/11/2001. Not that I've searched for them specifically.

There are political reasons why this strategy might not be proposed by public officials. First, decentralization is expensive, at least at the moment. Building one big water plant and keeping it out of sight is much cheaper (and prettier) than building multiple smaller, redundant water supply modules.

Second, decentralization is complicated. Look at what happened in the large electrical grid failure in August 14th, 2003. Large, interconnected systems can display unexpected behavior. One can certainly make a case that a poorly designed decentralized system can fail more catastrophically than a well designed centralized system.

Over the next 20 years, we will be increasingly vulnerable to attacks from rogue groups and individuals. It's time to start thinking about ways to design complex, distributed systems that are much less vulnerable to attack.

These new "hardened" distributed systems might be designed based on observations of living organisms, or better yet, stable ecological systems. Perhaps a predator-prey model could be used as the basis for interacting energy generators?

I think that cost issues will dissipate as nanotechnology and robotics reduce manufacturing costs. In fact, it's quite plausible that there will be economic advantages to customized utilities. Each organizational unit, whether it be a family, a business, or a local government, could install a generator and power switch that matched their own special needs and made use of local resources (e.g., solar, wind,geothermal, biothermal or tidal power).

No comments: