 Live from Las Vegas, it's theCUBE. Covering Edge 2016, brought to you by IBM. Now, here are your hosts, Dave Vellante and Stu Miniman. Welcome back to IBM Edge, everybody. This is theCUBE, the worldwide leader in live tech coverage. Hayden Lindsay is here as the vice president and distinguished engineer. DevOps for enterprise systems at IBM. Good to see you, thanks for coming on theCUBE. Thanks a lot, appreciate you having me. So, you're welcome. So, let me ask you a question. The world loves habit, right? Humans, we just creatures of habit. We still got green screens, right? We still do covan line interface. Your mission is to change that, isn't it? It is. How you doing? We're making progress. I would like to make far faster progress, but this DevOps for enterprise systems, that's code name for making sure that DevOps that people are doing in the distributed realm gets applied to the mainframe realm with the same first class support. And, of course, that's not how the DevOps movement started. It was working in other platforms. So, we've applied it to mainframe to allow you to have a holistic approach. Everything from mobile, mid-tier, mainframe can all be using the same type of processes to get the agility, speed, and yet lower risk, improve quality for every piece of the system, mainframe included. Now, the challenge, as you mentioned, is that people doing mobile stuff, they weren't doing that 30 or 40 years ago. The folks doing cobalt development very well might have been. And so, changing the status quo, defeating inertia is our mission. Okay, so, I mean, makes sense, right? If you're going to, people process technology. If I got a Z platform, I'm going to modernize the technology with Linux and Docker and, you know, all these, you know, we heard Hadoop. Okay, if I'm going to do that, then I got to worry about the process and the people. So, you're talking about applying modern process approaches to solve problems. For some things that you might not think is being quite as modern as Hadoop or Docker, something like cobalt or PL-1 or mainframe assembler, being the programming languages that are running a lot of the world's businesses. Cobal, for example, represents about, people estimate around 70% of the world's business transactions. And that's running on the mainframe, it's not running on, you know, x86 box. And so, it represents critical business capabilities, the apps that are running the business. But if you're dealing with it, using the process and techniques and tools that you were using 30 or 40 years ago, in all likelihood, there's a lot of waste as the DevOps community likes to call it. It's not as efficient as it could be and so we need to change that. So, Hayden, there's a lot of kind of fossilization of kind of processes there. You talk to traditional IT people and they're like, you know, no, we have our business process, it's going to take us 18 to 24 months to make change. Of course, the DevOps world is much more, you know, let's think of continuous integration. Exactly. Continuous delivery, it's something that, you know, it's tough to get over that hurdle. And especially when a lot of people on the Ops side view a critical element of their role to be to maintain stability. And they equate stability with infrequent changes. And of course we know in the DevOps community that's in fact a fallacy. Let's break it. Yeah, exactly. We'll break it or automate so that you're doing it so much faster and so much more often, you're actually increasing quality, reducing risk, but that requires a mind shift, culture change, and then process change. And that's hard because you're talking about human nature. And so it's not just about throwing a tool on someone's desk or on a server, it's about changing how people behave. Yeah, there's one of the lines we love to use some is hardware will eventually fail, software will eventually work, you know, people need to get used to some of these changes. Yes, for sure. And you know, so that's why we've been investing in this area, we've acquired some companies, we've and extended what they have, we've built some of them ourselves. And we have really good end-to-end coverage, as I said, from mobile to mainframe. And now it's a matter of getting people to make the leap and have the courage to try to do some things in new ways. And we've had decent penetration in some areas, not as good in others, and that's what we need to do. Because the way you think about it, businesses know they need to change. If you don't pivot periodically based on changes in market, changing what competition are doing, you're out of business. And I think line of business understands this, we need to have that same realization within IT. And especially the more entrenched parts of IT. So how do you push on some of those pain points? I know traditionally we go to, you know, infrastructure people, if you can find those things that they hate doing and they're doing it every month, you know, for quarter, after quarter, after quarter, if you can give them a way to get out of that, you know, they're usually open to at least looking at it. You know, how do you move some of this change forward? In general, you have to do exactly this, find the pain. And so the pain a lot of times is because line of business is saying, I need you to do this more quickly. I can do it on the mobile side or the website. I'm having maybe some difficulty getting you to update the back end that by the way has to be made in concert. These things have to be synchronized. And so we can say, we can help you by automating more. Because if you think about DevOps, if you think about agile and lean from the, there's a lot of process and culture change, but there's also an organizational model sometimes. But there's also tool changes. And the tools help mainly by automating. And so there's automation that can be done to reduce manual processes that are slow and error prone. But you have to find that pain. And sometimes it's because the IT group is getting pressure from line of business. I need you to do things differently. And then you do have people that are change agents. And we just go in and try to support them and encourage them, but. Well, the tooling can help catalyze change as well. But so we talked about technology, touched on process a little bit, quite a bit actually. And then there's the people piece that we're talking about now. And the skill sets around. I mean, it was interesting to hear you say that 70% of the world's transactions run on COBOL. People might be surprised about that. But COBOL code, first of all, it works. A lot of it's custom code. And to convert that would be kind of suicide for a lot of these companies. Extraordinarily high risk and take forever and cost way too much. What you need to do in our view, our view is like, it's a hybrid cloud model. Certain things you want to be cloud hosted or running on smart devices or what have you. But leverage the back end systems or back end transactions, data access layers that work but maybe are not exposed appropriately. And so that's where our whole focus around API economy, API management and we have introduced new capabilities to make it easier to expose as RESTful services a kicks COBOL transaction. Or a PL-1, IMS transaction or what have you. And so to anyone on the front end, you have no clue how it's implemented. You just see a RESTful interface. And you've automated that back end. Well what we're doing is. Oh I saw you've automated that workflow. We can automate the delivery pipeline. So you have this continuous integration, continuous deployment. And because there are these linkages. Now you would hope that the interface to the back end service doesn't change often. But at times it will need to change in which case you need to coordinate your mobile app change with a back end or COBOL change for example. Let the tool synchronize that for you. Well it has to change. I mean a lot of that COBOL is running in financial services. It's a highly regulated industry. There's compliance. Oh exactly. I mean that COBOL code is changing. Oh it's changing. I think there's figures, there's one and a half billion lines added every year to the 220, 250 billion that are in existence. That stuff's not going away. But you mentioned something about people. The folks that have been doing this for 30 or 40 years are not going to be doing this 30 or 40 years from now. So we've got to be able to bring in a new generation of folks. We need to have tools that help them grok that 200 and some odd billion lines of code. And so in fact we just did an acquisition a couple of months ago, a company called EasySource that is all about program understanding, discovery and understanding. And yes it's good for doing impact analysis. If I change this what all is impacted so I can build my test plans and determine how long it's going to take. But it's also good for onboarding people. Because if you can see graphical representations of the structure of systems, that's way easier than looking at millions of lines of source code. So that's just one example of we've got to think about how we bring the new generation in and make it appealing to them. They do not want to use ISPF, green screen editor that their grandfather was using. Yeah, it's fascinating. How is the pipeline for people to come in? I have to imagine so many people are retiring, aging out. Right, so we just, young people are learning scripting languages. They're learning Eclipse based IDEs in university or Eclipse itself, because it's free, that's something we put out a number of years ago. And some universities are teaching COBOL, but that's not the norm. And so I have a few responses to this. Number one, COBOL is a programming language. Just like JavaScript, just like Ruby, just like Python, just on and on and on. People put those on their resume because they learned it in a few days or a day. You can learn COBOL too, okay? And it's a matter of if that's the job that needs to be done, you can learn it because you're a developer. You know that you need to learn multiple languages in order to support modern environment. So I think they can learn it. The question is, now do they also want to be using some 30 or 40 year old tool to interact with it, green on black, something like ISPF? I don't know any young person who would really want to do that. I wouldn't want to do it and I'm not that young anymore. But I didn't want to do that when I came out of university. So we need to provide them with the modern tools and the language is just a language. But make sure they have a true DevOps pipeline, modern IDE's, modern automated testing, modern service virtualization, on and on and on, modern source code management, configuration management, all these things that the distributed folks or what they've done in a prior job, working in the distributed or mobile or web space, they understand all this. Don't try to teach them some brand new stuff that's actually 30 or 40 years old. That's a waste of time. So give them modern surroundings and the fact that the language happens to have been around 30, 40 years, okay, it's proven and it's actually important. So modernize the platform you're doing, IBM has been doing for quite some time, modernize the processes, DevOps, Agile, Lean, and provide modern tooling for the people. To make it easier to onboard new people. And that moves the platform forward. Yeah, for sure. I mean, the face of the mainframe, I mean, you think about it for a lot of people, okay, there's a system administrator interface in which we've modernized and have fresh GUIs and it's not just command line and green screen and all that, but it's for the developers. And you need to present them with modern alternatives exactly like you would have working for something that's going to run on any other platform. And that's what we have been doing. We have it. And now it's a matter of, okay, now let's move enough with the inertia. Let's move to this new capability so you can support the business. Well, better. Clients are getting this, right? I mean, some of them, but they're moving. Oh, no, everyone gets, they nod their heads. And then it's a matter of now, okay, let's get started. Let's build a roadmap because you can't make 20 changes at once. You need to think about the whole lean MVP model from a process maturity. Just like you're putting out a MVP of a product to test the market, determine if you need to pivot. Do the same for your process modernization and determine, okay, is it the modern IDE that I start with or is a modern source management system? Is it test automation? Where is the low-hanging, or deployment automation? Where is the low-hanging fruit? And that's going to differ for, or be a unique decision for each company. And so that's where we go in and help with doing what we call DevOps assessments. Work with you. Try to understand your business better and then say, all right, it looks like this would be the best path forward. So if this is, Hayden, if this is a baseball game, what inning are you in, in terms of that transformation? Realistically, we're second or third. And we've got maybe somebody on first. Yeah. But he's kind of off the bag, you know, give him a steal a second. We have some clients that have just made phenomenal progress, phenomenal. Well, as they started seven or eight years ago, just like about the same time as some of the born-on-the-web companies or the unicorns that we think about, and yet they're doing it in the context of mobile to mainframe. Phenomenal, phenomenal examples, like Nationwide and Fidelity and so forth. And so they're showing the way. And what's the business impact for them? You know, Gene Kim does this DevOps Enterprise Summit that's going to be in San Francisco in another month or so. And the stories you hear are amazing. So it's not just the born-on-the-web companies that are doing it. It's just now they've shown that it's possible we need to get more follow-up. Well, that's driving bottom line results for those companies. I mean, they're showing the way. And the metrics that they measure and track are business metrics. It's not about I can deploy 1200 times a day. It's about how is it impacting customer-sat, profitability, those types of things. So I think that's, and it's why we should be doing DevOps. It's not just because we can deliver 1200 times a day to production. It's because we're supporting the business in a more agile fashion. Well, so those later innings should go faster than the first couple. One would hope. Well, you'd think so, right? It's like the penguins in the iceberg. We just need to get the momentum going and see what people look around, see what their peers are doing. And it's just like the business. Do you want to be the blockbuster or do you want to be somebody who's a little bit more nimble on your feet? Cool. All right, Hayden. Thanks very much for coming by. Thank you. Appreciate the story. Appreciate it, guys. All right. Keep it right there, everybody. Stu and I will be back with our next guest right after. This is theCUBE. We're live from Las Vegas. This is Edge.