Configuration Management Database

This post is focused on the current configurations of customer environments and the difference between what they actively manage (have agents on) and the total amount of computing resources in the Enterprise.

I worked for VMware for 2.5 years and have many stories about how many servers customers thought they had and how projects were aligned on a set of servers to find out they had more servers than they thought they had.

My point being, having a complete inventory of computing resources is a vital step to aligning the business needs with the IT support for any organization. As I reflect on the computing world as it progressed from the main frame days through the explosive growth of the distributed computing world to the proliferation of the Windows server world, it has amazed me the disconnect (in far too many cases, but not all cases) between the procurement process, the needs of the business (computing requirements) and the IT departments. I say departments because of the difference between the Windows and UNIX side of most companies.

I digressed, however my point being how many companies have a hardware and software (more on why both later) inventory of their IT resources. Note I did not say, IT department, but IT resources across the enterprise. With the proliferation of servers, there are department level servers running vital business process still sitting out there under desks and in closets that have been sealed up with drywall. You have all heard the stories.

So where do we start? There are three ways to collect inventory information.
1. Send an email to every one having them reply with the servers they know about or use
2. Use an agent based technology to report what they see (remember you have to pay for every agent so likely as not, there is not an agent on every box (think development, test and in the back corner of the warehouse)).
3. An agent less collection process where Lanman, IP discovery or manual importing can safely scan the environment for "every" computing resource in the enterprise.

Back to the need for a hardware and software inventory. The difference lies in a tactical (put out the fires) IT organization or a strategic (what do we have and how do we manage it better) oriented organization. I participated on a call with a customer who had delayed virtualizing their applications until their upgrade to Win2003 was completed. We ran an assessment on their servers and found 20 servers still running Win2000. We thought we were progressing with the virtualization project only to find out they still had 20 servers to upgrade and no budget for that extra workload. I use that analogy as the same holds true for organizations that are patching some of their servers but not knowing how many are truly out there, the patch project keeps going and going like the energizer bunny. Another analogy is the number of versions of software start to slow down the IT service organization for patch management, support and development and support of new projects on old servers.

Bottom line; having a current (and updated quarterly) hardware and software inventory for both physical and virtual computing resources is vital for any size organization to help focus on strategic IT initiatives aligned with proper cost and support.

Next discussion will focus on the growth of the processor speeds on the servers and how to match the technology to the business applications for right sizing.

Virtualization and Chargeback

The concept of chargeback in the computer industry has been around for years. The mainframe provided the worklevel smf records, which allowed reporting tools like CA's Job Accounting and Reporting (JARS) to divide up the records of which services were being used by which customers. The reporting allowed for summarization by resources used.

Fast forward to the current world where virtualization has become a commodity and everyone from managed services organizations to the "Cloud" are running some type of hypervisor. So I pose the question to the industry, what is the costing model for sharing a resource and how much is a customer expected to pay?

Also keep in mind that the number one rule for a charge back program is that the processs must be repeatable, meaning if I run the same data base query every night, the cost should be the same.

So with these initial concepts in place, it will be interesting to see the various chargeback models as they come to market and even more interesting will be the hypervisor vendors and what performance and usage records they will produce that will allow chargeback systems to be created and brought to market.

Next posting will be a list of charge back vendors and how they are getting the data.