Confession time: If someone puts a nice chocolate in my reach, I find it very hard to resist. In fact, there are few days where I don’t get my dose of dark chocolate. Chocolate is one of the pleasures in life. Of course we all know that eating too much chocolate will get you into big trouble: With your blood sugar levels, your shirt-size, your partner, and with your kids (albeit for different reasons).
Complexity is really the same thing! Let’s be honest: Can we ever resist the latest features and functionalities on our networks? And with each new feature, we ask for even more visibility, control, and sub-features? But just like with chocolate, we all know that too much isn’t good for us.
Yes, we all love complexity!
Hang on – that’s not what we hear in the press, is it? “IT Complexity considered most important inhibitor to innovation and effectiveness” (1) “What causes enterprise data breaches? The terrible complexity and fragility of our IT systems” (2) You can find many quotes in this direction. So – we hate complexity?
The truth is: it’s just like with chocolate – small improvements can add lots of value, but eat too much and you become sluggish and might even get seriously sick.
The funny thing is, there is actually no definition of the term “network complexity”. Researchers have dug deep into certain areas, such as software complexity, graph complexity, routing complexity, and many others. However, networks have a bit of all of that, and there is no global view on network complexity. The Internet Research Task Force tried to get to the bottom of the topic, created the “Network Complexity Research Group”(3) in 2011, but concluded in 2014 without tangible results. Researchers and industry specialists collaborated at http://networkcomplexity.org, with lots of materials posted and discussed, but again no clear results.
What we do see is that too much complexity tends to slow us down. It becomes hard to make changes to the network, because we don’t really know what will happen. Introducing new systems requires serious up front testing, because there are just too many interactions on the network, and we can’t really judge the impact of change.
But complexity can also deliver value that we want. If you want a branch office that is robust against failures, you have to do a redundant set-up (middle of the graph). But that’s more complex than the single device/line solution (on the left of the graph), isn’t it? You need some failover protocols and mechanisms that you don’t need on the simple layout? Yes, you *do* want a certain level of complexity, because it provides value, in this case robustness against outages. Other values can be: Security, agility, programmability, and so on (there are lots!). There is no right or wrong here: In my home network, the left model is perfectly ok, in a branch office of a bank it might not be. All depends on the use case and its requirements.
Obviously, there are limits: Adding a third row to this layout (right) intuitively will not increase availability, but probably cause more failures due to more complex protocol interactions that are not widely deployed.
When eating chocolates, your waist line tends to grow over time. The same is true for network and IT complexity: Most networks start out reasonably simple, but then new requirements need to be supported, you move to a new device and OS types in parts of the network, ever growing security concerns add layer by layer of protections, and so on. And: Nobody ever removes components that aren’t used any longer. When have *you* last removed some feature from a network?
The Cynefin framework(4) (left) illustrates this process, and helps understanding the progression of complexity over time: Most networks start out as “obvious”, simple and consistent architecture, uniform devices, OSs, and initially simple requirements. As we add new components, make changes, allow exceptions, the network becomes more complicated. But “complicated” still means that an expert can, albeit with some effort, model the effect of a proposed change. Complex systems show an emergent behaviour: Even with massive analysis, the outcome of a change is not fully predictable. Finally, a system becomes chaotic if there is no relationship between a change and the result any more – This is unpredictability. Most networks today operate in the “complex” area, which is why analysis on paper is usually not enough. The only way to really know whether it works or not is to test it. No paper analysis can safely predict the behaviour of a complex system.
In summary:
• Complexity isn’t all bad. It’s important to balance the right level of complexity with the features you require.
• The level of complexity typically changes over the lifetime of a network.
• Complexity and Chocolates are best enjoyed in moderation.
In the next blog we’ll suggest some high level measures to control complexity. And, hopefully not surprisingly, there are actually a lot of innovations happening in Cisco which reduce complexity. Stay tuned!
This blog was prepared as part of a team project on complexity, actively supported by: Bruno Klauser, Patrick Charretour, Mehrdad Ghane, Dave Berry and Rebecca Holm Breinholdt.
(1) A.T.Kearney Study 2009
(2) http://www.zdnet.com/article/what-causes-enterprise-data-breaches-the-terrible-complexity-and-fragility-of-our-it-systems/
(3) https://irtf.org/ncrg/
(4) https://en.wikipedia.org/wiki/Cynefin
Photo credit: Dominic Lockyer, shared under the creative commons licence 2.0.
In Scott Shenker’s talk about SDN, he recounts a 1985 visit of Don Norman to Xerox PARC.
At start of his talk on UI design he asks:
“Who in the audience drives a stick shift?”
After most of the audience raises their hands, he looks sternly out over the crowd and says:
“None of you should ever design a user interface.”
Moral: Engineers will look to optimize rather than take a penalty for ease of use. Engineers need to learn to resist that instinct.
Its Network engineer’s inherent behavior to *fix* a design or solution by introducing more features & functionality.A network intended to optimally function over the years turns into a monster by additional complex feature additions.
There are too many interactions and dependencies between interactive components.
Can Engineers be guided with statistical guidelines to understand trade-off and penalties on specific areas to help design and deploy simpler networks ?
@Dannny: Every solution gets more messy / complex over time, without exception. This is because the incremental cost to deploy a hack to solve a current issue is significantly cheaper than solving the problem in a clean way. This is called “Technical Debt”. And because we accrue technical debt on a daily basis, and rarely if ever “pay back” (ie clean up), we need a complete start from scratch every x years.