hello everybody this is a quick common service data model overview and briefing that I typically give customers when they are first introduced to the csdm and also cdb here on the service now platform So today we're going to cover the Strategic context for data on the platform the three pillars of successful data Foundation which I like to think about um this problem in three different ways and uh we've seen the most success when you focus on these three areas balance your focus so you don't do one versus the other but you have to do a little bit of all three and finally features supporting csdm that you should know about and leverage as you implement service now so the first thing I would like to cover is that um the cmdb is sort of central to most of the products that we sell on the platform uh I came here to manage a product called APM at portfolio management over here on the right and um there are many other products here that coexist we have uh about a thousand product managers now and there's a lot more products than this but these are the main ones and the these are the main areas of the products that we invest in in various ways now the the cool thing about being on the platform as a product manager who who has worked in other companies before and try to make all these products work together is that we can share data across all of these products so some products contribute some products use the data and some will do bit of both for example my APM product that I used to manage manages the app portfolio and capabilities as an example and that that's stored in the repository and those U business applications can be seen in service management inate forms as an example so these are all things that can happen the other reason I joined service now is because I would like to join information across all these different spaces is because they're much more robust as a result so for example when evaluating your app portfolio you need to understand how it's used the risks in the portfolio the assets used within the applications you need to understand the um what's on the cloud or not yeah and so all of these elements kind of go into the evaluation criteria of business applications and there's more like costs and things like that we won't get into today but the cool thing about being on the platform is all of these products contribute to that picture and making a sound rationalization decision uh likewise when you're dealing with uh a sec a security vulnerability understanding the application context or understanding what assets you have that are covered by that vulnerability so uh the Central cmdb and service graph is a name we give the broader model here service now as the model extends into areas that aren't traditionally uh cmdbs cmdbs traditionally cover the operational concerns of physical infrastructure but as we move to cloud and as our model extends into pre-operational or more conceptual elements like business capabilities uh the the the model we call service graph kind of covers that larger Gambit now to get started with the three pillars we have to think about the data in the platform in three different columns and you have to do all three in order to make this work regardless of what product that you use that get that uses the information or that contributes information so the first pillar is what I call ingestion and the ingestion is all about bringing data in continuously from various sources and merging it into a single trusted repository we want to connect the discoverable to the non-discoverable information in this process as well and last but not least is you want to ensure that that data is managed by somebody that owns it uh invariably the folks that are managing the data repository doesn't necessarily own any of the data in it there it's sourced from other folks other products on the platform and other sources service graph connectors Discovery service mapping all of those products are are basically the ones that contribute that data and some products such as SPM uh products APM uh be able to capture information from humans as we inventory the services as we inventory the applications those are all things we need to adjust the next pillar is what I call govern and this is the idea of anything you bring in you should have a life cycle and plan to get rid of it so if you don't have a plan to get rid of it it'll likely never go away so you you need to consider the life cycle of any new information you bring in including human or automated um Discovery sources you to be able to support the use and extensions so they has to be some kind of governance team and roles established and without governance people will just add information ad hoc even though the data is already there somewhere else they may add additional fields or tables that are not necessary these are all things you should C you also need to be able to communicate and manage those structures and definitions now we provide this for you in terms of what csdm is all about csdm is there to communicate from our perspective what's the common service data model what's the common model that is used without throughout all the different products and that model will continue to grow and evolve as the commonalities continue to grow across our platform and the last column is Insight the data that we gather is to provide value usually for analysis uh be able to understand like operational impacts of a change or an incident as an example to use for planning so when when you're planning a data center move or moving from on-prem to Cloud for example all this information is useful so we want to be able to basically first and foremost support the personas and products that we sell on the platform and my guidance is don't collect information if you don't have a use for it people bring in everything because they can and then invariably that turns into a bit of a liability especially if you don't have a life cycle process to get rid of it it kind of sticks around never goes away and um you need to deal with that now here are some of the features in the seem to be we basically provide a lot of functionality in these three pillars and we're we're really aligning the way we come to Market with around these three pillars so we can communicate okay these are the product features for ingestion versus governance versus you know Insight the first pillar is about in having an ingestion Pipeline and using something called integration Hub ETL this is a product feature that allows you to bring information in safely and reconcile it with the existing information uh we also have some and that's called I or identification reconciliation engine well the next thing down here is uh something called multisource cmdb and that's a feature to be able to store some of the raw data coming in from various sources so you can debug and troubleshoot things what we typically find is information coming in from various sources may have erroneous data or outdated data or it's just not updated properly so uh you might use Discovery for example iton visibility and also secm secm may not have the latest details discover might might have pertinent details but of course those details also need to be merged into a single record at the end of the day and by looking at those details you might decide on um using One Source that's more trustworthy over another on governance we have data DB manager is used for marking information as retired or archived or deleted and deleting that information and we also have data manager looking at things like certification and adastation processes so it's a nice tool a lot of customers before this came along were doing this on their own now there's a central place to establish those policies cmdb class manager to actually establish the class structures what kind of data that we have in the seem Tob um see DB 360 is a visualization of the multisource data so you can see that data coming in compare and contrast it using some out of the box reporting capabilities uh we have of course documents and guides there's some features like Dynamic SE groups that allow you to manage uh inventories of CIS as a query basically and be able to use that in various processes uh we have dashboards that help you manage the health cmdb a health dashboard it's been in there for a long time you establish the criteria for the health in there and you establish the use of that Health dashboards as you need data foundations dashboard however is our view on data health and you can't change those we provide hsds that allow you to establish criteria from our perspective kind of like grading your own paper versus having us provide our perspective on the data Health that you have we also provide uh a prioritization of these metrics so we also have playbooks who fix the data that needs to be fixed within each of these metrics so we have the Insight pillar which has features like the cmdb work space that allows you to access the information and view the diagrams things like that to see the class structures query Builder to be able to build queries that Traverse many objects many different paths through the data so for example business capability to business application app service down into underlying CIS service graph data VIs lets you look at how that service graph connectors are bringing data in uh CMD csdm product views allows you to see how the products use the data that's in the system so this is a good reference to say oh I'm bringing in this data does anything really need it you can kind of use this as a reference the cmdb search uh is allow allows you to do uh natural language queries of the system you don't have to know the the query Builder query structures it'll produce those for you and last but not least is the support products that we actually sell again don't bring in data that you don't really need the products that you use it for whether it be an audit process or itom health uh event management or just regular itsm processes like incident problem and change I like to think about the value of the data across many different areas and the criticality of this data is increasing all the time as that as the data comes in from various sources it gets leverage more and more across the board and it's important that we're talking about the same data so when somebody talks about an application or software we're all referring to the same thing we're not basically referring to different things or different in different tables within the platform and there's a lot of features that require the csdm structure csdm was introduced a number of years ago now to basically guide our product teams in order to better produce products that are natively integrated that we're kind of sharing and reusing our our data and since it was introduced we've been moving our products to leveraging this common data in a common way and so some of the new products and features that we have are really the um start off with seem Tob data manager itself this leverages life cycle stage and Status fields that we introduced some years ago uh you can use the synchronization between Legacy and the new ones or there's an option to switch it over to using Legacy Fields but that is something uh what I would call Stepping backwards using the new ones allows you to move forward as new products are coming out on using those new stages and statuses Dynamic CI group is a new feature that came in Paris accommodates many different use cases even in customer service management we finding a huge adoption curb there business applications you can now see those on the incident form the incident is is not supposed to go against the application because that's ambiguous it doesn't speak to the actual CIS and the operational information that you have in the data center business applications is a higher level concept and you want to just see those business apps as the CI is identified you can see the net number of business apps as well as the net number of services that you that are impacted uh csdm is used in change management there's a videos on this there's also documentation on how but we unpack that Dynamic CI group there may be a thousand CIS being updated in a patch and we're able to track each one individually through change management by unpacking those application service wizard allows you to create those app services in the csdm structure we're not going to get into that today in detail but this allows you to create them dynamically as part of your cicd process and synchronize the CNB with the activities going on last here is the data synchronization process that looks at the ownership information at the technical service level this is a very high level abstraction for example you may have a network team that owns networking devices across five different uh facilities by creating a query in used in that Dynamic CI group you can associate that team the ownership the change management and The Incident Management uh information groups basically be specific to all the CIS that they happen on so if any incident happens against the CI let's say somebody finds a a damaged Wi-Fi device in the corner of the building we can automatically identify the folks that need to work on that particular item some new products that use csdm cite SRO is ability to expose to the devops teams the ability to create their app services in the user experience a lot of folks will create uh microservices or change the microsof services over time uh so allowing devops to kind of uh teams to kind of Define those microservices as they collapse some or create new ones on their own and be part of the process versus have to rely on other people to Define these things especially if you're not using apis up here service Builder is a nice feature to be able to create Services the offerings and connections to the app services and the catalog items per csdm we'll look at that in a minute but the idea here is that we want to allow service owners to kind of control their own destiny and learn about how they store and manage manage that data uh about the service within the platform so huge huge uh opportunity to not only train those service managers but they get the right model in place without having to learn cstm and all the details digital portfolio management allows the both the service management activities and application development and planning activities to be all seen in one spot under what we call Enterprise portfolios so that's a very powerful feature to bring the Dev and Ops worlds together on the platform especially as we're moving more towards product teams that own the full life cycle of their deliverables the next is devops config and this is an area that's kind of leveraging the sdlc component in the build domain this is the only product that currently uses csdm sdlc component more is planned but as of today that's kind of the only one last but not least is important to point out these product views in our doc site and those are just referen materials as you use different products you can actually leverage the product views to see what data is used or contributed to the model as a whole so I like to explain to folks what cstm is in the context of that full what I call digital products and services life cycle the idea here is that you'll plan something to product or service or an app uh obviously if you do provide an application it is consumed as a service and managed as CIS in the operations team and so when you see this name service graph it really pertains to that whole model from end to end and of course in that model you have pre-operational information about what's being deployed or planned uh what what's being purchased from an asset management point of view and then also you're looking at more conceptual elements like business capabilities and business apps information objects which are higher higher level Concepts csdm is our guidance uh and internally we treat this more like governance we require we mandate our product managers to leverage cstm obviously not everything is going to be caught Sometimes some of our product teams will come out with a feature that doesn't leverage something common we would typically have that caught by customers that are using csdm and then addressed over time as csdm expands and covers more and more products um we will also incorporate uh some governance and internal training to get those internal teams kind of on board with this common model this is a nice easy way to kind of look at you know traditionally it's been cmdb has been infrastructure but now we're getting more information in in the model and so as csdm kind of grows uh you'll see some elements that aren't traditionally just operational and infrastructure pieces but we want to understand the conceptual con context as well so when you look at common service data model these are the four key domains of csdm so we have the design domain here kind of in in the the beginning uh this is where your more conceptual elements of the model like business capabilities and business apps are created and are used for planning activities the next domain is build and this is the newest area for cstm it's still being fleshed out in terms of how many products actually interact in this area uh Dev apps and agile are the key ones and the other areas such as devops config is specific to the sdlc component in that area the next area is manage this is your typical operations in Asset Management space when we're managing the technology as it appears in the data center or in the cloud data centers then last but not least is consume and this is where we're managing the use of Technologies through it service management and customer service management so some of the things that customers will will use from a company are are running in those data centers and we need to understand how that connects all the way back to planning and so you can see we're addressing the full life cycle of what's going on in the cstm model from initial planning and ideation processes all the way through operations and use now all of this model sits on what we call the foundations domain the foundations domain in csdm deals with common information that is used across all all these areas things like location hierarchies business unit hierarchies product models things that you buy or you might think about building or buying in in the planning stages so um and software Hardware things like that product models so we'll look at these in a minute but this gives you an idea of the four key domains and then the fifth foundational domain that csdm consists of as we look at the cstm model you'll see the four key domains and their color codes here on the main diagram at the bottom here you'll see the foundational domain sorry that got cut off a little bit by the video but I just wanted to make sure that you understand the four key areas um that we're talking about and the fact that on the design domain this is where we engage typically folks like Enterprise Architects app owners to define the business apps and things like capability hierarchies that are used for planning purposes then in the build domain we have sdlc component this is currently optional and there is a connection that that is still maintained and used heavily that bypasses this so think of that is the express Highway and if you do have stlc components this is just giving you more detail with regards to the breakdown of that business application and the config files and things that basically make up the applications a lot more functionality is planned there and so hold on over the next couple years as we flesh this build a domain out much further down here on the lower left we have the manage Technical Services domain here we're managing the technology at the physical level I like to think about these as your traditional CIS physically representing the physical data center elements or client computer network devices things like that we also include Cloud CIS in this equation so we bring in cloud data through Discovery as well as U through service craft connectors the application service I like to think about as your logical playground this is where we describe the deployments of each applications that's un common use or the the starting point of the application stack from top down and these stack can be structured in that logical area in a couple different common ways for example a platform architecture may have one platform that supports many products on top of it and so each product on top of it relies on the platform and the way the platform is installed and and managed and could be in the data center or in the cloud doesn't really matter the opposite is true for microservice so microservices may be one application service that's logically connected to many microservices those microservices are also application services in our model and they're used to be able to describe each underlying app service and the fact that they're all part of a whole and just think these are not mutual exclusive patterns they can be mixed and matched as necessary but this is our logical tier that describes how we are broken down those things again for the technical service management aspect of things uh these can be monitored independently and we can see the dependencies between them left and right so some of these might provide apis uh those apis might be consumed by other applications as an example down on the right hand side we have sell and consume and these are elements that describe the offering in the business service and then how it's also consumed by a business consumer the business consumer I like to think about this is your last mile of consumption over on the left hand side you'll notice that we have these um infrastructure pieces that are managed in aggregate so like I described earlier the network team I own the different network gears in different facilities or break that down into different offerings different slas Olas or different teams that manage each of the buildings so as you break down the infrastructure that's going to allow you to create offerings that relate to the infrastructure that's being managed to an SLA or to a group when it comes to the technical service here we're dealing with applications that are more or less building blocks or platforms which are meant to be used to build applications on top of like the service now platform as an example and then of course over here we're dealing with technology consumers and we also want to promote self-service using things through the catalog on the right hand side the structure is the same the biggest difference between the business consumer and the technology consumer is the fact that the business consumers we know who they are we have their names so on the business consumers we know who they are we have their names we understand where they are and there are subscribers in the business service offering that you can relate to the everybody in a location for example a group of people and those groups would of course contain users users themselves individually or an enre Department as an example so and if users are related to those departments we'll know exactly all those individuals that might be impacted if a service goes down we we have Precision in terms of understanding the business context down at the bottom here we see the foundational elements things like business processes contracts contracts from suppliers either service suppliers or vendors that provide software and Hardware to you product models Now product models are kind of interesting product models are used heavily in asset management but also seem to be to relate the physical infrastructure and software that are used uh or assets from cloud vendors and then also you can use product models to indicate things like different versions of the request catalog or business offering or sdlc components so product models can be used in a lot of context location hierarchy same thing you can have the location of a specific specific Network device or server but also locations of who the where the consumers are so you can use this more maybe a geographic area versus specific building or or a GPS location of a of a server given where it was deployed groups and users obviously those are coming from user groups and that sort of thing versus cmdb groups cmdb groups are morals use as part of dynamic CI groups uh to group Hardware or or CIS in general and then there's organizational breakdown structure company business units and departments used in various ways and the last but not least are life cycles so when is the ideation all the way through use through end of life and there's quite a few life cycles there in life cycles in our model cover kind of the Gambit uh these are like I said there's a new set of life cycles from migrating folks too um but there's also a lot of Legacy stuff that's out there some products have migrated some have not so this is used on the new ones are used specifically more for readon at this point and um over the next couple years potentially we'll have most of our products refactored to using these new life cycles so something to keep in mind as you adopt csdm and you get into this detail a lot of folks think csdm is theory and it's not really relevant but it does tie to the physical models in the platform and here's just the list you can look at for reference purposes some things to point out in the infrastructure CIS we have over 1,000 C CI types that are down at this level so something to keep in mind is that as the different types of devices grow so will the infrastructure CIS grow and we're getting into use cases such as operational Technologies you know things like actuators PLC devices um things that are in the factory not necessarily in traditional it so all that counts as infrastructure CIS we also have have um some ambiguity here in the application Services there's different types depending on how you manage the details of each type so this is something to keep in mind as you're looking at the model you do want to understand the way you want to manage it tags versus Discovery or service mapping you'll have to look at the the type to know what table to use I recommend that you use the wizard that I explained earlier to see what tables are structured and what the pre requisite data values should be for those types like tags for tags based app service mapping the next is um on the relationships these are going to be the relationship types uh in solid lines and in the dotted lines are the references these are the reference attributes that we have and uh some are parents some are just references so you want to look at the actual table structures that we Implement on how we connect the dots between these particular elements a lot of folks will also refer to this csdm if you're an architect as a meta model it's a model of our data model so that's another way to think about it the thing to think about when you're adopting csdm a lot of our customers have been on the platform for a long time you want to be able to look at this data model and progress to it in incrementally and a lot of folks depending on the level of customization how long you've been on the platform what products you may or may not use this has a lot of bearing the first is really the focus on the foundation data if you're a new customer get this right out of the box right get your data coming from users into the system and by the way when you're bringing information from non-ci tables you can now leverage the cmdb uh tools IR multisource things like that in order to look at the data as it comes in from various sources about users an example would be active directory to understand their groups but you may want to augment that data with the Departments from workday or people soft so that's a common thing so take care of your foundation data first locations is also a very key element that you'd want to be able to tackle early on to make sure that location hierarchies are complete down to as level lowest level detail as you can rack and elevation some if you have a um an element manager if you have a um a DCIM system data center INF infrastructure management system you may have rack elevation level details crawl deals with what I consider the conceptual to logical to physical data model the the reason we start with crawl is twofold the first reason is because a lot of times you're dealing with Architects at the crawl level at at the business application Level you're dealing with Architects at the business application Level and you get them involved with the data the infrastructure folks the operations folks folks down here at discoverable piece Parts uh this is where operations tends to really start but they need to connect so the often part uh often times you have you can find a business application portfolio you can find Discovery and then the question is how do we connect these two these might be in different systems initially but as you adopt servers now you can you can leverage everything on service now to manage both ends and keep those two connected just in connecting the business apps to Discovery for example in all the parts in the day Center you can often find Opportunities to optimize what you have for example you may have a lot of infrastructure that has been retired and nobody turned off the infrastructure in the data center so getting a tight line between these two worlds is usually important next is walk being able to leverage and the technical services and do be able to leverage the dynamic CI group do be able to query what CIS are related to what Technical Services so what teams manage those Services what are the life cycles what do they support what are the slas for those particular items um getting the technical services folks on board is important this is it helping it folks and the engineering disciplines to understand what they own and manage in the data center and to do that better over time as they adopt various processes next is run or we introduce the offering and business service and this often relies on some of that core data as well like the who are the users and if you know the location for that particular business service you can identify the related users through the location relationship so as U it's a better management of the services and its context the better off you'll be long term last is fly and fly is really I like to think about that is the icing on the cake for the rest of the model you can actually bring some of these elements early I Al often get the question about well wait a minute Mark we're bringing in our business applications right here we have a mature capability hierarchy you can certainly bring those in earlier and establish them uh right as as you define crawl so these are guidelines this is all guidance at the end of the day so don't look at this like csdm Bingo you don't have to do things in this order and you don't have to do everything we're saying to do in csdm we just recognize the products that we have the use cases that we Pro they provide usually use this data in a very succinct way and this was just a guide to get you there and to leverage and get the value out of the data on the platform so I wanted to thank you for paying attention to this session this is just a very high level overview of the three pillars csdm what the cmdb is all about some of the tools available some of the products available that help you get up to speed and use csdm and our cmdb in a more successful way and so as if you need more information these links will be provided at the bottom of the video and allows you to kind of jump in there um some of the things for example our impact offerings uh we have Services now that we provide in order to assess your cstm situation and provide advice or to assess your cmdb at a basic level to see what quality is issues you might have that need to be addressed we have a huge following on YouTube this video is one of many we'll have a link to the playlist here at the very end and there's a lot of on demand material available in now create now create is part of our now training area and allows you to download additional information additional presentations about um about cstm that you can leverage right away example models are a very common thing and there's some Workshop materials if you want to run an internal Workshop or uh Do Your Own Thing to be able to kind of Workshop you know getting your data model into the cstm format and last but not least is product documentation we have really good product documentation out there uh we try to keep all this information about U as a about references of what kind of products are using what kind of data how to migrate to the new life cycles there's documentation on that so these this is all good reference material and and last I don't want to miss this but the community site and the csdm paper itself which is the original how we delivered this to customers in the very very beginning is a white paper so you can look at the cstd and white paper it may say draft on the white paper but it's been out there for two years now and it hasn't changed and that is pretty much um what's been used ever since so count the draft as a final version thank you very much for paying attention to this session and I hope it's useful and