.webp)
01
The inventory cannot explain impact
Assets exist, but links between business services, applications and technical dependencies are missing or unreliable.
JSM Assets and CMDB implementation
A useful CMDB answers who owns a service, what it depends on and what an incident affects. Avaratak builds service-first Atlassian Assets models that teams can maintain and actually use.
Service-first asset and configuration management
A CMDB should answer a question, not become a collection.
A configuration database is useful when service owners can trace which applications and infrastructure support a business service, what a change affects, and who needs to respond to an incident. An inventory full of disconnected objects cannot do that.
Avaratak designs Atlassian Assets around business services, relationships, clear ownership and sustainable data practices. We work backward from decisions the operations team needs to make.
Recognizable signals
Where CMDB efforts usually stall
02
Ownership is unclear
Changes, outages and lifecycle events expose data nobody is responsible for keeping current.
03
The model is too difficult to maintain
Object schemas and attributes have expanded without a working update process, integration design or data-quality checks.
How we work
Build outward from the business service
The relationship model should help incident, change and request processes—not simply generate a prettier inventory.
01 Business service
02 Application service
03 Application
04 Infrastructure and vendor
01
Define useful operational questions
Identify service owners, priority services, impact paths, escalation needs, relevant change records and the reports decision-makers require.
02
Design Assets schemas and relationships
Model object types, attributes, ownership, references, lifecycle states and permissions. Keep the model as small as the use case allows.
03
Connect trusted data and workflows
Plan data imports or discovery sources, deduplication, synchronization and Jira Service Management fields or automation where the data improves action.
04
Test impact analysis and ownership over time
Walk real incidents and change scenarios, evaluate data completeness, establish review ownership and hand over maintenance and quality measures.
What you can hold us to
Tangible engagement deliverables
- Business service and dependency model
- Assets schemas, attributes and relationship design
- Ownership and role/permission model
- Import, integration and data-quality plan
- JSM use cases for incident, change and service requests
- Training and ongoing CMDB governance
You may not need a full CMDB.
If the real need is a lightweight equipment register, contract inventory or ownership lookup, Assets can support a narrower model. We recommend the least complex structure that answers the questions people actually ask.
Evidence and deeper reading
See a service-first example
Our published service-management case study covers an Assets CMDB designed around business services and used for incident response. The guide explains how to make schemas maintainable.
The questions that follow
Frequently asked questions
Is Assets only for IT hardware?
No. It can represent business services, applications, vendors, facilities, contracts and other connected objects. The right schema depends on the questions the team needs answered.
Can we start with our current spreadsheets or discovery data?
Often. The work is to define quality, identifiers, ownership, update rules and relationship mapping before importing large volumes of inconsistent records.
Will a CMDB make incident response faster automatically?
No. Useful relationships and owners can improve impact analysis, but workflows, escalation and training must actually use the data.
How do we stop data quality declining after launch?
Assign owners, define lifecycle/update triggers, review exceptions and measure the fields and relationships required for the intended decisions.
When it Matters, Bring in Avaratak
Start with the business service that matters most.
Bring one critical service, the questions you struggle to answer during incidents and the data sources you already have. We will discuss the smallest useful model and how to keep it accurate.
Map your first service