Michael S (already5chosen@yahoo.com) on 2/10/09 wrote:
---------------------------
>
>Usual divide and conquer strategy should apply. What's impossible at corporate level becomes doable at departments.

Nope...

>Besides, computers don't suddenly disappear. Good IT persons or good consultants
>could huck a quick replacements out of off-the-shelf parts.

You presume that off-the-shelf parts exist. And it isn't simply that the computer is functioning, but that it can reliably do what is expected of it. But that really isn't the point.

Let's say you are a financial institution, and occasionally some of your transactions misplace a decimal point, or drop a few digits because of a 'soft error'. While you might be able to rerun the transaction after discovery, the damage it could do to your customers, and your reputation, could put you out of business.

So you can juryrig a few systems that will function - but can you guarantee they will *always* give the correct results?

>Sure their use would
>require few times more manual work the full custom stuff the failed but still would
>save orders of magnitude of manpower versus hand calculators.

So, let's say you have a large Unix system doing customer transactions - tens of thousands per day. Your system fails, so you bring in a few hundred x86 systems and... do what? Go buy off the shelf software, install it, port over your customer database, write a few lines of code to customize it so it does exactly what you want and viola' - you're back in business... right?

What we are talking about is not simply the fact that your transactions can be run sometime, but that you can satisfy your *CUSTOMERS* expectations of when you will be able to supply them. If you fail, you lose their confidence.

I used to work for ADP, and they did a *lot* of different services - taxes, payroll, billing, etc. Their mission critical app was payroll. If they screwed up *one* payroll run, they would be dead. We had two systems running in tandem, and one evening one of them went up in smoke (literally). We had to run all applications on a single system. The result was that everything else was put aside, and payroll was the *only* app that ran. Not only that, we only did what was necessary to print checks - no other payroll reports were generated until all checks were printed. Period.

Had they missed that payroll, it would have literally cost them millions - even if only by a few hours. This is because many of their union shop customers had a contract that ADP would have to pay *every* payee overtime for each hour their check was late. That is mission critical.


>
>First, your story tells us about the business that didn't fill my first condition - to be worth its salt.

You can try to change the definitions of things all you want. This was a business that had been around for over 50 years, and was very well respected at the time. Fact is, had their *mission critical* application not failed (in this case due to human error, not hardware or software), the business would have continued to function. The app failed, and so the business failed.

>
>Second, what's new - people can screw things up. It's easy, because we tend to
>trust non trusty people. The similar screw ups with computers are less likely because:
>1. Like with people, we tend to trust computer programs after seeing them delivering
>correct results several times. But unlike people, computer programs that delivered
>correct results several times are indeed likely to continue doing so.

Unless, of course, you don't have redundancy and/or error checking - and this is where the RAS comes in. Which, I thought, was the original point of this thread.


>2. Computer mistakes tend to be more obvious the human mistakes.

Uh - you actually believe that?

>3. Computers don't fool you intentionally.

Intent has absolutely nothing to do with it. We are defining mission critical applications, and why reliable (and servicable) machines are important.