A Final Thought
This investigation of complexity has so far concluded:
- Complexity is necessary to solve difficult problems, particularly in the area of robust design.
- Complexity beyond a certain level actually causes brittleness—robust yet fragile.
- Complexity is difficult (or perhaps impossible) to measure in any meaningful way at the systemic level.
- There are a number of classes of problems where it is impossible to resolve for more than two of three goals (such as fast, cheap, high quality).
Given this set of points, it might seem like this is the end of the road. Network engineers are reliant on something that cannot be effectively measured—and measurement is always the first step in controlling and managing a problem set. There will never, in the end, be a single number or formula that can describe network complexity. Should we simply put on our pirate hats and proclaim, “Abandon hope all ye who enter here”? Or is there some way out of this corner?
There is, in fact, a reasonable way to approach complexity in the real world. Rather than trying to find an absolute “measure of complexity,” or find some algorithm that will “solve” complexity, it’s possible to construct a heuristic, or a method of looking at the problem set that will enable a path to a solution. The heuristic, in this case, is a two-part process.
First, expose the complexity tradeoffs inherent in network design. Exposing these tradeoffs will help engineers make intelligent choices about what is being gained, and what is being lost, when choosing any particular solution to a particular problem set. Every problem cannot be solved equally well; any solution applied at one point will increase complexity somewhere else.
To put it in other terms, network engineers need to learn to be intentional about complexity.
The next chapter will begin looking at three specific realms of complexity—operational, design, and protocol. In each of these cases, several places where designers must make tradeoffs to illustrate the process of bringing complexity out into the open will be considered. The closer engineers get to making intentional decisions about complexity when designing and managing networks, the more likely meeting the real-world demands placed on networks will be possible.