Empowering Developers With Desktop Virtualization
ADP Dealer Services had to give its developer community a desktop environment that both fostered creativity and provided the latitude they needed to do their jobs. A virtual desktop infrastructure gave ADP the ability to provide them with an environment that was more specifically designed to meet their needs.
ADP Dealer Services is benefiting from expanding use of desktop virtualization. It's enjoying increased security, better management, and higher productivity benefits as it leverages desktop virtualization across its applications development activities.
To hear more about their VMware View expansion experience, we're joined by Bill Naughton, the chief information officer at ADP Dealer Services, and Shane Martinez, director of global infrastructure at ADP Dealer Services. The discussion is moderated by Dana Gardner, principal analyst at Interarbor Solutions.
Listen to the podcast (26:06 minutes).
Here are some excerpts:
Dana Gardner: Why have you pursued desktop virtualization for application development first?
Bill Naughton: We had an interesting problem to solve. The first issue was developer productivity, which is very important to us, because we do have a big software development engineering house that needs to be productive.
And we had issues where our traditional approach of putting them on the user-based plan was not giving them the creativity, flexibility and productivity they needed to spin up new environments, to have a free workspace so they could do what they needed to create products.
So we thought that a VDI solution, combined with a quick provisioning and deprovisioning for development environments, would make them more productive and protect their normal day-to-day use of email, ERPF, Salesforce automation apps that they might need on the traditional production environment.
It's been now going on for probably about a year-and-a-half. We were looking at what was the right design and what was the process, because there is a lot of process involved with change management, with the provisioning and deprovisioning. So we did some pilots and now we're in full roll out and pretty excited about the results.
We're talking over 1,000 technical people who will use the solution -- software engineers, QA type people, test people. And because ADP Dealer Services has a pretty big application portfolio, we're talking about hundreds of environments, thousands of servers that have kind of grown up over the years that support our R&D environment.
Gardner: What does ADP Dealer Services do that relies to heavily on software development prowess?
Naughton: ADP is the world's largest outsourced human resources, payroll, and tax benefits company started in 1949. It's about a $10 billion company, with 50,000 employees and close to 600,000 clients. It's one of Fortune's most admired companies and one of only four companies with a AAA credit rating from Moody's and Standard & Poor's.
ADP Dealer Services, is a division of ADP, about a (US)$1.7 billion company that's serving the auto retail client base throughout the globe. It has about 8,000 employees and 25,000 clients to serve through software and services the auto retail and the OEM auto manufacturing industry.
Gardner: So I imagine that the applications that you are creating for these dealers are very intensive in terms of data, and many different types of applications, custom apps, as well as more off-the-shelf or third-party, need to be integrated, so a fairly complex set.
Naughton: It's a very complicated set. You are right on the money. It's all the way from ERP systems that we develop for the industry, CRM applications, digital marketing applications, all the way to the telephony side of the business.
So there is hardware integration, third party integration, but it's mostly ground-up software development that is the core base of the business of cloud computing apps, multi-tenant applications, and then applications that will tie into telephony systems and other applications through APIs. But the core products are ground-up software development.
Gardner: So it's a highly technical undertaking and your developers are really on the front lines of making this business work for you. This isn't a nice to have. This is mission critical across the board?
Naughton: Absolutely. And you want to make sure the developers have as much creativity and freedom as they can possibly have.
At the same time, ADP being a public company, and being a company that people entrust the data with, we need to have good security across our different platforms. So the challenge was to give the developers a platform where they could be creative, where they could be given a wide range of latitude of tools and technology and at the same time, protect their day-to-day compute that they needed for things like messaging or applications the managers need to administer the workforce.
Gardner: Bill, as CIO, you had this vision about how to empower and enable your developers, perhaps even cut some costs along the way, I can imagine that you went to Shane and said, "Make it happen." Is that how it happened or did Shane come to you and say, "Listen, I've got this great idea?"
Naughton: It was a joint effort between knowing that we wanted to do something different, knowing that the developers had unique needs, knowing that security had definite requirements on how we protect from malware, how we protect from viruses, how do we patch and protect the environments. And then we had a cost consideration too in that the spiral of development that we provide to the CTO in his office was getting quite big.
So the combination of Shane being forward-looking at a solution, the requirements we had from the development community, and the security requirements from our GSO office brought it all together into something where we're going to try something a little bit different than traditional approaches.
Gardner: Shane, how has this impacted you from the infrastructure point of view?
Shane Martinez: There's been a tremendous consumption. The adoption by the associate community has been wonderful. We were faced with a challenge where we had to present the development community with an environment, which as Bill mentioned, had the latitude for them to perform their job function and they could be creative again. They were re-empowered to do their job and had all of the operational benefits that a typical compute would give them.
In addition to just that environment flexibility, also with the VDI View infrastructure, we were able to provide them with compute environment that was more specifically designed to meet their needs.
As Bill mentioned, we have a litany of different applications and development communities, and each one of their specific compute requirements are different. Using a technology like View that allows us to abstract from the hardware, we create infrastructure specific to each one of their needs.
There was a complex challenge that obviously we had to overcome, which was how do we present this pretty powerful environment and construct to people who are distributed, not just across the continental United States, but globally. By creating a separate VRF instance in our wide area network, we were able to bifurcate our WAN and create two discrete networks. That second network, which effectively became a shadow of our production infrastructure, is where the VDIs and all of our lab environments live.
As Bill said, that separate environment is one that is specifically designed to meet the needs of our development community. By virtue of having VDI and View out there for them to access over the separate network, they then can reach it from anywhere within our global network. So we have associates that are distributed across all of our sites that have the ability to consume these resources that we made available.
Gardner: And they have been mostly happy with the latency issues and performance?
Martinez: Oh, very pleased. As a matter of fact, there are several different ways in which we allow them to consume it. The first one is they can access the assets direct. With the View client, they can access their remote workstation and work on it however they are comfortable with.
In addition, though, we have the ability for them to check out that workstation and they can use that workstation either locally or when they are remote on the road. They can use that on their assets and then come back in and check it back in the library. It works very well for them.
There are two great benefits. The first thing is, from an administrative standpoint, just purely the FTE consumption. I have a very small staff that is designed to manage this specific environment. Currently, we're managing 300 to 400 workstations per administrator. So we get a very high level of density to associate from a support standpoint.
In addition, we can create and deploy workstations exceedingly fast, at a rate some days of up to 50 and 60 a day.
In addition to that, there's the server administration, as Bill mentioned, with Lab Manager and the accompanying technologies from VMware that we use. This small team is also able to manage in excess of 2,000 servers for the same group of developers and the development community.
Naughton: It's really important that we try to provide a service to the development community that they send a case in and Shane's team does the provisioning, deprovisioning for them. We spin the environments up real quick and deprovision and reclaim the space. So we get efficiency there.
The service by the admin is taken care of -- the whole process that they need for new environments. You want to make sure the environments get taken care of. So they do both of that. There is a service component to it that we think is important.
Gardner: You're referring here to your application development activities, but your R&D and lab, are they separate? Do they overlap? How does that work, and what have you been using to support them both with VDI?
Martinez: There are two different environments, as Bill mentioned, throughout the lifecycle of creating a new product. Our development community has to obviously create code and write code, but as we become more of a cloud-based service provider to the auto, truck, marine industries that are out there in the world, we become more of that and interact with the Internet.
So that lab, that test environment, needs to be very dynamic as we create new product, release it, and have it interact with the Internet and some of the OEMs and external parties that have access to that.
As a result of that, this environment also is able to provide us with a very secure, remote location that is separate from our ERP applications, our standalone Salesforce automation applications, etc., where we can have people connect and test product, beta product, alpha product even, in a place that poses no risk to the rest of our infrastructure.
As we as an organization continue to abstract our operating systems and the applications from the hardware that underlies it, it allows us to become more flexible in how we deliver compute, and application services, both to our internal associates as well as to our external clients.
So ADP has undertaken a great deal of effort in order for it to create its own private cloud infrastructure and the View client and the vSphere environment really is an adjunct to that strategy.