Foundational Data Concepts for ServiceNow

0:00Hi, Sean here, and welcome to this skill where we're gonna be taking a look at a few foundational concepts that will really help you understand setting up and working with CMDBs and ServiceNow on a deeper level. Now, the first question here, which may seem rather obvious, but you'd be surprised how many people have difficulty answering this question, is what exactly is a CMDB in the first place and what purpose does it serve? Now, in my typical fashion, I like to kind of reverse this question here and ask what purpose does it serve first.

0:34So let's jump over to my whiteboard here, and I'm gonna start off here with a situation, right? So this may sound familiar to you, it may not, but either way, I think it should help illustrate why CMDBs are so important. Let's imagine that in your organization, it's 2 a.m. and something bad happens, right? Now, there's plenty of things that could go wrong, but in this particular case, let's say that the customer-facing checkout page goes down, right? Maybe the customer tries to check out and it just sits there and spins forever, and this is a major problem, of course, because while this is happening, the company's not making money, right?

1:12Customers aren't checking out, customers aren't buying things, it's really bad. And so in this situation, what'll typically happen is the on-call engineer will be summoned, so to speak, and what they're gonna do is they're gonna try to figure out what's actually broken, right? So in this case, it probably wouldn't take very long to figure out that maybe the checkout service is failing, but this could be for any number of reasons. Now, here's the major problem.

1:43We happen to know, looking at this from the sort of omniscient storyteller perspective, that there are many things that could be causing this, right, the checkout service might be failing because of the database, right? Let's just draw that over here, sort of a sloppy database, but you get the idea. Maybe the checkout service is failing because of the payment gateway integration, something's wrong with that. Maybe the checkout service is failing because of a server that got patched earlier that night, or maybe the checkout service is failing because of a network change that someone made the day before, right?

2:22Now, again, going back to the main problem here, this engineer, right, our engineer that we've summoned, is more than willing to check out all of these things and see which one's the problem, but at this point, they don't actually know what things the checkout service depends on, right? They don't know that the checkout service has anything to do with this database or this payment gateway integration or this server or this network change, and that is the main problem that a CMDB, when properly used and maintained, will help us avoid.

2:58Right, so in other words, the main problem here is that our on-call engineer is gonna spend probably the first, let's say, 40 minutes just trying to map out what the checkout service actually depends on before they can even start diagnosing the real problem, right? So they're not able to check out the database or the payment gateway integration or the server or the network because they don't know that the checkout service depends on those, right? That information, if you're in an organization that unfortunately is like most, lives in many different places, right?

3:35Maybe some team over here has a spreadsheet that they maintain that has that information. Maybe, you know, fast asleep halfway across the world is the engineer that set this up, and that engineer remembers setting all of this up and remembers what the checkout service depends on, but that, at this point, is just what we call tribal knowledge, right? In other words, it's knowledge that's locked away in this person's head. And, you know, maybe somewhere else, maybe on Slack, let's say, there's a series of messages between people from the last time that something like this happened.

4:10Now, unfortunately, that conversation doesn't include our long-suffering on-call engineer over here, and so it's not really useful. So, again, all of the idea here of a CMDB is to get all of that stuff out of spreadsheets and people's heads and Slack conversations and into a place where any employee who needs that information, in this case, you know, our on-call engineer, can access it and quickly figure out how everything in our organization is connected.

4:44So that is the idea of a CMDB.

0:00All right, so as I said, now that we are familiar with the type of situation that CMDBs help avoid, or rather help facilitate the solution to perhaps, let's talk about how a CMDB actually works, right? How does it achieve this, you know, rather idealistic sounding task of getting things out of people's heads, out of Slack conversations, out of Excel spreadsheets, and into a centralized place where the right people, in this case, again, our engineer, have access to the information that it contains.

0:35Well, here's the basic idea behind a CMDB. A CMDB is a centralized repository that stores information about all the IT assets in an organization. Now, in ServiceNow, just to show you where this lives, if you go to the All menu and then search for CMDB, right, most of the things that have CMDB in the name have something to do with what we're gonna be looking at in this course. So just to give you a basic idea of how wide ranging the CMDB world is within ServiceNow, just wanted to show you that.

