IBM Z and LinuxONE IBM Z

For decades, IBM z/OS has been the workhorse of the enterprise world, powering mission-critical applications with unparalleled security and stability. But the IT landscape is changing. Businesses demand faster innovation and agility, which can seem at odds with the traditional, siloed approach of mainframe development.

Enter DevOps – a methodology that bridges the gap between development and operations. Many might think "DevOps on the mainframe? Isn't that an oxymoron?" Surprisingly, not! Here's how DevOps is reshaping IBM z/OS:

From Waterfall to Continuous Flow: Traditionally, mainframe deployments were slow and methodical. Code changes trickled down a waterfall of approvals, leading to lengthy release cycles. DevOps flips the script, promoting continuous integration and delivery (CI/CD). This means smaller, more frequent updates, allowing businesses to adapt and innovate faster.

Automation is King: DevOps is all about automation, and the mainframe is ripe for it. Repetitive tasks like provisioning environments, testing code, and deploying updates can all be automated, freeing developers to focus on bigger challenges. Tools like IBM Db2 DevOps Experience for z/OS are streamlining these processes.

Collaboration Conquers Silos: DevOps fosters a culture of collaboration between developers, operations teams, and security professionals. This breaks down traditional silos, leading to a more efficient and responsive IT organization.

Security Stays Paramount: Security is a top priority for z/OS, and that won't change with DevOps. DevOps tools can be integrated with existing security protocols, ensuring that automation doesn't come at the expense of data protection.

Modern Tools for a Modern Era: Gone are the days of cryptic green screens and arcane commands. Modern tools are making z/OS development more accessible. Version control systems like Git and user-friendly interfaces are attracting a new generation of developers to the mainframe.

The Future is Hybrid: DevOps isn't about replacing the mainframe, it's about integrating it seamlessly with other platforms. APIs and tools like z/OS Connect are making it easier for mainframe data to flow securely to cloud applications and other systems, enabling a truly hybrid IT environment.

The marriage of DevOps and IBM z/OS isn't just a fad, it's a sign of the platform's enduring relevance. By embracing agility, automation, and collaboration, z/OS is ensuring its place in the future of enterprise computing. So, the next time someone says "mainframes are dead," remember: the mainframe is evolving, and with DevOps as its co-pilot, it's ready to tackle the challenges of the modern IT world.

The Big Question: How long before the DevOps completely transforms the mainframe development, attracting a new generation of talent and solidifying z/OS's position as a cornerstone of the hybrid cloud future, or will the inherent complexities of the mainframe environment pose limitations on the full potential of DevOps?

I agree that it's not a question of whether it can be done. z/OS is all about automation and integration. In the past, automation was more concentrating on automating the operations rather than automating the deployment. That was the more pressing problem due to the relatively small and infrequent changes to the infrastructure. The required number of changes increased over time. I agree that most of the deployments can already be automated. All tools, features, and functionalities to automate z/OS deployments, middleware deployments, and application deployments are available. The main barrier is the mindset. Just because it can be done, you still need to it. It's like any other CI/CD pipleline and DevOps process. You just need to define and implement it. Therefore, the main question for me isn't about whether and how, but about who will be the first one to implement it and gain the competitive advantage in this area.

@Saurabh, are you implementing a DevOps process for IBM Z in your organization?

For decades, IBM z/OS has been the workhorse of the enterprise world, powering mission-critical applications with unparalleled security and stability. But the IT landscape is changing. Businesses demand faster innovation and agility, which can seem at odds with the traditional, siloed approach of mainframe development.

Enter DevOps – a methodology that bridges the gap between development and operations. Many might think "DevOps on the mainframe? Isn't that an oxymoron?" Surprisingly, not! Here's how DevOps is reshaping IBM z/OS:

From Waterfall to Continuous Flow: Traditionally, mainframe deployments were slow and methodical. Code changes trickled down a waterfall of approvals, leading to lengthy release cycles. DevOps flips the script, promoting continuous integration and delivery (CI/CD). This means smaller, more frequent updates, allowing businesses to adapt and innovate faster.

Automation is King: DevOps is all about automation, and the mainframe is ripe for it. Repetitive tasks like provisioning environments, testing code, and deploying updates can all be automated, freeing developers to focus on bigger challenges. Tools like IBM Db2 DevOps Experience for z/OS are streamlining these processes.

Collaboration Conquers Silos: DevOps fosters a culture of collaboration between developers, operations teams, and security professionals. This breaks down traditional silos, leading to a more efficient and responsive IT organization.

Security Stays Paramount: Security is a top priority for z/OS, and that won't change with DevOps. DevOps tools can be integrated with existing security protocols, ensuring that automation doesn't come at the expense of data protection.

Modern Tools for a Modern Era: Gone are the days of cryptic green screens and arcane commands. Modern tools are making z/OS development more accessible. Version control systems like Git and user-friendly interfaces are attracting a new generation of developers to the mainframe.

The Future is Hybrid: DevOps isn't about replacing the mainframe, it's about integrating it seamlessly with other platforms. APIs and tools like z/OS Connect are making it easier for mainframe data to flow securely to cloud applications and other systems, enabling a truly hybrid IT environment.

The marriage of DevOps and IBM z/OS isn't just a fad, it's a sign of the platform's enduring relevance. By embracing agility, automation, and collaboration, z/OS is ensuring its place in the future of enterprise computing. So, the next time someone says "mainframes are dead," remember: the mainframe is evolving, and with DevOps as its co-pilot, it's ready to tackle the challenges of the modern IT world.

The Big Question: How long before the DevOps completely transforms the mainframe development, attracting a new generation of talent and solidifying z/OS's position as a cornerstone of the hybrid cloud future, or will the inherent complexities of the mainframe environment pose limitations on the full potential of DevOps?

I couldn't agree more. This is not about tools, it's about mindset.

We're working actively to change how people think about the development process on the mainframe, but it's a big cultural change for many.

Changing tools is easy - changing culture is hard. 
This is why we're using CoP's to show that it's not just some intangible dream, but something real that brings actual value.

Setting up a learning environment that allows for failure and that initial drop in productivity is key.
Good knowledge base (instructions and training) and support on the journey (DevX team) will make it powers of magnitude easier to motivate that change.

I agree that it's not a question of whether it can be done. z/OS is all about automation and integration. In the past, automation was more concentrating on automating the operations rather than automating the deployment. That was the more pressing problem due to the relatively small and infrequent changes to the infrastructure. The required number of changes increased over time. I agree that most of the deployments can already be automated. All tools, features, and functionalities to automate z/OS deployments, middleware deployments, and application deployments are available. The main barrier is the mindset. Just because it can be done, you still need to it. It's like any other CI/CD pipleline and DevOps process. You just need to define and implement it. Therefore, the main question for me isn't about whether and how, but about who will be the first one to implement it and gain the competitive advantage in this area.

@Saurabh, are you implementing a DevOps process for IBM Z in your organization?

For decades, IBM z/OS has been the workhorse of the enterprise world, powering mission-critical applications with unparalleled security and stability. But the IT landscape is changing. Businesses demand faster innovation and agility, which can seem at odds with the traditional, siloed approach of mainframe development.

Enter DevOps – a methodology that bridges the gap between development and operations. Many might think "DevOps on the mainframe? Isn't that an oxymoron?" Surprisingly, not! Here's how DevOps is reshaping IBM z/OS:

From Waterfall to Continuous Flow: Traditionally, mainframe deployments were slow and methodical. Code changes trickled down a waterfall of approvals, leading to lengthy release cycles. DevOps flips the script, promoting continuous integration and delivery (CI/CD). This means smaller, more frequent updates, allowing businesses to adapt and innovate faster.

Automation is King: DevOps is all about automation, and the mainframe is ripe for it. Repetitive tasks like provisioning environments, testing code, and deploying updates can all be automated, freeing developers to focus on bigger challenges. Tools like IBM Db2 DevOps Experience for z/OS are streamlining these processes.

Collaboration Conquers Silos: DevOps fosters a culture of collaboration between developers, operations teams, and security professionals. This breaks down traditional silos, leading to a more efficient and responsive IT organization.

