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: TWeissmul
New Today: 17
New Yesterday: 96
Overall: 141268

People Online:
Visitors: 63
Members: 3
Total: 66 .

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 - CMDB vs Configuration Management Software
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CMDB vs Configuration Management Software

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


Joined: Jan 12, 2007
Posts: 48
Location: Warsaw, Poland

PostPosted: Fri Apr 27, 2007 10:59 pm    Post subject: CMDB vs Configuration Management Software Reply with quote

Is there any difference between CMDB software and Configuration Management Software?
My understanding is that CMDB software is the storage of configuration data and the Configuration Management software is the tool to maintain CMDB and configuration itself.
The main features of CMDB are reporting and searches, while the Configuration Management software features are automated update and change control.

Very often however these two are used as if they were the same. Am I wrong with my understanding?
_________________
Krzysztof (Chris) Baczkiewicz
IT Standards Support
Eracent
Back to top
View user's profile Send e-mail Visit poster's website
alphasong
Itiler


Joined: Mar 03, 2007
Posts: 33
Location: Minneapolis

PostPosted: Sun Apr 29, 2007 12:25 am    Post subject: No Reply with quote

No. You are right. We need to take ITIL and COBIT to the next level. See my response to "Advice on researching an overall CM tool."

-ctb
_________________
Charles T. Betz
Back to top
View user's profile Send e-mail
Cekir
Itiler


Joined: Jan 12, 2007
Posts: 48
Location: Warsaw, Poland

PostPosted: Mon May 07, 2007 9:24 pm    Post subject: Reply with quote

Charlie,
In the other thread you are writing about the difference between enterprise and element Configuration Management.
Relating to my question - which is which? Or you meant something else?

My understanding is that no matter if you are talking about element or enterprise CfM, you have a difference between CMDB and CfM software.
_________________
Krzysztof (Chris) Baczkiewicz
IT Standards Support
Eracent
Back to top
View user's profile Send e-mail Visit poster's website
vitalitil
Newbie
Newbie


Joined: Jul 25, 2006
Posts: 7
Location: Scotland

PostPosted: Thu May 10, 2007 1:09 am    Post subject: To CMDB or not to CMDB Reply with quote

Strictly 'CMDB' is an ITIL word. Personally, I would be very careful not to interchange terminology as this undermines the point of the ITIL glossary to aid communication and is the reason for many forum questions on itilcommunity and others. Logically, a CMDB is Configuration Management Software as ultimately it has to be a software entity of some sort, but it shouldn't be thought of as such. It's more of a magic, sage-like box that knows and sees all. Configuration Management Software may be employed to manage the CMDB (e.g. enforce the Configuration Management control policies), but the CMS should not be considered part of the CMDB. The CMS encompasses the CMDB may be a better way of putting it.

...as far as I'm concerned anyway. As always, you'll be able to find many who disagree.

Vitilitil
_________________
Vitalitil
Back to top
View user's profile Visit poster's website
Guerino1
Senior Itiler


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

PostPosted: Thu May 10, 2007 12:59 pm    Post subject: Re: To CMDB or not to CMDB Reply with quote

Hello Vitilitil,

Comments embedded, below...

vitalitil wrote:
Strictly 'CMDB' is an ITIL word. Personally, I would be very careful not to interchange terminology as this undermines the point of the ITIL glossary to aid communication and is the reason for many forum questions on itilcommunity and others.


Actually a CMDB is a very old concept, that has been around far longer than ITIL. The problem with ITIL is that if you implement its description of a CMDB, you're actually taking a serious step backwards in CMDB functionality, as a real CMDB handles far more than just computing Assets. Software Development CMDBs, for example, handle things like detailed source file versioning, build object handling, dependency tree creation, checkpointing, build control, deployments, installations, instantiations, executions, rollbacks, and much more, including tracking physical assets that the software was built on, deployed to, installed on, etc., as well as the environments that the work was performed in, etc. A CMDB, as described by ITIL is a very limited thing. In many cases a toy compared to what a real technology organization will want to leverage.

Quote:
Logically, a CMDB is Configuration Management Software as ultimately it has to be a software entity of some sort, but it shouldn't be thought of as such. It's more of a magic, sage-like box that knows and sees all. Configuration Management Software may be employed to manage the CMDB (e.g. enforce the Configuration Management control policies), but the CMS should not be considered part of the CMDB. The CMS encompasses the CMDB may be a better way of putting it.


I agree with you that a CMDB is a form of CfM software. It is one of many pieces that help to build a CfM "environment".

I think the safest way to look at it is that there are many different SW tools that help with CfM. Some are repositories, like a CMDB, some are version controlling systems, some are build control systems, some are change control systems, and so on. We use them all, together, in a synchronous landscape that exists to automate how we control our environment. After all, the whole purpose of software is to automate processes, while efficiently managing and sharing information.

Anyhow, I hope this helps.

My Best,

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


Joined: Jul 25, 2006
Posts: 7
Location: Scotland

PostPosted: Thu May 10, 2007 6:54 pm    Post subject: CMDB Reply with quote

Hi Frank,

A fair point about the CMDB concept being around for ages. What I should really have said is that ITIL seems to have pinched it for themselves to specifically denote a DB consisting strictly of CIs and their relationships, which is indeed very limited (on its own certainly). I think that's one of the problems in the IT world today - people of different ages/experience holding different meanings of the same word, depending on the context in which they first heard it used.
Very confusing!

Regards,
Vitalitil
[/i]
_________________
Vitalitil
Back to top
View user's profile Visit poster's website
jpgilles
Senior Itiler


Joined: Mar 29, 2007
Posts: 123
Location: FRance

PostPosted: Thu May 10, 2007 8:57 pm    Post subject: Reply with quote

Although the CMDB might be a pretty "old" concept, it just looks like as a pretty modern if not sci-fi thing in most companies I deal with.....
_________________
JP Gilles
Back to top
View user's profile Send e-mail
Guerino1
Senior Itiler


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

PostPosted: Thu May 10, 2007 11:23 pm    Post subject: Reply with quote

Hi JP,

jpgilles wrote:
Although the CMDB might be a pretty "old" concept, it just looks like as a pretty modern if not sci-fi thing in most companies I deal with.....


In some ways a CMDB appears like a sci-fi concept because it is an urban legend to many enteprises, since many enterprises that are supposed to be doing the right things just simply aren't. They hear about the right things but don't really know where to start. The reality is that if you're a mature enterprise, you should have had some form of a CMDB, in place, the day you started managing software (custom built or purchased). Having one acts as a command and control foundation for your entire SW infrastructure (think of your assembly line for SW manufacturing through its lifecycle). The reality is that most enterprises simply hack out code, manually, with no real appropriate controls in place. I think this is a direct fallout of the DOT.COM era, where people were getting hired as technologists simply because they could say the word "technology" and fog a mirror. The reality is that the industry lost a lot of its understanding of SW development best practices and we're only now recovering from the shock. Smart organizations that survived the bust are realizing that have to go back to fundamentals. We see it every day. And, while ITIL puts a slant on getting Infrastructure and Support teams to work and play more efficiently, the reality is that they only exist because of the whole Product & Service Development and Management processes. This implies that ITIL realy is a "subset" of what it really means to run IT like a business. Since ITIL started with the production environment and is working itself backwards, it obviously has some serious issues that don't take into account what drivers are for development. However, it's all good, as it all helps to run IT better.

