What Data Should I Include in Insight?
Hello! I’m back again with some more helpful tips on working with Insight. This will be a three part series that covers what data should go into Insight, how it should be structured, and how to keep it updated. These are maybe three of the most common questions we get asked by people starting on their Insight journey so I’m writing up our (Atlassian/Mindville's) advice for everyone to see.
These are all very good and valid questions but they're also very difficult for us to answer! The answer is so dependent on your uses of your data, your goals, how previous asset and configuration management was done, team knowledge/enthusiasm, even company culture!
Each company’s version of Insight is unique to them so it’s impossible for us to write a prescriptive guide or create the perfect template for everyone.
Instead, I can offer some guidance on what to include (or not), ways to structure your data to make it easier to work with and maintain, and how to actually maintain it.
I’m sure this is by no means a complete list so if you have other words of wisdom please share them in the comments!
If you’re new to Insight, then make sure to check out this article on how Insight is structured first.
Let’s start with what to include in Insight
The answer: any piece of information that is useful for you and your business to know and understand. It’s not the most specific answer in the world but the beauty of Insight is that it’s flexible enough for you to be able to add just about anything you like.
What specific objects you should include will depend on what you’re trying to do. An Insight instance for inventory management is going to look very different to one used to map business services and their dependencies for making changes and solving incidents faster.
Thinking about what not to include is key
When deciding what should go into Insight, think very carefully about what you are trying to achieve and what object information is needed to do so. Each object and attribute should be useful.
You should sit down with your team and any stakeholders and ensure each attribute is being consumed by someone or something. If nobody has a specific use for it then it gets binned. It can always be added later.
Do you really need to know the exact location of your servers? Or the manufacturer of your operating systems? Maybe you do, and that's perfectly valid. But if you’re not going to make a decision or query based on that data, then into the scrap pile it should go!
The best piece of advice I can give is to think very carefully and focus on what not to include as much as you focus on what to include. This is because:
-
The more objects and attributes you have the more work is needed to keep them accurate.
-
Lots of unused data will obscure the valuable data and could even degrade performance in extreme cases!
-
It is easier to add data later than remove it. So if you discover you’re missing something, add it in later rather than starting off with loads of data ‘just in case’. Nobody likes deleting data. I feel uncomfortable deleting data from our demo instances of Insight, let alone a working system!
A common theme we see with users that really get a lot of benefit from Insight is the attention they give thinning out their objects and attributes.
Consider future maintainability
It’s also critical to consider how you will maintain the data when it’s in Insight. How often does an object’s attribute(s) change and how easy will it be to keep it up to date in Insight?
I’ll cover ways to keep data up to date in a future post but it’s key to keep this in the back of your mind when building your object schemas.
If a particular detail of an object changes often but it's rarely used it probably makes more sense to keep it out of Insight and just look it up on the few occasions it’s actually needed. If something is used every now and then but is very static then it it may be worth including for ease of access.
Let’s take laptop software as an example. You could, if you wanted, update Insight to include every piece of software installed on the laptop a scanning agent, software request issues, and automation rules. If you have an open installation policy this is going to change relatively quickly and scanning patterns may not pick up new pieces of software so the accuracy might be a bit off. Instead, it’s probably better to look at a key set of software that you’re particularly interested in understanding the usage of.
If you have strict installation policies and software only get installed at laptop setup and through service desk requests then it may make sense to track in Insight as the rate of change is slower and easier to track.
Think beyond physical items
As Insight lets you define the objects you need, you aren’t limited to traditional or even physical assets. Business services for example, they’re not a physical asset but they’re often critical for people to understand in detail. You can link all of a service’s physical and non-physical dependencies to it so just by looking at a business service object you can get a full understanding of how it’s running.
But you can go as abstract as you like. Common examples users create are ‘objects’ of business importance, environment types, departments/teams, locations etc. There’s a great article series from Derek Fields that talks about data modelling with Insight that includes some example abstract object types or a facilities management system.
Another real-world example is categorizing business services. Lets say all your business services are added to Insight under the object type ‘Business Services’. You may want to categorise those business services into ‘Finance’, ‘Logistics’, ‘Sales’, ‘Infrastructure’ etc. You could do this with an attribute in the Business Service object type or you can make these categories their own object type called ‘Business Service Category’.
The benefits of this is that you can add details (attributes) specific to the category. Maybe there’s someone responsible for all finance business services. You don’t want to add that person directly to every finance Business Service object as it will become harder to maintain. Instead you just add it once to the finance Business Service Category object and now you only need to update it in one place and don't have to repeat data.
You could also have rules that take the operation status of each individual finance business service and roll them up into an overall status for the finance category. Now you can quickly see if there’s any service problems with each category of service by viewing the category objects.
You don’t need to add these types of objects to Insight but it’s important to know that you’re not limited by traditional assets/configuration items. It all depends on what you want to do which is why understanding your goals and the information you need to achieve them is so key.
Look ahead and grow organically
The last piece of advice is to have in the back of your mind any extensions you may want to do in future. This will both shape what data you choose to include but also how you structure your data (that will be the next article).
While it’s good to keep it in mind, we do recommend building Insight up in a gradual way. Trying to do one huge big release with 100% accurate data for 1000s of objects is very tough. Building small and adding new attributes, objects, and object schemas as you go is likely going to be significantly simpler.
Our recommendation is to find a problem, build up Insight to fix it, then move onto the next problem, growing Insight as you go.
I’ll wrap this up here. The next post will covers how to structure Insight once you have decided what to include. If you have any examples of how you decided what you include, please comment below!
Was this helpful?
Thanks!
Charlotte Nicolaou
3 comments