Security Stays Paramount: Security is a top priority for z/OS, and that won't change with DevOps. DevOps tools can be integrated with existing security protocols, ensuring that automation doesn't come at the expense of data protection.

Modern Tools for a Modern Era: Gone are the days of cryptic green screens and arcane commands. Modern tools are making z/OS development more accessible. Version control systems like Git and user-friendly interfaces are attracting a new generation of developers to the mainframe.

The Future is Hybrid: DevOps isn't about replacing the mainframe, it's about integrating it seamlessly with other platforms. APIs and tools like z/OS Connect are making it easier for mainframe data to flow securely to cloud applications and other systems, enabling a truly hybrid IT environment.

The marriage of DevOps and IBM z/OS isn't just a fad, it's a sign of the platform's enduring relevance. By embracing agility, automation, and collaboration, z/OS is ensuring its place in the future of enterprise computing. So, the next time someone says "mainframes are dead," remember: the mainframe is evolving, and with DevOps as its co-pilot, it's ready to tackle the challenges of the modern IT world.

The Big Question: How long before the DevOps completely transforms the mainframe development, attracting a new generation of talent and solidifying z/OS's position as a cornerstone of the hybrid cloud future, or will the inherent complexities of the mainframe environment pose limitations on the full potential of DevOps?

I agree that it's not a question of whether it can be done. z/OS is all about automation and integration. In the past, automation was more concentrating on automating the operations rather than automating the deployment. That was the more pressing problem due to the relatively small and infrequent changes to the infrastructure. The required number of changes increased over time. I agree that most of the deployments can already be automated. All tools, features, and functionalities to automate z/OS deployments, middleware deployments, and application deployments are available. The main barrier is the mindset. Just because it can be done, you still need to it. It's like any other CI/CD pipleline and DevOps process. You just need to define and implement it. Therefore, the main question for me isn't about whether and how, but about who will be the first one to implement it and gain the competitive advantage in this area.

@Saurabh, are you implementing a DevOps process for IBM Z in your organization?

For decades, IBM z/OS has been the workhorse of the enterprise world, powering mission-critical applications with unparalleled security and stability. But the IT landscape is changing. Businesses demand faster innovation and agility, which can seem at odds with the traditional, siloed approach of mainframe development.

Enter DevOps – a methodology that bridges the gap between development and operations. Many might think "DevOps on the mainframe? Isn't that an oxymoron?" Surprisingly, not! Here's how DevOps is reshaping IBM z/OS:

From Waterfall to Continuous Flow: Traditionally, mainframe deployments were slow and methodical. Code changes trickled down a waterfall of approvals, leading to lengthy release cycles. DevOps flips the script, promoting continuous integration and delivery (CI/CD). This means smaller, more frequent updates, allowing businesses to adapt and innovate faster.

Automation is King: DevOps is all about automation, and the mainframe is ripe for it. Repetitive tasks like provisioning environments, testing code, and deploying updates can all be automated, freeing developers to focus on bigger challenges. Tools like IBM Db2 DevOps Experience for z/OS are streamlining these processes.

Collaboration Conquers Silos: DevOps fosters a culture of collaboration between developers, operations teams, and security professionals. This breaks down traditional silos, leading to a more efficient and responsive IT organization.

Security Stays Paramount: Security is a top priority for z/OS, and that won't change with DevOps. DevOps tools can be integrated with existing security protocols, ensuring that automation doesn't come at the expense of data protection.

Modern Tools for a Modern Era: Gone are the days of cryptic green screens and arcane commands. Modern tools are making z/OS development more accessible. Version control systems like Git and user-friendly interfaces are attracting a new generation of developers to the mainframe.

The Future is Hybrid: DevOps isn't about replacing the mainframe, it's about integrating it seamlessly with other platforms. APIs and tools like z/OS Connect are making it easier for mainframe data to flow securely to cloud applications and other systems, enabling a truly hybrid IT environment.

The marriage of DevOps and IBM z/OS isn't just a fad, it's a sign of the platform's enduring relevance. By embracing agility, automation, and collaboration, z/OS is ensuring its place in the future of enterprise computing. So, the next time someone says "mainframes are dead," remember: the mainframe is evolving, and with DevOps as its co-pilot, it's ready to tackle the challenges of the modern IT world.

The Big Question: How long before the DevOps completely transforms the mainframe development, attracting a new generation of talent and solidifying z/OS's position as a cornerstone of the hybrid cloud future, or will the inherent complexities of the mainframe environment pose limitations on the full potential of DevOps?

Absolutely agree with your perspective Michael. It's evident that z/OS is designed for automation and integration, and while the focus historically leaned towards operational automation, the landscape is evolving. With the increasing frequency of changes to infrastructure, there's a clear shift towards automating deployment processes. The tools and capabilities to automate deployments across z/OS, middleware, and applications are readily available. However, as you rightly pointed out, the primary obstacle often lies in the mindset. Implementing automation requires a proactive approach and a shift in mindset towards embracing change and innovation. It's akin to any other CI/CD pipeline or DevOps initiative – the key lies in defining and executing the strategy. The real question now becomes not about the possibility or methodology but rather about seizing the opportunity. Who will be the trailblazer to implement and leverage this automation, thereby gaining a competitive edge in this space? It's a compelling challenge waiting to be embraced.

Yes, implementing a DevOps process for IBM Z, automating development build across different stages with continuous testing process

I agree that it's not a question of whether it can be done. z/OS is all about automation and integration. In the past, automation was more concentrating on automating the operations rather than automating the deployment. That was the more pressing problem due to the relatively small and infrequent changes to the infrastructure. The required number of changes increased over time. I agree that most of the deployments can already be automated. All tools, features, and functionalities to automate z/OS deployments, middleware deployments, and application deployments are available. The main barrier is the mindset. Just because it can be done, you still need to it. It's like any other CI/CD pipleline and DevOps process. You just need to define and implement it. Therefore, the main question for me isn't about whether and how, but about who will be the first one to implement it and gain the competitive advantage in this area.

@Saurabh, are you implementing a DevOps process for IBM Z in your organization?

For decades, IBM z/OS has been the workhorse of the enterprise world, powering mission-critical applications with unparalleled security and stability. But the IT landscape is changing. Businesses demand faster innovation and agility, which can seem at odds with the traditional, siloed approach of mainframe development.

Enter DevOps – a methodology that bridges the gap between development and operations. Many might think "DevOps on the mainframe? Isn't that an oxymoron?" Surprisingly, not! Here's how DevOps is reshaping IBM z/OS:

From Waterfall to Continuous Flow: Traditionally, mainframe deployments were slow and methodical. Code changes trickled down a waterfall of approvals, leading to lengthy release cycles. DevOps flips the script, promoting continuous integration and delivery (CI/CD). This means smaller, more frequent updates, allowing businesses to adapt and innovate faster.

Automation is King: DevOps is all about automation, and the mainframe is ripe for it. Repetitive tasks like provisioning environments, testing code, and deploying updates can all be automated, freeing developers to focus on bigger challenges. Tools like IBM Db2 DevOps Experience for z/OS are streamlining these processes.

Collaboration Conquers Silos: DevOps fosters a culture of collaboration between developers, operations teams, and security professionals. This breaks down traditional silos, leading to a more efficient and responsive IT organization.

Security Stays Paramount: Security is a top priority for z/OS, and that won't change with DevOps. DevOps tools can be integrated with existing security protocols, ensuring that automation doesn't come at the expense of data protection.

Modern Tools for a Modern Era: Gone are the days of cryptic green screens and arcane commands. Modern tools are making z/OS development more accessible. Version control systems like Git and user-friendly interfaces are attracting a new generation of developers to the mainframe.

The Future is Hybrid: DevOps isn't about replacing the mainframe, it's about integrating it seamlessly with other platforms. APIs and tools like z/OS Connect are making it easier for mainframe data to flow securely to cloud applications and other systems, enabling a truly hybrid IT environment.