Another reason a CMDB looks like a sci-fi concept is that a modern CMDB is way beyond what it used to be. In this day and age, a good CMDB is your core Knowledge Management platform for IT and the businesses that rely on IT. Done correctly, a CMDB is about so much more than managing infrastructure assets. (I can't tell you how amazed I am to find how many people I talk to think that the databases that come with Autodiscovery tools are CMDBs.) A good CMDB is about managing an enterprise and all the entities and relationships associated with that enterprise, including things like managing configurations for:

  • Technical Products, Services, and Processes
  • Non-technical Products, Services, and Processes (yes, businesses need to manage the configurations of their things, too)
  • Software and everything associated with it
  • Computing Assets (Computers and related infrastructure)
  • Non-Computing Assets (materials, vehicles, furniture, etc.)
  • Requirements, Problems/Defects, Risks, Incidents, Releases, Changes, etc.
  • Documentation
  • Facilities
  • People (Employees, Consultants, Vendors, Clients, etc.)
  • Contracts
  • Licenses
  • And so much more...

The reality is that a good CMDB goes way beyond just managing computing Assets. And, once it does, it becomes the portal into data, information, and, ultimately, knowledge. It will act as the centerpiece for data/information storage and exchange. It will provide you and your enterprise with powerful data mining, visualizations, report generation, interfaces, and so much more. It will provide your enterprise with modern collaboration solutions. It will provide your enterprise with major operational efficiencies. And, this is all just the beginning. Where good CMDBs will be going, in the next year alone, will be pretty amazing. This is why the undertaking of building a CMDB, oneself is not something that experienced IT people would ever recommend for their own organizations (unless, of course, they're in the busienss of selling CMDBs). The costs, complexity, skills, and time necessary to build and maintain a real CMDB are just too great and are constantly outpacing consuming enterprises' ability to keep up with them.

Anyhow, I certainly hope this helps.

My Best,

Frank Guerino, CEO
TraverseIT
On-Demant ITIL
Back to top
View user's profile Send e-mail Visit poster's website
Cekir
Itiler


Joined: Jan 12, 2007
Posts: 48
Location: Warsaw, Poland

PostPosted: Fri May 11, 2007 9:10 pm    Post subject: Reply with quote

Guerino1 wrote:
A good CMDB is about managing an enterprise and all the entities and relationships associated with that enterprise


Isn't it the Configuration Management Software and not the CMDB?

Guerino1 wrote:
I can't tell you how amazed I am to find how many people I talk to think that the databases that come with Autodiscovery tools are CMDBs.


I would say that the term means what most people say it means. After all standards and best practices are based on existing common understanding. At least in theory Smile

Getting back to my distinction - Can we say that the CMDB Software tool is the tool that is reporting the state of the infrastructure and the CfM Software is the superset that includes both reporting and maintaining?
_________________
Krzysztof (Chris) Baczkiewicz
IT Standards Support
Eracent
Back to top
View user's profile Send e-mail Visit poster's website
Guerino1
Senior Itiler


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

PostPosted: Fri May 11, 2007 10:30 pm    Post subject: Reply with quote

Hello Christopher,

Cekir wrote:
Guerino1 wrote:
A good CMDB is about managing an enterprise and all the entities and relationships associated with that enterprise


Isn't it the Configuration Management Software and not the CMDB?


Actually, not really. Configuration Management SW is usually strictly about managing version/change control. So, for example, Source Code Control Systems (SCCS) are CfM tools that manage versioning and change control but do very little to manage relationships, other than being able to tie Source Code to trunks, branches, etc. It's also the same with things like Autodiscovery tools. They help establish inventories, allow you to compare actual to expected, and some even allow for automated change control of configurations to assets. In this latter, case, just because there's a database behind it doesn't make that database a CMDB.

A CMDB is more about the following primary concepts coming together:

  • Being able to track inventories of all the important entities to an enterprise (not just infrastructure)
  • Being able to track histories & versions of all entities
  • Being able to create, track, and manage relationships between them (one-to-one, one-to-many, many-to-one, many-to-many, circular)
  • Being able to track histories & versions of all relationships
  • Being able to mine all that data/information in useful ways
  • Being able to see all that data/information in one place
  • Being able to render all that data/information in ways that are useful to the users

Given all of this, you can now use the CMDB as the hub for controlling operations (at a minimum, technology operations).

Things like autodiscovery tools are strictly a part of Asset Management. Things that control control changes to Assets are considered Change Management tools that act as sanctioned delegates to facilitate Configuration Management, making them, at best, CfM SW but not a CMDB.

Quote:
Guerino1 wrote:
I can't tell you how amazed I am to find how many people I talk to think that the databases that come with Autodiscovery tools are CMDBs.


I would say that the term means what most people say it means. After all standards and best practices are based on existing common understanding. At least in theory Smile


Not really. Calling Autodiscovery tools that come with DBs a CMDB is more of a marketing bend to take advantage of people that really don't know what a CMDB is. Remember, just because ITIL is weak on defining a CMDB doesn't mean that there aren't smart people out there that do understand what one is. The world is loaded with people that get it. Talk to any lead SW architect in any major firm and they get it. Sadly, most infrastructure teams are following ITIL blindly and, in doing so, are missing the finer points of SDLC. However, all of this is not to say that all such tools don't have specific value. There is great value in a Source Code Control System, in an Autodiscovery and Change Management system, in a real CMDB, etc. It's just important to understand the differences and why they add value.

Quote:
Getting back to my distinction - Can we say that the CMDB Software tool is the tool that is reporting the state of the infrastructure and the CfM Software is the superset that includes both reporting and maintaining?


See my description in the form of bullets, above, of what a CMDB has to do. It's far more than just a mechanism for reporting current state. Done correctly, it's your enterprise's key Knowledge Management platform, as it covers many different areas of the enterprise, not just infrastructure.

Anyhow, I hope this helps.

My Best,

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


Joined: Jan 12, 2007
Posts: 48
Location: Warsaw, Poland

PostPosted: Mon May 14, 2007 9:47 pm    Post subject: Reply with quote

OK, let's call "many different areas of the enterprise, not just infrastructure" a Configuration.
Let's assume that a history of changes belong to the state of Configuration - It is actually the state of history, that may change any moment.
Let's note that tracking, data mining, seeing and rendering are either part of reporting or input for reporting, therefore every reporting tool has to have these features.

After above can we say that CMDB is a reporting tool with relationships maintenance abilities?

As for Configuration Management tool, I think it is more then just a version/change management tool. Also the ITIL books treat it differently. Actually I have a feeling that the blue book is not saying about CMDB as a software tool at all. It just talks about Configuration Management software that is capable of maintaining a CMDB.

Sorry for the pure academic discussion, but I need a definition for documentation I am making.
_________________
Krzysztof (Chris) Baczkiewicz
IT Standards Support
Eracent
Back to top
View user's profile Send e-mail Visit poster's website
Guerino1
Senior Itiler


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

PostPosted: Mon May 14, 2007 10:34 pm    Post subject: Reply with quote

Hello Christopher,

The academic discussions are just as important as the implementation discussions, so don't be sorry about them. My comments embedded, below...

Cekir wrote:
OK, let's call "many different areas of the enterprise, not just infrastructure" a Configuration.
Let's assume that a history of changes belong to the state of Configuration - It is actually the state of history, that may change any moment.


Sure, but this type of history is only a small portion of Configuration Management.

CfM is also concerned with "Inventory". So, a good CMDB will know what your inventory state is/was, at any point in time (and this doesn't just mean computing infrastructure inventory).

CfM is also concerned with relationships between things. CfM helps to explain how things are tied together and why things are tied together, too. Now, with this in mind, "history" is important, both, in terms of tracking changes to an entity as well as in tracking changes in relationships.

Quote:
Let's note that tracking, data mining, seeing and rendering are either part of reporting or input for reporting, therefore every reporting tool has to have these features.


Yes, but in this day and age, these features should be coming with the tools you buy. If you're forcing a CIO to buy a CMDB and then go out and buy a separate Business Intelligence & Reporting tool, you're forcing two purchases, forcing integration work, forcing him/her to buy and manage infrastructure for both, etc. In this day and age, a good CMDB comes with built-in BI & Reporting tools. If it doesn't, you have to ask yourself if you're buying into something that's already antiquated.

Quote:
After above can we say that CMDB is a reporting tool with relationships maintenance abilities?


No, because reporting is only one small aspect of what you're using a CMDB for. You're most likely using it as a data hub, possibly an operational store (if you're buying a modern one), an inventorying system, and much more. If you're using a CMDB properly, you're using it as the backbone to manage configurations for many different pieces of your enterprise (documentation, designs, builds, deployments, installations, instantiations, executions, rollbacks, verifications, etc.). BI & Reporting are just features that help you look into all of this and understand it.

Quote:
As for Configuration Management tool, I think it is more then just a version/change management tool. Also the ITIL books treat it differently. Actually I have a feeling that the blue book is not saying about CMDB as a software tool at all. It just talks about Configuration Management software that is capable of maintaining a CMDB.


Remember, ITIL is very limited in its specification of a CMDB, leaving out a great deal of what is necessary for a good one. Therefore, if you implement a CMDB according to ITIL, there's a very high chance that, from day one, you will cripple your enterprise's ability to move forward and do some advanced things that it will need to do to compete with other companies.

I hope this helps.

My Best,

Frank Guerino, CEO
TraverseIT
On-Demand IT
Back to top
View user's profile Send e-mail Visit poster's website
Cekir
Itiler


Joined: Jan 12, 2007
Posts: 48
Location: Warsaw, Poland

PostPosted: Thu May 17, 2007 12:41 am    Post subject: Reply with quote

Frank,
Could you please name other sources (frameworks, best practices, standards, etc.) using the CMDB term?
_________________
Krzysztof (Chris) Baczkiewicz
IT Standards Support
Eracent
Back to top
View user's profile Send e-mail Visit poster's website
Nikhil
Newbie
Newbie


Joined: Mar 21, 2006
Posts: 17
Location: India

PostPosted: Tue May 22, 2007 11:06 pm    Post subject: Impact analysis with CMDB Reply with quote

Hi Guys,
sorry to but in this intresting discussion, but just wanted to add a point. Are we not losing on the most important benefit from a CMDB software, and thats Impact Analysis and Base lining.

Impact Analysis - Once you get in all the CI details and their relations ships, you can identify the impact of any change and any CI not working. This impact would be great to analyze if you are talking about a huge enterprise and immense number of CI's, both IT and non IT.

Base Lining - This may be related to the History of CI that was refered earlier in the discussion, but base lining is certainly one of the plusses of a CMDB. Once base lined, we can get any CI back to its working state by reverting the CI to its based lined version.

Probably, they could be termed as the benefits of a Configuration Management software, and wont be a part of a CMDB. This is the kind of intelligence that one would expect from a software and the information that is required for the extracting this intellegence could be called as CMDB.

Would highly appreciate your comments.
_________________
Regards,
Nikhil Kulkarni.
Application Analyst
cMango.. The Services Management Company

The taste of low quality lingers long after the satisfaction of low price.
Back to top
View user's profile MSN Messenger
Guerino1
Senior Itiler


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

PostPosted: Mon May 28, 2007 2:04 pm    Post subject: Reply with quote

Cekir wrote:
Frank,
Could you please name other sources (frameworks, best practices, standards, etc.) using the CMDB term?


Hello Christopher,

Sorry for the late reply. Have been busy dealing with other things.

Unfortunately, there really are no standards in this space. "Configuration Management" as a term, seems to have started and flourised in two different areas, a few decades ago:

1) In the chip/hardware/system design and development field (with known references that go back as far as the 1960s).

2) In the Software Design and Development discipline, where a good percentage of it is tied to version control, change configurations, build configurations, deployment configurations, test configurations, etc. (with known references that go back to the 1970s).

In both cases, I'd bet that references to CfM probably can be found to go back, even further, if one is willing to do the research.

The concept of a CMDB is something that didn't start showing itself until the late 80s/early 90s, when databases just started becoming common to the open market. Even so, what we were exposed to, back then were very crude and always highly limited. It was in the late 90s that I started to realize significant commonalities between repositories used by different industries that all tried to accomplish the same fundamental things:

- CMDB
- Knowledge Management Platform
- Global Information System
- Informatics Platform
- Etc.

The reality is that when you break them down, they all really exist to provide solutions for the same fundamental requirements.

As far as standards and best practices, it appears that aside from the many opinionated whitepapers that you can find, spread across the internet and in the research of such well known companies such as IBM, Bell Labs, etc., ITIL has been the first entity to try and standardize the purpose of a CMDB. However, because ITIL, itself, is highly limited and takes a production operations approach for managing infrastructure, more than anything else, those limitations carry into its description of a CMDB. Sadly, if you show a SW developer an infrastructure CMDB, you will not get much respect from them. Their expectations of a CMDB are far greater.

Anyhow, things that will definitely help make a CMDB effective are specs like RDF and WOL (OWL), because if you design to such specs, you will automatically take into account many of the implicit requirements of a solid CMDB.

I hope this helps.

My Best,

Frank Guerino, CEO
TraverseIT
On-Demand ITIL
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.