Why You Need to Let Developers Choose Your Company’s DevOps Tools
Mainframe teams looking to ditch their waterfall status quos are trading silos for collaboration and inactivity for speed. But when it comes to DevOps, thought leaders like CTO of DevOps Research and Assessment (DORA) Jez Humble say culture and application architecture are the lynchpins of transformation success.
I was fortunate to hear Jez speak on this at 2017’s Jenkins World in San Francisco, but it’s better that you read the 2017 State of DevOps Report, an annual analysis that’s become a DevOps beacon of sorts. Jez and DORA happen to be core contributors to the research and writing. Here’s what it says:
“It doesn’t matter if your apps are greenfield, brownfield or legacy—as long as they are architected with testability and deployability in mind, high performance is achievable. We were surprised to find that the type of system—whether it was a system of engagement or a system of record, packaged or custom, legacy or greenfield—is not significant. Continuous delivery can be applied to any system, provided it is architected correctly.”
Hence, your mainframe can be part of the buzz—Agile, DevOps, Continuous Integration, Continuous Delivery—if its applications can be quickly understood and made more modular (download the ebook, “10 Steps to True Mainframe Agility” to find out how). But you can’t stop here. There are other requirements that, even if they are secondary, could destroy your transformation efforts if left unmet.
You also need to change processes and use the right mainframe DevOps tools. Not only that, but how you choose those tools matters immensely.
Who’s Choosing Your Mainframe DevOps Tools?
Using the wrong tools can ultimately stifle your DevOps transformation success. In fact, a Compuware-commissioned Forrester report from 2016 found 22 percent of respondents struggle to accelerate mainframe application development and delivery due to “programming software that is unable to meet performance expectations,” and 21 percent struggle due to a “lack of tools to understand business rules and program logic.”
Tools matter, but who chooses what tools to use matters as well. From the 2017 State of DevOps Report:
“We discovered that teams that can decide which tools they use do better at continuous delivery. This is in contrast to teams that can use only those tools that are mandated by a central group. Teams that can choose their own tools are able to make these choices based on how they work, and the tasks they need to perform. No one knows better than practitioners what they need to be effective, so it’s not surprising that practitioner tool choice helps to drive better outcomes.”
This makes sense: the developers are the ones using the tools; empowering them to choose what DevOps tools they feel are best-of-breed correlates to their success. It also flies in the face of monolithic mainframe software vendors like IBM and CA, both of which follow outdated, procurement-led tool acquisition practices that result in developers being told which tools they can use based on price, licensing and budgets. If those force-fed tools are not easy-to-use and lack the necessary DevOps functionality, developers will resort to manual processes, which, almost by definition, prevent DevOps success.
Mainframe teams must be empowered with freedom of choice. Allowing your developers to choose from a variety of tooling options enables them to build a strong, cross-platform, multi-vendor DevOps toolchain that meets their most specific needs.
Of course, you should still maintain a core quality set of mainframe-specific DevOps tools that would probably serve you best if mostly coming from one vendor. But those should still integrate with other tools that are simply more qualified for certain mainframe-related or cross-platform and distributed tasks. We call this a mainframe-inclusive DevOps toolchain. Download our white paper to learn how to build one.
Here’s an example:
Building Your Mainframe DevOps Toolchain
Compuware has understood the importance of providing our customers with the above flexibility from the outset of our waterfall-to-Agile-and-DevOps transformation in 2014.
Of course, we began with a cultural transformation and a realization our applications needed to be more adaptable and understandable. Across the organization, we also updated our processes. But, eventually, we ran into issues because we didn’t have the right DevOps tools in place. Fortunately, we knew part of being Agile was empowering developers to discover and adopt the tools they needed to accomplish tasks more efficiently with higher quality.
One of our biggest obstacles to becoming fully Agile was our use of CA Endevor. It lacked the Agile source code management, release automation and deployment automation capabilities our developers required. They realized if they stayed with Endevor, Compuware would struggle.
Here’s a video that explains it a little more:
So, we listened to our developers and moved to ISPW—we liked it so much we bought the company. As a result, and along with many other developer-driven tooling changes, we’ve been churning out new feature functions and products every 90 days for 12 quarters and counting.
Culture and architecture are key to DevOps success, but your mainframe DevOps tools and how you choose them matters, too. Don’t force developers to settle for tools that don’t empower them to accomplish innovative tasks. They know better than anyone what’s best for your mainframe environment—the 2017 State of DevOps Report and our own history make that clear.
Latest posts by Paul Vallely (see all)
- Wherever You Are, Compuware Is There—Including IBM ZD&T - November 15, 2018
- Why You Need to Let Developers Choose Your Company’s DevOps Tools - September 19, 2017
- Are You Swimming Against the Rip Current of Mainframe Modernization? - August 10, 2017