1:12As I said, a CMDB stores information about all the IT assets in an organization, and these are typically referred to as CIs, right? Yes, there are a million and one acronyms in the ServiceNow spaces. I'm sure you're already aware. And this stands for configuration items. Now, again, that term configuration item is just a rather nerdy way of saying something that IT cares about, right? So that's the basic idea there.

1:43So the key thing to understand here is that CIs, right, configuration items, can be lots of different things, right? So they can be physical hardware, right? This can include things like servers, laptops, routers, switches, right? This can be software. So this could be like applications, licenses, and it is really hard to say all of those things and come up with them in my head while I'm writing this. Anyway, they can be applications, licenses, OS versions.

2:15They might be virtual assets, right? So, you know, this could be VMs, containers, cloud instances. They might be services of some sort. So this could include things like email. This could be a customer-facing web app. This could be a payment gateway. And it can also include a host of other things like documentation, contracts, and even people or teams who own something. That's actually a very important CI, right? Because it helps us understand if something goes down, who owns that thing that is causing the problem, right?

2:51And so anyway, that's the idea of a CI. Now here's the other part of a CMDB and how it relates to the scenario that we discussed previously. The database doesn't just list these items. It also maps how they connect, right? So there's a variety of different terms for this, but for now, we're just gonna call it relationships. So in addition to the CIs, it also maps the relationships between those CIs, right?

3:24So the CIs themselves are the things that the IT, you know, the things that IT cares about. The relationships are how those things are related to one another. And so that might sound rather obvious from the name relationship, but this might be something like saying that the web app depends on, let's say, these three servers, right? And maybe it also depends on this database over here, and maybe it also is load balanced by this device over here, and maybe it's owned by the payments team, right?

3:59Those are all very important relationships between things that could all be represented in a CMDB by a CI, right? This team that owns the thing is a CI. These servers are each their own CI. This load balancer is a CI. This database is a CI, and the web app itself is a CI. So by having that map, right? Let's go back to our other situation. What would this allow us to do? This would allow the on-call engineer to look at the web app and see, okay, this thing's related to these things.

4:34These things are related to maybe these other things. Maybe these servers depend on some other database or some other service. Those things depend on these other things, and ultimately, that just makes it much easier to at least know what parts of the vast IT system you need to investigate when something goes wrong. All right, so hopefully that helps you understand the main sort of subtopics underneath CMDBs, which again are CIs and relationships, and how they combine in order to give everyone in an organization a more accurate picture of how everything is connected and what all exists.

5:15So the next thing that I'd like to do, just to kind of close off this discussion about the basics of CMDBs, is I wanna go through a few additional situations, maybe slightly simpler than the first one that we went through, and discuss how a CMDB would be a lifesaver in each of those situations. So let's start off with the first situation here, which we'll call impact analysis. It's not a name that I came up with. That's a regularly used term, I know. All right, so let's imagine here that we have a database admin, and this database admin has realized that they need to apply a security patch to a database server over the weekend, right?

5:58Maybe this server has a known vulnerability that it's important that they fix. Well, the problem with this server is that it's an older server, and nobody in the organization is entirely sure what applications or what other parts of the infrastructure still use it, right? There's obviously lots of other apps out there, right? Other servers out there, but is there still an active connection between these things and that server that needs to be updated or not?

6:28Well, this is kind of a tricky situation because the database admin either needs to delay the patch, which leaves a known vulnerability open longer, or they have to take the risk, patch it anyway, and see if anybody calls them at three in the morning saying that something critical broke, right? That is not a good situation, and so here's how a CMDB would help. In this case, if this organization had a CMDB that had up-to-date information on all of this stuff, the up-to-date part is another issue that we'll talk about in much more detail in this course, but what the database admin would be able to do is pull up the server's CI, right?

7:11Remember that pretty much everything in here is going to have a configuration item that represents it, but what the database admin will be able to do is pull that up and look at something called its relationship map. Now, what this will enable that database admin to see is that maybe there are three applications that still depend on that server, and maybe two of them are no longer in use, maybe they're an old internal reporting tool of some sort, and maybe the third one is something that's moderately important, but not as important as the vulnerability in this database server, right?

7:50Well, in that case, using this information, the database admin would be able to schedule that patch and give a heads up to whoever owns that reporting tool, that's another CI, by the way, and relationship, that we know who the owner of that is, that will tell them what's going on instead of blindsiding them on Monday morning when they come in and their application doesn't work, right? So that's the first sort of additional situation. Let's talk about another one, which is a slightly different sort of situation.

