Anna Murray on the Value of Collaboration in an Automated World
Reg Harbeck: Hi. I’m Reg Harbeck, and today I’m here with Anna Murray, who is product management director at Rocket Software. Welcome, Anna. Maybe we can start by getting the sense of how did you end up in the mainframe space and at Rocket Software?
Anna Murray: Well thanks, Reg, for having me. I really appreciate it—and that’s not a direct answer actually. I happen to be in the gap generation where we all thought the mainframe was dying. So my story actually begins back in 1999 when I entered the space of automation. I started working for a company who did centralized automation across platforms, and those platforms included mainframe—so it included IBM mainframes and Unisys mainframes. I’ve done a lot of work around software development, except writing software. So I’ve done everything from technical writing to business analysis and quality assurance, and then I helped a team through an Agile transformation going from Waterfall to Scrum, got myself involved with the whole Agile area which as our audience probably knows and you know, leads to DevOps. As I got involved with that transformation, I moved into product ownership and then product management. I left that company and joined Rocket Software, which was formerly ASG Technologies a couple of years ago. They hired me because I knew how to spell IBM. I knew this much about mainframe and had some respect for it, but really didn’t understand its impact on this planet. What was really been very interesting is learning really fully how powerful the mainframe is over the last few years. I didn’t ever really think it was dying, I just heard it a lot so I didn’t give it much attention in the 90s or in the 2000s. I kind of figured, well it’s going away, but we serve that customer base and we’ll take care of them as long as it is around. Then I got to ASG and learned the power of the mainframe and learned to love the mainframe community, and understand its place in this world. Then Rocket acquired us last year some time, and so now we’re all Rocketeers and very excited because Rocket brings with it a really strong tradition of mainframe love. I now manage products at Rocket Software for automating DevOps value streams for our customers. We connect the dots from mainframe to cloud, and that’s where I’m very passionate about helping DevOps teams be able to automate their DevOps tool chain across their entire environment. You know that can be really challenging when you’re trying to blend your mainframe and distributed systems. We talk to customers everyday who are facing those challenges.
Reg: Well you’ve touched on a number of really interesting things to me. One of them, of course, is just the idea of DevOps. You know so many of these things like DevOps, like ITIL, a bunch of other things, have their starts—you know, virtualization—have their beginnings on the mainframe in the 60s and 70s and in many ways really were fully manifested in the 70s. Then we have this whole journey of the rest of IT sort of picking up the burden and slowly discovering the mainframe and on the one hand learning lessons from the mainframe, but on the other hand sometimes teaching lessons to the mainframe, and so everybody kind of moves forward on that. But the other thing you touched on that I just want to mention before I ask the next question is the community, you know that it’s such a spectacularly interesting and important part of the mainframe. No matter how excellent the technology is, the community is not merely excellent but wonderful, and I sense that that’s been a part of your journey of learning that we’re not just the technology but a community. So maybe if you can paint sort of a picture of how your journey toward DevOps has also been a community journey.
Anna: Well, that’s an interesting question. You know as I’ve gone through really the Agile transformations, and when I learned about Scrum, I went and I became a certified Scrum master and ultimately a certified product owner. The Agile manifesto really spoke to me, right? Because the very number one value in Agile manifesto is individuals and interactions over processes and tools, and I am very much about working with people. In fact I think part of what makes me a successful product manager is learning to listen to the different people on a team. And as my journey has progressed and I talked to an engineer or a QA person or technical writer, then to product marketing or marketing and then sales—you know a long time ago before I had learned all of this—I thought oh, if I’m talking to marketing or sales, it’s the same thing. And it’s not [laughs].
Reg: Yeah.
Anna: Marketing people think differently than salespeople think and if you talk to an engineer, they don’t understand marketing or sales at all because engineers think differently. And so for me, I had been learning that over time anyway, and so as I learned more about the mainframe community—which is heavily engineers, right?—I learned a long time ago that mainframe engineers were different than distributed engineers. They communicated differently, generally speaking, and it took me a long time to try and figure out why. I think part of it has been that there’s just been this big disconnect between distributed and mainframe for so long and those silos are just so strong that like these people don’t even talk to each other [laughs]. And they’re forced to and then like feel disrespected by the other one, and so then their shields go up and it becomes difficult [laughs].
Reg: Oh yeah. Those silos.
Anna: So I’ve had that experience and to me the journey for DevOps and the individuals and interactions over process and tools just sticks with me—not just for Agile and Scrum but for DevOps. DevOps is super tool-heavy, right? We talk about tools and there are hundreds or thousands of DevOps tools and for me, DevOps is still not about tools. It’s about the people. Why in the world are we doing this? Why are we doing automation of the different parts or the development and operations tools chains and building those tools? It’s for the people.
Reg: Right.
Anna: It’s for all of those people trying to manage the chaos, man. So it is about the people, and then when you’re having to change—because we all do have to change. We all have to grow and change—bringing us together, bringing the mainframe and the distributed together to help each other see their sides of the story and realize that actually we all have the exact same goal [laughs]. If we will respect each other, then we can figure out a solution to this problem, because each company has their own journey to take on their DevOps journey and they’re going to face specific problems that that company is dealing with. But if you have an open mind and you’ll respect each other, then you can solve any problem.
Reg: I like that. Now one of the things in the history of technology—it’s always been the case—is we come up with the latest hot word or hot phrase, and everybody uses it in all the meetings and the articles, that kind of stuff. So one of the challenges we have, this bit about Tower of Babel experience where everybody has a different meaning for the same word or different words for the same thing, and I think one of the challenges with DevOps is it’s still a relatively new concept even though it’s built on this established concept and culture. So maybe if you can kind of draw a picture for us about how DevOps came to have a distinct existence and what it actually means in terms of the value of the results.
Anna: Okay, that’s a big question [laughs].
Reg: I know you can handle it.
Anna: So I’m going to start at the end and then back up, because I want to talk about my definition as you talk about the Tower of Babel here. What is the definition of DevOps? There are several of them floating around out there, but the definition that I’ve come to is that DevOps is a philosophy that focuses on communication and coordination across teams, with the goal of providing better digital products and solutions to our customers as efficiently as possible. And so at the front end, DevOps is a philosophy, and to me, that is core of under—how to fit it into your lexicon, right? And how to fit it into what you’re talking about. Yeah, we do DevOps.
Well, you don’t actually do DevOps, because it’s not a thing. It’s a philosophy. It’s a thing that you’re trying to achieve. It’s a way of thinking so that you can bring your teams together, so that you can unify your processes. And where did that come from? It was really born out of Agile practices, out of necessity I believe. So when we think about Agile methodologies, they were evolving really in the 90s, and the Agile manifesto itself was published in 2001. So okay, great. We’re all going to break into smaller teams. We’re going to develop more code faster, and we’re going to be really good at it. Well that drove a very strong need for wait a minute: If you’re going to deliver software faster, how are we going to get it to our customers? How do we get it into operations? If you give me code every day, I really can’t give it to my customers every day. That doesn’t work for my business, right?
Reg: Yeah.
Anna: Some businesses can. If you’re a SaaS model you probably can. You could even do it hourly if you want to. But what if you’re producing software that’s mainframe-based? How often do you really want to distribute that for your customers? Your business decides, but the whole idea behind build software faster and Agile methods, DevOps, then coalesced five or six years later. So around 2007-2008, there started to be DevOps conferences and people realized we have to think about development and operations together. That’s great. The mainframe community went yeah, we know about being Agile and we deliver software all the time, and of course you have to put it into operations. You guys are silly. You know maybe they didn’t say that, but I think they were thinking this because the mainframe community really didn’t adopt DevOps at the same time. I think it’s really been only since about 2015 that there has been this stronger push in the mainframe community to say DevOps is a real thing and it makes sense that—who knows? Maybe the mainframe community said oh, okay. The distributed side of the house really finally understands and maybe we can come together now [laughs]. You know?
Reg: Go ahead. Keep on.
Anna: No, go ahead.
Reg: I was just going to say do you think that the slow but inexorcable turn of generations on the mainframe might be part of—you know 2015, it might have been sort of the tipping point where we have enough new people who want to try new things, and the established people sort of are giving way to them enough that something new like DevOps—which an established person would just say well look, I’ve got a hammer. Everything looks like a nail. I’ve done this before, but the new person is like, I’m learning this as I go. I see differences. I want to bring this in. What do you think? Might that be part of the reason?
Anna: I really do, honestly. I think that the generation gap is a real thing, and knowing that I’m part of that gap makes me realize okay, so my children and their—you know ultimately there’s millennials and GenZ are the ones that picked it back up, right? They said oh, there’s a career here to be had. We can do this and there’s a need here. I love Dr. Cameron Seay and the work he’s doing to train that generation.
Reg: Oh yeah.
Anna: And his passion. He’s amazing. And so when you’re training up that generation, they’re being trained on VS Code and they’re being taught application programming on the mainframe to start with. You don’t become a Sys Prog overnight, so you’ve got to start them somewhere [laughs]. Then these young people join a company and they’re used to using VS Code, and they can do application programming. Then they talk to the gray hair who knows exactly what they’re doing in ISPF and has been doing this for 30 years, and they can’t communicate that. They learn and I think they want to know—like you said, there’s a need. There’s a driving need—
Reg: Yeah.
Anna: That hey gray hair says I actually want to retire some time and play with my grandkids, but they also love the mainframe and they love the products that they’ve been working on for decades, and that love and that passion is hard to overlook. I think one of the things I’ve been talking about for several years now is you need to pair up your gray hairs with your new people coming on board. Pair them up, have them teach as much as they will before they leave you, and help transfer that love and that passion to the younger generation.
Reg: Yes. That’s so funny because that resonates so much with what we were talking about before we started recording, about how Rocket has kind of gone through that transition as well. I understand that Rocket has gone from being very much focused on the technology to a much more community kind of focus. Maybe you could talk about that.
Anna: Well Rocket has definitely been a product-focused company in the past, and really very strong in product for that matter. But really just now we are transitioning into focusing on our customers’ stories and their journeys, because it’s about their modernization journeys. Over time, because we’re a strong, product-focused company, we were able to strengthen our portfolio and our development processes. In fact one of my colleagues said yesterday as we’ve worked on our DevOps processes with our mainframe software: we’re drinking our own champagne. So we are learning about how to do this. How do we move our source control off of the mainframe? How do we build unified DevOps processes so that whether we’re working with distributed or mainframe software, we can unify our processes and be more efficient?
So we’ve implemented DevOps in our environment and we’ve realized we’ve actually had a big transition in the past year. We have a new CEO. It used to our founder, Andy Youniss, who ran Rocket for a very long time. He handed over to Milan Shetti and we are shifting our focus at this point to be about modernization. We are focusing in three distinct areas: Infrastructure modernization, which is the area I work in with automation and orchestration. I also manage a JCL management product on the mainframe. So this is infrastructure modernization, but there is also data modernization that our customers are working on, and application modernization. So while our customers don’t necessarily look at it in those three pillars—it’s all ugh. We have to modernize is really the thought—but we look at it in those three channels so that we can really focus and help customers in those areas. Because we find that in our conversations with them, those are the areas that they’re struggling.
Reg: Well, you know this whole concept of modernization is so funny, because on the one hand it is obviously necessary. If you’re got a clunky interface that just isn’t humane in the way that people have to use it and isn’t consistent with what a new generation expects from their interfaces, that’s worth updating to their perception. But on the other hand you know it’s not modernizing a car to get rid of the wheels, especially if you don’t have anything to replace them. I think there’s too many people who want to modernize off the mainframe vs. just modernize the business value regardless of where it resides. I’m going to guess that whether you’re talking infrastructure, data, or applications, that as you deal with your customers one of the challenges is to help them think clearly about what is modernization that has a business value vs. just attitude.
Anna: True—and in fact we did some surveys. We did a Rocket state of the mainframe survey recently and one of the questions we asked them was how critical is their mainframe to business operations? We’re trying to kind of get at the core of what matters to them as they’re going through modernization, and 80% of the respondents said that it was very critical or critical to their operations. That number is really high. Now we’re asking IT operations leaders about this—
Reg: Yeah.
Anna: So this is critical to our environment and in fact a lot of what happened I think is with the pandemic happening, many companies who had mainframes realized they’d been ignoring their mainframes. They were taking them for granted, I think in a lot of ways where oh this mainframe was just working, but it’s expensive. In fact, I’ve heard some companies say I’m trying to overcome this perception in my company that says that it’s old, slow, and expensive. Well if it’s old and slow and expensive, it’s only because you haven’t been doing something, right [laughs]? Right?
Reg: Yeah.
Anna: They need to be investing in their mainframes in the right way—and in fact we find that more companies are investing in their mainframes than divesting. It’s maybe the very smaller organizations that have a really tiny mainframe footprint and realize um, you know this isn’t really what we need. We can do this a different way because we’re a small company and we don’t need the power of the mainframe. Fine. That makes sense and they’ll replatform. But more than anything, people are realizing wow, I need to update from my z12 or z13 or something older. Like we’ve seen z10s still out there and even older—they just kind of ignored them. The modern mainframe is an amazing machine.
Reg: Oh yeah, the z16.
Anna: I think you could talk about that a little bit.
Reg: Well I’m of the opinion that the IBM z16 is the greatest business computer ever created, although I’ve been advised by people I trust that yeah, that’s because the 360 originally was the greatest computer ever invented. And then Kevin Stoodley, who is one of the key people in the mainframe space at IBM, told me as long as you say “so far”—because of course the next one is apparently going to be mind-blowing even more so. But it’s so amazing to take a look at this objectively and say this is the machine that embodies everything we’ve ever needed to do with business computing. So obviously having the customers understand the whole relationship thing, and I can see how DevOps strategy then can be a really valuable tool for building a valid perception, today and going forward.
Anna: Yes, definitely, and we work with customers that are upgrading to z15s, or z16s at this stage. Some of them keep one version back because that’s where they want to be, and that’s fine. We also find a lot of our customers are not deplatforming, but they are outsourcing. So the outsourcing market with several different outsourcers—including Kyndryl and Ensono, and there’s more of them out there—we like to partner with as many of them as we can because our customers are going with those outsourcers. That’s introduced an entirely different set of challenges for those customers. It’s maybe more cost effective for them. They’re outsourcing because they can’t find people to hire to work on their mainframes and so they think, oh well, we’ll outsource to someone who has people and that way they can manage the mainframe for us and we can still get the transaction processing that we need and we can get the modern hardware [because] our outsourcer is going to keep us up to date on modern hardware. So we are finding—and I’m sure you know this too, Reg—that their number of MIPS is still going up every year.
Reg: Oh yeah, oh yeah.
Anna: But the number of actual sites running mainframes is going down. So that juxtaposition is happening, but it isn’t because companies are necessarily getting off the mainframe, they’re outsourcing. So then who is doing the development? If the outsourcer is doing the development, it’s a challenging thing to coordinate from a people perspective, right? So this is where the people become involved and how do you make it flow across your people, and especially if you’re triggering things that have to happen both at the customer side and at the outsourcer side as well as whoever their customers are, right? So you’ve got all of these interactions happening and how do you make sure that all the right people are involved? How do you make sure they’re triggered when they’re supposed to be triggered?
For me, that comes back to automation. You have to automate or else somebody is going to forget one of those connections and somebody is going to be left out and you’re going to forget part of the chain. It’s just human nature. We can’t remember everything, and so what we as humans need to do is design the process. We need to figure out how is this going to flow from my company. What are all of the points to make this development and operations happen for my customers? I’ve been joining the value stream management community.
So there’s a value stream consortium that I’ve joined and it’s going back all the way to the manufacturing time, where value streams are in manufacturing and you talk about your supply chains. You talk about how you get from creating your thing to delivering it to your customer and getting it out the door. So how many value streams does a software company have? How many value streams does a bank or insurance have for building software? Usually, hundreds. And so then you’ve got hundreds of things that you’re trying to produce and keep track of and make sure that it is high quality, that it is secure, and that you’re delivering what matters to your customers. And it’s way too big of a problem to try and solve all at once because there are too many moving parts, too many variables. Let’s break it down.
So that’s why when we have talked with customers who are going through their DevOps transformations on their mainframe, we’ve had a few different conversations. I’ve had one where they came to us and said oh, we tried our DevOps transformation. We tried a big bang approach and it fell flat on its face. How do we even get started with this? They were totally overwhelmed because they said, oh let’s look at the big picture and do the big thing. Well, there’s too many people involved and there’s too many problems involved to do that. So actually that triggered a talk at a lunch and learn I did at SHARE in February—
Reg: Cool.
Anna: We talked about how do you get started, which triggered some other really interesting conversations. And what I’ve found is that most of these companies are starting with their source control and saying okay, we currently manage our source on the mainframe, but part of unifying a good DevOps process across products is to get the source code off the mainframe. How are we going to do that? There’s some pretty good standards that are evolving and we are able to help our customers make some choices or even support them as they go with open-source solutions to make that happen. It’s a very interesting journey to watch as they go through this.
There’s other steps of course in the journey, and some challenges customers are seeing is either they have trouble testing, so they’re having problems because of automated testing. Part of DevOps means you’ve got automated tests built in. Part of DevOps is you’re running security scans all the time. Well do you have good security scanners for the mainframe? That’s the challenge. That’s a space that’s not real strong right now because the mainframe was always seen as secure, right? And it is secure but you know the more we give it respect and the more people know about it, the more we need to watch out [laughs] because there’s bad actors all over the world.
Reg: Yeah. Oh yeah.
Anna: So you’ve got to make sure that you’re doing all of those steps and taking care of the process.
Reg: Cool. Now as I think about and you’re talking about, what you’re dealing with is basically a goldmine of legacy. You’ve got so many different individual components and constituents and cultures, and the biggest problem is it works—because if it didn’t work, you could just throw it all out and start from scratch. But the problem is not only does it work, it works so well that those shops that still have mainframes have by and large figured out there is no other platform they can do this with at the cost-effectiveness.
Anna: Right.
Reg: And so to have to use the old long-tail approach of having to look at each individual aspect rather than having to group things and treat them as generically similar. That’s one of the challenges obviously on the mainframe is you’ve got stuff that’s 58 years old, plus whatever predated the mainframe, and have deep culture, deep roots in some cases that have to be genuinely understood even to move on the mainframe, let alone move off the mainframe.
Anna: Sure.
Reg: So I guess the fact that DevOps is a strategy that becomes a very detailed and very specific strategy you have to investigate, which is amazing. You can talk about how do you then take a DevOps approach to strategically moving such an organization forward?
Anna: Well, you know I think there’s a lot of steps there, and Rocket offers some help. We have solutions and even supports to help you through some of that. My particular angle—I feel like one of the things that’s left out is the automation, the centralized automation of what you’re trying to do to pull things together. And so really, I think about it as three pillars to maximizing their approach to DevOps on the mainframe. They need to visualize how it’s going to work. They need to design what they’re trying to do. What is their company’s goal, right? There are many unifying tools that we can use to save costs. So if you’re using, I don’t know, three or four or five different tools to do builds, do you need them? Do you need three or four or five pieces? Like you don’t need Jenkins and Azure DevOps, and you maybe don’t even need Jenkins and five other tools that it can support, right? So a lot of what’s happened is that companies have tried so hard to start moving in this direction that all the different teams in the company try out a bunch of different stuff and they get something working. They go, oh look what we’ve done. And now they can’t walk away from there easily, but now you’re paying for either support or tools that are doing the same thing across the company.
So you visualize first. Okay, what are we trying to accomplish? What matters to us? You need to have overarching goals to help your process and you need to know, okay? Because then it will help you if something doesn’t matter. You can say look, this does not matter to our overarching goals. Focus on the goal/eye on the prize, because it’s very, very easy to get distracted. There are a lot of problems. We always have more problems to solve than we can, right? This is true of anything, any process that we’re doing, so just stay focused for one thing. Decide on the tools you want to use. Where do you want to unify your processes? Are there things you want to be unified through the mainframe? Fine. If you want it unified off mainframe, fine. Make a decision. Obviously prove it out, obviously do your proof of concept to make sure it’s going to work for your company, but make your decision and unify.
Reg: Yeah.
Anna: Then how does your process flow through those tools? What are the steps in that process? This might mean bringing through several different teams and several different cross-functional teams even to say okay, what does our process actually look like? How many times is it somebody making a phone call or sending an email to make that part of the process happen? Why isn’t that more automated? So now we start to realize where we’re wasting people’s time, because our people are our most critical asset that we have, right? I don’t like to call people assets because we’re people [laughs]. We’re the ones that can do critical thinking.
Reg: Sure.
Anna: We’re the ones that can see problems that can’t be seen by normal tools, right? So you know there’s the whole machine learning and things that can help. The thing about machine learning is it can show us things that we didn’t know were there, but we’re the ones that still have to figure what to do about what the machine learning told us, right? So it is about visualizing what you’re trying to accomplish, and you have to make realistic goals, of course. But once you can decide on your tools, then you start to adopt the right tools and in some of our customers’ cases like I’ve mentioned, they’ll decide okay, we’re going to move from whatever our mainframe source control tool is to Git. Okay, how are you going to do that? I have one of my cohorts, one of coworkers here at Rocket, he manages a product called Open AppDev for zSystems. That’s been a very popular conversation because we’ve built ports to help customers do better open-source work on the mainframe, and it’s secure and maintained. So maybe you could have a whole other conversation with Peter Fandel, but that’s a step in the process. I find that what’s happening in these conversations is that step is happening before they’re ready to take the next step with what I would talk to them about is orchestrating that work, right? Automating that, but I think even before you can automate, you have to coordinate. Okay, great. We’ve decided on the tools.
Reg: Right.
Anna: We know what we’re going to do. So part of that coordination is how are we going to cross the cultural boundaries, even between our mainframe developers and our open systems developers? How are we going to plan to train everyone so that we can come together? So the big thing is hey, we’re going to make this change, and in fact that’s what Rocket did, but we didn’t say we’re going to go DevOps in a year. Our president Andy Youniss came to the company and said we’re all going to get our source code off of the mainframe into Git this year. So you have a whole year to get it done, figure it out. Get it done. Now, he didn’t dictate how. Everybody is supposed to do that. That’s not his job. It was his job to as an executive to say I endorse this activity. I want you to get this done. It’s an objective of this company that we make this change this year, right? So I find one of the things that troubles me a lot is where most of this change is happening from bottom up, and bottom-up change happens a lot slower than top-down change and so if—
Reg: And with gaps.
Anna: I’m sorry?
Reg: With gaps like massive ravines. It’s like—you know, you’re in the middle of a field of mountains with deep ravines. So you’ve got like COBOL code that was written in the 70s, and you’re not even sure if you have access to the source anymore. Nobody seems to own it to find out.
Anna: Right.
Reg: But when you’ve got it top down, it’s different.
Anna: Yeah, because then you find a way to solve the problem because you’re being paid to do it then. There’s a difference. Our motivations change, right? Because our boss, or the boss’s boss’s boss, has said I will pay you your salary and maybe a bonus if you’ll get it done. Okay, we’ll figure it out. So that motivation really matters and how you coordinate your teams to get them to go do this. It does help with the culture change to say hey, my company as a culture wants to make this change. It’s not just the guy on the distributed team that thinks I’m doing it wrong, or it’s not just from the mainframe team telling the distributed guy, you guys are silly, you know. We’re not pitting each other against each other at that point. We have executive mandates that say we are going to do this, and the companies that have succeeded in this transition I have seen have executives not just mandate it but support it, right? Because it’s one thing to say it, it’s another thing to support it. We will spend the money on the tools. We will spend the money on the training. Because you can’t just say go do it.
Reg: Yeah.
Anna: You have to fund it. So I will say, we’re going to do it and I’m going to fund it. Now go do it.
Reg: This is so important.
Anna: I’m sure there was planning in advance, of course. We didn’t start like Day 1, oh no, now we’ve got to go figure out what we’re going to do. There was planning in advance. It was going to be next year you’re going to make this happen, right? So this year plan, next year make it happen, and we can do some budgeting and figure that out so it’s not magic. It does take planning and that coordination—so Step 1 is visualize. What is it that you want? Step 2 coordinate, and I highly recommend coordinating with executive management.
Reg: Yes.
Anna: And if they don’t buy in, sell it to them. Get them to buy in, because you will be more successful if you sell it.
Reg: Yes, yes.
Anna: So those are Steps 1 and 2. Then you have a clear direction. Then you know what you want to do. You know the tools you want to do. You need to automate as much of that process as possible, and that’s where I call that orchestrating. So visualize, coordinate, then orchestrate. Because if you think about a symphony, there is a lot of moving parts. You have hundreds of people in the symphony all playing different instruments—and all even bringing different tunes and different parts of the melody and the harmonies to the orchestra, right? It would be chaos without an orchestrator, a director, and that’s what brings it together. That’s what unifies it, and each person’s part in that orchestra is very important, you can’t do the job without them. So then you orchestrate this and in our case in an IT space with technology, that means automating it and automating it from a single central solution that you can then see across your company what’s going on. The customers that I talk to and support have hundreds of thousands of little tasks in their orchestra, little things going on in their orchestra. And in the central tool then they can see at the higher level that yes, the melody is coming through. I can hear the harmony and everything is flowing. Wait a minute. That’s out of tune. Let’s go figure out what’s going on over there, right? You can then from one place see what’s going on. And so that’s my perspective on how you get the most value out of this. You really do a lot of planning up front, and you invest in your people up front. Then you codify all of that wonderful work you did in your automation, which Rocket would want to talk to you about, but yeah.
Reg: This is a really important area because here’s the thing: You talked about the infrastructure, which is where the automation is going to go. You talked about the data, you talked about the applications. The funny thing is, with applications we have this wonderful practice of code management, and so when the boss says I want you to get all your code and move to Git or whatever, with the exception of a few orphaned applications, by and large we have practices with that code. We have testing practices on it. But then you take a look at automation—and automation isn’t even always done with code, and when it is done with code, it might be done with Rexx, it might be done with a proprietary language. It might be done automatically, or it might you know, be manually written. It might have been written 40 years ago and not changed since then. So you’ve got—although knowledge of Rexx is essential, it’s not exclusively necessary. And so on the one hand, in understanding the implicit picture of your organization that the existing automation has, but then in building new automation, just having the tools that speak the language of the automation, have the same level of scrupulousness as you have with your applications, must be a really massive issue.
Anna: Well it can be, and companies that do this well have automation engineers. So they have people that that’s their job, and whole departments where there’s even hundreds of people that participate in automation. Because you do have to describe every member of the orchestra, right?
Reg: Yeah.
Anna: Every single task that has to be executed has to be given the full attention of their value, right? And so it could be as simple as defining a JCL that needs to run at a certain time, and it could be as complicated as saying well yeah, we need to run that JCL, but only when this file arrives here and that file arrives there, and this web page is updated and it’s not the third Monday of the fourth quarter. Who knows what this is, right?
Reg: Right.
Anna: So this is where that advanced automation—but that one task is the thing that cares about that. Your whole automation of your whole end to end everything really doesn’t care about that little thing, but somebody has to do that. Somebody has to put that into your system and define those rules.
Reg: Right.
Anna: And so it’s all the more reason that once somebody has figured all that out, you save it so that it’s repeatable every single time without flaw, because somebody is going to put in the rules for that one task that’s going to do its thing. Maybe it is, I don’t know, calling Jenkins to do the build because you want to do that after we’ve done some other kind of scan prior to commit or after commit and before Jenkins does its thing—but it’s coded in. You know exactly what it’s going to do and you’ve tested it. Great. Now it will run forever without fail. Human beings cannot screw it up unless they stop it or get in the middle of it. They would have to do a concerted effort to get in the way because your automation, once codified, gets rid of that human error. I’m going to make a mistake, right? I fat finger, my password—every single day, I promise. So when you think about humans, we are invaluable right because we are the ones with the logic and the problem solving and the ability to see the 30,000-foot view, the ability to see in the smallest detail where there’s a problem. But also, we are really prone to mistakes [laughs].
Reg: Oh yeah. To err is human. Keep going.
Anna: Yeah, exactly. There is nothing new under the sun, right? And in my career over 20 years in automation, 20 years ago people were terrified of losing their jobs because of automation, and I still encounter that sometimes today. But it’s less often because people are realizing, wait a minute. Automation frees me to do my job.
Reg: Yes.
Anna: Automation frees me to do more. So automation really empowers these people to be able to grow more and get better at their jobs.
Reg: Well, and this is the thing is you’re not talking about discrete steps. You’re talking about layers and that’s so obvious in your DevOps approach that the visualization which gets you going remains critical so that you can continue to see, and the coordination so you can continue to keep things running smoothly so that you know as you do that, that orchestration—just like the conductor of the orchestra has to see the people that they’re conducting, even while they’re doing the conducting, so that you’ve got these layers. But it’s funny because it’s a reverse. You know the typical network stack: you have the lowest level at the bottom, your foundation layer, but the foundation layer here is a human layer at the top. You have to keep that human layer of the visual, of the coordination in order to keep everything else running. It’s so fun to see how people actually always only ever were the essential part of all of this.
Anna: Yes, I agree completely.
Reg: So that said, how do you see the future of DevOps, and especially your role and Rocket’s role in this as we move forward? Obviously this is, as you pointed out, an ongoing journey, and having found one level of automation working well, we naturally level up the next level. So if I sort of visualize and say okay, what does the future look like decades from now as we successfully take on this and move onto what comes next?
Anna: It’s dangerous asking someone who is not a futurist that question [laughs].
Reg: Hmm. You get more interesting answers.
Anna: Right because we know actually less. So take this for what it is: I do see a world where we have figured out how to break down the silos between our platforms and we see every computer that’s in our data centers as another system where we do business work, and we work in a unified way across our systems. We have developers who work on the mainframe and love the mainframe even 30-40 years from now, and we’ve built generation after generation that continues to love the mainframe for one thing. We don’t do the gap thing like we did in the 2000s, right? So everybody coming into the IT space, 2000 through 2010 about, I want to say pretty much we skipped all of them who entered the job market. Let’s not do that again in the future. We’ve learned that lesson. The mainframe is here to stay for one thing. I think in the future we’ve learned that lesson. We know that.
Reg: Right.
Anna: The mainframe is a powerful, high transaction, amazing computing machine that now handles quantum computing for us.
Reg: Oh yeah.
Anna: It’s managing a lot of the machine learning and AI that’s happening because it can handle the high transaction in quantum computing, right? So the mainframe plays a critical piece, but it’s not more important than the other pieces of our network, because everything makes our business run. I still need my web servers. I still need good backup systems. I still need all the pieces. I still need my users at my site to have their own laptops, their own operating systems, and everybody needs to be flowing together, right? So that respect to me, my future, there’s no more silos, right? We’ve broken down the silos and we’ve come together to automate across all of those silos to make the best use of everything at our fingertips. We have so much power at our fingertips, and if we work together and we coordinate across those teams, we can elevate what we have to another level, because we’ve come together instead of infighting. It’s not exactly fighting, but at least the passive-aggressive, I don’t want to talk to you thing, right?
Reg: Yeah.
Anna: But instead, we bring our power together and we do something even more. There’s going to be some new technology in 30 years obviously. We’ve learned so much in the last you know, even five years. I can’t imagine in 30 years what comes, but I do believe that automation continues to be key. The automation is still the way to free people to do their jobs. Now what kind of automation? I don’t know. There’s robotics that come out now and they talk about robots doing certain jobs. I don’t know. There’s places for automation and there’s places for people and I think realizing that we can invest in our people to do things that only human beings can do.
Reg: Yes.
Anna: Don’t be afraid of automation. Put automation where it frees our people to bring their whole self to work and their whole self to bring that value. When I bring my whole self—which you know is this much mainframe, right—to you, and we work together because you have history with mainframe and love of mainframe, and you have all of these ideas that can bring the power of the mainframe forward. I have an open mind and say, oh my gosh. If you can give me that piece from the mainframe, look at what we can do from Linux or Windows. And together we can produce this for our company. We came up with a new product together. So that’s where I see that automation really frees the people to be creative, to solve problems that we don’t even know about yet because we’re the ones that discover it. So my future is more one where we work together better, because silos are not there and we know how to bring—we flow, right? So the next level beyond DevOps has already started revealing itself as value stream management, and it’s a lot about what I’ve already talked today, where you do value stream mapping. That’s one of the steps and that’s that visualization piece where you’re mapping it out, but to take it and define the different sections. Okay, great. Value stream management is the next big buzzword maybe after DevOps. What’s after value stream management? Well value stream management is all about flow and I love that with value stream management, because it is about flow. How are we flowing? You don’t flow if there are silos—
Reg: You remind me of Mihaly Csikszentmihalyi—you know writing about flow and just that experience of being one with the task, and how really that’s such a humanizing experience. The other thing that you really make me think of as you talk about—this is something I’ve gone around telling people a lot more recently—is when you write a line of code on the mainframe, expect your great grandchildren to inherit maintaining it [laughs]. Computing is so young. We haven’t realized that we’re creating the future and that—you know, you look back 40 years. That’s great grandchildren. That’s two generations. You look back 40 years and stuff that you or your parents have written is being inherited by kids who could easily be generations in the same family. And so that long-term thinking you’re talking about and the essential humanity of it I think is so important. Any closing thoughts about Rocket, or humanity, or the future of mainframe or DevOps?
Anna: Oh my [laughs].
Reg: Take your time.
Anna: You’re all about big questions, aren’t you, Reg?
Reg: Ah, what can I say? I get such great answers when I ask them.
Anna: You know mostly my closing thoughts are that if you are going through a DevOps transformation, don’t forget that it’s a company by company journey. Each company has a unique journey, and that’s okay. I think people are looking for standards, and one of the things that drove me crazy about learning Agile was—you’d ask for a prescriptive way about doing something and they’d say well, how do you think you should do it? It’s like going to a shrink and them telling me well, what you do think about that? And it pushed back on us to solve the problem, right? And so you do need to solve the problem for your company. What is the right first step for your company to do DevOps transformation on your mainframe? We suggest that you need to visualize and you need to coordinate and you need that executive buy-in first, but then you still need to know okay, technically, what’s the first step? That’s for you to figure out. Yes, we can tell you we’ve heard a lot of companies wanted to do source control management first. Great. Maybe that’s not you. Maybe you have five different automation solutions at your company and they all say they’re centralized automation solutions, but you have five of them. Well, you’re not unified. Maybe that’s where you want to start, and you want to bring everything together into a single automation solution. That’s something that Rocket can help you with.
So what it comes down to is really starting with that visualization. It’s not visualizing what the rest of the world is doing. It is taking input from the rest of the world. It is asking Rocket, it is asking Reg, it is asking ten other people you know, what have you seen? What have you heard other companies doing? I don’t know what I don’t know; please help me, right? Ask for people to help you with what you don’t know, and then look at your own company, visualize what’s going to work for your company, and just start. I suggest starting small.
A customer I was talking to yesterday, he was like yeah, we realize we really want to crawl before we walk. They’re like not wanting to run even anytime soon, right? They’re at the crawl stage. That’s great. Figure out where you are, accept it and figure out how to grow from there. Take your journey forward and do come to Rocket if you have some questions. We have many solutions in this space to help you on that journey, and there’s not just one solution. I talked about a few of them today that are related, but we have a bunch of solutions that can help customers on these journeys. So we would love to have a conversation with people who are on these journeys and see where we can help because for us, it’s about meeting our customers where they are and helping them get to where they want to go. I use that a lot because as far as I am concerned, we can’t sell them any software they don’t already want, right? We can’t help them on their journey if they don’t know where they’re going—
Reg: Right.
Anna: And so we want to help them understand their journey if they don’t yet, because maybe they don’t have a vision yet. We can help them focus on a few things so that they can come up with a vision. Okay when you’re ready, let’s talk about some solutions that can help you with the things you’ve decided upon. So we would love to be part of your journey. And I think that’s maybe where I should end.
Reg: Awesome. Well Anna, this has been wonderful. I’ve really enjoyed it and I’m sure our listeners are also going to get a lot out of this, so I really appreciate you. Thank you so much for taking the time today.
Anna: You’re welcome. It’s been a pleasure.
Reg: So I’ll be back with another podcast next month, but in the meantime check out the other content on TechChannel. You can also subscribe to their weekly newsletters, webinars, e-books, Solutions Directory and more on the subscription page. I’m Reg Harbeck.