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: LGard
New Today: 50
New Yesterday: 44
Overall: 146560

People Online:
Visitors: 38
Members: 0
Total: 38

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 - ITIL Implementation Plan Draft
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

ITIL Implementation Plan Draft
Goto page Previous  1, 2
 
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion
View previous topic :: View next topic  
Author Message
query
Itiler


Joined: Feb 02, 2006
Posts: 41
Location: Sydney, Australia

PostPosted: Thu Jul 20, 2006 9:06 am    Post subject: Reply with quote

Guerino1 wrote:
Hello Query,

Two things...

First, I have a white paper that highlights the requirements for a fundamental CMDB system. I use it as the foundation for regular lectures and presentations that I give. If you're interested, you can contact me at Frank.Guerino@TraverseIT.com and I'll gladly get it out to you. If you're going to go down the road of building it yourself, I at least want you to be armed with as much information as possible.

Second, thanks for the feedback. This is exactly what we're offering. I don't know if you're familiar with the Cell Phone or Cable TV model, but what we're offering works along the same lines. Our users connect to our platform, through a web browser, and have very affordable access to a very large array of tools that address different areas of the ITIL specification. They pay per use, such as you would for your Cell Phone service.

What we're trying to do is offer pre-constructed and pre-integrated solutions so that our customers don't have to do so for themselves. It seems to be working and takiing off. Our clients and prospects are starting to realize that they're not in the business of building ITIL solutions. They're also realizing that they're not in the business of IT and can't compete with what we're offering. This means they're willing to acknowledge that they're not specialists in providing ITIL solutions. They are "consumers" of ITIL and that's where they get their true value. They are wise enough to understand that they want the benefits of ITIL, not the costs and the ongoing headaches of managing an ITIL implementation. They're also wise enough to understand that every time they try and implement any single piece of ITIL, they are re-inventing a wheel that has already been implemented by someone else, such as the CMDB you're going after.

The whole purpose of ITIL is to not re-invent the wheel. "That" is the gift of the OGC. They are giving us what is "common" across all enterprises and they're calling it ITIL. What companies are slowly starting to realize is that the implementation "can" be the same, just like terminology and the concepts are the same. We're seeing that the market is "finally" starting to get this.

Anyhow, we'll see how it all turns out, wont we?

Regards,


Thanks Frank

Please check your email Inbox.
Back to top
View user's profile
grommitt
Newbie
Newbie


Joined: Jul 29, 2006
Posts: 3

PostPosted: Mon Jul 31, 2006 12:28 am    Post subject: Reply with quote

It looks like this thread has been bouncing back and forth a bit and I can see both sides of the argument. However, I do think that Guenero1 is falling prey to one of the major pitfalls of a CMDB implementation: Unrealistic expectations.

Over the years I've seen the CMDB grow into this, "Holy Grail" of IT. Every post I see nowadays is looking for a CMDB as the silver bullet for a failing operation because it contains information about everything and how everything is related to everything else. This is a dangerous mindset, and although ITIL does indicate that the CMDB should store all sorts of info, it certainly does leave some room for flexibility in both scope and depth depending on your business need. When it comes down to it, the CMDB is nothing more than a database with useful information that needs to be kept up to date. Set the expectations of the CMDB with your leaders appropriately. It is not this consolidated monstosity that requires thousands of man-hours to manage. Nor is it the key to saving IT. It's simply a convenient location for information that your organization cares about. With a few added benefits from being consolidated, such as extended reporting capabilities and easy access.

The fact is that IT does not yet know what the true standard is for a CMDB. Remember that ITIL was written back when this was a much, much simpler task. You could track everything in IT because it was all in one room. On a server the size of a dishwasher. Today, my PDA has more storage and power than servers did a few years ago. How on earth would you track all of that information and more importantly, why on earth would you want to?

That being said, there are some key differentiators between a CMDB and a regular configuration database. Ronni Colville of Gartner group has some insightful thoughts on this topic:

“Not all configuration repositories are CMDBs,” said Ronni J. Colville, Research Vice President for Gartner, in CMDB or Configuration Database: Know the Difference, March 13, 2006. “A CMDB is a special-case database that must have four critical functions, which distinguish the CMDB from other tools.”