8:25Let's talk about compliance and auditing, right? Let's imagine that a company that handles customer payment data is going through an audit. Well, what the auditor is going to ask for, auditors always seem to wear glasses, I don't know why, but what the auditor is going to ask for is a list of every system that stores or processes cardholder data along with what's protecting each one. All right, now, in this case, if we don't have a CMDB, this is gonna be a problem because the security team would need to go system by system asking different teams to confirm what's actually running and how it's configured, and this could take weeks.

9:07All right, now, if we were using a CMDB, as we'll see a little bit later, the cool thing about CIs is that, in service now at least, they're typically tagged by data sensitivity and compliance scope, and what this would give us is an accurate list of servers, databases, applications, whatever it is that's processing this data in a matter of minutes instead of weeks, along with which ones have encryption enabled, hopefully all of them do, who owns them, maybe this person over here owns them, this person over here owns this one, and when they were last reviewed.

9:45So, as you can see, that's gonna make it much easier to get this information back to the auditor, in that situation. All right, and the last situation here that I'll give you has to do with cost management. These are just three of many different situations, by the way, but I think this gives kind of a good sampling of the various situations that CMDBs can help with. All right, so in this situation, let's say finance, our auditor wore glasses, maybe our finance team wears a tie.

10:17Ha ha ha. Let's say that finance flags that the cloud bill has gone way up over the past year, right? Maybe it's gone up 30% over the past year, and they want IT to explain why this is. Well, in this situation, if we don't have a CMDB, then IT might suspect that some of it's waste, right? Maybe we have unused VMs, maybe we have over-provisioned servers, maybe we have duplicate licenses, but again, without a CMDB, there's no easy way to see what's actually being used versus what's just been sitting there since some project wrapped up, right?

10:59And so in this case, what we would be able to do is look through a number of different CIs, right? Maybe one's a server, one's a virtual machine, one's something else, I don't know, and maybe this uncovers that a cluster of virtual machines from a project that ended maybe eight months ago are still running and still billing because nobody flagged them for decommission. This kind of thing happens all the time. And so in this case, all our IT team would have to do is shut them down and formally retire those CIs, and that would cut out a chunk of the bill immediately.

11:38All right, so anyway, these are just a few additional situations where a CMDB could really help us out. Hopefully this has helped you to understand the importance of CMDBs and what they allow us to do.

0:00All right. Well, now that we've talked about the basics of CMDB and why this concept is so important in ServiceNow, the next thing we're going to do is talk about another concept, right? Another acronym, unfortunately, which is CSDM. And that stands for Common Service Data Model. Not very helpful for understanding what this thing is, but that's what it stands for. People typically tend to wonder that. So CSDM is ServiceNow's standardized framework for organizing and relating configuration and service data across the platform. Yes, I did have that definition written down. Yes, it's a mouthful. Let's talk about what this actually means in simpler terms.

0:44So the idea of CSDM, in order to understand this, let's go back to the basics of CMDB, right? A CMDB, as we saw, allows us to organize lots of individual things that IT cares about, right? Which we call configuration items or CIs and also keep track of the relationships between those things, right? So this might be related to this somehow, this related to this, this related to this, this related to this, right? All right. Now, this is great. And it's a huge step up from, you know, everyone in the organization having no idea what resources we have and how they're related. Don't get me wrong, but it's not quite enough. And here's why. CMDB answers what things exist in our organization and how do they relate. What it doesn't answer are things like what business capability does this server actually support, right? In other words, is this just supporting an internal team? Is this a critical part of, you know, the company being able to sell products on Black Friday? What does it actually support, right? Or, you know, let's talk about this CI over here. If this CI goes down, let's imagine this is another, maybe this is a

2:03database. If this database goes down, which specific customers would be affected by that? Another very important thing that CMDB alone doesn't allow us to answer, at least not easily, right? Not in a way that's automatable typically. And so the problem with CMDB alone is that it tends to become a flat pile of CIs with relationships that made sense to whoever built them at the time, but that ultimately don't compose into anything meaningful at the organization level. So again, this might sound rather abstract at this point. That's okay. You'll see how this works in much more detail as we go through the course. But really, the main thing that CSDM does is it organizes everything into five conceptual layers, right? So I'm going to write CSDM layers here, and we'll go through the exact layers and what they mean here shortly. But the basic idea here is that the higher layers are closer to the business purpose or the business goals, right? So up here, I'm going to write business goals, right? And the lower layers

