nexus/knowledgebase/course-notes/ServiceNow-CMDB-Fundamentals-Notes.md

Configuration Management Database (CMDB) Fundamentals

Course Notes (structured from transcripts)

Source: /Users/weishen/mnt/volume2/knowledgebase/course/Pluralsight.Configuration.Management.Database.CMDB.Fundamentals.2026.BOOKWARE-GETH Generated: 2026-09-19 Note: 22 video transcripts across 3 chapters. Instructor: Ramiz. Pluralsight 2026.

---

Chapter 1 — 01. Course introduction

Core Insights

• CMDB solves the problem of configuration data scattered across spreadsheets, ticketing systems, and outdated documentation.
• The CMDB is positioned as the backbone of modern IT operations: faster incident management, safer change management, and real IT visibility.
• A neglected CMDB turns change management into guesswork and makes impact analysis impossible.
• The course is structured in three modules: foundation (Module 1), hands-on building (Module 2), and ongoing quality/governance (Module 3).
• Target outcome: ability to understand, build, and maintain a CMDB that genuinely supports IT operations.

Detailed Notes Course Motivation

• IT teams lack a clear picture of what is running and how everything connects when incidents occur or changes go wrong.
• ServiceNow CMDB is presented not as a nice-to-have but as a foundation for incident, change, and visibility.

Course Roadmap

• Module 1 — What the CMDB is, why it matters to ITSM, and the real benefits of maintaining it well.
• Module 2 — Hands-on: creating CIs, defining relationships, populating the CMDB with different methods, building a working configuration database.
• Module 3 — Ongoing work: monitoring CMDB quality, fixing common data issues, implementing governance for long-term reliability.

Action Items

• List where configuration data currently lives in your organization (spreadsheets, ticketing, docs) to scope the CMDB problem.
• Map the three-module structure onto your learning plan before starting hands-on lab work.

Key Terms/Concepts

• CMDB (Configuration Management Database): central repository of IT configuration data; the single source of truth for what is running and how components connect.

Chapter 1 — 02. What is the CMDB in ServiceNow

Core Insights

• The CMDB is a centralized repository — a master inventory of configuration items (CIs) such as servers, databases, applications, network switches, and printers.
• In ServiceNow everything lives in the base table cmdb_ci; specialized tables (server, database, application) inherit from it.
• The CMDB's power is in relationships: it maps how components connect, turning raw data into intelligence (e.g., server ABC hosts app XYZ, connects to DB 123).
• The CMDB is dynamic — it should reflect real-time infra changes, showing what is actually running, not what should be running.
• CIs carry essential attributes (name, manufacturer, vendor, location, operational status) that tell the story of each asset.

Detailed Notes What Counts as a CI

• Any part of IT infrastructure with relationships to other components qualifies — servers, databases, switches, applications, software, even printers.

Table Architecture

• cmdb_ci is the core base table where all CIs live; child tables like cmdb_ci_server, cmdb_ci_database, cmdb_ci_application branch from it.

Three Pillars of Value

• Centralized: one place instead of per-team spreadsheets — answering questions doesn't require pinging five people.
• Relationship-aware: spreadsheet says a server exists; CMDB says what it hosts, connects to, which licenses it needs, its team, and which services break if it goes down.
• Dynamic: reflects constant provisioning, retirement, and configuration shifts.

Cost of Neglect

• Outdated CIs and missing relationships make change management a guessing game, lengthen incident resolution, and break root-cause analysis — inefficient and dangerous.

Action Items

• Inventory your key CI types and verify they could be modeled under the cmdb_ci hierarchy in ServiceNow.
• For one critical server, write out its full relationship map as a warm-up exercise for CMDB modeling.

Key Terms/Concepts

• Configuration Item (CI): any component of IT infrastructure worth tracking in the CMDB.
• Base table (cmdb_ci): root table from which all CI classes inherit.
• Relationship: documented connection between CIs that enables impact analysis.
• Single source of truth: one authoritative, accurate record of infrastructure configuration.

Chapter 1 — 03. Demo Understanding the CMDB interface

Core Insights

• The CMDB application in ServiceNow is organized into modules for management, health, and data exploration.
• Management modules: CMDB 360 query schedules, Class Manager (class hierarchy, identification and reconciliation rules), Groups, Query Builder, Health Preferences, Remediation, Reports, and Exclusion List.
• Health visibility: the CMDB Health Dashboard measures completeness, correctness, and compliance.
• Category modules (application server, servers, clusters, database, network) list specific CI types; clicking a record opens the full CI with attributes.
• The Exclusion List prevents specific items from being created/updated as CIs — commonly paired with Discovery.

Detailed Notes Management Modules

• CMDB 360 query schedules: scheduled queries for a 360-degree view of a CI across the CMDB.
• Class Manager: centralized management of class hierarchy, identification rules, and reconciliation rules.
• CMDB Groups: logical grouping of CIs for management, reporting, and access control.
• Query Builder: build complex queries spanning multiple CI classes and relationships without code.
• Health Preferences: settings driving how CMDB health is measured.
• CMDB Remediation: track/manage actions fixing data quality issues.
• Reports: pre-built reports for visibility into CMDB data.

Health and Data Modules

• Health Dashboard shows visual metrics of completeness, correctness, and compliance.
• Category modules such as application server, servers, clusters, database servers, database instances, and network group related CI types; e.g., network groups different network device types.
• Opening a category (e.g., database) shows the CI list; clicking through opens the CI record with all attributes.

Action Items

• In a personal developer instance, navigate to Configuration and click through each module once to build spatial memory of the interface.
• Open the Class Manager and review the identification/reconciliation rule options available by default.

Key Terms/Concepts

• Identification rule: logic that decides whether a discovered item matches an existing CI or creates a new one.
• Reconciliation rule: logic resolving attribute conflicts between data sources.
• Exclusion List: items blocked from being created/updated as CIs.
• CMDB Health: measurement of data completeness, correctness, and compliance.

Chapter 1 — 04. CMDB and ITSM process integration

Core Insights

