Reference no: EM131049423

CASE

When you're a global company that keeps expanding into new countries, how do you keep all of your consumer sites updated in the local language-without spending a ton of time and money? PayPal realized five years ago that if it didn't solve this problem it would hinder the e-commerce payment company's ability to grow, says Matthew Mengerink, the company's vice president of core technologies; his IT responsibilities include PayPal's architecture and payment system infrastructure. Today, PayPal has re-architected the software code for its site to allow simultaneous refreshes for 15 locales ranging from France to Poland. In the development community, they call this unusual achievement "poly lingual simultaneous shipping" or "SimShip." "This is a big problem that's been around a long time," says Ron Rogowski, a principal analyst for Forrester Research, who specializes in globalization issues. "For the most part, companies really do a poor job localizing content," he says, noting that technology solutions in this area aren't plentiful, and companies also must conquer organizational battles over who controls what content. "Companies would like to manage their translations better," Rogowski says, "to realize internal and external cost savings. But the real benefit is the potential for revenue growth, the ability to roll into markets quickly." That ability today translates into a large portion of PayPal's bottom line: For PayPal, international business now represents 44 percent of net revenue, which was $582 million for the first quarter of 2008, a 32 percent increase year over-year.

As of late 2007, PayPal handled about $1,806 in payment volume per second; the company's re-architected code played a key role in this increase. PayPal, now part of online auction giant eBay, had to go global to support customer desire, Mengerink says. People outside of the United States were demanding that eBay let them use PayPal (the primary purchase mechanism on eBay) and that PayPal be presented to them as seamlessly as it had been presented in English, he says. The company had to do more than present a stilted translation of English into, say, French or German, he adds. "Imagine you're going into a bank and you want to speak French," Mengerink says. "The teller can speak French. But that's not enough. You want to feel you're in France. You want to see the French flag on the wall. Especially in the banking industry, it was very important to express something that people trust in such a way that it is natural and native for them," he says. Traditionally, companies solve the localization issue by working with third-party translation companies, whose staffers convert an English-based site into multiple languages, says Mengerink.

The problem: "If you can't send them the smallest amount of text, it gets fantastically expensive," Mengerink says. "Here at PayPal you have a full site experi ence, you have to translate it, and we're an Internet company; we update the site every six weeks. How do you not slow the company down with the process of translation?" PayPal's decision to custom-develop a solution is unusual and interesting. Few software vendors compete in the translation tools arena. Also, many companies can't even overcome the organizational hurdles related to translation. "There's a whole organizational issue that has to be looked at who's in charge of what," says Rogowski. For example, he notes, a consumer electronics company may not even have similar-looking content, never mind identical content, on Web sites in multiple countries. "A lot of times Web content springs up without any plan for centralization," he says. "Before your company can translate all of its sites efficiently, you may get embroiled in organizational messes," Rogowski warns, which is why some companies are tackling the problem silo by silo. Not Paypal.

Five years ago, Mengerink and a team of localization experts inside of IT began their project to fix the problem in a very centralized way. Often, Mengerink says, companies facing this problem try to cut and paste code, and then translate it into different languages; this can lead to trouble because it's not simple to keep compressing and unifying the code. "It's far easier to manipulate text than code, he says. PayPal decided that it had to re-architect its code to accommodate the language localization issue-purely for reasons of business speed. He says, "If you get the architecture right, you can get into new countries faster." No commercial tools existed that fit the bill, Mengerink says, so all the development was done in-house with a small IT team; PayPal will not disclose the exact size of the team or the cost metrics. "There's this notion of a country code and a language code," Mengerink says. "Your software has to understand two things: What country am I in and what language is being read? This is extremely important because there are countries outside the United States where customers cannot imagine not having multiple languages, Canada, for example. The first thing we said is put both codes everywhere," Mengerink says.

Then his developers had to create a code base with much more flexibility than the original; it had to convince the software, for instance, that strings of information such as e-mail addresses, customer support phone numbers, and time of day would change depending on the country code. The second key to the project's success for PayPal: Ghassan Haddad, PayPal's director of localization, and the development team created a tool that color codes text in the software code base to note newly added strings of text that will need translating. "People just program as if it's in English, Mengerink says. "At the same time, the software extracts the new pieces." Then PayPal can send only the new pieces, instead of whole paragraphs, to the translation house. "This can take 5, 10 days depending on the size of the release," Mengerink says. "Then off we go to the races, releasing simultaneously in all locales." So what's the next challenge for Mengerink and his developer team at PayPal? "We got very good at managing content with engineering," he says. "Now the question is, how we put that content management in the hands of business.

They want to change it themselves without an intermediary. The business folks are saying ‘we respect you but pretty please can we do it ourselves?' That's a challenge, he says, given that the development toolset will continue to grow. By the way, PayPal isn't looking to license the technology it developed. "Our tools are built for PayPal, Mengerink says. "We're encouraging others to build it for themselves." Although his team worked primarily in HTML, the programming language is not the important choice, he says. "Think about the methodology. That's a really critical part. We built custom tools and they literally change every six months. This is a nascent industry. When you start looking at the publishing tools and content tools, most are appropriate for preview and publish," he says. That's a simpler model than what PayPal does, for example, frequently linking new content with new features, he notes. "There was a lot of fear, a lot of people saying, ‘Why aren't we being industry standard?' Leverage what you can, but you have to be good at creating your own tools. In the beginning, there was a lot of healthy skepticism, even internally," Mengerink says. "Some of your execs and developers will note that their last company tried to do simultaneous shipping and failed," he says. "Some people in the developer community still don't think it's possible," he adds. "Once it was done, we saw that it's not just manageable, it's a core advantage." The sooner your company can start working on a SimShip project, the better: "Once you get too big, you can't afford the interrupt to the cycle," he notes. "Very early on, you have to create the generic structures for the code," he says. "Build every next thing correct." What's the bottom line for PayPal from Mengerink's team's work? "Today, we have 15 languages, 17 currencies, 190 markets," he says. "Our code base has grown a lot. All of the new code is being built using the right structure. You have to build internationalized." PayPal's re-architected code base now keeps e-commerce humming as the company continues to expand: PayPal's net total payment volume for 2007, the total value of transactions, was $47 billion, a gain of 33 percent over the previous year. To put that in context, PayPal's net total payment volume for fourth quarter 2007, $14 billion, represented almost 12 percent of U.S. e-commerce, and almost 8 percent of global e-commerce.

CASE STUDY QUESTIONS

1. One of the challenges that PayPal faces now that it has managed to overcome the polylingual obstacle is finding the best way to put this functionality in the hands of the business, so that they do not have to go through IT each time. How do you balance this need for responsiveness and flexibility versus IT's need to keep some degree of control to make sure everything keeps working with everything else? Provide some recommendations to managers who find themselves in this situation.

2. PayPal opted to deviate from industry standards and build its own custom technology that would better suit its needs. When is it a good idea for companies to take this alternative? What issues factor into that decision. Provide a discussion and some examples.

3. Although the new system has been quite successful, PayPal has chosen not to license this technology to others, forgoing a potentially important revenue stream given the lack of good solutions to this problem. Why do you think PayPal chose not to sell this technology? Do you really think this can be made into a strategic advantage over their competitors? How easy would it be for their competitors to imitate this accomplishment?