 Live from the MGM Grand Hotel in Las Vegas, extracting the signal from the noise. It's theCUBE covering Splunk.com 2015. Brought to you by Splunk. Now, here are your hosts, John Furrier and George Gilbert. Okay, welcome back everyone. We are here live broadcasting from theCUBE, our flagship program. We go out to the events. We expect to see the noise here at Splunk.conference in Las Vegas at the MGM Grand Hotel Conference Center. I'm John Furrier, the founder of Slip and Angle. I'm joined by Wikibon analyst George Gilbert, our next guest Oliver Hopper, Solutions Architect with Vodafone. Welcome to theCUBE. Thank you, nice to be here. Thanks for coming on, I really appreciate it. You've been an early adopter for Splunk's new IT service intelligence product, as well as an enterprise customer for a long time. I'm going to get your take on this. This is the big news at the show. What is ITSI or IT service intelligence? What does that mean to you? What has it done to your job and outcome? Explain the concept. Okay, Splunk ITSI is from our point of view the next level of data insight. We can automatically generate comparable and accessible data across the audience. So we increase in the audience that can access data and that is very valuable for the company because you don't have only the operations guy that knows the data, that knows the service, because suddenly we can, by the abstraction of raw data into KPIs, get managers on it. They can see data, they can see trends and they can see how the service is behaving and by that they can order and then react. So how big of an impact will this be in your opinion? Big, medium, it's big. The idea of ITSI has a big impact for us and I think for every other company installing ITSI. So you've had it since June, so you had it kind of under NDA. That's nice to have an early tire kicking view but you've rolled it out. What examples can you share with the audience that you've seen significant gains, big impact-like results? I think the most interesting part for most of the customers is that we didn't need to onboard any new data. The data was already in Splunk Enterprise. It's the same data that you're using already in your today's dashboards and searches and alerts and whatever you're doing. You just put an add-on on top of Splunk Enterprise and you can from then on automatically create the KPIs out of the raw data, which you already did so you already have an idea of your data and ITSI has been very easy to be installed. It took two days to install it to configure it completely and to present it to senior management. So a follow-up question is, at a company the size of Vodafone, the landscape is very complex, not just the infrastructure, but the application services running on top of it. How did the data that you already had in Splunk Enterprise reflect that landscape? And then when you put this new ITSI layer on top of it, how was it able to tell you that if something broke here, it rippled down and reflected in all these downstream areas? That's very complicated. It is very complex. We have, of course, applications that are not that complex, simply the naval services and whatever. We have, of course, very complex systems containing eight, nine different layers and components, but we have already insights with Splunk Enterprise, but the efforts that we need to spend to get this incident to transport the knowledge from the analytics team and from the analytics experts towards the operational engineers, to the architects, designers, networks, whoever might be interested in the data was fairly complicated, so information got lost. And ITSI, by having that great visualization with deep dive from glass tables, offers all these teams to work on the same data. So instead of argument and discussing with someone, they just work on the same data. So they at least get the chance to get to the same conclusion than I do. That brings us to the same level of discussion. So does this mean that did this change the uptime levels? Did it change the frequency of your application lifecycle? What ultimately at the highest level, what did it deliver? Greater agility, greater reliability? I think we are moving slowly, but we are moving from reactive to proactive. I think that's yes, and additionally, and that's a very personal finding on my side. I see people changing finely their mindset because they are afraid of data, they are afraid of all these tons of data even if SplunkEd has a very good access level, it can get very quick into it. They still had some distance to it. And ITSI, we rolled it out for the operational people, for the managers, that they can see how the surface is behaving. And by just looking simply at some ground, with capabilities to deep dive into the data and even drill down to the very raw data set, which then might be only needed for the operation teams, there's much more insight, much more visibility. And that then exactly offers, hey, we know outages, we know what happens, we know by our gut feeling as an IT guys, what's abnormal behavior of a system. If suddenly CPUs go up, IO goes up, response times of simple web servers go up as well, then we have a problem. And additionally, ITSI here supports that we can compare these in swim lanes. So the visualization of Splunk Enterprise was limited there, so now we can have all these KPIs being in swim lanes one under the other, and then now we can compare and mark them if at multi-KPI alerts. So abnormal situations, being based on multiple violated KPIs, can now be handled accordingly, we have action. So just to be clear, the swim lanes are like layers of abstraction or separation of concern. Like these KPIs or these indicators are related to service or infrastructure at this level. And then another set at this level, and then you would see the top level of performance and if you had to drill down, you had, it's not like one giant layer, you would go one after the other, is that how it works? No, no, you have basically, you have one layer after the other and the basic deep dive and the sort of service overview. So you have out of all KPIs of a component, service it's called directly, ITSI is creating a health score. So if you see that the health score is changing, there's a trend going down, you click into it and you get into the full KPI overview of swim lanes. And then you just can say, okay, this is stable, this is stable, this is stable, I just remove all of them and you can rearrange them by dragging and dropping and then you directly see, okay, there's something, there's a coincidence. I don't know why, but there's a coincidence. And then you can even save that as your private swim lane view and you can create out of that an alert, you can say, okay, the situation is over, but I can mark it and the next time it happens when it exceeds the surface threshold, please tell me. But how much of this in terms of trying to draw correlations between whether it's cause and effect or just correlation, how much is done by Splunk and how much by the operator? It's moving, it was more at the operator level and now it's moving to a first project and architectural level. So we try to define the KPI as all the stakeholders before and the operators just need to look at the data. Still, they can build down, they can still build their own stuff, whatever they like, whatever they require, but we are moving, I'm not the responsibility, but the knowledge a bit that is required. So two questions then. No operations console or tool manages the entire landscape. What augments Splunk and how does it augment it? Splunk itself, which we rolled up more than four years ago, can handle any kind of data and that's the big favor or the big pro that we have with Splunk. We don't need to care about where the data's coming from. It can be indexed, it can be searched, it can extract data and we can make comparable data out of that. So you don't have other management tools that we rely on in any meaningful way? There are other management tools, yeah, from different companies and they use and they make sense, but still they're complimenting each other, but with Splunk and Splunk ITSI, we get a kind of single pane of glass and a one view on the data. Sort of a manager of managers. Kind of. Now, given that this goes potentially from reactive to proactive, would that change how you can charge for your services, where you can charge for essentially for up time and you're not selling something that has break fixed built into it? I don't think so. Potentially it could, but we have service level of humans dependent of the tools that we're using to measure that. So we need to hit the target anyway. So the problem is more that we don't hit the target of the SLA and that's what we need to improve. Do you then budget the value of an implementation of Splunk sort of division wide or enterprise wide based on how much more, how much more often you're going to hit that SLA? No. You don't? No, no, we base that with a kind of recharging model based on the data volume and the professional services required for the implementation. No, but I mean the value to a bottle phone. Do you calculate the value? No, no, we don't. It's an investment that we do into our services. We were able over the time by rolling our Splunk now since four years that we have convinced the different services. And it's good that it's getting self moving. One service has it and they have deep insight. The other service owner wants to have it as well because he wants the same insight. He wants the same reaction time. Yeah, the mean time to recover is reduced if there's something ongoing. It's not about DevOps. In terms of the DevOps trend, developers, we know what's going on there, agile programming. But on the IT off side, that's about scaling to meet the requirements of the developers. Have you guys looked at that aspect of using Splunk in the cloud and or with making it much more developer friendly? Splunk is absolutely developer friendly. We've been working in other teams, the bottle phone before that had their own Splunk installation and they had a strong focus with DevOps and agile development and whatever. So we had QA teams and devs looking directly into Splunk to get data from mobile device applications down to backends and whatever. And the area that I'm working now where we rolled out IT service intelligence, we're an enterprise area. We buy software as it is usually. We put our requirements on the table and we buy software. So talk about the architectural kind of conversations that you're involved with. What are the top three conversations around just in general your job? And in terms of like the, you have the stack rank, the popular, none of them are the most painful. They could be the most painful, the most rewarding, the most painful. What are the top three conversations? The top three of the topics I'm talking about. What's trending in your world? Trending. Actually, my trends are changing a bit since I'm here at DocMons, which is amazing. I think it's at the moment all about, of course, big data is still there. It's a trending topic still, even if it's some years old already. We try to get more data on board. We try to utilize data more. We try to honor the data and respect the data. That, of course, has an impact down the chain to vendors, to software providers, whatever, in regards of NFRs, how logs look like. What do they need to provide? Logging interfaces, status interface, and whatever. I think that's an ongoing topic that I touch at least one, two times a week with people discussing, should at least have these kind of logs available that can help you once you're live, once you're production. The second topic at the very moment is, and that's something I love to speak about, is accessibility of data. Everyone in the organization has the right to access the data. And at the very moment over the last years when big data became trending, it was very limited. The geeks, the nerds, they're being stuck somewhere in a dark room, looked at data, and they had findings. But still they took the findings, brought them up to the level and said, hey, that's our problem. But if there's someone discussing with you that is not able to share opinion because he does not have the data, that's very problematic. I summarized that to some high level manager here that's clung to last years, Michael Conner from Coca-Cola was in the keynote. He said, without data, you're just another person with an opinion. That's a great sentence. But that's the biggest problem. Well, the KPI thing with ICSI is a game changer. Exactly, that's the point. You can get it funded in compensation. Exactly. Hey, I did my job. It solves the problem of the disconnect between the technical people and the non-technical people, or half-technical people in the management layer, because finally they have the same data, or at least maybe it's an abstract of the data, but it's based on the same single point of truth, of the same data pool. And that makes sense. You don't have reports that are incomparable. Why does the operations team report something else than the life cycle manager and the service owner? So it's a winning formula? Absolutely. It's a good concept. It is a brilliant concept. All right, well, we appreciate you sharing your insight here on theCUBE. You're welcome. Oliver Hopper, thanks so much for coming on. Really appreciate it from Vodafone. You know, getting a perspective from the folks in the trenches, who are the ones who actually build and architect the solutions. This was always great about doing theCUBE. Thanks so much for your time and insight. This is theCUBE, sharing the insight here at Dot Conference 2015 with you. I'm John Furrier. We'll be back with more after this short break.