As modernization initiatives accelerate across IBM Z environments, an increasingly common question is emerging:
If we already have Git, why do we need z/OS Change Tracker?
It is a fair question and exactly the question organizations should be asking.
Git has become the enterprise standard for source code management and modern software delivery. Across the industry, organizations are adopting Git, CI/CD pipelines, automation, and increasingly AI-assisted development to improve agility and accelerate innovation. IBM Z environments are no exception as organizations modernize application development practices and embrace DevOps. IBM itself continues to invest heavily in Git-based development, CI/CD pipelines, IBM Developer for z/OS, IBM Dependency Based Build (DBB), and automated deployment capabilities as part of its modernization strategy.
Modernization is unquestionably a positive step. Faster development cycles, improved collaboration, automation, and AI-assisted development can significantly improve productivity and accelerate innovation. However, modernization also increases the speed and volume of change occurring within mission-critical environments. As change velocity increases, organizations must answer a fundamental question:
Can we trust the environment?
Operational resilience, cyber resilience, business continuity, and regulatory readiness all depend upon maintaining a trusted operational state. Organizations must understand what changed, when it changed, who changed it, and whether the live production environment continues to reflect approved intent. This requirement extends beyond development teams and increasingly includes operations, security, audit, and compliance organizations as regulatory frameworks such as DORA, NIS2, and the NIST Cybersecurity Framework place greater emphasis on governance, operational controls, continuous monitoring, and evidence-based oversight.
Git plays a critical role in this process. Git excels at managing source code, developer collaboration, branching strategies, approvals, and deployment intent. It provides an authoritative record of what developers intended to deploy and serves as a foundational component of modern software engineering practices.
What Git does not do by itself is validate the state of the live operational environment.
This distinction is important because the operational environment evolves over time. Emergency fixes occur. Operational updates are made. Configuration changes are introduced. Maintenance windows happen. Occasionally, manual changes are necessary to address urgent business requirements or production issues. Over time, these activities can introduce differences between what was intended and what actually exists within the running environment.
Organizations still need to understand:
- What actually changed in production?
- Does the operational environment still reflect approved intent?
- Are runtime environments consistent across systems?
- What evidence exists to support governance and operational oversight?
- Can the environment be trusted for recovery, governance, and audit purposes?
These are not development questions. They are operational resilience questions.
As AI-assisted development and automation continue to accelerate software delivery, independent operational validation becomes even more important. The faster organizations change, the more important it becomes to verify that production environments remain trusted, consistent, and recoverable. Increased development velocity increases the need for operational assurance.
Modernization and operational assurance are not competing priorities; they are complementary disciplines. Git provides development governance by managing source, approvals, and deployment intent. Operational change intelligence provides operational assurance by validating what actually exists within the live environment and providing evidence to support governance, operational reviews, and audit activities.
Together, they enable organizations to move faster while maintaining confidence in the operational environment.
Organizations cannot recover, govern, or secure what they cannot trust. A trusted recovery requires a trusted environment, and governance increasingly requires evidence that operational reality continues to align with approved intent. As Frank De Gilio recently observed, "Compliance is not a calendar event." Compliance, governance, and operational resilience are continuous operational disciplines that require ongoing visibility and evidence rather than periodic point-in-time assessments.
In a Git world, operational reality still matters because Git manages code intent while operational change intelligence validates operational reality.
References
- IBM. IBM Z DevOps Acceleration Program. Available at: https://ibm.github.io/z-devops-acceleration-program/
- IBM Documentation. IBM Developer for z/OS Documentation. Available at: https://www.ibm.com/docs/en/developer-for-zos
- IBM Documentation. IBM Dependency Based Build (DBB) Documentation. Available at: https://www.ibm.com/docs/en/adffz/dbb
- IBM Documentation. IBM z/OS Change Tracker Documentation. Available at: https://www.ibm.com/docs/en/zos
- IBM Community. IBM Z DevOps and modernization blogs and articles. Available at: https://community.ibm.com/community/user/ibmz-and-linuxone
- European Union. Digital Operational Resilience Act (DORA). Available at: https://eur-lex.europa.eu/eli/reg/2022/2554/oj
- European Union. NIS2 Directive. Available at: https://eur-lex.europa.eu/eli/dir/2022/2555/oj
- National Institute of Standards and Technology. NIST Cybersecurity Framework (CSF) 2.0. Available at: https://www.nist.gov/cyberframework
- Frank De Gilio. Compliance Is Not a Calendar Event. IBM Community, May 26, 2026. Available at: https://community.ibm.com/community/user/blogs/frank-de-gilio/2026/05/26/compliance-is-not-a-calendar-event