Most knowledgeable mainframers always knew the mainframe was not only not dead; it would only get better, and would soon become indespensible, especially when paired with DevOps. I recently came across a blog that discussed this very topic. It was written by Marcel Hartog, an old friend and frequent contributor to our two mainfame magazines, Enterprise Executive and Enterprise Tech Journal. You can read his blog in its original form here.
About five years ago, I found myself standing in a hotel lobby at the end of a mainframe conference, deep in conversation with a group of mainframers.
Two members of the group explained to the rest of us why the mainframe was so stable, why it had to stay this way, and why this automatically meant that DevOps, Continuous Delivery and other "hypes" were out of the question. I must say, they confirmed many of my own thoughts and beliefs. I often wonder why we ("those who have been around, seen it and done it") have been able to run an extraordinarily stable and reliable platform for decades, without almost anyone in IT worrying about even it exists. If we can do it, and have been for years, surely "those who run the rest of IT" must be missing something. And maybe that is the reason why "they" think that adopting practices, like DevOps, may solve their problems?
But while the discussion lingered on, I realized that self-reflection was completely absent from the conversation. It felt like some of us were celebrating the greatness of the past, forgetting too that the world has not stood still in the past 15-20 years.
The Times, They Are a Changin’
Nobody can believe that doing things just as we did them when people still had XT's on their desks is good enough. It's not. The world has changed so dramatically, and keeps changing every day; whatever you did then, even if it still works, will never be the most optimal solution today! And consider the rising costs too—the average cost of a critical application failure per hour is now between $500,000 and $1 million, and average total cost of unplanned application downtime per year is between $1.25 billion and $2.5 billion!
For those that changed things, that implemented new technology—can you afford to support weekly release cycles? I bet not. Can you support Agile development and modern-day developer methodologies? I bet not. And yet, this is what your customers and your management expect of you.
At the same time, you may tell me that you have used a specific product for your Software Change Management (SCM) for more than 30 years, and if there ever was an example of DevOps working in the real-world, that was it. And, you are right. It was and still is, and what’s more, there are still a lot of things our distributed colleagues can learn from us.
But mainframes don’t run in isolation anymore. They are connected to everything else. In fact, IDC found the value of a connected mainframe could contribute $200M in incremental revenue per year. Changes cross-enterprise have an impact on what you run on the mainframe. So, the two have to meet. There is simply no other way. Large financial institutions have mission-critical, customer-facing front ends (apps, web-based internet banking) talking to their back-end (mainframe). Many other industries who own mainframes are doing the same and are looking for solutions to make all their different platforms look and feel as one, from a development perspective, but also from a management and security perspective.
Firms undergoing the transition will all have to adopt monthly release cycles before going to bi-weekly ones. Their trusted mainframe SCM solution will have to integrate with distributed solutions AND open source distributed solutions, as well to help manage all the components that make up business transactions—the key to a company’s success.
Mainframers Take the Lead
In today’s IT environment, we can’t wait for another team to integrate with us. Since many people do not even know that mainframes still exist, the change must come from within, from the mainframers themselves. We must open up, integrate and offer all the possible API's and interfaces to help people seamlessly integrate workloads and code cross-platform—regardless of what the code is, who works on it, and where it sits after we are done.
I know the purists will disagree with me, but as I see it, DevOps is nothing more than an efficient and intelligent way of working together, to make sure that the developers build with operations in mind, and that operations understands that it's their job to run systems as efficiently as possible. That requires a lot of common sense, intelligence, blood, sweat, tears, communication skills and last, but not least, integrated IT solutions that can halve the time to deploy from a baseline of 8-12 weeks. With numbers like that, you have to wonder; what are we waiting for.
Since we already covered SCM, let’s use this as an example. Business transactions these days are made up of many components; code written in different programming languages, multiple database and file definitions, JCL, Reports, Rexx scripts and more often from different vendors. A proper mainframe SCM solution also provides administrator traceability with conflict-of-interest user identification to pass every possible audit and supports role-based security to protect our most valuable assets (our applications).
Now, imagine a new developer who is tasked with adding some new functionality to a business transaction. Part of the transaction is written in Java and runs on a distributed platform, another part as a COBOL (or Java) transaction on the mainframe. We should not expect new developers to learn all the complexities of mainframe coding. Instead, we have to implement technology that allows them to work with their favorite IDEs like IntelliJ, lightweight text editors like Visual Studio Code/Sublime with simple extensions to create or modify Java programs or traditional mainframe assets such as COBOL, PL/1, C++ programs, etc. Build tools must help them run local unit tests, and once coding is done and tested, it has to be committed, using the familiar tools they are familiar with. This way, nothing moves from one platform to another, and it’s all seamless, no matter where (on what platform) things sit, allowing developers to use the tools they are familiar with.
Businesses don’t think in platforms or the expertise of their development staff. To them, a change is something that is needed to fix a problem or add new functionality. And enterprises are jumping aboard. One company moved to weekly release cycles, with 2,000 deployments per month. Truly staggering—considering the fact that it had millions of artifacts and thousands of developers.
For mainframers, but also for non-mainframers, this should be the same. The only way to support the requirements of the business is by implementing solutions, like the one described above. Not just on the development side, but also in areas like end-to-end application performance monitoring, security and automation.