In her research note, Ms. Colville defines these four critical functions as:

* Federation: bringing in multiple data sources directly by linking to sources.
* Reconciliation: avoiding duplicates and enabling matching of configuration items from different sources.
* Synchronization: identifying changes to the CMDB as they occur thereby ensuring the same version of the truth across integrated systems.
* Mapping and visualization: enabling a peer-to-peer and hierarchical views of the Configuration Items (CIs).

I would advise looking into both this article, and any Service Catalog articles before deciding on your final requirements.

Query, I think you have the right approach in that you are coming at this from a business requirement perspective.

I would however recommend that you not only take a look at the requirements of the CMDB itself, but discuss requirements of the surrounding processes with each of the owners. Here is where you will find some core requirements of your CMDB such as "the ability to traverse the relational model to automatically populate the most stringent availability requirement of component CIs" or "Relate Incidents and Changes to CIs for status accounting". These are steps that are often missed when pursuing a CMDB and the fact is, a CMDB is really not much more than an inventory if it is not actively integrated and used by surrounding processes.

A good approach to determining scope and depth is by determining those CI types which must be tracked. Start with Services and work your way down. Go only as far as you need to. Remember that nothing is stopping you from drilling down deeper every year. Relationships grow exponentially the deeper you, so most successful CMDB implementations start with a small scope and depth and grow as the maturity of the control activity grows.

Finally, regarding your question: I couldn't begin to answer whether building or buying is right choice for you. Although it sounds like you are not building from scratch, but rather integrating with an existing technology. I will say that the CMDB is the focal point of many companies such as BMC, HP, Axios, Marval and many others. Guenero1's point about their updates outpacing you is an accurate one. You may define a CMDB for what you deam your requirements to be and it will be fit for purpose today. However the features and growth of the tools built by industry leaders can seldom be matched and you may find yourself behind the pack in the tactical future.

At the very least, I would recommend evaluating at least the top 3 vendors AS WELL AS their strategic roadmaps once you have a clear vision of your requirements and the purpose of the CMDB in your organization.

I hope this helps.
Back to top
View user's profile
Guerino1
Senior Itiler


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

PostPosted: Mon Jul 31, 2006 3:48 am    Post subject: Reply with quote

Hello Grommitt,

Please find my response, embedded, below:

grommitt wrote:
It looks like this thread has been bouncing back and forth a bit and I can see both sides of the argument. However, I do think that Guenero1 is falling prey to one of the major pitfalls of a CMDB implementation: Unrealistic expectations.


This is an interesting statement. Please understand a couple of things. First, unlike many people, here, who are employees of an organizations who are trying to learn and implement ITIL as they go, my organization designs, implements, and sells ITIL solutions to the industry for a living. Unlike you, who is a consumer of such products and trying to learn as you go along, my organization is the creator of such products and has many years of experience in such matters. While I do not pretend that our experience is the only experience or even the best experience, it is, by far, a greater set of experience than that brought to the table by someone who is trying to figure out how to implement ITIL. What I bring you, I bring based on a great deal of experience that comes from already having implemented such solutions, many times over, and from dealing with customers and partners who have contributed a great deal to such solutions. Second, my expectations come from our customers and partners, which means these expectations are their legitimate expectations. As consumers of ITIL solutions, like you, their expectations are very real, legitimate, and accurate. Many of the people we deal with are some of the sharpest IT individuals in the industry. You may want to be careful about criticizing their expectations, if you haven't walked in their shoes and experienced their situations. Speaking for yourself is one thing. Speaking for others is very different.

Quote:
When it comes down to it, the CMDB is nothing more than a database with useful information that needs to be kept up to date.


You may want to understand a CMDB a bit more. A critical and fundamental requirement of a real CMDB is that it maintains relationships between entities or configuration items for the purpose of understanding dependencies between them. If it doesn't meet this requirement, it's not a CMDB. If you're falling prey to vendors that call their Asset Registers and repositories "CMDBs" then be careful. You may be exactly the ill-informed target they are trying to sell to. Remember there is a major difference between marketing and reality. Forgive me if I'm wrong, but your comments give me the impression that you are either very junior and not too experienced in IT or you have fallen prey to vendor marketing that makes anything and everything sound like a CMDB. Please remember that if it doesn't maintain relationships, it's not a CMDB. This requirement has existed for CMDBs since the late 70s early 80s. It is the baseline requirement for any and all CMDBs.

