An Introduction to Insight
Hey everyone! Me again, Charlotte from Product Marketing for Insight. We recently joined Atlassian and I wanted to tell you more about what Insight is and how it works. This will be the first in a series of Insight articles coming your way giving practical advice on using the tool.
If you’re already using Insight you’ll be familiar with these concepts but please feel free to add any tips or advice in the comments!
As you may recall, Insight was part of Riada, an Atlassian Platinum Solution Partner. Last year, Insight separated from Riada’s consulting arm and became Mindville. And this July we joined the Atlassian team!
Insight was born out of a need for Jira users to be able to store and manage assets from within Jira itself. Not only the assets, but also any relationships between the assets. This information is useful to give context to Jira issues, whether they’re requests or incidents, IT or HR, etc.
Over the years, Insight has expanded in capability and has been used in all kinds of applications, from full enterprise IT Service Management systems, to facilities management, to tracking fish (I don’t know how and I foolishly didn’t think to ask more about that application!).
In this post I thought it would be good if I cover the basic concepts of Insight so it’s documented and can be referenced for future. So let’s get to it!
What is Insight?
We call it a tool for configuration and asset management. Or a database of anything if you want the less official term. The core part of Insight is the CMDB/asset store/whatever you want to call it. I know CMDBs can have a bad reputation but we think Insight is far more than ‘just another CMDB’ and plenty of our users use it purely for asset management. That’s the beauty of Insight - it’s flexible enough to do whatever you want to do and it can scale with your needs.
All the objects you add to the CMDB are then available from a custom fields added to Jira issue forms. So if there’s an incident, the reporter can select the affected business service(s) from a drop down menu. The assignee then has all the details of the affected service (what it depends on, who is responsible etc) from the Jira issue itself. This provides key context to help close issues faster.
Every issue linked to an object is then documented so you can build up a history of your assets to make informed business decisions and improve your customer experience. Maybe one service has far more incidents than any other so some improvements need to be made. Or a particular piece of software is getting lots of user requests so some knowledge based articles need to be written.
The other parts of Insight are automations, reports, importers, and integrations but for now, let’s focus on how the CMDB works. There are three levels of data hierarchy in Insight.
Data Hierarchy Level 1 - Object Schemas
You can create multiple CMDBs in Insight. These are known as object schemas. This is useful for a number of reasons:
-
Breaking data into smaller chunks helps with ownership and keeping data accurate.
-
Each object schema can have its own permissions to keep sensitive data safe.
Insight itself (and by extension Jira) doesn’t care which information is contained in which object schema. It just sees one big pool of data. This means you can easily use multiple object schemas for one use case.
An example of where this is useful is when working with the HR team. HR might want to be able to select a laptop and phone from the CMDB for new employee and assign them training courses from one 'onboard new employee' Jira issue. In many traditional CMDB systems you would need to add the HR team to the IT CMDB with the laptops and add the extra data required to manage the HR training. This isn’t ideal for anyone.
With Insight you can have two object schemas. One stores HR specific data, such as available training course, the other stores hardware information. HR are able to control their object schema entirely and links from the HR data to the laptop data can be made. This is much more user friendly as IT are unaffected, HR don’t get swamped with IT information they don’t need, and each team can look after their own data independently.
When deciding how to put data into Insight, always consider how to break down the data into manageable chunks.
Data Hierarchy Level 2 - Object Types
The next level is the object types that go within a schema. You define these yourself or you can use an object schema template (not in Cloud just yet) that will come pre-populated with certain object types that you can customize. Object types can be whatever you want them to be (remember the fish!) as Insight is very open.
Common object types are business services, servers, laptops, software etc. But they don’t have to be IT assets. Insight is an information store so if there’s something you need to know to understand your business better, you can add it. For example many people add things like vendor, location, employees, and business priority as object types as this information can be useful to know and link to other objects. Each company’s version of Insight is going to be unique.
You can organize object types in the hierarchy tree in a way that makes sense. This tree is mainly for navigation and readability as you can have empty object types here (e.g. Hardware in the image below) but it can be setup to offer inheritance of attributes.
That brings us nicely to attributes. They are what define an object type. Each object type will have its own set of attributes. The object type 'Laptops' might have the attributes model, serial number, user, warranty expiry date etc.
All object types will have four default attributes: 'Name', 'Key', 'Created Date', and 'Last Updated Date' (the last three are set automatically). Every other attribute can be defined by the admin. And because there’s a unique key attribute, the name of each object does not need to be unique. This can be useful if you’re doing inventory management in Insight and have 20 items with the same name.
Attributes can be of many different data types including text, dates, numerics, URLs (great for linking to other stores of information or warranty contracts), Jira users (excellent for setting ownership of objects), and statuses.
One final attribute I want to call out specifically is the attribute type of object as seen below. This links to other objects and is how you start building a map of dependencies between different objects.
Object types should be considered carefully and we have a few recommendations.
-
If you have an attribute that is repeated in multiple different object types, consider making it its own object type as this is easier to manage.
-
Think very carefully about objects to define and what attributes to have. One of the biggest causes of CMDB failure is having too much data and not being able to keep it accurate. The users we see that are most successful concentrate on what data they can leave out as well as what they need.
Data Hierarchy Level 3 - Objects
Objects are the final level of data and these are your actual assets. These can be linked to your Jira issues so whenever an issue comes in, the agent immediately has an idea of what’s up. It stops back and forth between agents and customers to get the specific details of a laptop. It can be used to immediately say if a customer should have access to the software they’ve requested. And it helps report on your business services as each issue related to a particular business service will be found rather than relying on good spelling and documentation by the agent/customer.
You enter the attribute values that define a particular object and with a click your object is entered into Insight. For the relationship attribute you select a specific object to link another object to. For example, if location is it’s own object type, then each object could be one of your business' offices. Then for every laptop you can quickly set the location by selecting ‘Stockholm,' ‘Berlin,’ or ‘Montreal’ etc.
References between objects have two benefits:
-
Minor but useful - it’s easier to manage. If an office moves from say Montreal to Toronto, you only need to update the Montreal object rather than go through each laptop changing Montreal to Toronto.
-
Major - you can map dependencies between your objects. For example you can map your business services and the different hosts, operating systems, and files they depend on. This map can be incredibly useful for understanding the downstream affects of changes (if I change this OS, what might be impacted?), as well as finding the causes of incidents and problems. And because each object can be linked to a Jira issue, over time you build up a comprehensive history of your infrastructure or other business assets which helps further with solving future issues and problems.
How do you get objects into Insight?
To finish up I’ll quickly discuss getting your data into Insight. Entering everything manually could be a life’s work in a large organization. So that’s why there are a few tools to help.
Insight Discovery
An agentless scanner (although there is an agent version available) that picks up network assets. You can choose which of these, and which attributes, you pull into Insight and you can create your own scanning patterns to find more specific details. If you run it on a schedule it will pick up changes to keep data updated. With automation rules you can even trigger Jira issues, email notifications, and more based on detected changes!
Importers
Let’s be honest, a lot of us are using spreadsheets to store some information we probably shouldn't be. Insight Importers can bring CSV and JSON files into Insight and you decide how this maps to a new or existing object schema.
Integrations
These connect Insight to other tools such as cloud services (Azure, Google, AWS), other CMDB tools (ServiceNow, Device42) and various other third party tools. Please note, these aren’t available for Insight Cloud but we’re currently exploring future integrations for Cloud.
While we have all these tools, we don’t recommend you bring in every bit of data you have into Insight. I plan to do a full post on how to decide what data to bring in as it is such a source of difficulty. You can then iterate and grow the object schema over time.
Otherwise you’ll end up with a headache that is impossible to keep updated, especially as infrastructure is changing faster than ever before. Automation rules can be used to help keep data updated but again, that’s a whole other post in itself!
Now you know what Insight is, you can learn more about what data should go in here.
Stay tuned for more information on how Insight can help you to gain visibility into infrastructure dependencies, quickly troubleshoot incidents, and minimize the downstream impact of changes. If you have any questions comment below and if you would like to experiment with Insight you can access a free trial from the Marketplace.
Was this helpful?
Thanks!
Charlotte Nicolaou
7 comments