Corel_LINUX_OS_Desktop_to_Access_and_Run_Windows_Applications

David Allen jallen at cts.com
Sat Jan 8 14:38:47 PST 2000


** Reply to note from kplug-list at kernel-panic.com Sat, 8 Jan 2000 00:38:45 -0800 (PST)
>   
> In my experience, support costs for large-scale deployments increase in direct proportion
> to variation. There is a point at which it is cheaper to install a Citrix solution than it
> is to support the variances in end-user configuration at the workstation activity level of,
> say, a call center, or a large data-entry/processing center.

I'd have to say that my experience is the same. But it doesn't have to be this way. I put the
reason for high support costs on the poor quality of many support personnel. That's not their
fault either. But I have seen that PHBs don't think that hiring highly qualified IS support
staff is money well spent.

I have worked with too many people, especially lately, who just didn't have the experience,
or often, even a real interest, in computers. It looks like a fun way to make a living, and
with new generations' experience with computers being almost exclusively game-playing, I can
understand that thinking.

My feeling is that one cannot become competetant in the field of computer careers while
looking at it as just a job, or even worse, just a 9-5 job. It just moves too fast, there is
so much involved, that one has to constantly research and keep hands-on just to keep up.
Getting ahead is virtually impossible, becase no one can know everything.

I think there are way too many people getting into this field because it seems "Cool". Well,
it is, but it is also hard and, very often, frustrating work. Problem is, if you don't know
what you are doing, and you don't want to, of can't learn, it doesn't stay fun very long.

I have seen many young kids get hired to do support, and quickly get disillusioned when they
find they have to actually learn something new each day. "Gosh, this is work, it's just not
fun anymore". The net effect is that, in order to avoid learning something new, they tend to
apply the same solution to every problem. If the solution doesn't fit, they shoehorn the
problem to fit the solution. Pretty soon, the allowed solutions are defining the allowed
problems. Anything that can't be fixed with the standard set of solutions is just not
supported:

 "I have no idea how to fix that, maybe you shouldn't use it. Here, use this instead.
  It's not really meant for your particular application,  but at least _I_ know how to
  fix it when it breaks".

And of course, by definition, the inferior solution breaks often. From the user's point of
view, the solution is often worse than the original problem. The end result is more trouble
calls than before, or less productivity from the client or both.

It's interesting that our company used to do most of it's programmning solutions in-house.
Now, of course they don't because they don't want to pay the going rate for competent
programmers and analysts. Those apps and systems generally had a much longer useful life than
do any of the off-the-shelf solutions being used today. And almost no shrink-wrapped products
provide complete solutions to any problem. {Of course, I am not talking about clerical apps,
but the usefulness of this catagory has not really increased with its costs either).

Since moving to off-the-shelf apps our support costs skyrocketed. The reasons were several:

  Proprietary products - I don't need to explain the bad of this to this group!

  Less knowledgable personnel hired to support proprietary solutions. Being proprietary,
  there is really no such thing as an expert support person for this product, outside of
  the vendor. So, if we need expert help, we call the vendor. We don't need to hire experts
  in-house, because no one can be an expert on all the products we use! All we need is some
  one on call who can dial the phone and follow directions. We can teach such a person to
  the more mundane tasks such as backups, re-installs, etc. Actually, those two jobs can
  probably keep the average NT administator busy all week, and maybe even keep the system
  up indefinitely (that is, with no hard crashes, but merely, the occasional, reboot).

  Licensing. Almost all shrink-wrapped products are licensed. Multi-user products are
  renewable, per-seat on an annual basis. M$ does not do site licensing, and no longer
  allows on-demand client-server use or per-connection licensing of its products. Many
  high apps demand expensive maintenance contracts. (And if we are paying the vendor to
  support their product, we don't need hire someone in-house with the same ability).

  Upgrades. The never ending install-fest. This probably consumes more time and money than
  any other single effort on the part of the support group in large organizations. A side
  effect of this is an increase in bugs, real and imagined, caused by incompatibilities
  between various untested upgrades of various products. Because of the high frequency of
  product upgrades, it is nearly impossible to achieve a stable environment for any length
  of time.

  High expectations of ignorant PHBs. PHBs seem to have an overly optimistic view of the
  reliability, stability, maintainability and cost of canned (shrink-wrapped) software.
  Based on those views, IS budgets are lower than IS costs. Too little money always costs
  too much money.

There are other costs, but I have found these to be most visible to me.



> > you need more you may as well install the instances
> > on different machines. 
> > It just sounds hard to justify both financially and
> > practically.
>   
> Hypothetically, if you save $500,000 in support costs by simply exporting a display instead
> of risking client-side configuration variances, and it only costs you $200,000 to set up
> Citrix WinFrame and a big fat site license for your app, it's not really a hard decision.
> Big obvious costs savings that can be explained to a PHB will outweigh any arguments based
> on the technical elegance of an alternative solution.

Obviously, this will work with some solutions. WinFrame may be one of them, but not knowing
it, I can't say. But I can't see how most such bastardizations can be very efficient or
cost-effective for the general case. It depends too much on the reliability of the solution,
which needs to be very high in a multi-user environment. There is a reason that big iron cost
a lot: reliability. When you have many users dependent on one shared resource, 90% or even
99.9% uptime is just not good enough. You need 100% uptime. The costs of running that machine
is dwarfed by the cost of labor for people who can't do their jobs because "The computer is
down".

Also this solution is not going to work for everyone, unless everyone does pretty much the
same thing. It looks better when there are a lot of users doing the same thing. And it
assumes no proprietization of hardware use by the software.

One of our solutions to client-side configuration variences was to minimize it. Too many
people in an organization think the 'Personal' in 'Personal Computer' means that the box
belongs to _them_ instead of to the company. We tended to ignore such personalizations such a
color schemes, desktop layouts, screen-savers, application-defined preferences, etc., but did
not allow non-company-owned software, non-standard data formats, or non-standard local data
storage (for LAN-connected boxes).

All configuration files were standardized (autoexec.bat, config.sys, for example on DOS
boxes). All data was to be stored at defined locations on the LAN. We even configured Windows
exactly the same on every box, right down to the color scheme, icon/window placement, etc.
Often, dangerous apps, like fdisk, format, etc were removed. We found that if a box was set
up in a reasonable configuration, most people just left it alone. Only a few would do
much more than maybe change their colors or screensaver.

If we came across a box with personal software, odd system configurations (for no apparent
reason), or such, we "corrected" the problem, explaining to the customer as necessary.

I'm just saying that how the IS department does its job has a lot to do with IS costs. If you
want the job done right, you pay the right people to do it.

                           Sincerely, David Allen
                           <jallen at cts.com>



More information about the KPLUG-List mailing list