3:20are closer to the technical details, right? So what servers do we actually have? How are they actually connected? So we'll write technical details there. All right. So just to give you a simple walkthrough to show you how this CSDM framework works without going into the specific layers yet, which we will do, let's take a look at a specific situation and see how each of the different pieces there falls in a different place along this spectrum, right? From business goals to technical details. Let's imagine here that you're running an online store, and one night you get an alert that a database server has crashed, right? Well, that database server, right? We'll just draw that as a little database here. For some reason, I'm very bad at drawing that all of a sudden. Let's try that again. There we go. All right. That looks a little bit more like the typical database icon that you see. So anyway, this database server has crashed, and the next question is now what, right? So in other words, even if we have a CMDB that keeps track of what this database is connected to or related to, someone's still going to have to go in there and

4:39manually figure out from those relationships which app uses this database. Does checkout use it on our application, or is it something less critical like maybe the internal employee directory that no one uses anyway, right? All right. Maybe this database is related to checkout, but is it our main revenue source, or is it a small side feature? And some additional questions here could be things like who do we call, and how urgent is this really? Does this have to be fixed now, or can this wait until morning? All right. So in order to understand how CSDM fits into all of this and kind of categorizes things by how close they are to the technical details or to the business goals, let's start at this server and kind of work our way up the chain. Let's say that this database server is part of, we'll talk about this in a little bit more detail, but there's some standardized relationships that CSDM defines for us that make it really nice and easy to come to conclusions from technical details that business execs would care about, right? And so let's say that this database server is part of our checkout application, okay? So we'll write checkout app there, right? So this would be the software that runs checkout. And maybe this checkout app

6:01delivers, that's another relationship that we'll be able to define as you'll see a little bit later, the online checkout service, right? This is the service that customers actually experience, right? So again, we're getting closer to the business goals here. And finally, this online checkout service supports the business goal of selling products online, right? So we're going to say sell products. So as you can see this, right, organizing all of these things in this way from what, you know, corporate executives would care about most to what the IT team would care about most, right? What this allows us to do is instead of an engineer sort of reverse engineering the business impact from a server name, right? The server that crashed because of this standardized framework and these standardized relationships that we'll talk about later on service now will automatically be able to calculate the business impact here. And that saves us the trouble of having to manually investigate this situation, right? So once again, hopefully this little example has taken the idea of CSDM from something more abstract to something a little bit more

7:22concrete, or at least hopefully you can see the, hopefully you can see the benefits of being able to organize things like this. But just to summarize this in an even simpler way, the CMDB as we've seen allows us to keep track of what we have and how it's related. And CSDM allows us to make deductions from that, that the business actually cares about. All right. And I'm trying to draw a light bulb there. There we go. More concretely, it allows us to go from saying this thing crashed, which affected this thing and this thing and this thing to this thing crashed. And that's going to cost us this much money per hour until it's fixed, which is a much more actionable insight.

0:00All right, so now that we've talked about the basics of CSDM and the fact that its main purpose is to allow us to organize our CMDB data more effectively and gain insight from it, the next thing that we're gonna do is we're gonna go into a little bit more detail on what those layers that I mentioned are. And by the way, these are also called domains, right? You'll hear this word used for them as well. Now, I don't remember whether I said that there were five or not in the previous video.

0:31I think I did. There are actually seven. There are different versions of this thing bouncing around. All right, this new version, right, CSDM recommendations have versions just like anything else does. They released CSDM 5.0, which is what these specific layers come from. But anyway, whether there's five layers or seven or 25 or however many layers you wanna define, the main idea is still that these layers allow us to group our CMDB items, right, our configuration items more effectively and gain insight from them automatically.

1:10Don't forget that, okay? So let's talk about these layers, and I'm gonna give you some examples of these too. The first layer, which interestingly enough, isn't really part of this whole CI relationship thing. It's more like reference data. It's what's referred to as the foundation layer. So this layer, and I'm gonna kind of write the main concerns of each layer here, is the context under which the rest of the layers exist.

