Ehwotay!

After a refreshing few days off on holiday, its back to the grindstone.

Just about the first thing that happened after I had sat down at my desk, was that I received a phone call from a vendor we had spoken to just over a year ago. Tideway have an application dependency mapping product that looks like it might be quite useful in those situations where your development team has largely left and you're sitting looking at your infrastructure wondering what the heck all that smoke and mirrors is doing!

Tideway came in a year ago and spoke to us about their software then, but the requirement we thought we had wasn't really there on further inspection. Apparently their software has come on leaps and bounds and is even better and whizzier!

From the conversation, I think the biggest problem will be that it seems to overlap a great deal on systems that we already have: CMDB; performance monitoring (ish); etc. I’m not sure that it makes sense to consider linking them all, so it seems to me that if we were to use Tideway’s software correctly it means we’d have to consider giving up a number of pre-existing internal systems. And not using it properly would be a waste.

I guess a good question is what is a CMDB. It seems to be one of those useful marketing terms used to imply a good thing, but which is nebulous, yet a desirable tool. Such a wide diversity of tool claims to be or to have CMDB capability that the question is very valid.

You can always have a look at the wikipedia page on CMDB, although other than placing the blame for the term fairly and squarely at the feet of the UK's OGC the most remarkable aspect of this page is the reference to the excellent, cynical but completely realistic IT Skeptic site. I agree with a lot that this site outlines. The writer obviously bares a number of scars from having implemented CMDBs and other aspects of ITIL.

Having attained ITIL Foundation certification, a couple of years ago I have queried in private how practical some aspects are. It is so reassuring to discover that others are doing so too.

So, having said all that, I claimed my company had a CMDB.

What do we actually have? In a lot of ways it is very similar to a number of the products out there. Essentially a home brew system built as a Lotus Notes DB, every server should be listed, including:

General Info:

• Name
• Region
• Country
• Site

Equipment Inventory:

• Manufacturer/Model
• Server Serial
• OS
• Database software (if appropriate)
• Application

Purchase Details:

• PO Number
• PO Cost
• Purchase Date
• Asset Management record Number
• Supplier Details
• Asset Number
• OS LicenceApplication licence

Server Details:

• Manufacturer Type
• System Number
• BootProm rev
• IP Address
• RAM
• Server Type

Sub-System details:

• Type
• Make
• Model
• Model No
• S/N

Storage Configuration details:

• Disks, i.e. number & size
• Total Disk size
• Disk Partitions
• Disk Partition size
• Config i.e. RAID 0, 1, 0+1, 1+0, 4, 5, 5E, 5EE, etc
• Total Storage (GB) after Config
• Drive No
• Model
• Drive Capacity
• Drive Location
• Drive Mount Point

Graphics Device

• Make
• Model
• S/N

Operating System

• Make
• Type
• Patches

Network Cards

• Identifier
• Make
• Model
• MAC Address
• IP Address
• IPX Addresses

Applications

• Make
• Name
• Version
• Type

Maintenance

• Provider
• Start
• End
• Agreement

Support Record
Any Additional Information

• a free text area
• space for attachments
• Primary Contact Name
• Escalation Contact
• Support Queue

System Accounts - secured by a separate key

• Name
• Usage
• Password

Author
Date
Status: Active/Retired

• if retired, when

Of course, the majority of these fields are rarely documented!

What do we not have:

• sufficient application configuration information
• cross server relationship information
• cross application relationship information
  
• no auto-discovery
• ...

So its really an asset database!

So it goes!