I’ll summarize my takeaways from this book in a 5-minute discussion
Book Name: Building Evolutionary Architectures
Authors: Neal Ford, Rebecca Parsons, Patrick Kua
Publisher: O’Reilly Media
Purchase Link: Book available on Amazon
Audiences 👂🏻🔉
Software developers at all levels except for those in junior positions.
My understanding of “Building Evolutionary Architectures” 📖
The author attempts to list all the important aspects of software architecture, such as scalability, ease of maintenance, security, resilience, monitoring, etc. To help choose an architecture that matches business requirements. In essence, they aim to understand what it takes to create and maintain architectures that can adapt to constant changes.
Next, the author discusses various architectural approaches, including monolithic, modular monolithic, SOA, microservice, and serverless architectures. The author evaluates these options based on fitness functions, incremental changes, and coupling to determine the most suitable architecture.
What are guided, incremental changes?
The process of making gradual and step-by-step changes or additions to your software’s functionality, all while considering the broader context and concerns, such as scalability and maintainability.
what are fitness functions?
A fitness function review is a meeting with key business and technical stakeholders with the goal of updating fitness functions to meet design goals.
What is appropriate coupling?
When it comes to coupling, it’s something you’ll encounter in any architectural type. Sooner or later, you’ll need to share resources between your services. Therefore, it’s wise to opt for a coupling approach that provides maximum benefit with minimal costs and drawbacks.
An evolutionary architecture consists of three primary aspects:
incremental change, fitness functions, and appropriate coupling. In the remainder of the book, we discuss each of these factors separately, then combine them to address what it takes to build and maintain architectures that support constant change.
An illustrative example to simplify the comprehension of the previously discussed concepts:
As a software architect tasked with a new requirement for a notification service, it’s essential to compile a list of key “-ilities” concerns:
- Scalability: Ensure the service can efficiently handle a high volume of notifications, allowing it to scale seamlessly as the user base grows.
- Maintainability: Design the service with a focus on ease of maintenance. It should be accessible and understandable by both the monitoring team and the development team to facilitate updates, troubleshooting, and improvements.
- Security: Prioritize the security of sensitive data, such as user email addresses and phone numbers. Implement encryption measures to safeguard this information and protect user privacy.
Addressing these “-ilities” concerns from the outset will help create a robust and effective notification service that aligns with the business requirements.
When the business requests the addition of new functionality to support “Mobile notification,” it’s crucial to guide the process with an incremental change approach. This means that the new functionality should be integrated smoothly without disrupting the existing ones. For example, it’s important to ensure that the service remains backward-compatible, allowing it to support older versions until all services have completed their migration to the new version. This ensures a smooth transition for all users and systems involved.
After implementing the new functionality, our Fitness functions play a vital role in addressing our service concerns. We can assess these concerns through various means, including unit tests, integration tests, and scalability tests integrated into our CI/CD pipeline. Additionally, for matters like data privacy, we can incorporate a manual approval step in the pipeline when third-party verification is required.
Regarding coupling, it’s feasible for the notification service, handling various notification types, to use the same encryption/decryption library or service. This approach couples all sub-modules (SMS, Email, Phone Notification) to the same library. While this may introduce some level of coupling, it has the advantage of centralizing cryptographic operations, simplifying maintenance, and enabling updates across all services simultaneously.
My Favorite Quotes in the book:
– An evolutionary architecture supports guided, incremental change across multiple dimensions.
– Architecture is abstract until operationalized, when it becomes a living thing.
– The smaller your architectural quanta, the more evolvable your architecture will be
-Software suffers from the unknown unknowns problem: developers cannot anticipate everything
-All architectures become iterative because of unknown unknowns; agile just recognizes this and does it sooner. — Mark Richards
Should I Read “Building Evolutionary Architectures”?
I genuinely believe that even if you manage to extract just one page from a book, it’s worth the read. If you find the time, I highly recommend giving it a go. However, if you’re unable to do so, I hope the information you’ve gathered here serves as a valuable takeaway. Embrace it. This book Book available on Amazon
Stay tuned for future reviews.
Cheers, Matt Ghafouri
