Enterprise Tech Journal - 2016: Issue 2

Tech Talk

Mark Schettenhelm 2016-05-06 04:10:36

Why Are Mainframers Not Invited to the Table? My background is in mainframe development, and I suppose I still consider myself a mainframer. As such, I often find myself in conversations with my mainframe peers where I keep hearing the same thing: When there are meetings, discussions and plans being made, mainframers aren’t invited to the table. There must be a reason behind this troubling reality. How Did This Happen? I have my opinions on how this happened. I think it came from a gradual separation of the rest of IT from the mainframe. As I stated in my previous column, mainframers tended to tune others out for being behind and constantly relearning what mainframers solved long ago. This tuning out enabled a split to form between the groups, which only spread over time. During this period, the distributed side progressed with new technologies and practices, many that were initiated on the mainframe but were perfected elsewhere. These practices, such as Agile development, have led to what we now call DevOps. But really, this is just a quickening of the pace of development and delivery. What was happening in the mainframe world? Well, not much. Practices barely changed from the 80s, with the development environment remaining green screen ISPF while successful developments and practices outside the mainframe were “tuned out” and seen as inapplicable to the mainframe. Without getting into a discussion and learning from each other, as colleagues are supposed to do, mainframe development and the rest of IT evolved on separate paths— separate islands really. This was the genesis of what we now call Bimodal IT. Agile development and DevOps aligned better with the needs of the business than Waterfall development and its long cycles. Reporting tools and dashboards were adopted and the mainframe was not brought in. Without the visibility they provided, this led to the mainframe becoming a mysterious black box. As management began to change, they gave new projects to the groups that were eager to change, innovate and, most important, capable of quick delivery and repair, leading to an even greater chasm between mainframe and other development teams. Slowly, over time, less and less was asked of the mainframe, and mainframers have since felt excluded from the process. How You Can Change This It is not too late. Mainframe teams can catch up and all of IT can go forward together. It starts as many great things do: with conversation, sharing and realizing we are all in this together. We are more alike in what we do and in the problems we solve than the hardware and languages that separate us. To put it in the way that always seems to make us smile, it is after all, just ones and zeros. So, let’s start with that; we have some different expertise, but in the end a common goal to serve our users. Let’s look at the problems we need to solve and determine how best to solve them. But we cannot ignore what is at the heart of this: the differences in methodologies. If mainframe development doesn’t evolve, it will not be able to match other development groups. There needs to be a mesh of the rates of development and delivery. They must spin at the same rate for mainframe evolution to work. Part of the honest discussion and communication that must occur is a sharing of how things are done where both sides examine practices and pinpoint “best practices.” What can be done to get both sides moving at the same pace to bring the mainframe into DevOps? The hard part will be asking your peers what they feel needs to be done. But to do this, don’t be defensive; listen, take it in and work together. The mainframe environment is different, so “how” it is done will likely be unusual to those outside. Instead, concentrate on “what” needs to be delivered. Just Start I call on my mainframe peers to lead the change. Sit down with your colleagues and start to explore common ground. See where you can adopt common practices to increase agility. Look at areas like your source code management, automated testing, code coverage, application analysis and collaboration tools. These form the necessary framework for greater speed and will get you out of the 80s. Yes, your operating system, languages and tools may differ from other platforms but the end goal is the same. Make sure they match functionality and support DevOps. Look for opportunities to ease teams into working across platforms. The interfaces are more important than the back- end so use a common integrated development environment (IDE) such as Eclipse and standardize on reporting and collaboration tools. Find ways to get your metrics displayed alongside other platforms in the dashboards. Become visible and able to be compared. We know the power, stability and efficiency of the mainframe. Saying it is one thing, demonstrating it is another. Lay the groundwork to spin up to Agile development, show some progress and begin to fit into DevOps. You will find that as your agility increases, your ability to deliver increases, your ability to share common terms, tools and practices increases and so your presence at the table increases. We must end this division, and it starts with you—you can do this. You can earn your way back to the table. Mark schettenhelm, a product manager at Compuware, has more than 30 years of experience in the IT industry. Before joining Compuware, he was a software developer in the healthcare industry. In his 25 years with Compuware, he has been instrumental in helping bring the Compuware mainframe solutions to the forefront of the industry. Email: mark.schettenhelm@compuware.com

Published by Enterprise Systems Media. View All Articles.

This page can be found at http://ourdigitalmags.com/article/Tech+Talk/2476965/301400/article.html.