Asset and Configuration Management is an important part of many ITSM or ESM implementations. If you are a new Atlassian Customer, you may have the following questions:
Does Atlassian have a CMDB?
What is the Common Data Model for Atlassian’s CMDB?
Which integration capabilities does JSM CMDB have?
How can we keep CMDB up to date?
How long does it take to implement a CMDB?
Atlassian provides answers to most of these questions in multiple publicly available resources:
We will also share our answers in short:
Atlassian JSM Cloud has a great feature called Assets which is available with Premium and Enterprise plans. Think of it as a Service Management Database which can store any information that you would need in your ITSM or ESM implementations.
Atlassian does not lock Assets to fixed data models. Instead, they provide the freedom to create your own model according to your needs. They also now provide a few templates to help you get started. Even though every organization may have similar expectations, they are never exactly the same. The flexibility on modeling means you can design for what you need and eliminate noise.
JSM Assets provides integration capabilities for Assets and Configurations with the help of its Assets Discovery, 3rd party Marketplace Applications, and APIs.
Keeping the CMDB up to date requires both automated and manual methods. While existing integration applications are capable of automatically updating the data, there will always be some data types that your teams will need to update. For example, your Service Owners will update the definition of a service and its relations. A Service Management Database consists of both logical and discoverable relationships. Coupling your CMDB with Change enablement practices can help keep these up to date.
Depending on the complexity of your IT structure implementing your new CMDB may take between 1-3 months. The complexity lies in finding and understanding the data, designing the relationships, and the upkeep process. Naturally, integration applications will speed up the implementation but don't discount the planning, testing, and refining stages.
Ok, then comes the real question: Where to start?
Service Management Database will store related information for the following purposes:
Surfacing key information about assets (i.e., license expiration) and providing an easy way to notify interested parties (e.g., automate ticket creation based on attribute data & dates).
Simplifying user experience by filling available information to the ticket for setting the context
Speeding up the troubleshooting process and slashing down case resolutions by helping JSM agents to access correct and related information (i.e., finding Service Owner, Impacted Service, Service Dependencies, etc.)
Heads Up: A top challenge at this stage is resisting the urge to dump all data in.
Aiming for designing a “trusted database”, we advocate for asking the following simple question:
Does every data set fit the purpose listed above?
In case they don’t, we advise not to transfer the data into Assets. This way you can keep the database simpler and in the right fit. Only add data that you have a clear use for as you also need to ensure upkeep.
Commonly, there are 4 different data types that you would need for your Service Management Database:
People | People-related information includes your Employees / Managers, Partners, Suppliers, Vendors, Customers, and Organizational structures. You already have them in your Active Directory, CRM, ERP, and HRM systems. |
End User Devices | A list of your End User Devices would be stored in your device management tool. |
IT Infrastructure | IT Infrastructure, could mean an on-premise data center, hyperscale cloud platform, or both. They include hardware and software for servers, databases, network switches, routers, firewalls, load balancers, serverless structures, Kubernetes, licenses, applications, processes… |
Business related information | Any information that would help you to execute a better Service Management. Some examples: Business Services, Technical Services, Products, Agreements (i.e. Support Agreements, License Agreements), Security Policies and your config & process related data like process standards data, catalog of changes, risk scores, etc. |
Since JSM Assets can store all these data types you need to start with writing down your needs in the form of User Stories/Use Cases.
Data Type | Example Source |
People | Azure AD, Workday, Atlassian Access, Sailpoint, Okta, Salesforce, Hubspot etc… |
End User Devices | Microsoft Intune, Jamf, Google End Point Manager, Vmware Workspace ONE, etc… |
IT Infrastructure | AWS , Azure, Google Cloud Plarform, Alibaba Cloud, Data Centers… |
Business related information | Excel files, Salesforce, Hubspot, SAP… |
Here are some common needs you can use as an initial list and you can add more according to your project scope. We also added our example application(s) for importing relevant data in a few minutes. Data models will be created by the listed applications automatically. So, you don’t need to worry about how to design the model and integrate it with the source. The periodic synchronization feature also allows the data to be up to date.
Need | Data Provided By (example) |
---|---|
Finding managers of users and setting them as approvers automatically. (Step by step guide) | |
Finding the people in the same AD Group and sending them a notification. | |
Taking decisions based on the office locations of the employees. | |
Mapping Azure AD Users and Jira Users (Step by step guide) | |
Getting additional details of the requestor's manager (Step by step guide) | |
Setting the owner of a device (laptop, desktop, tablet, phone, etc.) | |
Keeping the inventory of managed end user devices (laptop, desktop, tablet, phone, etc.) | |
Searching for the owner of a device | |
Reviewing the important information about devices and taking automated actions according to the conditions:
| |
Notifying responsible teams to take necessary actions before the relevant expiration dates of devices such as:
| |
Keeping track of the deleted records. (Applicable for any data type. I.e. Users, Laptops, Tablets, Licensed Software, etc…) (Step by step guide) | Azure AD Importer for JSM Assets |
Connecting multiple object schemas and having an aggregated data model. Such as:
| Azure AD Importer for JSM Assets |
Keeping track of the whole IT Infrastructure. (AWS, Azure, Google Cloud Plarform, Alibaba Cloud, Oracle, SAP, etc…) | |
Using automated Service Dependency Mapping with Hosts for impact analysis. |
For more examples visit: Use Case Examples
Sometimes, using JSM Automation with Assets data may be tricky, especially if you are a beginner. Smart values, AQL syntax, components, and custom fields… all may get a bit confusing. In addition, consolidating data from multiple sources may be complicated too.
We included Step by step guides for some of the cases listed above so that you can replicate the same in a very short time.
In case you can not find an importer for your data sources, then you may use the APIs of JSM Assets to import the data programmatically. Here is a presentation from Team '22 explaining the steps for an integration project:
Asset and configuration management in Jira Service Management | Team '22 | Atlassian
Hakan Bahadir
Pio
Atlassian Marketplace Partner