I am new with an organization and am here to help them build a CMDB and implement Configuration Mgmt.

It has been identified to me early-on here that the service environment to be modelled in the CMDB is fairly unique, because rather than resembling a pyramid (service to IT components and subcomponents), it more resembles an hour-glass (services at the middle-part and infrastructure components on either side above and below)

In more detail, here is what has been described:

In most traditional IT environments, the geographic layout of CIs aids in the identification of how they would be modelled in a CMDB: traditionally with a pyramid type structure showing relationships extending down from upper-level business service offering CIs into various logical IT component set CIs, and finally deep into the physical IT components themselves.

With this organization, we simply provide network connectivity to various other organizations that use that network service to run hosted services. Some of those hosted services are either managed fully by us, or are black-box type server CIs.

The uniqueness factor comes into play in that beyond the physical components that we manage to the door of our client sites (router ports at the client site is the extent, with all infrastructure back to our raised floor), all infrastructure within the client sites (LAN/WAN) is not managed by us, HOWEVER some hosted services we provide and which users on the end-points in the WAN at the client sites use (through a portal, so no software on the desktop) is still our reponsibility to manage through ITSM.

How can this type of environment be accurately modelled in the CMDB, without needing to capture all of the LAN/WAN type components/relationships which are not our responsibliity to manage anyways, but yet capture into CIs the service components that represent that the end-user at the sites are using our services?

My hypothesis is that the fact that the geographic layout of CIs resembles an hour glass, when factoring service CIs, rather than a pyramid, as is traditionally represented in an organization, is irrelevant. This is because the CMDB models CIs based upon relationships, and not upon the geographic nature of the CIs (which you could still use location attributes to identify for each CI).

I would really appreciate some discussion on this and possibly some justification for my hypothesis.

This is no different to what I have seen in the companys that provide managed (mangled) hosting or network services as part of the package.

It is not a unique situation.

The CMDB should be oriented to the service that is provided or on how the relevent Service Desk / Resolution team would use the information

This is NOT an ITIL topic per se but a Database design topic

Please look at some of the previous posts

The core of the CMDB should be based on the statement

[color=darkred][b]we simply provide network connectivity to various other organizations that use that network service [/b][/color][/color]

Then there should be the statement

[color=darkblue][b]other organizations that use that network service to run hosted services. Some of those hosted services are either managed fully by us, or are black-box type server CIs. [/b][/color]

that is used to provide the relation ship between the network service you provide (service provider) to the service consumer( the organizations)

Then there is the hosting service that you are providing to the service consumers at the end of the stick - whether fully managed, or tin and power

So shoudn't hosted managed services be top-level business service offerings, with relationships that demonstrate that they are underpinned by a network IT Service Offering?

