Root Cause Analysis

Designers should be trained to identify the real issues for customers in computer network designs. Developing an excellent solution for the wrong problem can cause more damage than doing nothing at all. Finding the right issue is vital for assisting customers.

Imagine a customer tells you that they need a CGN (Carrier Grade NAT) solution and wants you to design their network.

Instead of jumping immediately to that solution, you should take time to determine the real issue.

After analysing the problem, you find the customer’s real issue was an IP address exhaustion. Then you come up with a range of solutions that include IPv6, CGN, asking for a new block from registry, existing address redesign.

You should keep in mind the advantages and disadvantages for each solution, and also include possible future benefits and potential issues.

Root cause analysis is another crucial part for identifying actual causes in network design.

The Toyota Production System in Japan has used a helpful procedure for this analysis which was named the ‘Five Whys’ and found it boosted their quality in assisting customers.

The procedure involves continuous questioning, even after a sole reason has been found.


The example above demonstrates using this technique and identifies that the real problem is training.

Although critics point out that results may vary when different people use this questioning technique, it has still proved to be powerful. It can be beneficial for troubleshooting, network design analysis and root cause analysis for the problems.

These concepts can help designers reduce time and stress by avoiding the use of the wrong solution for customers.

5 Replies to “Root Cause Analysis”

  1. learning from this article “Analysis is the first, most critical and the hardest part of Computer network design”

  2. Focus on the requirements, not the solution. Focus on what the system must do and not on how it will do it. “Carrier Grade NAT” is a solution, not a requirement. Be brutal in defining the requirements. You MUST write the requirements down and prioritize them. This is half the problem in defining a solution. With the requirements in hand, a solution to meet the requirements becomes much more visible and accurate. “Necessity is the mother of invention.”

    1. Hey Kevin. Nice one. But one point is important. You need both requirements and solutions.

      You keep try asking and asking, doing your analysis again and again to get the requirements and problematic place very well then you should come up with many solutions, among those solutions , most optimal one which satisfy the requirements, which solves the issues should be chosen.

      So we can’t say don’t focus on the solution, but we can say don’t focus on the solutions before understand all the requirements and the issues.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.