Understanding Object Types in JSM Assets

What Is an Object Type?

An object type is a category of things you want to track in your CMDB. Think of it as a class or template that defines:

• What it represents (e.g., Server, Application, Person)
• What information it stores (attributes like Name, Status, Owner)
• How it connects to other things (relationships to other object types)

Every individual item in your CMDB is an object - an instance of an object type. If "Server" is your object type, then "PROD-WEB-01" and "PROD-DB-01" are objects of that type.

Real-World Analogy

When to Create a New Object Type

Create a new object type when you have things that:

1. Have distinct identity - Each instance is individually tracked
2. Have unique attributes - The data you capture differs from existing types
3. Participate in relationships - You need to connect them to other things
4. Have their own lifecycle - They're created, changed, and retired independently

Decision Framework

Example: Should "Operating System" Be an Object Type?

Scenario: You track servers and want to record which OS each server runs.

Option A: OS as an attribute (select field)

Server
├── Name: PROD-WEB-01
├── Operating System: "Windows Server 2022"  ← Just a field
└── IP Address: 10.0.1.50

Option B: OS as its own object type

Operating System
├── Name: Windows Server 2022
├── Vendor: Microsoft
├── Support End Date: 2031-10-14
└── Security Baseline: CIS Level 1

Server
├── Name: PROD-WEB-01
├── Runs On: Windows Server 2022  ← Reference to OS object
└── IP Address: 10.0.1.50

When to use Option A:

• You only care about the OS name
• You don't track OS metadata (EOL dates, versions, patch levels)
• You have few OS variations

When to use Option B:

• You need to track OS support dates and lifecycle
• You want to query "all servers running OS X"
• You manage patches and want OS-level metadata
• Different teams care about OS independently

Object Type vs. Adding Attributes

A common mistake is creating too many object types when attributes would suffice. Another is creating too few and stuffing everything into one type.

Signs You Need a New Object Type

Anti-Pattern: The "God Object"

Don't create one object type called "Asset" with 100 attributes covering servers, laptops, software, and printers. This leads to:

• Most attributes empty for most objects
• Confusing forms with irrelevant fields
• Poor data quality
• Difficult reporting

Instead: Create specific object types (Server, Laptop, Software, Printer) that share common base attributes where appropriate.

Naming Conventions

Good naming makes your CMDB self-documenting.

Object Type Names

What to Avoid

• Abbreviations without context: "VM" alone is fine; "VPC Peering Conn" is not
• Version numbers: "Server v2" - just update the object type
• Technical jargon outsiders won't understand: "CI" (Configuration Item) - use "Asset" or be specific
• Redundant words: "Server Asset", "Application Object" - the CMDB context is implied

Common Object Type Patterns

These patterns appear across most CMDB schemas. Use them as a starting point.

People & Organization

Infrastructure

Object Type Hierarchy Considerations

JSM Assets supports object type hierarchy (parent-child relationships). Use this thoughtfully.

When to Use Hierarchy

Good use: Shared attributes and different specializations

Asset (parent)
├── Name
├── Status
├── Owner
│
├── Hardware Asset (child)
│   ├── Serial Number
│   ├── Warranty End
│   │
│   ├── Server (grandchild)
│   │   └── Hostname, IP, OS
│   │
│   └── Laptop (grandchild)
│       └── Assigned User, Model
│
└── Software Asset (child)
    ├── Version
    └── License Key

Flat vs. Hierarchical

Recommendation: Start flat. Add hierarchy only when you have clear attribute inheritance needs.

Quick Checklist: Designing Object Types

Before creating an object type, confirm:

• It represents something with distinct identity
• Multiple instances will exist
• It has attributes different from existing types
• Other objects will reference it OR you'll query it independently
• The name is clear, singular, and consistent with your schema
• You've considered whether it should be a child of existing type
• You're not creating it just for one attribute's values

Summary

Your object types form the vocabulary of your CMDB. Get them right, and everything else becomes clearer.