What Product Managers Should Know About Software Architecture
There is a reason why technologists borrowed the word “architecture” from buildings and blueprints.
Software architecture lays out what goes where and how it’s all connected.
While software architecture is designed by systems architects and maintained by engineers, there are some arguments for product managers knowing the basics of software architecture.
Improved communication between product managers and engineers, better product road mapping, and useful insight into time and budget are some of the reasons why a product manager should know a bit about this subject.
Here is our team’s perspective on what product managers should know about software architecture.
How Software Architecture Affects Product Experience
At the very least, product managers should understand why software architecture is vital to a successful product.
Summarized, a strategic software architecture ensures your product’s:
- Availability: Can users access your product when they need it?
- Scalability: Can your product scale as your userbase grows?
- Performance: Speed, uploads, APIs–is your product doing its job?
- Maintainability: Can your engineering team maintain your product as technology evolves?
Issues with architecture can create bottlenecks, which can dissatisfy users, slow implementation, or increase costs. Therefore, having a software architecture that supports your product’s functionality is essential.
Behavioral vs. Structural Changes
Within a system, there are two types of product updates.
- An update that changes the behavior of a function (on click:do this)
- An update that changes the structure of the system (both elements and the relationships between them)
In the product world, time is always scarce. There’s never enough time to do everything you want to, so product managers typically push for the changes they care about. That means structural changes are unpopular since they don’t change external behavior. In other words, if product managers can’t see the change, they don’t care about it as much.
However, software architecture is all about change. If engineers anticipate maintaining a program, there must be structural (nonvisible to product managers) changes. When these structural changes occur, they’re acting on a belief about how a system may change in the future.
Here’s a common analogy:
You want to install granite countertops (build a new feature into your application). Unfortunately, your existing cupboards are only rated for laminate, and can’t support the weight of the new granite.
In order to make granite countertops happen, you need to spend a month reinforcing the underlying structure.
You could have built granite-supporting countertops from the start, but that would waste money and time if you never put in granite.
Non-visible ≠ less valuable.
You Can’t Retroactively Collect Data
When planning products, it’s essential that product managers thoroughly understand all the types of data they need to collect.
That’s because systems have strict rules about communicating with one another. If your back end never requests a specific metric, it’s can’t collect it.
We sometimes see product teams forget about internal metrics. For example, many organizations have public promises around response times, so an example metric might be logging data (who did what, when).
If these metric requests are late in the development phase, functionality will need to be rewritten, costing time and additional resources. Worse, if v1 goes out, you may never be able to go back and get it. This kind of metric is easy to miss because there are “defaults” within databases. It’s the product manager’s responsibility to know the full scope of data collection.
There Are Two Main Types of Architectures
There is a range of architectural designs, with two limits on either side: monolithic and microservices.
A monolithic architecture is a single “stack,” where your front end, back end, and database share one server to suit all of the application needs.
With microservices, there are many servers (or serverless functions) that serve a particular purpose.
For example, let’s imagine we want to make a video streaming platform.
We will likely start with one server that will process logins and video streams. That means if there are too many people streaming video at once it could slow down the login workflow! Since we don’t want users to have a slow login experience, we break our monolithic server into two dedicated services: one for processing video streams and one for everything else (logging in, liking, commenting, etc.). This divided structure is microservices.
There are drawbacks to monoliths and microservices, but you should be able to understand why your software architect selected one over another. Think back to Conway’s law. It doesn’t make sense to have more microservices than teams maintaining them. For small teams, monoliths are much more beneficial.
When solving for speed and function, it’s helpful to understand these technical tradeoffs.
Ideally, when planning product updates and optimization initiatives, your architect should be involved. Since they know the current and future state of the architecture, they can give you instant feedback on the feasibility, timeline, and budget of any update which can be a massive time-saver for product managers.