| 2.3.2 Step 2: Becoming
e-Ready Step 1 leaves us with a
normalized application that is now maintainable, has flexible database interfaces, and
uses compatible technology platforms. Many fortunate sites will already be at this point,
and so begin with a head start. However, the application at this level still consists of
monolithic programs using character based terminal interfaces and tightly coupled data
interfaces, except for the SQL database. Worse, most legacy mainframe applications have a
significant batch window that must be eliminated in order to go to the 24x7 operation
required for globalization.
Step 2 addresses e-readiness using XML and componentization
strategies. Retrofitting XML onto a legacy application involves generating XML encoding
and decoding logic directly into application programs. This is a fairly straightforward
process, with one exception: data tags.
An XML document identifies each element of data by a data
tag. A basic XML document might derive tags from the program's datanames or the database
column names. There is nothing wrong with this, given that the tags are unique and
unambiguous within the namespace of the relevant XML dialect used at your site. However,
it is unlikely that your dialect will correspond to the industry standard dialect that you
will want to use for B2B data exchange, or even that it will correspond to the dialect of
another application with which you must exchange data under your own roof.
XML comes to the rescue with the XSLT translation process.
Once we have the dialect that is local to your application or to your site defined, we can
define an XSLT mapping to move from one to the other. This allows us to implement a true,
3-tier data exchange architecture that all but eliminates the historically onerous effort
of maintaining numerous 2-tier, tightly coupled data exchange formats with EDI partners.
Given a defined dialect, data tagging is not complete. We may
have defined what the tags will be, but the data fields in files, database tables, and
program record areas still have to be associated with those tags. Assigning the data tag
associations with legacy applications is similar to the date tagging exercise we went
through with Y2K. In that case, we had to find all the date fields within a program and
indicate unambiguously what each field's date format was. In this case, we have to tag all
the data names, not just the dates. Fortunately, we only have to tag the fields in record
layouts involved with data exchanges, and those only in the programs, which exchange data
outside the application system. As a result, the effort typically ranges from a few
minutes to a couple of hours per program, one time, for a small subset of an application
program library.
We briefly discussed above how an on-line program, once made
e-ready, would encode or decode an XML document when communicating with an XML aware
browser on a workstation. What is perhaps not obvious is that these programs are now free
standing components, and can as readily communicate with other programs, on or off
platform, as with a workstation. These online programs, which once were only character
based terminal programs, are now transformed to contain only business rules and XML
interfaces, with optional provision to conditionally invoke the character based interface
logic if they will sometimes still communicate with users on a green screen. If an XML
document arrives via a queue, via CICS, or another mechanism, the program neither knows
nor cares the source of the message. The output XML document returns via the same
transport.
If the output XML document is ultimately going to a
workstation, either a web server tier or the browser on the platform will have
presentation specifications contained in an XSL file. The XML data + the XSL presentation
is translated into HTML, which can be displayed by any browser or any other presentation
device, such as a Palm Pilot or a next generation digital telephone. We refer to this as
"scaleable presentation." Data access can similarly be isolated in I/O modules
accessible via XML document interchange, if required.
During the Step 2 process, a default XSL stylesheet is
generated from existing on-line presentation specifications. However, once generated, it
can be edited and localized as desired. For locations using the default XSL, it can be
resident on a server visible to all users. For locations that require localization for
language or other purposes, it can be resident on the individual workstation.
However, e-readiness involves a lot more than simply connecting your CICS applications to
a browser. Files and reports are exchanged as well as on-line transactions. If one program
needs to submit a transaction, it can format the necessary XML document and send it to the
on-line program, and obtain the response back. In this case, XSL files are unnecessary,
since there is no presentation involved.
For the cases where whole files or reports need to be encoded or decoded, this can be done
in two ways. Either the same XML encoding/decoding logic can be added to the programs
creating or reading the files, or standalone utilities can be created to post-process the
files in batch. Regardless, the process is similar.
The Step 2 e-readiness project is subject to the same cost,
risk and delivery time efficiencies of automation as we discussed for Step 1 Normalization
projects. Indeed, even the huge cost and risk gains available through automation of
testing apply here. It is for this reason that the move to native XML implementations will
ultimately disenfranchise middleware, because the user will get more for less - a
strategic solution for a tactical price. |