The marriage of DevOps and IBM z/OS isn't just a fad, it's a sign of the platform's enduring relevance. By embracing agility, automation, and collaboration, z/OS is ensuring its place in the future of enterprise computing. So, the next time someone says "mainframes are dead," remember: the mainframe is evolving, and with DevOps as its co-pilot, it's ready to tackle the challenges of the modern IT world.

The Big Question: How long before the DevOps completely transforms the mainframe development, attracting a new generation of talent and solidifying z/OS's position as a cornerstone of the hybrid cloud future, or will the inherent complexities of the mainframe environment pose limitations on the full potential of DevOps?

Geez, there's nothing like retconning to make your point.

All of the major mainframe source code management tools (SCMs) have had automated build and deploy capabilities that would work for unit test, QA, pre-prod, prod, etc. within the product for decades.  By "major," I mean:  Endevor, Librarian, Panvalet, ISPW and SCLM.  There are obsolete others out there (e.g., BIM-EDIT, Alchemist), and even these have long had a phase oriented build and deploy capability.  This functionality was appropriate for the environments and (especially) the constraints it was designed for:  very expensive compute and hyper-expensive storage, where every cycle and byte was counted and managed.  Deployment is generally to a small set of known environments and production deployment could be to a single set of libraries, even for hundreds or thousands of application instances. 

So-called "modern" DevOps was designed for a completely different set of constraints:  cheap compute and cheaper storage, automated, just-in-time provisioning of the underlying test environment and a need to deploy production to hundreds, if not thousands of server instances.

I fully agree that for many reasons, mainframe installations should adopt the tools and processes that have been developed to solve the scaling problems endemic to distributed software deployment.  None of those reasons includes, "because there aren't automated processes in place today."  The primary driver of resistance to these new tools is not, "we like working with stone knives and bearskins," more, "what's the value of changing these processes that have worked for decades?"  

Absolutely agree with your perspective Michael. It's evident that z/OS is designed for automation and integration, and while the focus historically leaned towards operational automation, the landscape is evolving. With the increasing frequency of changes to infrastructure, there's a clear shift towards automating deployment processes. The tools and capabilities to automate deployments across z/OS, middleware, and applications are readily available. However, as you rightly pointed out, the primary obstacle often lies in the mindset. Implementing automation requires a proactive approach and a shift in mindset towards embracing change and innovation. It's akin to any other CI/CD pipeline or DevOps initiative – the key lies in defining and executing the strategy. The real question now becomes not about the possibility or methodology but rather about seizing the opportunity. Who will be the trailblazer to implement and leverage this automation, thereby gaining a competitive edge in this space? It's a compelling challenge waiting to be embraced.

Yes, implementing a DevOps process for IBM Z, automating development build across different stages with continuous testing process

I agree that it's not a question of whether it can be done. z/OS is all about automation and integration. In the past, automation was more concentrating on automating the operations rather than automating the deployment. That was the more pressing problem due to the relatively small and infrequent changes to the infrastructure. The required number of changes increased over time. I agree that most of the deployments can already be automated. All tools, features, and functionalities to automate z/OS deployments, middleware deployments, and application deployments are available. The main barrier is the mindset. Just because it can be done, you still need to it. It's like any other CI/CD pipleline and DevOps process. You just need to define and implement it. Therefore, the main question for me isn't about whether and how, but about who will be the first one to implement it and gain the competitive advantage in this area.

@Saurabh, are you implementing a DevOps process for IBM Z in your organization?

For decades, IBM z/OS has been the workhorse of the enterprise world, powering mission-critical applications with unparalleled security and stability. But the IT landscape is changing. Businesses demand faster innovation and agility, which can seem at odds with the traditional, siloed approach of mainframe development.

Enter DevOps – a methodology that bridges the gap between development and operations. Many might think "DevOps on the mainframe? Isn't that an oxymoron?" Surprisingly, not! Here's how DevOps is reshaping IBM z/OS:

From Waterfall to Continuous Flow: Traditionally, mainframe deployments were slow and methodical. Code changes trickled down a waterfall of approvals, leading to lengthy release cycles. DevOps flips the script, promoting continuous integration and delivery (CI/CD). This means smaller, more frequent updates, allowing businesses to adapt and innovate faster.

Automation is King: DevOps is all about automation, and the mainframe is ripe for it. Repetitive tasks like provisioning environments, testing code, and deploying updates can all be automated, freeing developers to focus on bigger challenges. Tools like IBM Db2 DevOps Experience for z/OS are streamlining these processes.

Collaboration Conquers Silos: DevOps fosters a culture of collaboration between developers, operations teams, and security professionals. This breaks down traditional silos, leading to a more efficient and responsive IT organization.

Security Stays Paramount: Security is a top priority for z/OS, and that won't change with DevOps. DevOps tools can be integrated with existing security protocols, ensuring that automation doesn't come at the expense of data protection.

Modern Tools for a Modern Era: Gone are the days of cryptic green screens and arcane commands. Modern tools are making z/OS development more accessible. Version control systems like Git and user-friendly interfaces are attracting a new generation of developers to the mainframe.

The Future is Hybrid: DevOps isn't about replacing the mainframe, it's about integrating it seamlessly with other platforms. APIs and tools like z/OS Connect are making it easier for mainframe data to flow securely to cloud applications and other systems, enabling a truly hybrid IT environment.

The marriage of DevOps and IBM z/OS isn't just a fad, it's a sign of the platform's enduring relevance. By embracing agility, automation, and collaboration, z/OS is ensuring its place in the future of enterprise computing. So, the next time someone says "mainframes are dead," remember: the mainframe is evolving, and with DevOps as its co-pilot, it's ready to tackle the challenges of the modern IT world.

The Big Question: How long before the DevOps completely transforms the mainframe development, attracting a new generation of talent and solidifying z/OS's position as a cornerstone of the hybrid cloud future, or will the inherent complexities of the mainframe environment pose limitations on the full potential of DevOps?

I couldn't agree more Scott. We implemented Endevor at customers 20 years ago, as the Mainframe needs to deploy to countless application instances and NOT as distributed systems to countless SERVERS. 
So the question is really "what value brings the new deployment software and does it really fit for Mainframe deployment"

Geez, there's nothing like retconning to make your point.

All of the major mainframe source code management tools (SCMs) have had automated build and deploy capabilities that would work for unit test, QA, pre-prod, prod, etc. within the product for decades.  By "major," I mean:  Endevor, Librarian, Panvalet, ISPW and SCLM.  There are obsolete others out there (e.g., BIM-EDIT, Alchemist), and even these have long had a phase oriented build and deploy capability.  This functionality was appropriate for the environments and (especially) the constraints it was designed for:  very expensive compute and hyper-expensive storage, where every cycle and byte was counted and managed.  Deployment is generally to a small set of known environments and production deployment could be to a single set of libraries, even for hundreds or thousands of application instances. 

So-called "modern" DevOps was designed for a completely different set of constraints:  cheap compute and cheaper storage, automated, just-in-time provisioning of the underlying test environment and a need to deploy production to hundreds, if not thousands of server instances.

I fully agree that for many reasons, mainframe installations should adopt the tools and processes that have been developed to solve the scaling problems endemic to distributed software deployment.  None of those reasons includes, "because there aren't automated processes in place today."  The primary driver of resistance to these new tools is not, "we like working with stone knives and bearskins," more, "what's the value of changing these processes that have worked for decades?"  

Absolutely agree with your perspective Michael. It's evident that z/OS is designed for automation and integration, and while the focus historically leaned towards operational automation, the landscape is evolving. With the increasing frequency of changes to infrastructure, there's a clear shift towards automating deployment processes. The tools and capabilities to automate deployments across z/OS, middleware, and applications are readily available. However, as you rightly pointed out, the primary obstacle often lies in the mindset. Implementing automation requires a proactive approach and a shift in mindset towards embracing change and innovation. It's akin to any other CI/CD pipeline or DevOps initiative – the key lies in defining and executing the strategy. The real question now becomes not about the possibility or methodology but rather about seizing the opportunity. Who will be the trailblazer to implement and leverage this automation, thereby gaining a competitive edge in this space? It's a compelling challenge waiting to be embraced.

