Technically speaking, Configuration Management Databases (CMDBs) are the data warehouses of an IT environment. Practically, the job of CMDBs has expanded to mean many things to many people as their use has changed.

In the first part of our series on CMDBs we sit down with NetApp IT Senior Business Process Analyst Lisa Kurowski to get her perspective.

NetApp on NetApp:                  

We’ll start off with the same question for everyone in this series, but what does a CMDB mean to you?

Lisa Kurowski:  

CMDBs are used by IT organizations to not just understand what assets they have, but how they fit together. What dependencies they have on one another and how they help each other.

NoN:

How does NetApp IT use them? Are we fairly standard as far as how enterprise organizations use them or is there something that we do that’s unique?

Kurowski:

I don’t know that we do anything that is necessarily unique. I would say that in general, our CMDB is more mature than most. It’s been an iterative process. There’s still more assets that we could mature, but I don’t know if we’re necessarily unique, but I think we are successful.

NoN:

You talked a little bit about how it matured what’s that process been like? What are some of the changes you’ve seen?

Kurowski:

I tend to tell customers that you cannot mature the entire CMDB at once. We pick a tower of data, applications are hosted on logicals, which run on physicals, which sit in a data center. If you can create just that single path as your starting point, it gives you the foundation for them to extend. Okay. Well then how does storage fit into that picture? Where do load balancers fit into that picture?

You really can’t try to mature everything at once. We have customers that don’t have that core tower and come in and say they’re struggling, they want to figure out how to track storage in their CMDB. We ask “do you know what the linkage is between your applications and the logical servers?” If the answer is no, you’re never going to be able to, to create a sufficient picture that say how do I know who’s using storage?

So it’s, it’s an iterative process and overlaying on top of that, things like automation…automation can be exceedingly key to the quality of your database.

Probably our most important learning, because we did a great job of automating discovery…we did a great job of automating how new servers are added to ours, but we kind of forgot to automate deprovisioning. And that leaves you with everything up to the state of when it goes away. And then you end up with stale data that’s not leaving your environment as fast as your devices are.

NoN:

Do you have any ideas on how our use may evolve in the future?

Kurowski:

You’re always going to have a really large footprint, in my opinion, of either off the shelf applications, which you need to install somewhere or custom-built applications. I don’t think that fundamentally, the CMDB is ever going to go away. And I don’t think a lot of the structure is going to go away. You’re going to have legacy applications or new applications that simply aren’t suited for SaaS in the long run. I think that we’ll continue to extend the CMDB as it extends the resources that it uses. What does it look like if you’re in the cloud? By that, I don’t mean SaaS. I mean that if you’re hosted in the cloud, you expand the CMDB by discovering more cloud resources.

So what if we don’t have an on-prem server that’s hosting Oracle? What if we use the Oracle cloud? What if we used native Amazon databases instead? We will continue to extend. This is the more traditional infrastructure as a service type model.