Modeling all your infrastructure’s elements and data can seem daunting. But it doesn’t have to be.
We always advise that you adopt an agile approach to model your data in Insight: start small, with a specific challenge in a specific part of your organization, and then from there you can build as you grow. For instance, you could start by mapping the service catalog of your ITSM team, or even mapping your software licenses or your facilities.
The goal of this article is to enable you to build a centralized location for your employees to access the services that you provide. Using a Configuration Management System (CMS) to track assets and issues gives you a single source of truth for all of your operations, and gives you the information you need to address issues faster.
Because we’re using an agile approach, you should build your processes one at a time.
You will identify :
- Your most crucial asset management issues
- The departments that most need your help
- The information you’re missing to close requests faster
- The assets you need to track and how they affect each other
Once you’ve done that, we’ll show you how to create a data model that you can use to create a placeholder for your data. From there, you’ll be able to create service requests that give your service teams more information, and create instances in which you’ll be able to be proactive instead of reactive.
Step 1: Fast Track to Success With 4 Simple Questions
The first exercise is a simple one, but requires a little bit of thought. Because we’re using an agile approach, you will start small, and iterate from there. This set of questions helps you expose the assets you want to track, and how they need to be connected so that you’re able to view those connections in your requests.
- What assets do I want to track?
- What information do I want to track regarding those assets?
- What are the links between these assets?
- What is the easiest way to manage links between assets?
You can write your answers down on paper, on a whiteboard, or in a document on your computer. The medium is not important; what is important is that you accurately define what’s most important to you with regards to the questions above.
As we progress through this worksheet, we’re going to show you what we did as we performed the same exercise. In our case, we answered our questions on the whiteboard because we like to stand and write.
Once you’ve answered those questions, you can move on to the next step, which will help you to create an accurate representation of how you want your data to be represented in your CMS.
Step 2: Understanding Insight
Before moving on to the data model part of this exercise, it will be important for you to understand how your data is stored and represented in Insight. Let’s take a look at how Insight keeps your data arranged before we uncover the steps you will need to take in order to create an accurate data model that correctly responds to your needs.
Bridging the Gap: Key Insight Concepts
Think of Insight as a set of databases (object schemas), that contain different tables (object types), that are made up of rows (objects), and columns (attributes).
Let’s go one by one. Your object schema is a container for all of your assets and the information related to them. You can have one or many object schemas. It really depends on how you want to keep track of your content. Most people with an ESM practice create separate object schemas for each of their different departments.
(*Note that you’ll be able to link and reference different Object Types across Object Schemas)
Object types are containers for particular types of objects. They are very much like folders.
So, if our Object Schema was being used for HR, we could have an Object Type called Employees, another called Offices, and even one called T-shirt sizes. Each of these Object Types can be connected in different ways, which we’ll explore further later.
It’s worth noting that you can actually nest your object types. So, under Employees, you could have two other object types called Contractors and Full-Time. Again, it really depends on how you want to arrange your information.
Each of your object types can have attributes. So if we’re still using the HR example, then those attributes would be things like salary, employment start date, role description, and other things of that nature.
Object References - Inbound & Outbound
Your attributes can also contain references to objects for when you need to link them together. These references are directional, which means that there are both inbound and outbound references to assets.
When you create a new reference, or link, from one object type to another, it creates two references: the outbound reference is contained in the object type where you created the reference, and the inbound reference is shown in the object type that is being referenced.
For example, if you create an outbound reference from Object Type “Computers” that references Object Type “Users,” then the computer the person is using will be shown as an Inbound reference in a specific Object once the computer has been assigned to it.
You can reference Object Types in other Object Schemas, as well, which is extremely important in an ESM environment. For example, you’d be able to reference an employee Object Type in an HR Object Schema from a computer Object Type in an ITSM Object Schema. For now, however, it’s best to start small with one Object Schema, and then build from there.
Step 3: Creating a Data Model
Like the four questions you asked in the beginning, you can complete this on paper, whiteboard, or computer. What matters most is that it helps you to establish your data model so that you can arrange it properly in Insight.
There are more technical processes to follow from here, but in this worksheet, we just want you to have a solid foundation that you’ll be able to build on in your CMS.
Let’s use the answers from the four questions you answered in the beginning to help create your data model.
1. What assets do I want to track?
The answers to this question will give you your Objects and Object Types. Note that your Objects are just the actual assets you’re tracking, and the Object Types describe them, like we discussed above.
With this in mind, you will want to begin by grouping your assets into types. Because you can nest Object Types in Insight, you may end up with something like you see in the image below.
This image is obviously of a fully fleshed-out ITSM schema, but it’s an example of how you can nest Object Types to create nested categories.
As you can see, you can end up with quite a lot of information. It all depends on how you want to arrange your assets.
To give you an example of how you might go about this, we’ve done a data model of our own on a whiteboard. This is how we started.
Image 1a. Note that Hardware, Software, and Configuration have been added as Parent Object Types. This is an example of how you can use Object Types to create more detailed categories for your Objects (assets).
As you can see, we’ve used the information that we have about Insight and have created a data model that we can then use to advise us as to how to set up our CMDB when we’re ready.
2. What information do I want to track regarding my assets?
The answers to this question will inform what your Attributes for each of your Object Types will become. Remember that Attributes are attached to Object Types, and those Attributes are inherited by each Object.
So your Attributes are the things that you need to know about each of your Objects. In a computer Object Type, its attributes might be CPU, graphic card, motherboard, and RAM.
For our example, we gave letter designations to each of our Object Types and then did the same for their attributes. Take a look at how we did it in the image below.
Note that the Attributes here can also be existing Object Types. You’ll use those to establish connections to help you get more instant information when investigating service requests.
Now that we have established what the attributes of our Object Types will be, we’ll use our next set of answers to see how our assets are connected, and how they affect each other.
Tip: You can use the Status attribute as an Insight custom field that you’ll be able to show on the Jira customer portal or help center pages.
3. What are the links between these assets?
The goal of adding a CMS to your Jira instance is to give you a deeper understanding of what’s happening so you can close requests faster. Once you’re running Insight, you’ll be able to see how your assets are connected so you can make smarter decisions about next steps.
Insight also gives you the ability to configure more powerful workflows, but for now we’ll look at connecting assets. The image below is an example of what you’d see in a service request when you’re using Insight.
Note the Affected Business Service field. If you click on that, you’ll get to see even more information.
The links you create now will help to shape how you see affected services in your requests. In our ITSM example, we wanted to make sure that we could see the Operating System of our servers, and know the IP address so support staff can quickly locate the server.
To make it simple, we just drew a line between those attributes and the corresponding Object Types. We’ll get into more details in the next step.
4. What is the easiest way to manage links between assets?
We know what things we need to have connected. Now let’s decide how we’re going to manage those links.
Earlier, we talked about Inbound and Outbound references. This is where that information will become crucial to your data model. In our example, we linked the Operating System and IP Address attributes to their corresponding Object Types, in this instance, by making them Inbound Links of the Object Type.
The reason we do this is so that we can see those references when we look at the Objects (or actual assets) of those Object Types in service requests. We saw how that would look in a ticket in Image 3a.
You’ll also be able to access that information from Insight when looking at a particular object, as you can see below.
Any time an Attribute is added to an Object Type as a connection to another Object Type (which, in turn, will appear in the details of specific Objects) that connection becomes an Inbound link to the Object Type.
Take a look at how that looks in Insight in the Attributes section of an Object type below.
Insight provides a lot of different ways of adding Attributes, but for now, this serves as a good example. And once you’ve established what those links will be, you’ve completed your data model!
Originally published Apr 21, 2020 5:42:00 AM
Topics: Asset Management