Standard CMDB Data Models - myth or possibility?

mikkojuola
Giga Guru

Is it possible to define data models that would benefit and be useful for all organizations?

Are the models always dependent on organization, services, technology or something else that would make it impossible to define "standard data models for CMDB"?

When these questions are narrowed down to ServiceNow environments, some part of the models are taken for granted. For example one should not invent new classes related to Users (=People), Groups, Configuration Items (as base element) or Locations for example, since much of the functionality is bound to those classes. But when talking about the insides of the CMDB or how to combine CMDB with other ServiceNew classes, we definitely still have same room for variance.

So, what do you think? Is it possible to define standard data models for the CMDB? 

* If yes, what do you have in mind? Which area or domain? 
* If no, please explain why?

Cheers,
--Mikko

5 REPLIES 5

mikkojuola
Giga Guru

And to continue right away... I'd be very interested in knowing particular areas where following a fixed data model is a must, since there is a lot of flexibility in the platform. Especially when it comes to how different CI classes should be related to each other.

So, which ServiceNow features enforce certain data models to be used, inside or around CMDB, to get the benefit out of planned functionality?

Some areas that comes to mind:

  • Service Portfolio Management
  • Software Asset Management
  • Discovery?

Cheers,

--Mikko

yves_wullaert
ServiceNow Employee
ServiceNow Employee

Hi Mikko,

 

Yes it is possible, you can compare the CMDB in ITSM with the Bill Of Material what is used in the ERP world.

There are a lot of Maturity Levels in filling the CMDB from infrastructure to Capabilities (Business Service) Aware CMDB. I added a Picture of the Service Hierarchy (first CMDB Architecture Picture) which can be used plus the levels of CMDB usage and phases (see second Picture).

I know this is high level and not on CI level but it is important to understand the big picture before you zoom in to CI level.

I hope this Helps.

Kind Regards,

Yves

 

 

Hi Yves,

Thanks for the input. We are definitely on the same page here, since I also think that there can be common models and as you showed in the example pictures, especially on a higher, or more abstract, level.

And then depending on different scenarios, the more detailed blueprints inside each level or domain can differ from one company to another, but same principles can be used.

I did some research on the ServiceNow Community regarding "CMDB data models" and it seems that every now and then, people are asking about them, but have not really received any good answers. We would like to find and provide those answers, also on a bit more detailed level.

And the reason for this is that we have developed a "visual data modelling and audit application" for ServiceNow and this application also includes some blueprint templates. And after several years of consulting, the same models seems to repeat over and over again. One template is a very generic model for "Business Applications" for example.

Anyway... thinking about publishing these templates also outside of the application (at our website for example). But until then, you can find more information about our app from the DCM web pages: http://dcm.fans/datccb

I'll comment here again when the first blueprint template is available online.

 

Cheers,

--Mikko

Daniel Draes
ServiceNow Employee
ServiceNow Employee

There are certainly areas where you should stick to what we provide / use in our baseline.

Discovery is one example. Sure, you can modify all the scripts bringing back the data from Discovery, but this is a high burden on your end to maintain them with every release upgrade. I would challenge that this easily outweighs any short term benefits.

Another are is the Cloud Management piece. Here we built a lot of functionality around the CIs from automatic provisioning, decomissioning, meassuring (traffic, utilisation, ...). Certainly an area you do not wont to mock around with.