Mike: Hey, everyone, this is Mike, and given this is the first episode of a podcast about the mainframe, we’re going to kick things off with someone who’s about as pro-mainframe as it gets: Compuware CEO, Chris O’Malley. Chris, thanks for joining me.
Chris: It’s a pleasure to be here, Mike.
Mike: I was just telling you, I think we need to kind of lay the foundation for people who listen to this. Basically, why is the mainframe so important, to what we do at Compuware and really just to enterprises in general in the world?
Chris: If you take a step way back, for thousands of years, customer obsession has been the means by which companies distinguished themselves, or federal agencies as it relates to citizens being focused and centered on their needs. And that’ll be true a thousand years from now and in today’s world, that customer experience and customer engagement increasingly is preferred by customers or citizens based on a digital experience.
And digital experience is gained by, writing software. It’s taking ideas to engage with customers through digital means and through really good processes, continuously improving velocity, quality and efficiency, turning those ideas into deliverables that make a difference. And that’s why you hear things like Microsoft’s CEO talking about every company is a software company being built by developers.
I mean, that’s an important part of any company or any federal organization’s competitive strategy, well for large enterprises, that are presented with that challenge. Most of them have mainframes, and mainframes play an essential role in what they deliver in terms of value every day, and for good reason. I mean the mainframe is unchallenged in terms of its capacity to be reliable, be performant, be secure; in its efficiency from a transactional perspective in terms of costs, it can’t be matched by any other platform. And all of those virtues are critical in the digital age.
So, these ideas to serve customers when they come in, they don’t nicely fit either on the mainframe in terms of the system of record or on the system of engagement that may be in the cloud. It’s almost always one where those ideas, to be turned into deliverables that make a difference, need new software to be developed on all these platforms. And the mainframe has gone through a bit of a renaissance lately that these kinds of digital demands are really introducing the mainframe to CIOs as something that’s not to be apologized for, but an awesome platform to support the density of transactions that are created and with engaging with customers through digital means.
So you see in the z14, which is the most recent IBM model, it’s had five consecutive quarters of year-over-year growth. The success of that platform probably hasn’t happened in forever, I mean, it’s been, you’d have to go back certainly decades to see that kind of success. And I think that’s an indication of the fact that the mainframe plays an essential role for these large enterprises and doing things that no other platform could and is really important to engaging customers through digital means. So, all of those things add up to a mainframe that’s doing incredibly well and has a very strong future.
Mike: So, the mainframe platform is modern. You listed off all of the capabilities, all the power that it brings to enterprises and how much they need it. But you had kind of got into the idea that we talk about, “mainstreaming the mainframe,” also.
Can you explain kind of what that message is, to mainstream in the mainframe, modernizing tools for instance, and providing the tools that people need to actually do that.
And I know processes and culture are involved in that too. What does that kind of look like?
And then what do you kind of see in the difference between companies that are actually mainstreaming the mainframe and those that are kind of afraid to touch it?
Chris: That’s a lot of questions in one question.
Mike: I know you can answer them.
Chris: First to kind of simplify it all down, these large enterprises got to be thinking, “How do I turn ideas that matter to customers into deliverables that make a difference?” And when you think about managing that and leading it, you want to center around these KPIs that are really important to make that happen.
One is velocity: how fast can you get from an awesome idea to a deliverable? The quality of it, I mean that experience, rests on the fact that not only are there not bugs, but you’ve thought about the UX implications, and that you’re doing a good job in terms of creating features that create elegant simplicity in dealing with whatever services that you’ve got online. And you’ve got to be thinking about efficiency, that you’re doing a lot of efforts probably currently that, that are wasted. I mean, they’d bring no value to customers inherently and expending money on a non-value-added service just doesn’t make a lot of sense, and you’ve got to figure out how to get and harvest that latency and reinvest it in better ways.
And it just to make it more understandable, if you as a company take two weeks to go through a testing cycle and somebody else can do it in a minute, and the one that can do in a minute can do it as well in terms of the quality that’s produced, or better, there’s two weeks that you’re expending our wasted money, and no customer’s going to pay you more because it takes you longer to test, and certainly not pay you more for taking longer to test at poorer quality.
I mean, that’s like burning money in the parking lot. You’ve got to be fixated on the efficiency of those. These measures of velocity, quality and efficiency you got to think about as a leader and then you’ve got to think, “Okay, how do I get in a state where we’re continuously improving on those measures?”
Part of it is certainly culture. You want to go from probably a scenario where most people look at their jobs as just a job, to one where people are passionate explorers, that they celebrate the fact that customers are continuously, beautifully and wonderfully dissatisfied and are driven to figure out about innovative ideas, to respond so that it distinguishes your company from the next. That cultural portion of it is incredibly important.
The second thing is the process side. Waterfall processes presume the world is corner of maintenance nature, that you’re just kind of responding to the normal noise. Well, you need Agile methods to iterate and actually invent things, create new experiences. Agile is a crucial part of the process changes that you’ve necessarily got to go through. And, in the mainframe world, we’ve done a lot in terms of automation, but it’s been very selective. In the DevOps world, it’s intrinsic. You’re trying to automate everything that doesn’t bring value to the eyes of your customers. The process side of it is critically important.
And then the tooling side, the tooling side has to enable Agile, it has to enable DevOps. Leaders that are thinking about, “How do I get velocity to get better? How do get quality to get better? How do I get efficiency to get better?” Well, to do that, people matter, right? And people matter because in the order of Agile and DevOps, the roles change. What I’m accountable for changes.
The expectations, in terms of my performance on the job, changes. You’re not looking at me like a worker in the factory that’s got some discreet thing that I do over and over again. You’re, you’re trying to broaden the scope of what I have to do. I’ve got to be looked at like a high-performance athlete, and these tools that I use have got to help me to nail these new roles, new expectations and new accountability.
The mainframe historically has been a siloed organization and the cultures were different, the processes were certainly different—waterfall continues to dominate, but t’s obviously moving towards Agile—and these toolsets, were based on activities that may have served the mainframe ranks well in a kind of a maintenance state. But as we get more and more into innovation, the tools have got to be dramatically changed.
We see in terms of the trend is that the mainframe silo is starting to melt away, necessarily so for two reasons. One is that, the people that have been kind of the last great generation of it, workers that have supported this platform for decades, are starting to retire, but they’re being replaced with people who have recently come out of college, who know Agile, know DevOps. They come with a different nature about them, a nature that’s critically important that you want to foster.
The second thing is that, the mainframe silo has got to go away because we got to go from kind of this attitude of being maintenance-minded to being innovation-minded, building new features running at rates that are equal to the non-mainframe platform, in terms of system engagement activities.
We’re seeing a trend towards people philosophically saying, “We’ve got to have Agile, gain dominion over the platform. We’ve got to have DevOps and our preferred toolsets to gain dominion over the platform.” There’s a need to mainstream it to basically be the equal of any other platform and be different only in syntax from how you do things in the cloud or non-mainframe platforms.
When you look at Compuware, we have been a company obsessed with looking at the roles and responsibilities when you take non mainframe people and make them effective in terms of being mainframe stewards of the IP, the code and the data in this age where you’re trying to increase velocity and quality, efficiency all at the same time and getting better and better in terms of being iterative there too and creating awesome products and awesome experiences for your customers.
We’ve been obsessed, and that obsession goes beyond just thinking about the products we build. We’ve obsessed about it in terms of using these concepts internally. So, I will put Compuware up against anybody on the planet in terms of how we’ve embraced Agile as a company. We are a hundred percent agile and we do no waterfall efforts internally in terms of development of our own technologies to support our customers.
You’re always on a DevOps journey. It’s a never a complete thing. But the degree of automation that we’ve built to improve our ability to do automated testing, the process of iterating in terms of our cycle times and the release frequency, we’re pushing it to its absolute limits. We are a test bed, if you will, of knowing how these roles and responsibilities necessarily have to change and how these toolsets need to kind of morph over time and become, as you said, mainstreamed.
And now we just presented our latest release to a bunch of analysts as we do every quarter and one of the best compliments we got is from a non-mainframe person, a DevOps person that’s in the analyst rank saying about our technologies that “you’re making the mainframe look familiar to me. It is exactly like I would expect non-mainframe environments to work, as all of the tool chain I’m using, things like Jenkins, things like SonarLint.”
So our key, all of those things in terms of the experience, it’s just that you figured out all the things you need to do from a tooling standpoint to make that experience the equal of any other platforms. That’s an important part of getting to the point where the mainframe is a first-class citizen with them and that the assets, that code and data, are first-class citizens in all your digital efforts.
Mike: That’s a lot of good stuff. A lot of transformation has to happen. I know there’s multiple angles to this. What’s a simple way for someone to maybe understand how they can actually make it happen? Maybe they’re reading materials from us and sort of getting this understanding that they need to mainstream the mainframe. They need tools, they need to change culture, processes.
Based on our experience and maybe your experience before Compuware in your eyes, what do you actually have to do, that first step in terms of transforming or getting other people in the company on board even? What is it that you have to actually do?
Chris: I think, there are people that are ambitious about this. And usually the ones that are most ambitious, relative to the mainframe, have done it before. They’ve done DevOps and Agile on non-mainframe platforms. They know the parallel efforts that have got to occur to kind of jumpstart that transformation. But not all people have that degree of experience.
If you’re more of a pragmatist, you’ve got to think about these simple things that you want to do and spend more time on value-added services, things that your customers will pay for and enrich the experience of supporting your service to customers. And we want to do less of the non-value-added services or at least minimize them to the greatest extent possible. So, you think of that effort, you want to get into the stage of continuous improvement, right? You want to get a little bit better, a little bit better, so that the weeks and the days and the hours start to matter in ways that you’re starting to see an increased performance in terms of velocity, quality, efficiency.
If I was going to take a pragmatic approach, the first thing that I would do is think about development productivity. I mean, we’re seeing customers currently in using our tools have a fourfold increase pretty rapidly and the number of story points that they deliver in terms of a release cycle. I mean that’s all goodness, cause the more story points you deliver, those are things that are functional enhancements and customers see in customer value. So, getting unleashed from kind of these archaic ways of using tools from 1965 that just oppress new developers in terms of them trying to stress their efforts to increase performance. That’s one area that I would work on the idea and the environment within that space.
Second thing I would, focus on is testing. There’s various research that’s been done in terms of how much testing time is consumes what a developer does every day. And you do hear things that testing is 50 percent of a developer’s activity or even more. So that’s, again, if half of their time is being spent on testing and that can be made one where it’s cut in half or gotten down to 80% less and have as good or better outcomes, you’re giving back a lot of time to developers in ways that are more productive in doing value-added services.
Testing automation is a clear need, and as we work more and more with a global system integrators, as an example, I mean this testing problem, just how much time is wasted in manual processes or just not automating things, that’s low hanging fruit in terms of driving up productivity. So that’s the second thing that I would think about. The order of that would vary by customer in terms of which would go first or second, but both of them are things that kind of allow you to break inertia as it relates to the current state.
And the third thing that I would look at is that, you’re going to have to at some point go from waterfall to Agile because you need to have the ability to iterate in short increments because, in a world of maintenance where all the requirements that you’re going to have for the next year and a half or two years, one could make the case that waterfall is adequate. (I don’t think you can, and I would challenge somebody that would tell me that it’s a better approach). But when you have to work on new ideas and test them with the reaction from customers and basically get the development staff, product ownership, product management to escalate their understanding, you need methods that allow you to get constant feedback.
Agile is built with the idea of fostering that kind of innovative nature, and then increased learnings and trial and error that is required. So as you go to things like Agile, it breaks, all of the incumbent technology, the legacy technology, which has waterfall fused into it. And it also breaks ideas, where in a waterfall world work is predominantly done sequentially and agile scrum masters are constantly trying to load-balance work. And you’re trying to get scrum team to scrum team to do work increasingly in a parallel way, simultaneous way. So you need methods that allow you to do parallel development, be able to branch work, reconstitute it, so that you can get to these two week conclusions in ways that are equal to what everybody expected. So you got to figure out how to do source code management in ways to support agile development.
Those three activities are really important, I think, and jumpstart your effort towards kind of the cultural change, getting people to start working and behaving differently. And then the fourth thing, which is kind of foundational to all of those activities is that you got to start measuring things. I mean, for DevOps and Agile to prosper, part of the way you want to do it is you want a baseline of how you’re doing in terms of velocity, quality, efficiency today, and that as you start injecting these new ways of doing things, new ideas or going to automated testing or going from waterfall to Agile, you want to start to see what’s a fact in KPIs that truly matter.
You want to start baselining these measures, both the higher-order KPIs as well as behavioral data so that you get a sense of what the current state looks like. And then you want to start looking at how those things change, right? And you want a message even to your own employee base that as you start to see an IDE allows you to be more productive, you want people to know that, right? That working differently makes a difference. When you see automated testing improve the time that’s expended on testing and improving the quality of the result, you want to share that. That’s a major milestone that shows that we can get on a journey of continuous improvement, have it make a big difference for the firm.
I see a lot of people who basically measure nothing in large enterprise IT and they just look for anecdotes to say things are getting better. Those days are over when you’re really trying to drive throughput, and the business is expecting these ideas that we come in with to get turned into deliverables that make a difference. You got to look at finding patterns that make a material difference, right? Or you got to find constraints that are holding you back and assess about getting that out of the system so that you’re constantly spending more of your energies on value-added deliverables. So, this idea of measuring becomes a critical, foundational part of getting in this mode of continuous improvement.
So those four things, then you can take a more ambitious tab like retraining from waterfall to Agile and getting into expanding efforts on product management and really building up that skill so you’ve got people who are dedicated to obsessing about customers and feel celebrating the fact that they’re dissatisfied and figuring out ways to improve, building up that skill. But I would take these first steps in order to basically get the broader company on a road of continuous improvement before I probably take those next steps if I was going to do it in a pragmatic way that’s not trying to do all things at once.
Mike: Okay, cool. One more question. We had Gene Kim and in last week and Dr. Mik Kersten from Tasktop, and I know you spent all day with them and Gene is considered a DevOps guru and I know Mik Kersten came out with a book about moving from projects to products. What’s one or two, three takeaways even that you can share with everyone from their visit? Did you learn anything new from them?
Chris: Yeah, it was really intended to be a collaborative experience for both sides. They obviously have seen, and I’ve been witness to, a degree of success in DevOps and Agile that we aspire to. But we are also a company that is reflective of that success, and what is the greatest challenge in probably the worldwide economy, taking a large enterprise that’s done certain things—in terms of writing software for 40 years in a way that’s a force against the efforts to do Agile and DevOps—and we went from 40 years of waterfall and the techniques that we used—in terms of testing and our development practices that resulted in coming out with product deliverables every year or 18 months and not at a scale of innovation that would be necessary, certainly that was necessary for the mainframe market (when I came to Compuware, we hadn’t come out with a product for 15 years)—so we are an example of a company at scale that’s doing Agile/DevOps, having come from a vastly different former state and showing the fruits of that.
Our customer SAT is through the roof, in terms of where it was. Innovation that we’ve brought to the market over the last 17 quarters is unmatched, never happened in the mainframe market before. And, we’re proud of the fact that predominantly all these changes have been done with the people not changing. The people have adapted and have embraced these new techniques, new ways of doing these jobs and creating a degree of success that I’m sure Mik and Gene would like to have every large enterprise achieve.
So it was really a two-way conversation. I think the discussion with Gene and Mik in terms of helping me think about things is that, they’re very fixated on value streams and applying techniques that have been proven within manufacturing principles in terms of the way BMW makes cars and looking at how to apply those within IT.
And then using KPIs is part of the agent of change that you’ve got to try things and try things. You need empirical evidence to know whether those have helped or hurt. And not every good idea helps. Some good ideas can hurt, but when you get a good idea, you also want to be able to quantify just how good it is and that it is a really good idea, embrace it.
But then looking at the nature of work differently, that you’re looking at it in terms of those things that bring value and those things that don’t bring value that you can’t charge a customer for, you want to minimize them to the greatest extent possible. And it helps to kind of, in thinking about things that way, to start to really embrace ubiquitous, intrinsic automation. I mean, these techniques really help you to think about where to chase down these constraints and really make a big difference in terms of our own flow.
I think they came in and were shocked by the degrees by which we’re doing Agile and DevOps. They took a data center tour and they laughed before they came in that this is what they did in the ‘60s. But they came into our data center and what we show them is something that’s empty. And we showed them, through Two-platform IT, we run the company on the cloud and the mainframe. We don’t just talk about it, we did it. We’ve ripped out 16 tons of equipment and we went from Oracle ERP system to NetSuite. We basically run the G&A functions of the company on cloud consumed services. And we don’t rack our own equipment even for the development stuff that we do on the non-mainframe platform, we use AWS.
So, we showed them the elegant simplicity that it has created, how much money we’ve been able to re-harvest that was wasted, that that was non-value-added in terms of managing distributed infrastructure, which there’s a significant arbitrage when you go to the cloud. And then reinvesting that in creating innovative features and functional capabilities, new products for our customers. So, they got to see it right it firsthand, man. And they’re like, every large enterprise should see this. And see not only that it can be done but look to copy where as to how it can be done. And so they were incredibly excited. I mean, it was, it’s hard to capture the reaction that they had, but it was, it was a very cool thing.
They also spent a lot of time with us in terms of zAdviser, and zAdviser is a covenant we have with customers where they’re given us data—and have been for literally a decade—and we’re contributing machine learning as a method of trying to find patterns that help customers to determine best practices of what is the right things that they should be doing from a roles and responsibility perspective within Development and making those developers as productive as possible by treating them like high-performance athletes.
And they were amazed with some of the insights that we’re coming up with. A lot a lot of what we’re coming up with supports what they know to be true on non-mainframe platforms. But the fact that we’re able to capture that knowledge in mainframe environments and assist customers that way, it was really exciting to them.
The DevOps community is one where you share, so we’re sharing, an old company that reinvented itself and is doing things that are making a big difference in terms of success we’re creating for our customers and for ourselves. That’s wonderful to them, to see their DevOps things proven.
They want to learn from us in terms of, as a large enterprise that has done certain things for 40 years. What were your biggest constraints? What were the obstacles? So that’s incredibly helpful, but it’s also helpful because they’re teaching us, as zAdviser was a good example of insights that they’ve learned that they put forward to us to think about and kind of guide our efforts from a machine learning standpoint and in looking for statistical patterns and correlations. So, I think it was good for all three of us.
And it’s exciting times because the mainframe, I think, certainly four years ago it was looked at as something that was a problem relative to DevOps and Agile. And now, to see it as being something that’s becoming a first-class citizen, it’s very exciting. And it’s very exciting for the community. So, these kinds of events are exhilarating for me. We have a lot of customers that come here, nearly every week, and that’s exciting, and it’s exciting to share what we’ve done, and it’s exciting to share what they can teach us, and certainly what we had last week was that on steroids with Mik and Gene. So, very exciting.
Mike: Awesome. Definitely a lot of exciting things happening in the mainframe space right now. Chris, thanks so much for sharing all that.
Chris: You’re welcome. My pleasure.