An Introduction to Software Architecture for Product Managers
Technical Knowhow for Product Managers
Welcome to part six of a series of articles covering the technical knowledge that every Product Manager ought to know. Today I’m going to be talking about Software Architecture, and introduce some common principles and patterns.
If you’d like to learn why I think this knowledge is important, then head back to my article where I discussed WHY it’s important to work on technical skills in Product Management.
And don’t forget to subscribe to email updates if you want to be notified when the next article is published!
What is Software Architecture and how much do you actually need to understand?
A product manager doesn’t just identify user needs, but also ensures that the product meets those needs in a way that is scalable and maintainable. This is where software architecture comes into play. Software architecture is the process of designing and defining the fundamental structure of a software system.
Imagine software architecture as a blueprint for building a house, helping the builders (in this case software engineers) to know how to put all the pieces together. It acts like a map to define where everything is going. Without this, a part of the house may be built in a way that prevents the homeowner from making the changes they want to in the future.
Software architecture involves making decisions about:
- Organisation, implementation and functionality of software
- How components within an application relate to each other
- Which technologies and infrastructure to use
This is a huge area, and today I will just introduce the topic at the level of detail that a typical tech Product Manager would need to understand. In your role, you are likely to be collaborating with Software Architects who will be the primary decision makers.
Want to dive in deeper after finishing the article? I’ve included a (very!) extended reading list at the end.
Monolithic vs Microservice Architecture
Imagine playing with two different lego castles. One is built out of one big custom-made piece. The other is built out of 200 little lego pieces.
Whilst the big single piece might be exactly what you asked for at the time, it’s hard to make quick changes and updates to. Want to change the design of the master bedroom? Gotta send the whole thing back to the lego factory. This is like a monolith.
On the other hand, the castle built out of lots of little lego pieces can be easily taken apart. A section or piece of lego may have a specific job — like a piece opening and closing the gate, or the bed for the princess to sleep on — so if you want to modify or update just this one part, you don’t have to take apart the whole castle.
Monolithic architecture
Monolithic architecture is a singular computing network with one code base coupling all of the business concerns together. Monolithic architecture can make deployment and development simpler early on in a project.
However, as alluded to earlier, there can be issues when scaling. If you are modifying one part of the application, you will need to compile/test the entire thing. As an application scales, and there are multiple teams working on it, you may consider moving towards a microservice approach.
That said, it is not simply a matter of ‘monolith bad, microservice good’. When working with a small team, building out a proof of concept that is likely to require fast iterations, a monolith may make sense.
Microservice architecture
With the microservice approach, each service has its own business logic and database with a goal in mind. Changes, testing and deployment all happen within each service; this allows for accelerated release cycles and the ability to roll back specific changes. (More on this in a later article about the software development lifecycle)
Microservice architecture generally leads to faster development cycles, easier maintenance, and more frequent updates. They require thoughtful planning, and can be complex, but they can help teams manage complexity by seperating out different problems.
You can read an in-depth discussion of the benefits of Monoliths vs Microservices here.
One quote to leave you with from Zachary Crockett, CTO of Particle:
“When discussing microservices, people tend to focus on one end of that spectrum: many tiny applications passing too many messages to each other. At the other end of the spectrum you have a giant monolith doing too many things. For any real system, there are many possible service oriented architectures between those two extremes.”
Other Software Architecture Patterns worth being aware of
Here are some other examples of popular software architecture patterns.
Layered Architecture
This pattern involves dividing the software system into layers, where each layer provides a different set of services and a module is assigned to onle one layer.
The layers communicate with each other in a hierarchical manner, with each layer only communicating with the layers above and below it.
Many web applications use a layered architecture, with a presentation layer that handles the user interface, a business logic layer that performs data validation and processing, and a data access layer that communicates with the database.
Event-driven Architecture
Event-based design is a software development approach that is based on the concept of events. An event can be any significant change in the state, such as a user interaction, a change in data, or a system failure.
A simple example might be a customer placing an order online for an item. This might trigger three responses in other services: an email to the customer confirming, a notification for the warehouse team to pack and prepare the item, and an update to a database that manages stock so that they know that item is no longer available for sale.
In event-based design, software components or services are designed to respond to events that occur within the system or in the external environment. Event-driven architecture is extremely loosely coupled and well distributed. The former means that the event itself doesn’t know about the consequences of its cause. The latter means that an event can be almost anything and exist almost anywhere.
Check out the example from AWS for an e-commerce website here.
Service-Oriented Architecture
This pattern involves building a software system as a collection of services that can be accessed by different applications.
The services are typically invoked synchronously, meaning that the client application waits for a response from the service before continuing.
SOA is well-suited for building modular, reusable services that can be accessed by different applications.
Peer-to-Peer Architecture
Peer-to-peer (P2P) architecture is a distributed system architecture in which nodes in the network share resources and communicate directly with each other, without the need for a central server or authority.
Blockchain networks, such as Bitcoin and Ethereum, use P2P architecture to create a distributed ledger of transactions. Each node in the network maintains a copy of the ledger and communicates directly with other nodes to validate and process transactions.
Some Principles of Software Architecture
There are many different principles of software architecture, and you can read some in-depth articles (and arguments!) on the topic from software architects in the further reading list below.
However, I’d like to share with you a few important principles so that you can understand the kind of challenges that a solutions architect has to take into account when designing.
- Separation of Concerns — This principle states that software should be divided into distinct components or modules that each have a distinct responsibility or concern. By separating concerns, changes to one component won’t affect the others, making it easier to maintain and modify the system over time.
- Loose Coupling — Loose coupling is the practice of designing software components so that they have minimal dependencies on other components. Coupling refers to the direct knowledge one component has on another. When components are loosely coupled, changes to one component won’t affect others, making the system more resilient to change and easier to maintain.
- Modularity — Modularity is the practice of subdividing a computer program into seperate, independent and interchangeable sub-programs (modules), which group similar functions. Modular systems are more flexible, easier to test, and more maintainable than monolithic systems.
- Abstraction — Abstraction is the practice of hiding implementation details and exposing only the essential feature/purpose of a software component. Abstraction helps to reduce complexity, make software components easier to use, and increase code reuse.
- Encapsulation — Encapsulation is the practice of protecting the internal details of a software component from outside access. This allows you from having private data inside not exposed to clients, and also to change the implementation inside without bothering the client. It helps safeguard your designs from further changes.
Communicating Software Architecture Design
UML (Unified Modeling Language) is a standardized visual language used to model and design software systems. There are many different types of diagrams, but some that might be useful to a product manager involve class diagrams (used to represent the object-oriented view of a system) and sequence diagrams (visualising the sequence of calls in a system to perform a specific functionality).
When starting a new role, it can be helpful to study existing diagrams in order to understand how the software is structured. For example, what actually happens when a user clicks “save favourite”? Maybe a sequence diagram can help you better understand the calls that take place following this action.
There are many tools such as Draw.io or Gliffy that you can use to create and modify diagrams. They usually also have pre-built templates, if you are interested to see what some examples might look like.
I hope this has helped you get your head round what Software Architecture actually is, and the value that a solid architectural design adds to a product.
For the Software Architects reading; anything I missed, that you wish your PMs understood?
For the Product Managers reading; any other articles you’d like to share?
Want to improve your technical knowledge? I’ll be sharing articles every week. Here are the ones published so far:
- What Is The Internet?
- Tech Stacks and Programming Languages
- Cloud Computing
- APIs
- Databases
- Introduction to Software Architecture ← You are here!
Don’t forget to subscribe for email notifications to be updated when the next article in the series goes live!
Further Reading
General Articles
- The Software Architecture Handbook — freecodecamp.org (article) *this one is really excellent!
- 5 Key Principles of Software Architecture — Towards Data Science (article)
- Software Architecture and 5 Principles you should know — Article by iTechnoLabs
- 6 Important Software Architecture Principles — Better Programming (article)
- Key Principles of Software Architecture — TutorialsPoint (article)
- 23 Basic Principles in Software Architecture — Ali Zeynalli (article)
- Fundamental Software Architectural Patterns — Williams O (article)
- 10 Common Software Architecture Patterns in a Nutshell — Vijini Mallawaarachchi (article)
Microservices vs Monoliths
- Microservices vs Monolithic Architecture — atlassian (article)
- Monolith vs Microservices — freecodecamp.org (article)
- Microservices Explained: The What, Why and How? — TechWorld with Nana (video)
- Spring Modulith: Have we reached modularity maturity? — A Java Geek (blog post)
Deep Dives
- Loosely Coupled Architecture — Marcio Sete (article)
- Modularization in Software Engineering — Caitlin Jee (article)
- Modular Programming Increased Value — Infanion (article)
- Encapsulation — Prabal Cahkraborty (article)
- Abstraction — freecodecamp.org (article)
- Event-driven Architecture — AWS (article)
- Event-driven Architecture — Wikipedia (article)
- Event Driven Architecture: 10 Real-World Examples in Logistics — nexocode (article)
- The Bitcoin Network — Saylor (Article)
- Service-Oriented Architecture vs Event-Driven Architecture — Event Store (blog post)
- What is an API Gateway? — Kong HQ (article)
- Centralised and Decentralised and Distributed Systems — Geeks for Geeks (article)
UML diagrams
- UML — Standard Diagrams — TutorialsPoint (article)
- Types of UML Diagrams — LucidChart (article)
