What is Infrastructure + Architecture and Why Do I Need to Know About It?
Demystifying the Tech Side of Product Globalization
If you're in a tech adjacent role, infrastructure and architecture might sound like things only engineers need to worry about. Maybe you’ve heard “that won’t work because of our current architecture” or “our infra can’t support that” and you wanted to know more but were too intimidated to ask. This post is for you! Don’t be intimidated, approach this with curiosity. The more you understand the systems around you, the more strategic you can be in your work.
This post is a high level intro to infrastructure and architecture, tailored for folks in localization or roles that intersect with technical systems. I’m keeping this post beginner-friendly and including ways you can learn more. In my Deep Dive post at the end of this month (for paid subscribers), I’ll give a drilled down lesson into system design and common architecture patterns, plus localization specific resources. But for now, this is your jumping-off point!
What Is Infrastructure and Architecture?
Ok, let’s start with some basics.
Infrastructure is the foundation that systems run on. That includes servers, databases, networking, APIs, and services. Think of it as everything that keeps your tools up and running behind the scenes.
Architecture is how different systems are designed and how they fit together. It's about how tools connect, share data, and operate as a whole. Architecture can be very high level (just the big building blocks), or extremely detailed (right down to service calls).
If you're new to this, I highly recommend checking out this short video from Eric Kimberling. It's a clear, non-technical introduction to system architecture.
Side note, here are some rabbit holes you can go down on a rainy day:
How Systems Connect and Why That Matters
My husband is Italian-Brazilian, which means two things: he’s loud (but cute), and his coffee is sacred. When we first lived together, I thought I knew what good coffee was. I had a cute little French press and some grocery store coffee grounds. Life was fine.
Then he brought out the moka. Not just any moka pot - his moka pot, aged like a fine wine, seasoned from years of faithful service. But here’s the kicker: even with that sacred moka, our morning espresso isn’t always consistent (yes we still have it). Sometimes it’s chef’s kiss perfect: smooth, rich, lovely foam, strong enough to wake the dead. Other times it tastes like regret.
That’s when I started learning:
The grind must be just right…too coarse and it’s sad water, too fine and the moka clogs or makes muddy coffee
The water measurement is EXACT, and of course it has to hit below the valve (or else doom).
The flame must be low and steady: no high heat blasphemy.
Don’t even think about opening that moka before it cools down.
And don’t even get me started on the beans, where they’re from, if they were prayed over by a nonna, etc etc.
Living with him has taught me: good espresso doesn’t just happen. It depends on an entire ecosystem: the machine, the beans, the grind, the water, the timing, possibly the moon phase.
So now, when we go out and the cappuccino tastes off, he doesn’t blame the barista. He’ll whisper things like, “The water pressure was off,” or “This roast is burnt. Darker roast doesn’t mean better.” I just nod and thank my lucky stars that I get delicious homemade coffee every morning.
Don’t worry, this story has a purpose (lol): Most tools don’t stand on their own. Whether it’s a moka pot or a high-powered platform at work, understanding the systems around the thing is where the real magic and problem solving happens.
We recently moved to Milan, Italy where we are lucky to have fantastic coffee at home and when we’re out. Here’s a pic of our afternoon coffee at one of our favorite spots.
To understand how tech systems work together, I recommend The Principles of Application Integration video series from IBM. It is a bit older, but still a great resource. Start with this video, it breaks down how data moves across systems, and how those interactions are planned and managed.
Once you start seeing the connections between systems, you also start spotting the friction points. And that leads to ideas for making things better.
Why Localization Pros Should Care
So what does all this have to do with localization?
A lot, actually. Here are a few examples of how understanding infrastructure and architecture can help you:
The biggest one in my opinion: Spot automation opportunities. If you know how content flows through systems, you can identify places where manual work could be automated, steps could be combined or trigger for a certain step could move.
Understand where localization lives in your company’s architecture. This helps you troubleshoot issues, ask better questions, and advocate for improvements. As the localization expert, you know what the touch points are for your localization flows. When you understand how system architecture at your company works, you can identify places where pieces of architecture can or should intersect with your process.
Contribute to future planning. Once you understand the current setup, you can help shape what the next version looks like. Maybe that means proposing a content connector, or designing a better workflow for translation feedback.
Again, you don’t need to be an engineer to understand architecture. But learning the basics makes you a much more informed and effective partner.
Ok I’m convinced, How do I get started?
The best way to learn something is to jump right in, so I want to encourage you to step out of the theoretical and into a hands on exercise. I suggest getting started with something you know, so if you are a localization professional start by understanding the infrastructure and architecture of the way localization works at your company. Here’s a (made up) example:
*P.s. It doesn’t have to be perfect, this is a learning exercise, you got this!
**P.s.s. Everyone works differently, but for me I like to think about types of content and where they are coming from as a first step. However, you can organize information any way that makes sense to you! If you don’t know where data is coming from, you can start with a list of questions and then ping people to start your investigation.
This table shows us pieces of process, and within this process we can see pieces of infrastructure and how they fit together: architecture.
Build Your First Architecture Diagram
Once you have a list, start mapping out how the architectures is organized. Visualizing the systems you work with helps you understand how they’re connected, where information flows, and where your work fits in.
Check out this video for a quick how-to: Solutions Architect Tips: How to Build Your First Architecture Diagram
To build your own, you can use a variety of free tools (or start on paper and then transfer it to a tool) here are a few I have used and recommend:
Bonus resource: If you are feeling extra fancy and want to know how to make animated diagrams I recommend this quick video by amigoscode: Here's The Secret How To Create These Animated Diagrams
Ok, here is a high level *incomplete* example of how you could start mapping out the infrastructure and architecture of an imagined localization flow (which I created in Lucidchart, based on the above table):
When you start mapping it out, don’t worry if you don’t understand every tiny piece. Keep it high level to start, and as you investigate and grow your knowledge you can iterate on it and include more and more details. As you are creating the diagram, you may find that questions and ideas come up, write them down so you can come back to them later.
Here are some questions to ask yourself when you are mapping out your first architecture diagram:
What is the trigger that starts this flow/action? Is the trigger that initiates it automatic (i.e. step ends which triggers the next step)? Or is it manual (i.e. a developer creates a new branch)?
Where does this data come from? How does the system know ______?
How does the data get from point A to point B?
How are different pieces connect? If there are connectors, where do those “live”? Who “owns” them?
Ok cool, I created the systems diagram, how do I use it?
First: well you have to show it off. Share it with your boss, share it with your colleagues, share it with anyone who helped you while you were creating it.
Second: When you share this, include questions that came up: Ex:
I’ve been learning about infrastructure and architecture and decided to map out our current architecture for ________ as a learning exercise. As I was creating this some of the following questions and ideas came up:
I see an opportunity to create an automation that triggers _________.
I’m curious where __________ data is stored.
I wonder if the ________ API could also help us understand ________.
This architecture is overly complex, I am curious if there are steps we could skip or merge. I think there is a lot of opportunity [description of where you see opportunity to improve the flow]
This shows that you’re proactive, eager to contribute, and looking for ways to integrate your learning into real work.
Third: Use this as a jumping off point to set yourself a new technical goal and/or gain knowledge about the systems you work with.
For example, “I’m going to look into ______ API” or “I’m going to talk to someone on ______ team of engineers to understand how ______ connector works”
Fourth: See if there are places where this awesome systems diagram could live and add value for others. Maybe it’s a deck your team uses, maybe it’s documentation about your process, put it to good use!
Finally: Get curious about infrastructure and architecture outside of your immediate area. Now that you are expanding your knowledge, ask questions, ask if there is a systems diagram for adjacent architecture you work with, ask about how pieces work together! Add this to your conversations with stakeholders where it makes sense.
What’s Next? And subscribe for Deep Dives + more focused resources
Hope this was a useful one, I had a lot of fun putting it together! In the next two posts, I’ll go more in depth in two areas where I have grown my technical skills and been able to apply them in a meaningful ways in my roles:
What is i18n? How Can I Be a Resource for Engineers I Work With?
April Deep Dive: Let’s Talk Localization Infrastructure: What Do I Need to Know?
At the end of this month, I’ll release the deep dive I mentioned above for paid subscribers: “Let’s Talk Localization Infrastructure: What Do I Need to Know?” Subscribing is the cost of grabbing me a coffee, and it helps justify me spending a few Saturday afternoons creating these structured lessons. This Deep Dive will be a full on nerdy lesson summarizing what I’ve learned from 2 paid courses I took on infrastructure and sharing it in a practical way related to Localization specifically (i.e. how I’ve applied it and how you can too).
What did you think? If you enjoyed this post let me know in a comment, if you have questions throw them my way! If you have ideas for future posts drop them below.