Here is first draft of a paper I've been working on.
Pasted in from MS Word 6.0a, so hope it all made
the transition. I will try and ask about this at the
Management Roundtable at IPROF.
HP readers, before you think I'm just dinging you,
see the attaboy in the last couple paragraphs......
This is around 200 lines of email text and spaces.
Ken Sletten
=====================================
Software Support of the "Strategic Stepchildren":
What HP Needs to do:
Ken Sletten 360-396-2525 Rev: 95-04-02
By "Strategic Stepchildren" I am referring to a fairly long list of software
application development products, languages, and end-user tools that HP sold
to HP 3000 users over the last 10+ years, that have over time been derailed
from the marketing fast track and shunted onto one backwater siding or
another. Since we will refer to this group a lot, let us declare an
acronym-local to describe them: SS.
Even though the SS have been sidetracked and left behind by HP marketing,
that does not necessarily mean they have stagnated technically; in some
cases the opposite is true. But for those of us who have bet the datasystem
ranch on a few of these stepchildren, clearly the long-term outlook is a
major cause for concern in at least one important area: KEEPING UP WITH THE
PLATFORM (KUWP)..... KUWP as in ex-Surgeon General Koop, if you like....
Let us first ID some of the members of this family of stepchildren. This is
certainly not meant to be an all-inclusive list; readers can probably add
other poor relations. Also note that only items that are still carried in
the May 1994 HP 3000 Price Guide are mentioned; obsoleted products have
been omitted. If HP would like to dispute the inclusion of any product on
this list, the writer would be happy to listen to any such argument; my
perception is they all more-or-less belong:
Allbase/Query, Allbase/4GL, BRW, Business Basic, Dictionary,
Inform, MM, RPG, System Dictionary, Transact, VPLUS
SIDEBAR: There were other short-term high-flyers; things like Virtuoso;
that I won+t even get in to.
An important distinguishing feature for at least most of the above is that
that they are not off-the-shelf finished products that users run as-is;
they are tools used to implement user-specific production applications.
Which means that for any serious use, especially for the languages, the
initial cost and on-going software maintenance for the product is trivial
compared to the massive investment in end-user code developed over the
years.
It is also perhaps interesting to note that except for the ubiquitous VPLUS
and a couple others that I+m not sure of, I believe the installed base for
most of above SS is in the range of 1200-2000 sites. Since HP does not
officially disclose installed base numbers for products my 1200-2000 range
could be off a bit, but various bits and pieces from surveys and etc. lead
me to think it+s not too far off.
Especially for the RAPID products, I have some level of confidence that the
numbers for Transact and Inform are in the neighborhood of 1300-1500 sites
still paying software maintenance; perhaps a few hundred more than that for
Dictionary. The RAPID products are of course the ones in the above list
that are of particular interest to our site. But I would expect that
serious users of some of the other SS could tell similar stories of
commitment to particular products:
We have been developing a home-grown system for integrated management of all
facets of a complex, exception driven rework process for 10 years. Except
for INFORM reports, currently all the on-line code is in native mode
Transact; several hundred thousand lines worth; which translates to
something like $2,000,000+ invested in Transact development. I.e.: The
last thing we want to contemplate is needing to switch to something else;
or even to add something else in a major way, as far as a fully capable
server-based read-write interface to Image/SQL.
Upcoming evolution of our production system will not change the fact that
the core on the HP 3000 server will always be in Transact. We will probably
end up with a mix of:
(a) Selected parts of our system in a custom Winsock-compliant
client-server (C-S) system.
(b) Off-the-shelf windows-based C-S tools for ad-hoc PC reporting from
Image/SQL.
(c) QueryCalc for high-performance Postscript graphics and data output
from Image/SQL.
(d) Even with (b) and (c), INFORM will probably hang around for awhile;
users use it.
(e) The Transact - Dictionary pair, to do: Existing server-based
Image/SQL I/O processing; plus new server applications that SQL doesn+t do
very well (or can+t do at all); plus run the 80+ terminals we will still
have in the shop for years to come.... Yes, terminals.
If Congress doesn+t pull the plug on our program (no indication of that so
far), historical precedent and current projections suggest we will want to
run Transact on a 3000 for 10-15 more years. Note that this is
significantly longer than what appears to be the attention span of the
average software marketing department (sometimes it seems hard for HP
marketing to stay focused on any one "strategic direction" for one year, if
that long).
Given the current state of the 3000, we are pretty confident it will still
be around 10-15 years from now and longer. And we believe Image/SQL (or
whatever the next re-incarnation of the name for that product is) will still
be here. But where will Transact be ??
Transact and Dictionary and some of the other SS may still be "supported" in
10 years in one sense: At and after the Boston 1990 Interex conference HP
committed to "support Transact well into the next century" (note we are half
way to the next century, since the time of that statement). But the
question of just what that support will amount to has become very important
to the continued evolution of our in-house production system.
The plain fact is that complex systems like ours are NEVER finished unless
and until the day you totally turn them off; new development is always
going on at some level. We may call it software maintenance to avoid having
to call it new development, but it continues never-the-less.
And as the 3000 and Image/SQL continue to evolve and improve, we need to be
able to continue to make cost-effective use through Transact and Dictionary
of all the neat new features and capabilities that are incorporated in the
platform and the DBMS. Some of the "keeping up" examples that are and/or
will shortly be a problem:
Integral Image/SQL B-trees (coming soon); IEEE real numbers in Image/SQL
(already); Image/SQL dynamic detail dataset expansion (DDDX); ANSI
rounding, High-level sockets interface; Awareness of the HFS; Access
to the RPC part of DCE and interface definition language (IDL) routines
(coming soon to the 3000, I believe).
Of course SIGRAPID also has an additional outstanding list of what might be
called "insider" techie enhancements to the RAPID products, that do not come
under the KUWP heading; these insider enhancements will not be dealt with
further here. I say "of course" because users will never run out of
improvements they would like to see in the core products they use.....
Our site would like to respectfully but strongly suggest to HP and the user
community that support of core software development products, especially
languages, should include obvious KUWP features such as those listed above.
Users should not have to wait for the sometimes long, drawn out process to
bring all KUWP issues to the top of every individual product user
enhancement request list. Keeping up with the platform should be considered
part of basic support for any product that has a significant active
installed base.... And Transact users still qualify as "significantly
active".
Now in the case of Transact and most if not all of the other SS, expect HP
may come back with some version of: "But how are we going to pay for
enhancements to any of the SS ?? The user base is shrinking (or at least
not growing), and the income to support a higher rate of user requested
enhancements to the product(s) isn+t there"+
We could try and make somewhat of a special case argument for Transact and
Dictionary, in that for a short time around the Boston 1990 Interex
conference HP was perceived as clearly putting out the message that they
were planning to "freeze" Transact. User input on the spot and post-Boston
resulted in Transact being very much unfrozen and thoroughly thawed out;
however, the perceived temporary freeze clearly had a negative impact on a
number of large users of the RAPID products. Several instigated what were
in some cases painful moves to other products (i.e.: re-write your system).
The point is that HP cannot take a public course of action, however
temporary, that causes what were some committed users of a product(s) to
stop using it, and then later on look around and say, in effect: "Gee, the
user base for this product is dropping off. Users must be moving on to
other things for their own reasons. Guess we don+t have to worry about KUWP
any more in this case"+
I.e.: HP+s actions five years ago clearly contributed to what has still
only been a fairly slow erosion of the Transact installed base. The writer
is not trying to maintain that without the Boston on-off-on flip-flop by HP
that the user base would have doubled. But the negative impact of HP+s
action was not trivial either. So we would suggest that HP has a earned
itself a little extra responsibility with respect to KUWP on Transact.
Be that as it may, our site is willing to contribute to the "solution" to
this problem. The current monthly support charge for Transact and
Dictionary on our 957 is $47 each. Given the recent precedent of increasing
the monthly software support fee to bring Image/SQL to TurboIMAGE users, we
suggest and request that HP do the same thing with Transact and Dictionary.
After having invested over $2 million in Transact code, in our opinion
doubling the monthly support fee would be a small price to pay for keeping
the RAPID lab funded at a higher level, and thus allowing timely
incorporation of KUWP features in the products.
We realize that doubling the monthly support fee might cause a few more
casual and/or dormant users to drop Transact and Dictionary from their
software maintenance contracts. But even if another 25 percent of the
installed base dropped support on these products, there would still be a 50
percent overall increase in revenue to HP. And we doubt that anything close
to another 25 percent of the installed base would drop out.
Most sites who wanted to find a reason to drop Transact have probably
already done so (surely most system managers at least note what they are
paying for when they renew maintenance every year). Most that are left are
probably sites like ours that have made large investments in the product,
and continue to depend on it for mission-critical parts of their operation.
And if HP has to make one group or another of Transact users somewhat
unhappy (those who don+t need any new features and don+t want to pay more
for maintenance, versus active users who do), surely keeping active
customers happy should take precedence.
Plus if HP would incorporate the above KUWP features and perhaps a few other
requested enhancements to Transact, maybe HP could shock and pleasantly
surprise hard-core RAPID users by at least suggesting Transact to new
customers as a cost-effective host-based interface to Image/SQL, to
complement all those Windows SQL front end tools. There will always be a
need for complex batch processing on the 3000. And as far as I know, ANSI
SQL can not handle things like complex IF - THEN - DO - DOEND - ELSE - DO-
DOEND logic like Transact does, etc.
In closing would like to emphasize that non of the above is intended in any
way to minimize or disparage the large number of bug fixes and major
enhancements to NM Transact and NM Trandebug that have been delivered since
1990 by the HP Transact Lab. The extensive technical improvements the Lab
delivered over the last five years on the whole have been and continue to be
outstanding; first under Jim Sartain; then under Jim Brannan; and now
under Randy Roten.
What we are really agitating on is for HP management to make it possible for
the Transact Lab to continue to KUWP, and to deliver a good number of other
user-requested enhancements "well into the next century". This is our
definition of supporting the product. And we are willing to pay more to
help make this happen. How about it, HP ??
______________________________ END
|
