The EMC IT Transformation Journey: Making Big Bets and Taking Bold Action

A big mistake companies make as they work to transform their IT operation is thinking that they can achieve that change without making some bold, big bets.

CIOs and IT leaders I talk with often reason, “if we make a bunch of little incremental steps, we’ll get to where we want to get.”

That is absolutely not the case, because when you make small incremental steps, in most cases, you’re ruling by consensus; you’re letting the silos dictate the strategy and the direction. And in the end, there are so many vested interests in traditional IT organizations, that a CIO or a VP of infrastructure responding to consensus can end up missing the bigger picture.

You’re engineering complexity into the system, as opposed to taking complexity out. The bigger picture is that there is an entirely different model that we need to get to as quickly as we can, and to do that requires some bold moves.


In EMC IT’s case, we took on what were really big bets for us: the Intel chipset, Linux as a mission-critical operating system, VMware virtualization, and the strategy of running our applications in multi-tenant mode, which shares a large, consolidated infrastructure. (Read our white paper, “EMC IT’s “On-Ramp” to the Private Cloud” to learn more)

Today, they might not seem so bold, but in 2004 when these decisions were made, nearly all of our mission-critical applications, except Exchange, were running on SPARC/Solaris.  So, betting on x86 and Linux as an open-source operating system posed some associated risks. However, many other companies were making similar kinds of investments on mission-critical applications, so it was something we absolutely had to do.  Complexity was killing us and we had to remove as much of it as possible, so making and honoring those big bets was essential.

A new, multi-tenant world

The biggest bet that we made was a commitment to multi-tenancy, where multiple applications run together on shared infrastructure rather than having a single instance of software running on a dedicated infrastructure.  Multi-tenancy is completely different than the old traditional world of IT, where the business procured vendor-recommended, dedicated infrastructure that IT installed and ran.

The business bought, owned and had the illusion of controlling it, so they could prevent others from screwing up their workload!  This old, physical, dedicated model highlighted the dark side of asset ownership. In reality, when you own it, you’re a bound to it – having to upgrade it, predict the future capacity needs and scale it out in big, expensive chunks of capacity. Business asset ownership was a curse detracting from business agility and efficiency. We needed to prove there was a better way.

Business cases a CFO could love

Transitioning from the old IT world to our target architecture took some strategizing. We not only had to prove out the technical viability of the new architecture, we also had to change the dynamics that would otherwise have perpetuated the old world.  Those dynamics spanned everything from how projects were approved and funded, to how designs were reviewed and how teams and individuals were rewarded and measured.  We needed “external” help, so we called our colleagues in EMC’s Consulting organization to develop the strategy together.

We started with a business case to build the seed infrastructure that would enable us to prove the new architecture. We called it our “Stop the Bleeding” business case — as in stop perpetuating our customized and costly approach to developing business applications.  For this, we estimated how many business application projects we targeted for the next year and did a cost comparison between the old way on a dedicated infrastructure versus a converged infrastructure based on x86 and large SANs. The resulting funding decision was a no brainer – multi-tenancy would result in same-year payback on our investment.

Not surprisingly, our CFO became an immediate supporter of our new approach.

That said, just building the new infrastructure was no guarantee of adoption and value realization. We needed to take purchasing control for infrastructure away the business (without picking a fight), and give them other controls that assured them of an acceptable outcome. We ultimately accomplished this by buying the seed infrastructure ourselves and providing it to the business free-of-charge, which enabled them to spend the money on applications that they would have otherwise spent on infrastructure… a win for them.

Bold service level guarantees

Economics alone were not enough — we also had to guarantee service levels.  In the multi-tenant environment, the business was concerned their application performance could suffer from the “noisy neighbor.”  Because the infrastructure had been virtualized, we knew we could provision additional vCPU and memory quickly and, in so doing, respond to performance degradation.

This agility emboldened us to commit to the business that they should not worry about performance and that we would address any degradation in real-time fashion.  Between the economic benefits and SLA guarantees, we created an environment where our business users were eager to adopt the new architecture.  In the rare cases they were not eager, top-down support from the CIO was very helpful.

We then had to turn our attention to our legacy problem.  We had 160 stacks of disparate, customized infrastructure in our data centers. There were two ways we could have approached that.  One was to let the standard tech refresh process work its course, which would have taken a decade given the fact that dedicating CAPEX funding for tech refresh is always challenging.  The other was to accelerate the process and transform our legacy infrastructure as quickly as possible.

We decided that that incremental approach wasn’t bold enough to get the job done. We needed a bigger bet approach here too — which we called “Sweeping the Floor.”

Sweeping the Floor

By Sweeping the Floor, we’re talking about application transformations from SPARC/Solaris to x86/Linux, in additional to the more straightforward virtualization of our Windows and Linux environments.  We realized that we were going to have to write off some assets that weren’t fully depreciated. We also realized that to do those application transformations, we would have to invest in some labor on the application development side and engage the businesses from a testing perspective, at least.

On the benefits side, there were maintenance, electrical consumption, and datacenter space savings as well as an opportunity to reduce software licensing costs by reducing the CPU core count when moving from SPARC to the more powerful Nehalem chipset.  We put together a business case with VMware professional services’ assistance, and then we, much to our surprise, realized that there was a very compelling, short-term payback.

Once again, even in what was a trying economy at the time this project began, our CFO saw the merits of investing to accelerate the transformation of our legacy applications into the new IT world, and in the process take unnecessary complexity and cost out. These were big, bold bets but they paid off in a way that incremental steps would not have and helped ensure the success of our ongoing IT transformation.

Watch this space for further insights into stages of EMC’s IT Transformation and lessons learned that might help your organization on its journey to a new IT operating model.

About the Author: Jon Peirce