Data Modeling - Part 1: Distributed Object Schema Model
At Mindville, we often say that Insight can be used for all kinds of assets and that you are only limited by your imagination. But what does that actually mean?
Assets, IT and otherwise, are indeed all around us. The definition of an asset as an item in Insight will vary depending on your role within your organization.
For example, for an IT Manager, assets can be computers, servers, and routers. For an HR Manager, assets can be employees, organization charts, or diplomas. And, for a Marketing Manager, assets can include digital images, articles, roll-up banners, and more.
These assets are all very different, which means that you may need to document information about them differently. This is where strong data modeling practices make it easier to achieve information transparency for all your assets.
In this blog, we will share some practical information on how to model your data using Insight in Jira to implement and run a successful asset management solution.
Object Schemas: The Secret to Top-Level Design
In Insight, assets are called objects, and any number of objects are stored in various object schemas. Deciding how many object schemas and object types we need, and how they relate to each other, is how we define data modeling in Insight.
Although object schemas are high-level abstracts, proper distribution and design of these is the first crucial step in a successful Insight implementation. To simplify for all Jira users and admins, we can compare object schemas to Jira projects.
Our documentation on Insight contains definitions of all the abstracts we use, including object schemas. The Insight 101 guide can also help you to get started. It’s recommended that you read that information before continuing through this blog post.
When you create a new object schema in Insight, there are a few out-of-the-box templates available for you to use right away. You get the option of an IT Assets schema, CRM Schema, or an HR Schema. However, in some templates that contain different types of objects, there may be no links to connected schemas.
For example, an HR schema may contain IT assets, but does not refer to a separate IT asset schema. This design is done purposely to ensure that template schemas can be independent, in case you only need to set up one schema for all your assets.
Remember (as mentioned in the recommended reading above) that you can always reference objects from one schema to another. From a technical perspective, it does not matter if you work with one complex schema or multiple cross-referenced schemas.
There are, however, few topics that would second something we call the distributed schema model. Let’s elaborate on those topics:
Fit for Purpose
The term, fit for purpose, is taken from the service management area and means that a service or it's components fit the purpose they’ve been applied for. For example, a phone, text message, e-mail, Instant messaging system, or even a pigeon are fit for the purpose of sending a message to someone.
However, fit for purpose also means cutting off any unnecessary related assets. You don't need to buy a pigeon farm or a postal office to send a message. You just need a trained pigeon or postal service. It’s the same with Insight schemas: You may need to refer IT assets to HR assets such as employees, teams and departments, but you don’t necessarily need all your HR assets in the IT assets schema and vice versa.
Using separate schemas and cross-referencing them will fit the purpose in all areas supported by Insight without the unwanted overhead.
Ownership and Management
It seems reasonable that ownership of different schemas will be kept in different hands. HR will own HR, IT owns IT, Sales owns CRM, and so on. That said, the management of the schema, starting from design and through the development of required structures, integrations, and automation must be a separate, independent process run by the schema owner and his/her teams.
Other stakeholders can be consulted and have input in the process, but managing the schema needs to be its own dedicated process. Key points are cross-references, allowing schemas to reference one another to provide the respective integration layer.
Performance and Maintenance
Few smaller schemas will most likely consume a bit more of system resources than one, huge, complex schema. However, partitioning the data in several schemas will have a positive impact on the performance of Insight, Jira, and the overall user experience with Insight and custom fields.
Why? The smaller the data chunks, the easier to calculate –whether it’s IQL queries, searches over schema structures, or re-indexation of specific schema data.
Data security and compliance
Last but not least, following ownership, we have the approach to distributed schemas that will allow you to assign permissions against schema data.
It’s an often omitted, part of a solution design. As an example, HR data should follow GDPR compliance regulations, where only authorized employees can access or modify rights to specific personal data.
Similar but less-strict compliance regulations, such as the US-based SOX, the EU’s 8th Corporate Law Directive on financial data and systems, or PCI-DSS compliance for payment/transaction management systems also fall under this scope.
Of course, you could manage these using object type roles/permissions within one schema, but using both schema level, and object type level roles and permissions give you more flexibility in managing your data to ensure it’s in line with policies and compliance rules.
Yet, we still haven’t answered the question of how distributed schemas should be organized. Let’s get down to the practicalities.
Distributed Schemas Model - A Practical Guide
It can be as simple as creating object schemas from our templates, with a few amendments. With the templates, we already fulfill the first rule of thumb:
Match your schemas to business function/area
In other words, IT service management (or your IT assets) will be stored in the IT assets schema, HR assets in the HR schema, customers, contracts and suppliers in the CRM schema and so on.
If you use Insight’s templates, we recommend replacing any in-template references with a reference of an equivalent object in another schema. For example, instead of keeping your infrastructure assets in the HR schema, make sure to store it in the IT asset schema and update the references to the IT asset schema accordingly.
The picture below shows an example of this within the default HR schema template in Insight, explaining how we should move the IT assets to an ITSM schema and create cross-schema references.
There may still be a number of object types that are common and used in several schemas. Perfect examples are equipment manufacturers and models data. They apply the same way to laptops (in ITSM), mobiles (in ITSM or HR, depending on who owns mobiles in the organization), vacuum cleaners (facility management), cars (facility management, HR, Operations/Sales).
Where do we store those? And what about metadata? We highly recommend replacing the built-in Jira Service Desk fields with Insight custom fields that link to Insight objects, adding flexibility and precision to your data.
There is no single method or answer to how you organize your assets and schemas in the end. We suggest that you use common sense and your knowledge of the organization. That information will help you decide if you want to have a separate schema, centralized procurement/provisioning department/process, where you would store this kind of data, with references to all the other schemas (IT, HR, facility, operations, etc).
If there is no need for that, you can keep this data in other schemas as per ownership of actual assets. We suggest keeping it in a consistent (like to like) way to assure interchangeability.
Similarly with operational categorization - if you can combine it with a business service catalog, which will be common for all other schemas - why not? And if not - don't bother, but keep up your informational consistency for the sake of easier management.
When cross-referencing schemas you need to keep a few Insight specifics in mind:
- Attributes referring to Jira objects like users, groups, projects, versions, and components are not managed nor visualized as references, although they work alike.
- References to Jira objects like users/groups can be visualized at their Jira profiles, while Insight object references (e.g. Insight laptop object to Insight employee object with the same Jira user applied) are not.
- Group membership calculation is referred to as Jira users attribute, not the user/employee objects.
Why is this important? To properly resolve cross-references and, as a result, be able to utilize Insight’s advanced functionalities for custom fields and workflow conditions, validations and post-functions. We will get back to details in further blog posts, for the moment let's stick with the second rule of thumb:
The simpler, the better
Or, if we reference a popular acronym - KISS (Keep It Simple, Stupid).
You can manage complex IQLs, such as retrieving a Jira username from within an abject distant of 4-5 levels of references, but why would you? Especially if you can refer to it directly or over one referenced object? So wherever you don't necessarily need to - avoid complexity.
There is a third rule of thumb to remember in regard to the schema distributed model:
Run it dry before you buy
In other words, test your design with respective stakeholders before you implement it in a live environment. Even if you know your design perfectly, and it makes sense to you, there may be other opinions or valuable feedback on improvements. Remember that, by the end of the process, the stakeholders are the ones that will use it in the live environment, either creating data in Insight, using it in Jira tickets, or producing/assessing reports based on the data.
Data modeling is a dense topic, but in this blog, we wanted to start from the very top and explain the main concept of object schemas and the basics of what you need to keep in mind when building a distributed data model in Insight.
There are a few things to keep in mind when deciding the number of object schemas to use. These are:
- Fit for purpose
- Ownership and management
- Performance and maintenance
- Data security and compliance
We also talked about our three rules of thumb when designing a distributed data model.
- Match your schemas to business functions/areas
- The simpler, the better (or KISS)
- Run it dry before you buy
Adopting these rules will help you to organize and manage your data better in Insight.
For more information about the Insight product suite or to see the software in action, click on over to the Mindville site!
Originally published Jan 9, 2020 10:49:37 AM
Late 2019, we did a brand split. Mindville is the company behind the Insight products. Riada provides expert consultancy services on all things Atlassian. Riada can be found at riada.se. Mindville is an Atlassian Platinum Top Vendor and Riada is an Atlassian Platinum Solution Partner.
Topics: Jira Service Desk