1:40So in other words, this tells us things like who's involved, where all of this stuff is taking place, and also things like under what agreement, right? So what contracts are there involved? That one might be a little bit confusing. I hesitated to include it, but I thought it might kind of help some people understand what this does. So anyway, this is just the surrounding context that all of these applications are taking place in, right?

2:10So these are things like users, groups, different locations, office locations, things like that, different companies, different departments, and as I said, contracts. So once again, these things are not typically considered to be part of the other layers, but they form the background or the references that we'll see in many of the other layers. That probably sounds very abstract. Please don't worry about that at this point. You will definitely have plenty of practice with these layers when we get to using them in ServiceNow.

2:45But anyway, let's go to the next layer here, which is the ideation and strategy layer. So the ideation and strategy layer answers one main question, and that is why are we building this, right? So this domain captures the demand and intent of different features or different products that our company wants to offer, right?

3:16So just to give you a slightly more concrete example, let's imagine that we're working for a company that has some sort of online banking service, right? Well, in this case, in this layer, we might find something like we want a mobile check deposit feature because we believe this will increase the number of customers, something like that, all right? So the next layer down, we have the design and planning layer, right? Many of these layers, as you'll see, have double names.

3:49I don't really know why. They didn't just pick one word for it. But anyway, the design and planning layer, the question this answers is what should this look like when it's built, right? Now, maybe that's a slightly strange way of putting it because it's not just visual, right, even though that is part of it. It's also things like, I mean, what are the specific details behind this feature that we want to offer, all right? So going back to our mobile banking application scenario, this, you know, at this layer, this is basically just a plan on paper or probably not actually on paper, but you get the idea for what the online banking app, the mobile deposits feature should be, okay?

4:35So going down to the next layer, this is where we find build and integration. I told you all of these have double names here. This layer is where we answer the question how is this actually being constructed, all right? So we'll say how is this constructed? I'll shorten that a little bit. All right, so hopefully you're noticing at this point that, again, what we're doing is we're going from more business-related concerns. Technical people might call them vague concerns like, you know, why are we building this to more technical concerns like, okay, how are we actually going to build this thing, okay?

5:15And you'll see that this pattern continues in the next layer, which is the service delivery layer. The main thing that this layer is asking is what is actually technically running from an infrastructure point of view, right? So here, we'll just say what's running. I'm gonna shorten it to that. And this is what most people think of when they think of a CMDB, right?

5:48This is where things like servers, databases, cloud instances, application components, this is really the primary layer on which those live. And I guess I should probably clarify the build and integration layer, this would be where things like source code repos, build pipelines, releases, sprints, that sort of thing lives. The service delivery layer, that's where the actual infrastructure that that stuff runs on lives.

6:19So hopefully that makes sense there. All right, so the next layer, this is where the layers sort of stop their march from business desires to actual technical details. This is the service consumption layer. All right, so this layer is where we answer the question, what does the customer, right, actually get? So we'll just say what does the customer get here in our question?

6:50All right, so ultimately this layer is the packaged sellable or usable thing. All right, so customers don't care that the application they're using uses a database or server or whatever behind the scenes, at least typically they don't. They care, do you guys offer mobile check deposit, right? And so this layer is typically the layer that shows up on things like customer facing catalogs or business dashboards, right? And finally, the last layer here, which I'm gonna try to squeeze in, this is the manage portfolios layer.

7:27And this is the layer where we ask, how does this fit into everything else that we run, right? So how does our mobile check deposit feature fit into all of the other services that we provide? All right, so anyway, those are the seven CSDM layers and the main questions that they help us address. All right, so just a sort of mental shortcut here to help you make sense of all of this. And again, don't worry if this doesn't completely make sense yet.

8:01There will come a time later in the course, I promise when you see something that ServiceNow does, you think it's a little strange and then you remember these layers and you're like, oh, that's right, okay, that's why ServiceNow chose to do things this way. So anyway, these layers here, layers two, three and four, these basically define the service before or while it's being created. Layer five here, this is the technical reality of what's running.

