How many of you put supporting data that can not be collected via automated means into your CMDB? For example, if I have a list of Applications, for each I might have their Owner Resource and Organization, Their Description, their lifecycle status, etc. This is all data that is not created from automated scripts/solutions but, rather, created and maintained by humans. How many of you are using your CMDB to create and maintain such data and information about your CIs?

Any Auto Discovery tool is only discovering what is defined in the scope of the Auto discovery

In addition, just because the AD Tool found it, does not mean I want it in the CMDB

I dont have an issue with the AD data being used to validate existing data in the CMDB or determine a change is status has occured; however all CMDB Data has to be validated by a person - otherwise the data has no validity_________________John Hardesty
ITSM Manager's Certificate (Red Badge)

I've had the situation where we've designed and built CMDBs that hold both, automatically created/discovered data and manual data. The key was to uniquely identify the two categories and make them distinguishable and useful to the end users. So, for example, when anyone built software in any environment, the build would put all CIs and all relationships between all CIs (including the machines used in the build, the environment being built in, etc.) into the CMDB, with things like timestamps, user information, etc. While this information was not important to everyone, it sure helped to do things like tie software to machines and environments, which was important to development, engineering and support teams.

UKVIKING wrote:

Any Auto Discovery tool is only discovering what is defined in the scope of the Auto discovery

I agree, which is why I believe that enterprises often need many different forms of autodiscovery that have different contexts, to be successful. Unfortunately, not all enterprises have the skill sets to understand and implement multiple contexts or the funding to support it all.

UKVIKING wrote:

In addition, just because the AD Tool found it, does not mean I want it in the CMDB

True, but one can always filter out the noise and harvest what is important. I find simple scripting and ETL solutions to work best, here.

UKVIKING wrote:

I dont have an issue with the AD data being used to validate existing data in the CMDB or determine a change is status has occured; however all CMDB Data has to be validated by a person - otherwise the data has no validity

Very important point. I agree totally.

I guess one of the bigger issues is access to everyone who controls different types of data, throughout the enterprise, and integrating such data from all of their sources. For example, the Infrastructure teams rarely, if ever, are in charge of defining, creating, and maintaining Application data/information or enterprise Services data/information. I've found that the most useful CMDBs take feeds from many sources and then allow access by all of those sources. Is this your experience?

The CMDB should have only the data that is needed to delivery and manage the service being delivered to the customer(s) / user(s) and to have supporting data that reflects this.

The data also needs to be managed - not by tools or automated scripts. The data needs to be managed by individuals / people whose sole purpose is to ensure that the DB is valid

Case in Point: An AD tool will find all the devices that have IP addresses. This is one of the nice things about the tools. Going through each IP address in the IP range and using the built in tools of TCP/IP to gather the information - such as SNMP.

However, what if your environment is not in one data centre and the links between the data centre are public IP over public networks..

Are you going to AD the entire Internet ? OK. Cool. You can filter out that which is NOT yours.

However, certain protocols are rife for manipulation. These are ICMP and SNMP. Usually most businesses block these not only from external but also internally as well - VLAN firewall restrictions and all that

The CMDB should not be the Skynet as this is just GIGO. The CMDB for an org should be there for the IT SM processes. nothing else._________________John Hardesty
ITSM Manager's Certificate (Red Badge)

Any data that needs to be created manually by teams other than the one that puts together and maintains the CMDB, where such manually created data needs to be in the CMDB to maintain its integrity.

UKVIKING wrote:

Not all data needs to be in a CMDB.

Not all databases needs to be linked to the CMDB

I agree, however, the more good data there is, the more useful the CMDB becomes.

UKVIKING wrote:

The CMDB should have only the data that is needed to delivery and manage the service being delivered to the customer(s) / user(s) and to have supporting data that reflects this.

It's arguable that all IT services are constantly being delivered and therefore need to be in the CMDB. And anything that can have an incident, problem or risk registered against it should, at a minimum be in the CMDB.

Also, if you start to evolve beyond ITIL, you start to realize that the CMDB can also have Business Services and CIs as well as IT constructs and CIs, since the Business requires such tools as well. (Having two such tools, one for IT and one for the Business is rarely smart when, in fact, they can be combined into one.)

