Chapter 18. Agile ALM on the Mainframe
The mainframe is alive and well. Many corporations have been planning the deprecation of their mainframe infrastructure for years, but yet the mainframe continues to be in use. Application lifecycle management (ALM) on the mainframe typically enjoys a specific workflow. Despite a culture that lends itself well to step-by-step defined procedures, ALM on the mainframe often falls short of its potential. Sure, we can specify steps of a process, and everyone accepts that process tollgates are necessary on the mainframe. But that does not mean that our mainframe processes help improve productivity and quality. It is essential that ALM on the mainframe be agile and help the team reach their goals and the business achieve success.
18.1 Goals of Agile ALM on the Mainframe
The goal of agile ALM on the mainframe is to define processes that help you deliver updates and bugfixes while achieving the highest levels of quality and productivity. On the mainframe you will likely focus on iteratively improving your existing processes rather than adopting a whole new approach. It is likely that you also have the goal of aligning your mainframe processes with ALM processes for distributed systems. We discuss aligning the ALM across the enterprise in Chapter 19. But this chapter focuses on being agile on your mainframe.
18.2 Why Is Agile ALM on the Mainframe Important?
The mainframe is still the trusty workhorse in many organizations, and many technology professionals work on projects that must include, in whole or in part, mainframe systems. Coming up with an effective strategy on your mainframe is very important, or else you will find that your ALM is constantly held up waiting for those Cobol copybooks to be updated.
Getting started with ALM on a mainframe will likely have you first reviewing many well-established processes and procedures. Mainframe technology professionals often have large binders of technical and process-related information, which are often out of date and seldom maintained. Instead we find that “tribal” knowledge exists both in terms of process and technical procedures. Approaching process improvement in a mainframe environment should always begin with a careful assessment of the current state.
18.3 Where Do I Start?
Mainframe developers and systems administration have long had well-established procedures. The issue that we hear frequently is that the mainframe deployment procedures are reliable and traceable, but far from agile. We usually start by examining the existing procedures, looking for ways to help the team accelerate their delivery without compromising quality.
With the support and help of skilled programmers and systems administrators, mainframe systems are often extremely efficient, crunching through vast amounts of data at a remarkably fast and efficient rate. We don’t doubt that distributed systems can also efficiently handle big data, especially when you have the luxury of limitless cloud-based resources. But existing infrastructures (and investments) on the mainframe in many cases would take years (and a large budget) to replace without any real return on investment. Mainframes are good at what they do, and it is often pragmatic to improve mainframe processes without trying to replace these complex and reliable systems.
We do find that mainframe technology experts often have great ideas on what can be improved; therefore, reviewing and adjusting mainframe processes is often an excellent approach. Even the smallest mainframe incurred a huge investment of time, money, and effort to set up, so there is a great deal of value in focusing on process improvement and achieving better quality.
Many organizations do not think of including the mainframe in their efforts to implement an agile ALM. We view this as a lost opportunity, and our goal is always to approach process improvement on the mainframe in a way that aligns with its culture and technology, while also harmonizing with processes in the distributed world.
18.4 DevOps on the Mainframe
We have had several engagements where we worked to implement DevOps on the mainframe. The procedures were usually well defined, and changing them was most certainly no small matter. We made some tangible improvements by reviewing and improving on the CLIST and REXX scripts, although this project felt more like a corporate anthropology study than a code review. Sometimes, we were able to make modest improvements in the deployment processes by working with stakeholders and soliciting their suggestions and relying largely upon their technical expertise and knowledge of history within the organization. Many of the suggestions were considered to be significant changes in the mainframe world, but normal and accepted controls in any Linux/Unix environment. We managed to improve communication and collaboration between developers and operators on the mainframe, although again these roles were well entrenched, and protocols for interactions had generally been in place for many years. Process improvement on the mainframe must focus on taking baby steps with robust communication and collaboration.
18.5 Conclusion
In many organizations, the mainframe is alive and kicking. You should always include the mainframe in your process improvement initiative, including designing and implementing the agile ALM. Remember to understand the mainframe from within its own culture and technology, while also working to align its processes with the rest of the organization, as we will discuss further in Chapter 19, “Integration across the Enterprise.”