hello my name is joe steinfeld i'm a senior advisory solution architect within our it transformation business unit here at servicenow and here to talk to you around the service graph connectors versus discovery as an overall cmdb population strategy and when one should be used versus the other and things to be considered as you do so but first let me talk around the cmdb in that the investment service now has made over the many years and releases to really become that digital foundation to drive business outcomes and we've even gone so far as to come out with a service modeling architecture known as the common services data model so that we get prescriptive guidance for customers of how do you model data in the cmdb to drive the outcomes that you see here whether that's on the operation side in it operations security side risk as well as the planning the business management side of the house as well as the it service management but one of the things we see is customers start to adopt newer agile methodologies for bringing products and services to market like devops or site reliability engineering very agile ways of doing that that we didn't have all the data in the cmdb to continue to provide that out insight and outcomes and that was the genesis of what we call service graph so service graph first of all it's not a product anything you'd buy service graph itself is a strategy to provide that next gen system of record across for digital products and services across the platform to give customers that insight in the outcomes they're looking for so it includes data coming from the cmdb but also would contain data not typically in a cmv such as configuration data coming from config tools to build the environment like chef puppet ansible for example even terraform or tools used in the cicd process such as code repositories that capture the changes in the code because that visibility is needed in a lot of different areas as you start to use these agile automated ways of delivering services so a good example like in devops being able to understand whether application updates code changes config changes are impacting performance with traceability back to specific teams and technical changes or even another one in devops being able to proactively manage change within the cicd pipeline to find problems before they get pushed into production and then even on the business side of the house being able to really have a complete cost picture that's associated with delivering a service both human technology both in dollars and in time so those are some of the outcomes that service graph will provide and you'll start to see this rolled out of the strategy rolled out over the next few releases of servicenow but let's look at the first thing that was delivered as a part of that service graph strategy and that is specifically the connectors the connectors allow us to bring data in from third-party sources and you can see many of them here that many companies may already have in their enterprise and we often hear that when when talking with customers can we leverage data from quality or bigfix or dynatrace right but in the past bringing that data in is hard they often didn't bring data in to populate the right ci classes create the right relationships and often if you're bringing in data from multiple sources it was creating duplicates so it was it was conflicting with other data that's already being brought in either a discovery or another tool so customers asked us to help them solve this specific problem so they can have a holistic cmdb population strategy and that was again the genesis of the service graph connectors so the connectors themselves are built certified integrations from external tools that bring data in compliant with the common service data model strategy and architecture there so that the right tables get populated with the right relationship so that you can get the business outcomes you're looking for and you don't have to worry about hey do i have duplicates is my seam to be corrupt so that was the genesis of the connectors and you'll see a lot of the connectors here uh vr our first release in september of this year and then you'll see more coming over the next several releases but we always get asked i got discovery i've got connectors when should i use one over the other and that's what i'm really here to talk about is the things that should be considered as you start to put together a cmdb population strategy should i bring that data in via the connectors and or discovery and most of the time when you're talking data center for example we see a combination of both at most customers but let's get into some of these things that you need to consider first of all let's talk about discovery for populating the cmdb discovery's been purposely built over many years that they came out originally in 2007 and its purpose is populating that seemed to be with data center assets and i want to clarify that data center specific assets there and making sure the right cmdb classes along with the rate relationships are created so that you can have a healthy cbd and as you look at that one of the big things to consider as you you put together this population strategy is that it discovery gives you that one stop from the infrastructure item being discovered in the cmdb itself so you know the data is accurate so if we start looking at some of the advantages of doing this is direct population from the infrastructure to prevent duplicates and also make sure that data was accurate at that time of discovery data is updated in a timely fashion so we run discovery we pull back the data the relationships you populate the cmdb there's an updated time there you know at that time of date that's actually when we pulled that data from that endpoint so again you know that data is up to date discovery and purpose built on bringing relationships into the cmdb so again making sure that you have that your relationships between the cis the patterns that discovery uses to discover the infrastructure are easily customizable to pick up new attributes great new relationships or even discover new technologies that may exist in the enterprise now let's talk about service graph connectors for cmdb population so you can see a lot of these different tools have data to drive their specific outcomes a good example of that is system center system center usually manages endpoints so it has data around them what what software is installed for example what policies are set again it's very focused it collects data to drive its specific outcomes dynatrace is another example there being able to understand the modeling of an application and the transaction path that transactions take and it provides a visibility to help monitor the health of an application but a lot of times these tools don't have all the data that you need also there's a two-step process for bringing this in first of all those tools are going to bring data into their management database sccm is going to bring data into a sql server database and keep it there and then we're going to pull data from that database via the service graphic connectors into the cmdb so this is a two step process so data isn't directly populated there and things to be wary of their cautions there is the data in the tool may not be current again we're pulling the latest data in from the repository again sql server for sccm is a good example and those agents on those endpoints may not have reported in recently so again that data may be stale or not as current as it should be data may be duplicative again we don't control the data in those external repositories so if it's not well managed you may have duplicates there and again those duplicates would come down into servicenow and then data might not be complete to drive the outcome needed a good example i'm looking to populate a cmvb just with system center or bigfix data it just doesn't have relationships on how things are related to each other in the infrastructure and the reason it doesn't have it is it doesn't need that data to drive its specific outcomes so one thing you need to keep in mind is that whatever data i'm going to be pulling from does it have all the right ci's as well as relationships to drive the outcomes i'm looking for for my cmdb one of the advantages they do have though is leveraging existing data they're out there in the enterprise they're doing things sccm's managing endpoints data dogs monitoring the environment dyna traces monitoring the applications so that data already exists there why not leverage it to augment the visibility and provide a more comprehensive cmdb and lastly back to that last point they may have data discovery does not so a lot of times what we see is that discovery is a primary source for data center type assets and then these service graph connectors are augmented data to provide additional visibility for things discovery might not capture so as we engage with customers so the next question usually comes in okay well what should be my population strategy for the cmdb and the next two slides will give you an idea of tools that should be considered when putting together that strategy first of all when you're looking at the the different types of data that i'm going to have whether it's service info end user compute software iot info look at tools that provide complete coverage in those areas so for server info discovery service mapping for example endpoint solutions like tanium bigfix may provide some good server info as well as apm tools like dynatrace as a good example but then in the end user compute servicenow discovery really not geared to capture laptops desktops whereas device management and point management solutions so jf tamiyum bigfix really good for managing those components and have a full breadth of the the data you need so those are the things to be considered depending on the data you're looking to capture in the cmdb you know which tools have the most complete data ought to be considered but beyond that tools that we see as being a primary or a supplemental source for populating the cmdb to drive specific outcomes you'll see some of them on this slide here so for example if a customer came to us and said hey i need to really make sure my cmd's complete both from on-premise as well as my cloud resources our recommendation is discovery purpose built for both discovering on-premising cloud resources not only from a ci attribute standpoint but the relationships between those and then looking at leveraging any one of the tools depending on how they're used within the enterprise as supplemental information depending on the data needed to answer very specific outcomes again the big thing with the cmdb collect minimal viable data there to drive the outcomes you're looking to provide then for another example cmdb population for end user compute servicenow discovery not a good resource for that it's agentless it uses credentials on that based on a scheduled basis and catching endpoints that are on and off the network is very hard to do and be very hit or miss so wouldn't really provide a complete picture there but if you look at endpoint management solutions like jam fake fix sccm that have agents on there and that are monitoring and managing those endpoints those are good solutions there and from an end user compute you really don't care so much about the relationships but it's more about capturing the asset information so primary sources would be device or endpoint management solutions and then using discovery or maybe an iot tool like armis to supplement that information so again this isn't answer all the questions but get few things to consider as you start to put together your cmdb population strategy and then again another tool in your arsenal to be able to provide the most comprehensive cmdb is the service graph connectors in conjunction along with discovery and service mapping thank you