For example if two services we offer and manage are:
1. a web view into a database through a portal that shows data in an organized fashion via the application it runs on (let's call it DPV).
2. Email, again through a portal, with no actual desktop software installed.

Then, DPV and email would be Business Service Offering CIs at the upper-most level, with the network CI as an underpinning IT Service Offering underneath those two.

This would then allow some clients that use DPV and email to have CI relationships to those particular business service offerings, but other clients would not if they only used the network ISP type service offering. Thus, those other clients only using the network service would link to the IT Service Offering, but would show no business service offering.

Or, should the network CI also be a business service offering rather than just an underpinning IT service offering, with relationships to the other business service offerings on it's same level that show it as an underpinning CI.

Could you give me some examples of what you mean by the last point of "how the service is supported by production"?

In our organization, we provide the network service to a site, and many users use that network service to use hosted services (some hosted by us, others not by us, but still using our network service).

Thus, when a user experiences an issue on his/her desktop, they call their local help desk. That help desk then determines if it is something they can fix on their own, or if they need to call our service desk (if it's a network issue or if it's one of our hosted services).

So in this case, should we have a CI in the CMDB for each site (with associated contacts for each of those site CIs), and then relate them to the services they use (although this gets more complicated as not every client at that site uses the same services)?

OR, should we create a CI for each service at each site, thus allowing us to log incident records related to each service-site CI?

If your company is called about an incident on something that you support directly, yes there should be information in the CMDB about the service, the customers etc

If your company is called about an incident on something that you dont support, then the CMDB should not contain that information

for your example below, you are the service provider to the helpdesk that was called. That service desk is the service consumer of the network service that you provide. the fact that they use the service that you provide and provide a service to their users is NOT you concern. Nor is the service that is provided to you by the ISP, Telco or other companys that give you the ability to provide the network service_________________John Hardesty
ITSM Manager's Certificate (Red Badge)

Thanks for the reply. However, I was looking for an answer to specifically how to represent the structure as CIs in the CMDB.

Here's what we have now for CIs in the CMDB, cascading down through parent to child relationships:

1. Network (top-level business service offering)
2. Network Nodes (logical CIs representing the network circuit at a site)
3. Router, and/or Internet, and/or Basic (on this level, router is the physical CI, but internet or basic are also on this level as logical CIs identifying whether the site has internet access, just basic network connectivity, or some other special connectivity)
4. IP Endpoints (physical CIs, one for each IP address configured on the router

This describes the network CIs.

Then you have hosted service CIs, but they are represented as follows:
Service A-Site A
Service A-Site B, etc.
Service B-Site A
Service B-Site B, etc.

So we have numerous and redundant services listed as CIs. One for each site that uses it. Each of these hosted service CIs by site are related to the Network Node CI to represent the fact that that is what allows it to function.

This was all configured this way in the CMDB prior to me (new Configuration Manager) arriving on the scene.

I'm now proposing that we do away with this structure, and move to a more streamlined one as follows:
One CI for each service (no specific site information in those CIs)
One CI for each site (this would be an actual CI, and not just a site record in the tool, like Remedy)

Then, through the relationships we identify who uses what: that is, we relate all site CIs to the services they use.

Am I on the right path here or should I just continue to build upon what they have already created?

it is always difficult to comment on a small part of a system. It is important to know how the CMDB works, how it is used, how it is maintained, what its objectives are as well as seeing the structure.

Your proposal to streamline it is perfectly plausible and may well be sensible.

But the decision to go ahead has to be conducted like any other change; it must ultimately be based on cost and benefit and risk.

What problems emanate from the current structure? - does it lead to mistakes? delays? is it hard to maintain? will other processes have to be changed to stay in line?

What qualitative improvements will accrue from the change? - will processes be streamlined? more reliable? will the new design be more flexible? can you measure the effects?

What are the costs of the change? - design testing and implementation effort? training? maintenance?_________________"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

I can not provide detailed descriptions on how to relate the CIs in the CDMB. I dont know how your CMDB is arranged.

Things to take into consideration for the CIs are as follows

How will the SD identifiy the CI
what info is needed by the SD to link the CI to incidents etc
what supporting information is needed_________________John Hardesty
ITSM Manager's Certificate (Red Badge)

As my knowledge grows at this new organization, I want to share here with you what I have learned further about this environment so that I can continue to take reference from your knowledgeable comments and responses.

The CMDB should of course model the relevant service/physical components in the managed environment. As mentioned, we provide network connectivity to various sites, and manage hosted services that for those sites, but do not manage LAN/WANs of the sites, nor the desktop environments.

That being said, the service/physical components are geographically laid out like an hour-glass rather than a pyrimad (as in an more traditional IT server/client environment).
The middle part of the hour-glass is the service CIs (business services we offer), with the lower part being the back-end physical infrastructure (servers, internal network components, databases, etc.). This alone would form a more traditional pyramid shaped CMDB hiearchy, but we also have network components in the top part of the hour-glass. These are the routers that are at each client site, and their IP endpoints which provide various logical services.

The question is, how best is it to structure this "hour-glass" shaped CI level structure in the CMDB through traditional dependency and component type relationships?
As discussed above, is it really no different than any other managed service provider's CMDB? And if so, could someone give me an example of how it could be structured (just point me in the right direction).

To illustrate the "hour-glass", here is an example detailing the logical model:

The first issue about building the CMDB for your org is who will use it

If the 3rd party vendor and your company share responsibility for some CIs, services etc, then there needs to be a process/procedure on ensuring the shared data is verified together and updated together

the other issue is what services / CIs etc are being supported by you and in what manner_________________John Hardesty
ITSM Manager's Certificate (Red Badge)