Understanding Software Architecture: A Guide for Product Managers
Written on
Introduction
Welcome to the sixth installment of our series focusing on the crucial technical skills that every Product Manager should possess. In this article, we'll delve into Software Architecture, highlighting key principles and patterns.
For insights on why technical expertise is vital in Product Management, refer back to my earlier piece discussing this topic.
What is Software Architecture?
A Product Manager's role extends beyond recognizing user needs; it also involves ensuring that the product addresses those needs in a scalable and maintainable manner. This is where software architecture comes into play. It refers to the process of structuring and defining the essential framework of a software system.
Consider software architecture as akin to a blueprint for constructing a house, guiding builders (software engineers) on how to assemble various components. Without such a plan, certain aspects of the structure may inhibit future modifications desired by the homeowner.
Software architecture encompasses decisions about:
- The organization, implementation, and functionality of software
- The relationships between components within an application
- The selection of technologies and infrastructure
This topic is vast, and here, I'll introduce the fundamental concepts that a typical technical Product Manager should grasp, as you will often collaborate with Software Architects who are the primary decision-makers.
If you're eager to explore further, a comprehensive reading list awaits you at the end.
Monolithic vs. Microservice Architecture
Envision constructing two distinct Lego castles. One is a single, large, custom piece, while the other consists of 200 smaller Lego components.
The monolithic structure may meet your initial requirements perfectly, but making swift alterations can be challenging. For instance, if you want to redesign a bedroom, the entire model must return to the factory. This scenario illustrates a monolithic architecture.
Conversely, the castle made of numerous smaller pieces can be easily disassembled. Each Lego component serves a specific function—like a gate or a bed—allowing for targeted modifications without the need to dismantle the entire structure.
Monolithic Architecture
Monolithic architecture is characterized by a unified computing network with a single codebase that integrates all business concerns. While this approach can simplify deployment and development during the initial phases of a project, it may encounter challenges as it scales. Modifying one application segment requires recompiling and testing the entire system. As the application grows and multiple teams contribute, transitioning to a microservice model may be beneficial.
That said, it’s important to note that it’s not simply a question of “monolith bad, microservice good.” For smaller teams developing a proof of concept necessitating rapid iterations, a monolithic approach might be advantageous.
Microservice Architecture
In contrast, the microservice model allows each service to possess its own logic and database, focusing on specific objectives. Changes, testing, and deployment occur within individual services, enabling quicker release cycles and the ability to revert specific changes.
Microservice architecture generally promotes faster development, easier maintenance, and more frequent updates. While it requires meticulous planning and can be intricate, it aids teams in managing complexity by isolating different challenges.
For a more thorough discussion on the pros and cons of monoliths versus microservices, refer to the linked resource.
Zachary Crockett, CTO of Particle, summarizes this concept well: > "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."
Additional Software Architecture Patterns
Here are several widely recognized software architecture patterns worth noting:
Layered Architecture
This pattern segments a software system into layers, with each layer delivering a unique set of services. Each module is assigned to only one layer, facilitating hierarchical communication among the layers.
Many web applications employ layered architecture, featuring a presentation layer for user interface management, a business logic layer for data validation and processing, and a data access layer for database interactions.
Event-Driven Architecture
Event-driven design revolves around the concept of events, which may signify any significant state change, such as user interactions or data alterations.
For example, if a customer places an order online, it might trigger several responses from various services: an email confirmation, a warehouse notification to prepare the item, and an update to inventory management.
In this architecture, software components are designed to respond to events occurring within the system or externally, resulting in a loosely coupled and well-distributed setup.
Service-Oriented Architecture
This pattern constructs a software system as a collection of services accessible by various applications. Services are often invoked synchronously, meaning the client application waits for a service's response before continuing.
Peer-to-Peer Architecture
Peer-to-peer (P2P) architecture is a distributed system where nodes share resources and communicate directly without a central server. Blockchain technologies like Bitcoin and Ethereum utilize P2P architecture to maintain a decentralized ledger of transactions.
Principles of Software Architecture
Numerous principles govern software architecture, and while many detailed discussions are available, here are a few key concepts to help you understand the challenges a solutions architect must address when designing systems:
- Separation of Concerns — This principle advocates for dividing software into distinct components, each with a specific responsibility. This separation allows changes in one component without impacting others, simplifying maintenance.
- Loose Coupling — Loose coupling involves designing components with minimal dependencies on one another. This resilience enables easier maintenance and adaptation to changes.
- Modularity — Modularity entails subdividing a program into independent, interchangeable modules that group similar functions, enhancing flexibility and maintainability.
- Abstraction — Abstraction conceals implementation details while revealing only essential features, reducing complexity and promoting code reuse.
- Encapsulation — This practice safeguards the internal workings of a component from outside interference, allowing for changes without affecting clients.
Communicating Software Architecture Design
UML (Unified Modeling Language) is a standardized visual language for modeling and designing software systems. Various diagrams, such as class diagrams and sequence diagrams, can be particularly useful for Product Managers.
When starting a new position, reviewing existing diagrams can provide insights into software structure. For example, examining a sequence diagram may clarify what occurs when a user clicks "save favorite."
Many tools, such as Draw.io or Gliffy, can assist in creating and modifying diagrams, often offering pre-built templates.
Conclusion
I hope this article has clarified the essence of Software Architecture and the value a robust architectural design brings to a product.
Software Architects, did I overlook any aspects that you wish your Product Managers understood? And Product Managers, are there other articles you’d like to recommend?
Upcoming Articles
If you're keen to enhance your technical knowledge, I will share articles weekly. 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!
Be sure to subscribe for email notifications to stay updated on new articles in this series!
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 Chakraborty (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)