 Live from Atlanta, Georgia. It's theCUBE, covering AnsibleFest 2019. Brought to you by Red Hat. Hey, welcome back everyone. This is theCUBE's live coverage here in Atlanta, Georgia for AnsibleFest, part of Red Hat's big news, Ansible Automation Platform was announced, among other things, they're great products. I'm John Furrier with my co-host Stu Miniman. Got two great guests here to unpack all the Automation Platform features and benefits. Walter Bentley, Senior Manager of Automation Practice at Red Hat, and Vijay Jebolu, Director of Red Hat Consulting. Guys, thanks for coming on. Thanks for having us. So the activity is high. The buzz this year seems to be at an inflection point as this category really aperture grows big time. Seeing automation touching a lot of things, standardization, we heard glue layer, standard substrate, this is what Ansible's becoming. So lots of service opportunities, a lot of happy customers, a lot of customers taking it to the next level. And a lot of customers trying to consolidate, figure out how to make Ansible kind of a standard, other customers coming in. You guys are on the front lines doing this. What's the buzz? What's the main story? What's the top story going on around the services? How to deploy this? What are you guys seeing? So I think what we're seeing now is customers who actually been doing automation for a long time have been looking at it at a very tactical level, which is very departmental, very focused on silo. What they've come to realize is with this modern DevOps and the change in how they actually go to market, they need to bring the different teams together. So they're actually looking at what should my enterprise automation strategy be? How do we actually take what I've learned in one organization and actually roll it across the enterprise? So that now struggling at figuring out how do we scale what we have? How do we change the culture of the organization to kind of collaborate a lot more and actually drive automation across the enterprise? You know, Walter, one of the things we've been, we've talked about all the time on theCUBE and it's become kind of cliche. Digital transformation, okay, we've heard that before. And the three things, people, process, technology. Process and capabilities you guys have done, you mentioned siloed having capabilities, that's been there, check. Ansible's done very, very well as a product. Technology, Red Hat and the portfolio, great synergies, we talk about rail integration, all the benefits there. But the interesting thing this year that I've noticed is the people side of the equation is interesting. The people are engaged is changing their role because automation inherently changes their function in the organization. Because it takes away probably the mundane tasks. This is a big part of the equation. You guys are kind of hitting that mark. How are you guys seeing that? How are you accelerating that? How is that changing your job? Right, so customers are now kind of realizing that going after automation in a very tactical manner is not exactly getting them what they want as far as a return on investment in the automation. And what they're realizing is that they need to do more. And they're coming to us and more of an enterprise architecture level and say we want to talk more grander strategy. And what they're coming to realize is that having just one small team of people that we're calling the DevOps team is not going to be able to drive that adoption across their organization. So what we're trying to do is work with customers to show them how they've collaboration. And the culture of peace is huge. It's a huge part of adopting automation. Ansible's no longer considered a emerging tech anymore. And when I say that, I mean, a lot of organizations are using Ansible in many different ways. They're past that point. And now they're moving on to the next part which is what is our holistic strategy at how we're going to approach automation. And we want to leverage Ansible and Ansible Tower to do that. Has that changed how you guys do your, roll out your practices in some of your programs? Well, we did have to make some adjustments in the sense of recognizing that the cultural piece is a pivotal part of it. And we can go in and we can write playbooks and roles and we can do all those things really great. But now we need to go in and help them structure themselves in a way where they can foster that collaboration and keep it going. And I'll actually add on to that. So we actually launched Open Innovation Labs three years ago. And what we actually learned doing that is using labs and the lab's practices to actually help customers embrace new culture and change how they actually operate has actually helped us take those practices and bring it into our programs and kind of drive that to our customers. So we actually run our automation adoption program and the journey for customers through those practices that we actually learned in Open Innovation Labs, like Open Practice Library, even storming priority sliders and all of those modern techniques. So the goal is to help our customers understand those practices and actually embrace them and bring them into the organization to drive the change that that's looking for within the organization. Fiji, is there anything particular for those adoption practices when you're talking about cloud? Because the communication amongst teams, silos, making things simpler is something that we absolutely do need for cloud. So I'm just curious how you connect kind of the cloud journey with the automation journey. So all of the journey programs that we actually created, whether it's our content adoption program or the automation adoption program, we actually follow the same practices. So whether you're actually focused on a specific automation tool like Ansible or actually embarking on a hybrid multi-cloud journey, we actually use the same practices. So the customers don't have to learn new things every time you actually go from one product to another. So that actually brings a consistent experience to customers in driving change within their organization. So irrespective of whether it is focused on automation, focused on cloud, migrating to the cloud, the practices remain the same and the focus is about not trying to boil the ocean on day one, try to break it into manageable chunks that give return back to the business quickly, learn from the mistakes that you make in each of the way and actually build upon it and actually be successful. All right, so Walter, I always love when we get to talk to the people that are working straight with the customers because you come here to the conference, it's like, oh, it's really easy to get started. It doesn't matter what role or what team you're in, everybody can be part of it. But when you get to the actual customer environment, they're stumbling blocks, you know? What are some of those things? What are some of the key things that stop people from taking advantage of all the wonderful things that all the users here are doing? Well, one of the things that I've identified and we've identified as a team is a lot of organizations always want to boil the ocean and when it comes down to automation, they feel that if they are not doing this grand transformation and doing this huge project, then they're not doing automation. And the reality is is that we're showing them that you can break things up into smaller chunks as VZ alluded to and even if you fail, you fail fast and you can start over again because you're dealing with things in a smaller chunk. And we've also noticed that by doing that, we're able to show them the return on investment faster so they can show their leadership and their leadership can stand behind that and want to do more. So that's one of the areas. And then I kind of alluded to the other area which is you have to have everybody involved. You want your subject matter experts writing content to do their automation. You don't want that just being one silo team. You want to have everybody involved and collaborate as much as possible. Yeah, maybe can you give us any examples about the ROI? How fast do people get the results and prove to scale this out? So with the automation adoption journey, what we were able to do is that we come in and sit down with our customers and walk them through how to properly document their use cases. What are the dependencies? What are the integration points? Possibly even determining well, what is the ROI ranking for that use case? And then we move them very quickly in the next increment and in the next increment, we actually step them through taking those use cases, breaking them down into minimum viable products and then actually putting those in place. So within a 90 day or maybe a little bit more than a 90 day window, we're able to show the customer in many different parts of the organization how they're able to take advantage of automation and how they return on investment with hopes of obviously reducing either man hours or being able to handle something that is no mundane task that you have to do manually over and over again. What are some of the things that people get confused about when they look at the breadth of what's going on with the automation platform? I mean, obviously tool to platform transitions are natural, we've seen that many times in the industry and then you guys have had product success, got great community, the customers are active and now you got an ecosystem developing. So kind of things are popping on all cylinders here. So the biggest challenge that we've actually been seeing customers is they actually now come to realize that it's very difficult to change the culture of the organization, right? They're actually embarking on this journey and the biggest confusion they have is how do we actually go make those changes? How do we bring some of the open practice and some of the open source collaboration that Red Hat has had into their organization so they actually can operate in a more open source collaborative way? And what we've actually learned is we actually have what we call as Communities of Practice within Red Hat. It is actually a community of consultants, engineers and business owners. They actually all collaborate and work together on offering solutions to the market. So we are taking those experiences back to our customers and enabling them to create those communities of practice and automation community that everybody can be a part of. They can share experiences and actually learn from each other much easier than kind of being a fly on the wall or kind of throwing something over the fence to see what sticks and what does not. You know, it's interesting about the boiling in the ocean comment you mentioned, Walter and Vijay, your point there is is that the boiling ocean is very aspirational. We need change, right? So it's more of the outcome that they're looking for. But to get there is really about taking those first steps. And the folks on the front lines have either applications they're trying to solve or manage, getting those wins is key. So one of the things I'm interested in is the analytics piece. Showing the victories, showing the wins early is super important because that kind of shows the roadmap of what the outcome may look like versus the throw of the kitchen sink at it and boil the ocean over which we know is the failed strategy. Take us through those analytics. What are some of the things that people tend to knock down first? What are some of the analytical points that people look at for KPIs? Can you share some insight into that? Sure, sure. So we always encourage our customers to go after the platform first. And I know that may sound the obvious, but the platform is something that is pretty straightforward. Every organization has it. Every organization struggles with provisioning, whether of a private cloud, public cloud, virtualization, you name it. So we have the customer kind of go after their platform first and look at some of their day two operations. And we're finding that that's where the heaviest return on investment really sits. And then once you get past that, we can start looking at end-to-end workflows. Can they tie service now to tower to be able to make a complete workflow? Someone that's maybe requesting a VM and they can actually go through that whole workflow by leveraging tower and an integration point like service now. Those are where we're finding that the operators of these systems getting the fastest benefit and also of course benefits the business at the end of the day because they get what they need a lot faster. It's like a best practice then for you guys. You've seen that. Yes, sir. We document that out. Vijay, what's your comment on all this? So going back to the question on metrics, automation is great, but it does not provide any value to the business unless you actually show what was the impact. Whether it's from a people standpoint, cost standpoint or anything else. So what we try to drive is enable customers to kind of build the baseline as to where they are today. And as they're going through the incremental journey towards automation, measure the success of that automation against that baseline. And that actually adds the ROI back to the customer. As a business, you then get to see I was creating a storage line. I was doing it probably 15 times a month. Take it out of here. I've now automated it. I spent like a day, created a playbook. I saved myself probably half a person that can be doing something else better. So building those metrics and with the automation analytics that actually came in the platform, tying those baselines to the number of executions actually is a huge value to our customers. They'll actually be able to realize the benefits of automation and measure the success of it within the enterprise better. So if I'm a customer or a prospect, I want to get a win. I don't want to get fired. I want to get promoted, right? I say, okay, I got to get a baseline and knock down some playbooks. Knock that down first. That's what you're getting at. That's a good starting point. That's a good starting point. Understand your baseline today. Yes. Plan your backlog as to what you want to knock down. And once you knock them down, build a dashboard as to what the benefits were, what the impact was, and actually build upon it. You actually will see an incremental growth in your success with automation. And then you go to the workflow end to end. That's your selling point for the next level. Absolutely. Good playbook. Is that the automation programs in a nutshell or is that more of a best practice? Well, those are components of the automation adoption journey. We allow the customer to kind of decide how they want their journey to be crafted. Of course, we have a very specific way of going about and walking them through it. But we allow them to kind of craft that journey and that is, those are two components that make up the automation journey. Well, I got to put you guys on the spot as to the tough question we heard from JP Morgan yesterday on the keynote, which I thought was very compelling. You know, days, hours, to minutes, all this is great stuff. And it's real impact. Other customers validate that. So congratulations. Can you guys share any anecdotal stories? You know, the name customers, you can just talk about situations where customers gone from this to this. Old way, new way, and throw some numbers around. Share some anecdotes. This is not a public reference, but I'll actually give you a customer. It's actually a retail company. When we first actually went and ran a discovery session, it took them 72 days to provision an instance. And the whole point was not because it took that long, it because every task had an SLA. We'd actually wait for the SLA manually to do the task. We actually went in with- How many hours? 72 hours? 72 days. 72 days. We actually go in with the automation. We actually drive automation. It was, everybody was working on the SLA. We actually brought it down to less than a day. So you just gave the developer who's looking to code 71 days back for him to start writing code. So that's the impact that we see automation bringing back to the customers, right? And you'll probably find those use cases across everywhere, whether it's JPMorgan Chase, you actually had the British Army and everybody on stage talking about it. It is powerful, but it is powerful if you can measure and learn from it. That's the baseline point. Right. Give some other examples because that's 72 days. Is that mostly delay? It's delay. Purocracy? It's not so much time. It's manual task. And when it's a manual task, you're actually waiting for the person to do the task. Waterfall, pass things on. Well, there are any examples you can give. Yes. So the one example that always stands out to me, and again, it's a pretty trivial and straightforward, is Citrix Patching. So we worked with an organization, they were an energy company, and they wanted to automate patching their Citrix environment. Patching their Citrix environment took six weekends, and it took at least five or six engineers. And we're talking about bringing in application owners, the folks who are handling the bare metal, all of that whole window. And by automating most of that patching process, we were able to bring it down to one weekend and one engineer who can do it from home and basically monitor the process instead of having to be interactive and active with it. And to me, that was a huge win, even though it's, you know, it's Citrix patching. That's the marketing plan, get your weekends back. Absolutely. Throw some shrimp on the barbecue, you know. Absolutely. Great job. Guys, thanks for the insight, thanks for coming on theCUBE, really appreciate it. Congratulations. Thank you. Thanks for sharing. This is theCUBE, here live coverage, Ansible Fest, where the big news is the Ansible Automation Platform, breaking it down here on theCUBE. I'm John Furrier, it's Stu Miniman. We'll be back with more coverage after this short break.