Mainframe and Distributed: Uniting an IT House Divided
The current state of the mainframe reminds me of an important time in history before the Civil War, when Abraham Lincoln said:
“A house divided against itself cannot stand. I believe this government cannot endure, permanently, half slave and half free. I do not expect the Union to be dissolved—I do not expect the house to fall—but I do expect it will cease to be divided. It will become all one thing or all the other.”
Why Mainframe and Distributed Can’t Be a House Divided
DevOps calls for the breaking down of silos, for the unification of development and operations, and not just for one system but across all systems, mainframe and distributed. In DevOps, everything functions in unison at the same speed in order to improve the quantity and quality of functionality delivered.
Let this serve as a challenge to IT organizations that are still advocating for the division between mainframe and distributed or allowing that division to persist out of apathy, because a house divided cannot stand. As more applications span platforms, having mainframe and distributed running at different speeds—slow on the mainframe, fast on distributed systems—is only going to damage the customer experience your organization is trying to deliver through digital means.
The challenge, which is an exciting one, is to open the mainframe. Opening the mainframe means implementing the same Agile and DevOps best practices non-mainframe teams are likely already using—iterative development, earlier testing, Continuous Integration/Continuous Delivery and so on.
Instead of upholding the divide between mainframe and distributed, we need to become one thing, and I’m betting joining the “fast” side of the house will beat being on the “slow” side every time.
Innovating for Mainframe and Distributed DevOps
Mainframe and distributed should be on the same level, but you need a way to get the mainframe there. For a better idea of how to do this, I would read “Ten Steps to True Mainframe Agility,” our eBook that lays out a flexible plan involving many of the tools, processes and performance milestones you need to transform your mainframe.
The bulk of data and processing remains on the mainframe. It is the most efficient platform and the applications are right there with decades of business knowledge built in. What it lacks—not due to the platform but to poor practices and tools—is automation, visibility and integrations.
Rather than opting for the status quo, mainframe applications and tools must fit seamlessly into DevOps. They must adapt and become more open and flexible through REST APIs. Dashboards and management tools must see all of development, not just one side of it, and development must move from Waterfall to Agile, working with one IDE. Read a previous post of mine to get a list of the top 10 cross-platform and mainframe DevOps tools you should be using.
The mainframe “will become one thing or all the other.” The platform and the developers who work on it must adapt. Be on the side of change. Build one strong house for mainframe and distributed instead of fighting to maintain two.
Latest posts by Mark Schettenhelm (see all)
- Home Improvement Tech Debt - December 12, 2019
- Building a Better Mainframe Release Pipeline - November 7, 2019
- I Don’t Do New Year’s Resolutions—That’s Waterfall - December 31, 2018