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: ciseedyexorse
New Today: 39
New Yesterday: 201
Overall: 130602

People Online:
Visitors: 47
Members: 0
Total: 47

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

Federated Configuration Management System

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


Joined: Jan 26, 2009
Posts: 26

PostPosted: Tue Feb 10, 2009 11:26 pm    Post subject: Federated Configuration Management System Reply with quote

When (if) using a federated Configuration Management System, where many CMDbs (or sub-systems) make up one overall system, is it a good idea 'configuration manage' the make-up of the Configuration Management System, or is this over complication?

E.g.

CMDb001 - Main Configuration Management System
CMDb002 - Quality Management System
CMDb003 - Definitive Hardware Store
Back to top
View user's profile
UrgentJensen
Senior Itiler


Joined: Feb 23, 2005
Posts: 458
Location: London

PostPosted: Tue Feb 10, 2009 11:31 pm    Post subject: Reply with quote

RT a CMDB is not above the law.

Approach it like you would any other system. Afterall you've got to be able to support it, right?

UJ
_________________
Did I just say that out loud?

(Beige badge)
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Wed Feb 11, 2009 12:01 am    Post subject: Reply with quote

RT

NOTE: SILLINESS ONE
What do you mean Federated... did a bunch of CMDB ceded and form their own nation w/constitution etc.....

The answer to the question as to the number of the DBs in a F CMDB is

//// mister owl
how many licks does it take to get to the center of the tootsie pop.

kid hands lollipop to owl

lick .... 1 lick .... 2

you fill in the rest

IT DEPENDS
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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


Joined: Jan 26, 2009
Posts: 26

PostPosted: Thu Feb 12, 2009 7:41 pm    Post subject: Reply with quote

UJ - Thanks for the confirmation. My main concern was whether the idea of managing the CMDb within the CMDb would be too much for some people, but they seem to have grasped the idea.

My other question is kind of at the other end of the scale; where managing the CMDb itself is the highest level, where do you draw the line at the lowest level?

Someone here at work suggested that a disk store should be considered part of the CMDb, but I suggested that raising an RFC to remove a disk, updating the log to say it has been removed, then raising an RFC to put it back, then updating the log again, was just creating an administrative nightmare. Instead we should just define procedure/rules for the use of the disk store, which would be used when completing other RFCs. The originator agreed with this suggestion.

But then this got me thinking that perhaps I'd been misinterpreting the Definitive Software Library and Definitive Hardware Store as CMDbs. Are these systems that should be configuration managed, or are they just repositories that are used in the configuration management of software/hardware?
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Thu Feb 12, 2009 8:56 pm    Post subject: Reply with quote

RT

My Uncle, a CPA (US) (Charted Accountant UK ?) once said

never spend a dollar chasign a penny

For a CMDB, the lowest level of detail should be what information is needed by whom, how the information is added, updated, who does it etc

For example

If you are tracking servers, what level of info is necessary to provide support

If you host the servers, then rack name/ID and place within the rack would be usually to the DC staff providing support
otherwise..... the only info you need to track/record/update about the server is where it is and who provides support (external hosting)

If you merely manage the applications, then all you need to know is the server name and who provides support for the system.

etc etc
_________________
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.