IT service management
A lightweight CMDB that shows what depends on what
Map configuration items and their relationships so you can see what depends on what — a lightweight CMDB that ties assets, services and incidents together.
What kinds of relationships can we model?
Seven typed, directional relationships: depends_on, runs_on, hosts, connected_to, part_of, uses and backup_of. Direction matters — each edge points from a source CI to a target CI.
Already live in the product
Running in production today: configuration items and their relationships, tracked in the ITSM suite.
Built around real workflows
Highlights below describe capabilities already present in the protected app behind this page.
- Configuration items
- Dependency relationships
- Linked to assets and incidents
- Impact context for changes
What teams can do here
- Step 1Register configuration items
- Step 2Map relationships
- Step 3See impact before a change
- Step 4Investigate incidents faster
How it works
- 01
Treat assets as configuration items
Your existing IT assets act as configuration items (CIs). You can also keep component/CI-type masters — for example Hardware, Software or Network categories — as reusable reference data.
- 02
Map directional relationships
Record how CIs relate with typed, directional edges: depends_on, runs_on, hosts, connected_to, part_of, uses and backup_of. A relationship reads source → (type) → target, e.g. "App server → runs_on → VM" or "Service → depends_on → Database".
- 03
Run impact analysis
Ask "what breaks if this CI goes down?" The impact analysis walks the dependency edges upstream — depends_on, runs_on, uses, part_of, connected_to — up to a bounded depth and returns every affected CI, with the path it followed.
- 04
Visualise the graph
A graph endpoint returns the full set of CI nodes and edges so the relationships can be rendered as a dependency map rather than read as a list.
A worked example
Say a payments company with roughly 200 tracked CIs is about to patch its primary database. The change owner runs impact analysis on the database CI first. Because the billing service is mapped "depends_on" that database, and the customer portal is mapped "depends_on" the billing service, the walk returns both — surfacing that a "routine" restart would take the portal down two hops away, something no single relationship row showed. The patch is moved to a Sunday maintenance window, the two downstream service owners are told in advance, and the change record links the same CIs for the post-change review.
Frequently asked questions
See also: Change management · Asset management · Blog: IT asset management tools · Blog: The IT asset lifecycle · Incident management
Book demo
Know what breaks before you restart it
Map assets into typed dependency relationships and run impact analysis up the chain — so a two-hop outage is discovered in planning, on the graph, not in production.
