2020 A Great Beginning Continuous Learning for the New Year

2020 has started with a bang, starting with doing a session for Predict2020 and learning I was being recognized as the DevOps Evangelist of the year 2019 as part of the DevOps Dozen Awards by DevOps.com was very rewarding. I appreciate all those that voted for me and supported me. This is a team effort, culture change is hard. This gives me additional motivation to continue to drive the inclusion of the Mainframe in DevOps transformations. To that end I want to start this year pointing out some key books worth spending some time with. 

First Engineering the Digital Transformation by Gary Gruver. Really understanding and consciously moving toward practices for digital transformation is key to get the rewards companies are looking for. The book helps you understand how to engineer your transformation, you can't just copy what others have done but you can learn from them. Many large enterprises have significant work to go in moving to automated testing. As Gary points out focusing on building the right tests and making sure they are reliable and repeatable is the first step. Automating the entire process outside of test does provide value, but without the automated tests you can’t actually go faster. The idea of attempting to run the same tests multiple times in a row to make sure they are repeatable is a great way to assess the tests themselves. Focusing on automated tests also requires the focus on test data, with processes such as test data fabrication to insure the coverage required as well as removing any privacy concerns of using production data. 

The second book I took a second look at was Accelerate, by Nicole Forsgren, Jez Humble, and Gene Kim. Understanding the background behind the State of DevOps report and how it shows how organizations perform is enlightening. I am spending time with organizations asking the question how can we do this transformation with our large size and complex nature of the applications. The organizations I deal with have large systems of recording running on IBM Z systems. One comment from the book “there was no significant correlation between system type and delivery performance. We found this surprising: we expected teams working on packaged software, systems of record, or embedded systems to perform worse” particularly struck me in reading it this time. One key note with many systems of record running on IBM Z is that incremental deploys are standard even though it’s a monolithic application. The ability to deploy just the part that has changed, and the ability to “activate” the change in a live system has allowed teams more flexibility and options for change than is expected by those not normally dealing with IBM Z. This ability to deliver one load module, of say 1000 in making a change has provided significant flexibility to teams over the years, that is not always recognized. However, the challenge for many enterprises is that changing that one load module could have an impact on any of the other parts of the system, therefore many spend significant time doing manual integration testing to validate the change. The Accelerate book, as well as Engineering the Digital Transformation discuss the importance of automating this test so changes can easily be validated by the developer as soon as they make it. As part of this ability to test you need to have the right ability to create and destroy environments. 

The next book was Team Topologies by Matthew Skelton and Manuel Pais. Over the last year I have spent time working with organizations on recommendations for how teams should come together. This book clearly spells out team topologies and how these teams interact to form the right organization. This provides plenty of background to help you work through the right structure for your organization. Understanding Conway’s Law “organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations” is critical when designing any organization. It was interesting to think about the idea of designing the organization to create the architecture you desire. 

For the new ways of working we all have have to make sure we are continuously learning, this includes spending time reading the state of the art of the industry. We all can learn from each other. That’s also why activities like AllDayDevOps, and the DevOps Institute with their Global Skill Up Day are so critical. We all need to share what we have learned and learn from others experiences. To that end another paper was published in the set to help organizations include their z/OS assets in their distributed pipelines of choice. You can read the second paper on the Packaging and Deployment process, and if you missed it the first paper on migrating to a modern SCM and Build process. If you are interested in training courses for the modern development environment it’s available as well through self paced online learning with a digital badge.

For me, now that it’s clear modern development practices apply to z/OS as much as to any other system, and we have removed the barriers such that the same tooling can be used across the organization, it’s time to focus on automated testing. I look forward to new learning opportunities coming this year, starting with SHARE in just a few weeks. Join me there to learn more on topics around IBM Z including DevOps practices, Automated Testing, Open Source and many more.