Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: MadonnGrif
New Today: 35
New Yesterday: 73
Overall: 150084

People Online:
Visitors: 70
Members: 3
Total: 73 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

Note: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


The Itil Community Forum: Forums

ITIL :: View topic - What is the difference between a DSL and a CMDB
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

What is the difference between a DSL and a CMDB

 
Post new topic   Reply to topic    ITIL Forum Index -> Configuration Management
View previous topic :: View next topic  
Author Message
AllieCat
Newbie
Newbie


Joined: Sep 10, 2007
Posts: 1

PostPosted: Tue Sep 11, 2007 1:24 pm    Post subject: What is the difference between a DSL and a CMDB Reply with quote

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
Back to top
View user's profile
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Tue Sep 11, 2007 9:29 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send e-mail Visit poster's website
kimberlito
Newbie
Newbie


Joined: Aug 21, 2007
Posts: 6
Location: Portugal

PostPosted: Sun Sep 16, 2007 12:36 am    Post subject: Reply with quote

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
Back to top
View user's profile Visit poster's website
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Sun Sep 16, 2007 9:10 am    Post subject: Reply with quote

Hello Kimberlito,

kimberlito wrote:
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.


I would say that a person is a CI but the fact that a person is an End User is a descriptive relationship. For example...

Your primary ontological CI definition for a human being is going to be a Resource (i.e. a Person). This Resource will have a taxonomical categorization, such as an Employee, a Customer, a Vendor, etc.

You will also have ontological CIs for Services, Systems, Products, Assets, etc.

A very powerful way to categorize a Resource as an "End User" is through a relationship. So, for example, you might relate a Resource to a Service as an End User of that Service. This means you can relate as many people as you need to, independent of their role(s), to any System, Service, Product, Asset, etc. that they use, as End Users. It's a perfect example of when to use a Many-to-One Relationship solution.

I hope this makes sense.

My Best,

Frank Guerino, CEO
TraverseIT
On-Demand ITIL Platform
Back to top
View user's profile Send e-mail Visit poster's website
benja1
Newbie
Newbie


Joined: Oct 22, 2007
Posts: 1

PostPosted: Mon Oct 22, 2007 7:02 pm    Post subject: CI clarification Reply with quote

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
Back to top
View user's profile
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Mon Oct 22, 2007 10:48 pm    Post subject: Re: CI clarification Reply with quote

Hi Ben,

benja1 wrote:
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?


You're thinking in terms of what is important to "you" and not what's important to everyone else. An enterprise is a big place and different people and roles have different concerns. Engineers care about the world of infrastructure, Software Developers care about the world of code, Human Resources cares about the world of People, etc. Depending on which world you sit in, different things need to be versioned for you. Also, each world you sit in has concerns that overlap from one world into the next.

The truth is, that if you're managing your enterprise correctly, you're versioning just about everything...

  • Your Products
  • Your Services
  • Your Processes
  • Your People
  • Your Assets
  • Your Locations/Facilities
  • Your Incidents
  • Your Problems
  • Your Releases
  • Your Changes
  • Etc.

Today, you're probably versioning and controlling such things in different systems. The world of tomorrow will allow you to version and control such things all from one system (see our own platform as an example). There is no need for many different systems in your enterprise. With today's technologies and the low costs associated with implementing them, you can now collapse everything down into one system. We do it all the time.

A good CMDB allows you to show relationships between any two data types that are important to any stakeholder, regardless of the role they're in. In order to do this, your CMDB must now account of data that is outside the norm of infrastructure. The ITIL CMDB focuses on infrastructure. To any IT leader that has any real experience, this is a very incomplete view of a CMDB. Implementing such an incomplete view will leave you in a very incomplete and ugly state. Thinking of the bigger picture will be critical for real success, when implementing your CMDB as, when done correctly, the CMDB of the future is the definitive Knowledge Management platform for the entire enterprise. It becomes one place where everyone can go to see and understand their entire enterprise, not just infrastructure.

Anyhow, I hope this helps. Please let me know if you have anymore questions.

My Best,

Frank Guerino, CEO
TraverseIT
On-Demand ITIL Platform
Back to top
View user's profile Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Configuration Management All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.