Yes, implementing a DevOps process for IBM Z, automating development build across different stages with continuous testing process

I agree that it's not a question of whether it can be done. z/OS is all about automation and integration. In the past, automation was more concentrating on automating the operations rather than automating the deployment. That was the more pressing problem due to the relatively small and infrequent changes to the infrastructure. The required number of changes increased over time. I agree that most of the deployments can already be automated. All tools, features, and functionalities to automate z/OS deployments, middleware deployments, and application deployments are available. The main barrier is the mindset. Just because it can be done, you still need to it. It's like any other CI/CD pipleline and DevOps process. You just need to define and implement it. Therefore, the main question for me isn't about whether and how, but about who will be the first one to implement it and gain the competitive advantage in this area.

@Saurabh, are you implementing a DevOps process for IBM Z in your organization?

For decades, IBM z/OS has been the workhorse of the enterprise world, powering mission-critical applications with unparalleled security and stability. But the IT landscape is changing. Businesses demand faster innovation and agility, which can seem at odds with the traditional, siloed approach of mainframe development.

Enter DevOps – a methodology that bridges the gap between development and operations. Many might think "DevOps on the mainframe? Isn't that an oxymoron?" Surprisingly, not! Here's how DevOps is reshaping IBM z/OS:

From Waterfall to Continuous Flow: Traditionally, mainframe deployments were slow and methodical. Code changes trickled down a waterfall of approvals, leading to lengthy release cycles. DevOps flips the script, promoting continuous integration and delivery (CI/CD). This means smaller, more frequent updates, allowing businesses to adapt and innovate faster.

Automation is King: DevOps is all about automation, and the mainframe is ripe for it. Repetitive tasks like provisioning environments, testing code, and deploying updates can all be automated, freeing developers to focus on bigger challenges. Tools like IBM Db2 DevOps Experience for z/OS are streamlining these processes.

Collaboration Conquers Silos: DevOps fosters a culture of collaboration between developers, operations teams, and security professionals. This breaks down traditional silos, leading to a more efficient and responsive IT organization.

Security Stays Paramount: Security is a top priority for z/OS, and that won't change with DevOps. DevOps tools can be integrated with existing security protocols, ensuring that automation doesn't come at the expense of data protection.

Modern Tools for a Modern Era: Gone are the days of cryptic green screens and arcane commands. Modern tools are making z/OS development more accessible. Version control systems like Git and user-friendly interfaces are attracting a new generation of developers to the mainframe.

The Future is Hybrid: DevOps isn't about replacing the mainframe, it's about integrating it seamlessly with other platforms. APIs and tools like z/OS Connect are making it easier for mainframe data to flow securely to cloud applications and other systems, enabling a truly hybrid IT environment.

The marriage of DevOps and IBM z/OS isn't just a fad, it's a sign of the platform's enduring relevance. By embracing agility, automation, and collaboration, z/OS is ensuring its place in the future of enterprise computing. So, the next time someone says "mainframes are dead," remember: the mainframe is evolving, and with DevOps as its co-pilot, it's ready to tackle the challenges of the modern IT world.

The Big Question: How long before the DevOps completely transforms the mainframe development, attracting a new generation of talent and solidifying z/OS's position as a cornerstone of the hybrid cloud future, or will the inherent complexities of the mainframe environment pose limitations on the full potential of DevOps?

The value DevOps brings lies in the single responsibility for development and operation.  It's not different teams with all the communication problems. You can always see what value lies in automation if you look at z/OS. I don't know of any environment that is more automated than z/OS operations. Just think about what is already automated via policies, and automation products like IBM System automation.  WLM, Sysplex, Storage, ....
Operation was the main focus for automation in the past because environment and applications had been very stable and the most critical area was operations. That changes in today's world. New application and faster application changes are needed to adhere to business needs.

Whether I have multiple applications that end up in separate servers or on a  few server for me is just a question about stakeholders and approvers for a process. In fact, for me a z/OS parallel sysplex is a cloud. Therefore, whatever value there is to run workload in a cloud is also a value for the mainframe. If someone would start from scratch with the mainframe, who would build a cloud without DevOps and automation?

The DevOps process for a mainframe might be more sophisticated, but other than that, I do not see any difference between a mainframe, and say a cloud. 

To repeat myself: It's just a different mindset. 

Where do you see the difference?

I couldn't agree more Scott. We implemented Endevor at customers 20 years ago, as the Mainframe needs to deploy to countless application instances and NOT as distributed systems to countless SERVERS. 
So the question is really "what value brings the new deployment software and does it really fit for Mainframe deployment"

Geez, there's nothing like retconning to make your point.

All of the major mainframe source code management tools (SCMs) have had automated build and deploy capabilities that would work for unit test, QA, pre-prod, prod, etc. within the product for decades.  By "major," I mean:  Endevor, Librarian, Panvalet, ISPW and SCLM.  There are obsolete others out there (e.g., BIM-EDIT, Alchemist), and even these have long had a phase oriented build and deploy capability.  This functionality was appropriate for the environments and (especially) the constraints it was designed for:  very expensive compute and hyper-expensive storage, where every cycle and byte was counted and managed.  Deployment is generally to a small set of known environments and production deployment could be to a single set of libraries, even for hundreds or thousands of application instances. 

So-called "modern" DevOps was designed for a completely different set of constraints:  cheap compute and cheaper storage, automated, just-in-time provisioning of the underlying test environment and a need to deploy production to hundreds, if not thousands of server instances.

I fully agree that for many reasons, mainframe installations should adopt the tools and processes that have been developed to solve the scaling problems endemic to distributed software deployment.  None of those reasons includes, "because there aren't automated processes in place today."  The primary driver of resistance to these new tools is not, "we like working with stone knives and bearskins," more, "what's the value of changing these processes that have worked for decades?"  

Absolutely agree with your perspective Michael. It's evident that z/OS is designed for automation and integration, and while the focus historically leaned towards operational automation, the landscape is evolving. With the increasing frequency of changes to infrastructure, there's a clear shift towards automating deployment processes. The tools and capabilities to automate deployments across z/OS, middleware, and applications are readily available. However, as you rightly pointed out, the primary obstacle often lies in the mindset. Implementing automation requires a proactive approach and a shift in mindset towards embracing change and innovation. It's akin to any other CI/CD pipeline or DevOps initiative – the key lies in defining and executing the strategy. The real question now becomes not about the possibility or methodology but rather about seizing the opportunity. Who will be the trailblazer to implement and leverage this automation, thereby gaining a competitive edge in this space? It's a compelling challenge waiting to be embraced.

Yes, implementing a DevOps process for IBM Z, automating development build across different stages with continuous testing process

I agree that it's not a question of whether it can be done. z/OS is all about automation and integration. In the past, automation was more concentrating on automating the operations rather than automating the deployment. That was the more pressing problem due to the relatively small and infrequent changes to the infrastructure. The required number of changes increased over time. I agree that most of the deployments can already be automated. All tools, features, and functionalities to automate z/OS deployments, middleware deployments, and application deployments are available. The main barrier is the mindset. Just because it can be done, you still need to it. It's like any other CI/CD pipleline and DevOps process. You just need to define and implement it. Therefore, the main question for me isn't about whether and how, but about who will be the first one to implement it and gain the competitive advantage in this area.

@Saurabh, are you implementing a DevOps process for IBM Z in your organization?

For decades, IBM z/OS has been the workhorse of the enterprise world, powering mission-critical applications with unparalleled security and stability. But the IT landscape is changing. Businesses demand faster innovation and agility, which can seem at odds with the traditional, siloed approach of mainframe development.

Enter DevOps – a methodology that bridges the gap between development and operations. Many might think "DevOps on the mainframe? Isn't that an oxymoron?" Surprisingly, not! Here's how DevOps is reshaping IBM z/OS:

From Waterfall to Continuous Flow: Traditionally, mainframe deployments were slow and methodical. Code changes trickled down a waterfall of approvals, leading to lengthy release cycles. DevOps flips the script, promoting continuous integration and delivery (CI/CD). This means smaller, more frequent updates, allowing businesses to adapt and innovate faster.

