Globalization Insider: Why did you choose to build and maintain your own system, rather than adapting a commercial global content management system (GMS) to support your clients?

Simon Otter: Our systems have a history – further back than the existence of global content management systems almost. We developed various technologies over the last 8-9 years that we brought all together in 2007 under our LanguageDirector product line. When we first started this development, buying an off-the-shelf global content management system wasn’t really an option. It’s sort of like civilizations that exist on different continents developing the same ways of solving problems.

Only just recently there has there been more sharing in this area. About three years ago, we seriously discussed whether this was a game we could win, and we considered joining Idiom’s LSP program. We even talked to them about implementing some of their components through their API to enhance some of our own automation components.

'Could you tweak this a bit to better fit what we need?'

In the end, we decided that we were supplying something of real value to our customers that they couldn’t find elsewhere. It looks like we made the right decision – LanguageDirector came in second in CSA’s recent report on TMS (translation management systems) due to the breadth of our solution. Their criteria focused on business process management, in addition to the language piece. This means we won points for our eProcurement integration, budgeting, reporting, billing, etc.

Based solely on a feature-by-feature comparison with Idiom, we probably wouldn’t score as high. However, if the goal is to meet the needs of the business stakeholders who also have challenges when it comes to global content management, along with the linguistic and technical stakeholders, we’re usually a better fit. We have always focused on all three types of user, and 90% of what we have developed originated with a customer asking, ‘Could you tweak this a bit to better fit what we need?’

Insider: Where are your developers located?

Otter: We have in-house developers in the UK and an outsourced team in Beijing. We are also working very closely with LISA Member XML INTL in Poland to implement its XML capabilities. And we recently sent some work to a company in the Ukraine. The development team (not including the IT team that runs the SaaS services) total 24 at this point, and we are definitely growing – we have just made offers to two more people. The team also includes Business and Systems Analysts along with our Product Managers.

Insider: As a customer, why does it make sense for me to choose thebigword and its LanguageDirector solution, rather than implementing a global content management system of my own?

Only about 30% of the features in today’s GMS are actually used by customers

Otter: As I mentioned earlier, we have supported customers for a long time in this area by providing technology to enhance their workflow. We truly believe that a lot of the features in today’s GMS are not used by most clients – probably only about 30% are used. What happens is a company invests to build a team to implement the system. Often, these systems become enterprise software that no one understands anymore – perhaps with just one project manager or a translator left who knows how to use certain functions that they need. Yet, the company must still pay license/usage fees for a solution which no longer adds any value.

Based on our research, we believe that there are less than 50 companies worldwide who need a huge, installed GMS. At the other end are users who depend on lower-end portals from language service providers. thebigword is positioned to meet the needs of the users in the middle.

We’re offering GMS as a service … with service

Our goal is to obviate the need for our customers to hire people to run a GMS – we like to think that we’re offering GMS as a service, with service. Our customers rent the software and pay for only those capabilities that they need. We want to give the client control of their projects, without their having to be specialists at analyzing and developing additional functionality. In other words, expertise on-demand when they need it.

Here’s a concrete example of what I mean. Let’s say that your original GMS developer provides thirty file filters included with the initial implementation. The 31st filter will still require someone to develop and maintain it. Either you must train your people internally to do this, or you must convince and pay your developer to do it for you. With our model, we have a worldwide engineering team that is very motivated to respond. In fact, we encourage our customers to send us any file format, and we’ll deal with the file formatting. Then we’ll share the solution in future releases with other customers.

There is also another important future benefit to this adaptive and collaborative way of working. When the new commercial versions of LanguageDirector become available, our customers don’t have to wonder if their previous customizations still apply. We update our technology every 2 months, and the monthly fee automatically includes these updates.

It’s important to understand that the LanguageDirector family of products is offered as an SaaS service (Software-as-a-Service). This means that the core set of features are free to any of our clients. There are services that we charge for on a monthly basis, and customers have the flexibility to select and use any combination that they wish. The chargeable services include CMS integration, eProcurement integration, the distributed TM function, use of the online language review tool and use of the online terminology tool.

What’s great for customers is that they can pause or discontinue a service as their needs require. For example, they may need CMS integration for only a month, but online terminology access every month. The bottom line is that we don’t want a customer paying for a service they’re not using. This even applies to CMS integration – we don’t start charging for the CMS use until it’s configured, implemented and actually being used. In other words, we take the risk (unlike some of our competitors who charge from day one).

Insider: Is LanguageDirector based on open standards? If so, which ones? If not, why not?

Otter: Right from the beginning, we’ve tried to bring in best-of-breed (I hate that term, but it applies in this case), to aggregate the best off-the-shelf technology. We want to give our customers choices. This means, for example, that we provide an API to perform auto cleanup and analysis of TRADOS memories. At the same time, we also support STAR Transit. We still receive Word 97 files, for example, so we must continue to support legacy file formats at the same time that we continue to offer new technology.

We have to maintain a balance between old and new technology capabilities

XML is an example of newer technology. We are now partnering with XML INTL, whose technology is based on LISA standards, to integrate XML into our product line. At the same time, we are providing lots of real-world input to XML INTL, allowing them to enhance their technology to be applicable to customers’ real needs. This will provide more tools for our toolbox, as well as for our customers. For example, it will allow for TMX exchange between two TM systems. It makes more sense to use Transit for some of the DTP formats, than it does to use TRADOS, so this capability will address that issue.

The balance we maintain between our flexibility to handle older workflows, processes and formats vs. offering the latest in technology to meet more advanced user needs is an important one. This means, for example, that we may be 50%-TRADOS based in the future, rather than 75%-based.

To answer your question specifically, as of the current release of LanguageDirector, we now support TMX and TBX-Basic. We will very shortly support GMX and XLIFF through the XML INTL integration.

Insider: What are you missing from the standards bodies to enable you to fully support GIM standards?

Promotion!!

Otter: The first standard that comes to mind is Translation Web Services (TWS). We already had our own web services standard defined that predated the OASIS standard, and many of our customers have been using it since 2000. We worked with OASIS and did our best to move towards TWS. However, we found that we would have had to go backwards to be able to support it. In addition, progress on moving TWS forward was way too slow for us. In the future, we would like to see more work in this area and are more than willing to contribute again.

Clay Tablet Technologies is now essentially the middleware between CMS and TMS, since TWS didn’t really get off the ground. We are talking with them, but more players simply mean a more complicated process for our customers.

We are eagerly awaiting the other two components for GMX – Complexity and Quality from LISA OSCAR.

Along the way, we have also discovered that some of the standards are only frameworks, e.g., they need populating for each locale. The LISA Standard SRX is an example of this. The rules for each language are defined for only a few locales at this point. That was a shock to us, actually. In practical terms, this means that the standard really isn’t finished from a developer’s implementation standpoint since it’s not really usable yet.

However, even though some standards are not as complete as they would be if produced as proprietary standards through commercial developers, we firmly believe that we need standards to enable us to port assets between service providers. And we are more than willing to work with other groups to move current standards forward.

Insider: What 3 specific actions do customers, technology providers and standards bodies need to take over the next 4 months to ensure that you will have the information need to build a strategy and an action plan to support the applicable global content management standards within the next 12-18 months?

Otter: More completeness of standards, as I explained above, followed by consistent promotion to ensure that a few of the ‘big guys’ implement them.

---

Simon Otter is Group Technology Manager for thebigword, with overall responsibility for the technology and associated processes used to create efficient, integrated translation services. Otter previously worked for Ford Motor Company where he created localized public-facing software solutions. He is a Chartered IT Professional and Engineer and a Member of the British Computer Society.