• The CMDB is the thread tying incident, problem, change, and asset management together.
• Incident management: linking an incident to a CI instantly reveals dependencies, downstream systems, and impacted users — cutting investigation time from ~30 minutes to seconds.
• Problem management: relationship data turns five seemingly unrelated incidents into an obvious pattern pointing to a common root cause.
• Change management: impact analysis shows the blast radius (dependent apps, downstream risk) before approval — without it, change management is guesswork.
• Configuration data flows both directions: executed changes update the CMDB (patches recorded, retired apps marked inactive, new databases added).

Detailed Notes Incident Management

• First step on an incident (e.g., slow accounting app) is linking it to the relevant CI — the app itself or its hosting server.
• From the CI, teams see what depends on it, what databases feed it, and what systems are downstream.

Problem Management

• Five incidents sharing a cause (e.g., a failed network switch) become visible as one pattern via relationship data, enabling root-cause analysis and preventing cascading failures.

Change Management

• Before approving a change (e.g., patching a DB server), the dependency map shows affected applications and the full impact chain.
• Data-driven scheduling, testing, and stakeholder notification replace guesswork.

Bidirectional Flow

• Changes feed back into the CMDB: patches, retirements, and provisioning keep records current.

Action Items

• For each incident template in your org, define which CI linkage should be mandatory.
• Draft an impact-analysis checklist for change requests that queries the dependency map before approval.

Key Terms/Concepts

• Affected CI: configuration items directly impacted by an incident.
• Blast radius: the set of downstream components at risk when a change is applied.
• Impact analysis: evaluating consequences of a change using CMDB relationships.

Chapter 1 — 05. Demo Incident linked to CMDB

Core Insights

• Incidents carry two distinct tabs: Affected CIs (directly impacted, being worked on) and Impacted Services/CIs (downstream business services affected via relationships).
• Affected CI lists speed resolution — technicians know exactly which systems are involved with no guessing or email chasing.
• Repeated appearance of the same CI across incidents is a strong signal for problem management root-cause analysis.
• Impacted services give a service-centric view that drives prioritization, SLA tracking, customer communication, and major incident decisions.
• Clicking a CI (e.g., SAP App SRV01) opens the full CI record with attributes and a related-items dependency list — the link between incidents and the rest of ITSM.

Detailed Notes Demo Walkthrough

• Navigate to Incident → Open, select an incident, and review standard fields: short description, caller, priority, assignment group, state.
• The Affected CI tab lists CIs directly involved in the incident; the Impacted Services/CIs tab shows downstream business services derived from CMDB relationships.

Value to Roles

• Incident resolution: immediate identification of the affected server, application, or database.
• Problem management: pattern detection when the same CI recurs across incidents.
• Management: a service-centric view — seeing degraded business services, not just a broken server.

CI Record Drill-Down

• Clicking SAP App SRV01 opens a server CI showing name, class, operational status, owner, location, and related items with all dependencies.

Action Items

• Standardize the practice of always linking incidents to affected CIs in your instance.
• Build a recurring report of top CIs by incident count to surface potential problems early.

Key Terms/Concepts

• Affected CIs tab: CIs directly impacted and under investigation for the incident.
• Impacted Services/CIs tab: downstream services and CIs affected as a consequence, derived from CMDB relationships.

Chapter 1 — 06. Benefits of a well-maintained CMDB

Core Insights

• Operational benefits: faster incident resolution, outage prevention via single-point-of-failure discovery, and higher change success rates.
• Strategic benefits: infrastructure-wide visibility enables cost savings (retiring redundant apps, capacity optimization), true service dependency mapping, and data-driven strategic decisions (cloud migration, consolidation).
• Governance benefits: compliance audits, risk identification (unsupported OS, end-of-life apps), and organizational accountability through CI ownership.
• Prevention is cheaper than firefighting — reinforcing critical paths before they break.
• The real value isn't what you spend on the CMDB; it's what you save: time, money, effort, and risk.

Detailed Notes Operational Benefits

• Incident resolution: teams instantly see context, dependencies, and impact from the affected CI.
• Outrage prevention: accurate relationships reveal hidden vulnerabilities and single points of failure.
• Change success: better planning, testing, and communication raise change success rates and cut production incidents.

Strategic Benefits

• Visibility/optimization: answer which servers are underutilized, which apps are redundant, where investment is over-concentrated.
• Service dependency mapping: surface hidden chains (e-commerce → server C → SAN → network segment; financial system outage blocks payments).
• Strategic decision making: answer cloud migration, app migration, and data-center consolidation questions with data.

Governance Benefits

• Compliance: audit trail proving what runs in the environment for regulated industries (healthcare, finance, government).
• Risk management: flag unsupported OS, end-of-life applications, compliance gaps, lifecycle risks.
• Accountability: CI owners, tracked changes, documented relationships make people take better care of owned infrastructure.

Action Items

• Run a report to identify single points of failure in your critical service paths.
• Create a compliance query flagging CIs on unsupported OS versions or past end of life.

Key Terms/Concepts

• Single point of failure: a CI whose outage breaks critical services and has no redundancy.
• Service dependency mapping: documented chain of how business services are constructed from underlying CIs.
• Configuration baseline: snapshot of configuration at a point in time used for change impact and compliance.

Chapter 1 — 07. CMDB terminology and ITIL evolution

Core Insights

• Configuration management is a discipline, not just a database: identifying, tracking, and maintaining CI information involving people, tools, and governance.
• Attributes (name, vendor, serial, location, status) make a CI valuable; relationships (runs-on, connects-to) are typed and drive impact analysis.
• CI classes form an inheritance hierarchy rooted at the base CMDB CI table; server CIs inherit base attributes plus server-specific ones (CPU, RAM, OS).
• The CMDB originates from ITIL, which defined configuration management in the 1980s; ServiceNow's CMDB is built on ITIL principles.
• ITIL process parts: planning, identification, control, verification/audit — with supporting concepts like configuration baseline and release management.

Detailed Notes Core Terminology

• Configuration items: the entities themselves.
• Configuration management: the whole process discipline of identifying, tracking, and maintaining CI info.
• Attributes: fields in a CI record; value comes from completeness and accuracy.
• Relationships: typed connections (e.g., app runs-on server, server connects-to switch) that matter for impact analysis.
• CI class structure: hierarchy with base cmdb_ci table and subclasses (server, database, application) inheriting attributes.

ITIL Evolution

