Re: BPCS History -- MIDRANGE-L

I think that SSA's problems stemmed from many things.  Granted the foray 
into Unix probably looked like a sound business decision, however poorly 
executed.  And trying to bring down the product into the least common 
denominator didn't help.

There were a host of other problems.  Like their attempts at EDI. 
Everybody and their brother had an EDI package.  What the market needed 
was the ability to interface that data from EDI into ERP.  What needed to 
be done was reopening batch interfaces into order entry, etc.  Granted, 
due to the joke of EDI every interface would probably need to be 
customized, but a starting point was needed.  They chose to come out with 
yet another EDI package.

Another example was numerous attempts to develop their own development 
environment for client server computing.  Never did get off the ground, 
was cost prohibitive, and even if you used their Client/Server model you 
still had to have them do most, if not all, of the customization because 
they wouldn't release that part of the tool.

I thought their AS/SET tool was good at first.  But it failed to keep up 
with evolution of RPG, etc, and lost most, if not all, of it's advantages. 
 It couldn't function as a "cash cow".  Even though later releases of BPCS 
leaned heavily on AS/SET.  About the only enhancement to later versions of 
RPG is they use they do a CVTRPGSRC and then CRTBNDRPG.  And, other than 
to get around a few limitations regarding program size, etc that was only 
to say "See, we generate RPGIV now".  Yes, they still take 10 character 
AS/SET names and convert them down to 6 character RPG names before 
generating the original RPG source, that they then do the CVTRPGSRC on. 
And I can remember AS/SET customers that didn't even have BPCS.  I served 
as secretary of the AS/SET User Group.

I think SSA spent too much time generating pie-in-the-sky theories about 
development.

But, we still like their ERP package and are a happy customer with that.

Rob Berendt
-- 
"They that can give up essential liberty to obtain a little temporary 
safety deserve neither liberty nor safety." 
Benjamin Franklin 




<shannonjano@xxxxxxxxxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
09/22/2003 09:01 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
"Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
cc

Subject
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.
>
>
>


_______________________________________________
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.