8:34Layer six is the business packaging of that same thing and layer seven is the management view across the entire landscape, you might say. And then layer one going way back to here, this is the shared reference data underneath everything. So hopefully that makes sense for now. Again, you will see these layers show up in ServiceNow a little bit later in the course. And when you encounter them, I hope that this video will help you make sense of them a little bit faster.

0:00All right, so at this point, we've talked about the basics of CMDB, the basics of CSDM, and the last thing that we're gonna talk about here is what's often referred to, at least in the training materials, as the three pillars of CMDB, right? So the idea here is that there are so many different aspects to, you know, managing CMDB, right, and to actually making that data useful that it's really helpful to have these three groups to kind of sort them into, right?

0:35This is actually quite similar to what we just talked about with CSDM, how it helped to, you know, kind of separate that into different areas. And so the three pillars here, which I'm gonna talk about in more detail after listing them, are one, ingest, right? This is typically how data gets into our CMDB. Two, govern. This is basically managing the data and making sure it stays up to date. And three, this is consume, or ServiceNow has recently changed this verbiage to insights, right?

1:12That's kind of the buzzword these days. So anyway, these are the three pillars of CMDB governance, you might say, right? Now the idea here, I'm just gonna go back and start with ingest. The idea with ingest, so far I've been talking as if all of these CIs, right, all of this information that we wanna store about the things that IT cares about and how they're related, I've been talking as if this is something that people are going to be entering manually.

1:45Now thank goodness this is usually not the case. Well, sometimes it is, but sometimes people will put stuff like this in manually, and we'll see how to do that a little bit later in the course. But typically this is done using automated discovery, right, I'll just write that as auto discovery here, where basically what ServiceNow will do, or whatever program you use for this discovery will do, is it will go through your network, and it will automatically find all of these CIs for you, and it will enter them into your CMDB for you, along with, again, their relationships.

2:23And so this is, you know, a much more sustainable approach than having some poor person or poor team whose job it is to regularly comb through your network and figure out how all this stuff is connected. I would never want that job, I think very few people do. And so typically this is automated. Now I wanna be very clear that this is far from a perfect process. There's all sorts of things that can go wrong during auto discovery. There's all sorts of important information that auto discovery tends to miss.

2:56But the basic idea is there, right? We want some sort of automated way to get most of the things that we want in the CMDB into the CMDB, right? All right, so once we get those things into the CMDB, and this is a continuous process, right? Your network and all the relationships in it are continually going to be sort of evolving, right? In fact, all three of these pillars are pretty continuous processes.

3:26But really the next stage here is the govern stage, or I've called them the pillars, the govern pillar. And this is the ongoing process of keeping ingested data, all of these CIs and their relationships as trustworthy as possible, right? We want these CIs to be accurate, right? We want them to represent the data that's actually out there. We want them to be current, so we don't want older versions of the data. And we want them to be non-duplicated, right?

4:00So we don't want two CIs in there representing the same thing. Now, all of these might sound obvious. You might be thinking that they're simple. They are absolutely not. And we're gonna see that later on in the course, right? So the idea here again is that no matter how good the data in a CMDB is at first, it degrades very quickly, right? Again, as soon as something changes in the real world, in your real world IT setup, the CMDB is now out of date, and an out-of-date CMDB is one that nobody wants to use.

4:37Why? Because, well, it's out of date, right? It's not the right information. All right, so for this one, I don't have a good visual like I had for ingest where we're sort of automatically adding these things into the CMDB, so I'm just gonna write those sort of three sub-pillars. I don't know if I wanna call them that, but you get the idea. The three things that we typically will want to ensure, in fact, I'll write them as A, B, and C here, which are that the data is accurate, right? That the data is current.

5:08And lastly, that the data is non-duplicated. I'll just write non-duped there, all right? So that's the idea of governance. There's lots of different pieces of governance, just as there are lots of different pieces to ingesting. And so the last pillar here is the consume slash insights pillar. This is where we use the governed data in our CMDB to help us make better decisions and add automation elsewhere in the platform, right?

5:43So again, the CMDB is typically not an end in itself. You probably won't think this by talking to your average IT person who works with one, but the ultimate goal of a CMDB, which is achieved in conjunction, as we've seen, with CSDM, is to help bring these IT concerns automatically into the business concerns realm and vice versa, right? So again, this is a drawing that I made a little bit earlier in the course, I believe, but this is where we take all of the data that's in our CMDB, all the CIs and the ways that they're connected, et cetera, and make real-world insights that business executives actually care about, right?

