This article was originally featured in the July/August 2010 issue of MultiLingual Computing Magazine, in Adam Asnes’ Business Side column.
The subject of managing releases over worldwide markets can be a contentious one, with pros and cons on either side of business and development cases. The concept of simship is that if you are releasing your product to worldwide markets, you do it all at once rather than first releasing to your home market and then following with localized versions later. I can’t say that any one approach is right for all organizations, business situations and products, but I can share with you some of the organizational, procedural and business issues that contribute to successful simship global releases.
When a company commits to product releases that serve a worldwide customer base, there’s a long shadow cast on revenue, marketing, sales teams and of course development practices and testing. It’s a challenging logistical undertaking to release software products in multiple markets, requiring well-integrated planning and practices. It’s no wonder simship is viewed alternatively as difficult and impractical to the best thing a company can do. Let’s consider a few of the issues within any organization, starting with the business case.
Internationalization and localization are always in pursuit of a business case, and one exists both for and against simship. That said, the business cases tend to vary based on the global perspective and maturity of the company. The case for simship is strongest among experienced global companies. Their revenues are already global, so delaying releases for localized versions only serves to delay resulting new release revenues. There may be good reason for adding secondary tiers for some local release schedules, but products really should be internationalized, with a clear path for localization and testing within the development path. In practice this isn’t the reality, but there’s quite a bit of agreement and successful data on the business case existing for simship with this class of company.
When companies are relatively new to global markets, they generally tend to put less of an emphasis on simship with new releases, and more of an emphasis on market or business agreements as drivers for their efforts. Perhaps they have a new customer or distributor that must have a localized version. In that case, synchronizing new version development with localization is usually—but not always—an afterthought. This is because the company sees its prime revenues being driven by current product customers. New releases boost sales, renewals and competition, so that connection is strongest where the current customers are. We’d still argue that even under these circumstances, simship should not be pushed aside, as there are gains to be made both for revenues and operations.
Time and Revenue Projections
Attached to initial time to release and revenue opportunities are quarterly and annual growth numbers. If a product is expected to grow sales by percentages outlined and expected in a marketing plan over months, quarters and years, significant delays in turn make those projections difficult, if not impossible, to meet. Delays add up to real dollars. Now let’s leave the business case behind and look at software development organizations. It is extremely common among both development and localization teams to view localization as a tail-end process. But this is a critically limiting perception if your company is committing itself to serve global customers. Practically, a company shouldn’t build a product with a requirement as major as supporting multiple locales as a tail-end process. Even in cases where legacy code is now being first internationalized for global customers, once that adaptation is complete, from then on localization should be included as an expected part of the development process. That means including requirements for planning, architecture, development implementation, testing and release.
I asked my internationalization colleague Tex Texin to add some words about this. He seconded that as with many other aspects of globalizing applications, development organizations tend to see just the work and delay to releasing their product and not the benefits. And although we work to plan to minimize the pain, there is cost to achieving simship. However, exercising the localized versions often uncovers critical problems in the product core that can require urgent updates, recalls or even the creation of specialized tools to repair customer data in the field. In that context, simship is not only a requirement to be in the international markets and significantly enhance revenue, but is an important part of product testing preventing problems that are costly to repair and damaging to both reputation and future domestic sales.
Tactics
Simship nearly always seems to be the outcome of an internationalization implementation. So, we have some experience working with legacy code that we are internationalizing and then merging with concurrent new development, building localization proactively into the process.
We find and work with the localizable content embedded in the code first. We gain a clear estimate of localization costs by examining those strings, even while they are still embedded in the code using static source analysis. That’s important because it allows the budget and financing mechanisms of an organization more time to accurately fund the localization. Then we systematically provide externalized strings for localization as we go along in the project, rather than waiting until the end. We also perform static analysis on concurrent new feature development so that when we merge legacy and new code, we minimize the risk of expensive surprises. We build functional internationalization and localization test cases and execute both. The internationalization functional testing can be performed by testers regardless of linguistic proficiency. However, because we have been localizing all along, we are also quickly ready for linguistic testing. The combined processes are extremely effective in finding both functional and linguistic defects that may have passed through if performed as an afterthought.
Agile Development: It’s one thing to talk about including localization into your internationalization and development process on large-scale efforts, but what about smaller scale and rapid agile releases? Turns out it’s really no different. I talked to Mike McKenna, globalization manager at Yahoo!, to get some perspective. An extreme example is the release cycles for Flickr, Yahoo!’s photo sharing social network. Flickr sometimes rolls out four to six releases per day, holding the expectation that developers can get immediate access to translations they may need, likely to be small UI changes. Then they pride themselves with directly connecting their developers to users, without intermediaries, to fix issues that may arise from localization or functional changes.
Yahoo! has other software, such as its Open Strategy Platform or Yahoo! Application Platform, which typically have six-week release cycles. In this case, there is a UI freeze before the release sprint so that localization can be integrated into the final release sprint. Developers work with their localization managers and ensure any last-minute tweaks that may become necessary to the UI during the release sprint are well coordinated.
Security: Let’s go back using our timetunnel to the 1990s: Windows 95 was first released in August 1995, its first service pack was released in February 1996 and the second pack in 1998. The localized versions were always lagging behind: Microsoft first released the “Enabled“ version, which was not localized but could run software in your language. A few months later, Microsoft released the localized version. Today, Microsoft and other companies release security patches on a monthly basis if not on a weekly basis. Can you imagine releasing the patch in North America first and only a few months later in the rest of the world? Simship enables the release of security patches and other critical patches on a timely basis to all markets and prevents security glitches.
Internationalization as Enabler
The success of localization and the ability to coordinate simship processes are directly dependent upon the quality of a product’s internationalization as well as the development team’s ongoing internationalization practices. Internationalization is the software development enabler, and without it or without a consistent internationalization benchmark, localization and particularly simship get broken. As the saying goes, garbage in, garbage out. Simship takes a little more planning, time, tools and coordination, but it’s hardly an onerous process. Like a lot of things, your organization has to be aware of the benefits and just do it. Then the actual doing is clearly achievable.
About the Author
Adam Asnes is President and CEO at Lingoport and enjoys investigating how globalization technology affects businesses expanding their worldwide reach. Adam is a sought after speaker at industry events and a columnist on globalization technology as it affects businesses expanding their worldwide reach. He often writes articles for localization, internationalization and globalization industry publications and enjoys cycling and Colorado’s Rocky Mountains; he can be reached by clicking here.
Lingoport’s Internationalization (I18n) and Localization (L10n) Tools and Consulting Solutions
Founded in 2001, Lingoport provides extensive software localization and internationalization consulting services. Lingoport’s Globalyzer software, a market leading software internationalization tool, helps entire enterprises and development teams to effectively internationalize existing and newly developed source code and to prepare their applications for localization.
For more information on how Lingoport can assist you with all of your internationalization and localization needs, please contact us at info@lingoport.com, call 303.444.8020, or complete the quote request form.