• ITIL (Information Technology Infrastructure Library) is the world's widely adopted ITSM framework; it defined the CMDB concept in the 1980s.
• Process steps: planning (what to track and why), identification (register CIs with attributes/relationships), control (keep CMDB updated as infra changes), verification and audit (regularly confirm CMDB matches reality).
• Configuration baseline: a point-in-time snapshot (e.g., production as of March 1st) for change impact and compliance.
• Release management: deploying a new app version is a release; the CMDB records it and captures dependency shifts.

Action Items

• Define your tracking strategy first: decide which CI classes matter before populating anything.
• Set up a recurring verification/audit cadence so the CMDB is checked against reality.

Key Terms/Concepts

• ITIL: Information Technology Infrastructure Library, the widely adopted ITSM framework.
• Configuration baseline: snapshot of configuration at a specific point in time.
• Identification: registering CIs with attributes and relationships.
• Control: ensuring the CMDB is updated when infrastructure changes.
• Verification and audit: periodically confirming CMDB accuracy against reality.

Chapter 1 — 08. Demo CMDB in action

Core Insights

• cmdb_ci.list is a quick navigator shortcut to the CMDB table; the demo instance holds 2,786 CIs (real orgs often have tens to hundreds of thousands).
• Grouping CIs by class reveals how ServiceNow organizes infrastructure logically (AIX servers, applications, clusters, databases, email servers, IP routers, etc.).
• A CI record has identification fields (name, asset tag, manufacturer, serial, model), configuration details (device type, IP, location, port), and a related-items section listing typed relationships (depends on/used by, member of).
• The Dependency View renders the whole topology as an interactive map with layouts (vertical, horizontal, radial, force, groups) and filters (dependency depth, CI type, manufacturer).
• The ITSM bridge: an incident's impacted service (SAP Enterprise Service) opens a dependency map showing five related incidents and a linked problem record — a strong root-cause signal connecting CMDB to incident and problem management.

Detailed Notes CMDB Table Walkthrough

• Navigate via cmdb_ci.list; columns include name, manufacturer, location, description, class, updated, maintenance schedule.
• Grouping by class shows the logical organization of infrastructure in the instance.
• Drilling into an IP router CI: identification fields at top; configuration details (device type, IP address, location, port, channel, firmware manufacturer) below; related items at bottom with depends-on/used-by and member-of relationships.

Dependency View

• Visualizes topology as a map instead of relationship lines; layout options adapt the view to the analysis goal.

ITSM Integration

• Opening an incident shows affected CIs and impacted services; the impacted service is SAP Enterprise Service.
• From the incident's dependency map, details reveal five incidents reported against the CI — the incident manager sees isolated vs. systemic issues; the problem manager sees a root-cause signal.
• A linked problem record shows the team already investigating the recurring issue; filters narrow the view by dependency level, CI type, or manufacturer.
• Real-world pattern: see the CI, see dependencies, link to incidents and problems, drive faster resolutions — used in banking, telecom, healthcare, manufacturing.

Action Items

• Practice navigating with <table_name>.list shortcuts to reach CMDB records quickly.
• Use the dependency view's filters to build reusable views per service for impact analysis.
• Configure a monitoring pattern: repeated incidents on one CI should auto-flag for problem management.

Key Terms/Concepts

• Dependency View: interactive topology map of a CI's relationships with multiple layouts and filters.
• .list shortcut: navigator syntax (table_name.list) jumping straight to a table's list view.
• Impacted service: business service degraded as a downstream consequence of an incident.

---

Chapter 2 — 01. CMDB data model and CI class structure

Core Insights

• The CI class hierarchy is the blueprint of the CMDB: every configuration item inherits from a single base table, cmdb_ci.
• Inheritance makes the data model scalable — base attributes (name, short description, operational status, discovery source) apply to all CIs, while specialized child classes add type-specific attributes (CPU/RAM for servers, database-specific fields for databases).
• There is no single "correct" CI scope; organizations must decide which CI types to track based on needs and governance strategy.
• ServiceNow allows extending the hierarchy with custom CI classes, but flexibility demands governance or the CMDB becomes messy and inconsistent.
• Design CI classes with consistency, completeness, and scalability in mind; getting the structure right first prevents months of data cleanup later.

Detailed Notes The Inheritance Model

• cmdb_ci is the parent/base table; every CI record traces back to it. First-level specializations include database, server, application, and computer categories.
• Child tables inherit all parent fields and add their own specialized attributes — same structure, different detail per class.
• Example path in ServiceNow: Server → Computer → cmdb_ci.

CI Planning (part of ITIL configuration management)

• Before creating CIs, define: which infrastructure types to track, which attributes matter per type, and who owns maintenance of each type.
• Scope decisions vary: some orgs track every device (printers, switches, UPS), others stay business-centric (servers, databases, applications).

Governance Principles

• Consistency: a server CI should look like every other server — same attributes, naming, relationships.
• Completeness: capture what you need to know (e.g., tracking servers without OS is a critical gap).
• Scalability: the structure must accommodate new infrastructure types without breaking.

Action Items

• Document a CI class plan before building: list tracked types, mandatory attributes, and data owners.
• Enforce naming conventions and standard attributes per CI class across all creating teams.
• Review the out-of-box class hierarchy and only create custom classes where a genuine gap exists.

Key Terms/Concepts

• CI class structure: The inheritance hierarchy of tables defining what attributes and behavior each configuration item type has.
• cmdb_ci (Configuration Item base table): The root table all CI records inherit from, holding universal attributes.
• Inheritance: Child tables automatically receive all parent fields and add type-specific fields.
• CI planning: The ITIL-aligned activity of deciding what infrastructure to track and how.

Chapter 2 — 02. Demo Exploring CI class structure in ServiceNow

Core Insights

• The CMDB is not one table — it is an ecosystem of thousands of tables, each storing a specific type of configuration data.
• All CI tables inherit from the single root base table cmdb_ci; this was demonstrated live on a ServiceNow personal developer instance.
• Grouping tables by their "extends table" column reveals the parent–child hierarchy behind the scenes.
• Structural changes made at the base table level propagate automatically to every CI class in the CMDB.

Detailed Notes Navigating the Table Landscape

• Filter Navigator → Tables; the demo instance contained 6,207 total tables, each like a spreadsheet with defined columns and rules (incidents, users, changes, CMDB each live in separate tables).
• Filtering labels by "CMDB" surfaced 5,000+ CMDB-related tables — evidence the CMDB is a family of tables.
• Filtering names by cmdb_ci narrowed to 596 tables, all specialized children of the same base CI table: servers, databases, applications, and more.

Viewing the Hierarchy

• Grouping by the extends table column produced 73 parent–child groups.
• Expanding "Configuration Item" showed only one table extends directly from it: cmdb_ci itself — the root of the entire hierarchy.
• Every server, database, and application table ultimately traces back to this one base table.

Action Items

• In your own instance, use the Tables list filtered by cmdb_ci to inventory existing CI classes before creating new ones.
• Use the "group by extends table" view to map your CMDB hierarchy and spot duplicate or orphaned classes.
• Audit base-table field changes carefully since they cascade to every child class.

Key Terms/Concepts

• Staging/extends relation: A table's parent in the inheritance hierarchy, shown as the extends table column.
• PDI (Personal Developer Instance): A free personal ServiceNow instance used for learning/demos.
• Table: The storage structure in ServiceNow; all data lives in tables.

Chapter 2 — 03. Creating and managing CIs

Core Insights

• Two creation paths exist: manual form entry and automated discovery; imports via import sets/transform maps handle bulk population.
• Manual creation is precise but does not scale — for hundreds of CIs it is unrealistic, error-prone, and stale the moment it is done.
• Discovery tools scan infrastructure and populate the CMDB automatically, but still require governance around approvals, validation, and ownership.
• Import sets stage raw data into a temporary table; transform maps define column-by-column mappings into the target CMDB table.
• Quality over perfection: an 80%-complete, actively used CMDB beats a perfect one that was never started.

Detailed Notes Manual Creation

• Fill a form: basics (name, description, type), then type-specific details (OS, CPU, RAM, manufacturer, owner, location, support group).
• Which attributes are mandatory vs. optional must be defined in governance policy (e.g., name + OS + owner minimum).

Automated Discovery

• Agents/scanners find components: Windows discovery agents for servers, SNMP for network devices, dedicated processes for databases and applications.
• Discovery can auto-create CIs and relationships — but who approves and validates new CIs are governance questions.

Import Sets & Transform Maps

• Import set = staging table where raw data lands; transform map = rule mapping source columns to target fields (e.g., spreadsheet server name column → CI name field).
• Powerful for initial population from a source of truth (inventory system, spreadsheet); quality is still garbage-in, garbage-out.

CI Attributes & Best Practices

• Core attributes: name (unique, follow naming conventions), type (class), owner (accountability), status (lifecycle: in use/in development/retired), location (physical/cloud region).
• Operational attributes: CPU, RAM, OS, version, component-specific configuration.
• Populate attributes that drive incident/change decision-making rather than collecting everything.

Action Items

• Define mandatory vs. recommended attributes per CI type in a written governance policy.
• Start small: load critical servers and key applications, define relationships, and use the CMDB in incident/change workflows.
• Establish an iteration loop to identify and close data gaps as the CMDB is used.

Key Terms/Concepts

• Import set: A staging table holding raw imported data before transformation into the CMDB.
• Transform map: Defines how source columns map to target CMDB fields during import.
• Discovery: Automated agents that scan infrastructure and populate CI data.
• Lifecycle status: A CI's state (in use, in development, retired) tracked for governance.

Chapter 2 — 04. Demo Creating a CI

Core Insights

• A CI is created from a blank, class-specific form — the demo created a server CI manually on a PDI.
• Key identification fields: name (unique identifier), company, asset tag, and serial number.
• The assignee/owner field is among the most important — no owner means no accountability for keeping the CI accurate.
• Server-specific fields (OS, RAM) only exist on the server table, demonstrating inheritance in action.
• The manual workflow is identical across all CI types: fill identification, set owner, add type-specific attributes, save, verify.

Detailed Notes Demo Walkthrough

• Filter Navigator → "configuration" → Servers → All (41 existing server CIs) → New to open a blank server form.
• Filled: name serve prod 01, company Acme (business unit owner), asset tag SV41, serial number 123456789.
• Assigned to a user (Antony) — the owner accountable for record accuracy.
• Server-only attributes: OS (Hyper-V) and RAM; real implementations would add CPU count, disk space, IP address.
• Submitted, then verified the CI appeared in the server list.

Verification

• Added the "Updated" column via the gear icon to spot the newest record; sorting by that column put serve prod 01 at the top.
• The record is stored in the cmdb_ci_server table.

Action Items

• Standardize which identification fields are mandatory for each CI class before enabling creation.
• Always assign an owner/assignee on every CI record.
• Use the Updated column sort to routinely spot stale CMDB records.

Key Terms/Concepts

• Asset tag: An organization's internal asset tracking number for the CI.
• Serial number: The manufacturer's unique hardware identifier.
• Assignee: The person accountable for the CI's data accuracy.

Chapter 2 — 05. Defining and visualizing CI relationships

Core Insights

• A CI in isolation is just a record; relationships give the CMDB its power, connecting CIs so the data becomes intelligent.
• Relationship types carry meaning: Runs on, Connects to, Part of, Depends on, Backed up by, Managed by — each affects impact analysis differently.
• Relationships can come from discovery (auto-created), manual definition, bulk import via transform maps, or be added organically during incident/change work.
• Visualizing relationships (dependency maps) enables instant impact analysis: if a database goes down, which applications break?
• Start with high-value, critical relationships for your most important services and expand iteratively — don't map everything on day one.

Detailed Notes Common Relationship Types

• Runs on: application/service runs on one or more servers.
• Connects to: server connects to a database; application talks to an API.
• Part of / Grouped in: server part of a cluster; database part of an instance group.
• Depends on: a service depends on a supporting application/shared library.
• Backed up by: a system protected by a backup solution.
• Managed by: an infrastructure component managed by a systems team.

Defining Relationships at Scale

• Small environments: click-through manual definition is feasible.
• Large environments: discovery finds installed applications and auto-defines run-on relationships; spreadsheets/CMDB tools can be imported in bulk; users add relationships as they discover them.

Visualization & Impact Analysis

• Dependency maps show the full chain: applications → servers → databases → backup systems.
• Answering "what breaks if X fails?" becomes a glance at the map — operational intelligence for change decisions and incident response.

Action Items

• Identify and model the critical dependency chains for your top business services first.
• Test impact analysis on the mapped relationships before expanding coverage.
• Prefer discovery-generated relationships for installed-software dependencies; reserve manual effort for what discovery cannot model.

Key Terms/Concepts

• Impact analysis: Determining downstream effects when a CI fails or changes.
• Dependency map: A visual graph of CIs and their directional relationships.
• Relationship type: A labeled, directional connection (runs on, depends on, etc.) between CIs.

Chapter 2 — 06. Demo Creating and visualizing relationships

Core Insights

• The related-items section on any CI record lists all relationships, each with direction and meaning (depends on, used by, exchanges data with).
• L1/L2/L3 labels indicate dependency depth: L1 is directly connected, L2 one hop away, L3 two hops away — the foundation of impact analysis.
• A freshly created CI sits in isolation; relationships are what bring the CMDB to life.
• The relationship editor lets you pick relationship types and connect a CI to other CIs; results appear immediately in the dependency map.

Detailed Notes Demo Walkthrough

• Opened the master view (cmdb_ci.list), grouped by class, and opened an AIX server record (SAP App SRO 2).
• Related items showed: web servers "Depend on / used by" the server; storage/database as parents the server depends on; "Exchanges data with" both child Windows servers and parent mass-storage devices.
• Explained L1 (direct neighbors, hit immediately on failure), L2 (one hop), L3 (two hops) — at risk depending on the chain.
• Opened the dependency map showing the server centered with arrows to its dependencies and dependents.

Creating Relationships

• Plus icon opens the relationship editor: suggested types across the top (connects to, depends on, used by, child/parent), filters, and a CI picker below.
• Selected "depends on / used by" and added three CIs (Thinkpad T20, MacBook Pro 15, DP00315), then "receive data from" and "connects to / child" with more CIs; saved.
• The dependency map and related-items list both updated to show all new relationships.

Action Items

• Review the related-items section and dependency map on your most critical CIs as a first impact-analysis exercise.
• Use L1/L2/L3 depth to prioritize which connections to keep accurate first.
• Use the relationship editor's type suggestions rather than free-typing to keep relationship vocabulary consistent.

Key Terms/Concepts

• Related items: The section of a CI record listing all its relationships.
• L1/L2/L3 dependency depth: Distance of a connected CI from the CI of interest (direct, one hop, two hops).
• Relationship editor: UI for adding and typing relationships between CIs.

Chapter 2 — 07. Methods of populating the CMDB

Core Insights

• Four approaches exist: manual creation, automated discovery, import sets/transform maps, and the hybrid approach — which most mature organizations actually use.
• Manual gives complete control but is time-intensive, error-prone, non-scalable. Discovery automates at scale and builds relationships, but only covers discoverable infrastructure and needs configuration.
• Import sets bulk-load fast from external sources but depend on source-data quality and require transform-rule definition.
• Data quality is decisive: garbage in, garbage out. Validate sources, map to standards, assign ownership, and enforce mandatory attributes.
• A realistic phased rollout: discovery first, manual for gaps, import the application portfolio, define relationships, then iterate with real usage.

Detailed Notes Method Comparison

• Manual: use for specialized items that don't fit discovery patterns, small initial setups, or CI types needing specific manual entry.
• Discovery: Windows agents, SNMP scanners for network devices, database discovery — finds what is actually running and auto-creates relationships; data quality depends on the process.
• Import sets/transform maps: export from spreadsheet, competing CMDB, or inventory tool → stage → transform → bulk load; ideal for initial population and legacy migration.
• Hybrid: discovery for servers/network, manual for specialized components, import sets for application data from an APM/portfolio tool.

Data Quality Best Practices

• Validate source data before import or discovery.
• Enforce naming conventions, standard attributes, and consistent status values (no "server 123" vs "production server UK01").
• Assign ownership so someone is accountable for stale records.
• Define mandatory attributes per CI type; don't leave every field optional.

Realistic Scenario (mid-sized org)

• Phase 1: discovery finds ~150 Windows servers and network devices.
• Phase 2: manually add ~50 servers without agents (Unix, legacy, out-of-band devices).
• Phase 3: bulk import 300+ applications from the APM/portfolio tool.
• Phase 4: define server–application relationships (part automated, part manual).
• Phase 5: iterate — use the CMDB, find gaps, fix them.

Action Items

• Choose a population method per CI category rather than one method for everything.
• Write naming and status-value standards before the first import or discovery run.
• Build a phased rollout plan with explicit governance checkpoints (approval, validation, ownership).

Key Terms/Concepts

• SNMP scanner: Discovery mechanism for network devices.
• APM (Application Portfolio Management): A tool holding application inventory, often a source for imports.
• Hybrid approach: Combining manual, discovery, and import methods based on situation.

Chapter 2 — 08. Demo Import sets and discovery

Core Insights

• The import flow is: create a staging table → load raw data → build a transform map → run the transform → verify CIs landed in the target table.
• Import sets can be new per import or reused for recurring imports of the same structure; sources can be files (CSV/Excel) or configured data sources (FTP, JDBC, REST).
• A transform map is the bridge that tells ServiceNow which source column goes to which target field — without it, the staged data has no destination.
• Auto-mapping works only for exactly matching column names; mapping assist gives a controlled visual editor for manual mapping.
• Completion code "success", a complete import-set run state, and target-record links verify the transform cleanly.

Detailed Notes Demo Walkthrough

• Prepared a sample CSV of 10 laptop records (name, asset tag, manufacturer, serial, OS, location, department, owner, CPU count, RAM, hard disk, IP, MAC, operational status).
• System Import Sets → Load Data → created a new staging table (label: computer import CMDB test), uploaded the CSV.
• The import-set state showed "loaded" — data staged but not yet in the CMDB; all 10 rows visible under the import set rows tab.
• Created a transform map: source = staging table, target = cmdb_ci_computer; used mapping assist to map nine fields (asset tag, CPU count, department, IP, MAC, manufacturer, etc.).
• Ran the transform: completion code success; all 10 records got target-record links; the import-set run state was "complete".

Verification

• Opened cmdb_ci_computer.list and confirmed all 10 CIs present.
• Added asset tag, CPU count, MAC, IP, model, and RAM columns to verify imported values match the spreadsheet exactly.

Action Items

• Reuse an existing staging table for recurring imports of identical structure to keep the process streamlined.
• Prefer mapping assist when source column names deviate from target field names.
• Always verify imported CIs by checking target-record links and spot-checking a few attribute values.

Key Terms/Concepts

• Staging table: Temporary holding area for raw import data before transformation.
• Transform map: Defines source-to-target field mappings between staging and CMDB tables.
• Mapping assist: Visual editor for manually mapping source fields to target fields.
• Import set run: A record of a completed transformation run with its state.

---

Chapter 3 — 1. CMDB data quality and integrity

Core Insights

• Building a CMDB is easy; keeping it reliable over time is the hard part — a CMDB decays like an untended garden unless continuously maintained.
• Data quality and integrity are the foundation of trust: impact analysis, incident response, and change approvals are only as good as the CMDB data behind them.
• Data quality has four dimensions: completeness, accuracy, consistency, and currency.
• Maintaining quality is an organizational problem, not a technical one — ownership, governance, audits, process integration, and education.
• Without attention the CMDB drifts into entropy: records go stale, relationships age, and nobody notices until a bad decision is made.

Detailed Notes What Defines a Healthy CMDB

• A healthy CMDB is one where you can trust the data for decisions — approving changes via impact analysis, incident responders tracing relationships.

The Four Dimensions of Data Quality

• Completeness: essential attributes populated (e.g., every server has an owner); not every field, just what decisions require.
• Accuracy: data matches reality (e.g., actual OS version vs. recorded version) — small errors compound in compliance and support-lifecycle decisions.
• Consistency: standardized naming and formatting ("Prod App Server 1" vs. "Production App Server 2" breaks search and reporting).
• Currency: records reflect the current state, not a historical record — decommissioned servers and upgraded apps must be updated.

Operational Consequences of Bad Data

• Incident management may miss affected systems and resolve without addressing root cause.
• Change management may approve risky changes when the CMDB understates what a CI supports.
• Configuration management cannot enforce standards against an untrusted source of truth.

How to Maintain Data Quality

• Every CI needs a named owner or it will decay; define and enforce standards (attributes, naming, statuses); schedule audits comparing the CMDB to reality; integrate CMDB updates into provisioning/decommissioning/deployment processes; educate users with real examples of bad decisions caused by bad data.

Action Items

• Assign an owner to every CI and make the list of ownerless records a tracked metric.
• Define mandatory attributes per CI type, a naming convention, and valid status values; write them down and publish them.
• Schedule recurring audits (compare CMDB entries against live infrastructure) and hold teams accountable for discrepancies.
• Wire CMDB updates into standard operating processes so they happen automatically, not as an afterthought.
• Run a training session showing real cases where stale or missing CMDB data caused a costly or risky decision.

Key Terms/Concepts

• Completeness: degree to which essential, decision-driving attributes are populated on CI records.
• Accuracy: how closely recorded CI data matches the real-world component.
• Consistency: uniformity of naming, formatting, and status values across records.
• Currency: how current records are relative to the actual infrastructure state.
• Entropy (CMDB decay): the natural drift of CMDB data toward staleness and error when no one actively maintains it.

Chapter 3 — 2. Using CMDB health dashboards

Core Insights

• Health dashboards turn vague "is our CMDB good?" into quantifiable scores that show where problems live.
• Trending over time is the real power: visibility into improvement or decay tells you whether governance efforts are working.
• The ServiceNow dashboard computes KPIs from your governance rules — completeness, accuracy, and compliance are only meaningful relative to standards you define.
• Measure what matters to your organization: align metrics with incident management, change, or other priorities instead of tracking everything.
• Metrics drive behavior — tracking something makes people improve it, and declining scores force accountability.

Detailed Notes Dashboard KPIs

• Completeness score: percentage of CIs with mandatory attributes populated, calculated from governance rules; 95% is good, 60% signals work to do.
• Accuracy metrics: automatically detectable issues like CIs with no relationships or orphaned records.
• Compliance: CIs meeting governance standards, e.g., production servers must link a backup solution.

The Power of Trending

• Scores tracked over months show improvement or degradation; a dropping score means governance is not preventing decay; an initiative that lifts the curve proves measurement drives results.

Customizing What You Measure

• Tailor metrics to priorities: % of CIs with SLA info, missing relationships, % of applications with documented dependencies, data freshness vs. reality.
• If incident management is the priority, measure data incident managers rely on; if change is critical, measure the data change managers need.

Key Metrics Worth Tracking

• Discovery coverage: % discovered automatically vs. manually created — more discovery catches new infrastructure automatically.
• Relationship density: average relationships per CI — near-zero suggests missing definitions, dozens suggests over-granularity.
• Freshness/verification age: when each CI was last verified; unverified for 6+ months is stale.
• Ownership coverage: % of CIs with assigned owners — ownerless CIs decay.
• Showing completeness climbing from 65% to 78% demonstrates progress and creates accountability.

Practical Approach

• Don't fix everything at once: pick the high-value CI type first (e.g., servers, databases), drive it past 90% completeness, then iterate.

Action Items

• Configure the health dashboard and note the baseline overall score and per-KPI values before any cleanup.
• Define mandatory and recommended attributes per CI type so completeness scores are meaningful.
• Set up a monthly trend review of the three KPIs; investigate any month-over-month decline immediately.
• Choose 3-5 custom metrics aligned to your biggest operational pain (incident, change, or compliance) and track only those first.
• Prioritize one high-value CI class (e.g., servers) and target 90%+ completeness before expanding scope.

Key Terms/Concepts

• CMDB Health Dashboard: ServiceNow tool showing overall CMDB health scores and surfacing where problems are.
• Completeness Score: % of CIs meeting mandatory-attribute governance rules.
• Compliance KPI: % of CIs satisfying governance audit rules (e.g., backup linked, owner assigned).
• Discovery coverage: share of infrastructure captured automatically by discovery vs. entered manually.
• Relationship density: average number of relationships per CI, used to spot missing or over-granular relationship definitions.
• Freshness: how recently each CI was verified accurate, tracked via timestamps.

Chapter 3 — 3. Common CMDB data issues and remediation

Core Insights

• The five classic CMDB problems are duplicates, orphans, wrong relationships, missing attributes, and stale data — each with a distinct remediation path.
• Prevention beats remediation: enforce naming standards, run duplicate detection regularly, and validate data at entry.
• Prioritize fixes by impact × effort: high-impact/low-effort quick wins first; skip low-impact/high-effort items.
• Many fixes (relationships, attributes, freshness) require subject-matter-expert validation — remediation is a people process, not just a technical one.
• Remediation is never a one-time project; a five-phase loop of identify → triage → fix → measure → govern keeps issues from undermining trust.

Detailed Notes Issue 1: Duplicate CIs

• Same physical component recorded multiple times (e.g., "ProdDB01" vs. "proddb01"); duplicates confuse relationships, skew metrics, and link incidents to the wrong CI.
• Remediation: merge using ServiceNow's merge tool — pick the master record, merge the rest, relationships update automatically.
• Prevention: strict naming conventions plus regular duplicate detection.

Issue 2: Orphan CIs

• CIs with no relationships — unused apps, disconnected servers, isolated databases; either the CI is obsolete and not retired, or relationships are missing.
• Remediation: investigate; then delete it, mark it retired, or add the missing relationships.

Issue 3: Wrong/Outdated Relationships

• E.g., Server A no longer uses database B; an app was migrated away a month ago.
• Remediation: harder — requires system owners to validate whether the relationship still exists before deleting/updating.

Issue 4: Missing Attributes

• No OS specified, no version, no owner.
• Remediation depends on the attribute: query external systems where possible, otherwise survey system owners with a pre-filled list, specific asks, and a deadline.

Issue 5: Stale Data

• Records unverified for months or years (app at v1.5 but actually v3.0).
• Remediation: periodic (e.g., quarterly) verification campaigns — send owners lists to confirm or update, creating accountability and freshness.

Issue 6: Inconsistent Data

• Naming conventions broken, status values inconsistent, relationships modeled differently.
• Remediation: enforce standards with dropdowns instead of free text and ServiceNow rules that validate data as entered — make deviation hard.

Prioritization Framework and Phased Approach

• High impact + high effort: schedule dedicated effort. High impact + low effort (quick wins, e.g., merging 50 duplicates): do first.
• Low impact + low effort: nice-to-have. Low impact + high effort: skip.
• Phases: 1) identify via dashboard/reports, 2) triage by impact/effort, 3) fix high-impact first, 4) measure progress, 5) govern to prevent regression.

Action Items

• Run duplicate detection (naming and owner-based) and merge the top duplicates as an afternoon quick win.
• Produce an orphaned-CI report and triage each record into delete / mark retired / add missing relationships.
• Launch a quarterly verification campaign: email system owners a list of their CIs with a deadline to confirm or correct.
• Replace free-text fields with dropdowns and add validation rules so bad data cannot be entered.
• Build the five-phase remediation loop into a recurring review (e.g., monthly triage, quarterly verification).

Key Terms/Concepts

• Orphan CI: CI record with no relationships, indicating isolation or obsolescence.
• Master record: the canonical CI record kept when merging duplicates.
• System owner: the person/team responsible for a component, used to validate relationships and attributes.
• Verification campaign: periodic exercise where owners confirm or update CI data to keep it fresh.
• Impact × effort matrix: prioritization grid — high-impact/low-effort quick wins first, low-impact/high-effort skipped.

Chapter 3 — 4. CMDB governance and best practices

Core Insights

• Governance is what prevents decay in the first place — policies, processes, and responsibilities that keep the CMDB healthy over time.
• Ownership must exist at two levels: a configuration management team owns the CMDB overall, and each CI has a system/application team owning its accuracy.
• Don't rely on voluntary compliance — enforce standards inside ServiceNow with mandatory fields, dropdowns, business rules, and compliance dashboards.
• Governance evolves along a maturity curve from ad-hoc to optimized; most organizations should target Level 3 (Managed), which delivers reliability without constant firefighting.
• Start simple, iterate: define CI types, mandatory attributes, and naming conventions, enforce them, track metrics, then refine annually.

Detailed Notes Key Elements of Governance

• Clear ownership structure: a configuration management role/team sets standards and drives improvement; individual CIs have named owners.
• Standards: document CI types tracked, mandatory attributes per type, naming conventions, and valid status values; distribute to everyone creating or updating CIs.
• Enforcement mechanisms: mandatory fields so critical attributes can't be blank, dropdowns for status, business rules validating relationships, dashboards tracking compliance — make the wrong thing hard and the right thing easy.
• Process integration: provisioning auto-creates CIs (via discovery or workflow), decommissioning marks retired, deployments update versions — CMDB updates are part of operational processes, not an afterthought.
• Ownership and accountability: use a RACI matrix for CMDB decisions; make clear that keeping CIs updated is part of each owner's job, with consequences when health metrics decline.
• Regular audits: periodically (e.g., quarterly) sample CIs and verify existence, location, and ownership against reality; use findings to fix systematic problems.
• Training and communication: people can't follow standards they don't know — train teams, share real examples of failures caused by bad data.
• Continuous improvement: governance is not static — add CI types for new technologies, refine attribute definitions, review the whole framework annually.

Governance Maturity Model

• Level 1 (Ad-hoc): CMDB exists, no clear governance, poor data quality, sporadic updates.
• Level 2 (Defined): basic standards defined, some enforcement, quality improving but gaps remain.
• Level 3 (Managed): governance documented and enforced, ownership clear, health metrics tracked, data quality good — the realistic target for most organizations.
• Level 4 (Optimized): governance fully integrated with processes, continuous improvement, consistently high quality.

Action Items

• Publish a CMDB standard document covering CI types, mandatory attributes, naming convention, and valid statuses.
• Turn on mandatory fields, dropdowns, and business rules in ServiceNow so standards are enforced at entry.
• Draft a RACI matrix for the CMDB (responsible/accountable/consulted/informed) and communicate consequences for declining health metrics.
• Run a quarterly sample audit of CIs against reality and use findings to drive systematic fixes.
• Schedule an annual governance review asking: is it working, what are the pain points, what should change; then iterate.

Key Terms/Concepts