6:28So this is where we get, again, I'll draw that little light bulb here. There we go. For some reason, that's a really hard thing to draw. I don't know why. But anyway, that's where we turn this technical information into something that business people care about, right? So again, instead of saying things like, hey, this database needs to be updated or something like that, which most people on the business level will respond to with a blank look, we can say, hey, this database needs to be updated because it's linked to this application and could potentially have these negative effects on the business side.

7:02Again, that's what people care about up there in the business world. All right, so anyway, these are, again, the three pillars of working with CMDB data. Once again, ingesting is how we actually get the data into our CMDB. Governance is making sure that that data remains high quality, and in many cases, even improving the quality above the auto-discovery. And consume slash insights, where we take all of that curated data and turn it into business insights.

7:34So anyway, those are the three pillars.

0:00All right, well hopefully you've given this challenge a try and answered all of the questions. So what I'm gonna do here is I'm just gonna walk you through and give you a little more of an explanation around the answers. So the first question here was, which of the following is the best example of a configuration item, CI? I wanted the opportunity to explain this one especially because throughout this skill, I've been referring to CIs as things that IT cares about. And this, you know, this is an easy thing to say.

0:31Certainly it prevents me from having to search for more effective words. But the fact is that not all of the things below are technically CIs. In fact, only one of them is. And so by reading through them, my hope was that one in particular stood out, and that is a production database server, right? So things like help desk tickets, change requests submitted last week, a monthly status report. Obviously, you know, people working in IT care about those things in many cases, but they're not something that we can manage through a CMDB, right?

1:10In other words, these are not things that other things typically depend on. You could have a help desk ticket that maybe references a database server, right? If something is, let's say the server's down, but that does not make it a configuration item, right? And so anyway, that is the right answer for that. There we go, we got that right. Moving on to the second question. What is the primary purpose of a CMDB? We've talked about this one in pretty extensive detail, so hopefully you got this one right.

1:42And that was to provide a single source of truth about IT assets and their relationships. The other ones were, you know, clearly not the right answers, so we're gonna submit that. Clearly not the right answers, provided you watched the videos above, so hopefully you did. And so the next one, which statement best describes the relationship between CMDB and CSDM? This is something that you really would have had to watch the videos about CSDM in order to know. So CMDB replaces the need for CSDM, you never need both, that's definitely not it.

2:16The next one, CSDM is only used for financial reporting, not IT data, we know that that one's not the case. CSDM provides a structured taxonomy that helps organize and give context to CMDB data. That one is absolutely it, but let's just read the last one to make sure that that one doesn't make more sense. They are unrelated frameworks and used for different platforms. Absolutely not the case, although I did mention earlier that CMDB is not necessarily specific to ServiceNow. It's used by ServiceNow, but it's also used by other platforms, whereas CSDM is more specific to the ServiceNow platform.

2:52That's something that ServiceNow actively kind of manages, is that CSDM specification. So anyway, let's submit that, and sure enough, we got it right, and the last thing here, hopefully this one is pretty easy because we just talked about it, says in the ingest, govern, consume insights model, which stage is primarily responsible for bringing data into the system, i.e. via discovery tools or integrations? We haven't talked about discovery tools or integrations yet, but I wanted to give you a little kind of hint there of what's to come later when we get back into ServiceNow.

3:23So this one, of course, is ingest. Sometimes people get confused there and say that that's consume, right? Consuming is typically when a human user is consuming something from a system, right? When a system is getting data from somewhere, we typically call that ingestion, right, ingesting. So we're gonna submit that, and sure enough, that is the right answer. So anyway, hopefully these questions helped solidify what you already knew. In case you're wondering, you may have been expecting at this point a sort of matchup question where you had to match different things to the different layers of CSDM.

4:00I specifically didn't do that because that's something that we're gonna get into in much more detail when we start taking a look at how CSDM is actually implemented in ServiceNow. As you'll see, there's all sorts of different tables and tools we can use that will directly represent or directly reflect those domains or layers that we talked about. So we're just not really ready for that at this point. Just wanted to point that out here. So anyway, that is the solution to the challenge. So hopefully this helped to solidify your knowledge, as I said.