Limbering Up for a Data Center Makeover
Let's focus in on two major pillars of proper and successful data center transformation (DCT) projects and some proven methods that have aided productive and cost-efficient projects to reshape and modernize enterprise data centers.
Specific trends are buttressing the need for DCT. It's important to fully understand the current state of an organization's IT landscape and data center composition in order to then properly chart a strategy for transformation.
However, there are pitfalls that can be avoided by balancing long-term goals with short-term flexibility. The key is to know how to constantly evaluate based on metrics and to reassess execution plans as DCT projects unfold. This avoids being too rigidly aligned with long-term plans and roadmaps and potentially losing sight of how actual progress is being made -- or not.
This is the first in a series of podcasts on DCT best practices and is presented in conjunction with a complementary video series.
With us now to explain why DCT makes sense and how to go about it with lower risk, we are joined by Helen Tang, worldwide data center transformation lead for HP Enterprise Business; Mark Grindle, master business consultant at HP; and Bruce Randall, director of product marketing for project and portfolio management at HP. The discussion is moderated by Dana Gardner, principal analyst at Interarbor Solutions.
Listen to the podcast (27:31 minutes).
Here are some excerpts:
Helen Tang: We all know that in this day and age, the business demands innovation, and IT is really important, a racing engine for any business. However, there are a lot of external constraints. The economy is not getting any better. Budgets are very, very tight. They are dealing with IT sprawl, aging infrastructure, and are just very much weighed down by this decade of old assets that they've inherited.
So a lot of companies today have been looking to transform, but getting started is not always very easy. So HP decided to launch this HUB project, which is designed to be a resource engine for IT to feature a virtual library of videos, showcasing the best of HP, but more importantly, ideas for how to address these challenges. We as a team, decided to tackle it with a series that's aligned around some of the ways customers can approach addressing data centers, transforming them, and how to jump start their IT agility.
The five steps that we decided that as keys for the series would be the planning process, which is actually what we're discussing in this podcast: data center consolidation, as well as standardization; virtualization; data center automation; and last but not least, of course, security.
To make this video series more engaging, we hit on this idea of IT as superheroes, because we've all seen people, especially in this day and age, customers with the clean budget, whose IT team is really performing superhuman feats.
We thought we'd produce a series that's a bit more light-hearted than is usual for HP. So we added a superhero angle to the series. That's how we hit upon the name of "IT Superhero Secrets: Five Steps to Jump Start Your IT Agility." Hopefully, this is going to be one of the little things that can contribute to this great process of data center modernizing right now, which is a key trend.
With us today are two of these experts that we're going to feature in Episode 1. And to find these videos, you go to hp.com/go/thehub.
Dana Gardner: Mark, you've been doing this for quite some time and have learned a lot along the way. Tell us why having a solid understanding of where you are in the present puts you in a position to better execute on your plans for the future.
Mark Grindle: There certainly are a lot of great reasons to start transformation now.
But as you said, the key to starting any kind of major initiative, whether it's transformation, data center consolidation, or any of these great things like virtualization, technology refresh that will help you improve your environment, improve the service to your customers and reduce costs, which is what this is all about, is to understand where you are today.
Most companies out there with the economic pressures and technology changes that have gone on have done a lot to go after the proverbial low-hanging fruit. But now it's important to understand where you are today, so that you can build the right plan for maximizing value the fastest and in the best way.
When we talk about understanding where you are today, there are a few things that jump to mind. How many servers do I have? How much storage do I have? What are the operating system levels and the versions that I'm at? How many desktops do I have? People really think about that kind of physical inventory and they try to manage it. They try to understand it, sometimes more successfully and other times less successfully.
But there's a lot more to understanding where you are today. Understanding that physical inventory is critical to what you need to understand to go forward, and most people have a lot of tools out there already to do that. I should mention that those of you who don't have tools that can get that physical inventory, it's important that you do.
I've found so many times when I go into environments that they think they have a good understanding of what they have physically, and a lot of times they do, but rarely is that accurate. Manual processes just can't keep things as accurate or as current as you really need, when you start trying to baseline your environment so that you can track and measure your progress and value.
Of course, beyond the physical portions of your inventory, you'd better start thinking about your applications. What are your applications. What language are they written in? Are those traditional or supportable commercial-off-the-shelf (COTS) type applications? Are they homegrown? That's going to make a big difference in how you move forward.
And of course, what does your financial landscape look like? What's going in the operating expense? What's your capital expense? How is it allocated out, and by the way, is it consistently allocated out.
I've run into a lot of issues where a business unit in the United States has put certain items into an operating expense bucket. In another country or a sub-business unit or another business unit, they're tracking things differently in where they put network cost or where they put people cost or where they put services. So it's not only important to understand where your money is allocated, but what's in those buckets, so that you can track the progress.
Then, you get into things like people. As you start looking at transformation, a big part of transformation is not just the cost savings that may come about through being able to redeploy your people, but it's also from making sure that you have the right skill set.
If you don't really understand how many people you have today, what roles and what functions they're performing, it's going to become really challenging to understand what kind of retraining, reeducation, or redeployment you're going to do in the future as the needs and the requirements and the skills change.
You transform, as you level out your application landscape, as you consolidate your databases, as you virtualize your servers, as you use more storage carrying all those great technology. That's going to make a big difference in how your team, your IT organization runs the operations. You really need to understand where they are, so you can properly prepare them for that future space that they want to get into.
So understanding where you are, understanding all those aspects of it are going be the only ways to understand what you have to do to get you in a state. As was mentioned earlier, you know the metrics of measurement to track your progress. Are you realizing the value, the saving, the benefit to your company that you initially used or justified transformation?
Gardner: Mark, I had a thought when you were talking. We're not just going from physical to physical. A lot of DCT projects now are making that leap from largely physical to increasingly virtual. And that is across many different aspects of virtualization, not just server virtualization.
Is there a specific requirement to know your physical landscape better to make that leap successfully? Is there anything about moving toward a more virtualized future that adds an added emphasis to this need to have a really strong sense of your present state?
Grindle: You're absolutely right on with that. A lot of people have server counts -- I've got a thousand of these, a hundred of those, 50 of those types of things. But understanding the more detailed measurements around those, how much memory is being utilized by each server, how much CPU or processor is being utilized by each server, what do the I/Os look like, the network connectivity, are the kind of inventory items that are going to allow you to virtualize.
I talk to people and they say, "I've got a 5:1 or a 10:1 or a 15:1 virtualization ratio, meaning that you have 15 physical servers and then you're able to talk to one. But if you really understand what your environment is today, how it runs, and the performance characteristics of your environment today, there are environments out there that are achieving much higher virtualization ratios -- 30:1, 40:1, 50:1. We've seen a couple that are in the 60 and 70:1.
Of course, that just says that initially they weren't really using their assets as well as they could have been. But again, it comes back to understanding your baseline, which allows you to plan out what your end state is going to look like.
If you don't have that data, if you don't have that information, naturally you've got to be a little more conservative in your solutions, as you don't want to negatively impact the business of the customers. If you understand a little bit better, you can achieve greater savings, greater benefits.
Remember, this is all about freeing up money that your business can use elsewhere to help your business grow, to provide better service to those customers, and to make IT more of a partner, rather than just a service purely for the business organization.
Gardner: So it sounds as if measuring your current state isn't just measuring what you have, but measuring some of the components and services you have physically in order to be able to move meaningfully and efficiently to virtualization. It's really a different way to measure things, isn't it?
Grindle: Absolutely. And it's not a one-time event. To start out in the field -- whether transformation is right for you and what your transformations look like -- you can do that one-time inventory, that one-time collection of performance information. But it's really going to be an ongoing process.
The more data you have, the better you're going to be able to figure out your end-state solution, and the more benefit you're going to achieve out of that end state. Plus, as I mentioned earlier, the environment changes, and you've got to constantly keep on top of it and track it.
You mentioned that a lot of people are going towards virtualization. That becomes an even bigger problem. At least when you're standing up a physical server today, people complain about how long it takes in a lot of organizations, but there are a lot of checks and balances. You've got to order that physical hardware. You've got to install the hardware. You've got to justify it. It's got to be loaded up with software. It's got to be connected to the network.
A virtualized environment can be stood up in minutes. So if you're not tracking that on an ongoing basis, that's even worse.
Gardner: Bruce, you've been looking at the need for being flexible in order to be successful, even as you've got a long-term roadmap ahead of you. Perhaps you could fill us in on why it's important to evaluate along the way and not be even blinded by long-term goals, but keep balancing and reassessing along the way?
Bruce Randall: That goes along with what Mark was just saying about the infrastructure components, how these things are constantly changing, and there has to be a process to account for all of the changes that occur.
If you're looking at a transformation process, it really is a process. It's not a one-time event that occurs over a length of time. Just like any other big program or project that you may be managing you have to plan not only at the beginning of that transformation, but also in the middle and even sometimes in the end of these big transformation projects.
If you think about these things that may change throughout that transformation, one is people. You have people that come. You have people that are leaving for whatever reason. You have people that are reassigned to other roles or take roles that they wanted to do outside of the transformation project. The company strategy may even change, and in fact, in this economy, probably will most likely within the course of the transformation project.
The money situation will most likely change. Maybe you've had a certain amount of budget when you started the transformation. You counted on that budget to be able to use it all, and then things change. Maybe it goes up. Maybe it goes down, but most likely, things do change. The infrastructure as Mark pointed to is constantly in flux.
So even though you might have gotten a good steady state of what the infrastructure looked like when you started your transformation project, that does change as well. And then there's the application portfolio. As we continue to run the business, we continue to add or enhance existing applications. The application portfolio changes and therefore the needs within the transformation.
Because of all of these changes occurring around you, there's a need to plan not only for contingencies to occur at the beginning of the process, but also to continue the planning process and update it as things change fairly consistently. What I've found over time, Dana, with various customers, as they are doing these transformation projects and they try to plan, that planning stage is not just the beginning, not just at the middle, and not just the one point. In other words, it makes the planning process go a lot better and it becomes a lot easier.
In fact, I was speaking with a customer the other day. We went to a baseball game together. It was a customer event, and I was surprised to see this particular customer there, because I knew it was their yearly planning cycle that was going on. I asked them about that, and they talked about the way that they had used our tools. The HP tool sets that they used had allowed them to literally do planning all the time. So they could attend a baseball game instead of attend the planning fire-drill.
So it wasn't a one-time event, and even if the business wanted a yearly planning view, they were able to produce that very, very easily, because they kept their current state and current plans up to date throughout the process.