International cosmetics giant Mary Kay Inc., a privately held company with more than US$1 billion in revenue, credits its online presence for processing 85 per cent of sales placed by its army of consultants or directly by consumers – up from just 10 per cent a few years back. Chief Architect for E-Business Barry Bloom spoke with Network World (U.S.) Senior Writer Denise Dubie about the technology behind Mary Kay’s online evolution.
NW:What exactly does a chief architect for e-business do?
BB: It varies. I am involved in architecture meetings around how we’re going to lay out the next version of our applications across the network to what servers we’re going to purchase. I’m involved in discussions around the deployment of our storage area network (SAN) as well as our Internet connectivity to the load-balancing technology we use. I am responsible for our adoption of [Microsoft] .Net. We have probably 50 different Web applications that support our sales force, and we have an extensive deployment process for moving new versions of those applications into our production environment. I created that deployment process, and I’m involved in what we call our release process on a day-to-day basis. I’m also a very hands-on kind of architect, so if there are problems with our production environment I’m typically involved in trying to resolve them.
In the past, a typical Mary Kay consultant didn’t have access to the Internet and the company didn’t have a large Web presence. But in the past few years it’s amazing how vigorously they’ve adopted it. To go from less than 10 per cent of your orders coming from electronic means to 85 per cent coming off the Web in a three-year period is huge.
NW:How much of the IT infrastructure is dedicated to the Web site?
BB: The 700 servers [and 2,000 desktops] we have support everything, including corporate [applications]. There are 200 servers involved with our Web presence. We started with about 20 servers dedicated to our Web presence. In late 1998 through 1999, we went from 20 to 200 in six months. We totally underestimated how many servers we were going to need, and we totally underestimated the adoption rate. There was this period of time [when] we were just blowing up our architecture every two months, trying to cope with the load. It was a big challenge because the executives and the management didn’t always support that. We weren’t given this big chunk of money up front. It wasn’t until we proved that we needed something that we got it. Today, we’re finally built out. We run a 16-processor Unisys [system outfitted with] SQL Server as our back end for all of our Web stuff.
NW: What types of servers do you have?
BB: Predominantly Windows [but also VMS, Solaris and other servers]. We use a mixture of Compaq, Dell (Computer Corp.), IBM (Corp.) and Unisys (Corp.) servers. There are probably 50 different configurations from duals with 512MB of RAM to 16 processor boxes with 16GB of RAM. We have spent a lot of our time trying to leverage higher processor servers so that we can have less of them. We just went through a big server-consolidation phase moving to [Microsoft] .Net and we reduced our overall server count by about 30, which was a lot.
NW: What is the cost and the expected return on investment (ROI) with your server consolidation?
BB: We used to have 46 servers to run our Web applications for our sales force, and once our .Net migration is complete we will have 20. This is for a number of reasons: .Net is compiled, and it scales up better. We are moving from dual-processor servers to quad-processor servers. .Net is more stable so we can afford to run all our applications on one server type – those 20 servers are duplicates of one another and share the load.
NW: Any advice for others looking into server consolidation?
BB: There is no magic bullet. Part of the issue is that there are so many different versions of software. And [the software packages] don’t all work together on the same box. So you have to be very careful about what you put on the same server. You also have to realize it’s going to slow down your ability to deploy changes to a highly consolidated server because you have to make sure that your changes don’t break everything else that runs on it. It’s really hard in the Microsoft world to solve that problem easily because there are so many disparate applications. A lot of the time, the applications are not well thought out. And it’s not just Microsoft’s fault. The applications that run on the Microsoft platform are not always well-written.
NW: Why .Net?
BB: Our experience was with [Microsoft’s] Visual Basic 6 and [Component Object Model] using tools like Site Server 3.0 Commerce Server Edition to supplement our development efforts. What we learned from that experience allowed us to build the best system for Mary Kay using .Net technologies.
NW: How do you take 50 applications and bring them over to .Net?
BB: Most of the struggle in developing a Web application is in figuring out what you want it to do. But to take an existing Web application and bring up a new version in .Net is nothing compared with starting a brand-new application from scratch. We took our existing ordering application, which services 85 per cent of our business and was written in Microsoft’s Site Server 3.0 Commerce edition, a five-year-old technology, and brought it over to.Net. We took the way it looked, the way it worked, all the rules that were in there, and just took that knowledge and wrote a .Net application from scratch. It took us about two months. The ordering applications originally took 18 months to develop. When we [moved to .Net] we reduced the number of servers by 20 and were able to increase the number of orders we could handle 10 times.
NW: How much is Mary Kay spending on .Net, or what’s the anticipated total cost of ownership (TCO) or ROI?
BB: .Net is free except for the development tools and that cost is per developer, so it’s pretty negligible. As for TCO, we will reduce the number of servers required to run our applications by 50 per cent just by moving to .Net.
NW: Any tips for others looking to switch to .Net?
BB: First off, Microsoft has thought an awful lot about how you should develop your applications. You need to understand the tools that you have available and leverage them to the fullest before you decide you need to do something different. We had one of our developers go off and kind of work in a vacuum, and he came back with a non-.Net site that wasn’t written with Microsoft’s recommended guidelines. It had problems executing.
NW: Are you deploying Web services with .Net?
BB: There are a couple of different ways we use Web services: to integrate into our legacy systems; to wrap third-party applications that haven’t provided their own Web services; and to communicate with partners. For example, we have Web services that wrap our tax calculation package. Mary Kay is not about calculating tax rates for the whole country, so we bought something that does that for us, but it didn’t provide a Web service interface. It made it a lot easier for us to integrate our .Net applications into it by just wrapping it with a Web service.
NW: What are the keys to successful Web services?
BB: It would be easy with all the hype around Web services to decide to do [them] everywhere. But all that is going to do is introduce this artificial layer that is going to be slower than other kinds of distributed, component models. It’s an XML-based communication protocol, so it’s verbose. The kinds of Web services I see us doing are ones where the third-party vendors don’t run the kind of technology we do. ProPay is a proprietary Unix-based system. We were able to just say, ‘Here’s our Web service interface and here’s the documentation for how to talk to it.’ By defining the Web service you’re giving the documentation so you don’t have to go and explain to another development staff how to talk to it. It’s a standard so it makes it easy to do business-to-business transactions.
NW: Where is Web services not working today, but could possibly in the future?
BB: The biggest problem with Web services are going to be trying to do high-volume transactions over the Internet. We’ve talked about deploying clients to desktops for our sales force, where they would do Web service transactions in the process of doing their order. But we just feel like now we’re still going to have to be careful in terms of security about the kinds of transactions we introduce to Web services.
NW: How do you ensure that Mary Kay’s applications are secure?
BB: We’ve adopted methodologies that force developers to use specific types of security. We’ve already defined how the security is going to be laid out, whether an intranet application or a public Web site. Developers don’t have to think about it; they just develop applications the way we’ve predefined and the security is built into the application.
NW: How are you dealing with security issues surrounding Microsoft software?
BB: Our physical infrastructure has protected us from all the recent virus attacks. We are very diligent about applying security patches when they are released. I have hopes that Microsoft will make it easier for everyone to keep up with security updates and make us all more comfortable that our applications won’t break when we apply patches.
NW: What’s your top IT priority right now?
BB: I’m engaged in a project to deploy a content management system. We developed it in-house and it leverages the Google search appliance. We’re trying to help change what was primarily a print business – we have a lot of glossy brochures with pretty women on them – and translate it to the Web. Our goal is to allow content developers the freedom to develop whatever they want at the same time allowing us to provide targeted searching.
NW: What about your IT infrastructure keeps you up at night?
BB: We have all these policies in place to manage our applications as we move forward, [but I worry] we’re going to do something in an attempt to be innovative that will be detrimental to our site. When we first innovated, there were all these mechanisms for taking orders that didn’t involve the Web; now if we do something that devastates our online ordering application, boom, we’re not taking orders. It just can’t be OK to be down for eight hours.
