Software Architecture Unveiled: A Series by Igor Fraga

Welcome to a series of articles meant to shine a light on the everyday life of a software architect. My goal is to bridge the gap between complex architectural topics and practical, real-world examples. Each article focuses on a key aspect of the role, told with stories and lessons that are immediately useful.

If you noticed, I’ve rebranded the blog to bring you much more content about the architect role that is part of the everyday live of a software architect, along with the technical content and career that I usually share.

So, let’s get started with our very first article:

What Does a Software Architect Actually Do?

If you ask someone on a software team, “What does a software architect do?” you might get a confused answer. Some might say, “They’re the most senior developer.” Others may say, “They decide how our systems are built.” There’s truth in both, but the real role goes deeper.

Guiding the Technical Ship

Let’s imagine a story.

A group of friends wants to start an e-commerce company. They have a great idea: a platform where small local sellers can easily open online shops. The budget is tight, and the timeline is even tighter. The team hires developers, designers, and someone with the title “Software Architect.” Let’s call her Ana.

Most people on the team write code every day. Ana does too, but she spends a lot of her time doing something different—she listens.

She listens to the business founders talk about goals:
“We must launch before Christmas!”
“We expect 10,000 users in the first month!”
“We absolutely can’t lose any customer data!”

Then, she talks with the developers:
“What framework will let us move quickly?”
“How do we keep the platform secure?”
“What will happen if traffic doubles?”

Drawing the First Map

Ana’s most important work happens before the first line of code is written. She creates a map for the project—just like a captain charts the course before the ship sails.

This map is called the architecture:

  • What pieces need to be built? (Shopping cart, user accounts, payment processing…)
  • How will these pieces talk to each other?
  • Where is data stored?
  • How will they grow if thousands of users join overnight?

Ana chooses the structures and technologies that make sense for the team’s skills and the company’s goals. Maybe she recommends using a cloud provider, so the website can handle big traffic spikes. Perhaps she picks a simple, secure payment system because speed and safety are crucial.

Making Hard Choices

Sometimes, the business wants everything perfect and fast—but that’s impossible. Ana explains that to add new features later, the foundation must be solid now. She draws a line between “must-have” and “nice-to-have,” making sure the team is focused.

Once, in this e-commerce story, a founder says:
“I want video reviews from buyers, right from launch!”
Ana explains: “That would need lots of servers for video storage. Let’s start with text and photo reviews, and add video later when we’re ready.”
By saying “no” to some requests, Ana keeps the project realistic and on schedule.

Communication: The Secret Ingredient

Good architects are also translators. Ana writes clear documents and draws simple diagrams. Developers understand where their code fits in the bigger picture, testers know what to check, and business leaders see how their goals are being built in, and the way you talk to each of these groups, from business to developers, is completely different.

For example, when Ana shares a big diagram showing all the parts—and which are most important for launch—everyone feels calmer. The road ahead is clearer.

Responsible for the Big Picture

When the website finally launches, and people start shopping, Ana is still there. If bugs appear or traffic surges, she works with the team to fix things—always thinking about how today’s solution will impact tomorrow.

She teaches the team to ask, “How will this change affect everything else?” She helps make the system strong, secure, and able to grow.

In Summary

A software architect is more than a senior developer.

  • They are map-makers, guiding teams safely through unknown waters.
  • They listen, translate, and make hard choices.
  • They focus on the big picture, so every part works together smoothly.
    And while you may not always see them writing code, you always feel their impact—through systems that are strong, clear, and ready for the future.

In my next article, we’ll see how architects help business and tech teams speak the same language, and why that matters so much.

See you in the next post!