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: ACrofts
New Today: 21
New Yesterday: 54
Overall: 146234

People Online:
Visitors: 57
Members: 1
Total: 58 .

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 - CMDB - Custom Software - How many CIs?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CMDB - Custom Software - How many CIs?

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


Joined: Mar 25, 2008
Posts: 2
Location: Norcross, GA

PostPosted: Tue Mar 25, 2008 11:03 pm    Post subject: CMDB - Custom Software - How many CIs? Reply with quote

My company is in the software business. We develop software for Financial Institutions. We host many of the applications we develop.

The question is how many CIs should I have for a product?
My user community is wanting to confirm that setting up the CIs in the fashion we are proposing is a strategy that is being used by others.

For Product X here is what I am proposing:

CI 1: Product X (this is the CI that is connected to the client that has purchased this product)

We have mutliple environments - production, certification (where we test with external clients), lab (for performance/stress testing), beta, and alpha.

I have proposed that for each of these enviornments we have 1 or multiple CIs for product X. (At this time we are not creating CIs down to the module, API, etc level.)

At some point in the not too distant future we will be doing automated discovery using CA's Cohesion product. When we do that it is going to create CIs for every instance of the software. So, if I have it on 12 servers in a cluster - then I'm going to get 12 CIs. The name will be unique because it will include the server name.

Does anyone have any thoughts, questions or suggestions about this strategy?

Thanks,
Jan
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Tue Mar 25, 2008 11:41 pm    Post subject: Reply with quote

the simple answer and the favourite ITIL one

is

a ) it depends

b ) answering the question in any detail constitutes consulting. My rate by text is ###/###

c ) what ever the company wants - see a

===============================================

It all depends on how the database is built and how the company tracks things like this

for example

if you are concerned about o/s on servers, then you would have 1 CI for each O/S

Then each server would be linked to the appropriate O/S using a many to one relationship many servers and 1 O/S. The Server would hold the licence key for the specific server

Same would apply to patches, service packs etc

Because of the relationship, I could get reports on the # of servers with a particular O/S as well as what are the licenses keys used for a O/S

as to your last point on auto discovery tools, there are a lot of comments in this forum about the appropriate use of autodiscovery tools.

I personally think they are a waste of space. The use of A/D tools allows the technical type to abrogate their collective responsibility of proper documentation by saying things like - hey i dont need to document the s/w on this bulid.. because the autodiscovery tool ....

I see a use for tools like Autodiscovery as AUDIT & verification tools not as data populator. I prefer to use organic - carbon based - programmable units to do the data population - the unix types gather the unix data and make sure the cmdb data is valid etc
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Mark-OLoughlin
Senior Itiler


Joined: Oct 12, 2007
Posts: 306
Location: Ireland

PostPosted: Wed Mar 26, 2008 8:56 pm    Post subject: Reply with quote

Hi,

what you need to ask is

What CI's do you want to record?
To What level do you want to go down to regarding relationships?

Simple Smile

That is it. The more CI's you record and the more relationships you want means proportionally more administration for one or more configuration manangers and librarians.

One other thing to think of - but don't let it drive your decisions, it what is your current tool or tool of chioce capable of in regards relationships etc.
_________________
Mark O'Loughlin
ITSM / ITIL Consultant
Back to top
View user's profile
Cotswolddave
Itiler


Joined: Mar 23, 2007
Posts: 35
Location: UK

PostPosted: Tue Apr 01, 2008 7:07 am    Post subject: Reply with quote

Hi Jan,

its a good set of questions as it shows many of the issues you will face when trying to document environments, not just services. For example

1. the autodiscovery software will maybe tell about software modules in detail, but you only need the overview of packages. It cannot determine whether something is live, it will depend on the category you allocate to the hardware platform or instance. The name it finds will be different to your CI naming as your CI is identified by adding the host name. So you will have to manually reconcile as per John Hardesty comment.

2. the CI name may be the same in each environment, but you have to have uniqueness for tracking (ie version no) so the use of grouping, types and categories will enable you to keep separate the production implementation on multiple platforms from test, dev etc.

3. Groupings of CIs may be held under a release CI so that you can easily identify the components of release 1.0, 1.1 etc. - all of which may exist differently in the environments. So the hardware, OS, middleware and application etc. may be different in dev, as opposed to test and production. So your approach to product X, X+1 etc. should work and enable traceability for circulation.

As per John, much more detail becomes a consulting issue as you have to design the data structures to suit the process needs - its the process and communication needs that ultimately will determine the requirements.

Dave
Back to top
View user's profile Visit poster's website
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.