Build Versus Buy for LSPs - Its When, Not if
From their earliest stages, LSPs face the question of whether to build or buy the software on which they run their business. Triggers can include the need for differentiation, the need to tailor work processes for different customers and job types, or the requirement to stitch together disparate systems for monitoring and reporting. The question of when to begin proprietary development is important because if they wait too long, they may miss growth opportunities. But jumping too soon can result in unfocused and wasted effort.
Interviews and analysis for a recent CSA Research report led us to conclude that LSPs must start developing software – if they hope to get to full maturity. We interviewed CEOs and CTOs at language service providers about their technology adoption patterns, then compared their plans to the LSP Metrix™ maturity model (see Figure).
We discovered that Stage 4 (Responsive) companies demand control and reporting capabilities on substantially all work they perform for clients. That means that they must figure out how to pull status and other project information from multiple commercial platforms for translation (TMSes) as well as interpreting management systems (IMSes). No TMS nor IMS can manage or report on projects being processed in another system, so monitoring work processes and gathering intelligence in multiple systems becomes a drag on operations and an obstacle to growth.
In earlier stages, LSPs experiment with low-risk development exercises such as filters, scripts, and other utilities for file processing, or increasingly progressive adaptation of open-source solutions. Then they move on to building discrete applications from the ground up. By the time they approach Stage 4 (Responsive), they face a bigger challenge -- integrating the reporting and control functions from the multiple TMSes and IMSes that they use to satisfy the needs of their diverse clientele.
At this stage, even the most cautious LSPs must take the plunge and start writing their own code. They build proprietary cross-TMS/IMS control components to enable what CSA Research identified as the company operating system (COS), to monitor and report on multiple production platforms or business units. The COS may include commercial components, but proprietary development is needed to create a cross-platform layer not currently supported by off-the-shelf solutions. Without this operational layer, they can’t achieve the responsiveness required to graduate to Stage 5 (Adaptive).
We are sure that there are exceptions to this pattern and that some ambitious software vendors, Plunet and Smartling among them, could still add this missing cross-platform layer. However, for now the only LSPs we find operating with this level of maturity build important parts if not all of their core system.
While it is always advisable to use commercial tools over sub-par bespoke systems, LSPs need to gain experience in software development. When should they start? CEOs and technology leaders can make better decisions on what and when to build by using the combined analysis and maturation roadmap provided by the LSP Metrix and the tech-savvy LSP typology.
About the Author