New technology developments are stirring up the language industry, but the buzz mostly centers around neural machine translation (NMT) and artificial intelligence (AI). Something else is afoot that most observers are not discussing: the shift from monolithic to distributed systems. Microservices addressed via REST APIs promise to increase agility by allowing swappable engines. During a recent CSA Research Colloquium at LocWorld, we put this new solution architecture in the context of enterprise business needs: Current systems do not adequately address the push to ubiquity for language support.

• Expanding access. As enterprises’ localization capabilities mature, greater numbers of workers gain access to language services and tools. The original translation management systems (TMSes) brought tools to the specialists working in localization departments. Portal-based interactions added “business users” to the mix, allowing content owners in other groups to request, track, and retrieve translated documents. The most mature global brands provide access via integrations and plug-ins so individual content contributors can interact with localization processes directly, without leaving their customary work environment. Ideally, every worker from the CEO to the factory floor can access spoken and written language tools.
   
• Embracing content. From legal and human resources to digital campaign teams, every new content type benefits from the application of stored language assets and localization best practices. Handling low volume, infrequent, and changing content sources proves to be a challenge for traditional localization teams and tools. Process flows incorporate video, social, apps, and a constantly shifting array of file formats. Whereas the current generations of TMS focus on web and technical information, today’s content output requires new filters, work steps, and human and machine resources in the mix. The variety of content types from a single department or business unit can be overwhelming. In large organizations, this creates a “triage” requirement for proper assessment of new job requests, even from known participants.
   
• Agilizing workflow. Expanding access and embracing new content types results in hundreds of workflows – beyond what a human can effectively manage. Next generation systems will include AI with machine learning to comprehend differences in time, quality, and resource requirements for translation requests and combine the machine and human resources in the right sequence to optimize accuracy, time-to-market, brand voice, and cost parameters. Traditional, standardized workflows are still relevant for some content types, while the newer, ad hoc style workflows common in digital campaign management must co-exist in the same environment. Some organizations, in addition to a dozen or more CMS environments, end up using three or more TMSes, internally or at key vendor sites in their supply chain.

So far, no CMS or TMS vendors have stepped in to fill this gap, leaving enterprises without a core business process controller to coordinate the heterogeneous content environment outlined above. Thus, several large organizations have addressed the gap by developing a proprietary “content bus” technology to shuttle files or strings from one system to another. A TMS cannot be an island unto itself. Rather than leaving global 3000 enterprises to develop their own systems, CSA Research asserts that commercial software vendors must begin to take this on
What does an enterprise content bus include? Here are the basic concepts:

• Business process core. This is the brains of the bus that stores the logic or AI for triage and workflow creation, with a plug-and-play architecture for language processing microservices and connections to other business applications and content environments.
   
• Triage logic. Ideally an AI with machine learning capability, this module would parse inbound content, including metadata, copy, media, and structure, to identify human and machine resource requirements and optimize workflow assignments.
   
• Workflow design. Another module takes the triage output and creates an on-the-fly workflow to best optimize the time, cost, and quality requirements of the job. Machine learning can pick up from user actions, either when a project participant manually alters the workflow or based on escalation events, to improve decision-making in the future.
   
• Business intelligence. Both the triage and workflow components can also connect to the stored results gathered from the CMS, TMS, and microservice engines.
   
• REST APIs. These are needed for effective connection management in distributed computing environments, allowing new engines to be added and old ones swapped out with minimal impact on the core.
   
• Microservices. While CMSes and TMSes provide on-ramps and off-ramps for jobs, microservices are used to process files internally. These can be TM, terminology, and MT routines, but also MT build configurators, language quality assessors, other QA checkers, style guides, and so on.

Rather than support hundreds of pre-defined workflows, moving to an AI-driven ad hoc workflow controller will help organizations manage complexity with greater efficiency. For job types that do require a specific system, using a locked-down workflow, the controller already knows to assign the job correctly – such a system does not preclude Taylorist activity, it’s just no longer limited to that model. Similarly, it’s not limited to a lights-out project management approach, but can handle all coordination tasks when appropriate. It doesn’t remove human actors, but learns from them and only requests input when and where their talents will improve the results of a process or task.