| Mainframe as Fossilized
Relic There is a common perspective that
mainframe sites encounter when dealing with firms specializing in creating web
applications. The mainframe is treated at best as a necessary evil, sometimes with thinly
disguised disdain. Few web services firms really understand the mainframe environment, and
their preference is to treat any mainframe as a completely static black box.
In some cases, it makes good business sense to get off of the
mainframe platform, and therefore to freeze existing applications. For these sites,
treating the mainframe as a fossilized relic is at least reasonable, if a bit
disrespectful to those staff members who have invested a big chunk of their life in the
applications on that platform. For these sites, however, the application integration
question is actually more complex. Either legacy system processing is being moved
gradually to new applications on new platforms, or the old applications are being ported
to the new platform and modernized in the process. Either way, integrating an application
in transition is much more difficult, unless the new application or the modernization
process includes XML interfaces.
However, for many mainframe sites, and for most large
mainframe sites, the mainframe is not a fossil. Rather, it is the platform of choice for
sound business reasons, and is not static but undergoing regular maintenance on old
applications as well as new development. This essential fact must be understood and
respected by web services firms if they are to do the job that is needed rather than the
job they perceive or the one that best fits their business operational model.
Interestingly, if you understand both mainframes and web
services well, doing it right may be as easy or easier than current practice. This can
mean being willing to make minor changes to programs. Existing products and services based
on them go to great lengths to avoid recompiling a single program, and in the process may
add complexity, fragility and expense rather than reduce it as claimed by their respective
vendors. As the saying goes, if your only tool is a hammer, all problems look like a nail.
These middleware products have their place, and many of them
are very respectable implementations, but what is needed is a flexible approach that uses
middleware when that makes sense and changes programs when that is the better solution.
One implication of this is that the staff members who know the platform and the
application well must be closely involved in the design and implementation, and respected
for their knowledge and contributions. |
