What is the difference between a DSL and a CMDB

[AllieCat]

I am reviewing a document that shows a DSL and a CMDB. Is the CMDB the database where you track changes and a DSL is the actual library of software? Obviously, I am brand new to ITIL.
Thanks

[Guerino1]

Hello AllieCat,

Here are the differences between the DSL and the CMDB...

A Definitive Software Library (DSL) is usually a large file system where you store copies of your software. It will have all your source code, executables, libraries, etc. and will be structured to have meaning, usually through the use of a Taxonomy that helps categorize the directories you store things in. If done correctly, it will also have partitions that are broken down to match your "environments", so that you can have copies of the code in each partition that match the quality of the software to the environment it is currently in (or has been in). Whenever you or your enterprise gets software (from any source, such as a CD, DVD, download, etc.), you would instantly store a copy of the software in the appropriate directory(ies) on the DSL. The DSL would be exported to the entire enterprise, so that everyone knows where to find the definitive copies of any software version they care about. (NOTE: ITIL will tell you that a DSL is a cabinet or room where you store copies of the media. This is antiquated and very few enterprises in the world still do this.)

A Configuration Management Database (CMDB), is a system that has a database behind it, which allows you to record, track, and manage "both" individual Configuration Items and all the relevant relationships between them. A Configuration Item is "anything" that is worth tracking in your enterprise. For example:

- Assets (such as Software, Hardware, Vehicles, Furniture, etc.)
- Products
- Services
- Releases
- Changes
- Incidents
- Problems
- Projects
- Tasks
- Documents
- Projects
- Etc. (The list is endless.)

In a world where you have full integration, what is in the DSL should be "synchronized" and "correlated" with what's in the CMDB, as there should be nothing in the DSL that isn't tracked in the CMDB, in some way, shape, or form. However, getting this to happen is a complicated undertaking, as it requires complete automation of how to create, manage, edit, promote, reject, build, deploy, etc. all your software in the DSL. The automation framework will ensure that whatever is done in the DSL will synchronize the database, in the CMDB. This way, when people look at the CMDB for the latest information, it won't have stale data.

Anyhow, I hope this helps.

My Best,

Frank Guerino, CEO
TraverseIT
On-Demand ITIL Platform

[kimberlito]

Hi Guerino1,

could a user be considered as CI? My question is because a user has some attributes that change, like an internal phone, a cell phone, a location, etc.
Tanks in advance.
_________________
Kimberlito
Service Desk & Incident Management Project Leader.
ITIL Foundations Certified

[Guerino1]

Hello Kimberlito,

[benja1]

Hi Frank,

I've just read your post about CI examples and I always thought CIs tracked in a CMDB should only be ones under change control and are components of the overall system. For instance a laptop would be a CI, but the incident records associated with this CI are not CIs in their own right. Yes, you would want links to incidents/problems etc for each CI but you wouldn't want to track them in the CMDB as they're not components of the system, not to mention their volatile nature meaning tracking is very difficult.

Please can you clarify why you think 'anything' can be a CI?

Thanks, Ben

[Guerino1]

Hi Ben,