By Derek Fields
As a Jira Administrator, you may not think too much about object-oriented databases. In fact, the only time you may think about a database at all is when you have to contact your DBA to get them to do something.
In this article, I want to suggest that you might want to think about the kinds of objects that you need to represent in your Jira instance and why an object-oriented database might be just what you need to make that work.
What is an Object?
Simply put, an object is something that you want to store in your Jira ticket that has more than a single characteristic. For example, the summary, due date or description is not an object; that is data about the issue. A User, a Location, a Laptop, a Network Device, a Contract, a Patent: these are all objects. What makes them objects is that they have multiple attributes that describe them. For instance, a Jira User is an object that has a username, a display name, and an email address. A Location may have an address, a contact phone number, open and close times, etc. A Contract may have a Period of Performance, value, contract type, etc. What these all have in common is that there is more than one piece of information that you need to know about the object.
The second feature of an Object is that you may want to link that object to multiple issues. A User can be the Assignee or Reporter on multiple issues. Likewise, many issues may refer to the same Location or Laptop or Contract.
You could create multiple custom fields to hold this information for each ticket. If you are supporting laptops, you could have a Laptop Serial Number, Laptop Model, Laptop Make, and other fields. The user would then enter all of that information into the ticket.
As you can imagine, this is a terrible idea. Not only are you relying on your user to enter the same information every time they open a ticket for that same laptop, you are expecting them to enter it correctly each time. When you go back to look at which laptops seem to need service the most, you are going to find that a lot of your data aren’t any good.
You really don’t want your user to have to enter the same object data on every issue that relates to the same object. You would like them to be able to select the correct object from a database of objects and have all of the information about that object be immediately available to anyone who needs it. This leads to much more useful data both for resolving the issue and for tracking your business data.
Insight
One of the most popular apps for Service Desks is Insight from Mindville (formerly Riada). [Note: RightStar is an Insight partner.] Insight usually enters the Service Desk ecosystem as a Configuration Management Database (CMDB). A CMDB is a database that contains the hardware and software supported by an IT Service Desk. When a user creates a new issue in the service desk, say to request a printer repair, they will need to specify the printer. The CMDB provides them with a list of printers that are available, helping to reduce data entry errors and thus speeding the process of providing the requested repair.
Each of the items in the CMDB is itself an Object. The printer that we talked about above has a make, model, serial number, location, network address, etc. This information is vital to the IT department to help them to manage the printer. It allows them not only to locate the correct printer when it needs repair, but to create reports that show all sorts of information about the different equipment for which they are responsible.
You may already be using Insight for your CMDB, but you may not realize that what you really have is an extensible, configurable object-oriented database in which you can store any kind of object that may make sense for you.
Using Insight for storing Objects
Now you that you understand what an Object is and what Insight is, lets talk about how Insight can be used for storing and managing any kind of Object you may need.
Lets say that you are creating a Facilities Management service desk. You will receive tickets from users with requests for facilities service such as cleaning a break room, fixing a door, or replacing a light bulb. In addition, you want to make sure that you perform maintenance on certain pieces of equipment on a regular basis.
One of the core needs that you will have in this example is a database that shows the Buildings, Floors, Wings, and Room or Location numbers of each area. Similar to our printer example, you need to send a technician to the right place with the right equipment. To do that, you can use Insight to model these different location objects. In Insight, you can link objects together to create a hierarchy. So, Buildings have Floors, which in turn have Wings that have specific locations. Using this model, you can easily create custom fields that will allow your user to pick exactly the right location when submitting a ticket.
Now, since you have modeled your facilities this way, it becomes very straightforward for you to create reports that will show you which buildings or floors have the most problems. These are good places for you to focus your proactive maintenance tasks.
In addition, by modeling your serviceable equipment in Insight, you can automatically create tickets for your technicians to service the equipment according to the manufacturers specification. You can store links to the manufacturer’s instructions in the object and create a history right on the equipment object of the work that has been done in the past so that the technician knows the peculiarities of this specific piece of equipment.
Moving forward
This may all sound pretty abstract . Over the next few weeks, I will provide more details about how to create this kind of Facilities Management service desk combining Jira Service Desk and Insight. When we are done, we will have a simple but useful Facilities Management service desk that supports both repair and maintenance tasks.