Automation is King: DevOps is all about automation, and the mainframe is ripe for it. Repetitive tasks like provisioning environments, testing code, and deploying updates can all be automated, freeing developers to focus on bigger challenges. Tools like IBM Db2 DevOps Experience for z/OS are streamlining these processes.

Collaboration Conquers Silos: DevOps fosters a culture of collaboration between developers, operations teams, and security professionals. This breaks down traditional silos, leading to a more efficient and responsive IT organization.

Security Stays Paramount: Security is a top priority for z/OS, and that won't change with DevOps. DevOps tools can be integrated with existing security protocols, ensuring that automation doesn't come at the expense of data protection.

Modern Tools for a Modern Era: Gone are the days of cryptic green screens and arcane commands. Modern tools are making z/OS development more accessible. Version control systems like Git and user-friendly interfaces are attracting a new generation of developers to the mainframe.

The Future is Hybrid: DevOps isn't about replacing the mainframe, it's about integrating it seamlessly with other platforms. APIs and tools like z/OS Connect are making it easier for mainframe data to flow securely to cloud applications and other systems, enabling a truly hybrid IT environment.

The marriage of DevOps and IBM z/OS isn't just a fad, it's a sign of the platform's enduring relevance. By embracing agility, automation, and collaboration, z/OS is ensuring its place in the future of enterprise computing. So, the next time someone says "mainframes are dead," remember: the mainframe is evolving, and with DevOps as its co-pilot, it's ready to tackle the challenges of the modern IT world.

The Big Question: How long before the DevOps completely transforms the mainframe development, attracting a new generation of talent and solidifying z/OS's position as a cornerstone of the hybrid cloud future, or will the inherent complexities of the mainframe environment pose limitations on the full potential of DevOps?

Here's the point:  before anyone called it "DevOps," Endevor, ChangeMan, SCLM and other "software change management systems" orchestrated the exact same set of processes that any set of integrated DevOps tools (e.g., Git + Jenkins + Artifactory) would perform for distributed software development.  DevOps neither "discovered" nor "invented" this mindset, it has existed for decades.  The only credit due is for giving it a whizzy name.

To be more blunt:  telling people that they're out of control of have the wrong mindset (especially when they had the mindset before many DevOps acolytes were even in diapers) is unlikely to induce them to come to your toolset.

Clearly, the tools built to accomodate a far more variable environment can be used for mainframe development.  I work with these customers every day.  Adopting a "DevOps mindset" is not the issue, mainframe developers and operations staff have been keeping application integrity since the early 1980s with the existing tools set.  The value proposition for the newer tools comes from:

1) Reducing the barriers for new developers to work with mainframe code - it's one thing to ask someone from the distributed side to come and work in COBOL and/or PL/I.  It's another thing to make them learn a bunch of arcane tools that they've never seen before in a user interface that resembles Pong.  What's the ratio of mainframe developers to distributed?  1:5?  1:10?  1:100?

1a) Keeping the source code for different deployment platforms in different repositories just makes life harder when having to design, implement, and test application code that crosses those platforms.  It's more effective to allow someone with the appropriate skill to make changes "on both sides" and then test those changes.  A common development repository eases this for writing code and a common deployment tool eases this for testing, especially when the deployment process needs to "stitch together" the various systems so they can talk to each other.

2) Reducing the complexity of deploying applications across multiple platforms - as applications become more entwined between different platforms, it only makes sense to centralize deploy capability so that they are appropriately synchronized and potentially backed out across platforms.

To your question, "If someone would start from scratch with the mainframe, who would build a cloud without DevOps and automation?"  The answer is, "Nobody did.  They just didn't call it DevOps, they called it Endevor:  ENvironment for DEVelopment and OpeRations."

For more:  CA Endevor – A History Lesson for Today's DevOps Pipelines

I'll sit back now and wait for the responses telling me about some edge cases that mainframe SCMs didn't have to deal with being core and important distinctions to DevOps.

The value DevOps brings lies in the single responsibility for development and operation.  It's not different teams with all the communication problems. You can always see what value lies in automation if you look at z/OS. I don't know of any environment that is more automated than z/OS operations. Just think about what is already automated via policies, and automation products like IBM System automation.  WLM, Sysplex, Storage, ....
Operation was the main focus for automation in the past because environment and applications had been very stable and the most critical area was operations. That changes in today's world. New application and faster application changes are needed to adhere to business needs.

Whether I have multiple applications that end up in separate servers or on a  few server for me is just a question about stakeholders and approvers for a process. In fact, for me a z/OS parallel sysplex is a cloud. Therefore, whatever value there is to run workload in a cloud is also a value for the mainframe. If someone would start from scratch with the mainframe, who would build a cloud without DevOps and automation?

The DevOps process for a mainframe might be more sophisticated, but other than that, I do not see any difference between a mainframe, and say a cloud. 

To repeat myself: It's just a different mindset. 

Where do you see the difference?

I couldn't agree more Scott. We implemented Endevor at customers 20 years ago, as the Mainframe needs to deploy to countless application instances and NOT as distributed systems to countless SERVERS. 
So the question is really "what value brings the new deployment software and does it really fit for Mainframe deployment"

Geez, there's nothing like retconning to make your point.

All of the major mainframe source code management tools (SCMs) have had automated build and deploy capabilities that would work for unit test, QA, pre-prod, prod, etc. within the product for decades.  By "major," I mean:  Endevor, Librarian, Panvalet, ISPW and SCLM.  There are obsolete others out there (e.g., BIM-EDIT, Alchemist), and even these have long had a phase oriented build and deploy capability.  This functionality was appropriate for the environments and (especially) the constraints it was designed for:  very expensive compute and hyper-expensive storage, where every cycle and byte was counted and managed.  Deployment is generally to a small set of known environments and production deployment could be to a single set of libraries, even for hundreds or thousands of application instances. 

So-called "modern" DevOps was designed for a completely different set of constraints:  cheap compute and cheaper storage, automated, just-in-time provisioning of the underlying test environment and a need to deploy production to hundreds, if not thousands of server instances.

I fully agree that for many reasons, mainframe installations should adopt the tools and processes that have been developed to solve the scaling problems endemic to distributed software deployment.  None of those reasons includes, "because there aren't automated processes in place today."  The primary driver of resistance to these new tools is not, "we like working with stone knives and bearskins," more, "what's the value of changing these processes that have worked for decades?"  

Absolutely agree with your perspective Michael. It's evident that z/OS is designed for automation and integration, and while the focus historically leaned towards operational automation, the landscape is evolving. With the increasing frequency of changes to infrastructure, there's a clear shift towards automating deployment processes. The tools and capabilities to automate deployments across z/OS, middleware, and applications are readily available. However, as you rightly pointed out, the primary obstacle often lies in the mindset. Implementing automation requires a proactive approach and a shift in mindset towards embracing change and innovation. It's akin to any other CI/CD pipeline or DevOps initiative – the key lies in defining and executing the strategy. The real question now becomes not about the possibility or methodology but rather about seizing the opportunity. Who will be the trailblazer to implement and leverage this automation, thereby gaining a competitive edge in this space? It's a compelling challenge waiting to be embraced.

Yes, implementing a DevOps process for IBM Z, automating development build across different stages with continuous testing process

I agree that it's not a question of whether it can be done. z/OS is all about automation and integration. In the past, automation was more concentrating on automating the operations rather than automating the deployment. That was the more pressing problem due to the relatively small and infrequent changes to the infrastructure. The required number of changes increased over time. I agree that most of the deployments can already be automated. All tools, features, and functionalities to automate z/OS deployments, middleware deployments, and application deployments are available. The main barrier is the mindset. Just because it can be done, you still need to it. It's like any other CI/CD pipleline and DevOps process. You just need to define and implement it. Therefore, the main question for me isn't about whether and how, but about who will be the first one to implement it and gain the competitive advantage in this area.

@Saurabh, are you implementing a DevOps process for IBM Z in your organization?

