Solutions Architect Chat with Erik Vogt

Solutions architects in the localization industry are akin to bridge builders. We all need them to design something sound and reliable we can use daily. Something that spans the gaps, supports heavy loads, and adapts to changing conditions. And if it’s elegant, even better. Just like sound localization workflows.

Solutions architects have always been indispensable, but their role is changing. So at the recent Solutions Roundtable, hosted by The Localization Institute, industry experts gathered to discuss how organizations can better align their strategies for success.

To dive deeper, I conducted an interview with Erik Vogt, Director of Solutions and Innovations at Argos Multilingual, where we discussed his main takeaways from the roundtable.

Stephanie Harris-Yee: Hi Erik. Thanks for talking with us today. You had the Solutions Architect Roundtable that happened last week. Tell us a little bit about what is a Solutions Architect? What is that role? What’s that whole thing about?

Erik Vogt: Yeah, the Solutions Roundtable originally started a few years ago, prior to the pandemic, and I think we, we did one roundtable during the pandemic, which was kind of an interesting prototype of what we did last week. But the general idea started with the idea of what is a solutions architect and how do you know whether one is doing a good job at it?

And this, this comes from years of working with solutions architects, myself, I’m managing them and setting up solutions teams and thinking about how to take, just sort of a roughly formed person who’s good at problem solving. How do you formalize that to make it a little bit more of a predictable and understandable profession?

If you’re hiring a solutions architect, what should the job description be? If you are a solutions architect or you want to be one, what kind of skills should you have to be able to come on? A very loosely formed job description.

But what’s interesting is that as we started this journey of trying to understand what a solution architect does and how do you know whether one is good, we got into how do you solve problems with complexity? How do you handle all these parameters of technology and language quality and management and these aspects kind of affect all of us.

It’s actually a fundamental business strategy conversation that affects us. Almost everybody. in the roundtable, we had representation from, solutions from a tech provider Konstantin Savinkov, who is part of Intento. We also had several folks who were solutions team managers.

Among them decades of experience of managing the solutions function within our organization. We also have clients who want to understand more about how to break down problems in the problem space of complexity and all the things that I’m talking about. The idea was to bring a multidisciplinary view to this that we’re not thinking just in terms of being LSPs. How do we tackle problems from a broader standpoint?

Stephanie Harris-Yee: Okay. What was kind of one of the big stand out things that came? I know AI, of course, is gonna jump into this discussion somewhere. Was that one of the big influencers, or maybe how the roles have changed? Or what were those big stand outs?

Erik Vogt: Well, a couple of big ones. One, I think that there was a CSA report a couple of months ago hypothesized that we may have seen peak localization. And by that meaning that the traditional language services industry has kind of reached a, peak. A pivot point, and it isn’t that it isn’t growing and that it’s not going to be dealing with more revenue total, but it’s shifting in terms of how this is going to evolve.

The traditional model, I think, is recognized as not being sufficient to be highly competitive in this current market. One needs to be able to take advantage of every tool at your disposal to be able to be competitive. And that means, you mentioned AI is an important part of it. It’s not just AI though.

One of the big lessons I think that I took away from it too, was that there’s a lot more to this than just AI. We still need to be good at everything we used to be good at. I mean, nothing has gone away. None of the skills that we really need to have expertise in have gone away. We just are adding another parameter, which is AI.

Another is that AI shows up all over the place. It’s not just about the improving the translation. That is one of them, and there’s lots of nuance that particular conversation, for example, one of the participants was a client side participant. They were prohibited from using AI in their normal business for security reasons. We were talking about RFPs and how can we make better RFPs that better represent what, what is needed. And then also how to suppliers respond better to those RFPs. That’s a big friction point in our industry. That where there’s a lot of work to put these things together, and it’s a lot of work to process them and a lot of work to respond to them and to make sense and use them in a way that actually helps improve the business relationship and the selection process. you know, lots of interesting conversations about RFP. But this particular individual wasn’t allowed to use this at work, but realized that they were missing an opportunity to get some great ideas for what constitutes a great RFP. They asked Chat GPT or another AI to make recommendations.

