Architecture vs. tech stack
What’s the difference? What’s common between the two?
One of the questions I ask folks occasionally when they talk about their role or project they work on as full-time employees is to talk about the architecture and the tech stack. And I found that those two things tend to be confusing to people. So I thought I’d try to distinguish the two.
Imagine that you’re a software engineer and you’re joining a new team. There are two onboarding sessions on the calendar: one about architecture of the system and the other one about the tech stack. What kind of information do you expect to get on either of those?
Architecture
Talking about system architecture, people usually use the words “components” or “moving parts”, sometimes also “behaviors”. They recall the books Building Evolutionary Architectures and Domain-Driven Design, they talk about suppleness and fitness. When it comes to practical terms, we also talk about the inverse Conway maneuver and how each team contributes to the system by holding together a small part of it, usually a handful of components, such as microservices and databases. Finally, we end up talking about layers, — somehow every architecture I’ve discussed in the past 5 years could be, without exceptions, expressed in terms of layers.
If we’re lucky and go deep in the discussion, we end up talking about emergent behaviors, using expressions like “how things work” and “how things break”. I think the latter is very interesting, because it’s much harder to explain why an architecture is robust than it is to describe a happy path. Which then explains why the software architecture work is so important: it also is, in some way, a failure prevention exercise.
And we often talk about seams, or what happens between the components of the system. This, too, is part of the architecture.
Tech stack
When discussing the tech stack, we talk about technologies that are used to make the system work and to make it possible to change it (as in, engineers writing code and such). Typically the topics of shiny new tech vs. boring tech come up, which leads to a discussion of history and evolution of specific tools, and how they vary in terms of the problems they solve, the gotchas the have that seem to travel at job change’s pace via folklore and people telling each other stories.
Specific technologies is the topic of discussion when we talk about tech stack. Since I mostly revolve around web frontend tech, I get to talk a lot about TypeScript, and React, and all the awesome tools around that. We talk about the frequency of changes, cost of maintenance, how to use them idiomatically, and fml moments that happen after months and sometimes even years of incorrect usage of a particular technology. Although there’s usually a fair amount of talk around databases and serverless which do, technically, take a spot on the stack, too.
When it comes to changes, a typical conversation revolves around how easy or hard it is to change a stack at a certain stage of the evolution of the company. We talk about code rewrites, the small ones and the massive ones. And we pick on specific technologies and think how to craft a tech stack in a way that it contains the least number of technologies that allow for everything that software engineering is going to need now and in future.
Architecture vs. tech stack
Both architecture and tech stack have a few attributes that make it harder to distinguish between the two. Either of the two has a learning curve, can make similar impact on the product (like, break stuff or speed it up 2x), and can follow industry practices (or not).
Both are hard! It takes a lot of time to really grasp architecture and it takes a lot of time to master the tech stack. Sometimes it’s not even pragmatic to spend time trying to comprehend the entire thing, especially when impact of an individual engineer is likely to be small and local, when the org is big.
And both evolve over time, driven by people making choices and solving problems. Architecture changes when teams inadvertently (e.g., as part of an experiment that accidentally made it to production) or purposefully (e.g., as part of rearchitecture work) change the way different parts of the system work together.
But then, if the result of picking a tech stack affects you mostly at build time, the result of architecture work affects you mostly at run time.
If you get asked about architecture, talk about the moving parts in the system and the layers. If you get asked about the tech stack, well, describe the tech stack. When (actually, before) you’re getting people on board at your team or you’re talking about your company’s software on a meetup, it might make sense to put some effort into documenting both of them, but I think it’s a much more practical investment of time to prepare short 1–2-minute answers to both questions and anticipate follow-up questions to go into specific details without trying to cover everything at once.