Bringing DevOps to your mainframe

The days of waterfall software development on a mainframe are coming to an end. It’s no longer tolerable for end users to have to wait two years for a new application to be written and delivered to a spec that, by then, is two years out of date. The inflexibility of the waterfall methodologies make them uncompetitive in the modern mainframe environment. What’s needed are the faster, more flexible, processes associated with Agile and DevOps ways of working. But what does an organization need to do in order to move from their old way of working to this new way – a way that can bring regular and frequent updates to any application to suit the needs of the users?

As well as talking about DevOps and Agile, mainframers will need to get to grips with the ideas of an app-centric economy and re-using APIs to speed development. And while this might seem like a big change to many more stable mainframe sites, it will bring them a win-win situation. It will be better for their end users – who these days are not necessarily employees. And it will allow them to manage an integrated approach to application development across a mainframe, cloud, mobile, and distributed environment.

Like anything, before embarking on this new way of working, it’s important that each organization is clear about its goals and what it hopes to achieve, and what their priorities are. There’s no point moving to a DevOps way of working just because everyone else seems to be. And this may also be the time to move away from ‘green screen’ environments to an Eclipse-style Integrated Development Environment (IDE).

As anyone who has tried to modify an existing mainframe application can tell you, they are probably quite complex (perhaps linking to other applications), they can be very large, and they probably don’t have very much documentation associated with them. You may be lucky in that you still have older mainframers onsite who understand the complexities of the applications running on their mainframes. Or you may not!

The first step is therefore to be able to understand an application’s runtime behaviour, and that includes the sequence and nature of each program call and each file and database I/O. Once some kind of workflow diagram can be created, it becomes possible for staff to start working on the application.

Once the ‘story’ of each application is understood, it becomes possible to have a conversation with the end users to see what their experience of using the application is like. And the fact that a particular application is being worked on, would indicate that the end users are experiencing some kind of performance issues. Using modern tools, these issues can be addressed. And because the cycle of development and end user feedback are so brief, it becomes possible to modify code until the processes that end users adopt match their needs, and the performance of the application also matches their needs.

These meetings between development staff and users are typically called scrums. They are often held with people standing rather than sitting because it encourages people to be brief. They allow developers to change their priorities, based on feedback from the users. It makes sense for ScrumMasters at a site to receive appropriate detailed training, and for members of the scrum to receive some training on how the new way of developing applications works.

Having spent time earlier getting an understanding of the processes used by the original application, as development work starts on it, it’s useful for DevOps team members to understand the operational metrics of the application so that they can measure the progress towards the team’s goals. They need to understand the application’s impact on MIPS/MSU-related costs, and recognize the importance of finding ways to reduce these by writing more efficient code that consumes less CPU.

As well as enhancing existing applications so that they work better for their users and so provide a business advantage for the organization, there is also a need to develop new applications quickly and reliably. With Agile Software Configuration Management, it becomes possible to synchronize the deployment of these new applications to their target environments (cloud, mobile, etc). If there are any deployment issues, these need to be identified quickly so that corrective action can be taken. The mainframe is usually the hub for mobile/Web/cloud applications, but for the developer, it can be considered as just another platform, and they need to understand all the different platforms that they are using.

With these ideas, it is possible make sure that your mainframe environment has a future, and bring speedy application development and renewal to multiple modern platforms.