For decades, IBM z/OS has been the workhorse of the enterprise world, powering mission-critical applications with unparalleled security and stability. But the IT landscape is changing. Businesses demand faster innovation and agility, which can seem at odds with the traditional, siloed approach of mainframe development.

Enter DevOps – a methodology that bridges the gap between development and operations. Many might think "DevOps on the mainframe? Isn't that an oxymoron?" Surprisingly, not! Here's how DevOps is reshaping IBM z/OS:

From Waterfall to Continuous Flow: Traditionally, mainframe deployments were slow and methodical. Code changes trickled down a waterfall of approvals, leading to lengthy release cycles. DevOps flips the script, promoting continuous integration and delivery (CI/CD). This means smaller, more frequent updates, allowing businesses to adapt and innovate faster.

Automation is King: DevOps is all about automation, and the mainframe is ripe for it. Repetitive tasks like provisioning environments, testing code, and deploying updates can all be automated, freeing developers to focus on bigger challenges. Tools like IBM Db2 DevOps Experience for z/OS are streamlining these processes.

Collaboration Conquers Silos: DevOps fosters a culture of collaboration between developers, operations teams, and security professionals. This breaks down traditional silos, leading to a more efficient and responsive IT organization.

Security Stays Paramount: Security is a top priority for z/OS, and that won't change with DevOps. DevOps tools can be integrated with existing security protocols, ensuring that automation doesn't come at the expense of data protection.

Modern Tools for a Modern Era: Gone are the days of cryptic green screens and arcane commands. Modern tools are making z/OS development more accessible. Version control systems like Git and user-friendly interfaces are attracting a new generation of developers to the mainframe.

The Future is Hybrid: DevOps isn't about replacing the mainframe, it's about integrating it seamlessly with other platforms. APIs and tools like z/OS Connect are making it easier for mainframe data to flow securely to cloud applications and other systems, enabling a truly hybrid IT environment.

The marriage of DevOps and IBM z/OS isn't just a fad, it's a sign of the platform's enduring relevance. By embracing agility, automation, and collaboration, z/OS is ensuring its place in the future of enterprise computing. So, the next time someone says "mainframes are dead," remember: the mainframe is evolving, and with DevOps as its co-pilot, it's ready to tackle the challenges of the modern IT world.

The Big Question: How long before the DevOps completely transforms the mainframe development, attracting a new generation of talent and solidifying z/OS's position as a cornerstone of the hybrid cloud future, or will the inherent complexities of the mainframe environment pose limitations on the full potential of DevOps?

The value DevOps brings lies in the single responsibility for development and operation.  It's not different teams with all the communication problems. You can always see what value lies in automation if you look at z/OS. I don't know of any environment that is more automated than z/OS operations. Just think about what is already automated via policies, and automation products like IBM System automation.  WLM, Sysplex, Storage, ....
Operation was the main focus for automation in the past because environment and applications had been very stable and the most critical area was operations. That changes in today's world. New application and faster application changes are needed to adhere to business needs.

Whether I have multiple applications that end up in separate servers or on a  few server for me is just a question about stakeholders and approvers for a process. In fact, for me a z/OS parallel sysplex is a cloud. Therefore, whatever value there is to run workload in a cloud is also a value for the mainframe. If someone would start from scratch with the mainframe, who would build a cloud without DevOps and automation?

The DevOps process for a mainframe might be more sophisticated, but other than that, I do not see any difference between a mainframe, and say a cloud. 

To repeat myself: It's just a different mindset. 

Where do you see the difference?

I couldn't agree more Scott. We implemented Endevor at customers 20 years ago, as the Mainframe needs to deploy to countless application instances and NOT as distributed systems to countless SERVERS. 
So the question is really "what value brings the new deployment software and does it really fit for Mainframe deployment"

Geez, there's nothing like retconning to make your point.

All of the major mainframe source code management tools (SCMs) have had automated build and deploy capabilities that would work for unit test, QA, pre-prod, prod, etc. within the product for decades.  By "major," I mean:  Endevor, Librarian, Panvalet, ISPW and SCLM.  There are obsolete others out there (e.g., BIM-EDIT, Alchemist), and even these have long had a phase oriented build and deploy capability.  This functionality was appropriate for the environments and (especially) the constraints it was designed for:  very expensive compute and hyper-expensive storage, where every cycle and byte was counted and managed.  Deployment is generally to a small set of known environments and production deployment could be to a single set of libraries, even for hundreds or thousands of application instances. 

So-called "modern" DevOps was designed for a completely different set of constraints:  cheap compute and cheaper storage, automated, just-in-time provisioning of the underlying test environment and a need to deploy production to hundreds, if not thousands of server instances.

I fully agree that for many reasons, mainframe installations should adopt the tools and processes that have been developed to solve the scaling problems endemic to distributed software deployment.  None of those reasons includes, "because there aren't automated processes in place today."  The primary driver of resistance to these new tools is not, "we like working with stone knives and bearskins," more, "what's the value of changing these processes that have worked for decades?"  

Absolutely agree with your perspective Michael. It's evident that z/OS is designed for automation and integration, and while the focus historically leaned towards operational automation, the landscape is evolving. With the increasing frequency of changes to infrastructure, there's a clear shift towards automating deployment processes. The tools and capabilities to automate deployments across z/OS, middleware, and applications are readily available. However, as you rightly pointed out, the primary obstacle often lies in the mindset. Implementing automation requires a proactive approach and a shift in mindset towards embracing change and innovation. It's akin to any other CI/CD pipeline or DevOps initiative – the key lies in defining and executing the strategy. The real question now becomes not about the possibility or methodology but rather about seizing the opportunity. Who will be the trailblazer to implement and leverage this automation, thereby gaining a competitive edge in this space? It's a compelling challenge waiting to be embraced.

Yes, implementing a DevOps process for IBM Z, automating development build across different stages with continuous testing process

I agree that it's not a question of whether it can be done. z/OS is all about automation and integration. In the past, automation was more concentrating on automating the operations rather than automating the deployment. That was the more pressing problem due to the relatively small and infrequent changes to the infrastructure. The required number of changes increased over time. I agree that most of the deployments can already be automated. All tools, features, and functionalities to automate z/OS deployments, middleware deployments, and application deployments are available. The main barrier is the mindset. Just because it can be done, you still need to it. It's like any other CI/CD pipleline and DevOps process. You just need to define and implement it. Therefore, the main question for me isn't about whether and how, but about who will be the first one to implement it and gain the competitive advantage in this area.

@Saurabh, are you implementing a DevOps process for IBM Z in your organization?

For decades, IBM z/OS has been the workhorse of the enterprise world, powering mission-critical applications with unparalleled security and stability. But the IT landscape is changing. Businesses demand faster innovation and agility, which can seem at odds with the traditional, siloed approach of mainframe development.

Enter DevOps – a methodology that bridges the gap between development and operations. Many might think "DevOps on the mainframe? Isn't that an oxymoron?" Surprisingly, not! Here's how DevOps is reshaping IBM z/OS:

From Waterfall to Continuous Flow: Traditionally, mainframe deployments were slow and methodical. Code changes trickled down a waterfall of approvals, leading to lengthy release cycles. DevOps flips the script, promoting continuous integration and delivery (CI/CD). This means smaller, more frequent updates, allowing businesses to adapt and innovate faster.

Automation is King: DevOps is all about automation, and the mainframe is ripe for it. Repetitive tasks like provisioning environments, testing code, and deploying updates can all be automated, freeing developers to focus on bigger challenges. Tools like IBM Db2 DevOps Experience for z/OS are streamlining these processes.

Collaboration Conquers Silos: DevOps fosters a culture of collaboration between developers, operations teams, and security professionals. This breaks down traditional silos, leading to a more efficient and responsive IT organization.

Security Stays Paramount: Security is a top priority for z/OS, and that won't change with DevOps. DevOps tools can be integrated with existing security protocols, ensuring that automation doesn't come at the expense of data protection.

Modern Tools for a Modern Era: Gone are the days of cryptic green screens and arcane commands. Modern tools are making z/OS development more accessible. Version control systems like Git and user-friendly interfaces are attracting a new generation of developers to the mainframe.

