Second-Generation
Legacy to Web Strategies via XML
Part 2: Disenfranchising Middlewareby
Don Estes
 |
| 2.3.1 Step 1:
Normalizing the Legacy Environment Step 1
of the process requires that we move the applications from the hodge-podge legacy
environment of many sites to:
- A standard operating system environment, which in practice
means Windows 2000, Unix or IBM's MVS
- A standard 3GL language, which arguably means a target of
COBOL or C, but may be Java as well
- A SQL database target for all persistent data stores
- A standard teleprocessing monitor, such as CICS if using MVS
When considering the economics of what is sometimes called
"a giant step sideways", it is important to consider the costs, risks and
benefits of the total project. Although there is always a huge temptation to tinker along
the way, making bug fixes and other minor improvements, the strong economic advantage from
fully automating the process transforms these minor improvements into major sources of
increased cost and delay. When the project is properly done with automated language and
data access transformation tools, the result should be highly maintainable code with
roughly the same level of performance as before. The catalog of the desired improvements
can be readily implemented in the transformed sources when the process is complete.
Another lesson from Y2K is that the actual code changes are the smaller part of the
project. Testing the results can cost roughly double the cost of transforming the
programs: |
 |
The exact relationship varies depending on
technical and business risk factors, but the typical range for the cost of testing is from
50% to 80% of the total cost of the project. This means a ratio in the range of 1:1 to
4:1, with an average of roughly 2:1 as represented above. If this primary issue is not
thoroughly understood by all participants, the project is at risk before it starts. |
| Unfortunately, testing is not a
discipline that is well implemented across the board in IT. This is because testing an
application to prove that it is correct is extremely expensive, and as an industry we have
settled into the pragmatic mode of doing as much testing in advance of production as
management will allow, and fixing the rest in production. The result is that testing costs
are high because there are no economies of scale available in the process nor in
controlling the sources of error. Fortunately
for modernizing efforts, testing for a Step 1 Normalization project is a special case that
allows dramatic reductions in testing costs. This follows because we don't have to prove
that the applications are correct, only that they are equivalent to what is currently
executing in production. Equivalence testing, like language and other database access
transformations, can be readily automated, thereby producing the cost reduction while
bringing the accuracy as close to 100% as possible. This is not just theory. We are among
a small handful of companies that have perfected this test automation and offer it
commercially. Considering all the economic realities, we believe that anyone considering a
modernization project would be well advised to study test automation services in detail. |
|
|