UKVIKING wrote:

The data also needs to be managed - not by tools or automated scripts. The data needs to be managed by individuals / people whose sole purpose is to ensure that the DB is valid

Case in Point: An AD tool will find all the devices that have IP addresses. This is one of the nice things about the tools. Going through each IP address in the IP range and using the built in tools of TCP/IP to gather the information - such as SNMP.

Agreed.

UKVIKING wrote:

However, what if your environment is not in one data centre and the links between the data centre are public IP over public networks..

Are you going to AD the entire Internet ? OK. Cool. You can filter out that which is NOT yours.

Certainly not.

UKVIKING wrote:

However, certain protocols are rife for manipulation. These are ICMP and SNMP. Usually most businesses block these not only from external but also internally as well - VLAN firewall restrictions and all that

The CMDB should not be the Skynet as this is just GIGO. The CMDB for an org should be there for the IT SM processes. nothing else.

While I agree with your statement that the CMDB should not be "skynet", one thing that many IT resources miss is that the CMDB, done correctly and made accessible to the Business, can also be valuable to them, too. For example, when you start to mix Business constructs and CIs with IT constructs and CIs, you start to get a very powerful Knowledge Management solution for the enterprise. (Hence my other post on whether or not anyone is using things like their Service Catalogs or CMDBs as KM tools for their businesses : http://itilcommunity.com/modules.php?name=Forums&file=viewtopic&t=6210)

ITIL is merely a book of knowledge about what people have done in the past. That is all

I do IT Service Management and have been since 1984

I use ITIL as the basis for the policy, process and procedures that I write and enforce

Now, as to the CMDB being constantly updated.

There is a vast difference between an NMS tool which is keeping track / status - Real Time - on the status of each object within its scope and a CMDB

The CMDB is not an NMS tool. It is a reference tool. The data in there should not change as the service changes w/in a business day. That is pointless
The IM and PM tools should be linked to or as part of the CMDB or verse vica

ITIL is merely a book of knowledge about what people have done in the past. That is all

Actually, I would disagree with you on this. ITIL is, allegedly, all about IT Service Management (reference the ITIL documentation which clearly states this). (Whether people agree that ITIL is a good representation of ITSM or not is a different conversation.) Also, I would add that ITIL is not just a set of books of what has been done but also what they are recommend you do and use as a baseline for your own IT Service Management improvement.

UKVIKING wrote:

I do IT Service Management and have been since 1984

I use ITIL as the basis for the policy, process and procedures that I write and enforce

Good, so we're on the same page and I'm clear that I'm dealing with someone who has the experience and the common sense that comes with being involved in a bigger picture of IT, that has existed since before ITIL and which and that goes beyond ITIL. I too have been doing ITSM since about 1982 (even though it wasn't called ITSM back then).

UKVIKING wrote:

Now, as to the CMDB being constantly updated.

There is a vast difference between an NMS tool which is keeping track / status - Real Time - on the status of each object within its scope and a CMDB

The CMDB is not an NMS tool. It is a reference tool. The data in there should not change as the service changes w/in a business day. That is pointless

I would add that this depends on the organization and the quality of the data they need for decision support/decision making. For example, a number of very large enterprises I've dealt with provide federated IT services to other like clients. An example is one very known financial institution (BlackRock) which not only provides IT to its own business but also packages and resells most of its IT solutions to other financial institutions that would rather buy their IT than build it and maintain it from scratch. Enterprises like these require and demand better data (often real time) for better decision making and decision support. As a result, NMS results do, in fact, make it into their versions of CMDBs because such data is important to them. However, I would also agree that not all enterprises would require this and could probably get by without it.

UKVIKING wrote:

The IM and PM tools should be linked to or as part of the CMDB or verse vica

Unless, of course, you know how to build your own (and can justify doing so) where all are in one system, as we did for a major financial institution that wanted such a solution. Remember, if you can reduce the costs and complexities of three systems, down to one, and do so without sacrificing quality and satisfaction, why not do so? The reality is that most people don't know how to do this and simply resort to buying other tools.

