What do you think?
Rate this book
Fundamentals of Software Architecture: An Engineering Approach
Although salary surveys worldwide regularly identify software architect as one of the top ten best jobs, no decent guides exist to help developers become architects. Until now. This practical guide provides the first comprehensive overview of software architecture's many aspects. You'll examine architectural characteristics, architectural patterns, component determination, diagramming and presenting architecture, evolutionary architecture, and many other topics.
Authors Neal Ford and Mark Richards help you learn through examples in a variety of popular programming languages, such as Java, C#, JavaScript, and others. You'll focus on architecture principles with examples that apply across all technology stacks.
Authors Neal Ford and Mark Richards help you learn through examples in a variety of popular programming languages, such as Java, C#, JavaScript, and others. You'll focus on architecture principles with examples that apply across all technology stacks.
422 pages, Paperback
First published January 27, 2020
1393 people are currently reading
9105 people want to read
About the author
Mark Richards
7 books73 followersThere are multiple authors with this name in this data base. This one is Mark^^^Richards.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 216 reviews
June 19, 2021
Software Architecture is hard as well as writing a book about it. Eventually it's a well written position wich unofrtunately didn't give me as much value as I expected.
What I liked:
- Chapter about modules. This is a content that I was looking for - truly engineering way of looking at aspects like cohesion, coupling or connascence. Very interesting equations and quality metrics were provided.
- Accentuating over the entire book that there is no one perfect architecture - it's all about compromises and tradeoffs.
- The entire part about soft skills is plausible and pleasant to read. It consists of interesting (and sometimes funny!) tips for managing time, creating presentations, relationships with teams and many more. The best chapter from that area is about risk management (because it's the most engineering one!). I liked the idea of risk storming meeting and artifact called risk matrix.
What I didn't like:
- When the part of the book's name you're supposed to read consists of term "An Engineering Approach" you expect it to have a lot of engineering stuff inside (at least I expected that...). There were too few of these elements. The biggest part of the book is just a brief description of each architectural style which you can easily find literally everywhere.
- Strong separation of architect from the team. I notice that many organisations nowadays deliberately pick the path where the whole team is responsible for the architecture. Regardless of whether it is good or not, this book suggests only one path - there is a person named Sofware Architect who just coworks with teams. There were moments where I felt a bit uncomfortable with such strong seperation. I will recall the name of the book again - it's about Software Architecture and not about Software Architect role...
Finally, who is this book for?
If you're a Developer and your biggest dream is to become an Architect - go for it!
If you've never read before anything about Software Architecture - go for it!
However, if you're an experienced Developer (or already Architect) and you know the both soft skills fundamentals (it's all about communication with people, negotiating and tradeoffs) and technicals fundamentals (types of Software Architecture; fallacies of distributing computing) then don't expect too much from it.
What I liked:
- Chapter about modules. This is a content that I was looking for - truly engineering way of looking at aspects like cohesion, coupling or connascence. Very interesting equations and quality metrics were provided.
- Accentuating over the entire book that there is no one perfect architecture - it's all about compromises and tradeoffs.
- The entire part about soft skills is plausible and pleasant to read. It consists of interesting (and sometimes funny!) tips for managing time, creating presentations, relationships with teams and many more. The best chapter from that area is about risk management (because it's the most engineering one!). I liked the idea of risk storming meeting and artifact called risk matrix.
What I didn't like:
- When the part of the book's name you're supposed to read consists of term "An Engineering Approach" you expect it to have a lot of engineering stuff inside (at least I expected that...). There were too few of these elements. The biggest part of the book is just a brief description of each architectural style which you can easily find literally everywhere.
- Strong separation of architect from the team. I notice that many organisations nowadays deliberately pick the path where the whole team is responsible for the architecture. Regardless of whether it is good or not, this book suggests only one path - there is a person named Sofware Architect who just coworks with teams. There were moments where I felt a bit uncomfortable with such strong seperation. I will recall the name of the book again - it's about Software Architecture and not about Software Architect role...
Finally, who is this book for?
If you're a Developer and your biggest dream is to become an Architect - go for it!
If you've never read before anything about Software Architecture - go for it!
However, if you're an experienced Developer (or already Architect) and you know the both soft skills fundamentals (it's all about communication with people, negotiating and tradeoffs) and technicals fundamentals (types of Software Architecture; fallacies of distributing computing) then don't expect too much from it.
May 8, 2021
The book is not bad. I just wish that the authors had learned Russian and read "Пиши, сокращай" by Maxim Ilyahov and Ludmila Saricheva before writing this one. When it comes to non-fiction, short and concise will almost always beat long and verbose.
This book is fine as a first book to read on software architecture. It's stays high-level and tries to be coherent. It does lay down the foundation principles with top-to-bottom approach.
However, it's very verbose. It gives very long examples, spends long paragraphs explaining simple obvious concepts. I've ended up skimming 50-70% of it and that still took noticeable amount of time.
Which is a shame cause overall I liked the content and definitely appreciate the systematic approach to architecture the authors had taken.
I believe somebody should create a short version for more seasoned developers and architects.
This book is fine as a first book to read on software architecture. It's stays high-level and tries to be coherent. It does lay down the foundation principles with top-to-bottom approach.
However, it's very verbose. It gives very long examples, spends long paragraphs explaining simple obvious concepts. I've ended up skimming 50-70% of it and that still took noticeable amount of time.
Which is a shame cause overall I liked the content and definitely appreciate the systematic approach to architecture the authors had taken.
I believe somebody should create a short version for more seasoned developers and architects.
September 15, 2020
A great book about everything (that I could think of) about being a software architect, and how to be an effective one. The section about different architecture styles is a great overview of the different styles and explains clearly about the rationale behind the decisions made by each of them and what they are better at in certain contexts. The book also covers soft skills like architecture thinking, negotiation skills and communication skills, which I also find very useful. Highly recommended to any software engineer that is interested in learning more about the architect role and software architectures.
April 18, 2022
It depends.
As I moved onto the engineering management track, I'm not a software engineer anymore. Thus I'm not the target audience for this book. I've read the "Fundamentals of Software Architecture" to deepen my knowledge and to be able to be a better partner and leader to staff/principal engineers I work with.
I've thoroughly enjoyed reading this about architecture. I appreciated that it's more than just a collection of patterns and architectural styles. The authors do an excellent job at establishing what could be considered when picking an architecture, the various trade-offs/risks, and what could be measured. I would've been a better software engineer if this book existed and I'd read it ten years ago.
I didn't always enjoy the bits about a software architect's job. I cringed during some parts on soft skills (handshakes 🤝). While I'm sure that soft skills advice will work in some settings, it's not generally applicable.
Overall, it's an excellent book. Besides being a good read-through, I can imagine it would serve well as a reference for most senior engineers and architects.
As I moved onto the engineering management track, I'm not a software engineer anymore. Thus I'm not the target audience for this book. I've read the "Fundamentals of Software Architecture" to deepen my knowledge and to be able to be a better partner and leader to staff/principal engineers I work with.
I've thoroughly enjoyed reading this about architecture. I appreciated that it's more than just a collection of patterns and architectural styles. The authors do an excellent job at establishing what could be considered when picking an architecture, the various trade-offs/risks, and what could be measured. I would've been a better software engineer if this book existed and I'd read it ten years ago.
I didn't always enjoy the bits about a software architect's job. I cringed during some parts on soft skills (handshakes 🤝). While I'm sure that soft skills advice will work in some settings, it's not generally applicable.
Overall, it's an excellent book. Besides being a good read-through, I can imagine it would serve well as a reference for most senior engineers and architects.
April 4, 2020
Fantastic book, great examples and I loved the section about soft skills. Highly recommended!
March 24, 2021
I had high expectations for this book. The title and the premise were so promising. I had searched for a good book on Software Architecture with a good overview of different architectures, but most of the books I had found, focused only on specific architectures and paradigm and others were incomplete.
The book tries to give a general overview of not only different architectures but also the roles and responsibilities of a software architect. But it is an uneven book and different parts are not evenly explained. Some technical concepts are just glossed over, and some are extensively elaborated (relatively). I feel the authors don’t have enough expertise on the general subject. The book lacks a consistent categorization and structure, and sometimes the principles are meshed with the examples which makes it hard to identify the principles.
Aside from these points in the technical aspects, the book also covers the role of software architect and the soft skills required for choosing this as a career path. These parts also feel a little abstract (albeit there are some concrete techniques), but for me it gives a good overview of the path, which is a good starting point.
The book tries to give a general overview of not only different architectures but also the roles and responsibilities of a software architect. But it is an uneven book and different parts are not evenly explained. Some technical concepts are just glossed over, and some are extensively elaborated (relatively). I feel the authors don’t have enough expertise on the general subject. The book lacks a consistent categorization and structure, and sometimes the principles are meshed with the examples which makes it hard to identify the principles.
Aside from these points in the technical aspects, the book also covers the role of software architect and the soft skills required for choosing this as a career path. These parts also feel a little abstract (albeit there are some concrete techniques), but for me it gives a good overview of the path, which is a good starting point.
May 23, 2020
Useful reading. I'm not the core audience for this so I skimmed some sections, and while it tried to cover a lot of bases, it remained firmly anchored to concrete concerns. I really liked the lengthy middle section which was a bestiary of common system architectures and their strengths and weaknesses. Recommended for senior engineers trying to expand their scope of influence. I imagine it will remain a useful reference.
May 18, 2021
It is hard to tell if the book is worth reading or not. I don't know :) Let me put it that way... If you do consider yourself as an architect - read it. If you have read some architecture books - for instance by Uncle Bob or Sam Newmann or Ploeh blog/plurarsight and You do consider yoursef as a programmer it safe for you to skip that one.
Pros:
- Teaches you to wear the glasses of everything is a compromise.
- Katas!
- Emphasizes the importance of soft skills.
- Tells that Architect should write the code.
- Contains great quotes from other books/people.
- Good diagrams.
- Great chapter about space based architecture.
Cons:
- What about "The best architectures, requirements, and designs emerge from self-organizing teams" ??? The book says about the architect as a role, not bunch of activities. It is the worst thing in the whole book.
- It seems that the authors are in their comfortable zone :) You can learn nothing about the Jamstack, microfronteds. Fuck the UI. What about event sourcing? What about clean architecture? Ports and adapters? Gosh!
- Databases, ok the authors said that this is a broad topic and it is sth outside the book but some references please?
- Lack of references... The only chapter that has some is the one about microservices. As a book about "fundamentals" it should give good directions - I mean good references!
- It totally misses the point of negotiations. Read "Negotion Genius" if you want to know more. Here it is about effective communication.
At the end I think that the book is a really nice one for the ones working at companies that will never get into the essence of agile software development (so the bigger part). For the minority it still good read, but You will not lost much if You skip it.
Pros:
- Teaches you to wear the glasses of everything is a compromise.
- Katas!
- Emphasizes the importance of soft skills.
- Tells that Architect should write the code.
- Contains great quotes from other books/people.
- Good diagrams.
- Great chapter about space based architecture.
Cons:
- What about "The best architectures, requirements, and designs emerge from self-organizing teams" ??? The book says about the architect as a role, not bunch of activities. It is the worst thing in the whole book.
- It seems that the authors are in their comfortable zone :) You can learn nothing about the Jamstack, microfronteds. Fuck the UI. What about event sourcing? What about clean architecture? Ports and adapters? Gosh!
- Databases, ok the authors said that this is a broad topic and it is sth outside the book but some references please?
- Lack of references... The only chapter that has some is the one about microservices. As a book about "fundamentals" it should give good directions - I mean good references!
- It totally misses the point of negotiations. Read "Negotion Genius" if you want to know more. Here it is about effective communication.
At the end I think that the book is a really nice one for the ones working at companies that will never get into the essence of agile software development (so the bigger part). For the minority it still good read, but You will not lost much if You skip it.
March 31, 2022
Abrange diversos conceitos importantes relacionados ao assunto, desde a parte técnica à parte comportamental (soft skills).
Não dei uma nota maior porque simplesmente o livro não me trouxe tanta coisa nova assim (uma que vale dizer é o estilo de arquitetura "Space-based", que eu desconhecia).
Como destaque cito todos os pontos relacionados à modularidade e acoplamento e o capítulo referente à gestão de riscos.
De negativo (mas nem tanto assim), é o enfoque no "arquiteto de software". Acredito que poderiam pelo menos ter feito um paralelo com cargos mais atuais que absorvem boa parte da atividade de arquitetura, como Tech Leads e Principal Engineers.
De todo modo, vale a leitura, seja para iniciar na disciplina de arquitetura ou para refrescar alguns conceitos.
Não dei uma nota maior porque simplesmente o livro não me trouxe tanta coisa nova assim (uma que vale dizer é o estilo de arquitetura "Space-based", que eu desconhecia).
Como destaque cito todos os pontos relacionados à modularidade e acoplamento e o capítulo referente à gestão de riscos.
De negativo (mas nem tanto assim), é o enfoque no "arquiteto de software". Acredito que poderiam pelo menos ter feito um paralelo com cargos mais atuais que absorvem boa parte da atividade de arquitetura, como Tech Leads e Principal Engineers.
De todo modo, vale a leitura, seja para iniciar na disciplina de arquitetura ou para refrescar alguns conceitos.
August 30, 2020
Excellent overview of software architecture fundamentals. Recommend.
March 21, 2025
Software architects guide development teams during projects from design to completion. It’s a notoriously nebulous field where the only goal is to build successful software… whatever that means and whatever that takes. Like any ill-defined field, getting from point A to point B requires skill and wisdom. That skill and wisdom evolves over time as the field evolves. Mark Richards and Neal Ford attempt to provide a guide to being a software architect without tying their approach too closely to any one technology.
The authors succeed in their goal of writing for the general audience of software designers, regardless of programing language; however, they fail to meet their audience at the same time because they are highly wedded to the design of microservices, their expertise. A lot of complex software development today doesn’t use microservices, and this book contains a lot of material that is only tangentially relevant to that crowd. Their work sees software through the lens of microservices versus monoliths, and in my experience, that contrast simply isn’t foundational to many developers.
Of course, we’re all biased towards our own areas, but the authors could have investigated this topic with a more scholarly approach that balanced other paradigms. The final sections on the interpersonal aspects of a software architect’s work life are helpful. I’d suggest that they’d serve as a better unifying theme to the topic and should be covered first. Then perhaps the authors could convey what architecture patterns exist in different development domains like web development, microservices, embedded systems, etc. The world of software is exploding with diverse approaches to a wide array of problems, and I’m still looking for a good book on software architecture to unite them. This book, while certainly solid, is more of a specialist’s guide to microservices than a grand tutorial.
The authors succeed in their goal of writing for the general audience of software designers, regardless of programing language; however, they fail to meet their audience at the same time because they are highly wedded to the design of microservices, their expertise. A lot of complex software development today doesn’t use microservices, and this book contains a lot of material that is only tangentially relevant to that crowd. Their work sees software through the lens of microservices versus monoliths, and in my experience, that contrast simply isn’t foundational to many developers.
Of course, we’re all biased towards our own areas, but the authors could have investigated this topic with a more scholarly approach that balanced other paradigms. The final sections on the interpersonal aspects of a software architect’s work life are helpful. I’d suggest that they’d serve as a better unifying theme to the topic and should be covered first. Then perhaps the authors could convey what architecture patterns exist in different development domains like web development, microservices, embedded systems, etc. The world of software is exploding with diverse approaches to a wide array of problems, and I’m still looking for a good book on software architecture to unite them. This book, while certainly solid, is more of a specialist’s guide to microservices than a grand tutorial.
September 6, 2024
Fine as a high level overview, can be skimmed
May 16, 2020
Fundamentals of Software Architecture: An Engineering Approach
By Mark Richards and Neal Ford
The book, Fundamentals of software architecture, is an excellent guide for software developers aspiring to move to an architect role or architects that have been just promoted to the role that would like to become more effective in their role. It provides clear definition of software architecture, the responsibilities of an architect and technical and social skills needed to succeed as a software architect. The composition of the book is perfectly calibrated to be used as a receipt for first time architecture design projects. It provides guidelines for architects to have a good understanding of the business side of software projects, how to identify key architecture characteristics from business stakeholders and use these characteristics to guide the selection of best fit architectural style, make trade-off analysis and document these decisions. It also highlights approaches on how to continue monitoring the evolution of the architecture as the project progresses in the development. In general, the book provides practical examples, as the names suggests (an engineering approach), to elaborate both technical topics, such as how to identify components and make architecture trade-off, or methods for effective communication and negotiation with stakeholders.
However, there are also some missing ingredients that I personally would have liked to see. The first one is the organisation of some chapters could be reordered to make it cohesive and easy for readers to follow logically. Another missing piece, in the Architecture style discussion, is it didn’t provide the constraints that are applied with the discussed style. In the discussion of the styles, the authors discuss the re-organisation of components as if there are no constraints. It also discussed synch/async method of communication between components but didn’t go into enough details through connectors of components as it did in great detail through component discussion. The figures and equations presented in the book are not clear enough (Eg. Equation variables are sometimes not defined) or some of the figures are not of good quality. The good side of the book is it provides sufficient representations of the discussed material. Another very lightly discussed but mostly needed by architects is drawing the architecture. The book provides few methods of presenting the architecture, but I would be happy to see how the architecture characteristics address the concerns of the stakeholders (view points) and this is mapped to a certain view of the architecture, for instance as in the architecture description standard in ISO/IEC/IEEE 42010.
In summary, the book provides a comprehensive set of information for new architects and developers that want to be an architect. I highly recommend this book for software developers to read it; it shades light to the role of an architects that was usually not so clear. If you are looking for a guide to become an effective software architect this is one of the best books to start with.
December 20, 2021
This book was very valuable to me. I learned a lot about an architect's work, challenges, solutions, and techniques.
As the authors claim, the book will not be relevant forever, as the landscape changes quickly. On the other hand, it offered useful vocabulary to think and speak about the different architectural solutions in terms of tradeoffs analysis, which is a great technique, no matter what the current solutions are.
I would recommend it not only to future architects, but also anyone who works closely with architects, or in a no-architects environment.
As the authors claim, the book will not be relevant forever, as the landscape changes quickly. On the other hand, it offered useful vocabulary to think and speak about the different architectural solutions in terms of tradeoffs analysis, which is a great technique, no matter what the current solutions are.
I would recommend it not only to future architects, but also anyone who works closely with architects, or in a no-architects environment.
November 7, 2020
Awesome approach to software architecture. Packed full with concrete examples and advice, as well as mindset things (how to think like an architect and design software effectively). Highly recommend for anyone getting deep into software development
April 11, 2024
A very basic book on the topic. It has good parts, but a reader must be very careful because it's full of bullshit advice.
The writing is boring and overly long. I have no idea why could anybody call this a good book.
The writing is boring and overly long. I have no idea why could anybody call this a good book.
July 28, 2023
Good book! At some point in a software developer's career, books about architecture start being more and more important.
Notes from the book:
* Info sources:
** infoq
** dzone refcardz
** thoughtworks technology radar
* Types of architects:
** control-freak arch. (will dictate the implementation of components; the a.'s job should be to create the components (as ideas), and then let the developers to implements them. When transitioning from developer to architect, ppl tend to become control-freaks)
** armchair architect: sets boundaries that are too loose. Possibly hasn't coded in a long time. Does not take into consideration feedback from developers
** effective arch.: somewhere in the middle of those extremes
* "According to Michael, architecturally significant decisions are those decisions that affect the structure, nonfunctional characteristics, dependencies, interfaces, or construction techniques."
* Standards for diagrams:
** C4 model: good for monoliths, not so good for microservices
** Archimate model
* ADR types:
** Enterprise
** Integration
** Application
* ADR (arch. decision records). Author sugests adding 2 sections: Compliance (how we ensure compliance) and Notes (metadata. author, date). Main sections:
** title
** status (proposed, accepted, superseded by)
** context
** decision (and justification)
** consequences
** +compliance
** +notes (author, date of approval)
* Architectural anti-patterns:
** Covering your assets anti-pat. (delaying decisions too much out of fear of making a bad decision). To solve, wait till the last moment, but not longer. Second way is to collaborate with devs.
** Groundhog day anti-p. (when decisions are discussed over and over, mostly because justifications were not properly or completely provided)
** Email-driven architecture anti-p. (don't send architecture decisions in emails, because they're hard to update and not all people care about that email...and info is hard to find, which might lead to groundhog-day anti-p.)
* microservices: if transactions across multiple uservices are required, one should rather refactor the microservice structure, to remove the requirement, rather than to implement distributed transactions - if possible
* space-based architectures are comprised of: processing units, virtualized middleware (to coordinate thr pr.un.), data pumps, data writers (to update the db), data readers (to read from the db, at startup)
* service based architecture: independently running backends, frontends, but 1 single db
* "layer sync-hole" anti-pattern: when there are lots of layers that do nothing but pass stuff along to other layers
* layered architectures are a good default
* "business delegate pattern"?
* DDD doesn't work well with layers
* fallacies of distributed computing: 8 of them
** network is reliable
** latency is 0
** bandwidth is infinite
** the network is secure
** topology never changes
** there is only 1 administrator (for the network)
** transport cost is 0 ($: extra hardware)
** network is homogenous (not all hardware works with other hw, and packets get lost)
**
* distributed architecture styles: service based, event driven, space-based, service oriented, microservices
* Monolithic architecture styles: layered, pipeline, microkernel
* "Architecture katas" -> look them up online, for practicing architecture skills
* "Conaisence" (cə-ney-sens): 2 components are conaiscent, if a change in one, requires a change in the other, for the system to maintain correctness
* Java 1.1 worked only with .class files in folders. Java 1.2 added .jar files, which now allowed for classes with the same fully qualified name to exist in 2 places, overriding the initial intention (for name clashes to be impossible)
Notes from the book:
* Info sources:
** infoq
** dzone refcardz
** thoughtworks technology radar
* Types of architects:
** control-freak arch. (will dictate the implementation of components; the a.'s job should be to create the components (as ideas), and then let the developers to implements them. When transitioning from developer to architect, ppl tend to become control-freaks)
** armchair architect: sets boundaries that are too loose. Possibly hasn't coded in a long time. Does not take into consideration feedback from developers
** effective arch.: somewhere in the middle of those extremes
* "According to Michael, architecturally significant decisions are those decisions that affect the structure, nonfunctional characteristics, dependencies, interfaces, or construction techniques."
* Standards for diagrams:
** C4 model: good for monoliths, not so good for microservices
** Archimate model
* ADR types:
** Enterprise
** Integration
** Application
* ADR (arch. decision records). Author sugests adding 2 sections: Compliance (how we ensure compliance) and Notes (metadata. author, date). Main sections:
** title
** status (proposed, accepted, superseded by)
** context
** decision (and justification)
** consequences
** +compliance
** +notes (author, date of approval)
* Architectural anti-patterns:
** Covering your assets anti-pat. (delaying decisions too much out of fear of making a bad decision). To solve, wait till the last moment, but not longer. Second way is to collaborate with devs.
** Groundhog day anti-p. (when decisions are discussed over and over, mostly because justifications were not properly or completely provided)
** Email-driven architecture anti-p. (don't send architecture decisions in emails, because they're hard to update and not all people care about that email...and info is hard to find, which might lead to groundhog-day anti-p.)
* microservices: if transactions across multiple uservices are required, one should rather refactor the microservice structure, to remove the requirement, rather than to implement distributed transactions - if possible
* space-based architectures are comprised of: processing units, virtualized middleware (to coordinate thr pr.un.), data pumps, data writers (to update the db), data readers (to read from the db, at startup)
* service based architecture: independently running backends, frontends, but 1 single db
* "layer sync-hole" anti-pattern: when there are lots of layers that do nothing but pass stuff along to other layers
* layered architectures are a good default
* "business delegate pattern"?
* DDD doesn't work well with layers
* fallacies of distributed computing: 8 of them
** network is reliable
** latency is 0
** bandwidth is infinite
** the network is secure
** topology never changes
** there is only 1 administrator (for the network)
** transport cost is 0 ($: extra hardware)
** network is homogenous (not all hardware works with other hw, and packets get lost)
**
* distributed architecture styles: service based, event driven, space-based, service oriented, microservices
* Monolithic architecture styles: layered, pipeline, microkernel
* "Architecture katas" -> look them up online, for practicing architecture skills
* "Conaisence" (cə-ney-sens): 2 components are conaiscent, if a change in one, requires a change in the other, for the system to maintain correctness
* Java 1.1 worked only with .class files in folders. Java 1.2 added .jar files, which now allowed for classes with the same fully qualified name to exist in 2 places, overriding the initial intention (for name clashes to be impossible)
April 13, 2024
The book is a useful companion to “Building Evolutionary Architectures” and provides additional depth.
It sets off with answering the question of what software architecture is and defines it as a combination of four planes:
* Structure (aka an architecture style such as a service-based architecture)
* Architecture characteristics (aka non-functional requirements such as scalability, reliability, compatibility)
* Architecture decisions, e.g. that the persistence layer in a layered architecture style is closed, i.e. calls from higher layers mustn’t bypass it for accessing the database layer.
* Design principles, a less hard and fast rule than an architecture decision, it might be a general advice to prefer gRPC communication over REST.
It then defines the two laws of software architecture:
1. Everything in a software architecture is a trade-off (a corollary of which is that if a software architect has discovered something that isn’t a trade-off, more likely they just haven’t identified the trade-off yet)
2. Why is more important than how.
Architecture as a process of making trade-offs is a leitmotiv of the book.
To me the most useful bit of the book is its introduction extensive review of the main architecture styles that have sprung up over the past 25 years.
Having entered the realm of enterprise software development in the early 2000s, the main thought that was spinning in my head as I was reading on the different architectural styles was that one could implement the majority of them with versions of JavaEE 5 and higher. Having been part of that evolution from J2EE 1.2 to JavaEE 6 and then to Spring Framework helped me a lot to relate to the material in the book. All the building blocks were baked in into JavaEE. One could do:
* Layered with tecnical partitioning
* Service-Basee, with domain partitioning
* Pipeline with JMS and MDBs
* Event Driven (both broker topology and mediator topology) with JMS and MDBs
* SOA
* Microservices
The only small issue we had was with excessive reliance on Java Serialization (RMI calls and when passing objects via JMS), which created tight coupling to the same classes (a huge bounded context one could say). But even that could be overcome with RESTful or SOAP-based services. Interestingly the book dwells on this too by giving a real world example of an architect who wanted to ensure that none of the development teams accidentally created coupling points between each other, hindering the teams ability to move independently. That architect had a wide mix of technical skills on the teams, he mandating that each development team use a different technology stack. If one team was using Java and the other was using NET, it was impossible to accidentally share classes!
Overall a highly useful book that would help those in the industry for some time consolidate and improve their knowledge of software architecture.
It sets off with answering the question of what software architecture is and defines it as a combination of four planes:
* Structure (aka an architecture style such as a service-based architecture)
* Architecture characteristics (aka non-functional requirements such as scalability, reliability, compatibility)
* Architecture decisions, e.g. that the persistence layer in a layered architecture style is closed, i.e. calls from higher layers mustn’t bypass it for accessing the database layer.
* Design principles, a less hard and fast rule than an architecture decision, it might be a general advice to prefer gRPC communication over REST.
It then defines the two laws of software architecture:
1. Everything in a software architecture is a trade-off (a corollary of which is that if a software architect has discovered something that isn’t a trade-off, more likely they just haven’t identified the trade-off yet)
2. Why is more important than how.
Architecture as a process of making trade-offs is a leitmotiv of the book.
To me the most useful bit of the book is its introduction extensive review of the main architecture styles that have sprung up over the past 25 years.
Having entered the realm of enterprise software development in the early 2000s, the main thought that was spinning in my head as I was reading on the different architectural styles was that one could implement the majority of them with versions of JavaEE 5 and higher. Having been part of that evolution from J2EE 1.2 to JavaEE 6 and then to Spring Framework helped me a lot to relate to the material in the book. All the building blocks were baked in into JavaEE. One could do:
* Layered with tecnical partitioning
* Service-Basee, with domain partitioning
* Pipeline with JMS and MDBs
* Event Driven (both broker topology and mediator topology) with JMS and MDBs
* SOA
* Microservices
The only small issue we had was with excessive reliance on Java Serialization (RMI calls and when passing objects via JMS), which created tight coupling to the same classes (a huge bounded context one could say). But even that could be overcome with RESTful or SOAP-based services. Interestingly the book dwells on this too by giving a real world example of an architect who wanted to ensure that none of the development teams accidentally created coupling points between each other, hindering the teams ability to move independently. That architect had a wide mix of technical skills on the teams, he mandating that each development team use a different technology stack. If one team was using Java and the other was using NET, it was impossible to accidentally share classes!
Overall a highly useful book that would help those in the industry for some time consolidate and improve their knowledge of software architecture.
May 6, 2021
Never shoot for the best architecture, but rather the least worst architecture.
It is a good book but was difficult reading for me because I don't see how to immediately apply learnings in my current work. I hope to return to this book later when I'll work on high-level architectures for projects.
The authors explained who is an architect, what does it mean to think like an architect, what metrics are important for architectures.
The main part of the book gives an overview of different architecture styles and often how they overlap. That chapters can be used as a reference by discussing the pros and cons, costs and risks of applying a certain type of architecture.
I'd suggest this book to someone who is clearly on a path to an architect role. Programmers will find many useful things in "Fundamentals of Software Architecture" but often it goes very deep to levels that are not necessarily needed for all developers. As the authors mention: programmers know the benefits of everything and the trade-offs of nothing. Architects need to understand both. And this books helps to learn how to achieve it.
My favourite quotes:
All architectures become iterative because of unknown unknowns, Agile just recognizes this and does it sooner.
First Law of Software Architecture: Everything in software architecture is a trade-off. If an architect thinks they have discovered something that isn’t a trade-off, more likely they just haven’t identified the trade-off yet.
Second Law of Software Architecture: Why is more important than how.
Inspired to read:
The Checklist Manifesto: How to Get Things Right
May 29, 2022
This is a must read book for aspiring architects, or people who have transitioned into an Architect role currently. Because the advice given in this book is very practical and concise, because it does not teach you how to write perfect code or a set of best practices, but it teaches you things practically by considering all the factors which go into making a decision.
All rchitecture decisions are trade offs.
Because no matter what decisions you take it's not possible to build a perfect system, but you should aim to solve the problem at hand considering the functional and non functional requirements of a system.
This book teaches you read between the lines, because non functional requirements are never specified on the paper, but you have to understand them.
This book also focuses on lot of architecture types, and gives a detailed break down of architecture characteristics by rating them.
But the thing which I took most from the book is how can you convince your business stakeholders to invest in a specific architecture style, becuase at the end of the day it all comes down to cost. But you can convince using diagrams very effectively, and learning that skill is key for an architect.
Because being an architect your decisions are always going to be challenged by everyone involved, and how you convince them is basically the key to success, and this book teaches you that and much more.
A must read 5/5 stars.
All rchitecture decisions are trade offs.
Because no matter what decisions you take it's not possible to build a perfect system, but you should aim to solve the problem at hand considering the functional and non functional requirements of a system.
This book teaches you read between the lines, because non functional requirements are never specified on the paper, but you have to understand them.
This book also focuses on lot of architecture types, and gives a detailed break down of architecture characteristics by rating them.
But the thing which I took most from the book is how can you convince your business stakeholders to invest in a specific architecture style, becuase at the end of the day it all comes down to cost. But you can convince using diagrams very effectively, and learning that skill is key for an architect.
Because being an architect your decisions are always going to be challenged by everyone involved, and how you convince them is basically the key to success, and this book teaches you that and much more.
A must read 5/5 stars.
December 21, 2020
For anyone who is a software architect (mint or seasoned, really doesnt matter!) or is on the path to become one or just has an interest in software architecture!
The book has a very satisfying content varying from core disciplines and manifests of software architecture to different styles with specific characteristics plus the personal aspect that goes with the role.
Being some sort of an experienced architect with having gone through majority of the topics and issues described in the book, i can only echo that they are for real! Authors know exactly what they are talking about. Rather pinpointing a billion of resources in every other page, one will find exact blood and tears of effective architect experiences.
A guiding book that will always be on my desk, as a dictionary to look up in day2day work. Thanks!
The book has a very satisfying content varying from core disciplines and manifests of software architecture to different styles with specific characteristics plus the personal aspect that goes with the role.
Being some sort of an experienced architect with having gone through majority of the topics and issues described in the book, i can only echo that they are for real! Authors know exactly what they are talking about. Rather pinpointing a billion of resources in every other page, one will find exact blood and tears of effective architect experiences.
A guiding book that will always be on my desk, as a dictionary to look up in day2day work. Thanks!
February 8, 2021
The reason this book gets such a low rating is due to my frustration of not getting more architecture case studies with their chosen solutions for the buck i paid.
The book is abstract , written in a bird view way , just as a software architect should look at the system he is building.
My favourite part was the high-elasticity bidding system.Its a masterpiece to see how a problem formulated by the business analysts/clients/pm gets decoded and translated into rock-solid system constraints and then based on these constraints ,how the system gets split , decoupled into functional components.
What i think is useful but for me was a bit too pedantic and dry compared to the previous parts was the last part of thee book.where the focus is people skills/negotiatiion.
While i don't deny its useful , i would've preferred more case studies like the one i mentioned where you are given some ambigue systems constraints and its ur job too figure all out.
The book is abstract , written in a bird view way , just as a software architect should look at the system he is building.
My favourite part was the high-elasticity bidding system.Its a masterpiece to see how a problem formulated by the business analysts/clients/pm gets decoded and translated into rock-solid system constraints and then based on these constraints ,how the system gets split , decoupled into functional components.
What i think is useful but for me was a bit too pedantic and dry compared to the previous parts was the last part of thee book.where the focus is people skills/negotiatiion.
While i don't deny its useful , i would've preferred more case studies like the one i mentioned where you are given some ambigue systems constraints and its ur job too figure all out.
This entire review has been hidden because of spoilers.
January 25, 2022
I picked this book up to read right after finishing Staff Engineer by Will Larson. As a Staff Engineer working as a Software Architect, reading the two books back-to-back were very interesting (and informative!). Just as Will Larson’s book provided valuable broad insight into the what exactly a Staff Engineer, Mark Richards and Neal Ford provide excellent insight into software architecture.
The book covers everything from what exactly is software architecture from a conceptual/definable level, some technical knowledge of architecture (including various architectural styles), and non-technical/soft skills that are required for architecture.
Being a software architect won’t always require being a Staff+ Engineer, but there is a lot of skill overlap. If you’re reading of these two books, I’d highly recommend reading the other as well. I certainly wish I had them both available earlier In my career.
The book covers everything from what exactly is software architecture from a conceptual/definable level, some technical knowledge of architecture (including various architectural styles), and non-technical/soft skills that are required for architecture.
Being a software architect won’t always require being a Staff+ Engineer, but there is a lot of skill overlap. If you’re reading of these two books, I’d highly recommend reading the other as well. I certainly wish I had them both available earlier In my career.
December 29, 2023
The book gives an excellent foundation for someone to learn software architecture. It also gives you many resources and practical techniques for dealing with different aspects of software architecture. I especially like how it presents and scores different architectural styles in various aspects.
What I wouldn't say I like much about the book is that it portrays software architects as people who hold that title, while many engineers, although not holding that position, would play that role at some point in their careers. The book relies heavily on the authority that the title gives to the software architect to shape the architecture and influence the team to get the work done. From my experience, that's less likely to be the case.
Regarding soft skills, although it does provide some practical techniques, it could have been a bit better. I believe that some of those techniques would work more if you're working in the US than if you work in many European countries.
What I wouldn't say I like much about the book is that it portrays software architects as people who hold that title, while many engineers, although not holding that position, would play that role at some point in their careers. The book relies heavily on the authority that the title gives to the software architect to shape the architecture and influence the team to get the work done. From my experience, that's less likely to be the case.
Regarding soft skills, although it does provide some practical techniques, it could have been a bit better. I believe that some of those techniques would work more if you're working in the US than if you work in many European countries.
February 7, 2022
Really a good book to get an overview of architecture activities from professionals.
Actually, the less interesting part was the beginning, because it lays down generic statement that you can think you've seen everywhere
then it goes into the collection of architecture patterns which were really interesting to see the variatous archtiectures. There was information that is hard to see in other places. Most interestingly, they do not put microsercies architecture as the ultimate goal to attain. That always depend on what you are trying to optimize.
So I really enjoyed reading it. Maybe not all chapters will be seen as insightful, but at least most architects should get something out of it
The "technology radar" part at the end was interesting as well. It gave me the objective of checking regularly Thoughworks existing radar to keep touch with existing trend in IT.
Actually, the less interesting part was the beginning, because it lays down generic statement that you can think you've seen everywhere
then it goes into the collection of architecture patterns which were really interesting to see the variatous archtiectures. There was information that is hard to see in other places. Most interestingly, they do not put microsercies architecture as the ultimate goal to attain. That always depend on what you are trying to optimize.
So I really enjoyed reading it. Maybe not all chapters will be seen as insightful, but at least most architects should get something out of it
The "technology radar" part at the end was interesting as well. It gave me the objective of checking regularly Thoughworks existing radar to keep touch with existing trend in IT.
January 21, 2025
A very good explanation of the architect’s role in software development projects. This is definitely a book I will come back to, especially for its fairly detailed description of the differences between monolithic and microservices architectures. I recommend it.
Bardzo dobre wytłumaczenie roli architekta w projektach wytwarzających oprogramowanie. Jest to na pewno książka, do której będę powracać. W szczególności jeśli chodzi o dość konkretny opis różnic architektur monolitycznych i mikroserwisowych. Polecam.
Bardzo dobre wytłumaczenie roli architekta w projektach wytwarzających oprogramowanie. Jest to na pewno książka, do której będę powracać. W szczególności jeśli chodzi o dość konkretny opis różnic architektur monolitycznych i mikroserwisowych. Polecam.
March 30, 2025
A fantastic book which i would love to have read while in university. Definitely i would use it as a reference from time to time!
It is very nicely written, easily read has a ton of useful examples and takes you step by step on some of the foundational steps of software Architecture.
Aside the technology aspect the fact that it goes into the role of S.Architect as an IC and how it should be part of the development teams, along with the ways of working and career growth it is a great asset in the book.
It is very nicely written, easily read has a ton of useful examples and takes you step by step on some of the foundational steps of software Architecture.
Aside the technology aspect the fact that it goes into the role of S.Architect as an IC and how it should be part of the development teams, along with the ways of working and career growth it is a great asset in the book.
June 5, 2022
I manage a data science team. Over the past several years, the worlds of data science and software development have started to overlap, leaving me planning projects at a higher level and designing architectures. This book describes the art and craft of software architecture in a down-to-earth manner that really clicked for me.
December 31, 2023
The book comprehensively covers a wide range of topics pertaining to the role of an architect, encompassing both technical skills and soft skills. Although the topics are not explored in extensive detail, the breadth of subjects covered enhances the book's value. It explains the characteristics of architecture (non-functional requirements, or NFRs), various architectural styles, and their respective trade-offs. This book fosters a deep understanding of architectural thinking, which is particularly beneficial for new architects. It encourages them to adopt an architectural perspective, rather than limiting themselves to a 'senior developer' viewpoint.
September 20, 2021
I'm not sure if it's the fact that I got burned by Building Evolutionary Architectures, co-authored by Neal Ford, or my previous experience with other "fundamentals" books which tended to be rather useless - my expectations were fairly low of this one but I'm glad I went ahead and read it.
The book starts off by discussing what software architecture is, what the job entails, what the common misconceptions are and then for the remainder of the book covers both the technical and soft skills required for a person to become a good architect - how to maintain the technical know-how required by the job, what types of knowledge to focus on, how to detect, discuss and document the architecture, the reasons behind it and the trade-offs it entails, how to interact with your colleagues, both on the developer and the business side, how to resolve conflicts, nurture and promote constructive collaboration etc. So, as you can see, the authors try to cover a lot of ground without going too deep (and waking Durin's Bane) - and they do it successfully.
That being said, the book isn't perfect, some chapters could have used more feedback, especially the event-driven architecture one, which felt a bit dated and like it came from someone who didn't have firsthand experience with it recently. Also, I can't really say that I truly discovered something new within its pages - which isn't necessarily a bad thing if, like here, the summary of the things you know is presented in such a way it actually reinforces the existing knowledge.
The book starts off by discussing what software architecture is, what the job entails, what the common misconceptions are and then for the remainder of the book covers both the technical and soft skills required for a person to become a good architect - how to maintain the technical know-how required by the job, what types of knowledge to focus on, how to detect, discuss and document the architecture, the reasons behind it and the trade-offs it entails, how to interact with your colleagues, both on the developer and the business side, how to resolve conflicts, nurture and promote constructive collaboration etc. So, as you can see, the authors try to cover a lot of ground without going too deep (and waking Durin's Bane) - and they do it successfully.
That being said, the book isn't perfect, some chapters could have used more feedback, especially the event-driven architecture one, which felt a bit dated and like it came from someone who didn't have firsthand experience with it recently. Also, I can't really say that I truly discovered something new within its pages - which isn't necessarily a bad thing if, like here, the summary of the things you know is presented in such a way it actually reinforces the existing knowledge.
Displaying 1 - 30 of 216 reviews