An enterprise decides it needs to implement DevOps principles in its IT organization. A z/OS developer asks a simple question – “Why change? Everything works just fine now.”
The answer, according to DevOps evangelist and IBM Distinguished Engineer Rosalind Radcliffe, is simple: if you are not delivering business value (in other words, applications, products, and ideas) faster than your competitors, your existing development processes and practices don’t work as well as you think they do.
Skepticism is common in any organizational transformation, and DevOps is no exception, Radcliffe explained in a recent SHARE presentation. But, it’s also why it’s important for IT leaders to involve other stakeholders throughout the business in early discussions around the goals and expected benefits of a DevOps transformation from the very start.
DevOps is all about encouraging a collaborative work culture, along with supporting processes and practices, between an organization’s IT operation and development teams. Even though it’s an IT initiative, DevOps impacts many people outside of these departments, including:
- Senior executives – who can endorse a DevOps transformation as an organizational imperative, and support it through funding
- Internal auditors – who, if they know about changes to IT structures and processes ahead of time, can anticipate and advise on ways to ensure ongoing compliance and governance
- Development and operations – who will feel much better about their change in workflow if they know from the start that this transformation will make their lives easier
The objective of any DevOps transformation should be to empower businesses to deliver new ideas and solutions faster, Radcliffe said. A number of factors are forcing companies to pick up the speed and consider reorganizing IT accordingly. Those include:
- The need to incorporate predictive analytics to drive new revenue.
- The need to move quickly to resolve existing and emerging security threats.
- The need for cloud- and mobile-friendly solutions.
Still, moving toward DevOps means shaking up existing processes. That can feel uncomfortable to the mainframe team, said Radcliffe, which has depended on a long-time and stable development and deployment process for years – decades, even. These mature development teams are already comfortable with existing tools and processes, as well as highly integrated and monolithic applications.
Bringing mainframe in line with DevOps transformation involves first breaking teams out of the mindset that change inherently only creates risk, and that minimizing risk thus means reducing the number of changes that happen to a team or environment. In reality, the best way to reduce the risk of transformation is to focus on how you implement change – in other words, the processes and strategies that drive transformation.
Radcliffe recommends several strategies to make the transition easier, which includes providing a modern development environment that includes capabilities such as code rules and unit tests, and that supports developers with the proper time and resources to train and transition. She also stressed increasing the amount of automated testing that happens in mainframe development, including earlier tests and additional test environments, so that deployments aren’t delayed by waiting for quality assurance.
From a technology standpoint, mainframes aren’t incompatible with the speed and efficiency of DevOps. Any mainframe team can add more test environments, or take advantage of APIs to add in missing processes like regression testing that will modernize mainframe work. Ultimately, DevOps in mainframe is all about a cultural, rather than a technological, transition, and that’s an imperative that’s driven by business needs and organizational buy-in.
Watch Rosalind’s full presentation, “DevOps for the Enterprise” in the SHARE Content Center. You can also learn more about mainframe and DevOps in our recent blog posts: