IT for IT

By Sanjay Mirchandani

Senior VP and CIO at EMC

Sanjay Mirchandani
Sanjay Mirchandani, senior VP and CIO at EMC, says EMC uses its in-house environment to show how it wants to transform the larger IT landscape. Photograph by Kathleen Dooher

During the more than 20 years that I sold information technology, the top question prospective customers asked me when I went to them with a product idea or solution wasn't, "Is the product ready?" It was, "Does your company's own internal IT organization run it?"

Sometimes, I had to tell them "no." But when my answer was "yes," it made the value proposition credible and the discussion totally relevant.

As CIO, I no longer sell, and the people in my organization certainly avoid it, too. Yet we are frequently pulled into the sales process. To help, we've been formalizing a program to use EMC products in-house, including placing products into our IT environment well before they are finished.

Using your own gear is a long-standing practice in the IT world, of course. Paul Maritz, now VMware CEO, coined the famous phrase "eating one's own dogfood" back in 1988 at Microsoft. Still, at EMC, we are now formally instituting a program that seems counterintuitive, even risky: inserting not-ready products into an active production IT environment of a multibillion-dollar corporation.

We accept the risk with good reason. We want to help EMC build better products, and real-life use cases are important. Developers can observe how their product runs in a live data center. Our IT people, our customers, and our field organization can touch and feel the product before it ships.

That ability tends to get people pretty passionate about what EMC is building. It gives a salesperson, for example, a better perspective on what a customer scenario might be before meeting with a CIO to say, "Hey, this new product of ours could solve the issues you're having."

I know the method works. Whenever we investigate bringing a significant non-EMC technology into our data center, my leadership team and I tend to talk to the CIO of the company selling that product. We ask for a use case to establish its value. We tell them, "As long as we don't make the same mistakes you made, you've added value to our process." And that's what we're hoping to do for our own customers.

Introducing risk, but sensibly

EMC's IT team was part of the development of EMC SourceOne Email Management for Microsoft Exchangea product that was at least six months away from being ready when we got involved. The developers needed to test SourceOne in iterations, in a scalable environment, and we had 40,000 e-mail users. So we deliberately inserted into our mission-critical Exchange environment a product not fully baked.

By definition, we brought in risk. But our team did it sensibly, starting with small, isolated user groups. As the product became more stable, they went broader, without negatively affecting the business.

A product's roadmap shouldn't change because of us unless we find something really wrong. But in fact, Rick Devenuti, chief operating officer for the EMC division that built SourceOne, told us, "We won't ship until EMC IT tells us it's ready."

That was a bold, confident statement to make about the collective capabilities of a combined product-development and internal IT team that worked shoulder to shoulder, day and nightsometimes all nightrolling out builds to another 10,000 users and remaining until everything worked.

Giving developers a firsthand look

SourceOne shipped on time and is an exemplary product, I think, not only because of the rigorous in-house testing, but because of the information its developers absorbed in the process. Engineers who wanted a firsthand look at their product running in a data center merely swiped a badge, walked in, talked to our people, and studied the product as it operated. I can't put a dollar value on how much added quality resulted from EMC's early adoption of SourceOne, but I know it is huge.

We're not doing this for every EMC product, and not all early-adoption ventures are months-long events. For example, when we incorporate a pre-GA point solution, it may simply involve a team of four people working, albeit hard, for a couple of weeks.

But in every instance, the use case must apply to us. We are a big enterprise IT shop, so EMC's consumer-focused storage and backup offerings don't suit us. Large-scale virtualization, on the other hand, can bring obvious cost benefits to our environment. That's why we are using, and are looking forward to using, just about every VMware virtualization product. Proofs of concept, lab tests, controlled user-environment testswe're doing it all.

Our goal is to have our x86-based environment 100 percent virtualized by early 2010. In parallel, we'll serve up desktops in a virtual environment, dramatically changing our cost-of-ownership equation. We're on the cusp of some big strides.

Helping products "walk before they run"

I don't have a large organization to devote to testing products. We opt out sometimes. But if a development group is having trouble finding a ready-made install-base of customers, or if EMC needs very early input from (or for) its sales organization, or if the product is a game-changing, business transformational technology, we help if asked. We did it for Enterprise Flash drives; we're an early adopter of RSA Security technologies, too.

Among RSA, Ionix, Documentum, VMware, EMC storage, and beyond, we already have plans to engage ourselves with many unreleased, pre-beta products that fit our use case. We want to help these products walk before they run.

The value of touching customers

Having spoken to many CIOs of large enterprises, I'm fairly sure that our data center closely resembles what a lot of them are dealing with every day. With our ambitious timetable for virtualizing our x86 IT infrastructure, we showcase our in-house environment as an embodiment of how EMC, the information infrastructure vendor, wants to transform the larger landscape.

It's what my leadership team and I affectionately call "IT for IT," and it is what we consider to be a central responsibility of the IT organization of an IT company. The bar is set high for us, to respectfully and humbly add value beyond, obviously, keeping EMC's IT infrastructure running nicely.

We have a good day when we've touched a customer and shared something with them. I'm proud to say that every member of my leadership team touches one or two customers daily. It's VP of Infrastructure to VP of Infrastructure. VP of Applications to VP of Applications.

They simply share what they do. Sales reps aren't in the room. Again, I don't make sales pitches anymore, and neither does my team. We are strictly about how we run IT and about helping other IT organizations be more efficient. We use EMC products because we have actual, valid use cases for having them in our shop, not because we "must" use them as EMC's IT organization. (In fact, we pay for all of our products, including our storage platforms.)

Driving the car for 100,000 miles

Folding an unproven technology into a production environment is much like assembling and test-driving a car. It is another job entirely to drive that car for 100,000 miles and watch how it holds up, or to stress the car by switching to a different motor oil or gasoline. Doing the IT equivalent, we don't just test products pre-GA; we continue to use them and collect long-term observations that might help EMC's product groups.

The SourceOne product family went GA almost six months ago, but we're still using our internal use case to give developers feedback regarding upgrade paths, migrations from legacy systems, the effects of adding something else to the Exchange environment, and so on.

The mission we're on has three components. Our "test IT" component looks at a product before it's generally available. Our "show IT" component shows partners, customers, and developers how the product runs in our data center and how it interoperates with other products. And our "run IT" component is where, over time, we harness intellectual property that may be of value to our customers and find ways (through our field organization) to bring that value to them.

Most good IT companies test and use their products internally when appropriate. We're not boasting or selling. We're saying to customers and our own product groups that if our use case might be insightful to them, then we're happy to share.

The level of support we're getting from senior executive leadership for this work really is gratifying. Everyone from the top down knows putting unfinished products into production involves risk, but we in IT are in no way swimming upstream on this effort.

Nothing is perfect, including us. But if a product is not good enough for our environment, it's not good enough for our customers. That's being "IT for IT."

Additional Information
IT for IT
Notes: