Video: DevOps is the hot topic in 2018: Five reasons why
It's four years since the mainframe software company Compuware went from public ownership to private. Now its CEO Chris O'Malley believes the company is ready to reinvent the mainframe software market thanks to two state-of-the art software breakthroughs -- agile and DevOps. ZDNet caught up with O'Malley to find out more.
When did you first come to Compuware?
A little over three years ago. Prior to that, I ran CA's mainframe business unit which is still 55 percent of CA's total business, and the largest mainframe business other than IBM. I see the world through a mainframe lens.
What we are seeing is people moving away from the old style of doing things, which means looking for new concepts and new ways of doing things.
For large organisations that have been dominated by mainframes -- 87 percent of the top 100 banks and most insurance companies are still dominated by mainframes -- it's challenging because they need to use agile and other techniques in order to compete.
Even if you are big, you've got to be fast, because of these new-age companies that you are increasingly up against. So, you have to learn how to be much more adept with digital techniques if you are going to help your customers.
So I brought my thesis into Compuware. Now my thesis was, if you apply all these startup techniques, like DevOps and agile, then the people will come with you.
So I came in, not as a guy who ran a major business unit. I got on stage and a lot of people thought of me as the guy who was going to change everything and not for the better. But, while some of them thought that the devil had just shown up, some of them thought, 'hey, this guy's got some good ideas'. But then I told them to be careful what you wish for, because at some point you're going to hate me, because I am going to make everybody change.
Everybody's role has to be altered. There's not anybody in this room, I said, who a year or two from now is going to think that they are in the same situation that they are now. That's what I said. I told them that in order to be able to win, every role in the company had to change.
The lesson was: stop looking inwards, trying to cut costs and so forth, but make it always about looking at the jobs that customers have to perform and helping them to do that.
People will hang onto waterfall because it's like it's a comfy blanket in front of the fire. In agile, the jobs become more exact.
Download now: Quick glossary: DevOps
Three years ago, I promised that every first business day of every quarter we would come out with new capabilities, new enhancements, integrations with preferred, state-of-the-art DevOps tools linked to the customer experience, and we would make it simpler as we went.
In those three years, we have remade our technologies around the Topaz brand. We have created this Topaz brand and that has created an environment which allows not a mainframe programmer -- because the mainframe programmer is going away -- no, you have to take a computer science graduate and have them know that a mainframe is not different, apart from in syntax, from any other platform.
It's just development and the fact that you are doing it on a mainframe is irrelevant. So what can you do with these applications that have code a million miles long? We visualise this sprint cycle so that now programmers can do changes in 24 hours.
We have built this whole framework that allows this new developer to see things differently. The only thing that shows it's a mainframe is that it is in Cobol rather than C or Java.
When people say that you can't do agile or DevOps on a mainframe, it's completely untrue. We are proving that every day. We've got a Spring team where we have 23-year-old Noah and 72-year-old Judy and they're on a team together. What it has proved is that this crew can do agile on a mainframe and DevOps on a mainframe. We know that the mainframe is irreplaceable.
So, you are saying that you can do the same thing with C and Java and so on, and it doesn't matter what you use to do it with?
Well, no, it does matter because the mainframe is doing things that C and Java can't.
When we started off doing this, we were one company doing DevOps and agile on the mainframe. Now, when we go and see our customers, everyone is doing this.
It's interesting because one of the things about Deming and The Theory of Constraints is that any improvements made to anything other than the bottleneck is an illusion.
That's interesting because a lot of these banks have done their digital efforts with some small, quarantined team. These guys go to events and say they have this team and they deploy 15 times a day and so on. But all of this is a placebo that makes no difference in the eyes of the customers. The work doesn't leverage the IP and the data that's on the mainframe.
So, instead of doing all this work with these small teams, you should start on the mainframe because the mainframe is where all these things need to be realised.
Now, for most companies, the mainframe is not something that they are going to change easily. The mainframe people are a cynical group. But that's where you've got to work to change things.
Where did you get involved with this idea that you could make DevOps, agile and so on work efficiently the mainframe?
I saw it work as a startup CEO with a company that had no revenue and no customers. I had come from a big company to this lab in St Louis because I wanted to do the exact opposite of what I had been doing.
Now, you learn through their work inventing a product using DevOps and you learn that you don't want to do it any other way. The product that we were building was for large companies and, in particular, one very large credit card company.
And the average age of that team was probably about 23, and they all had PhDs, and they would come up with these brilliant ideas. So then you had to match them with the practical demands of a big credit card company, and, on top of that, the credit card company had all these rules it must obey, like compliance. So, there was some difficult conflict.
Now, what DevOps allows you to do is to work like a lab and gain some understanding of these companies and what will work and what will be viable.
Now, you can experiment and meander and get to your destination much faster and so understand the value. Add to that the intensity of the way you have to work: if you're a startup and you have to work very quickly.
At Compuware, I have tried to recreate this, to make it feel like you're working as a startup. Somewhere that has the intensity and where things must work. And it works -- it feels like a startup.
We are building a culture where while, in the old Compuware, if you made a mistake you got fired. In the new Compuware you're making mistakes all the time. You make a mistake twice? Fine, it's in the nature of inventing.
What about DevOps and agile, do you see them as they same thing?
A lot of people say you don't need both -- you can have one without the other. I think that's a fallacy. Agile needs to work with the attributes of DevOps. The idea of automation which DevOps brings is something that you need but you need Agile techniques in terms of the experimentation that it brings.
They are different things but you absolutely have to do both of them.
Recent and related coverage
Forrester examines Agile adoption among enterprises.
We break down why understanding the current maturity of DevOps leads to successful implementation.
A majority of organizations are employing DevOps to some degree, and dramatic reductions in development-to-production lead times are expected.
Simple ways to instill more quality into DevOps (Tech Pro Research)
Along with the benefits of DevOps comes the risk of skimping on QA testing, leading to flawed results. Here are a few easy steps you can take to improve DevOps quality control.
DevOps may be the new paradigm in app development, but a report out from CyberArk reveals that widespread adoption of that approach has become a security nightmare.