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: NBonilla
New Today: 8
New Yesterday: 70
Overall: 142373

People Online:
Visitors: 81
Members: 2
Total: 83 .

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 - Unique Service Environment - How to Build CMDB
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Unique Service Environment - How to Build CMDB

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


Joined: Jan 27, 2009
Posts: 5

PostPosted: Wed Jan 28, 2009 12:51 am    Post subject: Unique Service Environment - How to Build CMDB Reply with quote

I apologize in advance for the length of this original post:

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


Joined: Sep 16, 2006
Posts: 3300
Location: London, UK

PostPosted: Wed Jan 28, 2009 1:51 am    Post subject: Reply with quote

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

The drill down should be

network -> org -> hosting solution -> hosting type service
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Sittler27
Newbie
Newbie


Joined: Jan 27, 2009
Posts: 5

PostPosted: Fri Jan 30, 2009 1:02 am    Post subject: Reply with quote

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


Joined: Sep 16, 2006
Posts: 3300
Location: London, UK

PostPosted: Fri Jan 30, 2009 2:27 am    Post subject: Reply with quote

IT Depends on how the services are packaged to the customer - which is a sales / marketing responsibility and

how the service is packages by the development team of that service,

how the service is to be supported as noted by the development team for that service

how the service is ACTUALLY supported by production... which most of the time the dev team/marketign /sales team forgets to include in the 2 above

The important one is the last one
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Sittler27
Newbie
Newbie


Joined: Jan 27, 2009
Posts: 5

PostPosted: Sun Feb 01, 2009 11:58 am    Post subject: Reply with quote

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


Joined: Sep 16, 2006
Posts: 3300
Location: London, UK

PostPosted: Sun Feb 01, 2009 9:16 pm    Post subject: Reply with quote

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)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Sittler27
Newbie
Newbie


Joined: Jan 27, 2009
Posts: 5

PostPosted: Tue Feb 03, 2009 11:06 am    Post subject: Reply with quote

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


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Tue Feb 03, 2009 4:58 pm    Post subject: Reply with quote

Sittler27,

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
Back to top
View user's profile Send e-mail
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3300
Location: London, UK

PostPosted: Tue Feb 03, 2009 6:53 pm    Post subject: Reply with quote

Sittler27

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)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Sittler27
Newbie
Newbie


Joined: Jan 27, 2009
Posts: 5

PostPosted: Tue Feb 24, 2009 11:54 am    Post subject: Reply with quote

Thanks very much for both of your comments.

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:


IP Endpoints - physical CIs (top of the hour-glass)
Site Specific Hosted Services (email, portal functionality, specific application data) - logical CIs that are dependent upon the network router
Site Specific Network Connecton Types (Basic, Internet, Special Connections) - logical CIs
Site Specific Routers - physical CIs, but act as logical CI representations of the sites
Network Connectivity Business Service (middle of the hour glass)
Applications (OS, Exchange, etc.) - physical CIs
Internal Network Switches - physical CIs
Internal Hosted Service physical servers - physical CIs
Internal Hosted Service physical server components - physical CIs (bottom of the hour glass)
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3300
Location: London, UK

PostPosted: Tue Feb 24, 2009 9:17 pm    Post subject: Reply with quote

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)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
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.