Root Cause Analysis for Software Problems
Let's assume that every problem worth solving has a cause. Interesting assumption. Reality: Any one problem may have many causes. The causes may interact in complex ways. How do we go about figuring this out?
We can use the technique of Root Cause Analysis (RCA) to brainstorm the reasons for why the problem is occurring. I'd like to demonstrate this technique to investigate the causes for JaBOWS (in a later post). First, we need to lay some groundwork.
Many of you have heard of Root Cause Analysis. The most common method is known as "5 whys" where you ask the question "why" five times.
Problem: My car won't start
Why: The battery is dead
Why: The alternator doesn't work
Why: The alternator belt broke
Why: I allowed it to get frayed and worn
Why: I have not maintained the car on the proper schedule
That method is useful in some situations, but it leads to a single cause. For systems of people and software, I'd rather use a fishbone diagram, aka Ishikawa diagram.
The fishbone diagram is usually used to categorize the causes of systemic effects in product manufacturing. In that space, we would use categories like: Price, Promotion, People, Processes, Place / Plant, Policies, Procedures & Product.
Is this useful for system integration or IT Business Software? Not really. The listed categories miss the obvious problems solved by information or functional interdependencies. In addition, the notion of 'place' is probably best replaced with 'proximity.'
Doing a little analysis, I repurposed the standard categories to make more sense for Software Root Cause Analysis. See the Software Fishbone Diagram above and the description of the categories below.
To demonstrate the value of this work, I'll follow up in a later post by using this approach to take on the causes for JaBOWS.
| Category | Definition of the Software Root Cause Category |
| Cost | Causes driven by or related to the cost of resources, time, materials, or licenses needed to create, manage, deploy or maintain systems. |
| Culture | Causes driven by the culture of either the producer organization, customer organization, or prevalent culture |
| Context | Causes driven by the interrelationships between information, process, and/or functionality supported by the software or embedded within it. |
| People | Causes driven by the people involved in creating, managing, deploying, or maintenance of systems. |
| Process | Causes driven by the business processes by which the system is created, managed, deployed, or operated. |
| Policy | Causes driven by the policies of the organizations that create, use, or maintain software. |
| Platform | Causes driven by the capabilities of the software systems used to create, manage, deploy, and maintain the software. |
| Proximity | Causes driven by the relative distance between people involved in the creation, management, deployment, and maintenance of the software. |
