Software Architecture in a Nutshell

Understanding Modern Software Architecture Through Real-World Structures

In my earlier posts, I used building construction to explain software architecture. Buildings and software share a lot in common, even though they're obviously different things. If you're curious about that, you can find links at the end of this post.

Today, I'll keep using construction as my example, but from another angle.

If someone asked me to describe architecture using only one word, I’d say structure.

Structure matters whether you're building a house or creating software.
As an architect, I make structural choices all the time. Which component should handle what job? Where should we put different parts of the system? But am I the only one making these structural choices? Not at all! Engineering managers shape how teams are organized. Product managers figure out how to structure products and features.

The real trick is bringing all these structures together, creating something that actually works.
A challenge accepted :)

From Buildings to Systems

Every big project starts small, with some fundamental choices. If you're constructing a building, you begin by deciding whether you'll use concrete, metal, or wood. These choices shape everything that comes after.

It's exactly the same with software architecture. Instead of materials, you pick programming languages, frameworks, databases, and hosting environments. Each choice opens up certain possibilities and closes others.

After choosing materials, you define the actual structure. Buildings have clear components: floors, rooms, walls, etc. Everything has its place and purpose.

Similarly, in software, you have a clear structure too. At the top is the system itself. A system typically provides major functionality that is valuable enough to be used directly by customers. You can think of it like a complete product. It might interact with other systems, but it should be valuable on its own.

Within a system, you have services (or modules). These are smaller parts responsible for specific tasks. Each service consists of even smaller pieces called components. Components are often the smallest meaningful architectural units, though you can break them down further if needed.

For particularly complicated systems, you might even add another layer—sub-systems. This whole structure matches the idea behind the C4 model very neatly.

When Systems Work Together, They Form a Solution

What happens when we have more than one system? Sometimes we face a complicated problem that requires several systems working together to fully deliver customer functionality. In software architecture, we call this a solution.

Think about buildings again. Usually, a single building doesn't exist in isolation—it's part of a neighborhood or a city block. Along with buildings, you have streets and essential services like water, electricity, and communication lines. All these pieces must be carefully planned, or you'll end up with the telecom workers accidentally hitting a gas line and causing a disaster. You must also plan for things like schools, hospitals, and fire stations. If you've ever played games like Civilization, you know exactly what I’m talking about.

Unlike construction, planning software solutions at this same level of detail are much more complex. Solutions typically include several applications, each providing services to users. Each application is composed of application-level services. The tricky part is mapping these applications and services back to the systems that support them.

In simple cases, each application service directly corresponds to a single system. More often, however, multiple systems combine to support one application, creating complex relationships. In the worst-case scenario, you might end up with multiple applications sharing multiple systems in a confusing web of connections. As an architect, I always try to avoid these messy many-to-many relationships because they're challenging—and expensive—to fix. But sometimes, especially when working with existing solutions, we just have to accept the reality and do our best to bring order to the chaos.

Thinking at the Enterprise Level

Let's go even bigger now. Several city blocks together form a city. At this scale, you must consider large-scale infrastructure like electricity, water supply, and city-wide emergency services.

In software architecture, we also have this "city level," which we call the enterprise. At the enterprise level, software architecture connects directly to the business. Now you're thinking about bigger concepts like products, offerings, and the business capabilities that power them. You'll hear terms like value streams and business domains a lot at this level.

Frameworks like TOGAF and ArchiMate try to provide structure here, but honestly, I find this level still quite vague in many organizations. I'm actively exploring better ways to understand and define this clearly, so, frankly speaking, it’s still a work in progress.

The Public Cloud as a Case Study

Let’s look at a real-world example of something incredibly complicated—the Public Cloud.

As you can probably guess, many different systems work together behind the scenes. But let’s simplify and start with the foundations.

At the enterprise level, everything boils down to three main business capabilities: Compute, Storage, and Network. Each capability has several products:

Compute

• At the lowest level, you have basic virtual machines (VMs or EC2 instances).

• Building on top of these, you can create containerized environments like Kubernetes or ECS.

• At the highest level, you have fully managed serverless solutions like Cloud Functions or Lambda.

Storage

• The simplest storage option is disks attached directly to VMs.

• Next, you have managed databases like AWS RDS or Google Cloud SQL.

• You also have serverless databases such as AWS DynamoDB or Google BigQuery.

• Finally, there are serverless blob storage services like AWS S3 or Google Cloud Storage.

Network

• At the basic level, networks are structured into VPCs (Virtual Private Clouds) with subnets.

• On top of this, you’ll need network middleware like firewalls, load balancers, and DNS services.

• Additionally, connectivity between VPCs or other clouds or on-premises networks is established via peering, direct connections, or VPNs.

At the solution level, the Public Cloud offers various "Cloud Services," each of which is a solution in its own right.

Some services are straightforward and foundational, like EC2 (compute instances), EBS (storage disks), or VPCs (networking). Others are more complicated. For instance, a managed database service would typically include multiple applications, like provisioning a MySQL or a PostgreSQL database. Each application provides specific database functionality, but both rely on underlying EC2 instances (for compute power) and EBS volumes (for storage).

The system level is incredibly complex. Even something seemingly simple like EC2 involves numerous systems: managing physical servers and racks, network communication, and interacting with storage infrastructure. At this level, complexity skyrockets, and the details are mind-blowing—but that's a story for another day!

Why Structure Matters

Structure is probably the most critical aspect of architecture. Why? Because the way you structure something directly impacts what you can and cannot achieve. Structure helps (or hurts!) how your system handles important things like scalability or reliability—what we call "non-functional requirements."

The good news is we don't have to reinvent the wheel each time. Most fundamental structures are already well-known. They're called architectural styles, and each style clearly enables or restricts specific characteristics of your architecture.

But here’s the tricky part: aligning your software structure with how your business and teams are structured. Usually, these form a hierarchy:

• It starts with the structure of your business and products.

• That influences how your product and engineering teams are organized.

• And finally, according to Conway's Law, your software structure naturally mirrors how your teams communicate and organize themselves.

If you ever want to "fix" your architecture, don't just look at your code. Instead, focus on your organization's structure. Real, meaningful improvements to your architecture almost always start by adjusting how your teams work together.

---

What’s Next

In future posts, I’ll talk about those architectural styles and how they shape the systems we build.

Subscribe and stay tuned.

Want to learn more?

🎓 Check out the course: Modeling, Viewpoints, C4
🌐 Follow us on LinkedIn: Software Architecture Guild
📖 Explore the Free Guide: Jump to Website

Want to Explore the Analogy Further?

If you're interested in how software and construction architecture compare, check out these earlier posts: