Relationship Modeling and Service Mapping
Relationships carry the meaning
A CMDB without relationships is a list. Relationships are typed, directional links (for example depends on, runs on, hosts, connects to) that let you trace impact from a failing component up to affected services. Candidates must understand that relationship type and direction matter: reversing a dependency inverts the impact analysis.
Concepts to name
- Dependency mapping: which CI relies on which, and in what direction.
- Service mapping: automated or guided discovery that builds service-level dependency maps from traffic and configuration evidence.
- Top-down versus bottom-up: starting from the business service and decomposing, versus aggregating discovered components upward.
- Impact analysis: traversing relationships to find affected services and users.
- Relationship hygiene: avoiding duplicate or contradictory links and orphaned CIs.
Traps
Common question traps: assuming all relationships are bidirectional (most are directional); confusing containment with dependency; and believing service mapping is purely manual. Automated mapping accelerates coverage but requires validation, and it only maps what it can observe.
Worked example
A database host fails. Traversal finds the database CI, the application service that runs on it, the technical service supporting it, and the business service depending on that - plus the service instance consumed by finance. The impact statement lists affected business services and user groups, not just the failed server.
Rule of thumb
Model relationships only where they change a decision. If a link never appears in an impact or reporting path, it is noise.