Also, if you start to evolve beyond ITIL, you start to realize that the CMDB can also have Business Services and CIs as well as IT constructs and CIs, since the Business requires such tools as well. (Having two such tools, one for IT and one for the Business is rarely smart when, in fact, they can be combined into one.)

[Evolving "beyond ITIL"? ITIL is not sufficiently tangible (except where mis-applied) and does not set any markers (except where misunderstood).]

The situation is not quite so clear cut as that. Yes it is possible that a business could benefit from an integrated solution. But it is unlikely. It is not possible to get away from the diversity of purposes it would have to serve. IT People have been dreaming of the universal solution since Cullinane (or perhaps since Einstein, but that is another matter ). However different parts of any large organization have different needs, have different pace of change, have a potential to diverge from one another and come together in unpredictable ways.

The issue that IT people have underestimated is that all these differences are around human behaviour and not machines. They are about the setting of goals and policies, they are about responding in a human way to (in part unpredictable) outside change. The smaller an organization is and the less complex its functions (if you like the less diverse its product range) and the more integrated all its activities are by their nature, then the easier it is to achieve the universal solution.

The software, once developed is never sufficiently universal if it is sufficiently usable. The solution, if implemented is never sufficiently versatile and responsive and it makes it more difficult to disentangle functional parts of the organization which can be important in the case of mergers and hiving off of areas externally as well as internally.

Creating links is one thing, integrating is another. The necessity of the IT service's CMDB delivering the capability of IT service configuration management has to take precedence over any other demands. and this would be equally true of other of the organization.

I'd better stop. I was interrupted and lost my thread. I cannot back what I say with hard evidence, but my experience suggests it very strongly.

Let me qualify that last remark. The fact that so many organizations seem to want ITIL to be a comfortable coat to wrap around them (when all along treating it like that makes it more of a straitjacket), is suggestive of how far we are from being able to achieve a universal solution._________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

Yes, ITIL is about IT Service Management but it is about better practices in doing IT Service Management.

You dont do ITIL. You dont implement ITIL. You dont apply ITIL.

You use better (best) practice guides - ie ITIL and standards ie ISO27001 or ISO 20000 - in order to make your IT Service Management processes well managed and well organized

You can do IT Service Management without ever seeing a book on ITIL or CoBIT or ISO2000.

All IT SM is managing the IT environment for the business

1982 is either Mainframe - which is where ITIL comes from in the initial version - Diarmid was around when dinosaurs rules - VAXs and all that
or
VAX / PDP-11 / Crays which I played with in '83 and '84 as well as the ARPAnet.

So even then IT SM was being done - managing the PSN, TAC,s, PADs, and the various telco connections - without ever hearing of ITIL

The CMDB was a white board with magnetic stickers for the PSN and telco links

Query Point: why do you keep telling this forum.,, about solution you sold to customers... frankly it is irrelevent to this group. This is not a sales / marketing forum in any sense. It is irrelevent to the question as the question was not about CMDB products sold to a customer

I find the constant references to the sales you have made to be a bit ...._________________John Hardesty
ITSM Manager's Certificate (Red Badge)

Query Point: why do you keep telling this forum.,, about solution you sold to customers... frankly it is irrelevent to this group. This is not a sales / marketing forum in any sense. It is irrelevent to the question as the question was not about CMDB products sold to a customer

I find the constant references to the sales you have made to be a bit ....

Hi John,

This is simply because I've spent the better part of the last three decades providing Business and IT solutions to other enterprises. It's one thing to learn about ITSM by implementing it for yourself, to meet your own needs. It's very different learning about it by implementing it for others.

It's the broader exposure that's come from so many varying requirements that allows realizations that the ITIL books don't appear to handle or teach people about things like...
- Business Interaction Management Systems, which are growing in importance, are very similar to and can be the same as IT CMDBs, and
- Business Service Catalogs are as important (if not more important than) as IT Service Catalogs and they, too, can be combined, and
- Building a CMDB or a Service Catalog that cannot be used by the Business, directly, to solve their own needs as well as those of IT's, is often an injustice that leads to tremendous waste of funds, and
- CMDBs and Service Catalogs can also be combined, under the right circumstances, and
- When combining CMDBs and Service Catalogs, and allowing them to handle and be used by the Business as well as IT, you've constructed one of the most powerful Knowledge Management constructs in an enterprise (which is often overlooked by IT staff that doesn't get KM big pictures)

