Sunday, November 21, 2010

Inventory, Data, and the Unicorn.

Managing the data center inventory for a large corporation is no small task. There are many questions that have been asked, are asked, and will be asked regarding the equipment and many times the person asking questions will throw you a curve. Some common questions that should be easy to answer are:
  • How many systems do you have?
  • How many are deployed and how many in inventory?
  • What OS are deployed?
  • What is the break down by manufacture?
  • What is the warranty on the systems?
  • Who is responsible for the systems?
  • How much is the equipment worth?
Now there are many more but these are very common and something any inventory system should be able to answer.

So what is missing from this? It has been my experience that there is the once a year or maybe even twice a year question that gets asked. This question seems to change every year so it's a little hard to predict exactly what they will ask for this year. One year Finance may ask about the value of equipment? Next year they may ask what is the value and depreciation of the equipment? Other years they may just ask for the list of equipment and the purchase order they came in on?

Now you might reasonably ask, "Why are they asking me, they sign the PO and track the orders don't they?" Well first smack your self and realize you don't think like a Finance person. They have pieces of information, not all information. In many cases they lack the expertise to know the difference between a Linksys router you use in the branch office and the Cisco 4000 you use at your HQ. They simply know how much they cost and when it was purchased. Add to this they may have some arbitrary amount that they consider to be a capital asset where as the usage you may have for an item is a little more laissez-faire.

Take the gbic for example. You will most likely use it in one system and probably purchased it with that switch. However three years later the switch has lived it's glorious life and is being decommissioned. However it's 10Gb gbic is still good and you need it for another machine.  Now you may quite reasonably think you can just take it and move it to another system. It's still a usable part and can fix a problem you currently have. Finance on the other had has different ideas. For them the gbic may still have monetary value and still be considered a capital good. It's where abouts has impact on them and they only have record of the equipment it was first purchased with. The equipment you are putting it in has a value in their records. By you moving that gbic from equipment A to equipment B you have now devalued A and increased the value of B. Your little equipment move no longer seems so simple.

Finance isn't the only group with this problem. Your operations team has a set of information they want to know. Managers have information they want and there may be other teams that need information. In my organization Network and System's used to be all together but now they are distinct groups. Each group's has different bits of information they want to tie to an asset and that is where all the fun begins.

Incoming!
Quote: "Captain, we're receiving two hundred and eighty-five thousand hails" -- Lt. Wesley Crusher (Parallels)

For ever group their could be 5 requests. Each of the 5 requests may require data from 5 different places. 5x5x5 = 125 Unique queries. In short that is a lot of data to juggle. That of course is a low number considering I have already provided more than five questions earlier. Add in the variants on those questions and new questions and your query begins to sprawl. So what are you to do?

ITIL offers us some hope in the Change Management Database (CMDB), however it is my understanding that many people confuse a CMDB for being the holder of all good information in all it's glory. Truth is ITIL calls for federating the data in large data sets. To put it simply there is to much data for one system to adequately hold it all. Instead you need to link multiple databases where the CMDB contains some data but not all data.

This is done so as to simplify the data for it's respective members. The idea being that Finance has a record of it's data and can easily go out and gather additional information from other systems, either by finding it in the CMDB or the CMDB telling them where they can find more data. Meanwhile the Service Desk can retrieve information from different information pools in the same manor. The Service Desk may not care how much the equipment cost and it's depreciation rate but they may care about when it was purchased and received.

Great in Theory
Quote: Now I will believe that there are unicorns...
--William Shakespeare--
(The Tempest)

A federated database that tells you where everything is, everything you wanted to know and things you didn't want to know, why this is a grand idea! And then I woke up. I have seen many vendors attempt to make this grandiose dream of data jubilee come true but I have never seen such a wonder. HP, IBM, they get pretty close, if you are an HP and IBM shop and drink their kool-aid you can come very close to this dream, but we are not a pure HP, IBM, Dell, Oracle, ACME, shop. Many places are not bound to one vendor and their in lies the problem. How does one federate what so many applications keep hidden?

I would like to think that the Open Source Community can tackle this but I'm not sure if the heart or even the thought is there. Various asset tools try to gather information regarding hardware but you still run into the same issue of linking data with Finance and Service Desk applications (or other groups for that matter). You need to have your data accessible and as it stands every vendor has their own idea of accessible. Where is the W3 of data interoperability? Where is the IEEE of data transport?

I'll tell you where! It's right next to the unicorn and the pink elephant.