There is an emerging phenomenon in IT: developers working on systems that are older than they are. While not unique to the mainframe (think Windows or Word), it is becoming more and more prevalent on the mainframe.
Think of it. As this developer was learning to walk the application was up and running. As this developer was learning to talk, the application was already being modified. As this developer learned to drive, people were already reluctant to make changes to the application because it wasn’t well understood. And now this developer is responsible for the application.
Why does this matter—as long as the application works? It matters in so many ways. For one, the application is very likely customer facing. The customer actually drives the execution of the application. And if something goes wrong with the application it is revealed, unvarnished, directly to the customer. The application is also very likely the system of record. So any mistake in the application may be reflected in the permanent record of that customer. And, depending on your business, that permanent record may be a loan amount, a credit balance, tax records or an insurance rating. These are not Google maps where one route is basically as good as another; these are numbers that people demand be right.
Even if the application produces correct output understanding how it works still matters. Think of the hummingbird and the butterfly. Each takes a different route from flower to flower. And each serves its own specific evolutionary directive. Because mainframe applications tended to be monolithic they were more like the butterfly, flitting from one objective to another. Today’s digital economy requires the mainframe application to be more like the hummingbird, direct to the next target.
So, fractured analogies aside, how does today’s developer gain a level of understanding of these mainframe applications? They can walk through each line of code. Not only is this painstaking (and painful) but it is also error-prone. Reading code does not give any indication of what code matters and what code doesn’t.
What if you could slow down and replay the execution of a given application, transaction or job step? See which programs are only executed once, which programs are called over and over, which programs do I/O. This is an unprecedented view into the application black box, allowing you to feel the personality of the program interactions and, more importantly, to understand and have confidence as you step in and begin to make changes.
Intrigued? Watch an example in action here.