I recently read a blog where someone used a quote he once heard during a management meeting; “The mainframe can’t be THAT important, because it hardly ever comes up in management meetings..”. I have been in quite a few management meetings, and was under the impression that things that go WELL hardly ever make it to the agenda. Things that go wrong however are discussed all the time.
Unfortunately, it is in our nature to forget about the things that simply work. When was the last time you walked to your car and thought; “it’s really a miracle that this thing never breaks down!”. Does that make your car obsolete? Absolutely not!
But the fact is that, due to the reliable nature of our mainframes, many companies hardly ever realize how much of their mission critical applications still rely on that same mainframe. So how did we ever succeed in implementing an architecture that seems to live on forever?
To understand this, we have to go back to when the mainframe was the only computer we had. If an application, a database, or a piece of hardware failed, all Electronic Data Processing (as it was called back then) would stop and all connected terminals would go blank. The company simply stopped working. There was only one department to blame when something like this happened and this made the people working with the mainframe to who we are. Today, we still live by the rules we created in a time when a simple mistake was enough to stop companies from doing business. The disaster recovery procedures, the strict separation between development/test/QA environments, the bullet proof architecture and the long hours spent on defining the correct database structure all resulted in what we still see today; applications that have lived for 25 years or more and which survived many cycles of upgrades, enhancements and additions to allow integration with distributed applications.
Our mainframe applications live this long because we built them with care and surrounded them with the proper management procedures. And, perhaps most important, because the people who created, managed and maintained them understood the importance for the business.
So why am I stating the obvious? I am doing that because it is only obvious to US and not to anybody else. So here is the homework; let’s make a list of the 10-15-20 of the most important mainframe applications, their age, and what business processes are depending on them. If possible, explain how these applications grew and were enhanced over time. To make it stand out even more, find a picture on the internet that represents the year the application was built…. Nothing works better than a picture of Duran Duran in their early days to demonstrate how long ago this really was. Present this to your Mainframe Director, CTO, CIO, or anybody else who, after some thought, will realize that this is the exception these days, and not the rule. We simply don’t make applications with an expected lifespan of 20+ years anymore. Maybe even try and get a (non mainframe) architect to listen to it. You will not change the world, but maybe, it is yet another thing that will help people realize that, even though nobody ever mentions the mainframe, they do so for a good reason. Because it simply works….