 Live from New York, it's The Cube, covering Riverbed Disrupt, brought to you by Riverbed. Now, here are your hosts, Dave Vellante and Stu Miniman. Welcome back to New York City, everybody. This is The Cube, the worldwide leader in live tech coverage. We're here with Jay Haynes, who is a global IT operations leader at Royal Dutch Shell. Great to see you. Hi, thank you. Thanks for coming on. Glad to get the practitioners' perspectives. Glad to be here. You know, on the front lines, solving the world's problems, making it all tick. So, first of all, what do you think of Disrupt? How's it going for you? Oh, it's been great so far. I've actually participated in several events like this, but the Disrupt, I've learned a lot today and got some insight, both at the high level strategy perspective, but also in the breakout sessions, I saw some bit level stuff that I'm ready to go back to the shop and I would say play myself, but actually it'll be get my guys to play. They gave me the ideas that I saw something, I'm like, hey, I like that. So, it's been very good. Oh, so I want to actually come back to some of those, but tell us about your role at Shell. So, Royal Dutch Shell, a large integrated oil and gas company. I suspect most people have heard it of it. And right now, actually the integrated part is good because with the price of oil being down, we're talking about what we say lower for longer and how do we survive in that environment in the exploration and production environment. But downstream and chemicals are doing well because obviously the feedstock price is optimal, but in the balance game, it's a tough environment to operate in. And so I manage our global IT operations for our infrastructure and applications area and we are responsible. I tell people I'm in charge of bad. If it's bad, people call me because something's broke. We need to get something back up and running. And then I'm also responsible for the operational integration or SIAM function if you're aware of that on the integration side of making sure that we integrate all of the suppliers and app teams across the entire Shell and the globe. So I want to ask you, so Jay, energy companies are, they're used to solving big hairy gnarly problems. They're engineering oriented, but it sounds like they're no less difficult on IT than other companies. Is that the case or are they more receptive to the challenges that you face as an IT? Well, it depends on the business. And so the Shell has such a scale that actually it's a bunch of businesses put together. Upstream wants it fast. Downstream wants it cheap. Trading wants it up. And trading, we have a quote, minutes mean millions. And so depending on the segment that you're in or the time of day or the project or activity that's going on, the dynamics of it change. And so this theme of disrupt from a digitalization perspective is to a degree it's good news, bad news and being kind of forced upon us with the changes in technology. Used to be you'd have a shift worker go into a terminal and enter a shift log. And so your proliferation of IT was often very concentrated. Now with digitalization and laptops and tablets and mobile devices and pushing the apps further and further into the hands of users is really changing the dynamics of the IT landscape and what we have to provide and support. Jay, we've looked at kind of the oil and gas industry. Data is so important. It's one of the use cases that comes up in analytics and a lot of what we look at. How are things like digital transformation and big data analytics transforming kind of the role of IT inside Shell? Again, it goes back to the business with the cloud. The cost of storage is all of a sudden potentially cheaper but the challenge is getting it in and out and so the strategies of what do you do with that data depending on where the data is. And then the telemetry of people pulling up to a gas station and using either a credit card or a loyalties card and having that data to be able to quickly do those transaction but at the same time keeping it secure. Big issues, big problems. Probably maybe not in the same realm as a financial institution of a bank but in the retail space there are a lot of concerns with security and making sure that we protect the customer's data and then the applications that go along with that. Obviously need to be up running secure. Well, it's an interesting question, right? Because you know the old bromide, the data is the new oil. You guys are all about the oil. A lot of people don't like that comparison but nonetheless, paint us a picture, if you would Jay, of sort of the applications that you're supporting. Huge company, obviously massive scale but which ones do you touch? Well, actually all of them, really. But all of them only when they break. Okay so in the sense that you know we're not, my teams are not the ones that are out building and developing and creating in that DevOps space if you will but we are on that upside from the Crit-Sit-Sev-A-Sev-1 crisis management perspective. So and then we take our apps and we divide them up into business critical apps and non-business critical applications and so BC applications as we call them definitely have a focus and with a lot of the monitoring that we do for those BC apps and some of the non-BC apps because sometimes apps that aren't business critical such as your PC or even potentially logging on after the log on process might not seem to be BC but it can be very impactful. And so actually the span of control is from the base infrastructure, email, SharePoint, Office 365 to our business critical supply and trading type applications, supply chain, exploration, the data management apps, process control. So you mentioned DevOps so I got to ask the question Stu if you don't mind. So I'll give you my version of the way, I see it and you tell me of course correct me but application development, they develop an app, they throw it over the wall to ops and they say deploy and then ops looks at it and goes oh they didn't do the security right, it doesn't comply with the whatever requirements that we have. You go in, maybe make some changes, go to deploy it, the code doesn't work, send it back over to application development and say the code doesn't work. They say well it did when I sent it and you get this back and forth. Okay so this DevOps culture emerges but a lot of people say it's more ops dev than it is dev ops. What is it at your company? Well so we're in a transformation right now and I think you know if you ask five people on the street in the office what DevOps is you possibly are going to get five different answers. I'm DevOps, no I'm DevOps. Right, but for me I still, you know sometimes they talk about DevOps, I believe that I was doing DevOps when I started with Shell and I'll go ahead and say back in 1983 which dates me a little bit but you know DevOps is a mindset and it is a methodology of how you do stuff and I think in the way that applications are morphing and shifting that indeed that it's not so much throw it over the wall anymore but it's this DevOps self-contained environment that if you have an application and as a developer and you can publish that app and immediately get the results of it's working, it's not working then you kind of self-control and then with the cloud and the foundation and the platforms of infrastructure that those pieces, those foundational pieces and so we think of the electricity and the air conditioning in this building and so much of it you would never consider part of your app it's just there and so I think there's this sometimes missed understanding in my opinion of DevOps going the entire life cycle into these infrastructure platforms and I don't think that's the case and I think that if we talk about IaaS and PaaS and SaaS and those type things that this DevOps really fits in this I've got a website, I've got a customer front end I need to roll quick and do that and so with that we need to be able to monitor it but to me the DevOps when you're changing your SAP infrastructure or you're changing some key data element table structure thing for a financial quarter closing it's no longer DevOps, it's not throw it out there and you need to have more of the waterfall methodology. So Jay you said that you basically get the call when things aren't working, I'm curious what your thoughts are on kind of SD-WAN in general and the vision that Riverbed laid out here for the Steel Connect and the Steel Connect 2.0 announcement that they've made here at the show? In general I think it's absolutely the right direction right vision and actually seeing it in action at the first breakout session was kind of cool so it excites me in the realm of I think that it paves new way to somebody messing up in other words somebody going in and tail netting to a router and changing something and it breaks because they didn't understand what they were doing or they made the mistake they did the wrong thing and so this SD-WAN to where you can kind of abstract some of the complexity and make it easier, pre-configure, pre-defined easier to swap devices in or out I think it's going to have a tremendous impact on reducing our number one, what's the number one cause of our operational problems? Human failure. Change and if you break the failures of change it comes down to human failure so the more that we can take the human out and put smarts in the better that it's going to be it also scares the hell out of me in the realm of the more and more we take the human expertise out because we've made it easy when the problems are tough they're tough that's where then you need the tools to have the visibility to come down and to be able to get down at times to the packet level to be able to solve the problems and so it's a good news, bad news mostly good slash great news but you want that underlying foundation to be strong and secure. So you mentioned that you've been some of the breakouts and found some little nuggets that you're going to be able to take to your team give our audience just a flavor of some of the specifics what kind of things do you learn coming to these sessions sitting with the breakouts talking to your peers? So in the John Hodges did one on how do you better troubleshoot application performance using steel central or app internals expert and interesting in the realm of looking at some of the transactions that add up across many many things and so for example you take there might be some component on a desktop that is part of every transaction so if your network driver for example are sub optimized and it's defaulting to 2.4 gig instead of the five gig and you don't know that and it's happening to every user or a lot of users spread across an aggregate you might not see that unless you have the visibility of getting that data getting those tools to go look for obscure problems that may manifest themselves in an additive fashion across many number of users especially this would be true if you were a consumer facing and you had millions of users and those seconds start adding up and so being able to look at the tools we've solved a lot of the big problems with the monitoring that we've put in so far and the next level is or trying to go after is this kind of I believe this end user experience and as cloud and HTTPS SSL come into space we start getting blinder in the middle because we can no longer see inside and so being able to do the end user experience with eternity is going to hopefully give us a solve some of that and bring some of the visibility back that two sided coin of security is always the way so with Riverbed you're doing both when optimization and visibility and yes application performance management yes okay and you've been a customer for a while or yeah well and so and I I sit more on the visibility side we have when optimization and on the kind of the peer networking side being in this operational fire fighting role and responsible for that we used to have the age old you know the best of monitoring system in the world where the user would call you and tell you that their stuff was down whereas getting ahead of that curve and deploying the tools now we can see problems before they occur and you know simultaneously the fixing them before the user calls or even better predictive and proactive to where you actually see it stop it before it ever occurs in the first place and the users never even know or you avoided the outage the impact in the first place no call and then the business impact is higher productivity for the users which means money in the pocket of the corporation indeed and then and then telling that story which is critical which is often a miss I think of IT organizations is they don't tell their story or they don't tell the story in business terms and so if you go to your business stakeholders and talk about latency you talk about MTTR you talk you know you need to put it in context of terms that the business is going to understand right even RPO and RTO right which people say oh that's a business term I'm like give me a hundred business guys they wouldn't know what RPO and RTO stands for and MTPD maximum tolerable players yeah so you're right yeah excellent jay great having you on the cube thanks so much okay appreciate it all right glad to be here thank you you're welcome keep it right there buddy Stu and I went back with our next guest we're live from Riverbed Disrupt we got the music playing in the background this is the cube right back