And if you have AI deployed during the RFP creation process. You also are seeing AI being used in the RFP response process, where You’re you want to either analyze the problem, the question, and the things that you ought to be considering in the RFP, but you also could be considering how to write it better, how to make it more fluent, how to make the whole thing more coherent.

Interestingly, one of the observations was that RPs are painful across the board, and that it’s confusing as to what is needed. Trying to put a square peg in a round hole. The metrics they’re looking for don’t meet the metrics that you have. You have to kind of do some work repurposing of the core value proposition to fit into some kind of question.

And that can create some distortions and less than ideal outcomes for everybody involved. AI can help us improve that. That translation layer, it also can help us, of course, with some of the key core processes that we have. In engineering, you need to parse a new file type, or you need to write a quick script that will do a QA of a certain kind of a thing, we’re able to process those much more quickly with AI.

So, it’s showing up all over the place as a way of accelerating certain kinds of activities, not just in the translation aspect of our industry, which I think we tend to be absorbed with quite a lot. Our industry is also deals with complexity, the handling of the vast number of different potential parameters that affects what we’re doing from the systems along the whole. You know, the whole value chain, to the constraints, to different info sec industries, different resource types, the global supply chain management, managing different kinds of quality expectations in these different kinds of environments with systems that may or may not be particularly internationalized.

It adds up.

Stephanie Harris-Yee: Yeah,

Erik Vogt: We clearly see a lot of opportunity to get all the help we can and AI is one of the ways that we can tackle all this complexity.

Stephanie Harris-Yee:  Yeah. It sounds the industry is just getting more and more complex. And we’re even seeing, I know just Argos made an announcement that we’ve hired a joint solutions architect with Phrase. So, the TMS and an LSP hiring someone 50/50 in order to work on that complexity problem for their clients.

Is this something that you see as having to become more common with the growing complexity of the situation? Or is it more, this is a special case? How do you see that going in the future?

Erik Vogt:  Yeah, good question. I mean, I’m on record of being a huge fan of bridge building, I mean, I want to smooth the more barriers we put in between different entities, the friction there is between us and the end user goal. And by us, I mean a partnership between a client who has a globalization challenge, some technology, some human resources, some business process, business layers that are incorporated into into a particular solution. The more we can streamline our relationship and build the right levels of trust, the right levels of understanding, the more likely we’re going to reduce those levels of friction. Considering sort of visualizing a big screen full of these entities, And these entities are companies, but they’re also units within companies.

You can see an engineering team versus a quality team versus a business project manager team. The larger organizations get the more of these different entities who are trying to cooperate with each other. And building bridges and building ways of getting across these intrinsic silos that we create for ourselves inadvertently.

And nobody’s doing this on purpose. There are reasons why there needs to be different entities, but the complexity creates a lot of challenges. And this is kind of at the heart of my entire thesis here is that in order to break down this complexity into meaningful business values, you need to go back down to the root value propositions.

You’re trying to create something and build and understanding of how each of the components that you have in your system is adding value. You might need to get rid of some, you might need to simplify. You might need to rethink some of the assumptions that were true two years ago are no longer true because now there’s a different kind of way of approaching something. And you don’t want to lose sight of the fact that just because something’s new, it’s not automatically better. There might’ve been good reasons why things are the way they. You don’t want to throw the baby out with bathwater.

So, again, the solutions design is all about slow down, at the big picture, try to understand the root value proposition of what you’re trying to deliver, and then build up from there. Something from the ground up that represents a realistic view of what the best way is to get to the ultimate end goal that you’re trying to achieve.

Stephanie Harris-Yee: So, looking at the discussions that you had across this whole session, what were the main takeaways that came out of it? Were there any sort of recommendations for, if you want to be a solutions architect, you need XYZ, or if you’re hiring a solutions architect, look for XYZ. What was kind of the takeaways?

Erik Vogt: Well, one thing, I had a lot of trouble putting together my intro deck. The introduction to this. It was a kind of a survey of the space that we’re going to cover in the next two days of the workshop.  And I did that deck four times. I kept, I said, Oh, this is the thread. This is the story that I want. And then I was like, nah, it doesn’t quite click. And then finally, what I settled on that felt it resonated was you need to look at this through different lenses. What I did was start off with solutions as a problem solving methodology, kind of how do you break down problems?

And, there’s a guy named Thomas Davenport, who’s a business expert who has published a lot of stuff. And I picked up one of his business analytics papers in the Harvard Business Review a few years back. And basically I found this one anchor idea that really helped me think through this, which is that problem solving is a three stage process.

Understanding the problem, solving the problem, and then communicating and acting. And that is a lens. If you think about how do you break things down, you break it down by understanding the problem. You build solution candidates, you collect data, you analyze and you present solutions, and you action it. And you include kind of a feedback loop in that, but that’s not the only way to think about it.

Another is to get to the root value proposition of whatever thing that is, you’re being spending an effort on and that, ultimately boils down to the language of a return on investment. Kind of an idea of this effort will yield this output. And this output is worth it.

For some reason, part of it is cost reduction, which is usually where our brains go to when we’re thinking about ROI. But actually, our industry is more focused on enablement and differentiation and risk reduction as value propositions, enablement, meaning accessing global markets.

I think, Renato Beninato has mentioned a lot of times that we’re essentially an insurance business. And we, Language Services, is all about mitigating the risk of bad translations at this point and the effort of doing it right is about your brand and making sure that you can communicate what you intend to communicate. But there’s other lenses through which to look at it, looking at the lens of architecture.

If you use the metaphor of building a building and the of thinking about the foundations, the wiring and the plumbing is the data flow. The portals as access points and endpoints. You think about the purpose of why the building’s being built in the first place and building it to the appropriate scale.

There’s also solutions as a business function, and this is kind of thinking about it as where does it sit within an organization? There’s program owners, there’s a pursuit team and the sales team and there’s technology in some way. Solutions fits in between these other core business functions and creates value mainly through excellence in analysis and making other people’s job be more efficient.

It’s kind of that lens of things. I’m also a big fan of Osterwalder’s Business Model Generation Framework. That model helps think about how solutions can be a business analyst and also a business builder.

We’re sort of looking at the pieces that are required to offer something. There’s also solutions as a profession, and I think there’s different kinds of solutions architects. The solutions architects that might be focused on a high volume type of technology environment need technical skills that are very specific to the platform that they’re supporting. Solutions architects with very specific set of skills involved with optimizing, for example, data storage and transaction moving costs like data.

But there’s also a sales engineer function. There’s also a sales facilitator. There’s also a role as a teacher. And as a researcher. And then there’s kind of a an onboarding specialist, which is another kind of aspect of it. As we thought about that, we think about these different skills that solutions architects need to have. And came up with 10, probably a topic for another conversation, maybe more.

Lots of things. There’s also solutions as a part of the customer journey. There’s solutions as a bridging function. There’s a, there’s solutions is how do you build a better proposal? Like, how do you build a better RFP, RP response? Like, do you make, um, how do you do this? And we, we, one of the big reviews was this exercise. That happened a few years ago which we identified eight criteria of an excellent proposal, And we discussed what which of these correlates most with positive outcome of the event. that’s for another day, perhaps. But one of the benefits of having a bunch of passionate experienced people in a room together for two days is that you double click and triple click into really nuanced conversations that you could never get to if you’re trying to do this on a one hour conversation.

Stephanie Harris-Yee: Yeah. Okay. Well, is there anything else that came out of the, round table and your discussions that you think would be super interesting for people to hear about? And I hear you talking about further conversations, I’m sure we’ll have a chance to dig deep into some of the little niche ones later as well.

But for today, anything else?

Erik Vogt: Well, I just want to say thanks for chatting with me about this. I, as you know, will talk forever about given the chance. A passionate topic for me, but I really appreciate having the chance to chat with you about this. I think if I took any takeaway from this at all, is that, at a very high level, we are never going to run out of problems to solve.

Stephanie Harris-Yee: Yes.

Erik Vogt: Getting better at solving them, it can’t hurt. And not just for solution architects, cause this really wasn’t, and it ended up not being about solution architects. A solutions mindset or a solutions function within our organization. You don’t have to be a solution architect to be a solutions professional.

I will close on with that thought.

Stephanie Harris-Yee: Okay. Wonderful. Well, thanks much, Erik.

Erik Vogt: Thanks, Steph.