By Derek Fields
In my last post, I introduced the idea of using Insight as a general-purpose Object-Oriented database to allow you to extend the Jira data model to capture information about objects and not just about issues.
In this post, we will look at how to model Facilities in Insight so that you can create a simple Facilities Management Service Desk using Jira Service Desk and Insight. Lets get started by stating some basic requirements that we want our service desk to meet:
-
Our facilities consist of Buildings, which have Floors, which have Wings (West, North, South, East), which have Locations. Note that I have capitalized Buildings, Floors, Wings and Locations because these are going to be object types that we want to capture.
-
We also have Equipment, which is a general term that we will use for any device or object that our facilities staff might have to repair, replace, or service.
-
We will distinguish between two types of Equipment: Replaceable and Serviceable. A Replaceable item is one that is not generally fixed, but is replaced. For instance, the light bulb in a light fixture is replaceable while the light fixture itself may be serviceable.
-
Of greater interest for serviceable items are those that need maintenance. These are a subset of Serviceable that we will call Maintainable. A Maintainable item is one that we will regularly provide with preventative maintenance so that we reduce the number of service calls for that piece of Equipment.
The following requirements will be discussed in a following article, which is how we are going to set up our service desk Issue Types, Request Types and Workflow
-
We will have two Issue Types. A Service Call, which is a request to repair or replace a piece of Equipment and a Maintenance request, which is a routine call to perform maintenance.
-
We will have one Request Type that is a Service Call.
-
Our workflow will be quite simple. The ticket will be Open, Scheduled, In Progress and Done. This is certainly too simple for a real Facilities Management service desk, but for our purposes, it will be sufficient, since the point of this exercise is not to demonstrate workflows, but to demonstrate the use of Insight to model our objects.
Design
Now that we have our basic requirements, lets look at how these lead to our design. The following diagram demonstrates a very simple hierarchical structure. Based on this structure, we should be able to allow our user to specify a specific location and send our technician to the right place without any guessing. We have added a Notes field to each object so that we can indicate information that might be pertinent to that object, such as “The door is on the West side” or “Stairwell” or “Make sure you bring earplugs – it is very loud”
(Aside: we could have model Wings above Floors. This is a design choice that should reflect how you and your facilities staff think about the real-world Floors and Wings represented by these objects)
The next diagram illustrates how we set up the Equipment model. This is a little more complicated because we illustrating inheritance, not hierarchy.
Implementation
Now that we know what our model looks like, lets implement it in Insight.
We start by creating a new Insight Object Schema that we will call Facilities with a key of FAC. Now that we have our empty schema, we can start by creating our objects, as designed above.
This illustrates the Building object type. I will create the rest of the object types the same way before I populate the attributes in them. Here you can see the Building/Floor/Wing/Location objects.
Note that I name them in the singular. These are not tables where we are keeping rows of buildings. These are types of objects and each object will be of type Building or Floor. So, we want to refer to the Object Type in the singular.
Inheritance
Remember that the Equipment hierarchy uses Inheritance in its data model. Lets take a short digression to discuss the concept of inheritance, which may be unfamiliar to you unless you happen to be an object-oriented software developer. Inheritance is the idea that one object type is a sub-type of a higher level type. You can see this in the Equipment Model that we presented above. We have two sub-types of Equipment: Equipment that is Serviceable and Equipment that is Replaceable. Each of these has its own fields but they also “inherit” the fields from their parent, which is the Equipment type. Further, we have another sub-type of a Serviceable object that is Maintainable, which has additional information regarding the maintenance schedule and guidelines. Generally, when an Object Type is a child or sub-type, it inherits all of the attributes of the parent type and then adds a few attributes of its own. There are exceptions to this rule, which are outside the scope of this article.
In order to make Equipment attributes inheritable, we need to check the box in the Object Type Configuration screen that will cause the children to inherit the parent’s attributes.
Note that we also set the object type as abstract. This simply tells Insight that we aren’t going to be creating objects that are only Equipment. All of our objects have to be either Replaceable or Serviceable. By setting the abstract checkbox, we are simply enforcing this policy.
Because of the way Insight is implemented, you must set the Inheritance checkboxes above BEFORE you create any of the child types. If you forget or later decide to make an Object Type a child of another type, you won’t automatically inherit the attributes and you may have to reimplement your schema.
Equipment
The reason for talking about inheritance will become clear was we look at how we create the Equipment types. In in the picture below, you can see that for Replaceable, we have specified that it has a Parent, which is the Equipment type:
When we create each of the Equipment child types, we indicate the parent type for this object. This means that Serviceable and Replaceable both use Equipment as their parent. Maintainable uses Serviceable as its parent. This results in the following complete Object Schema.
What you can see in this illustration is the inheritance from Equipment to Serviceable to Maintainable.
You may be asking at this point, why didn’t we do the same thing for Building and Floor and Wing and Location. This is a common mistake if you are new to object-oriented thinking. When you are thinking about inheritance, ask yourself, “Is this Object a type of another Object or does it belong to or part of another Object?” In this case, we say that a Serviceable object is a type of Equipment but a Floor belongs to a Building. Only the is a type of statement means inheriting from the parent.
Now lets look at how we manage the “belongs to” or “is part of” relationship between objects.
Attributes
Each characteristic or data point on an Object is called an Attribute. An attribute corresponds to a column in a database table.
The following shows the attributes that we have defined for the Floor object type.
The first four attributes – Key, Name, Created and Updated – are all standard attributes that Insight adds to every object type. In addition, we added the Notes attribute. More important, we added the Building attribute. Notice that under Type, we have selected Object instead of Default. This allows us to say that this attribute is another Insight object. In this case, Building. Under Additional Value, we have selected the “Is In” relationship type. This is a custom relationship type that I added in my environment. You can select “Dependency,” which is a standard type. This is just for documentation purposes and has no practical effect in our implementation.
I used the “Is In” relationship type for Floor, Wing and Location. To make this clear, here is the Wing object type:
In this case, we defined the attribute Floor to point to the Floor that the Wing is on.
The Equipment model is a little different because we are going to use inheritance. Here is the definition of the Equipment object type:
We have an Attribute called “Location” that references the Location where the equipment is found. We don’t need to specify this again for the other Equipment object types because they are going to inherit all of the fields that you see here. For instance, here is the Serviceable object type:
You can see by the hierarchy icon on the left of Location that this attribute was inherited from its parent. We added the Service Guidelines and Manufacturers Link attributes to the Serviceable object type.
The Maintainable object type further inherits from the Serviceable type:
Maintainable has inherited the attributes from Serviceable and added two additional attributes: Maintenance Procedures and Maintenance Interval.
When we are done with all of the object types, we can see a graphical view of our object model that looks like this:
Moving Forward
This was a long discussion about how to model our equipment in Insight. Next week, we will discuss how we tie this Insight object model to Jira Service Desk to allow the equipment and locations to be used to help our users get us the information that we need to support them.