In my role as IBM Fellow and CTO for the IBM Z and LinuxONE Ecosystem, I have the privilege of working closely with a wide range of ISVs building solutions on our platform. These ISVs span the same spectrum as our clients — from highly modernized teams using cloud‑native pipelines to organizations still relying on decades‑old processes.

Development modernization tools have been available for more than 25 years, and over the last 15 years we’ve made significant progress in aligning the experience of building cloud‑native applications with building applications for z/OS. In the last five years, the tooling has reached a point where the process can be essentially identical.

This was one of the key areas I focused on during my time in IBM’s CIO office: ensuring that z/OS applications used the same CI/CD pipelines, tools, and engineering practices as cloud‑native, SAP, and other distributed workloads. That experience taught me an important lesson — when processes aren't “broken,” teams often continue using them simply because they still work. But “broken” is the wrong word. The real issue is familiarity: the fact that something can be done the old way does not mean it should be done that way.

Technology evolves. Our development processes must evolve with it.

When teams adopt new tools and modern engineering practices, the benefits extend far beyond productivity. New team members onboard faster. Senior engineers discover new enthusiasm and renewed mastery. And collectively, teams gain insights and innovation simply not possible with outdated workflows. This is exactly what we saw in the CIO office.

What’s Holding Teams Back?

The most common refrain I still hear is:

“This is how we’ve always done it.”

In software development, that mindset is a red flag. Technology changes rapidly. If you aren’t paying attention to new practices and tools, you’re missing opportunities — not just for efficiency, but for competitive advantage.

That doesn’t mean chasing every shiny new thing. But it does mean actively observing the landscape and evolving your processes to stay current, productive, and relevant.

Why Git Matters

One of the most critical first steps is adopting Git as the single source of truth for your source code. Git is the most widely used source code management system in the world. Anyone graduating today already knows it. And even for those who don’t — including many with decades of experience — learning Git requires minimal effort.

In the IBM CIO office, teams that were initially reluctant ended up adopting Git successfully — and quickly. Most teams were able to complete training, migrate their code, and move into the pipeline within 8–12 weeks. This was after the initial pipeline foundation was built, but once that foundation existed, every subsequent team could move at speed. Learn more from https://ibm.github.io/z-devops-acceleration-program/docs/scm/

When I say “source code in Git,” I mean Git as the only source code manager — not Git mirrored with another system and not a Git façade over a proprietary SCM. You need one definitive, authoritative repository. See the post by Senthil for more information https://community.ibm.com/community/user/blogs/senthil-nathan/2023/02/21/why-only-git

Modern Git servers (GitHub, GitLab, etc.) provide enterprise‑grade auditability, governance, access controls, and integrations with tooling such as Z Open Enterprise Foundation and Git clients on z/OS.

Git is also foundational for AI‑assisted development — whether using Watson Code Assistant for Z or Project Bob or other AI development environments and MCP-based tools. These tools work best with Git‑based projects that you can load locally or into cloud‑based IDEs. Branching enables safe experimentation with AI‑generated ideas, documentation, and refactoring. Personal builds with DBB and isolated test environments let developers build and test freely without disrupting others.  Using a Git workflow, teams can establish approval requirements for changes satisfying even the most stringent audit requirements.  

Common Arguments Against Change — and Why They Fall Apart

Over the years, I’ve heard variations of the same objections:

• “Our build process is complex and deeply integrated into our system.”
• “Deployment is complicated — the existing tools handle it for us.”
• “We don’t know how the current system works anymore, but it still works.”
• “We’re afraid modernization might break something.”
• “Our current process works well enough; we don’t need to change.”

But “well enough” is not a strategy.

Especially not for systems as critical as those running on IBM Z — systems responsible for the world’s financial transactions, supply chains, government infrastructure, and mission‑critical business logic. Client and ISV applications play a central role in that ecosystem.

To sustain that impact for the next 50 years, we must bring in new talent, adopt new tools, and modernize how we build software. If we don’t evolve, we don’t just slow down — we fall behind.

No Time to Wait — The Future Is Already Here

IBM Z continues to power the world’s economy. And Client applications and ISVs remain essential to that mission. But innovation doesn’t happen by standing still. It happens by continuously modernizing — by adopting the tools, processes, and practices that empower teams to work smarter, faster, and with greater creativity.

Modernization isn’t about abandoning what works. It’s about ensuring it continues to work in a world that is rapidly changing.

If you haven’t begun your modernization journey, there is no time to wait. The tools are ready. The processes are proven. And the next generation of developers is eager to help build what comes next.

Let’s get started.  Join the community to learn more and share your experiences https://community.ibm.com/community/user/groupz?CommunityKey=f461c55d-159c-4a94-b708-9f7fe11d972b