How DevOps Changes the Meaning of ‘Mainframe Programmers’
We live in the age of DevOps, and no sector of IT — not even mainframes — remains unchanged. Here’s a look at how DevOps has reshaped the way mainframe programmers work.
As you probably know by now if you work in IT, DevOps is an approach to software development and deployment that emphasizes close collaboration between development teams and operations (or “IT Ops”) teams.
The driving idea behind DevOps is that by having the programmers who write applications work alongside the people who deploy and manage applications, each group can better understand the other’s pain-points and take steps to address them.
Although DevOps doesn’t totally blend together the roles of developers and IT Ops engineers, it does entail a fair bit of overlap between the responsibilities of each group. As a result, it requires developers to understand how applications are deployed and maintained in production. It also requires IT Ops staff to know something about how applications are written.
The DevOps movement has been most closely associated with software delivery teams who are working with next-generation technologies, like containers and microservices. These technologies can help to improve collaboration between different groups of IT teams by making applications more consistent.
DevOps and Mainframe Programmers
This does not mean, however, that DevOps has no role to play in the world of mainframes. Although mainframe programming may not be high on the list of topics that come to mind when most people think about DevOps, the ramifications of the DevOps philosophy apply to mainframes just as much as they do to any other type of IT infrastructure.
How, you ask? In two major ways, actually:
- Most obviously, DevOps requires mainframe programmers to branch out from roles that are limited strictly to programming, and to participate in administrative tasks, too.
- At a higher level, DevOps also means that programmers (or, for that matter, system administrators) who specialize in mainframes should also collaborate more closely with the rest of the IT organization.
That second point represents perhaps the most dramatic consequence of the DevOps movement for the mainframe. Traditionally, mainframe programmers have existed in their own worlds, relatively disconnected from the rest of the IT organization or other types of infrastructure, such as the cloud or on-premise x86 servers.
But what DevOps has reminded all IT professionals is that things work better when everyone collaborates. Otherwise, different groups end up working in “silos,” which stifle communication and collaborative potential.
No Mainframe Is an Island — And Neither are Mainframe Programmers
After all, no mainframe is an island. At some point, the data and applications that run on your mainframe almost certainly interact with other parts of your infrastructure.
True, the extent to which your mainframe is closely connected to other parts of the infrastructure varies depending on a variety of factors. If many of your mainframe workloads are running in Linux virtual machines, chances are that they more closely resemble, and are more directly compatible with, other applications hosted on commodity servers. This is less likely to be the case if you are still working primarily with COBOL applications on your mainframe.
Still, your mainframe does not exist alone. It may send and receive data from other systems for backup purposes. It may offload data to analytics tools hosted on commodity servers. Your mainframe probably relies on your networking infrastructure to connect to the world.
These are all good reasons to be sure that the job roles of your mainframe programmers are flexible enough to allow them to work more closely with the rest of the IT team — and to help other IT staff to understand and contribute to mainframes, too.
Download our 2018 State of the Mainframe report to learn about what this year has in store.