| Renato |
With so many options on the market for translation management tools, it seems obvious that there should be one that meets all your requirements with minimal investment in setting up. The folks that Michael talks with today make sure these technologies function to their clients’ satisfaction. It is why a company providing technical consulting and development exists in localization. Enjoy this round-table discussion that covers APIs, connectors, MT integration and technology transitions within our industry. |
| Yan |
I’m Yan Yoo. I’m with Spartan Software. |
| Michael |
And Yan, what is your role at Spartan Software? |
| Yan |
I started the company. Nowadays, my main purpose is to make sure that the team has what they need to do their jobs. |
| Daniel |
I’m Daniel Chin with Spartan Software, I’m head of operations and I manage all of our client accounts and engagements. |
| Scott |
I’m Scott Schwalbach, and I run the customer experience at Spartan Software to ensure that our customers get everything that they’re looking for across the board, from the engineers, from the engagement. And then I also run our marketing. |
| Michael |
Yan, we worked together years ago, and I was asking you about, “Oh, you started your own business, what was that like? How did that progress?” and I said, “What is your management philosophy?” And you said something that really stuck with me, something that even I could understand. Do you remember that conversation? |
| Yan |
Everything starts with people and ends with people. My management philosophy is to, you know, do whatever you can to help people to be successful. |
| Michael |
Okay, the exact quote that I still quote you on is, “Hire smart people, put them in a room together and let them go.” [Laughter] |
| Yan |
That would definitely work too. |
| Michael |
Yeah. Let’s talk a little bit about the roots of Spartan Software. What do you guys do and how did you come about to where you are now? |
| Yan |
We mainly do custom development for the localization industry, for mostly enterprise clients. It came about because after almost eight years at Idiom, I decided to try something on my own. |
| Michael |
Yeah. |
| Yan |
And I had some experience integrating systems and customizing TMS for clients. So, there was a very natural way for me to leverage that background when I started the business. |
| Michael |
Yeah. And so, working at Idiom, that was really a turning point in the phase of technology in our industry. Before that, you had the TM technology that folks would use, and this moved more into a TMS world. So, that was a very formative time and most of the enterprise clients at that time were customers of Idiom, many still may be. |
| Yan |
Yeah, yeah. |
| Michael |
Yeah, and so, when you’re doing development and integrations, is Idiom’s product, WorldServer, still a part of what you’re working with? |
| Yan |
Right now, the bulk of our business is actually custom development. We do do WorldServer work; not the main part of what we do, but it is still part of the mix. |
| Michael |
Daniel, how did you end up into this mix? |
| Daniel |
Well I’ve worked with Yan for many years through the Idiom days. I stayed behind with SDL for a couple of years, then got out of the industry and got pulled right back in. |
| Michael |
We can never get away! [Laughter] |
| Yan |
That’s definitely my fault. [Laughter] |
| Daniel |
Well, I think at that time, what Yan mentioned is right. We were known for our WorldServer expertise and there were still a lot of companies that needed help with WorldServer, but I think that quickly evolved to custom software development because I think as WorldServer progressed, a lot of the users realized they needed a lot more beyond a TMS. And so, they started looking into other products out there and they realized, “Wait a minute, it’s not catching up to what we need.” And so, especially the bigger firms, they realized, “You know what, we can’t wait. Let’s just build what we need now,” and what’s better than using us who know the technology space and the localization space so well? So, that’s why I think we come in as a very unique party where, even though some of these companies have large engineering teams, they do not understand localization, they do not want to spend the resources or the people. |
| Michael |
Their engineers are looking to do new product features or whatever may be most interesting to them, and you guys bring a level of expertise and knowledge in the space that helps it be more tailored to what the needs are for your clients. Scott, you’ve worked on the tools side in the industry and on the services side, is that correct? |
| Scott |
The tool side, the services side, twenty years on the client side. I’ve been full-circle. |
| Michael |
What does customer success in the realm of tools look like? |
| Scott |
For Spartan, and particularly in this company here, customer success is meeting the needs on both sides of the spectrum that Daniel just alluded to. There is this need that the client has because there are the tools that the client uses that were developed without localization in mind. But, the content that those tools create needs to be localized. And how do you get it from Point A to Point B and through all the various systems and all the various people through the whole gamut? And a TMS only does a certain part of it, or a portal only does a certain part of it, and SharePoint can only do a certain part of it. Nobody comes up with a complete system. |
| Michael |
Let’s dispel one of the myths in the industry now and tell me why this is wrong. There are so many systems out there right now. I just need to find the right one that fits all my needs as a buyer. I need to have a good requirements list and go find that one translation management system that meets it all. |
| Scott |
Never going to happen. |
| Michael |
Yeah? |
| Scott |
No. |
| Michael |
Why not? |
| Scott |
You have to think about when I started: an IBM Selectric was technology. |
| Michael |
A what? |
| Scott |
An IBM Selectric, right? I mean, it was a typewriter that actually remembered what you typed, right, and it had a little ball that you could change for the different countries. That was technology. But, it changes as it goes along. So, as here we are in Silicon Valley, and as new companies come up with new technologies, new systems, TMS systems and those kinds of systems aren’t able to keep up with those kinds of things, there’s always a gap. And there will continue to always be a gap. We don’t standardize. What I produce is not the same as what this guy produces because that’s my differentiator. |
| Michael |
Is it as simple as some of these tools are really good for developers and integrating with string repositories and getting the content, and some are really good for translators? Is that the dichotomy or is it more diverse than that? |
| Scott |
It’s more diverse than just those two, right, because you have the developers, but you also have content creators, you have marketers, you have HR people, you have these people that are in health science that need government approvals. It’s more than just translators and technology folks. There are other things. |
| Michael |
Yeah. And then isn’t there this newer movement of, like, business process? |
| Daniel |
Yep, absolutely, yes. To answer that question, first, I think it’s broken down by content type. So, each content type from knowledge base to marketing, engineering, each one of them has a whole set of content management systems out there to service those groups. And each one of them has a different way of authoring content. A translation management system is now catering and becoming very specific to that one content type and trying to just service that group of people. And that’s how they get really good at that arena and that’s where we can find 5, 10, 15 of them fighting in that arena. And then we can see a whole different 5, 10, 15 of them in a whole different content type. And that’s what I see in the market today. And one of the problems is the fact that if you’re a new player in this space, it’s very hard for you to find the right tool. There’re so many tools you don’t even know what those tools are and which one you need, and there are so many different people coming at you saying, “I have the same tool; it’s good, too.” That’s one problem. But, going back to your question, on top of all of that, we’re in a time where we realize we have really maximized the whole translation memory, machine translation and how to reduce cost that way. |
| Michael |
Yeah. |
| Daniel |
And now we’re forgetting a lot of the admin time is now project managers managing 50 projects, 50 languages, and it’s not feasible for a firm to hire so many project managers to try to handle all these projects. And so, what we need is a smarter business process management tool that can actually assist project managers in making quicker decisions, and that’s the part that I think is kind of missing in the whole conversation. Everything is focused on TM, MT, all those things right now. |
| Michael |
Yeah, so back in the TM days, we were focused on file type, right, and making sure we could process particular types of files and get them back well. Translation management systems were focused on content type, right, so we can work with whatever the CMS may be. Now, there’s something else going on. Does this tie into the Agile workflow? Does this tie into the translation as a utility? |
| Yan |
If we look at most loc departments in large organizations, what we see, typically, is that between the content and the translation management system, the project managers are filling the gap, and sometimes Scott will tell us, “Feel bad for the project managers; you know, they’re always overworked and responding [to] very challenging timelines,” and all that. When I look at that, I kept thinking something is missing. And to answer your question, Agile is one reason; the sheer number of content management systems, that’s another reason. But ultimately, I think it’s just the amount, the volume and the speed and the type of content stream coming in create these extra problems that we didn’t see 10, 15 years ago when translation management systems started. |
| Michael |
Now, there could be sales people who might just say, “Well, you know, all of this is solved by API. We’ve got an open API, and, you know, we just connect with your open API and we’re rolling. Of course we can work that out.” You guys are all grinning at me when I say that. What’s the concern with that idea? Because there’re actually TMS tools that have a premise that we have an open API that can integrate with any system. |
| Scott |
Great! But the system has to be created with localization in mind. If localization isn’t in mind and you don’t have the right APIs pulling out the right information that’s needed for localization, from images to PDF types to whatever the XML that’s going to have to be filtered, where is the repository coming from, right? Their content strings, can I pull it out of whatever…GitHub, if it’s sitting in GitHub, if that’s where my strings are at? But, my marketing is sitting over there in Marketo, right? And my website’s sitting over in AEM. And I may be using MadCap for my knowledge base. And I may be using MindTouch over here for a different knowledge base. And if I’m in a large corporation, I can have all of those different tools. Half of those tools were never written for localization. So, you have to manipulate those APIs to even get that stuff out. |
| Michael |
So, the open API is like a starting place for systems talking to each other. |
| Scott |
Mhm. |
| Michael |
But that means there’s a lot more work to. |
| Daniel |
Right. I would say the best way to describe this, since we have done so many integrations: having API means you have the toll booth of the bridge. You need to build the whole bridge to get that integration. I want to dispel the fact that a lot of people think, “Oh, both have APIs; the connectors are easy.” It’s incredibly hard because you have to imagine, on each side, there are different landscapes that you’re trying to build a bridge and it’s always changing. They don’t care about that bridge that you’re building; I don’t care about you connecting to me. And so now, we have to design this whole bridge based on the fact that okay, you have some APIs. Now, how do we get data from one system to the other, also considering wider user experience and user interface, because it’s not just purely grabbing data and dumping it to the other place and back? And so, there are many, many integrations that a company needs to do, but at the same time they need to be able to go and monitor and be able to see what the traffic is. Now, this whole dashboard requires a whole new different way of monitoring the integrations. Basically, you have to imagine you have 50 bridges running. How do you track all the traffic? When you build integrations, you have to keep in mind the level of complexity. You’re trying to build a bridge between two places. You have to really think about how you can build that bridge. And so, I would say in terms of integration, just having APIs means nothing. |
| Scott |
And even after you build that bridge, all it takes for me is to upgrade my product, and now I’ve broken that bridge again. |
| Michael |
Would the bridge be the connector? Because you have companies talk about open APIs and then you have, “oh, but we have a connector to…” name the product. |
| Scott |
Right. |
| Michael |
So, the connector is the bridge itself. |
| Scott |
Correct. |
| Michael |
And then you upgrade that product and the bridge no longer connects. |
| Scott |
Correct. |
| Daniel |
Right. |
| Michael |
Gotcha. Gotcha. |
| Yan |
And also, I would say that, you know, in general, this is how we talk about it: connector does not equal integration. |
| Michael |
Tell me more. |
| Yan |
Connector is just moving files back and forth. To have the full user experience and integration, that encompasses, you know, all the tracking. You may even have financial information you’ve got to track, not just the files moving back and forth. You might have certain metadata or unique identifiers in a CMS that need to be mapped back to the TMS. So, it’s a lot more than just moving the files around. |
| Scott |
But you also may have to take that content and change it. |
| Yan |
Correct, pre-processing. |
| Scott |
So, I have to do something with it to get it in to this place, right? It’s not just a simple ‘put it on the highway and let it go.’ It’s not an autobahn, go as fast as you want. It’s got to go somewhere, it’s got to pick up its McDonald’s, have a good meal and then continue on. |
| Yan |
Yeah. If I can just add one thing, I think that some people say that, “Well, we have a connector so it’s going to work.” In most enterprise environments, they are customizing the CMS. |
| Michael |
Yeah. |
| Yan |
They are building their own templates out of [the] CMS. They’re configuring the CMS to fit their unique requirements. |
| Michael |
Which is one of the bonuses of the CMS, it’s like a feature… |
| Yan |
Correct. |
| Michael |
…that CMSs are selling. |
| Yan |
Yeah. |
| Michael |
“This can work precisely for your business.” |
| Yan |
Right, and they’re all going to do that. What happens is that it’s fairly difficult to build a connector that would plug into an enterprise environment and out-of-the-box would fit all those customized and unique requirements. Just probably not going to happen. So, you’ve got to do something with the connector to even make the integration work. |
| Michael |
Some of the reasons that companies come to you, is they say, “Hey, I bought this TMS, I’m super-excited about it, it met half my requirements and the connectors aren’t working. So, of the half of the requirements I thought I had, maybe a third of them are functioning.” And that’s when you all are brought in and engage and they say, “What do we do?” |
| Daniel |
Some simply don’t have connectors or integrations, so they will come to us as well. Those are the key factors. From an integration perspective, it usually comes down to one, they don’t have a connector or two, the connector works but it’s purely export/import of data. In reality, you need someone to have the whole use case built out from, “Hey, how do I request it? How do I go through all of these things?” |
| Michael |
You need to have conversations like “What is a project?” |
| Daniel |
Right. What is a translation request? |
| Michael |
Right? That’s a really philosophical, but that’s a very practical thing when you get into talking about the systems: is a release a project or is a file a project? |
| Yan |
Yeah. So, there’s definitely a level of consulting that’s required to make integration work. When I was at Idiom, I was in the professional services team, so when I started Spartan, that kind of became part of our business. Besides the engineering capability, when we work on an engagement, we provide consulting. Map out, like, what is a request, for example. If you have conflicting requirements from different stakeholders within a company, how do you make sure that everybody’s happy? You might have budgetary constraints, so you need some consulting to get these kinds of things working. It’s not just out-of-the-box software. |
| Scott |
But, the other part is, when you buy these systems, I’m not looking at it from an engineering aspect; I’m looking at it from a use case, right? |
| Michael |
Right. |
| Scott |
Can I put my knowledge base articles in it? Yes, I can. Will it connect to my translation system? Of which the sales guy goes, “Great, I got APIs, you can do it.” |
| Michael |
“Go for it.” |
| Scott |
Right? But, I have no idea what an API is. I’m not an engineer, I don’t know how to connect it, so I’m going to believe that there’s an API, and these wonderful APIs are just, you know, little rabbits that just multiply and do things, and that isn’t how that works, right? |
| Michael |
Yeah. You need to be concerned that APIs are magic, because they may not be. |
| Scott |
They are the magic mushroom of life. |
| Michael |
Yeah. One way that some of this complication can be solved is through standards, and there are different ways that our industry and other industries are trying to go about doing that. Seems like even just from this conversation, that’s going to be a lot of work to build standards for any of these systems to work well together. Another option is you build individual APIs, connectors, customize all of that. Our listeners love to hear about success stories and we’ve talked about how complicated this can be. Can you guys tell us about a couple instances where you really saw the benefit of the work you’re doing for your clients? |
| Yan |
A lot of clients come with a set of problems, especially if they’re a translation management system—usually WorldServer-specific—and it starts from there. That’s how the relationship grows. We go in there, we solve some problems. I would say most of our clients, they realize, “You know what? I really need an engineering team to be able to service my localization needs, but at the same time, I don’t want to hire a full-time engineering team because just the ramp-up itself will be tremendous.” So, we are basically their engineering team, and a lot of times, they have us basically on retainer because they know things will come. They may not have the projects or specifics yet, but they know there will be problems and they need us on-demand, and I think that’s where our value comes in. We are literally their extension, where any technical problems, they can throw at us and we can deal with, and that goes beyond translation management systems. In terms of catching up with the market, “Hey, what is MT?,” they can come to us and say, “Hey, teach me about these things and tell me where I need to go.” And I think that’s the part that we provide the most value. We actually start planning ahead for them in terms of what the technology needs to be, what do you need to have in your tool set so that they are prepared for all this content that is going to come through the floodgate. |
| Michael |
Being able to provide an engineering team without that being an ongoing or recurring cost and being able to use you guys on an as-needed basis would be a huge benefit. |
| Scott |
And it’s also different. You know, normally on an in-house engineering team, they’re there for a specific purpose, right? They do one thing and one thing only. Whereas as an augmented team that we are, they come to us with, “We’ve got this problem can you do this one but, vice-versa, this other group has this problem, can you do that?” And because we become that group that knows a little bit about everybody, we see the entire vision, and so we can go back and say, “Here’s how we’re working it through this part; let’s make it seamless through the entire company.” And so, we look at the longer-term vision, not just that short-term issue. |
| Michael |
And when clients engage you guys to talk about MT, what’s your philosophy? |
| Yan |
We go in as the integrator because there are many MT experts out there that really deep-dive and understand the ever-changing technology in that space. For us, it’s really making sure they can connect to a machine translation engine. |
| Scott |
We’re not there to replace their localization vendor who usually gives them the best advice and the post-editing and all that good stuff. We’re there to help them figure out the best processing system and where to put it in place, and, you know, what’s the right time and place in that workflow, and then how to connect it into that system. |
| Michael |
So, when they push that MT button, it works. |
| Scott |
It works and it goes to however, whatever which way they want to go. |
| Michael |
I think one of the benefits you all bring as consultants, as integrators: you’re free of the hard-core bias when it comes to products. And so, you can really look at requirements more objectively than sales people or even engineers from other companies and say, “This appears to be the best fit for you now and long-term.” And that can be a huge benefit to clients. |
| Scott |
And the other part is that when we talk clients, we always think of clients as the Microsofts, etc., those kinds of companies. But for us, clients are also localization vendors, right? They come to us with just as many issues as the other side does. So, we’re full-circle. Which gives us a little bit of advantage, again, because then we know both sides of the issues completely. |
| Yan |
Going back to the customer success question that you have, Michael, the couple instances that I was very excited about, one is that we have one client that…their project managers are so overworked. They already have a translation management system, but their project managers are still overworked. |
| Michael |
So, that’s like 90% of the companies in our industry. |
| Yan |
Right. And we built some system for them and after they went into production, they basically said, “I’m so glad to have this thing because now I don’t have to deal with all the spreadsheets and… [Laughter] |
| Yan |
…and moving data around.” And they were at a point they just could not scale anymore. Like, you can’t just keep hiring PMs, it’s just not feasible. |
| Scott |
Yeah. What was it you asked, the difference between a project and a…? |
| Michael |
A request, yeah. |
| Scott |
A request, right? So, I mean, a request can be, “I have this one English request. I need 42 languages,” and those 42 languages then become 42 separate requests that are then going to 42 different translators in addition to the 42 different reviewers in addition to the 42 different editors, before it all circles around and comes back. I mean, one project with 42 languages can end up being 600 people. With engineers and everybody else. But that one request person doesn’t think of the 600 people that are actively involved. |
| Yan |
We have one client that…they have a translation management system. They also had a CMS. They could not meet the launch deadline of two languages or two locales because it needed good integration. We were able to help them to launch those two locales within three months and after that, they told us that it was basically impossible to do it without adding 20-30 PMs. And we actually wrote a blog about it. It’s on our website. |
| Michael |
That’s great. What is the website so people can check out your blog? |
| Yan |
It’s www.spartansoftwareinc.com. |
| Michael |
My favorite question to ask you is: if you’re at a conference and people might be looking for you, what’s the easiest way to find you? |
| Yan |
I’m always wearing blue shirts. |
| Michael |
Yeah. You’ve got the Steve Jobs…it’s not a black turtleneck, it’s just a blue shirt. I love that! Thanks guys. |
