Re: Anyone have thoughts on impending purchase of JBA by GEAC?

Sorry if I wasn't clearly presenting my (personal) viewpoint about development.
What was meant by coding in an artificial vacuum is the process where the coders
do not have contact with those requesting functionality and are perhaps lacking
in awareness of the general or specific concepts behind the programming specs.
An example might be similar to Style being written out of Sri Lanka as mentioned
in another email.

I have worked directly with JBA US for bespoke work and product enhancements, as
well as working with people brought to the US from JBA UK on product direction
and enhancement ( since version 2.1 ) and also have been in the "labs" at
Studley and Birmingham, discussed future direction and product architecture with
those responsible within JBA UK.  It seemed there was an enormous amount of
(billable) effort going back and forth to agree on functional specifications,
then it disappeared from the customers point of view.  Just because the
functional specs language looked good doesn't (and often didn't) mean that JBA
"got it right".  An analogy comes to mind of a story told one by one to a series
of people and seeing what came out at the other end.  I think that is a close
approximation other than the story is not finished till repeated from the end of
the line back to the first person.  All the testing, quality checks, etc. were
done within JBA, then the finished product delivered for use.  Since there was
no interaction between customer and coding, along with the wild card of the
customers environment and library list set-ups, not to mention PTF's applied
during the process, the first use of the functions (bespoke or product
enhancements) were fraught with problems unless inordinate time (mostly
billable) was taken in their introduction.  It may be especially provoking to
those who are not European based and wonder why the development process had
little sensitivity to their regional, national, or continental issues.  Fully
featured EDI transaction sets for most standards and Canadian Taxation issues
come to mind as examples.  (Wonder if anyone from GEAC is on this list?)

At one point not to long ago, over half of JBA's revenue was from North America,
no idea what it is now.  How many people in Europe know the intricacies of the
IRS, CST, PST, Multi-modal, zonal, class of service logistics of
intrastate/provincial transportation?  Fully functional ANSI X.12 EDI
transactions?  North Americans are not immune to multi-currencies as many
companies have Canadian, US, Mexican, and off-continent operations with their
own associated currencies.  I'll grant that smaller US based software developers
with few if none non-US issue based customers have diminished capabilities in
reference to the following email.

I'm not disagreeing, just trying to illustrate a different perspective.

It's completely understandable to one in position of authority within product
development that prioritization (and re-prioritization) is a fact of life.  What
is not as understandable is that the customer has no idea of where they were
placed in the queue, or if they made it at all.  Even the times release dates
were given (CA and GA) of the product itself, much less requested functionality,
they were seldom met.  ( "Where is 3.6?", "There will be no 3.6, just 3.5x until
4.0", etc.)

As far as the product getting to be too cumbersome if everyone got what they
wanted, the product, or better said, the products are already too cumbersome.  I
think mostly because of the underlying architecture which had been added onto
too many times instead of being redesigned.  Financials may be an exception to
that.  Even as of last year there were mod marks within the programs going back
to 1984.

Enough whining from me.  I'll just be happier if there is better communication
between JBA and the customers who are living with the product from day to day.
Better than between JBA and stockholders or future customers about the
product(s).

Often I have had better information, technical support, education, and
implementation assistance from third party providers than from JBA.  It ought
not to be.

As others have said, just my own opinion.

Randy Smith
OMRON Electronics, Inc.







I hope they do not bring the development to North America.  That would be a
mistake in my opinion.  Of course it would be great for American companies
but what about the rest of the world.  How many people in America know the
intricacies of Pan-European trade, multi-currency and accounting laws.  You
say the product has been coded in a vacuum.  I know from personal experience
(I was JBA's Financials Product Development Manager) that is just not true.
Just because they do not put something in the product doesn't mean they
didn't listen, it just means they perceived other requests as a priority.
Not every company can get exactly what the require in the standard product,
it would just be to big a cumbersome.  As you say, the BIG guys requests are
listened to much more, isn't that just a fact of life.  They spend more
money, they have more "clout".

Anyway, just my own personal thought and opinions.

Regards,

Mark.



+---
| This is the JBA Software Users Mailing List!
| To submit a new message send your mail to JBAUSERS-L@midrange.com.
| To subscribe to this list send email to JBAUSERS-L-SUB@midrange.com.
| To unsubscribe from this list send email to JBAUSERS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: doug333@aol.com.
+---