Architecture and technical leadership
A CMDB that actually models relationships
I led the architecture and delivery of a relationship model that can answer what touches a configuration item several hops away.
- Role
- Architecture and delivery lead for a 5-engineer team
- Constraint
- Direct-only associations turned multi-hop questions into manual lookup chains
- Decision
- N-level traversal that preserves relationship type and direction, revealed one level at a time
- Result
- Released to production in 7 monthsMulti-hop relationship exploration shipped inside the ITSM product; documented publicly by EZO.
Sanitized artifact
A multi-hop question becomes one traversal.
Ownership and reflection
My part
I designed the n-level traversal model, wrote the design RFCs, built the new module's backend, and led delivery across the data model, relationship rules, and the interface built on top of them.
The team's part
Five engineers implemented and integrated the module across the wider ITSM product.
Hardest trade-off
Traversal depth is useful until the graph becomes unreadable. The model preserves type and direction while the interface reveals one useful level at a time.
What I'd do earlier
I would bring the ugliest real relationship paths into week one. Clean demo graphs do not expose where the model and the interface become hard to read.
01 · Constraint
What was breaking
Most CMDBs stop at direct associations. Answering which vendor contract covers the software on a particular server becomes a sequence of manual lookups instead of one navigable relationship.
02 · Decisions
How I approached it
I designed the data model for n-level traversal and led the ITSM-integrated interface built on top of it. Each configuration item expands to its next level while preserving relationship type and direction.
03 · Consequence
What changed
The module moved from architecture to production in seven months and put multi-hop relationship exploration into the product interface.