In my 2008 article on terminology management ( Whaddya Call It? ), I commented on the proliferation inside many companies of the terms used to describe the products they build, market, sell, and support. I referenced one manufacturer that had 120 variations of a product name; is that product the Model J30 Flux Capacitor, the J30 Fluxcapacitor, the Flux-Capacitor J30, FluxJ30, or the Fluxmaster II?

In summary, I pronounced terminology management an under-practiced science in most corporations, outlined the motivations for doing it better, and promised guidance on the best solutions to achieving consistent terminology across a product line or an entire enterprise. That last point is a tall promise given the variability of size and needs in any company, but let’s give it a try.

 First off, let’s refine our own terminology before going any further. “Terms” are the words and concepts of a particular company, industry, science, art, government, or social entity. In aggregate, they represent the “terminology” for that application. Think automotive terms like “drivetrain,” “tire,” “anti-lock brake,” “instrument cluster,” and so on. “Terminology management” involves the systematic identification, storage, processing, presentation, and search for these terms by content authors, translators, marketers, and other participants in your content supply chain. “Multilingual terminology management” extends that practice to other languages, so that translators can consistently represent these terms when creating the Czech version of the “Fluxmaster II Service Manual” for your global information management initiatives. Finally, there’s a “terminologist” who’s responsible for making the decisions about what goes into the “terminology base” (“termbase,” for short), how it’s updated, who can use it, and so on.

There are lots of tools in the market, some available as commercial, off-the-shelf products (COTS) and others available only as part of an engagement with a language services provider (LSP). Our research at Common Sense Advisory consistently finds that Excel spreadsheets, Word-based style guides, relational databases like Oracle or SQL Server, and bespoke systems built with application development tools dominate the short list for terminology management software. Trailing these repurposed and purpose-built solutions are specialized COTS products from companies like ACC, Across, Acrolinx, SDL, and Tedopres and offerings from LSPs such as Lionbridge, SAJAN, and Translations.com.

That leaves the potential terminologist with two initial choices: 1) COTS versus a more restricted software product from a service provider; and 2) a do-it-yourself (DIY) solution built on productivity applications, a real database, or coded from scratch.

To be frank (and thus not terribly helpful), all these solutions have a place in the world. As is often the case with any information technology product, which is best depends on your particular application. Consider a documentation team with a handful of writers. If they all buy into the same process (and their compensation plans reflect that commitment), they could be very satisfied passing around an Excel file with a list of terms and a Word document describing their corporate style. However, that same documentation team working for a multinational firm with documentation, translation, marketing, support, and other content needs across a wide variety of product lines will quickly find that the simple solution just doesn’t scale.

Let’s get down to some practical requirements that will help you figure out where your application fits in the cosmology of terminology management. First off, consider your requirements and what that means for the tool. Here are the core requirements that we typically hear from companies with larger projects such as multilingual websites, broad product lines, etc.

• It has to work with everything. The enterprise has enough silos, so don’t create a new one for terminology. A terminology management solution should integrate with the systems that describe your business and manage your systems of record. That means it should work with your content management or documentation system, workflow, authoring, translation memory, commercial dictionaries, and other tools that are used by your marketing, support, and other people to create and edit corporate content. Core to this requirement is openness: Does the solution have an open, documented, and supported API for integration with other products? If you’re using a commercial database to store it, is the record structure easily accessed by an assortment of ODBC-based or Web database services? Does it support the TBX framework of ISO 30042:2008 for terminology management interchange?

• It needs to manage big lists. Our research shows that termbases range from domain-specific lists comprising hundreds of words up to corporate databases with tens of thousands of terms. This question begs a classic enterprise scalability issue: Small applications have a tendency to get large, and large systems often have a problem gaining traction because of their cost, complexity, and footprint. No one wants to choose the solution that doesn’t scale, but no one wants to be responsible for the white elephant that nobody uses but that consumed a third of that year’s software budget and half its human resources.
  
• It has to be usable by people with diverse needs. If the only person using a terminology management solution was the terminologist, the user interface question would be simple. However, a solution has to support the terminology life cycle – identify a term; harvest it; store it; make it searchable; present it to the writer, translator, or marketer on demand; deal with and approve the inevitable changes; and manage the terms in other languages. The product or DIY solution needs enough flexibility in its interface to support use by a wide range of content folk.

Then there’s a raft of platform requirements that could be lifted from a Web 2.0 product brochure. These are all tied to actual usage patterns, outsourcing strategies, and corporate computing architectures.

• It has to be a central resource. Any termbase aspiring to real use needs to be shared across an organization, accessible to anyone in the content supply chain. Given today’s computing architectures, this almost always auto-correlates to the next requirement…
• It must be Web-based. Solutions that require installation of large clumps of software on end-user computers are so five years ago. The terminology management solution that gets used will be the one that allows any user with a browser to get in.
• It has to be accessible through the firewall. Common Sense Advisory finds that nearly 90 percent of companies outsource some or all of their translation and localizationactivities(“LocalizationVendorManagementhttp://www.commonsenseadvisory.com/research/report_view.php?id=61&cid=0), so it’s critical for your translation partners to be able to use the termbase without jumping through hoops. Furthermore, many companies have begun outsourcing even the authoring of content, so those authors in Bangalore and Brno need access, too. Whichever tool you choose has to provide access control with defined levels of security.

Finally, there’s the issue of “marketing” a solution to the budgetary powers that be – and then to the people who will have to use it. Whether you build it or buy it, terminology management software costs money for software, training, and integration. We find that few practitioners enter into terminology management without a strong conviction that there will be benefits such as discussed in my last article, but few can quantify the benefits in improving quality, consistency, and productivity because they don’t have data or even metrics on how to measure what they’re doing now.

In February 2009, Common Sense Advisory will publish a report on the best practices in terminology management, including how to measure success and return on investment. Until then, terminology management will remain an under-practiced discipline with terminologists constantly under pressure to show their worth.

Don DePalma is the founder and chief research officer of the research and consulting firm Common Sense Advisory, and author of the premier book on business globalization “Business Without Borders: A Strategic Guide to Global Marketing.”