Field Notes: Connectors

Join Stephanie Harris-Yee and Erik Vogt for a comprehensive exploration of system connectors in the localization industry. In this insightful discussion, Erik explains why “just connect the systems” is far more complex than it sounds, revealing the hidden challenges and risks of connector implementations in enterprise environments.

Key topics covered:

• The complexity of connecting multiple systems with diverse APIs and specifications,
• Why connectors are fragile and how system failures can lead to missed delivery windows,
• ROI considerations and the hidden costs of maintaining connector infrastructure,
• Alternative approaches including direct API integration and middleware solutions,
• Best practices for implementation: discovery, tier matching, and maintenance planning,
• The role of AI in connector monitoring and management.

More “Field Notes” Episodes

Explore more topics with Stephanie and Erik in our Field Notes series, where we break down complex localization concepts into practical insights for industry professionals. Check out our other discussions on translation technology, localization strategy, and industry best practices.

• Field Notes: Are Fuzzy Matches Dead?
• Field Notes: AI LQA
• Field Notes: AI in Marketing
• Field Notes: From Idea to AI

LinkedIn Field Notes: Connectors

Stephanie Harris-Yee: Hello. So today I am back here with Erik to talk about a new topic, and this one is gonna be connectors. So some of you might be thinking connectors, what’s the big deal? And some of you thinking connectors. That’s right. So Erik, let’s start out. And people often say, just connect the systems. Why isn’t it that simple?

Erik Vogt: Yeah. Thanks, Steph. This is something that comes up a lot because in our industry we’re heavily focused on the translation part of the system of business that we’re operating, and it’s really not that simple. Of course, that’s a critical part of it, and that’s one of the reasons why we’re in this industry is to provide translations.

But when you think about the systems and how they need to connect to each other, the permutations start getting astronomically complex very, very quickly. So there’s hundreds of content systems. There’s something like 40 TMSs out there. Even if you’re only counting the major ones, there’s a whole bunch of

adjacent tools as well. So I was doing some back of the napkin math, kind of looking at the number of permutations out there of all the different systems that need to talk to each other in our industry. And it very rapidly hits tens and hundreds of thousands. And then there’s this natural inclination of buyers to say, oh, you have a connector for such and such.

And it’s not that simple. The implementation varies. There’s lots of customization on each of the different aspects. There’s also… the systems don’t necessarily speak the same language. So I was looking at inRiver for example. They have a entity driven, kind of, object level. And then XTM thinks about it in terms of jobs. Lokalise, maybe thinks of it in terms of strings.

Each of the approvals at each of these steps could mean different things. So publish, complete, approve. These things all have different meanings and there’s different depths of integration that’s possible. So generally speaking, there’s very few examples of connectors really being a plug and play kind of mindset.

Very often. They are very complex , and there’s a lot of gray area around what is and is not included in a what a system connection really looks like.

Stephanie Harris-Yee: Right. So you mentioned a few of the challenges, but it seems like there’s a lot of challenges around connectors and what are some of those that really make it so challenging to build them in the first place, and then also the maintenance aspect.

Erik Vogt: Yeah. Well first of all, the API is different. They, they differ. There’s REST, SOAP, GraphQL There’s some that are underdeveloped and they’re also continued to be developed. So as these systems evolve they add features that don’t necessarily stay stable. And if you build an automation, let’s say it’s handling tens or hundreds or even hundreds of thousands of transactions per any given time unit, one piece of those can silently go wrong or stop working correctly, then you might realize that you have a backlog that just builds up. The absence of something isn’t always a signal or you’re not even measuring the absence of a signal. And so the building of these systems can be very, very complex and difficult to maintain. The workflow alignment is very difficult. The maintenance is often underestimated.

There’s sort of this one and done kind of mindset and very often that doesn’t work out. So realistically, it’s probably worth considering if you’re talking connector, you’re also talking about 15 to 30% of the build cost per year just to keep it maintained.

Stephanie Harris-Yee: And then what would be the consequences, I guess, from a business perspective, if it does slip out of maintenance or it doesn’t work as expected?

Erik Vogt: Well, you can have situations as I, as I alluded to earlier, where any one of the steps could break the different integrations could break. Let’s say there’s a small change upstream or there’s a new use case that hadn’t been planned for, and then you end up with a gap and you can miss delivery windows at that point.

Not only that, but you can end up with a staggering backlog. There’s one project, that I was involved with years ago that had such a high velocity that it stopped, I think for a matter of 12 hours or so, and already at that point, the backlog took several days to catch up with just because the volume was… So you can end up missing product windows.

You could end up with the wrong locales, you could end up with outdated content going to the wrong markets. The compliance risks come from that. Generally the burden falls to PMs often to spend hours chasing files or fixing or reworking. And your ROI just evaporates in that case. So connectors are fragile and there’s revenue, there’s compliance and there’s some efficiency consequences to not getting the connectors working correctly. So then think about all these extra layers you have to put into it, to monitor. Not only, it’s not just a watch folder, it’s like, is there a file there or not? Now you have to know, is there not a file when you were expecting one or is there a file in the wrong format or there’s some input criteria which isn’t fitting the expected output and therefore we’re running into a situation where backlog can be largely catastrophic, very quickly.

Stephanie Harris-Yee: Wow. Okay. So it sounds like connectors might not be the best solution. Are there alternatives that enterprises are looking at that you’ve seen?

Erik Vogt: I think sometimes they’re looking at direct API integration, so many software providers, let’s say TMSs, will have any published API and a customer or a client can essentially hook from their system straight into these systems without a connector layer. That means, working with those API systems directly, you have more control

you have more tailored workflows and there’s really less vendor lock-in at that point as well, which is beneficial. You do need the engineering resources in-house to be able to configure those things. That’s something to consider. There’s also middleware systems out there, and I think some of the signals that we’re getting from TAUS and others is that there’s this discussion about orchestration.

They’re talking about, IPAs which is integration platform as a service. This is, there’s high level. There’s things like MuleSoft and Boomi and Workato. These are kind of high level business systems that kind of handle a broad range of different systems internal to our industry. We’ve got folks like Blackbird.io and then there’s domain specific systems like Lingoport that are focused directly for developer, as a developer extension.

But there’s, there’s a number of these kind of middleware providers out there that are angling to kind of be a hub that helps bridge different entities together. And then there’s content standardization. And I think cleaner input pipes lead to better output. Common exchange formats like XLIF and JSON are standard in our industry.

You’d be surprised at how many clients are still working with 1980s or 1990s to early 2000s technology, and they have these excessively complex, kind of, file management. Like just the simple process of separating what you wanna translate from what you’re not gonna translate, or being able to isolate workflows per different content types or different groups.

You end up with exceptions per language, exceptions per locale. Exceptions per product line. Companies buy these other different companies over time, and each one has legacy systems. Each of these systems can get very complex, so I think for anybody who’s confronting the complexity of their system and looking for a connector, one good way to start is how are you inputting

things into the pipeline, into the workflows that are downstream from that, both TMSs, CMSs, LSPs, all these different players thrive and optimize around standardization. So that really makes a big difference in this approach. So there’s a opportunity for a API first approaches really focusing on building strategy and getting kind of the right integration approach from the ground up.

Stephanie Harris-Yee: So do you have any other tips for someone who’s just, they know they need some sort of integration. Besides kind of going through those basic steps you’ve already mentioned, is there any ideas on how to approach this in a smart way?

Erik Vogt: I will always say this, start with discovery. Start with a honest conversation about what the what, what are you really dealing with? What are the options? And very often this is a much more complicated thing than it looks like upfront because a key stakeholder may be on a localization team may need to be working upstream with different internal teams that they’re dependent on, some of whom may or may not be motivated to be particularly helpful.

It’s, it’s the reality of business, like sometimes you have to kind of work on this, but a structured approach really helps. And so I’m working on a questionnaire to really define scope and ROI potential in any conversation with any customer with regards to our integrations, but I think in general

this is a good approach. Build a questionnaire, build a system for setting expectations for what’s possible. The second is like match the tier need. The basic MVP might be $15,000 – $20,000 of investment to try to build a custom connector, it goes up from there. Mid range might be up to $80,000, a $100,000 maybe for enterprise implementations.

And it can be much more than that actually. It depends on the complexity and the velocity of the systems, but think about what you’re building for and start with the right approach for the right situation. Plan for maintenance, that maintenance is necessary. And then as always, aligning stakeholders and really defining what you’re talking about when you mean connector, it’s not just system A versus system B. And the ROI of each of these needs to be against something. So think about what is it currently costing to get something done? And you might think, well, it’s costing a PM 20 minutes a day, or four hours a day, or it now I need a team of six project coordinators to be shuttling files around. That starts the conversation for what that ROI looks like, and now you can think about your long-term objectives from there.

Stephanie Harris-Yee: So what about AI? Does AI factor in here at all? Does it help? Does it hurt? How does it come into this whole situation?

Erik Vogt: It’s a really good question. It’s as tempting as it is to think about AI in this context of file management and task assignments. It’s really important to consider that AI and especially GenAI, which is the thing that we’re focused on the most these days, is not highly deterministic. It can get you close

to your target, but often you need a person to make a decision. So you might use AI to monitor an existing connector to look for anomalies, for example, but it’s when you need a workflow to work a hundred percent of the time where at 99.9% efficiency, then you need something a little bit more deterministic and a little more structured to get that level of confidence.

And we don’t really want creativity here. You want reliability. So as a result, AI be is a little less of an emphasis when it comes to connectors or systems integration. It doesn’t mean it doesn’t have a role to play within specific systems. So, for example, thinking about booking. An AI that say helps you with picking up flights for, for travel.

AI can be good at identifying, taking your input natural language criteria to specify a particular parameters for a flight. But you still need somebody to make a decision about whether or not that flight is the right flight or not. And very often the number of permutations there are actually quite large. The number of possible fights, willingness to go through certain hubs, you know, it just adds up.

So I think in general, AI can play a role in that selection process as a filtering criteria, but it’s not necessarily the right way to think about orchestrator models except in very narrow circumstances, which those who are familiar with the space could explain. I would be happy to explain this in more detail on a particular instance.

There’s just too many permutations to get into right here, but in general it’s a good idea to be thinking about it. But when it comes to connectors, it’s a little bit boring, but it’s really important to get it right.

Stephanie Harris-Yee: Any last words or thoughts on this topic?

Erik Vogt: Sure. One connectors are super powerful. I mean, they’re enablers. But they’re not magic. So enterprises, we really need to weigh your options. And that means looking at API options. Look at middleware solutions, look at standardization with an emphasis on that last one. Because believe me, number one, so many problems could be solved with strong standardization upfront.

And I mean standardization, not just in terms of file standardization, but just standardization in terms of what the expectations are. How are you defining your terms? What are the process steps that you’re trying to deliver here. What does quality look like? What does a review mean?

What are the choices that a human in the loop can make in a particular station, in a workflow? How does that work? The goal here isn’t just to move text between systems. It’s to really look at a sustainable, scalable, multilingual content operation thing. So before you build, ask the right questions.

Start with a discovery framework. And then have a deeper, more focused conversation about how to make the specific business processes more efficient, one step at a time.

Stephanie Harris-Yee: Okay, perfect. Well, thank you so much, Erik.

Erik Vogt: Thanks Steph. Look forward to next time.

Share this post