• CMDB governance: the policies, processes, and responsibilities that keep the CMDB healthy over time.
• Enforcement mechanism: technical controls (mandatory fields, dropdowns, business rules) that make deviations from standards hard.
• RACI matrix: responsibility assignment grid — Responsible, Accountable, Consulted, Informed — applied to CMDB decisions.
• Governance maturity model: 4-level progression (Ad-hoc → Defined → Managed → Optimized) describing how mature CMDB governance is.

Chapter 3 — 5. Demo: CMDB health dashboards and metrics

Core Insights

• The ServiceNow CMDB Health dashboard is found via the Application Navigator under "CMDB" — either through the CMDB workspace or directly to the Health dashboard.
• Three views exist: Class (by CI type), Services (by business service), and Health group (by custom groupings like environment or owning team).
• The overall score is a weighted average of the three KPIs — Completeness, Correctness, and Compliance — a headline metric for status reports.
• Each KPI drills down to concrete problem lists: missing mandatory/recommended attributes, duplicate/orphan/stale CIs, and governance audit failures.
• KPIs may show "this KPI has not run" until the scheduled calculation jobs execute — an empty dashboard usually means disabled jobs, not a healthy CMDB.

Detailed Notes Navigation

• From the Application Navigator, filter by "CMDB"; either open the CMDB workspace or jump straight to the CMDB Health dashboard.

Dashboard Views

• Class: health grouped by CI type (server, database, applications...).
• Services: health from the perspective of delivered business services.
• Health group: health by custom groupings, e.g., all production CIs or CIs owned by a particular team.
• The Configuration Item filter on the Class view shows visibility across all CI types.

Scores and KPIs

• Overall score: single number, a weighted average of the three KPIs below it; higher is better, moves with data quality.
• Completeness: required and recommended attributes populated — drills down to Missing required attributes (most serious) and Missing recommended attributes.
• Correctness: accuracy, free of duplicates, orphans, and stale records — three classic integrity problems.
• Compliance: CIs failing governance audit rules, e.g., "every production server must have an owner assigned".
• Completeness drops when new CIs arrive incomplete; scores improve when teams populate missing data.

Reading the State

• All KPIs showing "this KPI has not run" means the scheduled score-calculation jobs have not executed yet in the instance — the next demo shows how to activate and run them.

Action Items

• In a ServiceNow instance, navigate to the CMDB Health dashboard and note which view (Class/Services/Health group) suits your reporting audience.
• Record the overall score and each KPI value as a baseline; identify which CI class drags the score down.
• Check whether any KPI shows "has not run" — if so, verify the calculation schedule jobs are active before trusting the dashboard.
• Set up the Class view with the Configuration Item filter to get cross-CI-type visibility in status reports.

Key Terms/Concepts

• Overall score: weighted average of Completeness, Correctness, and Compliance KPIs summarizing CMDB health.
• Correctness: KPI measuring data accuracy — surfaced through duplicate, orphan, and stale CI lists.
• Audit section: compliance list of CIs failing governance rules (e.g., missing required ownership).
• KPI has not run: dashboard state indicating the scheduled jobs that compute scores have not executed.

Chapter 3 — 6. Demo: CMDB health review and correction

Core Insights

• Health dashboard KPIs are not computed in real time — scheduled jobs, typically every few hours, calculate and store scores, and the dashboard displays stored results.
• Out-of-the-box, 5 of the 6 CMDB Health schedule jobs are inactive; an empty dashboard is usually "the engine isn't switched on," not a healthy CMDB.
• After activating all jobs and triggering them manually, the instance showed an overall score of 63% — with 295 duplicate computers flagged by Discovery and by Owner.
• Duplicate detection works through two signals: Discovery can't uniquely identify the CI (missing serial/asset tag) and shared owner-defined identifiers.
• Filtering the dashboard to a specific CI class (application servers) recalculates every KPI for that scope (67% overall) — the dashboard localizes where problems live.

Detailed Notes Score Calculation Architecture

• Recalculating across thousands of CIs per dashboard open would be too expensive; ServiceNow runs scheduled jobs (typically every 3 hours) that store results the dashboard renders.

Activating the Jobs

• Filter Navigator → System Definition → Scheduled Jobs; filter the long list by "name contains health" to find the 6 CMDB Health jobs.
• 5 of the 6 showed active=false — disabled jobs never run despite configured schedules; select all 5 and set active=true.
• To populate the dashboard without waiting up to 3 hours, open each job (e.g., Completeness Score Calculation) and click Execute now.
• A 3-hour schedule is a sensible production default: current enough without straining the platform.

Interpreting the Results

• Overall score 63%; Completeness at 100% — every CI in scope has mandatory and recommended fields filled per current rules.
• Correctness: 295 duplicate computers flagged — non-compliant by Discovery (couldn't uniquely identify, often missing serial numbers/asset tags) and non-compliant by Owner (shared owner-defined identifier); printers flagged similarly.
• Orphaned CIs: empty (no isolated records). Stale CIs: service CIs plus 14 Windows cluster nodes not updated recently.
• Compliance audit: 34 service CIs and 13 databases fail governance rules (e.g., missing required ownership or invalid status).

Scope Filtering

• Searching "server" and selecting Application Servers recalculates the overall score to 67% with every KPI re-scoped to that class — the dashboard reveals not just overall health but where the problems live.

Action Items

• In any ServiceNow instance, verify all six CMDB Health schedule jobs are active before trusting the dashboard.
• After enabling jobs, trigger each one manually with "Execute now" to populate KPIs without waiting for the schedule.
• Review Correctness lists for the two duplicate signals (Discovery-identified and owner-identified) and plan merges.
• Use the Compliance audit section to drive fixes for failing CIs (e.g., missing ownership, invalid status).
• Compare per-class scores against the overall score to locate the CI types with the worst health.

Key Terms/Concepts

• Scheduled job: platform job that periodically computes and stores dashboard KPI scores (default ~3 hours).
• Non-compliant by Discovery: duplicate flag when Discovery cannot uniquely identify CIs, typically missing serial numbers or asset tags.
• Non-compliant by Owner: duplicate flag when records share the same owner-defined identifier.
• Execute now: manual trigger that runs a scheduled job immediately (used to populate dashboards without waiting).
• Stale CI: record not updated or verified recently (e.g., Windows cluster nodes flagged in the demo).