Almost every DCIM solution comes with standard objects such as model floors, racks, devices or power & cooling elements; many solutions will probably offer some virtual equipment, circuits and cables. There are even some vendors who may model less common things – such as panels or doors – but inevitably, you will need something modeled that is not part of the “out-of-the-box” catalog. For instance, what if you need to model something a bit odd, say, a fire extinguisher (or the foosball table that is in Room 43B)? Can your DCIM vendor do that? And if so, how easily?

Let’s be clear: “yes, we can do that after some customization” doesn’t count as a valid answer. That statement is loaded with unknowns. What does ‘customization’ mean, anyways? Scripting? Some API extension? Does it mean maybe having the feature in some future release somewhere down the line? An army of consultants charging you for services work?

You need to ask the following (and get a clear answer): can you, as an end user, model any new object types that are important for your DCIM strategy? We believe DCIM software doesn’t have to be hard and shouldn’t require endless (and expensive) consulting work. For example, with netTerrain, not only can you define any type of object with endless properties and rules yourself, we show you how to do it…in 60 seconds (see the above video).

In the 1st part of our 8 part series, we addressed the issue of flexibility in DCIM systems from a generic standpoint; now, we’re ready to start digging a bit deeper. Today, we’re discussing the ability to model new object types and the basic requirements in the modeling process: type definition, properties and rules.

Creating new object types can be easy when your DCIM solution is flexible. Despite what some DCIM vendors would have you think, getting a new object type for your project doesn’t need to take months and cost an arm and a leg. With the right DCIM software in place, you should be able to add new object types in three basic steps (click here for the infographic):

1. Define the Object
   in this exercise, we’ll model something a little different – a fire extinguisher -for your data center to show you what is possible when your software allows you to do-it-yourself. So, the first step in making a fire extinguisher for your project is to create the object type in the catalog.To do this, you’ll give the type a name, pick out an icon, choose a category and select defaults such as size and template. You can also choose to keep the aspect ratio when resizing the object.
2. Define the Properties
   Next, you need to model the object’s properties. You should be able to add an unlimited number of properties, but for each property you’ll want to assign a property name, order, whether it’s mandatory, the default value, its list values, uniqueness and diagram display. You will then be able to decide which of these properties displays (and in which order) depending upon which user type is navigating through your catalog.
3. Define the Rules
   Now, you can define the rules that can change the behavior of your object. For example, you can use overrides to change the way the fire extinguisher’s icon appears based on the object’s specific values. Rule types you can choose include which image displays depending on the object’s values and hierarchy, instance effects, parent effects and upwards propagation (allows you to specify how far up you can add parent and grandparent effects).

Ok, so while our object creation and modeling process is actually quite feature rich, you may be wondering, “what about something a bit more complex, like a rack, device or card?” Fair enough, those types of objects have additional attributes and behaviors that may be outside of what we just modeled, such as: nameplate power, discovery parameters, interfaces, slots and more. In fact, the simple object we modeled today is usually referred to in netTerrain as a “generic node type”. To answer this question, you can model smart devices using our software and we have an upcoming blog devoted to modeling the “smart objects” like racks, devices and cards.

Bottom line? Buyer, beware. Some of the most expensive DCIM tools out there are very inflexible. Because much of the value of DCIM depends upon its ability to do what you need it to do in your environment, inflexible solutions are a bad choice. Further, it’s the rigidity that contributes to the high prices as, with rigidity, comes big price tags for consultants! In brief, you end up paying more for a tool that is actually worse (harder to use and less flexible).

Our story on DCIM flexibility is only beginning. In our next blog article, we’ll continue digging deeper; we’ll look at the creation of an actual hierarchy and discuss how you can customize your DCIM views, parent-to-child relationships and diagrams.

Stay tuned!

See also: our post on choosing the right DCIM solution and how to define DCIM.