So, if I go into areas that sound very sales-like and that you're not familiar or comfortable with or that are not painted as "the right way" by ITIL, please understand that I am not trying to sell anything so much as I am trying to expand the limits of the conversation to possibilities that go beyond conventional norms. I've been fortunate enough that my personal experiences have allowed me to see and be a part of such solutions.

To many who haven't seen these things or who are religious about frameworks such as ITIL, what I talk about comes across as too complicated to achieve or even worse... as heresy. However, I've been a part of designing and delivering such solutions so I know they can truly exist.

As for too sales-like, if you'd like me to get into details, we can always get into how traditional relational modeling of data entities doesn't scale nearly as well as semantic data models for things like the implementation of, both, CMDBs and Service Catalogs. Or, we can talk about how to lay out data models to leverage powerful visualization technologies like D3.js to advance your CMDBs and Service Catalogs to levels that most enterprises can't dream of. If you don't like "salesy," trust me, I can go as deep into the technical details as you'd like.

I would prefer that if you are going use my name in this forum I get a name from you so I am talking to a person

Not some nameless dog on the internet.... obtuse reference...

As for Implementing IT SM...

Let's see

1984 - 1987 - ARPAnet / Milnet (Pac side)
1999 - 2012 - DI. C&W DI, C&W, BUPA, BT for client and now the company I work for- working with two different outsourced vendors

Been there, done that got the tshirt and it is faded

So now that you and I have shown that we (and Diarmid) piss from great heights, can you now cease with the continual validations

A CMDB is important - we all agree
The entry of data should be controlled and managed - we all agree

The issue where I think I and most likely Diarmid agree and disagree with your premise is that the CMDB is all things to all people whom are using it.

The problem as Diarmid stated is that we are working with different departments, teams and individuals and well as either an internally delivered service or an external delivered service

A single answer is never going to meet all of every dept requirements

The IT Department and the teams that manage the IT Services should gain themost benefit from the CMDB and from Configuration Management - which is a lot more than the CMDB_________________John Hardesty
ITSM Manager's Certificate (Red Badge)

Sorry for the delay in the response. I kept getting distracted before being able to finish and finally hit "submit"...

Diarmid wrote:

IF4IT wrote:

Also, if you start to evolve beyond ITIL, you start to realize that the CMDB can also have Business Services and CIs as well as IT constructs and CIs, since the Business requires such tools as well. (Having two such tools, one for IT and one for the Business is rarely smart when, in fact, they can be combined into one.)

[Evolving "beyond ITIL"? ITIL is not sufficiently tangible (except where mis-applied) and does not set any markers (except where misunderstood).]

The situation is not quite so clear cut as that. Yes it is possible that a business could benefit from an integrated solution. But it is unlikely. It is not possible to get away from the diversity of purposes it would have to serve. IT People have been dreaming of the universal solution since Cullinane (or perhaps since Einstein, but that is another matter ). However different parts of any large organization have different needs, have different pace of change, have a potential to diverge from one another and come together in unpredictable ways.

Actually, I would like to respectfully disagree with this. I've been a part of solutions that have been "collapsed together" to benefit, both, business and IT. For example, there is absolutely no logical or technical reason that the Business Service Catalog and the IT Service Catalog cannot co-exist. And, there is no logical or technical reason that the CMDB and the Service Catalog cannot be "collapsed together". The most common excuses I've heard for not collapsing such solutions together revolved around the designer's/implementer's lack of understanding of how and why to do so, leaving themselves to be manipulated by vendors, into buying and implementing very limited and unscalable point solutions.

In my experience, I've found that if people supply a vendor with the requirements that "we must be able to provide for, both, Business and IT services in one catalog," they will work to make that happen. However, if people supply a vendor with only the requirement to "handle only IT services in an IT-only Service Catalog," the vendor will only go so far to make that sale, yielding a limited solution. The issue seems to revolve around the requirements providers not providing broad enough requirements that think of their Business(es) as well as themselves (IT). When we do things like collapse the two, it is my opinion that we bring IT and the Business closer together, further aligning them and, ultimately, bridging that gap that so often yields in Businesses not liking their IT organizations. Again, this all just my opinion, based on my own experiences.

Diarmid wrote:

The issue that IT people have underestimated is that all these differences are around human behaviour and not machines. They are about the setting of goals and policies, they are about responding in a human way to (in part unpredictable) outside change. The smaller an organization is and the less complex its functions (if you like the less diverse its product range) and the more integrated all its activities are by their nature, then the easier it is to achieve the universal solution.

I totally agree with this and I like that you migrate to the example of how roles and responsibilities blur as enterprises get smaller, where one person is often responsible for far more cross functional activities than in a much larger enterprise. This is the example that, in my opinion, always highlights and forces acknowledgement of the "common sense" aspect of things.

Diarmid wrote:

Creating links is one thing, integrating is another. The necessity of the IT service's CMDB delivering the capability of IT service configuration management has to take precedence over any other demands. and this would be equally true of other of the organization.

I don't know that I agree with the statement that "the capability of IT service configuration management has to take precedence over any other demands." It is my experience and my opinion that the Business' needs "always" outweigh the needs and especially the desires of IT. I believe it is when the IT organization goes off in its own direction, taking into consideration its own needs before its Business' needs, that IT becomes slower, costlier, and of a lower quality.

Diarmid wrote:

The fact that so many organizations seem to want ITIL to be a comfortable coat to wrap around them (when all along treating it like that makes it more of a straitjacket), is suggestive of how far we are from being able to achieve a universal solution.

I would prefer that if you are going use my name in this forum I get a name from you so I am talking to a person

Not some nameless dog on the internet.... obtuse reference...

Putting your name out for use by others is a choice you made. Criticizing others for using your name, which you granted freely, seems a bit dramatic, don't you think? You could have simply asked in a friendly and professional tone, as I would gladly comply. My name is Frank.

UKVIKING wrote:

A CMDB is important - we all agree
The entry of data should be controlled and managed - we all agree

The issue where I think I and most likely Diarmid agree and disagree with your premise is that the CMDB is all things to all people whom are using it.

The problem as Diarmid stated is that we are working with different departments, teams and individuals and well as either an internally delivered service or an external delivered service

A single answer is never going to meet all of every dept requirements

The IT Department and the teams that manage the IT Services should gain themost benefit from the CMDB and from Configuration Management - which is a lot more than the CMDB

I respectfully disagree that, in the case of a CMDB, a single answer cannot meet the needs of all stakeholders. I believe this has to do with how the CMDB is designed, delivered, and managed.

As is often the case, many IT professionals think only of themselves and of their own organizations, when it comes to the needs and desires that they're trying to deliver solutions for. As a result, we get a proliferation of unnecessary systems that are "half baked" in nature. In addition to thinking only of themselves, I find that most designers and deliverers of CMDBs tend to be infrastructure people who have very limited experience designing and building enterprise wide applications that could, in fact, solve bigger problems.

Very simply, the purpose of the CMDB is to hold details about specific things and to show the relationships between those things and other things. There is nothing in such a definition that limits the solution to just IT things.

Also, business leaders who own and/or run the businesses that IT professionals work for will tell you that it is the purpose of IT professionals to serve their businesses before they serve themselves (this is contrary to the opinions of many IT professionals). And, it is these very same business leaders that will publicly denounce IT when they see that IT goes off and does things in very limited ways. I, therefore, believe that it becomes the responsibility of IT professionals to implement solutions that reduce the great divide between IT and its Business(es), rather than implementing solutions that increase the divide.

My experiences show me that those who argue for IT only solutions usually have very limited insight into the bigger picture of an enterprise's needs and limited insight into how to provide solutions that meet the needs of a wider audience, with one solution. I believe that we, as IT professionals, should "always" strive for solutions that offer economies of scale and meet as many needs as possible, not just our own. However, this is my opinion and you don't need to agree with it.

I know we disagree on the above so let's not quibble on the topic and just agree to disagree.