November 12, 2008

Determining the CMDB scope (part 1 of 3)

Posted in CMDB tagged at 4:26 pm by Molly

Review the previous article I wrote about the definition of SCOPE to refresh yourself what scope actually means.

What does it mean to the CMDB?  The most important aspect of your CMDB is that information stored within it is accurate and up to date.  The second most important aspect is that you have relationships between your CIs. After all what is the point in just holding static information, you want your information to be related in someway so that you can either find out what the fault is or other investigation works like future planned upgrades or project works in your organisation.

Scope includes:-

  • What the potential contents of the CMDB will be;
  • Categories of objects and what kinds of relationships you will be able to capture between these categories;
  • Your database schema;
  • Some indication of the object classes that will be included in the CMDB.


Don’t overlook the CMDB relationships and associations. I would personally keep those separated out and review them again at a later stage.

We’ve just discussed what will be IN SCOPE for your CMDB, let’s have a look at what will be OUT OF SCOPE.

To give you a chance to think about the scope for yourselves, I’m not going to be writing long lists of what NEEDS to be included and excluded here, after all, each organisation is different, therefore each scope will be different in turn.  What I shall be jotting down for you are notes with question marks for you to go away and consider for yourselves, after all this is your project and I’m not getting paid to do your work:

Incident reports and change records – do they offer up any benefits for relationship modelling within your CMDB?  They are stored in the physical CMDB but are they going to be CIs?

Business continuity plans, DR plans, change back-out plans, roll-back plans? They are not CIs are they?

What about procedural documentation like how to perform a change in our organisation or a list of all software installed on a server or installation guides and technical specifications? Are they good CIs?  What does ITIL say?  Will these documents substantively help define your IT environment?

What about the relationship between a printer and a workstation, should you be making a relationship within our CMDB for this?  What if it is a network printer, or a roaming laptop or a pool laptop for that matter, are these items really going to be IN SCOPE for your CMDB?  What did I say about associations?

NOTE:  THINK CAREFULLY ABOUT THE ISSUES SURROUNDING THE SCOPE FOR DOCUMENTATION AND PAY CLOSE ATTENTION TO THE RELATIONSHIPS YOU WANT TO DEFINE IN YOUR SCOPE!

  • KEEP IT SIMPLE
  • PAY CLOSE CONSIDERATION TO THE COST OR COSTS
  • SCORE SOME EASY AND EARLY VICTORIES
  • DOES THE SCOPE CONTAIN BUSINESS VALUE
  • REDUCE YOUR RISKS
  • CONTINUOUS IMPROVEMENT
  • DOCUMENT THE CMDB SCOPE
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: