The Strategic Significance of Mainframes

Back in my undergrad days (in the ancient times, when we computed on stone tablets) our primary compute platform was a mainframe. In fact, the bulk of my coding activities occurred on the university's mainframe.

So it may surprise you that the bulk of my coding activities did not involve COBOL. Truth be told, most of it was Pascal and assembly language. Only once was I forced to code in COBOL - and that's because I took a class for familiarity.  

Years later, as an IT architect, the same statement was true: I coded C/C++ and Java on AIX and delivered web-enabled apps on WebSphere on a mainframe.

You see, mainframes are not synonymous with COBOL. In fact, the latest mainframe survey from BMC found that 82% of respondents are using Java in their mainframe environments. And if you were surprised by that, you should hold onto your chair because 48% of respondents use Agile and DevOps practices in their mainframe environment.

I'll let you recover for a moment before I go on.

The truth is that mainframes have a bad rap in IT. They are viewed as dinosaurs, when the reality is that they provide a significant source of computing power for many organizations. Computing power that's growing in use. Consider the BMC survey and you'll find that over the past year:

• 59% increased transaction volumes 
• 55% increased data volumes
• 46% increased their number of databases
• 45% increased the speed of application change  
  

Those numbers are important when you recognize that over 51% of respondents state that over half of their data resides on the mainframe. What's important about that is that data has gravity.

Let me say that again because it's really important - data has gravity.

As the F5 Office of the CTO noted recently, our ability to move data impacts just about everything about IT and applications. It affects where applications are deployed, how they're architected, and the application services that protect it by defending applications that access it. As data volumes increase, the weight of that data begins to pull applications to it - just like real gravity and its relationship to mass. Whether in the cloud or in traditional environments - or on the mainframe - data gravity is a real factor in where applications are ultimately deployed.

To see evidence of this in action, consider a Sapho study that explored reasons organizations weren't adopting cloud and were instead modernizing apps on-premises. In fact, over half (56%) said on-premises wasn't going anywhere and that less than 5% of their enterprise application portfolio would be making the migratory move to the cloud.  

Someone right now is shouting that this is technical heresy. But consider the reasons behind the rejection of "all cloud, all the time." First and foremost, it's based on the gravity of data. More than half (58%) of respondents to that survey said apps that touch critical data and systems must be on-premises. 

Now, if you go back and look at the BMC survey you'll note that over half of organizations are seeing data volumes on mainframes increase year over year. 

Because they're efficient and contrary to popular myth, they are compatible with DevOps and Agile and modern methods of computing. If I can deploy web-based apps on AIX on a mainframe, you can deploy microservices in a Kubernetes environment on them.

Mainframes are collections of compute resources and they're here to stay. The gravity of data - especially in this era of digital transformation - is going to keep them firmly fixed to the data center floor. That means the ability to modernize apps and environments through integrated tools and application services will continue to be critical in the coming years. 

In time we may look back and see that mainframes were actually more strategic than cloud - if we can stop associating mainframes with COBOL and recognize that it's the data and the apps - the software - that's important, not the kind of hardware on which it's deployed.