Quote:
Set the expectations of the CMDB with your leaders appropriately. It is not this consolidated monstosity that requires thousands of man-hours to manage. Nor is it the key to saving IT. It's simply a convenient location for information that your organization cares about. With a few added benefits from being consolidated, such as extended reporting capabilities and easy access.


I totally agree with this statement. Too much focus is put on the CMDB. However, please understand that the need for consolidated and centralized information is becoming greater and greater as the internet shows the individual consumer that they can be empowered by having more information at their fingertips. Enterprise executives and employees are starting to take this expectation to work with them. Why shouldn't they have everything at their fingertips? It's a great requirement and fundamentally what will cause the CMDB to take a more visible position with enterprises in the next few years. Both Gartner and Forrester agree that this is the case.

For many years, IT organizations around the world have spent hundreds of millions on solving for centralized business repositories or data warehouses that address the needs of their vertical busiensses. Every major enterprise in the world has continually worked to consolidate their critical information into more centralized and focused repositories and this is picking up speed as we move into the future. The CMDB represents the elusive data warehouse for the horizontal IT industry. Companies that have implemented it, like our own, are making rapid progress in convincing IT leaders that their staff is not equipped to do it correctly, nor will it be equipped to do it correctly, since it's not their core business. Any sound IT leader will agree with this instantly. A CMDB is a very complex solution that leverages many different technologies, patterns, and paradigms that very few organizations in the world are equipped to address. When we encounter an organization that has built its own, we simply show them ours and compare the costs vs. the benefits and end results. It's a pretty easy discussion.

Quote:
The fact is that IT does not yet know what the true standard is for a CMDB. Remember that ITIL was written back when this was a much, much simpler task. You could track everything in IT because it was all in one room. On a server the size of a dishwasher. Today, my PDA has more storage and power than servers did a few years ago. How on earth would you track all of that information and more importantly, why on earth would you want to?


First, please understand that a CMDB is not the invention of ITIL. It is an invention of the software industry that has worked dilligently, for years, to manage build, distribution, installation, instantiation, execution, and rollback dependencies for many decades. It spilled into the hardware/infrastructure industry when it was realized that the infrastructure industry was growing and spending out of control. Leaders want IT to be held accountable. ITIL is the very positive outcome of that need.

To answer your question of why you would want to track all that information: It's simple. Because understanding as much as you can makes it easier to manage. If you've ever managed a large enterprise you would understand this. You cannot manage what you can't see. Knowing what you own means you can manage it more proactively and productively. It also allows you strategic vision. If you can't see it, you're always in a tactical mode. One day, when you lead a large organization that has tens of thousands to hundreds of thousands of devices/assets to manage and hundreds to thousands of resources, spread throughout many locations around the world, with people that speak different languages and bring different cultural views to your organization, I'm sure you will understand the need for seeing and managing everything more effectively.

Quote:
That being said, there are some key differentiators between a CMDB and a regular configuration database. Ronni Colville of Gartner group has some insightful thoughts on this topic:


Grommitt, you may want to be careful, here. "CMDB" is an acronym for Configuration Management DataBase. They are not different. They are exactly the same thing.

Quote:
“Not all configuration repositories are CMDBs,” said Ronni J. Colville, Research Vice President for Gartner, in CMDB or Configuration Database: Know the Difference, March 13, 2006. “A CMDB is a special-case database that must have four critical functions, which distinguish the CMDB from other tools.”

In her research note, Ms. Colville defines these four critical functions as:

* Federation: bringing in multiple data sources directly by linking to sources.


This is not a fundamental requirement for a CMDB. It is a requirement for a "Federated CMDB", which is a different type of implementation. This definitely does not address an operational repository, which is a totally different implementation.

Quote:
* Reconciliation: avoiding duplicates and enabling matching of configuration items from different sources.


Yes, a CMDB will ensure uniqueness to eliminate redundancies and contention.

Quote:
* Synchronization: identifying changes to the CMDB as they occur thereby ensuring the same version of the truth across integrated systems.


