Remote Mismanagement

Whether or not, as Reuven Cohen has suggested in his blog ElasticVapor :: Life in the Cloud blog, cloud computing "is just a little bit of history repeating" (where, in this case, the history happens to be the origins of ARPAnet), it still needs to be recognized as the new new thing for the old old problem of managing resources by maintaining a significant number of those resources remotely. For those of us who can remember the time sharing systems that existed before the ARPAnet was even a glimmer on the Defense Department's budget, the history goes even further back than Cohen imagined. Nevertheless, the problem is still with us. Are we just so innovation-hungry that we do not recognize when the solutions repeat themselves; or has each solution led to its own sad story of a nice theory running aground when confronted with practice?

I had two interesting episodes concerned with service providers having to deal with the unintended consequences of remote resource management. One was my broker, and the other was the guy who runs The UPS Store downstairs, for whom both my wife and I have been loyal customers. Let me briefly account for both episodes.

In the first case my broker is now one of those professionals who, thanks to the many advances in Internet technology, can spend much of her time working from home. Thus, most of our telephone meetings are telephone meetings that both of us conduct in front of a screen. I am looking at my personal records and, if necessary, some screens from Yahoo! Finance; she has a secure connection to her company's resources, many (most?) of which I would not be able to get to on my own. The problem she faced this morning had to do with getting that secure connection. If it is anything like the sort of technology with which I have had experience, it probably involves a client-server system; and, on the basis of the few remarks she made when she called to say she would have to push our meeting back an hour, my guess is that some changes had been made to the server since the last time she had made a connection. I have no idea whether or not this was actually the case, nor do I know if her company uses electronic mail to circulate information about internal maintenance activities. All I know is that she was caught off guard when she tried to make a connection prior to a scheduled meeting and could not do so.

The story at The UPS Store was a bit more drastic. It turns out that, once you become a customer, your history of business transactions goes into a database whose contents are accessed through your telephone number. Beyond the extent to which this may serve any UPS data mining technologies, the good news is that, once we send something to an address, it is "in the system." Thus, at this time of year, when, for the most part, we are sending gifts to the same addresses to which we sent last year, the sending of a batch of parcels can be handled rather efficiently (meaning the shop can be run with a rather modest staff). Unfortunately, those database records turn to reside at a remote site; and this morning they were "off the air," which had two consequences:

1. Getting out my packages took over twice as much time.
2. The line behind me started growing and a rate I had not previously seen.

Furthermore, since it was early in the morning, the store manager was the only one in the shop; so he had to deal with this increased load all by himself, a wonderful way to start the day.

As I see it, both of these vignettes have the same punch line: There is no doubting the advantages of remote resources when they work, but what happens to your operations should they become inaccessible? In the case of managing a secure connection, my guess is that you do not want to compromise the security; but I suspect there are still ways in which the meeting could have proceeded without the secure connection, say, by preparing some of the material in advance and taking steps to guarantee its security (such as keeping it on a computer not connected to any network). As to the UPS story, there is no reason why that database could not have been maintained locally and synchronized with the master database used for data mining. One could even periodically create space by local deletion of records never accessed, but my guess is that storage is cheap enough these days that such measures would rarely, if ever, have to be taken.

My point is that, whatever the benefits of a technology may be, success always depends on customer satisfaction. Safeway learned this the first time their automated checkout stations decided to have a meltdown. This happened at our local Safeway about a month ago; and my wife, who was initially impressed with the technology, no longer wants to put up with it. (My own spot-checks indicate that customer confidence is recovering; but I am sure that my wife is not their only suspicious customer!) Customer satisfaction is not just about improving the customer experience when things are working. It is also about making sure you do not lose the customer as a result of an experience when things are not working. You do not read much about this in the literature concerned with how these systems are designed, implemented, and deployed, which probably has a lot to do with why so many of the technologies that now confront us leave us with few feelings other than frustration!