 At ServiceNow Knowledge 14, is sponsored by ServiceNow. Here are your hosts, Dave Vellante and Jeff Frick. This is Dave Vellante, and we're here live at Moscone South. This is day three of ServiceNow Knowledge. We've been here all week interviewing customers, CIOs, pundits, like Jeffrey Moore was on, fantastic executives, and one of the areas that we've talked about extensively, and we have for quite some time. We've written about this, both on Wikibon, SiliconANGLE, John Furrier has an article on Forbes, about the ServiceNow market opportunity. When ServiceNow first came out for its public road show, everybody was focused on the help desk piece of it, relatively small market, you know, billion, two billion dollar market. And then, ServiceNow started to educate people about the IT service management market, which is much bigger, it's, you know, multi-billions, maybe it's four billion plus. But we started to, at Wikibon, take a look at the TAM, and noticed that there were several opportunities, and one of those was actually managing infrastructure, operations management, other pieces of the IT life cycle. Of course, we've also talked extensively today about the enterprise service management, which is any service-oriented component of the enterprise and process, which can be automated. But we want to drill in to that piece that's a little bit more concrete. I called it the IT life cycle management. ServiceNow calls it IT operations management, ITOM. And Mike Nappy is here to talk about that. He's in the product group at ServiceNow, he's an expert in this field. Mike, thanks for coming on theCUBE. It's great to be here, Dave, thanks. So how do you guys define ITOM, and how does it relate to sort of the core ITSM piece? Sure, ITOM really kind of evolved out of our customers telling us, hey, they've been putting more and more of their processes on ServiceNow, automating those processes and getting great efficiency, as you know, with the ITSM side of the house. And so they've been asking us to extend those processes more deeply into their own infrastructure, which is increasingly a cloud infrastructure, hybrid cloud type of infrastructure. And light up, if you will, more of what's going on in their infrastructure. So they can make more informed decisions on the process side of the house and drive change, really kind of put the horse in front of the cart, have the process drive the infrastructure. So, okay, so let's compare that to the core. When we talk to ServiceNow customers, they say, well, we started with problem management and change management. You're talking about going beyond that and actually managing the process of that change, right? That's right, yeah. So we've had technologies like Discovery and orchestration for quite some time at ServiceNow. What we've been doing in recent releases is building on top of that as a platform and delivering solutions for cloud management, for configuration management, and with our upcoming release for event management. And what's bringing all these things together is the need to understand our customer services how they're deployed, their relationships and their dependencies, so that when issues arise on those services, they can connect them to our incident management, for example. Incident management and turn can drive change. Change can connect to automation that we have in orchestration and extend down into the customer's infrastructure and actually remediate the issue directly. So you get this kind of closed loop, fully automated loop. Now just to clarify, and I'm sure you get this a lot, you're not competing with Puppet and Chef, right? Just like you're not competing with Workday and HR. Explain what you're doing, for example, with those tool sets and how they fit into ITOM. Sure, great, yeah. Puppet and Chef do a great job of managing data center configuration at scale. They have this model-based approach where they have a master server, essentially that contains all of the golden images, if you will, for things like database servers, web servers, et cetera. So it's a great solution, very powerful. But what we've heard from our customers, a lot of the enterprise customers, are concerned that it's so powerful that it tends to create some issues on its own. It's not governed by any sort of process. What we do is we connect our change management, for example, to these tools and allow change to actually drive configuration execution in the data center. And so from our standpoint, Puppet and Chef represent kind of the last mile, if you will, of change management. Right, okay, so now talk about the CMDB and how that fits in to the, so this, let's say, specific example of the execution of the change and how you guys approach that. Sure, yeah, so the CMDB is, among other things, a repository of service and service relationships. And increasingly for our customers, it is the system of record. So of all the different sort of state models that exist in the typical enterprise, the ServiceNow CMDB represents how customers want to drive their business. And so based on that, we're extending that system of record notion through these orchestration capabilities that we have into tools like Puppet and Chef to remediate issues where perhaps the desired configuration drifts and you get some sort of change in what's expected. And we can remediate that directly through orchestration into the data center and correct the drift. Okay, so the CMDB is the authority, if you will, or the record of authority. That's right. So how does that get adjudicated? So let's say there's a dissonance between what happens and what's supposed to happen. So do you write to the CMDB first and say this is the way it's supposed to be and then execute against that? Or is it the other way around? You execute and then save that transaction to the CMDB. It's kind of a fuzzy question, but I think you understand what I was asking. Sure, sure, and in most enterprises, that's exactly the issue, right? Is that changes happen on both sides of the equation without the other side knowing what's going on. And so what we're doing here is we're creating capabilities that allow the CMDB to drive the configuration as opposed to understanding what changes happen to the configuration after the fact. This gives enterprises the ability to have greater control and audit trail and a better understanding of everything that's going on in the data center such that when issues happen, it's easy to go back in time and understand what was the root cause of that issue. It's all about visibility and with visibility you get control. Okay, so the policy gets written to the CMDB and the CMDB then is the enforcing mechanism to ensure that the change occurs the way it was supposed to. That's right. Which is perhaps different than many companies do it today. Wouldn't many companies make the change and then document it? Sure, and we certainly support that model as well, right? Okay, so you could do it that way. Sure. But is that the best practice? Well, we think the best practice should be that service analysis processes which our customers spend a lot of time in refining and automating should be in fact driving what's happening in the configuration. As you know, most issues with services are configuration related issues. Either intentionally or unintentionally some configuration drift happens on a server and it creates some sort of service impacting issue. If we could have better visibility into those changes we can catch those changes before they impact the service. Yeah, well you want a single point of, well I'm going to say single point of control even though service now is not controlling but you are certainly keeping track of everything and making sure that there can be a single point of control. It's really about visibility. Yeah, right, okay. Other than Fred the server guy is saying okay, I'm going to do this. Okay, and so has this, how has this, talk about the examples in customers, how your extension into ITOM has proceeded, what's the uptake like? Can you share with us any real world examples? Yeah, well we introduced cloud provisioning which allows us to provision virtual machines in either Amazon or VMware environments through our service catalog with our Calgary release and that was really kind of our first chip on the operations management table if you will and since then we've expanded on that capability. We've added configuration management which we just talked about which connects to Puppet and Chef and other partner tools over time and coming up we have event management. So what we're laying down here essentially is a foundation that enables us to understand service health in our customer's infrastructure, connect it to service now processes, have those processes drive remediation activities back into that infrastructure and again get that closed loop. Moving beyond that being able to connect to our service catalog is the front door to IT and have DevOps for example request virtual machines and have those virtual machines be spooled up and not only the virtual machine but have that machine be assigned a role like web server or database server and have it be provisioned automatically through these technologies. Okay so we talked about event management let's talk about that a little bit. So event could be anything any kind of outage or a disaster would be an event. So take us through an example of let's say you know say some minor disaster right? You get some outage or I don't know fire or whatever there's some prolonged outage. Now it's not Katrina but there's some prolonged outage that you can remediate instantaneously. Take us through an example of how a customer would utilize service now to do that and other tools obviously. Sure, sure. Yeah first and foremost I want to clarify that what we're introducing is not a monitoring tool. Our customers it's not a question of whether our customers are monitoring their infrastructure. Oftentimes it's a case that they've got too many tools monitoring the infrastructure. This creates redundancy, duplication, et cetera. What we've introduced essentially is a standardized way for customers to promote events from those monitoring tools into service now. And what service now does then is takes those events from all those different monitoring tools. It dedupts the ones, it correlates the events to service now CMDB to a CI and by extension to the service it's impacted. And it allows you to define a set of rules that submits those events into service now as incidents. And you can set the appropriate priority and so forth based on the impact. Okay, so maybe a better example would be some kind of human error, right? That's a very common event, as opposed to some big disaster. So that would occur, there might be several points of visibility throughout the organization to that event that might trigger several systems. They would flow into service now, you would dedupe those, identify that okay this is all related to the same problem and now let's go through a process to remediate. That's right, that's right. And a good example is let's take for example a disk failure on a server. You might have a monitoring tool that's monitoring the hardware itself and saying hey the disk is failing. You may have another outside in type of monitoring tool that's looking at the service and seeing service performance going down. Both of those may come into service now as events and you may say oh both of those, service now then says both of those events are related to the same issue on the same CI and it impacts this service. That's a great example. Okay, Jeff and I were talking earlier about one of your long term opportunities we think is analytics as to what's going on in the system and so if you can start to develop what you maybe have doing this already, you're probably doing it internally but just predictive analytics as to these types of events that are going to occur, when they're going to occur, the likelihood, et cetera. Is that something that, is that a near to midterm opportunity more long term and just in terms of specifically the predictive analytics? Yeah, the answer is absolutely and we're working with partners today like Splunk and Sumo Logic and others that have strong capabilities in that area to connect to this event management solution we've created and add that predictive capability. But eventually that's the only way that you scale. You need to separate the signal from the noise. You need to understand the things that really needed to be acted upon and those predictive analytics are key to doing that. All right, Mike, we got to leave it there. Thanks very much for coming on theCUBE. Absolutely. Great to see you again. Thank you, Dave. All right, keep it right there, everybody. We'll be back right after this word. This is theCUBE, we're live from Moscone. Right back.