Yes, a CDMB will ensure auditing and versioning, with views into the past as well as the present.

Quote:
* Mapping and visualization: enabling a peer-to-peer and hierarchical views of the Configuration Items (CIs).


Well, this is arguable, as this can actually be part of the reporting implementation and visualization framework that doesn't necessarilly need to be a part of the CMDB, itself. We actually do make it a part of the CMDB but it doesn't have to be.

It appears that Ms. Colville has missed the most important requirement for a CMDB of all... the fact that it must maintain relationships between entities, within it, for the purpose of understanding dependencies.

It appears that she has also mixed in some things that are questionable, when it comes to the implementation of a CMDB. This goes to show that you should be careful as to what you read and believe.

From her statements above, it appears that Ms. Colville has no real experience in either implementing or ever having seen a real CMDB. Interesting, isn't it?

Below, you speak of "traversing your data model". If you do not have the relationships in the repository you will not be able to perform any traversal, at all. It is the relationships between entities that make this possible. Therefore, you, yourself, acknowledge the need for maintaining the relationships. (FYI: We are called TraverseIT specificallly because we maintain the relationships and make such traversals possible. This is one of the many things that distinguishes us from our competitors.)

Quote:
I would however recommend that you not only take a look at the requirements of the CMDB itself, but discuss requirements of the surrounding processes with each of the owners. Here is where you will find some core requirements of your CMDB such as "the ability to traverse the relational model to automatically populate the most stringent availability requirement of component CIs" or "Relate Incidents and Changes to CIs for status accounting". These are steps that are often missed when pursuing a CMDB and the fact is, a CMDB is really not much more than an inventory if it is not actively integrated and used by surrounding processes.


Excellent advice. I second it.

Quote:
A good approach to determining scope and depth is by determining those CI types which must be tracked. Start with Services and work your way down. Go only as far as you need to. Remember that nothing is stopping you from drilling down deeper every year. Relationships grow exponentially the deeper you, so most successful CMDB implementations start with a small scope and depth and grow as the maturity of the control activity grows.


Questionable advice. What's stopping you is that you're spending money that doesn't belong to you. You company is not in the business of CMDBs and if you're making a decision to constantly invest in the growth and maintenance of one, year over year, you are making a decision to invest in something that has nothing to do with the busienss. This means you are planning on increasing your organization's "expenses" and makes you part of the big picture problem. Be careful, here. One half of your job responsibilities is not to create expenses but to reduce them. The other half is to help increase revenues. This is what every commercial entity that is in the business of making money or managing its costs wants of its employees.

Quote:
Finally, regarding your question: I couldn't begin to answer whether building or buying is right choice for you. Although it sounds like you are not building from scratch, but rather integrating with an existing technology. I will say that the CMDB is the focal point of many companies such as BMC, HP, Axios, Marval and many others. Guenero1's point about their updates outpacing you is an accurate one. You may define a CMDB for what you deam your requirements to be and it will be fit for purpose today. However the features and growth of the tools built by industry leaders can seldom be matched and you may find yourself behind the pack in the tactical future.


This is becoming more and more of a fact. When prospects see our visualizations they reallize they will never be funded to achieve what we have and that we can provide solutions at a fraction of the cost that it would take them to do it, themselves. This is when they realize that by making the decision to build their own, they instantly put their enterprise on a path that will fall further and further behind the industry.

I hope this information helps. As always, I enjoy and appreciate the information exchange.

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
grommitt
Newbie
Newbie


Joined: Jul 29, 2006
Posts: 3

PostPosted: Mon Jul 31, 2006 5:21 am    Post subject: Reply with quote

Hi Guerino1,

First off, let me explain that it was not my intent to offend you with my comments. I am simply trying to share my experiences and gain from the perspective of others. Unfortunately, I won't have time to respond to your post in detail since you've offered so much information. But let me elaborate on a few points:

Quote:
Second, my expectations come from our customers and partners, which means these expectations are their legitimate expectations. As consumers of ITIL solutions, like you, their expectations are very real, legitimate, and accurate. Many of the people we deal with are some of the sharpest IT individuals in the industry. You may want to be careful about criticizing their expectations, if you haven't walked in their shoes and experienced their situations.


