I find rich ironies in what I am about to write, so give this as a
disclaimer. But for my own paper last year at HP World, I reread several
chapters of the now out-of-print book, "The Legacy Continues" (I also got
George Stachnik to sign my copy, and hope to get Mike Yawn's and, if
possible, Perry Sellars's). If you can find a copy, I think it is worth
reading, as a good starting point for thinking about these issues.

One if its ideas is from the Gartner Group's work on applications systems as
having three layers: presentation, application, and data / database. Parts
of those can live in different places between the client (or even
dynamically support multiple clients) and one or more servers. And migrating
those should be evaluated separately. Migrate for business reasons, not
because it would be fun to be able to view data on a Palm Pilot. There is an
awful lot that can be said about these considerations.

Some simple tasks like edit checks can be entirely contained in the
interface (for something simple and stable like dates or two letter state
abbreviations), or be validated by a table lookup against IMAGE, et al (for
data validation checks). This layer is the least likely to be profoundly
business specific (perhaps only because relatively little time is spent
designing it), but has to account for the nature of your business. Highly
trained or experience workers who know the application intimately are
probably not going to benefit from a pretty face, especially one that does
not reward this familiarity with efficiency, but only slows them down.

But my point in mentioning this, is this text also discussed evolving
existing layers, if it is in fact desirable to do so, so that, at least in
principle, one could migrate this or any other layer onto another platform.
Calls to data can be abstracted, so that a generic call to different
libraries or object code could be making that call to data stored in a
variety of formats, on one or more of several platforms. Then, if need be,
and when the time comes, it is easier to test and deploy such a migration.

Application logic is written in one or more languages. Is the language
portable? If so, to what platforms that could meet your business need better
than the 3000 already is? Is the code actually portable, or is it riddle
with system specific artifacts, some of which need not be system specific?
For certain HP intrinsics, there are platform neutral equivalents in your
language(s) of choice. For others, these can be isolated into platform
specific libraries of source code or object libraries. If the language is
not portable, what are you looking at for a conversion or rewrite? At that
point, you either need remarkable tools, and / or lots of time and money. It
may be more prudent to focus on the "lower hanging fruits" available in the
interface and data layers.

Once the learning for this evaluation is happening, and the analysis and
evaluation appears to have peaked on the 80 / 20 rule, a direction can be
set. Knowing most of the questions and having good answers gives you the
advantage of time. You can stay put, and avoid disrupting your business,
while you move to a more portable model. Should it become clear that the
3000 is not going to continue to meet the business needs, you can look at
why, and what you can or should do about it, and that transition should be
less painful, from the perspective of applications maintenance development
(it's the systems admin and TCO that will drive you insane). If it ain't
broke, you can always make it better.

Run it. Trust it. Evolve it.

Greg Stigers
http://www.cgiusa.com

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *