We’ve completed our monthly web conferences with our clients, following our January reports which cover December. This is always the most interesting month of the year for us, because it’s the time we grade ourselves. Most of our clients process point of sale transactions, so this is the time of the year with their highest volume. We grade ourselves on how well we’ve been able to anticipate and prevent client processing problems.
Each month we grade our clients’ systems, from A to F, on a dozen factors. An “A” from us means “Adequate capacity.” “B” means “Basically adequate.” Grade C means “Cause for concern,” or, “You had better have someone take a look at this problem because we think it’s going to hurt processing if it’s not fixed.” D is “Deficient,” F is “Failed, too late!”
This year I would give us an “A-“. Not because anyone failed or had processing problems that we could have foreseen. We deserve an A- because we didn’t push one of our clients hard enough. We didn’t ask enough questions, and cause a large enough stink.
They are a large client, lots of systems, processing point of sale. Unfortunately, they are also compartmentalized, and outsourced, and don’t communicate well enough among themselves. You know the pattern: Operations, sysadmin, capacity planning, and applications are all large departments. We’ve been asking for years for some key information which would help us track and trend their application traffic statistics. We’re just now beginning to get it. We’ve offered our monthly web conference to them, but they haven’t attended in years. We know that they use the statistics we generate, and review our reports, and act on our warning emails and phone calls, but feedback is lacking.
When we are able to count and track the application statistics, we are able to correlate the system usage stats with the application traffic stats. We are able to project those numbers, and answer the question “Will we make it through the next peak?” Equally as important, we are able to look at the intra-day processing patterns, and the larger day/week/month/historical patterns, and answer the questions: “Does this make sense? Is usage proportional to the demand on the system? Why is CPU or Disk or Comm activity at X per transaction at this time, and Y per transaction 3 hours later?”
If we had been able to do this for this particular client, we would have been able to detect well in advance that a user had been doing large DB restores at bad times during the day. S/he continued doing these during Christmas week, and the online application suffered.
No, we don’t monitor their systems in real time. No, we aren’t involved with their operations policies, nor their security policy. Yes, they hold some blame here too, perhaps the lion’s share.
But, as consultants, we should be pressing harder for the client to engage us in the dialogue that we offer them. We should press harder to acquire the best information possible on the system and application. We should press harder to make the Ban Bottlenecks process work superbly.
“A-“
Recent Comments