Management Perception of System Administration

[Bryan McDonald]

5 9's always amuses me. People always ask for it, and most don't understand
what they are asking for.  And your right, trying for it is interesting.

One of the problems I saw a lot when I was at GNAC doing team consulting
work was that many customers did not understand what their real core
requirements were when it came to relibility and recovery.  Each contract
started not on the design board, but talking to the customer management team
and deciphering what their true requirements were of their IT systems.
Given that we were almost always called in to do something that had been
attempted already, the fact that the requirements were not already clearly
defined is the reason the project failed in the first place.

This is clearly tied into the discussion of strategic management versus IT
management.  IT managers and staff usually can tell you what the technology
requirements are for solving particular kinds of problems, but they are
disconnected from what strategic managers think the real problems to solve
are.  Many sr managers and executives I have known have a clear idea of the
business problem they are trying to solve, but are not effective at
translating it into the technology requirements needed, nor at expressing
the business issues to the technology managers for them to translate.

As more executives progress from computing ranks, this is changing, but this
just demonstrates that IT department integration into corporations is
maturing...and they will be just as broken as other departments in
corporations, but only just, and not more so. ;-)

bigmac

> -----Original Message-----
> From: Jim Hickstein [mailto:jxh at jxh.com]
> Sent: Friday, February 22, 2002 1:13 PM
> To: Bryan McDonald
> Cc: David Dull; baylisa at baylisa.org
> Subject: RE: Management Perception of System Administration
>
>
> One thing struck me about the technology risks: Someone says "we want 5
> nines", but then they set up a business that cannot tolerate any service
> interruption above that point.  0.99999 is a _probability_, not a
> certainty, and an average one at that.  Some days will be below average.
>
> I was thinking of systems where this would seem to matter more,
> and seem to
> achieve better certainty: airline reservation systems, and better yet,
> air-traffic control systems.  Yet, in the latter case anyway, they _do_
> have major system failures, and they _do_ have major service
> interruptions.
> But they also have manual procedures.  When the radar goes black,
> you talk
> in the radio; when the radio falls silent, you look at your
> pieces of paper
> and start talking on the telephone (to other radio operators).  The
> airplanes have procedures for clearing the airspace around such an
> emergency, and they don't all fall out of the sky.  This happens
> _routinely_.  (P.S. Don't tell the passengers.)
>
> I didn't see a failsafe system when Paul was describing the totes going
> round the distribution center.  Partly this may because they
> didn't set out
> to design one.  But that, IMO, is a business failure, not a technological
> one.  Some service interruptions, at some level, are
> _inevitable_, period.
> (And the harder you try -- and succeed -- to reduce the small disasters,
> the larger the average disaster becomes.)  If you set up a business that
> won't survive one, and don't have the humility to admit that Plan
> B should
> exist, that's not the technology's fault.
>
> You can buy a certain number of nines these days.  But so can your
> competitors.  The next couple of nines are harder, and they consist of
> putting systems in place to help people avoid making mistakes.  I've
> achieved some modest success at this in my operations career.  It's the
> most interesting part, to me.