Asking ” The 5 Why’s” is an important part of the job of IT architect’s and should be an important part of our personal decision making process. It is exciting to see that many content creators are pushing to use this technique. 

What is often overlooked is that this is only the first step of a technique called the “5 Why’s”, developed by Sakichi Toyoda, a Japanese inventor and founder of Toyota Motor Corporation.

Personally, I use this technique on an almost daily basis in two areas. The first is when interacting with others to define or review a solution. Very often the decision for the solution has been made before the stakeholders have even understood the need. It’s also very useful to use the 5 Why’s technique when doing root cause analysis.

How does the 5 Why’s technique work?

Identify the problem

Start by identifying the problem you’re trying to solve. This can be anything from a technical problem to a process problem.

Ask “why” five times

Once you’ve identified the problem, start asking “why” several times until you get to the root cause. The idea is to keep asking “why” until you can’t ask it any more.

Analyse the answers

Once you have the answers, analyse them to identify the root cause of the problem. This will help you design a solution that addresses the underlying problem, rather than just treating the symptoms.

Here are three examples of how the 5 Why’s can be used in an IT context.

Example – The website is slow

1. Why is the website slow? Because it takes a long time to load.
2. Why does it take a long time to load? Because there are too many images on the page.
3. Why are there too many images on the page? Because the marketing team wants to showcase all the products.
4. Why does the marketing team want to showcase all the products? Because they think it will help increase sales.
5. Why do they think it will help increase sales? Because they don’t have any other way to showcase the products.

Root cause: The website is slow because there are too many images on the page, which is causing it to take a long time to load. The marketing team is requesting too many images because they don’t have any other way to showcase the products.

Solution: The 5 Why’s allow us to identify a solution based on implementing a new system that allows the marketing team to showcase the products in a more efficient way, such as a product catalog.

Example – Our critical application failed (Root Cause Analysis)

1. Why did the application fail? Because the server was no longer available?
2. Why was the server not available? The server failed because of a hardware outage.
3. Why did we have a hardware outage? Because the system was not build with redundancy?
4. Why was the system build with no redundancy? This was a business decision based on the defined crititicality of the application.
5. Why did the business made that decision? Redundancy would have been too expensive.

Solution: Support the Business to develop a use case around buisness value, risk and cost of the possible options and review high availability options.

Example – The system keeps crashing.

1. Why is the system crashing? Because it’s running out of memory.
2. Why is it running out of memory? Because there are too many processes running at the same time.
3. Why are there too many processes running at the same time? Because the system doesn’t have enough processing power.
4. Why doesn’t the system have enough processing power? Because the hardware is outdated.
5. Why hasn’t the hardware been updated? Because there is no budget for new hardware.

Visualization

Conclusion

The 5 Why’s is a powerful tool that can help you quickly get to the root cause of a problem. It’s a simple technique, but it requires an inquisitive mind and a willingness to keep asking “why” until you find the underlying problem. By using the 5 Why’s in your work as an IT architect or project manager, you can help design systems and solutions that solve business problems more effectively and efficiently.

From personal experience I can add that you will be surprised at how often an apparent technical problem has a root cause in organisational or budgetary areas. By using this technique, you tell a story that all stakeholders can follow, because it does not use technical terms.

A german version is available here and I recommend reading about how architecture is team work here.