The Future is Hybrid: DevOps isn't about replacing the mainframe, it's about integrating it seamlessly with other platforms. APIs and tools like z/OS Connect are making it easier for mainframe data to flow securely to cloud applications and other systems, enabling a truly hybrid IT environment.

The marriage of DevOps and IBM z/OS isn't just a fad, it's a sign of the platform's enduring relevance. By embracing agility, automation, and collaboration, z/OS is ensuring its place in the future of enterprise computing. So, the next time someone says "mainframes are dead," remember: the mainframe is evolving, and with DevOps as its co-pilot, it's ready to tackle the challenges of the modern IT world.

The Big Question: How long before the DevOps completely transforms the mainframe development, attracting a new generation of talent and solidifying z/OS's position as a cornerstone of the hybrid cloud future, or will the inherent complexities of the mainframe environment pose limitations on the full potential of DevOps?

"...the single responsibility for development and operation" 
I agree, but the challenge is that in many/most mainframe shops there's a separate group responsible for making changes to production systems. That is partly been for security reasons ... "separation of roles" ... but there is also the fact that the team making the changes to production is usually also on 24x7 call for any problems out of hours. Now if the applications developers want to make their own changes to production, they must also take responsibility for being called at 02:00 for problems caused by their changes. The problem is, they don't want to do that. Application developers seem to think Devops means they get to do pretty much what they like but take no responsibility for the problems caused.  For Devops to be successful, there does indeed need to be a change in mindset, but it's not just the minds of the mainframe support folk. there needs to be a change of mindset by application developers to take responsibility for their changes and be on-call for them.

The value DevOps brings lies in the single responsibility for development and operation.  It's not different teams with all the communication problems. You can always see what value lies in automation if you look at z/OS. I don't know of any environment that is more automated than z/OS operations. Just think about what is already automated via policies, and automation products like IBM System automation.  WLM, Sysplex, Storage, ....
Operation was the main focus for automation in the past because environment and applications had been very stable and the most critical area was operations. That changes in today's world. New application and faster application changes are needed to adhere to business needs.

Whether I have multiple applications that end up in separate servers or on a  few server for me is just a question about stakeholders and approvers for a process. In fact, for me a z/OS parallel sysplex is a cloud. Therefore, whatever value there is to run workload in a cloud is also a value for the mainframe. If someone would start from scratch with the mainframe, who would build a cloud without DevOps and automation?

The DevOps process for a mainframe might be more sophisticated, but other than that, I do not see any difference between a mainframe, and say a cloud. 

To repeat myself: It's just a different mindset. 

Where do you see the difference?

I couldn't agree more Scott. We implemented Endevor at customers 20 years ago, as the Mainframe needs to deploy to countless application instances and NOT as distributed systems to countless SERVERS. 
So the question is really "what value brings the new deployment software and does it really fit for Mainframe deployment"

Geez, there's nothing like retconning to make your point.

All of the major mainframe source code management tools (SCMs) have had automated build and deploy capabilities that would work for unit test, QA, pre-prod, prod, etc. within the product for decades.  By "major," I mean:  Endevor, Librarian, Panvalet, ISPW and SCLM.  There are obsolete others out there (e.g., BIM-EDIT, Alchemist), and even these have long had a phase oriented build and deploy capability.  This functionality was appropriate for the environments and (especially) the constraints it was designed for:  very expensive compute and hyper-expensive storage, where every cycle and byte was counted and managed.  Deployment is generally to a small set of known environments and production deployment could be to a single set of libraries, even for hundreds or thousands of application instances. 

So-called "modern" DevOps was designed for a completely different set of constraints:  cheap compute and cheaper storage, automated, just-in-time provisioning of the underlying test environment and a need to deploy production to hundreds, if not thousands of server instances.

I fully agree that for many reasons, mainframe installations should adopt the tools and processes that have been developed to solve the scaling problems endemic to distributed software deployment.  None of those reasons includes, "because there aren't automated processes in place today."  The primary driver of resistance to these new tools is not, "we like working with stone knives and bearskins," more, "what's the value of changing these processes that have worked for decades?"  

Absolutely agree with your perspective Michael. It's evident that z/OS is designed for automation and integration, and while the focus historically leaned towards operational automation, the landscape is evolving. With the increasing frequency of changes to infrastructure, there's a clear shift towards automating deployment processes. The tools and capabilities to automate deployments across z/OS, middleware, and applications are readily available. However, as you rightly pointed out, the primary obstacle often lies in the mindset. Implementing automation requires a proactive approach and a shift in mindset towards embracing change and innovation. It's akin to any other CI/CD pipeline or DevOps initiative – the key lies in defining and executing the strategy. The real question now becomes not about the possibility or methodology but rather about seizing the opportunity. Who will be the trailblazer to implement and leverage this automation, thereby gaining a competitive edge in this space? It's a compelling challenge waiting to be embraced.

Yes, implementing a DevOps process for IBM Z, automating development build across different stages with continuous testing process

I agree that it's not a question of whether it can be done. z/OS is all about automation and integration. In the past, automation was more concentrating on automating the operations rather than automating the deployment. That was the more pressing problem due to the relatively small and infrequent changes to the infrastructure. The required number of changes increased over time. I agree that most of the deployments can already be automated. All tools, features, and functionalities to automate z/OS deployments, middleware deployments, and application deployments are available. The main barrier is the mindset. Just because it can be done, you still need to it. It's like any other CI/CD pipleline and DevOps process. You just need to define and implement it. Therefore, the main question for me isn't about whether and how, but about who will be the first one to implement it and gain the competitive advantage in this area.

@Saurabh, are you implementing a DevOps process for IBM Z in your organization?

For decades, IBM z/OS has been the workhorse of the enterprise world, powering mission-critical applications with unparalleled security and stability. But the IT landscape is changing. Businesses demand faster innovation and agility, which can seem at odds with the traditional, siloed approach of mainframe development.

Enter DevOps – a methodology that bridges the gap between development and operations. Many might think "DevOps on the mainframe? Isn't that an oxymoron?" Surprisingly, not! Here's how DevOps is reshaping IBM z/OS:

From Waterfall to Continuous Flow: Traditionally, mainframe deployments were slow and methodical. Code changes trickled down a waterfall of approvals, leading to lengthy release cycles. DevOps flips the script, promoting continuous integration and delivery (CI/CD). This means smaller, more frequent updates, allowing businesses to adapt and innovate faster.

Automation is King: DevOps is all about automation, and the mainframe is ripe for it. Repetitive tasks like provisioning environments, testing code, and deploying updates can all be automated, freeing developers to focus on bigger challenges. Tools like IBM Db2 DevOps Experience for z/OS are streamlining these processes.

Collaboration Conquers Silos: DevOps fosters a culture of collaboration between developers, operations teams, and security professionals. This breaks down traditional silos, leading to a more efficient and responsive IT organization.

Security Stays Paramount: Security is a top priority for z/OS, and that won't change with DevOps. DevOps tools can be integrated with existing security protocols, ensuring that automation doesn't come at the expense of data protection.

Modern Tools for a Modern Era: Gone are the days of cryptic green screens and arcane commands. Modern tools are making z/OS development more accessible. Version control systems like Git and user-friendly interfaces are attracting a new generation of developers to the mainframe.

The Future is Hybrid: DevOps isn't about replacing the mainframe, it's about integrating it seamlessly with other platforms. APIs and tools like z/OS Connect are making it easier for mainframe data to flow securely to cloud applications and other systems, enabling a truly hybrid IT environment.

The marriage of DevOps and IBM z/OS isn't just a fad, it's a sign of the platform's enduring relevance. By embracing agility, automation, and collaboration, z/OS is ensuring its place in the future of enterprise computing. So, the next time someone says "mainframes are dead," remember: the mainframe is evolving, and with DevOps as its co-pilot, it's ready to tackle the challenges of the modern IT world.

The Big Question: How long before the DevOps completely transforms the mainframe development, attracting a new generation of talent and solidifying z/OS's position as a cornerstone of the hybrid cloud future, or will the inherent complexities of the mainframe environment pose limitations on the full potential of DevOps?

