December 17, 2009, 10:27 AM — Overseeing the IT operation for a massive financial operation isn't for the faint of heart. Overseeing the merger between two such organizations -- well, that takes a special breed. Scott Dillon, head of technology infrastructure services at San Francisco-based Wells Fargo, which completed its merger with Wachovia at the close of 2008, brings a level-headed approach to integrating disparate IT resources, including 650,000 square feet of data center space. In this interview with contributing writer Beth Schultz, Dillon reflects on ...
THE 'JUST IN TIME' DATA CENTER: We used to have a 'capacity on demand' model in the data center. What that really meant is that we'd have hardware pre-provisioned in the data center so we could turn it up quickly if we needed. By definition, that meant we had non-utilized devices in the data center— and that's expensive. We were essentially warehousing capacity because we couldn't get what we needed from the provider into the data center and configured fast enough. Now we work with key hardware providers to go from their production line to our data center in a matter of days, which means we don't have to maintain the capacity.
SUPPLY … : One of the key things we've learned is to have an unyielding focus on our supply-management disciplines. That might be a little bit different than how other folks talk about the data center, but what we're really trying to say is that within the data center--and all that space and compute power within it--one of our key objectives now is really to drive up compute power per square foot while driving costs down simultaneously. So the supply management side is really not only about how do we do a great job within the four walls of the data center but also with all those things that go into and come out of it.
" Building brand new is good, but if I can get server utilization double the industry standard, through virtualization, and double on storage, or even a 10-15% improvement, our leverage with shareholders without having to put any capital into a deployment is pretty great. "
… AND DEMAND: At the same time, in parallel, we know how critical maximizing our relationship with our business partners is for driving great demand management opportunities. It's really that intersection of the supply and demand levers that have allowed us to really optimize the data center asset, that key strategic resource. So we also have an unyielding focus on how to put the customer experience first and foremost-- and then how do we take our most critical assets, configure them, align them and manage them so we're really enhancing that experience.
MEASURING POWER CONSUMPTION: It's very important to understand what's going on with power consumption and optimization not only for the carbon footprint but also the raw financials. We put labs in the data centers as a way of validating the power ratings our providers and vendors are quoting us.
STANDARDIZING ON DATA CENTER GEAR: We understand that one size doesn't fit all and know there is going to be some need for customization, but we standardize whenever possible. We have what we call SSOs, or standard service offerings, and we want to make sure that we're around the 70%-plus range on deployment of devices configured to standard. As we configure and architect the data center we use those standards to drive down costs.
BEING ALWAYS AT THE READY: We know through the merger that we have to be very thoughtful and rigorous in stepping back in all infrastructure areas and putting together target operating models and actual strategies. Our philosophy within infrastructure is to be in a continuous state of integration readiness. We have to be able to beat long lead times. We don't want to just jump into an N state overnight. Our belief is that a lot of companies get into trouble by looking for a technical solution to a business problem versus really solving out the mechanics of it.
FINESSING THROUGH A MERGER: At the time of the merger and continually every 30, 60 days, we do an integrated capacity plan about what the business partners have coming up, what we see coming from the integration, and what applications are planned for retirement and how all of these affect capacity in the data center. This allows us to be really forward-looking in getting the things that do require long lead times built out.
UNDERSTANDING APPLICATION REQUIREMENTS: We know not all applications will be kept as the business makes its product decisions, so on the infrastructure side we have to understand the needs. We're literally mapping back from application decisions to servers to understand the capacity in the data center and what that will mean to us over what period of time. Then over the top of that we lay organic growth. Then on top of that we lay our overall data center.
WHERE PEOPLE AND PROCESSES FIT IN: When you have something as simple as a server being provisioned to run a legacy Wells Fargo application, it's pretty straightforward if you want to provision the server and put it in a legacy data center. But what if you want to put that application in a legacy data center from the new company? Then you have to make sure your IP addressing is consistent, the workflow, the provisioning, the integration back to your third parties, the firewall infrastructure, and the network and storage infrastructures -- that all those things are integrated. So we have been putting as much rigor into the integration of our infrastructure teams as we are into the application infrastructure itself.
POWER OF VIRTUALIZATION: Building brand new is good, but if I can get server utilization double the industry standard, through virtualization, and double on storage, or even a 10-15% improvement, our leverage with shareholders without having to put any capital into a deployment is pretty great. Trying to put up brand-new infrastructure in the middle of one of the largest mergers in financial history would not be our ideal thing for our business partners.
What do you know now that you wish you'd known then? Share your tales here or contact Beth Schultz, at email@example.com.