What We Learned in 2022

🖥
As we come close to the end of the year, I wanted to take some time to reflect on what we learned in 2022. This year, Theropod published a set of diverse authors and topics ranging from How to Get Students in Front of IBM Z to deep technical topics like How to Stop Failing Fetches.

The top three most popular articles on Theropod this year were:
3. IPL z/OS without an Automation or an HMC by Kevin Miner
2. z/OS Modernization, when all you really need is a knife by Mike Koster
1. 3270 is Terminal? by Neil Johnson

You should check them out along with all the other great content that was published this year.

To celebrate another successful year of the Theropod publication, I asked our authors to provide us with their reflections of what they learned in 2022.

Here’s what they had to say:

Joe Bostian
Software security is a more important topic in 2022 than ever before. All stages of software development, test and deployment are under attack from bad actors who use increasingly sophisticated methods. The software community is moving in several directions at once to respond to these threats, and the hard part as a member of this community is knowing how to participate. What are the best practices and most efficient workflows that enhance security, while still allowing us to be creative and inventive? The key here is to not only manage the risks that we see today, but to be agile in our responses to new and novel threats that will emerge next week, or next year. Efforts to harden our processes to attack will have a cost, but this must be balanced against slowing the pace of innovation. This balance can be achieved, but it will require us in the software community to value secure practices in our workflows more highly.

Frank J. De Gilio
In 2021, I talked about how hard it is for people to change. At the time, I was thinking primarily about people who had been managing systems for decades and how they need to adopt and adapt to modern practices. While I still think that is true, there is equally a need for people who have been doing traditional DevOps work in the cloud to understand that their way of managing applications needs to morph as well.

Today, a lot of traditional cloud developers see managing performance and availability as a function of the number of nodes that are available. This assumes a scale out strategy. In a world that scales up as well as out, managing for performance and availability requires a different perspective and can make these developers uncomfortable. It is as hard to get one of these people to embrace a different perspective, even though they don’t have years of experience driving it.

Helping people see the value of change takes time, effort, and patience. Providing facts is not enough to help people see how they can be effective in a new paradigm; it requires an understanding of how it is done today with an effective translation to the new model. People need to see the path you want them to follow. You need to explain, describe, and demonstrate the path multiple times before they are ready to walk it with you. Patience, active engagement, and appreciation for the current model are important
tools for bringing that path to someone if we expect them to change. Vitriol and stubbornness should be expected and endured if you want people to ultimately embrace change.

Michael Gildein
As I reflect on 2022, the lesson that has come back on multiple efforts reaffirms the old adage “change is hard”. Adaptability is key for successful business but is often a weak point for individuals and teams. It is easy for teams to continue doing something the same way they have for years (even decades) or to blame rigid business processes and audit requirements as a reason to not change. Many agile, lean, and DevOps frameworks help teams focus on adaptability and automation for a reason. We need to
continuously ask ourselves a relatively simple question, “how can we improve?”. Then, take a small step via concrete actions to experiment and see if that helps move us in the direction of our end goal. I found the key for me, is to continuously challenge myself to improve and embrace the sentiment penned well by Benjamin Franklin, “When you are finished changing, you are finished.”

Anthony Giorgio
I learned quite a lot in 2022, as it was the first time I was formally responsible for leading a team and bringing a project to market. I took a position as a lead developer on the Z Open Automation Utilities (ZOAU) project, and hired a team of developers to assist me. Being the lead exposed me to all sorts of details about releasing a software product. While in the past I had only concerned myself with making sure all the technical details
were correct, I now had to contend with the formidable IBM bureaucracy as well. Learning how to navigate the maze of paperwork and approvals has been quite an experience, and I keep getting exposed to new details I never considered.

I also learned how to start delegating authority to my team members. Learning how to decide which assignments would be the best fit for each team member, and letting them complete the assignment to the best of their ability has been quite an adjustment. I had to learn how to take a step back and give my team members room to grow on their own. It’s a bit nerve-wracking at first, especially if they take an approach that I wouldn’t have considered! Letting the team grow and meld into a cohesive unit is necessary for us to deliver high-quality products.

Suman Gopinath
In 2022, from a product development perspective, I learnt how things must go slow to move faster. I learnt that there can be strong developers, but it takes time to build a team that trusts each other and only this team can deliver. I also learnt that “no” is an accepted word in the technical circles, contrary to what many people think and that customers understand why features and products may take time and can take “no” for an answer if the reason is valid.

