Lextron, Inc. is a wholesale distributor of animal health pharmaceuticals with about 700 employees, 60 locations across 20 U.S. states and upwards of $500 million in annual sales. Until recently, as a result of mergers and acquisitions, it also had four separate ERP systems, says Tim Hays, Lextron's IT Director and its top IT decision-maker. As Hays explains, when the company in 2009 decided to consolidate to a single SAP implementation, he opted to do so in a virtual environment – and he's never looked back.

Q: What got you interested in virtualization for SAP?

A: Our success with virtualization in other areas. We were early adopters of VMware. Before that, we had a virtual LAN infrastructure to support VoIP and virtual storage with SAN technology. Then we got to pricing the infrastructure for SAP and found we needed about 20 Unix servers and all the resources that would require. So we looked at virtualization instead. We found out very few people actually were doing that. We said, why not? The advantages are there and proven in other areas, in terms of the hardware savings, business continuity benefits and the ability to right-size the environment as needs change. We'd been running virtual HP-UX servers for some time with great success. We felt there was no downside to trying it out.

Q: How did you make the business case for virtualization?

A: It was a simple math problem. We were able to save about 60% off what the anticipated budget would've been for hardware had we not used virtualization. Assuming it worked, it was a no-brainer.

Q: What does your implementation look like?

A: We're running HP-UX on four HP Integrity BL870c blade servers. They each come with eight cores and we've got 96G of memory in each of the four blades. We run the infrastructure on that. The blade server cluster is connected by 8GB fibre channel to an EMC Clariion SAN. We use a combination of solid-state drives, about 300G worth, and traditional spinning disks.

Q: How did the implementation go?

A: We started in July of 2009 and used a slightly different approach. A typical ERP implementation starts with white boarding what you need for feature functionality, then you send developers away and wait for them to come back. We flipped that on its head and spent 30% of the time on design and 70% on implementation. Our goal was to implement as much as we could out of the box and make only make slight modifications. So we installed SAP, loaded data on to it, then did a business playback to the organization. We asked, "Why won't this work?" as opposed to, "What don't you like?" That allowed us to rapidly deploy SAP to the organization. In July we had the SAP infrastructure built and, one month later, we had data converted onto it and completed a conference room pilot of the SAP infrastructure and business processes.

Q: What are some of the benefits you've seen thus far from running SAP in a virtual environment?

A: We can snap copies of HP-UX servers on a whim and do dynamic provisioning of servers as we see fit. Say we're having an issue with an application and want to see if more memory will help. We can dynamically double the memory. If it doesn't have the desired impact, you can set it right back. We're also using the online migration capability. If I want to install a patch on a physical host, I can move the load from that host to all the remaining blades, do the patch, then transition the load back. Instead of having to take an SAP outage to do it, we can do it during normal business hours.

In terms of disaster recovery, we now have the ability to recreate this environment fairly quickly. We've been testing the DR capability lately with full restores from a backup, so once the physical server layer is there I can create a place for the tapes to spin up to. We have the ability to move the server around in real time. If it looks like a blade is going south, you can live migrate the load to another blade. If you were operating multiple blade enclosures across multiple data centers, so long as you had enough bandwidth and appropriate SAN infrastructure you could do the same thing between data centers.

Q: How have things changed in terms of performance?

A: Our implementation partner told us this is one of the fastest SAP systems they've ever seen. That's because there are lots of resources available to the applications and the use of solid-state drives reduces I/O wait time.

It's also built in such a way that we can add resources as we need to. That may be one of most salient points. You go through sizing exercises in terms of what resources you need to run SAP but it's really a best guess. We built a system that allows us to react quickly to whatever the reality turns out to be. On a whim, we can add memory, CPU and disk if we need to. In many ways the virtual infrastructure allows us to protect our investment rather than having to make a forklift change if we guessed wrong on the low end. It also allows us to take a middle of the road approach rather than risk spending way too much on hardware.

Q: What about from an operations perspective – is it simpler to administer?

A: Yes. If we need another app server, it basically takes 20 minutes to stand up a new one. We make a clone of an existing app server, make some SAP changes to say, "This is a valid application server," add it to production pool and wham, we have a new production server in SAP. In a physical environment, you'd have to provision a physical device, lay down the OS and do a base SAP installation, basically building from the ground up.

In the virtualized environment, patch management is also so much easier. You never know exactly what the impact on an app will be when you make a change. With virtualization you can take a snapshot of the environment, apply the patch, test it and if all goes well you can make that the new production server and just delete the original. If the patch causes a problem, you still have the original to go back to.

Q: What were some of the most unexpected problems you had when implementing virtualization with SAP?

A: The most unexpected problem was just convincing the people working on the project from our implementation partner that virtualization wasn't going to be a problem. Everyone says it needs to be a physical environment because of this, that and the other. We said, "No, trust us, you won't even know it's running on a virtual machine." Beyond that, there were no significant hurdles to overcome that we hadn't seen before.

Q: Shifting gears a bit here, how do you go about keeping your staff engaged in their jobs?

A: We've always tried to work on exciting things and have a project identified for each person that's going to keep their skills sharp. Part of it is pushing the envelope on things like virtualization and VoIP as they become available. We were probably one of the first five companies in Colorado to put in VoIP 7 or 8 years ago when that came to be somewhat popular. The other part of it is, we're a very integrated part of our business. We're trying to deliver opportunities for the company to increase revenue or decrease costs and we keep that in focus with every project.

Q: What is the most challenging part of your job these days?

A: We're dealing with some interesting challenges in terms of how to consume some newer technologies in a safe way. For example, should we allow people to use Facebook at work? One group says customers are on Facebook and that's how they want to communicate while others say it's a time sink. The iPad and iPhone are revolutionizing the way IT has to think. We're trying to come up with ways to as quickly as possible make the infrastructure device-agnostic. Mobility will be the next big challenge. How do I enable my people to work in a manner that's consistent from wherever they happen to be? The goal is to have services we can deliver no matter where you are and what device you're using, whether an iPad, home computer, work computer, whatever. We haven't fully delivered on that but that's where we're trying to get. It's really just a logical extension of the hub and spoke infrastructure we've had for years, where all services consumed by the organization are delivered centrally.

Q: Are you a Blackberry guy or an iPhone guy?

A: I'm an iPhone guy. For us, the iPhone and Android are far easier and cheaper to support than the Blackberry, which requires Enterprise Server and licensing to do message sync. With active sync on the Android or iPhone it's just plug and play.