Your expectations and those of your clients are irrelevant to my point. My point is that each organization is different and has differing sets of expectations. One needs to manage those expectations carefully, specifically with regard to the CMDB. I am not criticizing anyone's expectations, only questioning them. I did not question anyone's intelligence either.

Quote:
You may want to understand a CMDB a bit more. A critical and fundamental requirement of a real CMDB is that it maintains relationships between entities or configuration items for the purpose of understanding dependencies between them. If it doesn't meet this requirement, it's not a CMDB.


This goes without saying and I'm surprised you've even raised it as a point. However, I agree completely.

Quote:
If you're falling prey to vendors that call their Asset Registers and repositories "CMDBs" then be careful.


I agree with this statement. There are a plethora of vendors who are masquerading their Asset Registers or Inventory systems as CMDBs. In fact, I would argue the true CMDB hasn't been delivered by any vendor yet. This is a common view that I hold with both Gartner and Forrester.

Quote:
Forgive me if I'm wrong, but your comments give me the impression that you are either very junior and not too experienced in IT or you have fallen prey to vendor marketing that makes anything and everything sound like a CMDB.


This is the quote that leads me to believe that I've offended you. Once again, my intent was not to insult you. However I would have expected more diplomacy in the response of a senior level executive, such as yourself. As for my experience, I hold practitioner level certifications in ITIL and have over 10 years of practical experience. In my opinion, one needn't even have credentials in order to engage in healthy debate over these processes and I welcome anyone's comments. Whether or not they are new to ITIL or IT.

Quote:
Why shouldn't they have everything at their fingertips?


I'm afraid you've missed the mark here. The answer is simple: They may not need it all. The key is not delivering ALL the data. It's delivering the RIGHT data.

Remember that the CMDB doesn't have to be a costly, painstaking endeaver. You can deliver vast improvements with the right amount of data. The point I was trying to make is that over-ambitious expectations are the top killer of CMDB initiatives and once again, not all companies require information about everything.

There is certainly room in the industry for CMDBs of varying sizes. It needn't contain everything for the sake of it.

Quote:
Quote:
That being said, there are some key differentiators between a CMDB and a regular configuration database. Ronni Colville of Gartner group has some insightful thoughts on this topic:


Grommitt, you may want to be careful, here. "CMDB" is an acronym for Configuration Management DataBase. They are not different. They are exactly the same thing.


I disagree with your statement and I think you'll find that so too do the leading analyst firms. I understand why you would think this, as it is a long held belief that any database can be a CMDB. The truth however is that there are unique qualifiers that differentiate a CMDB over and above relationships, and federation alone is not one of them. Federation is however, a required function (to some extend) of a healthy CMDB. The point of federation is to make use of the data that you already maintain. True, you could duplicate all of your data within the CMDB, but that would hardly be effective.

If you have access to Gartner, I encourage you to read the article I've referenced in it's entirety. I think you will alter your perspective once you do.

Quote:
From her statements above, it appears that Ms. Colville has no real experience in either implementing or ever having seen a real CMDB. Interesting, isn't it?


I obviously cannot speak of Ms. Colville's experience but I hardly think it professional of you to challenge it in such a way. Perhaps you think we should put more stock in your organization than in Gartner's?

Quote:
Below, you speak of "traversing your data model". If you do not have the relationships in the repository you will not be able to perform any traversal, at all. It is the relationships between entities that make this possible. Therefore, you, yourself, acknowledge the need for maintaining the relationships.


Yes, the relationships are a given and are covered in detail in the foundations class.

Quote:
What's stopping you is that you're spending money that doesn't belong to you. You company is not in the business of CMDBs and if you're making a decision to constantly invest in the growth and maintenance of one, year over year, you are making a decision to invest in something that has nothing to do with the busienss.


Missed the plot again I'm afraid. I'm talking about drilling down deeper as far as the data stored in the CMDB. Do you believe that a company needs to be in the business of building CMDBs in order to have one and grow the amount of data they store in one? I'm guessing that my statement was misunderstood here.

I appreciate the feedback and will attempt to better word my comments in the future to avoid ambiguity.

Regards
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion All times are GMT + 10 Hours
Goto page Previous  1, 2
Page 2 of 2

 
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.