Re: BPCS History

Wow!  There's a whole host of lessons to be learned from this tale!

I wonder how many other software projects took such a downward, wayward
spiral as this?

Thanks Joe. Very interesting.

Shannon O'Donnell


----- Original Message ----- 
From: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'" <midrange-l@xxxxxxxxxxxx>
Sent: Monday, September 22, 2003 4:13 PM
Subject: BPCS History


> > From: shannonjano@xxxxxxxxxxxxxxx
> >
> > Can you expand on your comments a bit about BPCS?  I used it many,
> many,
> > MANY years ago and liked it back then (somewhere around 1989/1990).
> >
> > Were you working there when they chose the SQL course?
> >
> > I guess what I'm asking for is war stories and gossip. :-)
>
> I'll post one semi-autobiographical account of the demise of The SSA
> That Covey Built.  This is based on memory and some conjecture, so
> accuracy is in the eye of the beholder.
>
> During my last years at SSA, we were in the midst of the client/server
> revolution and at that time, it was all thick client.  We were also
> trying to figure out configurable processing, which meant the ability
> for end users to customize their workflows (for things like order
> entry).
>
> We had an incredible architecture in place, that we called CPR (for
> Configurable Processing, but I coined the term with no small amount of
> amusement at the irony of the acronym).  This architecture was going to
> revolutionize the industry.  Small, independent modules could be called
> anywhere in the job flow.  Each session would keep track of the current
> session information, and each module would query the session for needed
> information.  If it didn't find what it needed, it would prompt the
> user.  The panel it used could be different for different users,
> allowing either fast path entry or more detailed transactions.
>
> All database interactions were encapsulated by server programs.  The
> servers all shared a common interface and could be invoked by any
> program.  Related files (header/detail) were processed by the same
> server, and servers could in turn invoke other servers to resolve
> foreign keys as necessary.
>
> What a concept!  And all in RPG III, no service programs, none of that.
> We made use of data queues and programs that didn't turn off LR.
> Sessions and even individual transactions could be restarted in case of
> errors, all that good stuff. And this cleared the way to interaction
> with thick clients, which could all call the same servers (can you say
> "web service"?).
>
> And then it happened.  In the early 90's management turnovers started
> happening.  Roger Covey (the architect of the software and founder of
> the company) was spending extended time in China, both for personal
> pursuits (he was an Asian history scholar and spoke Mandarin, if not
> other dialects) and in an attempt to exploit the fledgling Chinese
> manufacturing industry.  A former marketing Veep from IBM was brought in
> to run the show, and rather than the late-night technical arguments
> (often in the local tavern) between the technical managers and the
> President that had directed the architecture of the package, instead
> technical decisions began to be made in boardroom meetings by
> non-technical people.  Decisions were soon based not on sound technical
> merits, but on the latest buzzword of the day.  "Platform independence"
> started to rear its ugly head, and thus began the ill-fated move towards
> Unix and SQL.
>
> Unix experts were brought in, who insisted that SQL was more than a
> match for DB2, and that OS/400 wasn't really that complex an operating
> system; they could emulate both inside of a year.  I remember finding
> this amusing, especially the one code cowboy who insisted that he could
> write an AWK script to convert RPG to C in a single pass.
>
> Thus began the road to perdition.  A few of us declaimed the Emperor's
> nakedness, but in general we were shouted down by visions of
> marketshare, not to mention the newly found motherlode of cheap labor to
> be had in places like Bangalore.
>
> Anyway, to cut the story short, projections of writing the emulation
> were wildly optimistic, to say the least.  Having no concept of things
> like program to program calls, it turned out that Unix wasn't quite
> ready to emulate OS/400.
>
> An example: Program calls with parameters were emulated by writing the
> parameters to a file, spawning the called program and waiting.  The
> spawned program would then read in the parameters, do its thing, and
> write the parms back to the file.  The calling program would then wake
> up and read those parameters in.  As you might guess, this had some
> negative impact on performance.
>
> Another example: in an effort to maximize the ability to
> programmatically convert code from RPG to SQL/C, the C programmers
> simply chose the easiest way to do things.  Nobody who knew both systems
> was in charge, and the SQL experts weren't exactly adept at business
> programming.  Thus, a CHAIN became a SELECT using a cursor (because you
> never knew if someone was then going to do a READP).
>
> Then, in order to try and catch up with the schedule, the first option
> was to farm as much as possible to India.  The results, especially with
> the state of the Internet back then and the hit or miss ability to send
> large files, were less than stellar.  So, the client/server project
> began to be cannibalized.  I raised more of a stink, and that was the
> beginning of the end of my tenure at the company.
>
> Interestingly enough, I did have one last major part in this IT tragedy.
> Near the end, as the product was about to be delivered to the first beta
> sites, somebody noticed something.  Nobody had bothered to convert CL
> programs.  In fact, nobody had bothered to even design the basic
> features of CL programs, such as overrides, or message queues, or
> printer files, or even the concept of a batch job.  Over the course of
> three weeks I became intimately familiar with HP-UX as I basically wrote
> an OS/400 emulator, and the product finally limped (and that's putting
> it kindly) out the door.
>
> As you can see, by this time pretty much all the resources of the
> company had been bet on this new technological direction, all processes
> had been transformed from the traditional development life cycle to a
> bastardized combination of rapid application development and outsourced
> programming with no real design lead.
>
> And when the thing was released, it was slow, lumbering, error-ridden,
> and ugly (remember, it was STILL a text-based interface - the closest it
> ever came to anything GUI was a nasty screen scraper front end that
> didn't even function properly with character-based Unix terminals).
> Nobody bought it, and rather than cut their losses, they continued to
> pour money into it.  Any true innovation (such as the modular
> client/server architecture) went by the wayside.  Some left, some were
> fired, some just burnt out.
>
> And thus ends the tale, the sad tale, of The SSA That Covey Built.
>
> Joe
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>
>