6. The SOAP Method: Subjective Data, Objective Data, _Analysis, and Plan
Sams Teach Yourself Network Troubleshooting in 24 Hours
Author: Jonathan Feldman
I hope you've liked all the writing involved in the last hour, because the
method of troubleshooting in this hour involves a great deal more of it. Treating
a complex problem usually involves a lot of note-taking, because you have
to fill in the gaps where your understanding of the problem is incomplete.
Up until now, you've treated problems the way you treat a multiple-choice
testwith change analysis, divisive reasoning, and matching. Now, we're
talking about a fill-in-the-blank test, and it gets a little bit harder; this
is the hour where you have to wade through the subjective, match it up with
the objective, analyze your data, and plan on what to do next. In other words,
this is the hour you want to save for the tough problems.
First, a little bit about the SOAP method. I first encountered the SOAP
method while I was deciding not to be a doctor like my father. Although
I had absolutely no interest in sticking needles into people, hanging around
my father in his office taught me a lot about troubleshooting. In a sense,
medicine is much harder than computingthere are hardly any
standards, the designer never released the data sheets (much less the full
documentation), and the device you're trying to troubleshoot can sue you
if you make a mistake. The medical profession has come up with all sorts
of diagnostic trickswe as network troubleshooters have a great deal
to learn from the medical profession.
One of those diagnostic techniques is the SOAP method of note-taking.
On their patients' charts, some doctors write down on separate lines the
letters S, O, A, and P, standing for Subjective,
Objective, Analysis, and Plan, respectively. Therefore,
if I went to see the doctor about my stomach, he might write:
S: Patient reports stomach pain; ate hot chicken wings
last night; extra work lately.
O: Palpation reveals tenderness in upper right quadrant.
A: Suspect acute gastritis.
P: Treat with antacid x 5 days, bland diet, follow up in
5 days to assess condition.
The subjective is what I say to the doctor, the objective is what the doctor
sees, the analysis is what he deduces from his additional questions and
reasoning, and the plan is what he will do to try to treat the problem,
plus the next step. Doctors are used to not being able to get a black-and-white
answer; however, if they have a plan, they are going in the right direction.
Going in the right direction is what the SOAP method is all about. Not
every problem you run into as a troubleshooter is going to be solvable within
that day or weekparticularly problems that are not show-stoppers (emergency
room visits). In particular, problems that come and go (intermittent problems)
are usually long-term and complex troubleshooting
jobs. To be able to wrap your arms around a complex problem, you have to
segregate the problem into its component partsthat is, the subjective
report and the objective facts. It's particularly important to be able to
separate the subjective outsomeone may be reporting something that
has some bearing on the problem but perhaps is not pointing directly
at the problem. Consider someone who's reporting chest painsis this
person reporting a heart attack or a muscle problem? The report of pain
in the chest is a subjective feelingthe active investigation that
reveals a heart attack or muscle pain is the objective finding. The subjective
is useful but can only be borne out
When considering the facts in an intermittent or complex
network issue (also known in the industry lingo as "troubleshooting
a weird problem"), you need to categorize a basic list of objective
items that can help point towards a solution:
Duration of problem (all the time or intermittent?)
Start of problem (date and time)
Place (on the network, physical location)
Number of users involved
Configuration of workstation (like or unlike others?)
Number and types of applications involved (running simultaneously
User name(s) involved, security group(s) belonged to
Behavior of similar applications
Even though you may have a lot of objective data, you might not have
the right objective data to analyze in order to come to the right conclusion.
Therefore, your "plan" item on your first couple of tries on
a tough problem will probably be to gather more data. Don't give up; the
more data you have, the better guess you can make.
Let's take a case in which a user says she can't run a particular
Web applet that she needs for her
job. Figure 6.1 shows a logical
map of the site; her PC lives at point A on the map.
You visit the user's PC and can run the applet just fine. She frowns
at you, and says, "Well, it doesn't work for me." She tries
right after you, and it works, but she reports the problem again the next
day. You decide to use SOAP on this one:
S: Web applet does not run.
O: Web applet runs when I try it.
A: Perhaps the time of day has something to do with it?
P: Come back during the time she usually tries the applet.
Troubleshooting a time-related problem.
Your analysis of the problem is a good one, and your plan to gather
new information works. You visit her when she usually tries her Web
applet, and, sure enough, it won't work for you. What's going on? This
time through, you're the one supplying the subjective data; it's your
S: I bet that the time of day has something to
do with the applet not working.
O: Web applet does not run at 8:00 a.m.
A: Could it be related to another network activity on
that segment happening at the same time?
P: Try using a different network segment (point
B on the map).
An okay plan, but it doesn't work out,
as shown from your notes:
S: Network activity may be different on her segment
at 8:00 a.m.
O: Web applet still fails on a different segment.
A: My head hurts. What else could be different
at this time of day?
P: Investigate what goes on at 8:00 a.m. on the network
as a whole.
She still has problems at 8:00 a.m. on a different network segment. That's
fine. You've now ruled out her network segment, and that's very important
to do. You've made a deduction, and it's wrong. Don't sweat
One of the primary architects of OpenCable, Michael
Adams, explains the key concepts of this initiative in his book
Broadband, Second Edition
by George Abe
Introduces the topics surrounding high-speed networks
to the home. It is written for anyone seeking a broad-based familiarity
with the issues of residential broadband (RBB) including product
developers, engineers, network designers, business people, professionals
in legal and regulatory positions, and industry analysts.