You know about waterfall software development, where localization has its origins. You’ve heard of agile localization, which has become more popular in recent years too. Software-as-a-Service (SaaS) has moved into the mainstream as a delivery model for software, with more and more tech companies embracing it then ever before. But what are the latest trends in building great software that localization teams need to be aware of? More importantly, how can localization teams fully align with these to enable international growth?
First, a few definitions of key concepts, which I’m borrowing from the Synopsys blog:
- Agile focuses on processes highlighting change while accelerating delivery.
- CI/CD focuses on software-defined life cycles highlighting tools that emphasize automation.
- DevOps focuses on culture highlighting roles that emphasize responsiveness.
What does this look like in practice? It means that Product teams can deliver quickly and continuously, with a high degree of automation as well as ability to roll out changes in response to user inputs, needs, and product vision.
But there’s another important software concept that I think needs to be included in this list, defined here, borrowing from the FireCloud blog:
- High availability architecture is an approach of defining the components, modules or implementation of services of a system which ensures optimal operational performance, even at times of high loads.
If you’re familiar with the gold standard of “five 9’s of uptime,” this basically means that the system is 100% operational (e.g. available, not failing) 99.999% of the time.
Thinking about how all these concepts play together for localization teams at software companies that espouse these very practices, I believe all of these concepts are important. But I believe that the high-availability architecture concept is the one that matters most for localization teams — quite simply, because it enables most of the others.
Why High-Availability Localization Matters
If you’re at a company where the product teams embrace CI/CD, chances are you’re already investing in DevOps, and Agile is probably “old news” to your development teams. As a result, the responsiveness, accelerated delivery, and automation mentioned above are probably so deeply ingrained in your company culture that your product localization practices are already aligned, enabling continuous localization on the product UI front.
What’s interesting, in product-led companies, is the ripple effect that these approaches have on the rest of the company. Localization teams, especially those supporting other parts of the company beyond product, are impacted hugely in this regard. Here’s an example of a simple feature release and how the various teams are intertwined:
- Product team releases an important new feature, not as part of a product launch, but as part of ongoing regular deployments, which happen routinely
- Product marketing team creates some promotional content to ensure the right user profiles are aware of the new feature and how to best leverage it to achieve their goals
- Help docs team creates support documentation to represent the new feature and deprecate older content on the feature it is replacing
- Training team updates training videos to reflect the new features
- Community team updates threads in the community to ensure users are aware of the update
- Sales enablement team updates content to ensure salespeople and sales engineers know how to talk about the new feature, replacing an older feature they referenced previously, to set proper expectations with new customer
- Implementation team updates documentation and training materials
- Partner channel team updates materials to ensure partners understand the new feature
- Legal team reflects new feature where mentioned in any standard agreements, if applicable
This is not a complete list of all possible teams affected by a given feature release, but it gives you a sense of the complexity and how Product serves as a catalyst or trigger for changes nearly everywhere else in the company. That’s a lot of changes, even just for your original language. If this sounds like a lot of work for all of those teams, consider that the localization team will be expected to help roll out these changes too, but not just in one language. Across all other languages.
Now, imagine that this happens every week. Or every day. Or several times a day! (After all, engineers at Amazon are reported to deploy new code every 11.7 seconds.)
No localization team can actually keep up with this pace unless they have a system that is specifically built to handle not only the pace of changes, but the depth and variety of the changes that stem from the Product team’s way of working. This assumes that your company’s localization efforts are centralized all across the business, which isn’t always the case.
In short, you’ll have to build a localization system which ensures optimal operational performance, even at times of high loads. That’s what high-availability architecture seeks to achieve.
In other words, the more advanced along the curve your company is with the best-of-breed software development concepts above, the more important it is to espouse high-availability localization.
What High-Availability Localization (HAL) Means in Practice
The working definition I’ve been using for HAL is as follows:
A localization system that is configured to handle different types and volumes of content continuously, with minimal or no downtime.
What does this mean in practice? Here are some of the characteristics of what constitutes a HAL system:
- Stakeholder wait time is minimized
- Repeatable process steps are automated
- Content transfer between systems is frictionless
- Content that is created / updated continuously is localized continuously
- Linguistic resources are diverse enough to accommodate time zones and specializations
- Varying volumes can be accommodated (including “surges”)
High-Availability Localization as a Competitive Advantage
I believe high-availability localization is not only possible, but the way of the future. It already exists, to some degree, at least for product localization at many SaaS companies that use continuous deployment, agile, DevOps, and depend on a high-availability architecture.
What I’ll admit might be a utopian vision is to extend the concept of HAL into areas beyond Product, such as Marketing localization, Support localization and so on. If you work at a company that is already doing most of these things in ways that are highly agile, continuous and digital, I do believe high-availability localization is possible, but won’t be easy.
Many companies are already trying to achieve this vision with machine translation, but that’s just not enough. No matter how good machine translation quality becomes, humans remain in the loop for certain types of content, at some point in the process. What might happen is that machine translation becomes the “T” step in the classic old “translate-edit-proof” or “TEP” workflow that used to dominate the localization industry, that perhaps “E” is performed by what today we refer to as human translators, and that “P” is perhaps left to user communities to report “bugs” and issues that can later be fixed if needed.
What will distinguish the truly High-Availability Localization systems from those that report lots of “downtime” will be the degree to which workflows are automated, including their many steps and variations, including leveraging the best that humans and technology have to offer.
Can HAL be a competitive advantage for a software company? Absolutely. Just as time to deployment is a competitive advantage, the time to localized delivery is too. More and more, I believe that this competitive advantage for the world’s best software companies won’t just be about deploying continually, but ensuring that all of the processes that stem from there to communicate with customers and end users — selling, marketing, training, enabling, onboarding — will need to be continuous too.
In tech companies, localization has a major role to play in ensuring that as fast as communication can happen with customers and users in any language, it can happen in all languages. The industry is a good bit away from achieving that vision, but it’s only a matter of time until we get there.