Re: OT (Maybe): ERPs

"Ah...now you touch on it...it really isn't a hardware platform issue
...it's
a software platform issue.....only a specific instance of a failed
project
knows why the project failed and I'd venture a guess that 75% of
projects it
is not the hardware... "

First, I generally deal with systems that process huge amounts of data.
In the accounting system's case, data was sent to it across the
internet. That data was processed to produce bills and statements.

It became obvious that at some point (within months) the laser printer
would not be able to print all the "reports" in a timely fashion. This
would cause a need for multiple printers, and a larger hard drive used
to spool the print output. This was on top of the number of electronic
billing statements/invoices being sent out.

So, yes it is a hardware issue. This is generally what I am talking
about when I speak of architecture and I do modeling to determine if
the system can handle the I/O load required of it. Again, the
accounting system moved to NT, all the users (<10) were able to access
the data across the LAN. Had there been a need for 100 users, the LAN
would have needed an upgrade, and that would have required going from a
single do it all server to 3-4 servers.

If they were to have more data coming in (I have forgotten how many MB
it would take), then the Telecommunications connections would have to
be upgraded (business level broadband - and at that time it was
recognized that the ISP had over sold its capacity). Once we surpassed
a certain point there, then the NT server handling the incoming data,
regardless of motherboard (single or multiple CPUs), clock speed, etc.,
would not be able to handle the data in a timely fashion.

As can be seen, there are many types of I/O processes that must be
looked at. CPU speeds are generally so much faster than I/O rates, that
software platform is not really an issue until you do an environment
migration. Had there been a migration to Linux from NT at that point,
it can now be argued (it wasn't available to argue then) that the Linux
system could do more in the same time. But the do more capability still
ran out of gas because the limitations imposed by simple physics.

And so the reason for COBOL being used on day one was to facilitate
moving from one environment to another as that company grew (COBOL
programmers are more available than are C++ and/or VB programmers --
therefore, less training would need to be done as the system grew).

Amazing what happens when a real architecture knowledgeable person is
in the room with the Board of Directors.

Later,
Steve.T