The DevOps Transformation
The solution offers continuous software delivery and new tools for the mainframe
7/8/2015 12:00:30 AM |
By Alan Radding
In the end, everything comes down to software. Not MIPS, not I/O operations per second, not GB per second, not even data. It comes down to software, the stuff that does the work and processes the data and generates the results. For many mainframe shops, however, software is a cumbersome, even broken process.
That’s why DevOps is so important to the mainframe, especially the newest generation of mainframes like the IBM z13 system, which has the resources to handle a wide variety of things—transactions, mobile, social, security, machine to machine, analytics and more—concurrently. And as the Internet of Things (IoT) ramps up it will be another piece comprising the ever-increasing range of activities handled by mainframe software.
Broken Mainframe Development
You’ve heard the complaints: Four to six weeks to deliver minor application changes to customers, 70 percent of budgets must be devoted to maintenance and operations, 45 percent of customers report they experience production delays. Ouch.
The solution, according to Rosalind Radcliffe, IBM’s Chief Architect for Collaborative Lifecycle Management and DevOps, an IBM Distinguished Engineer and an IBM Academy Member, is DevOps on the mainframe
. It offers enterprises “the capability for continuous software delivery that enables them to seize market opportunities and reduce time to customer feedback,” she notes. As a result, DevOps has started resonating with enterprises that are demanding improved business outcomes.
Nationwide Insurance, for instance, became an early adopter of DevOps and already has reported significant gains. Specifically it has experienced a reduction in critical software defects by 80 percent and a 20 percent efficiency gain in its maintenance and support operations in just 18 months. That’s real money. Read the Nationwide Insurance case study
to learn more.
Mainframe shops, however, have been slow to follow the lead of Nationwide and other early adopters. Radcliffe realizes it is a major change given the far-reaching technology, process and cultural implications for them. “Many shops are still doing development as if it were 1987,” she says. “It is important that they start to modernize.”
DevOps is about continuous software development and deployment. That means continuous business planning, collaborative development, testing, release and deployment, monitoring, feedback and optimization in a continuous cycle. And it works.
In effect, DevOps is agile development combined with what amounts to agile deployment. In practice, developers work closely with the test and deployment groups. They engage in frequent communication in what amounts to a highly iterative process aimed to deliver the applications customers want fast, but with the high quality and security they expect from the mainframe. As a result, DevOps promises to enable organizations to seize market opportunities and reduce time to customer feedback.
Don’t be surprised when a DevOps proposal encounters pushback. If nothing else, DevOps is about deep change. The old waterfall methodologies, no matter how comfortable, simply have to go, insists Radcliffe.
DevOps makes traditional mainframe shops nervous. “They have been doing development the same way for 30 years,” notes Radcliffe. Yet, mainframe applications are extremely rock solid, and crashes and failures almost unheard of. That’s why the pushback.
She also tries to reassure those nervous mainframers that in the mainframe environment DevOps leads straight into continuous testing, not deployment. The testing can and should be as rigorous and extensive as is necessary to reassure that everything works as it should and anything that will fail has failed. Only then does it go into production. To do it thoroughly and fast, however, it needs to be automated.
If a team resists, Radcliffe can be blunt. The old way is not sustainable. Unless the mainframe development process changes, you won’t meet business needs. Enhancements and new apps won’t be delivered in time and opportunities will be missed while costs, already high, will get higher.
Your developers might be happy with Interactive System Productivity Facility but that’s a dead end. The team needs to think about new processes and new tools. Start by leveraging common Eclipse-based integrated development environments for all types of development. Also, it’s not just a COBOL world anymore; aim for broad coverage of runtimes, languages, compilers and platforms. Of course, one possibility could be IBM’s Cloud Managed Services. Then, start creating agile services from your existing mainframe assets.
Rational offers a set of tools starting with Blue Agility. IBM also offers an expanded set of tools acquired through acquisitions such as UrbanCode (release automation) and Green Hat (software quality and testing solutions for the cloud and more) that offer an integrated developer experience on open cloud platforms such as Bluemix to expedite DevOps collaboration, according to IBM. And there are many more DevOps-capable tools available through Eclipse.
It will take time to get your mainframe shop to DevOps for the mainframe. To begin, Radcliffe suggests a four-step process:
1. Define business objectives
2. Identify actions to fix immediate pain points
3. Execute on the actions
4. Measure results and iterate for continuous improvement
Radcliffe makes it sound simple. It’s harder than it seems but the payoff should be great. Besides, with the IoT bearing down on you and whatever comes next, you don’t have an alternative to DevOps on the mainframe.
Alan Radding is a Newton, Mass.-based freelance writer specializing in business and technology. Over the years his writing has appeared in a wide range of publications including CFO Magazine, CIO Magazine and Information Week. He can be reached through his website, technologywriter.com.