I'm not sure that developers don't want to take on the responsibility. We see it in other areas that DevOps is working. It's more the other point that you mentioned; in a mainframe environment you have organizational constrains like separation of responsibilities and roles that prohibit taking on those responsibilities. In that sense,  organizational structures represent a mindset. Therefore, my point is that it's not a tools questions. Whether you're using git, Endevor, Jenkins, or you name it to implement your DevOps process doesn't matter to me. It's may be easier to find people who know the current tools, but for me, it's the concept that matters.

It's always very hard to run processes in structures that don't support the mindset. Based on that, DevOps requires different organizational structures. Therefore, I would start with the organizational changes. Nearly all people optimize based on what they are paid for and where they get credits for their work. If you change that and stimulate other behavior, then an organization will find the tools and processes that fit it's purpose.

"...the single responsibility for development and operation" 
I agree, but the challenge is that in many/most mainframe shops there's a separate group responsible for making changes to production systems. That is partly been for security reasons ... "separation of roles" ... but there is also the fact that the team making the changes to production is usually also on 24x7 call for any problems out of hours. Now if the applications developers want to make their own changes to production, they must also take responsibility for being called at 02:00 for problems caused by their changes. The problem is, they don't want to do that. Application developers seem to think Devops means they get to do pretty much what they like but take no responsibility for the problems caused.  For Devops to be successful, there does indeed need to be a change in mindset, but it's not just the minds of the mainframe support folk. there needs to be a change of mindset by application developers to take responsibility for their changes and be on-call for them.

The value DevOps brings lies in the single responsibility for development and operation.  It's not different teams with all the communication problems. You can always see what value lies in automation if you look at z/OS. I don't know of any environment that is more automated than z/OS operations. Just think about what is already automated via policies, and automation products like IBM System automation.  WLM, Sysplex, Storage, ....
Operation was the main focus for automation in the past because environment and applications had been very stable and the most critical area was operations. That changes in today's world. New application and faster application changes are needed to adhere to business needs.

Whether I have multiple applications that end up in separate servers or on a  few server for me is just a question about stakeholders and approvers for a process. In fact, for me a z/OS parallel sysplex is a cloud. Therefore, whatever value there is to run workload in a cloud is also a value for the mainframe. If someone would start from scratch with the mainframe, who would build a cloud without DevOps and automation?

The DevOps process for a mainframe might be more sophisticated, but other than that, I do not see any difference between a mainframe, and say a cloud. 

To repeat myself: It's just a different mindset. 

Where do you see the difference?

I couldn't agree more Scott. We implemented Endevor at customers 20 years ago, as the Mainframe needs to deploy to countless application instances and NOT as distributed systems to countless SERVERS. 
So the question is really "what value brings the new deployment software and does it really fit for Mainframe deployment"

Geez, there's nothing like retconning to make your point.

All of the major mainframe source code management tools (SCMs) have had automated build and deploy capabilities that would work for unit test, QA, pre-prod, prod, etc. within the product for decades.  By "major," I mean:  Endevor, Librarian, Panvalet, ISPW and SCLM.  There are obsolete others out there (e.g., BIM-EDIT, Alchemist), and even these have long had a phase oriented build and deploy capability.  This functionality was appropriate for the environments and (especially) the constraints it was designed for:  very expensive compute and hyper-expensive storage, where every cycle and byte was counted and managed.  Deployment is generally to a small set of known environments and production deployment could be to a single set of libraries, even for hundreds or thousands of application instances. 

So-called "modern" DevOps was designed for a completely different set of constraints:  cheap compute and cheaper storage, automated, just-in-time provisioning of the underlying test environment and a need to deploy production to hundreds, if not thousands of server instances.

I fully agree that for many reasons, mainframe installations should adopt the tools and processes that have been developed to solve the scaling problems endemic to distributed software deployment.  None of those reasons includes, "because there aren't automated processes in place today."  The primary driver of resistance to these new tools is not, "we like working with stone knives and bearskins," more, "what's the value of changing these processes that have worked for decades?"  

Absolutely agree with your perspective Michael. It's evident that z/OS is designed for automation and integration, and while the focus historically leaned towards operational automation, the landscape is evolving. With the increasing frequency of changes to infrastructure, there's a clear shift towards automating deployment processes. The tools and capabilities to automate deployments across z/OS, middleware, and applications are readily available. However, as you rightly pointed out, the primary obstacle often lies in the mindset. Implementing automation requires a proactive approach and a shift in mindset towards embracing change and innovation. It's akin to any other CI/CD pipeline or DevOps initiative – the key lies in defining and executing the strategy. The real question now becomes not about the possibility or methodology but rather about seizing the opportunity. Who will be the trailblazer to implement and leverage this automation, thereby gaining a competitive edge in this space? It's a compelling challenge waiting to be embraced.

Yes, implementing a DevOps process for IBM Z, automating development build across different stages with continuous testing process

I agree that it's not a question of whether it can be done. z/OS is all about automation and integration. In the past, automation was more concentrating on automating the operations rather than automating the deployment. That was the more pressing problem due to the relatively small and infrequent changes to the infrastructure. The required number of changes increased over time. I agree that most of the deployments can already be automated. All tools, features, and functionalities to automate z/OS deployments, middleware deployments, and application deployments are available. The main barrier is the mindset. Just because it can be done, you still need to it. It's like any other CI/CD pipleline and DevOps process. You just need to define and implement it. Therefore, the main question for me isn't about whether and how, but about who will be the first one to implement it and gain the competitive advantage in this area.

@Saurabh, are you implementing a DevOps process for IBM Z in your organization?

For decades, IBM z/OS has been the workhorse of the enterprise world, powering mission-critical applications with unparalleled security and stability. But the IT landscape is changing. Businesses demand faster innovation and agility, which can seem at odds with the traditional, siloed approach of mainframe development.

Enter DevOps – a methodology that bridges the gap between development and operations. Many might think "DevOps on the mainframe? Isn't that an oxymoron?" Surprisingly, not! Here's how DevOps is reshaping IBM z/OS:

From Waterfall to Continuous Flow: Traditionally, mainframe deployments were slow and methodical. Code changes trickled down a waterfall of approvals, leading to lengthy release cycles. DevOps flips the script, promoting continuous integration and delivery (CI/CD). This means smaller, more frequent updates, allowing businesses to adapt and innovate faster.

Automation is King: DevOps is all about automation, and the mainframe is ripe for it. Repetitive tasks like provisioning environments, testing code, and deploying updates can all be automated, freeing developers to focus on bigger challenges. Tools like IBM Db2 DevOps Experience for z/OS are streamlining these processes.

Collaboration Conquers Silos: DevOps fosters a culture of collaboration between developers, operations teams, and security professionals. This breaks down traditional silos, leading to a more efficient and responsive IT organization.

Security Stays Paramount: Security is a top priority for z/OS, and that won't change with DevOps. DevOps tools can be integrated with existing security protocols, ensuring that automation doesn't come at the expense of data protection.

Modern Tools for a Modern Era: Gone are the days of cryptic green screens and arcane commands. Modern tools are making z/OS development more accessible. Version control systems like Git and user-friendly interfaces are attracting a new generation of developers to the mainframe.

The Future is Hybrid: DevOps isn't about replacing the mainframe, it's about integrating it seamlessly with other platforms. APIs and tools like z/OS Connect are making it easier for mainframe data to flow securely to cloud applications and other systems, enabling a truly hybrid IT environment.

The marriage of DevOps and IBM z/OS isn't just a fad, it's a sign of the platform's enduring relevance. By embracing agility, automation, and collaboration, z/OS is ensuring its place in the future of enterprise computing. So, the next time someone says "mainframes are dead," remember: the mainframe is evolving, and with DevOps as its co-pilot, it's ready to tackle the challenges of the modern IT world.

The Big Question: How long before the DevOps completely transforms the mainframe development, attracting a new generation of talent and solidifying z/OS's position as a cornerstone of the hybrid cloud future, or will the inherent complexities of the mainframe environment pose limitations on the full potential of DevOps?