Identifying the Simple Application Hiding in Your Legacy Code

[#1]

In a previous post I wrote that at one time developers had to write a great deal of code that today would depend on prebuilt or commercial components.

There is one class of legacy program that represents the ultimate example of this - large apps that manipulate flat files for reporting purposes.  It is common in these instances to see extensive JCL devoted to sorting and copying, and COBOL programs doing substantial filtering, merging, and rewriting of data.  Understanding exactly what is happening is complicated by the use of multiple jobs and programs to paste this all together.  The fundamentals are actually fairly simple, once you work your way through the complex overlay of report processing that was written repeatedly.

I've seen programs that write out the table content, line by line, with a tag on the front indicating what type of report line it is. Then a final pass creates the actual formatted reports - kind of a primitive model, view, controller - with the model being the original input flat files, the controller being the multiple JCL and COBOL jobs filtering and massaging, and the view being that final COBOL program that emits 132 column lines suitable for your fan-fold, green bar paper.

Today, these programs would be built by linking a reporting tool to a relational database.  The endless JCL manipulations would be accomplished by predefined views or appropriate SELECTs.  And the results would be published to our corporate intranet with appropriate access controls.  Agility, in terms of our ability to produce new or modified reports, would be enormously enhanced and the labor costs associated with maintaining the reporting capability would drop by an order of magnitude.

This is a classic candidate for what Steve Woods has labeled asymmetrical transformation, which involves identifying those portions of your application that truly require custom coding and then ensuring that the rest are implemented by the appropriate COTS solution.