However, it's part of a larger application with many other programs, each of which has a specific role, such as transferring money between accounts or withdrawing cash from your bank account or any number of other banking functions.
The problem is, a few months later, another program in that application had to be changed to allow for a new feature. And, the structure of your data had to be changed as well, so there was somewhere to keep track of that new feature.
Your program didn't need to use that new feature, but it did need the data, which now had more information, and therefore had a slightly modified structure. So your program had to be changed to use the new data structure.
But, you couldn't just change your program and put it into production and be done, because you had to wait until the data and all the other affected programs had also been changed, and then put it into production all at once.
Then, if even one of those programs turned out to have a significant error that hadn't been found during testing, it could become necessary to back out all the changed programs and data and revert to the previous version so production could keep running smoothly.
Meanwhile, you were also working on further changes to the program that would respond to future functions the application would offer - but not for several more months.
Keeping three concurrent versions of the same program, application, and data structure is quite normal on the mainframe. Often there may even be more. And it's necessary to keep track of each to avoid any possibility of confusion between versions.
The thorough testing of everything to minimize the possibility of problems before you "go production" is a core aspect of the Quality value. The connected value of Lifecycle Management allows for managing and tracking of multiple versions, to be able to develop one or more versions concurrently while having another in production, and even a previous one available in case a backout is needed.
Any true production computing platform needs these features, so that business activities aren't negatively impacted by the dynamic introduction of buggy programs and inability to back them out in a timely fashion.
Of course, such scrupulous practices have the paradoxical effect of making mainframes so reliable we take them for granted, forget they're there, and then focus on the squeaky-wheel platforms that are constantly crashing and having bugs, and give them all of our attention.
At IBM's System z Technical University at the beginning of October, I gave a presentation entitled "Getting a New Generation to a New Normal on the Mainframe." I had some great discussions in connection with that, and one of the concepts that emerged was the Warren Buffett approach as mapped to computing.
As you may be aware, Warren Buffett is one of the richest people in history, and he got that way by identifying and acquiring companies with excellent fundamentals but significantly reduced valuation.
Well, as evidenced by the benefits of Quality and Lifecycle Management, the mainframe is the only computing platform with such excellent fundamentals that we just take it for granted that it works. The problem is, we take it so for granted that we treat it like it doesn't exist. Talk about a reduced valuation!
So, to apply our analogy, if an organization wants to invest in a platform that will bring them a spectacular capacity to succeed - or if an IT professional wants to make such an investment in their career - there's nothing else out there like the mainframe, which has such amazing quality and so nearly invisible a reputation.
Talk about a ground floor opportunity for prosperity! After 48 years, the mainframe is poised for a tipping point of spectacular "overnight success" - will you and your organization be part of it?
No comments:
Post a Comment