CMDB - Custom Software - How many CIs?

[JanS]

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

[UKVIKING]

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

[Mark-OLoughlin]

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

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

[Cotswolddave]

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