A couple of years ago, we started discussing the commonalities among the many types of data center transformations (let's go with "DCT" after this) such as consolidation, relocation, replatforming, virtualization, DR activities, etc.

IT's a pattern: At approximately the same time we also happened to start discussing equivalence principles of CMDB/CMS architecture with those commonalities. What we found was pretty interesting: CMDBs and Discovery do a lot of the same things that tools used in data center transformations do! I'll save the "why?" for the end. Stay with me for a minute. What we found was:

All DCTs entail some type of comprehensive inventory / assessment phase. Hmm, auto-discovery does that. Also discovers dependencies. We'll get to that in a second. There are very messy parts of this phase that are often done poorly, inaccurately, and incompletely. For example, how do you collect data that isn't discoverable? How do you go ask 150 application owners for all they know about how their applications relate to your infrastructure. Riiiiight.

All DCTs involve some type of analysis, akin to application mapping, service modeling, sorting out your hardware, application platforms, rationalizing parts of the infrastructure, etc. A traditional term used for the output of these analyses are "move groups". Call them whatever you like. They're always there. Hmm, move groups are a lot like topology queries. And hmmm hmmmm, move group analysis is a LOT like defining application boundaries!

All DCTs incur major heavy lifting during the execution phase. Not only is there transformation activity, there is a doubling and redoubling of the analysis phase and even inventory phase. Why? Because time passes, change happens, and you don't shut down your data center for six months while these things are going on. So you have to re-analyze your move group right before you move. This generates a massive reporting effort, on the scale of thousands of reports over the lifetime of an average transformation. Hmmmm, CMDB is really good at generating reports (at least I hope yours is; if it isn't, please email jody.roberts@hp.com and I can help you)

A LOT of compliance and audit reporting. Is my target environment right. Is it compliant. Will it run my production without failing. Is it going to cost what I thought it would to operate it. Lots of reporting. Hmmmmm, CMDB has lots of that as well.

Transition to Operation - the transformation must have an end goal and at some point you have to switch on the target environment. Hmmm, back to that equivalence principle. Wouldn't it be great if we could leverage some of the knowledge about our infrastructure and apps we just learned, painfully, from that painful data center transformation we just did? Hmmmm, if you used a CMDB to do your transformation, you have it. Just like that.

What are the problems? The commonalities boiled down to four major problems amongst the five phases:

Move group analysis, turning "continents" into "islands".

Collecting unstructured data - gathering, managing, and reconciling human knowledge with all the other data required to do a transformation.

Identifying missing information - how to know when you're done, how to not leave anything behind.

Reporting. Huge, massive, killer problem. The kind of reporting that takes lots of time by highly-skilled persons.

We took action: As it turns out, the further we got into this, the more equivalence principles we found. So we wrote a paper on it. Then, we developed a solution to address the four major problems, with the help of many experienced people. I think it's going to work. In fact, we think data center transformations are one of the big waves of 2011 and beyond.

We're not in Kansas anymore: Cloud initiatives, virtualization, and environmental drivers are all expanding the use cases beyond what was once a small set of immutable forces. It's not just about being out of space or power, or merging an acquired company's data center anymore. It's about how IT moves forward with infrastructure and it's computing footprint on an ongoing basis.

Can you see it? You've got the tools and the talent to reduce risk, time, and cost to the point where a data center more or less continuously transforms itself. It's like we discovered smaller quanta. If it doesn't take a week and three top project managers to re-gen this month's move groups, why do we have to batch up all the moves themselves? Riiight - much more flexibility afforded to the transformation schedule itself, once you have the ability to generate your big-daddy move reports on demand, with a few keystrokes, within a minute or so. If you could automatically gather and relate human knowledge to your existing repository, seamlessly, how much would that be worth to your transformation project? How much would taming the reporting monster be worth?

Pitch warning: I don't want to sell or hype HP here - and I normally don't. So I apologize if this sounds like a pitch. But I'm tellin' ya, we've got something here with this idea. Come see us. Talk to us. If you're about to do a data center transformation, or you're currently experiencing/suffering from one, we'd be glad to help. The solution is called the "Data Center Transformations Accelerator for DDMA.".

Hi John, thanks for the comment. The current version of the paper is on the HP LiveNet in the UCMDB Community. We are in the process of updating it to the latest version of the DCT Accelerator package and will be publishing the updates in the coming weeks, possibly in 2010. If you are not licensed for UCMDB or DDM and you would still like to read the paper, please email me and I will send you an early copy.