No. But it has been a victim of friendly-fire.
I’m not sure that there is a headline relating to IT and enterprise software more cliché than the one at the top of this article. Cringeworthy? Perhaps, particularly If you’re in your 4th decade in the mainframe and enterprise software market as I am. But here’s the thing: our marketing guy manages our digital presence and monitors the analytics of our various campaigns and efforts. He tells me that not a week goes by that someone doesn’t conduct a Google search using the keywords “is the mainframe dead” and they end up on our site. It’s clear that we need to keep talking about it, and while the topic isn’t new, perhaps there are some new things to say about it.
This post is not meant as the latest rant from some old COBOL programmer in defense of the mainframe (especially since I’m an Assembly programmer). Let’s look at the data: what we see, such as the BMC’s 2018 mainframe research, continues to position the mainframe as a critically important enterprise computing platform. These predictions of the mainframe’s bright future are in line with what we see. In early December, I was onsite with a customer, a large enterprise in the top 100 of the Fortune 500. I heard firsthand of the long struggle to migrate off of the mainframe, at a cost of $500 million, with no results to show for it. The mainframe lives on at this organization, continuing to process the critical business transactions that are the lifeblood of the business.
The same week, I visited with a business partner about another top 100 Fortune 500 company that has the same story. It too has spent hundreds of millions of dollars across several years attempting to migrate off the mainframe, but to no avail. Does this mean that organizations like these are “stuck” on the mainframe? And if, so, is that a bad thing? The mainframe is still the biggest, baddest server on the block, highly scalable, and very secure. It has the characteristics that enterprise risk managers value highly. So, what’s the problem with the mainframe? Why are IT managers and enterprise architects continuing to discuss what to do with it?
I believe that the push some enterprises make to get off of the mainframe has less to do with the mainframe. Instead, it has more to do with well-meaning but misguided efforts to integrate it with things off the host. Anyone with a mainframe is operating in a de facto hybrid IT environment. Hybrid computing is the reality for an enterprise now, and in a hybrid world, integration is key! Over the decades, in the rush to get the mainframe to participate in the hybrid computing ecosystem, some poor integration choices and decisions were made. Integration layers were implemented, often in the middle-tier, that took overall response times from running natively on the host in milliseconds, to running in seconds through layers of ill-conceived integration technology. Too often, the assumption was made that the mainframe itself was at fault, not the layers of kludgy integration technology.
The result of these sub-optimal integration choices were taking applications that ran at warp speed on the mainframe and causing them to run on impulse power through poorly engineered integrations. The inevitable outcome was to lead IT and Business Unit managers to conclude that the mainframe was the problem and therefore it must go. This conclusion, however, is erroneous. The real problem is with the proximity of the integration and orchestration layer to the mainframe applications. As a rule, the closer this layer resides to the mainframe application(s), the better and more reliably the resulting integration performs.
This integration layer proximity rule is exactly why JavaScript, a powerful, standards-based integration technology, needs to run right inside of CICS, something our company pioneered more than a decade ago. In December of 2010, I wrote an article for Enterprise Systems Media, “JavaScript Tools for CICS/System z Integration: 10 Top Reasons” reasons that are even more valid today. Time has proven the value of JavaScript as an ideal integration and orchestration technology for CICS. Further validation comes from a longtime user and advocate of our JavaScript engine, who at the end of 2018 sent me an email to say that when we put JavaScript on the host, we “really did turn CICS into the world’s most bad-ass JavaScripting engine.”
Using JavaScript to make mainframe applications available via an API or as a web service requires no host application changes, is easy to develop and fast to deploy. Furthermore, the resulting integration performs well as recent CICS integration benchmarks confirm. When performance and reliability are at a premium, creating the integration to run right alongside the host application delivers the best outcome.
Enterprises will continue to rollout hybrid applications that require services, business logic, or data trapped within mainframe CICS applications. The mainframe has been unnecessarily marginalized through poor integration choices. JavaScript provides the best mechanism for allowing the mainframe to fully participate in the hybrid IT world. Adopting server-side JavaScript allows enterprise architects to use familiar technology to complete integrations that exploit the mainframe’s performance and reliability strengths.
Russ Teubner is a software entrepreneur and a pioneer in the integration of IBM mainframes with UNIX systems, TCP/IP networks and the web. Prior to co-founding HostBridge, he was the CEO of Teubner & Associates responsible for the development of four product lines and listed on Inc.’s 500 fastest growing private companies three times. Upon its sale to Esker SA, he stayed on for three years before founding HostBridge. Early in his career, Russ graduated from Oklahoma State University with a Bachelor’s in Management Science and Computer Systems and stayed on with the University’s computer center where he developed A-Net, a product allowing mainframes to access DEC applications. In addition to his OSU degree, Russ has participated in executive training programs including Stanford, Harvard and Pennsylvania’s Wharton Business School.
Russ is Chairman of the Board for Southwest Bancorp (NASDAQ: OKSB) and has seen it through tremendous changes. His 16 years at Southwest Bancorp has given him an insider’s view on the data processing needs of financial institutions, invaluable to his work at HostBridge.
Love the mainframe, love the principles you’re covering, and love what your company’s been tackling for years. I have to admit though, that I’ve now been terribly concerned about the mainframe’s future for about the last 4 years.
We’ve become the odd man (person) out in IT, and IBM and many of the other Z vendors have not been able to keep us as a relevant platform for applications. Developers can’t depend on their apps being able to seamlessly land on Z and just work, and the effort to port just seems less and less worthwhile. I fear the platform will stick around, but only as a niche option. Apps are the key to survival and they’re drying up. The decline will continue to be slow and slight, but we’re turning into BlackBerry and I’m not sure how to stop it. Containers? Little Endian (somehow)? Some unknowable IBM magic I hope?
Trey – Thanks for reading the article and for your comment. I hear you regarding being the “odd man out”. In one way or another, we see that phenomenon in many of the organizations we work with.
I do think IBM is working hard to transform the System z platform (i.e., the hardware) into a destination on which “apps can seamlessly land” (excellent choice of words). However, it’s another matter entirely as to whether this has anything to do with z/OS as the operating system environment. Perhaps this is stating the obvious, but the life span of z/OS in general (or specifically on a customer by customer basis) is a function of: (a) the ongoing business value of the apps currently running on the platform, (b) the ongoing cost of continuing to run those apps on the platform, and (c) the inherent business or technology “friction” in moving them to a different platform. We work with a number of extremely large mainframe shops who have spent hundreds of millions of dollars attempting to move complicated apps OFF the mainframe – and have very little to show for it. Bottom Line: It’s the “friction” part that organizations CONSTANTLY underestimate.
Sadly, in many organizations the zeal to move off the mainframe is frequently driven by a combination of factors that have nothing to do with business or technology fundamentals. Instead, it’s the way in which organizations have tried to “integrate” their mainframe apps into their modern distributed app architecture. The historical solutions adopted by some organizations were so bad that it’s no wonder they want to throw “the baby out with the bathwater”. But it’s actually quite rare that the problem is with the business app or even the cost deploying it on System z. In many organizations, it’s simply that over a period of time (perhaps decades) they have created layer after layer of adaptation/integration “stuff”. However, at some point, all this stuff acts like “plaque” in a coronary artery of your heart; it acts as a blockage.
Only IBM can solve many of the fundamental issues with making System z a platform on which apps can seamlessly land. In the meantime, we’ll continue to advocate for server-side JavaScript as the best way to deal with the “integration plaque”.
Russ, I agree with your assessment about integration being what slows things down and moving java script to the mainframe is a great idea. The problem is talent and desire. Selling the idea that we are going to teach these “old dogs” new tricks is a difficult sell when the current staff doesn’t show any enthusiasm for newer technology. It’s a much easier sell when a larger majority of the staff is excited for the next thing versus avoiding as much change as possible.
Rick – we’ve seen the reluctance you describe to learn something new. We’ve found that when we can get people to stick their “toe in the JavaScript pool” that both the mainframe COBOL programmers and the middle-tier developers/architects really like it. In fact, we’ve seen that when it comes to creating web services to access CICS applications, the COBOL programmers are the very best at doing this because their learning curve with JavaScript isn’t very steep, and they know the business logic of the mainframe apps. So yes, we’ve seen the lack of enthusiasm, but with some gentle persistence, we’ve been able to open the door and get people to walk through it. And, they almost always like it once they do.