Re: ADSM Support (sorry: long-winded and philosophical)

On Mon, 14 Jul 1997, Eric R Pfaff wrote:

> The ADSM Software Support Team is deeply concerned our customers needs
> and expectations have not been met as described in recent listserv =
appends.

We as customers were also alarmed that the dissatisfaction about ADSM
support which had previously been an exclusively European phenomenon is
now observed in the US and Canada as well.

> We have been adding resources to our staff and taking other actions to
> improve our effectiveness.

A non-technical side-remark:

My concern is that we see here a consequence of the world-wide trend of
companies to focus on "shareholder's value" as distinct from "company's
value", let alone "customer's value". My theory is that shareholders who
do not consider themselves owners of a company but only investors of =
money
(eg. investment funds) are not at all interested in a company's
medium-term viability but only in short-term revenue. The primary means =
to
increase the latter on cost of the former is firing (or not sufficiently
hiring) staff even when the proper functioning of the company is
jeopardised.

But back to the technical issues relevant here:

ADSM support need to recognise that it is different from other software
support in at least three respects:

   * Critical errors depend on the local situation. Other than with =
other
     software, it is unlikely that a critical problem can be reproduced
     elsewhere; it is too much dependent not only on the specific
     configuration, but potentially on the entire history which may be
     reflected in the database.

   * Critical errors are likely to remain after fixing. When, after =
analysis
     of a problem, the software is fixed to no longer introduce
     inconsistencies, this will not in any way help repair the problems =
that
     have already occurred at the customer's site.

   * There is no backup for the backup. Unlike most other systems, an =
ADSM
     installation has no backup. In general, a wrong computation can be
     duplicated after correction of the problem, lost data can be =
retrieved
     from a backup. If, however, the backup and archive system is
     malfunctioning, there is no rescue.

The above hardships are inherent in the endeavour of providing backup =
and
archive solutions. A support team must be prepared for this arduous =
battle
in which the traditional means of support are blunt weapons. The
dissatisfactory scenario is:

   * The customer calls local software support.

   * Local software support can neither reproduce the problem nor =
analyze
     it. They can just ask the customer a couple of standard questions.

   * They will then send the answers to central support who - if the =
problem
     is not already known - will tell local support the next questions =
to
     ask the customer.

   * The above process repeats with a turn-around time of a week in the
     avarage. Local support is demotivated by the procedure in which =
they
     play no active role and which does not lead to a solution.

   * During the whole time, all or part of the data may be inaccessible.
     Damage keeps growing.

   * At some time, one of the players gives up. The problem remains =
unsolved
     and the customer dissatisfied.

This is not a theoretical scenario. We had it in the past (I have =
repeatedly
reported here on our loss of the ADSM database which we were not able to
have analyzed) and we are currently afraid of getting it again with =
another
incident (I should not be too pessimistic as we are not yet at the last
step).

The way it should be: When the problem is sufficiently analyzed to see =
that

   * the problem is not reproducible
   * data is jeopardised

then a data rescue task force should investigate the problem and work on =
the
solution until

   * the customer's data is rescued
   * the customer's database is freed from remnants of the problem
   * the software is fixed so that will not cause the same problem again
   * tools are available to check at other sites whether the same =
problem
     may have occurred there as well, perhaps still undetected, and, if =
so,
     to provide repair
   * due notice has been given to all concerned parties.

This may violate the imagery of a perfect, ever-functioning software, =
but it
would render the software viable for a world where not everything is =
always
perfect and ever-functioning. In other words, ADSM would become a
professional tool from a professional company, designed for professional
customers.

Best regards,

Helmut Richter

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr. Helmut Richter                       Leibniz-Rechenzentrum
Tel:   +49-89-289-28785                  Barer Str. 21
Fax:   +49-89-2809460                    D-80333 Muenchen
Email: Helmut.Richter AT lrz-muenchen DOT de    Germany
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D