Author: Peter Wassel

Software delivery modernization should be done with care, especially with mission-critical mainframe apps. But for some, modernization will feel like a trip back to the future.

Mainframe applications are typically systems of record with high-value transactions, significant compliance risk and an essential need for stability and security. They’ve been running reliably, often for decades, with code changes made by teams of dedicated developers using time-tested interfaces like ISPF (green screens) and Eclipse integrated with mainframe-based source management tools—Endevor is the most widely used example.

So Why Modernize?

Three primary drivers of change are present:

• Business Agility: Digital disruption is generating an increased volume and velocity of business demands often resulting in cross-platform application architectures. It’s increasingly common to have cloud/mobile customer-facing apps calling back-end mainframe services for seamless experiences.
• Staffing: A talent crunch resulting from career mainframers retiring while traditional mainframe practices and tools lack appeal for the next generation. Backfilling is a challenge as next-gens would rather be using popular, cloud-native tools that offer broader career potential.
• Performance: DevOps adoption has raised the bar in terms of productivity, delivery velocity, quality, lead times, etc. The opportunity to achieve comparable performance levels with mainframe development is entirely possible but requires modernization.

The confluence of these drivers leads to an obvious conclusion—the time for modernizing mainframe application development is now. Version control is the foundation of software development, acting as the focal point with IDEs/code editors, Agile tools, DevOps automation tools (like code scanners and CI/CD orchestrators) and service management tools. This article focuses specifically on the adoption of Git as a critical enabler of modernization.

The Role of Git

The next generation of talent, typically millenials and Gen Zs, know and love Git. With 94% of professional developers viewing Git as a fundamental development tool per Stack Overflow, it has become the de facto standard for enterprise IT, eclipsing all alternatives. Built initially for open source development of Linux, it offers a decentralized model where devs can work independently in branches yet collaborate closely through pull requests, issue management, etc.

It has become so dominant that popular editors like VS Code have built-in Git capabilities. With the introduction of the free Code4z extension pack by Broadcom, VS Code and compatible tools (e.g., cloud-hosted GitHub Codespaces) are now viable options for mainframe developers, making Git adoption a natural, ‘parallel’ modernization opportunity. The Developer Cockpit Simulator illustrates the Git-ready experience using VS Code for mainframe application development.

Back to the Future

Beyond version control, leading Git platforms like GitHub and GitLab have expanded to become comprehensive DevOps platforms (e.g., GitHub Issues, Actions, Codespaces, Projects, etc.).  Yet the precedent for this evolution was set decades ago when Endevor was envisioned as an environment for development and operations with SCM at its core. Yes, DevOps before ‘DevOps’ ever existed. For many mainframers, seeing the Git version control tools evolve into comprehensive platforms comes with a distinct feeling of déja vu.

With automation that has stood the test of time, Endevor delivers code changes reliably and, with workflows optimized for the platform, does so very efficiently and securely. And while Endevor is continuously updated with new DevOps capabilities—including the recently introduced Dynamic Environments to facilitate developer self-service—there is no denying that Git is valuable from an enterprise perspective. In addition to attracting next-gens and facilitating onboarding, a Git experience empowers any developer, if authorized, to easily update mainframe apps. All they need is a few mainframe basics and experience with the relevant languages (e.g., COBOL, PL/I).

Back when the mainframe was the sole enterprise platform, a single, common experience was the norm, but IT evolved along many dimensions resulting in a sometimes disparate and siloed environment. Today, however, most developers are comfortable using multiple languages in a hybrid environment, so normalizing around a modern developer experience makes sense and brings things full circle.

Git-Native Approach

One option to take advantage of Git is to move source code to a Git enterprise server, but the inherent costs and risks associated with this approach should be carefully considered. Career mainframers are some of the most productive developers around and moving to a new paradigm will naturally be disruptive. In addition to changing workflows, this approach reestablishes build and deployment automation that has been working reliably for decades, which is both time-consuming and risky. Mainframe applications are often monolithic and complex with career mainframers’ expertise often filling gaps in documentation, so preserving this institutional knowledge should be a priority.

Career mainframers can, of course, learn Git, but training takes time. And as many are nearing the end of their careers, will they be motivated to embrace the change? Repo migration may have the unintended consequence of accelerating the retirement of a critical knowledge base. As Deloitte forewarns in their Modernization and the Aging Workforce paper, “Don’t underestimate the value of legacy coders.”

There are also costs associated with the migration—testing, documentation, training, project management—so the opportunity cost of porting code rather than investing in other high-priority business initiatives further qualifies this option.

With these factors taken into consideration, migration should start with applications that are both stable (e.g., infrequent change requests) and pose a low risk to the business (e.g., lower dependence on career mainframers).

A Git-native approach would require a specific tool such as Team Build, for example; a lightweight processor-based build engine that enables teams to collaborate natively using enterprise Git repositories while building on the z/OS platform. It is independent of Endevor and can be used for any build-and-ship needs for z/OS. It converts build logic in JCL and makes it maintainable off-platform with JavaScript.

Hybrid Git Experience

This ‘risk-managed’ option offers the benefits of Git—easier recruiting and onboarding, increased collaboration, etc.—while eliminating many of the costs and risks outlined above. With it, career mainframers continue working as they always have with existing tools and practices, without disruption, while next-gens use the tool they prefer, Git.

Endevor Bridge for Git enables the Git experience with Endevor continuing to serve as the main repository. It accomplishes this by synchronizing a ‘source control mirror’ on the Git enterprise server. With this option, those who prefer to use Git can do so while colleagues using native Endevor can work on the same codebase at the same time. They can use Eclipse, VS Code or VS Code-compatible cloud-based IDEs, which offer the added benefit of working in Git without a local copy of the code.

And with enablers like the Zowe CLI, modernizing-in-place offers the best of both worlds: Mainframe and off-platform tooling. For example, run Jenkins CI/CD pipelines for code scanning, testing and other functions off-host following a code change while allowing developers to continue to use the ISPF interface. To summarize, this option offers the advantages of the Git-native model without repo migration.

Recommendations

Due to the nature of mainframe applications, risk management is usually paramount so a thoughtful, pragmatic approach to the adoption of Git is recommended. Provide those career mainframers that are open to adoption with the time they need to embrace the technology by introducing Bridge for Git, for example. As organizations become more comfortable with the hybrid model and are satisfied they have enough Git-based developers with institutional knowledge of their codebase, they can identify apps to port to their Git enterprise servers.

At the other end of the spectrum, for companies with a Git-only imperative, one option is migrating an initial set of applications quickly using, for example, Team Build. However, a cold cut-over at the portfolio level could be excessively disruptive and it’s not recommended. Accelerated retirements and/or increased retention costs are a real risk, so a phased approach over time is the best approach. The key to success with Git adoption is recognizing it is a journey for the organization that requires a well-thought-out plan.

For a third-party perspective on the adoption of Git for mainframe apps, IDC has published an Infobrief, Git for Mainframe: Considerations for Enterprises, highlighting the opportunities and the challenges.

There are many paths to modernization, so take advantage of others who have blazed the trail.  But whatever the approach to Git adoption, younger team members should be prepared for a “We were doing that way back when” story or two.