From a change perspective and while convincing customers and other internal stakeholders to change, I learnt that it is hardest to accept change when it involves something that was personally built; and certain processes exist only because things have been viewed with a one-way lens. The way I have learnt to tackle this is to not give up and continue to persist, for example, by identifying a set of scenarios or questions that the current solution or process or automation cannot solve but ones that can plant a
seed of doubt or an inquiry in the stakeholder’s mind, to question their own practices. Even if it doesn’t directly result in change, it has helped point the stakeholder in the right direction.

I also learnt that the more you listen to people with different perspectives and from different technology areas, the easier it is for you to see the broader picture and the clear synergies even if they initially seem like disconnected topics

Jim Herrmann
What I have learned, or perhaps “come to understand” would be a better way to put it, in 2022 is that it appears that most college graduates in computer science have the mistaken belief that the mainframe is old and dead technology, and because of it they don’t want to learn or work with it. So, even though the mainframe still runs the world, and probably will for the foreseeable future, it’s shunned by the young. IBM is beginning to do three things to change this narrative. First, hiring bright non-computer science people who are willing to learn. The very good IBM term for this is “new collar” jobs. Second, delivering tools that makes z/OS easier to use and feel less foreign. Third, telling a better story about what the mainframe is, what it does, and why it’s the best tool for enterprise use cases. These are all solid actions to recruit the next generation of people who will do the care and feeding of the machines the world depends upon for so much.

For more Theropod stories relating to new Z talent, check out the tag Z Stories

Mike Koester
What I have learned in the last year can be summed up in one word, ‘CONSISTENCY’. I have been working with hundreds of systems that are all being managed by different personnel. Since they are being managed by different personnel, each have their own unique way of being managed. Due to their uniqueness, each one has their own set of challenges when using them. This showed me more than ever why one would want to
look at modernization. Modernization gives you the ability to automate some of the procedures you use and makes it easier to share them. By sharing procedures and automation, you bring consistency to the way the systems are managed which helps alleviate some of the challenges you may currently be facing when using the systems.

Barb Leinberger

2022 solidified the belief that moving the mainframe culture relies on getting back to what got people excited about computers. The magic happens when people are curious and open themselves to the what if possibilities. Rekindling that feeling is more difficult than I thought, but no impossible. One way I tried to spark that excitement has been through the creation of hack-a-thons inside and outside of IBM such as the SHARE hack-a-thon. A hack-a-thon gives people the flexibility to explore their creativity while also learning something new outside their daily task.

In 2023, I hope to see more of these initiatives for the mainframe community.

David Rice
Over the past year, I have really come to learn the need for developing solutions that don’t just work for the group I am focused on but work across a much larger playing field. We have been working on creating a DevOps pipeline for hundreds of z/OS applications, and the key for making this work is that all the tooling needs to be generalized and easy to consume. This may sound like a one-off situation, but many of our customers face the same type of issue. There are many other things I have learned this year, but this seems to stand out above the others.

Steven Perva
In 2022, I saw an incredible surge of open community-focused growth. The value of building a collaborative community is something we take for granted outside of mainframe technology. As projects like the Open Mainframe Project become cornerstones of collaboration, it’s encouraging to see both user and vendor communities crop up to support the needs and growth of the industry. IBM’s z/OSMF Guild and z/OS Open Source Guild are both inspirational communities that really listen and interact with their users. These venues, alongside educational initiatives like Z Xplore, provide budding opportunity for enthusiasts, hobbyists, and professionals to build skills, foster new ideas, and bolster the platforms usability. We’re at an inflection point in the platform’s history where new professionals are coming in with not only the skills necessary to fold zSystems into existing enterprise architecture, but also the desire to show how it can be done. Industry media likes to focus on decades-neglected infrastructure as an indicator that the industry has plateaued, but the community emphasis of the past few years is demonstrating that not only is the mainframe growing, but starting to smooth out any points of friction that some may use as an excuse for avoiding the integration/adoption conversation.

My hope for 2023 is that we see continued community growth, amplification of mainframe culture, and the continued normalization of integrating mainframe systems with the rest of the enterprise. For those who would like join a growing collaborative community to have real-time conversations with hobbyists, experts, and enthusiasts of all skill levels join the System Z enthusiasts Discord Server.

I want to close this article by thanking all our readers for supporting our publication, and our writers and editors for creating content that is meaningful to our audience. If there is a topic you would like to see on Theropod next year, leave us a comment and don’t forget to share with us what you learned this year. Happy Holidays and Happy New Year!