What do you think?
Rate this book
Just Enough Software Architecture: A Risk-Driven Approach
This is a practical guide for software developers, and different than other software architecture books. Here's It teaches risk-driven architecting. There is no need for meticulous designs when risks are small, nor any excuse for sloppy designs when risks threaten your success. This book describes a way to do just enough architecture. It avoids the one-size-fits-all process tar pit with advice on how to tune your design effort based on the risks you face. It democratizes architecture. This book seeks to make architecture relevant to all software developers. Developers need to understand how to use constraints as guiderails that ensure desired outcomes, and how seemingly small changes can affect a system's properties. It cultivates declarative knowledge. There is a difference between being able to hit a ball and knowing why you are able to hit it, what psychologists refer to as procedural knowledge versus declarative knowledge. This book will make you more aware of what you have been doing and provide names for the concepts. It emphasizes the engineering. This book focuses on the technical parts of software development and what developers do to ensure the system works not job titles or processes. It shows you how to build models and analyze architectures so that you can make principled design tradeoffs. It describes the techniques software designers use to reason about medium to large sized problems and points out where you can learn specialized techniques in more detail. It provides practical advice. Software design decisions influence the architecture and vice versa. The approach in this book embraces drill-down/pop-up behavior by describing models that have various levels of abstraction, from architecture to data structure design.
376 pages, Hardcover
First published August 30, 2010
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 34 reviews
January 25, 2019
I've read this one after a recommendation from Simon Brown. It took a while, because the book is hardly available (I've got it from Google Books), but it was worth the effort.
It's technology-agnostic & to some degree it's complementary to DDD concept as it doesn't try to introduce new patterns or sophisticated taxonomies, but focuses on composability, different levels of abstraction and a balance between parts that keep a proper internal cohesion. It's (the book) advertised as a "risk-based approach to architecture", but I'd just call it "need-based" or "pragmatism-based".
What did I like most? The emphasis on parallelism between design model & "code" model - maybe some naming was unfortunate (I prefer one from Living Documentation, X-rays or DDD), but the concepts behind are the same. The chapter about encapsulation (no 11) is freaking epic - literally EVERY software engineer should read it at some point.
What didn't I like? The main example ("Home Media Player") was rather dull, the chapter about styles very very simplistic & (IMHO) needs rework.
But it doesn't change the fact that it's one of the most "defining" books when it comes to design, modeling & defining architecture.
It's technology-agnostic & to some degree it's complementary to DDD concept as it doesn't try to introduce new patterns or sophisticated taxonomies, but focuses on composability, different levels of abstraction and a balance between parts that keep a proper internal cohesion. It's (the book) advertised as a "risk-based approach to architecture", but I'd just call it "need-based" or "pragmatism-based".
What did I like most? The emphasis on parallelism between design model & "code" model - maybe some naming was unfortunate (I prefer one from Living Documentation, X-rays or DDD), but the concepts behind are the same. The chapter about encapsulation (no 11) is freaking epic - literally EVERY software engineer should read it at some point.
What didn't I like? The main example ("Home Media Player") was rather dull, the chapter about styles very very simplistic & (IMHO) needs rework.
But it doesn't change the fact that it's one of the most "defining" books when it comes to design, modeling & defining architecture.
January 15, 2022
It explains complex architecture topics pretty clear and share the idea of not following an architectural pattern blindly but thinking around the project and the company as a hole. A must read related to the idea of "Agile architecture".
January 26, 2016
Full review at my blog.
Well worth the price but mainly missing the topic of risk-driven architectures. It is more an introductory text to architectural modelling.
Well worth the price but mainly missing the topic of risk-driven architectures. It is more an introductory text to architectural modelling.
November 20, 2021
Le titre du livre est un peu mensonger (comme d'ailleurs la première partie, qui est malgré tout la plus intéressante).
En effet, l'auteur parle de risk driven approach, et je me suis donc dit qu'il allait se concentrer sur l'analyse de risque et l'ensemble des éléments afférents. Et c'est partiellement vrai. En fait, cette approche peut se résumer à une phrase simple : si tu penses qu'un truc est risqué, réfléchis-y plus avant de te lancer. Et même si c'est très vrai, ça me paraît un peu insuffisant.
Surtout parce que ça n'est pas assez développé dans la suite du livre, qui parle certes du fossé entre le modèle et le code, des failles conceptuelles, méthodologiques et notationelles qui font suite à la création d'un modèle, ou encore de l'impact de la multiplication des vues et des échelles. Malheureusement, ces aspects me semblent un peu trop abstraits, alors que j'aurais préféré un travail plus détaillé sur les attributs de qualité et leur description comme des scénarios fonctionnels.
Cependant, je comprend complètement d'où Simon Brown a tiré les idées de son modèle C4 (qui n'est pas du tout la même chose que les 4+1 vues préconisées ici). En ce sens, c'est une lecture utile.
En effet, l'auteur parle de risk driven approach, et je me suis donc dit qu'il allait se concentrer sur l'analyse de risque et l'ensemble des éléments afférents. Et c'est partiellement vrai. En fait, cette approche peut se résumer à une phrase simple : si tu penses qu'un truc est risqué, réfléchis-y plus avant de te lancer. Et même si c'est très vrai, ça me paraît un peu insuffisant.
Surtout parce que ça n'est pas assez développé dans la suite du livre, qui parle certes du fossé entre le modèle et le code, des failles conceptuelles, méthodologiques et notationelles qui font suite à la création d'un modèle, ou encore de l'impact de la multiplication des vues et des échelles. Malheureusement, ces aspects me semblent un peu trop abstraits, alors que j'aurais préféré un travail plus détaillé sur les attributs de qualité et leur description comme des scénarios fonctionnels.
Cependant, je comprend complètement d'où Simon Brown a tiré les idées de son modèle C4 (qui n'est pas du tout la même chose que les 4+1 vues préconisées ici). En ce sens, c'est une lecture utile.
October 19, 2022
Good compendium. I am looking for books with a structured description of software architecture approaches that I can share with my team and this one fits quite well. Got a good introduction from the author, so a bit biased though.
January 14, 2024
A comprehensive book describing different architecture models, approaches and considerations
From reading it seems that a lot of the lessons here are common wisdom these days, but perhaps were not very popular ideas when the book first came out some years ago
The book itself is structured a bit like a series of architectural diagrams that it encourages to use - different levels of detail, different perspectives and it takes effort mostly from the reader to stich it all together into some kind of useful lessons
I found the examples used in book a bit lacking in useful meatyness - they were toy scenarios that very neatly fit the exact theory being described by the book without consideration of real world limitations, making their usefulness also more limited than they could have been
From reading it seems that a lot of the lessons here are common wisdom these days, but perhaps were not very popular ideas when the book first came out some years ago
The book itself is structured a bit like a series of architectural diagrams that it encourages to use - different levels of detail, different perspectives and it takes effort mostly from the reader to stich it all together into some kind of useful lessons
I found the examples used in book a bit lacking in useful meatyness - they were toy scenarios that very neatly fit the exact theory being described by the book without consideration of real world limitations, making their usefulness also more limited than they could have been
February 3, 2019
This book is a substantial introduction to the software architecture profession. It's based on a great number of sources, it explains well all technical terminology, reviews various architectural approaches, and gives examples of architecural models.
October 2, 2019
Review
I feel like I had misaligned expectations of this book, but I'm not sure if it's because I didn't know enough about the topic to understand what to expect or I just went to the theater to watch a thriller but got a romantic comedy instead, where the title and movie trailer guided me to make the wrong assumptions. In any case, this review might feel harsher than it actually is since there were parts I did actually enjoyed. Following are the bad parts, for the ones I found good are in the notes section.
Too much detail on high level concepts like port and connectors types between components.
Some diagrams feel too technical and unnecessarily detailed, like several relationship types between components, i.e. if two components are connected, I'm not sure it makes sense in many occasions to highlight the fact that the connection is sync or async, directly to the local file system or to a remote location, client or server port; by having a different dotted line to represent each one.
Most of the book feels somewhat academic and not matching the type of language you'd typically encounter in meeting rooms at work.
Very brief focus on the code model, not meaning I would've liked to see actual code, but, for instance, more concrete examples of how to apply the different strategies of dominant decomposition (folder structure). Same goes for the architectural styles.
The same concepts are repeated over and over again on most chapters from slightly different perspectives: quality attributes, module viewtype, runtime viewtype, components, ports, connectors. It feels like every chapter has a piece of the puzzle of each topic, rather than being covered in full in a continuous segment. Which innevitably leads to repetition.
Notes
Legend, vignette levels:
- 1st
* 2nd
^ 3rd
2)
- Risk-driven: design as much architecture to mitigate the biggest risks.
* If you need to process data in under 50ms, add that into the architecture.
- Apart from the features you're working on, always know what risk failures are you solving.
- There are problems to find and problems to prove.
* "Is there a number that when squared equals 4?", is a problem to find since you can test a solution pretty easy.
* "Is the sequence of all prime numbers infinite?", is a problem to prove.
* Finding is easier than proving since you need to demonstrate something is true for all posible cases.
4)
- Design intent will always be lost between design and code.
* We debated design decisions, discovered tradeoffs, imposed constraints; yet none of these is expressed in code.
- Code makes a good job communicating the code model, poor job communicating the runtime and allocation models (where and how is it deployed).
* Runtime model: what components and connectors exist at runtime.
^ How to represent it: Components and Responsibilities table, component assembly diagram, functionality scenario.
- Functionality scenario includes: Name, Initial state, Participants (components), Steps.
- Quality Attributes: describe here the tradeoffs, architecture drivers and design decisions.
- When integrating third-party components, make a list of failure risks.
* Make a diagram and write a functionality scenario of the risks mitigation strategies.
- After laying out a domain model, test it with a concrete example to detect potential problems.
* i.e. if you write a relationships model for Artist -> Song -> Album, the generic model might not highlight the potential shortcoming of handling bands or ex-band members going solo or artists changing names.
- Make rational architecture choices: when 2 ideas seem as good, figure out which quality attribute they help achieve, e.g. usability and testability, then pick the one you value higher.
7)
- Models help you solve problems and mitigate risks, but some problems are better solved directly, not through models.
- Every project should document its architecture: false.
* You should plan before going on a road trip, but you don't plan your commute every morning.
- "Your point of view is worth 80 IQ points", Alan Kay.
- Domain model: expresses enduring truths about the world relevant to the system, if something is 'just true', belongs in the domain.
- Design model: the system to be built makes appearance here, set of boundaries and commitments.
8)
- Domain models express details of the domain not related to the system's implementation.
- Stop domain modelling when it provides less value than other activity, such as prototyping.
- The most valuable part of this model is a list of types and definitions.
- Invariants: things in the model that must always be true.
- Functionality scenarios here include actors (real people or real world objects) not computer records or hardware as in the design model versions.
9)
- Module viewtype: things that exist only at compile time.
* Modules, layers, dependencies, db schemas, interfaces, classes, component types.
* Source code itself (code model) is this viewtype.
- Runtime viewtype: object and component instances, functionality scenarios, component assemblies.
* Hard to envision by reading the source code since you have to mentally animate the runtime instances.
11)
- Create levels of abstraction by hierarchically nesting elements, limit the number at any level, maintain encapsulation by not revealing unnecessary detail.
* Create a story at many levels.
- Dominant decomposition: the problem is that a single organisation system must be chosen.
* Like books in a library organised by size, helps finding the largest books, not so much finding by author.
* Decomposing the system into modules and components imposes an organisation on it.
- Encapsulation: rather than just grouping together related code, hide details likely to change inside the module.
* If you're unsure about design alternatives A and B, have the module's public interface support both, in case you need to swap.
14)
- Pipe-and-filter style: continually and incrementally processing data, (e.g. Node).
- Batch-sequential: complete all processing before moving to the next state.
- Client-server: is asymmetric, only clients can request the server to do work.
- Peer-to-peer: any node can be client or server, no hierarchy.
I feel like I had misaligned expectations of this book, but I'm not sure if it's because I didn't know enough about the topic to understand what to expect or I just went to the theater to watch a thriller but got a romantic comedy instead, where the title and movie trailer guided me to make the wrong assumptions. In any case, this review might feel harsher than it actually is since there were parts I did actually enjoyed. Following are the bad parts, for the ones I found good are in the notes section.
Too much detail on high level concepts like port and connectors types between components.
Some diagrams feel too technical and unnecessarily detailed, like several relationship types between components, i.e. if two components are connected, I'm not sure it makes sense in many occasions to highlight the fact that the connection is sync or async, directly to the local file system or to a remote location, client or server port; by having a different dotted line to represent each one.
Most of the book feels somewhat academic and not matching the type of language you'd typically encounter in meeting rooms at work.
Very brief focus on the code model, not meaning I would've liked to see actual code, but, for instance, more concrete examples of how to apply the different strategies of dominant decomposition (folder structure). Same goes for the architectural styles.
The same concepts are repeated over and over again on most chapters from slightly different perspectives: quality attributes, module viewtype, runtime viewtype, components, ports, connectors. It feels like every chapter has a piece of the puzzle of each topic, rather than being covered in full in a continuous segment. Which innevitably leads to repetition.
Notes
Legend, vignette levels:
- 1st
* 2nd
^ 3rd
2)
- Risk-driven: design as much architecture to mitigate the biggest risks.
* If you need to process data in under 50ms, add that into the architecture.
- Apart from the features you're working on, always know what risk failures are you solving.
- There are problems to find and problems to prove.
* "Is there a number that when squared equals 4?", is a problem to find since you can test a solution pretty easy.
* "Is the sequence of all prime numbers infinite?", is a problem to prove.
* Finding is easier than proving since you need to demonstrate something is true for all posible cases.
4)
- Design intent will always be lost between design and code.
* We debated design decisions, discovered tradeoffs, imposed constraints; yet none of these is expressed in code.
- Code makes a good job communicating the code model, poor job communicating the runtime and allocation models (where and how is it deployed).
* Runtime model: what components and connectors exist at runtime.
^ How to represent it: Components and Responsibilities table, component assembly diagram, functionality scenario.
- Functionality scenario includes: Name, Initial state, Participants (components), Steps.
- Quality Attributes: describe here the tradeoffs, architecture drivers and design decisions.
- When integrating third-party components, make a list of failure risks.
* Make a diagram and write a functionality scenario of the risks mitigation strategies.
- After laying out a domain model, test it with a concrete example to detect potential problems.
* i.e. if you write a relationships model for Artist -> Song -> Album, the generic model might not highlight the potential shortcoming of handling bands or ex-band members going solo or artists changing names.
- Make rational architecture choices: when 2 ideas seem as good, figure out which quality attribute they help achieve, e.g. usability and testability, then pick the one you value higher.
7)
- Models help you solve problems and mitigate risks, but some problems are better solved directly, not through models.
- Every project should document its architecture: false.
* You should plan before going on a road trip, but you don't plan your commute every morning.
- "Your point of view is worth 80 IQ points", Alan Kay.
- Domain model: expresses enduring truths about the world relevant to the system, if something is 'just true', belongs in the domain.
- Design model: the system to be built makes appearance here, set of boundaries and commitments.
8)
- Domain models express details of the domain not related to the system's implementation.
- Stop domain modelling when it provides less value than other activity, such as prototyping.
- The most valuable part of this model is a list of types and definitions.
- Invariants: things in the model that must always be true.
- Functionality scenarios here include actors (real people or real world objects) not computer records or hardware as in the design model versions.
9)
- Module viewtype: things that exist only at compile time.
* Modules, layers, dependencies, db schemas, interfaces, classes, component types.
* Source code itself (code model) is this viewtype.
- Runtime viewtype: object and component instances, functionality scenarios, component assemblies.
* Hard to envision by reading the source code since you have to mentally animate the runtime instances.
11)
- Create levels of abstraction by hierarchically nesting elements, limit the number at any level, maintain encapsulation by not revealing unnecessary detail.
* Create a story at many levels.
- Dominant decomposition: the problem is that a single organisation system must be chosen.
* Like books in a library organised by size, helps finding the largest books, not so much finding by author.
* Decomposing the system into modules and components imposes an organisation on it.
- Encapsulation: rather than just grouping together related code, hide details likely to change inside the module.
* If you're unsure about design alternatives A and B, have the module's public interface support both, in case you need to swap.
14)
- Pipe-and-filter style: continually and incrementally processing data, (e.g. Node).
- Batch-sequential: complete all processing before moving to the next state.
- Client-server: is asymmetric, only clients can request the server to do work.
- Peer-to-peer: any node can be client or server, no hierarchy.
This entire review has been hidden because of spoilers.
July 13, 2013
I liked the book's pragmatic approach towards modeling and stressing the point that modeling should not be for the purpose of modeling; rather it should be a tool for solving software development problems and difficulties.
May 1, 2020
This book is so dry that it could soak up an entire ocean.
January 31, 2023
Overall, this book has an interesting core idea (risk driven or "just enough" software architecture) that is overwhelmed by solid but fairly standard software architecture guidance. This book was published in 2010 so doesn't account for the way that cloud computing has impacted architecture, but the concepts that are explored are evergreen. It is probably most valuable for students studying software architecture or for software developers early in their career looking to build up on some key concepts. For more experienced developers, I recommend reading the Introduction, Software Architecture, and Risk-Driven Model chapters and skimming the rest, diving deeper based on your interest.
A core idea of this book is that all software has architecture, whether or not it's designed up front and whether or not it's well documented. The purpose of architecture is to abstract away details, partition systems, and encode common ideas. All of these together make it easier to reason about a system. The artifacts of architecture include documentation and diagrams but architecture can also be encoded in the structure of code.
Discussions of architecture sometimes turn into abstract debates between those who advocate for no architecture and those who advocate for a formal process. This book advocates for a third approach: just enough software architecture. But what is just enough? Enough is defined by the level of risk involved. Software with higher levels of novelty or higher levels of criticality deserve more design than software the follows well understood patterns or which can be changed with few consequences.
A design process can be architecture indifferent, where architectural details are not taken into account (often because there is a presumptive architecture to follow). In architecture focused design, architecture is used to achieve certain properties in the design. Architecture hoisting takes this even further and encodes architectural concerns into the structure of the system. An example is that a garbage collected system architecturally hoists memory management by taking it out of the hands of developers and giving up flexibility for consistency. (Whether or not that's the right trade-off depends on the system.)
Instead of thinking about architecture as a singular thing, we can apply these three approaches to the different risks that system designers need to mitigate. To utilize the risk driven mode, developers should (1) prioritize the risks their system faces, (2) choose appropriate architecture techniques to mitigate those risks, (3) reevaluate the remaining risks in light of the work done. For the biggest risks, we may want to apply architecture hoisting, if feasible. For other risks, design may be architecture focused. For low risks, we can afford to be architecture indifferent. By making risks a first class concern, developers strike a balance between doing enough design to mitigate risks with not doing so much design that it becomes wasted or redundant effort. (Note that architecture often deals with quality attribute risks such as performance or security or reliability. The same product features can generally be realized in many architectures, so it's these orthogonal properties where the architectural risks are most important. )
The risk driven approach is compatible with any development process, not just processes with large design efforts up front. For example, in an agile process, using a risk driven approach can help distinguish risks which should be designed for in an upfront design sprint, those which can be handled as they come up, and those which should become backlog items. By making risks explicit, the risk-driven process becomes a way to help product owners understand the costs associated with not addressing these quality attributes.
Although the book covers many other ideas, those were my key takeaways. Even if you do nothing else from this book, internalizing the question of, "What risk does this address?" is a valuable question for determining how much effort to put into any design exercise.
A core idea of this book is that all software has architecture, whether or not it's designed up front and whether or not it's well documented. The purpose of architecture is to abstract away details, partition systems, and encode common ideas. All of these together make it easier to reason about a system. The artifacts of architecture include documentation and diagrams but architecture can also be encoded in the structure of code.
Discussions of architecture sometimes turn into abstract debates between those who advocate for no architecture and those who advocate for a formal process. This book advocates for a third approach: just enough software architecture. But what is just enough? Enough is defined by the level of risk involved. Software with higher levels of novelty or higher levels of criticality deserve more design than software the follows well understood patterns or which can be changed with few consequences.
A design process can be architecture indifferent, where architectural details are not taken into account (often because there is a presumptive architecture to follow). In architecture focused design, architecture is used to achieve certain properties in the design. Architecture hoisting takes this even further and encodes architectural concerns into the structure of the system. An example is that a garbage collected system architecturally hoists memory management by taking it out of the hands of developers and giving up flexibility for consistency. (Whether or not that's the right trade-off depends on the system.)
Instead of thinking about architecture as a singular thing, we can apply these three approaches to the different risks that system designers need to mitigate. To utilize the risk driven mode, developers should (1) prioritize the risks their system faces, (2) choose appropriate architecture techniques to mitigate those risks, (3) reevaluate the remaining risks in light of the work done. For the biggest risks, we may want to apply architecture hoisting, if feasible. For other risks, design may be architecture focused. For low risks, we can afford to be architecture indifferent. By making risks a first class concern, developers strike a balance between doing enough design to mitigate risks with not doing so much design that it becomes wasted or redundant effort. (Note that architecture often deals with quality attribute risks such as performance or security or reliability. The same product features can generally be realized in many architectures, so it's these orthogonal properties where the architectural risks are most important. )
The risk driven approach is compatible with any development process, not just processes with large design efforts up front. For example, in an agile process, using a risk driven approach can help distinguish risks which should be designed for in an upfront design sprint, those which can be handled as they come up, and those which should become backlog items. By making risks explicit, the risk-driven process becomes a way to help product owners understand the costs associated with not addressing these quality attributes.
Although the book covers many other ideas, those were my key takeaways. Even if you do nothing else from this book, internalizing the question of, "What risk does this address?" is a valuable question for determining how much effort to put into any design exercise.
September 27, 2020
If just like me, you lost faith in models and model-driven engineering (MDE) a long time ago, this book might help. It shows how to reconcile architecture and modelling with agility and maintaining real software.
Just enough software architecture advocates modelling software until we feel confident enough to proceed with writing code. That is, if some technical risks (availability, maintainability, etc.) are not yet under control, then we should (re-)think how architectural decisions could help. G. Fairbanks answers many questions: Which models to use? For what purpose? What to model, and to what extent? And, how to reduce the model-code gap?
George Fairbanks has strong credentials. He holds a PhD in Software engineering (Carnegie Mellon University) and has been involved both with Industry and Academia. George focuses on software architecture and software engineering in general. He joins (and speaks something) at both academics and industrial event on software architecture.
Just enough software architecture covers a lot of ground. The first part describes how to risk-drive software architecture. It introduces software architecture and explains how this helps mitigate technical risks such as high availability, maintainability, portability and other “ilities”. Tradeoffs are critical here because many of these quality attributes inherently conflict with one another. Part II focuses on how to model software architecture and overviews its core concepts, such as components, connectors, views, constraints, relationships, patterns, styles, etc. Besides, the various references to books and academic articles give an interesting historical perspective.
It is several years since I had read anything about modelling and software architecture. I think this book is an excellent entry. I like the writing style, and I find the examples relevant without being overly complicated. I definitely recommend it to beginners: It’s full of pointers and covers a broad range of topics.
But seasoned architects might also like it. I like George nuanced approach to modelling (and BDUF), as opposed to agile. His risk-driven idea makes it problem-specific. I do not model for the sake of it, and I am regularly punished for jumping at my keyboard too eagerly.
I also like the discussion of the model-code gap: Some insights and architectural decisions (especially rationales) cannot show up in the code. While the advocated architecture-in-code idea seems a step forward, it only partially addresses this gap. I am curious to see what other solutions have been tried and tested.
Eventually, I give it 3.5 stars. I think it is an accurate introduction to software architecture, in practice, but, even though I am not an expert, there was a lot I already knew.
Just enough software architecture advocates modelling software until we feel confident enough to proceed with writing code. That is, if some technical risks (availability, maintainability, etc.) are not yet under control, then we should (re-)think how architectural decisions could help. G. Fairbanks answers many questions: Which models to use? For what purpose? What to model, and to what extent? And, how to reduce the model-code gap?
George Fairbanks has strong credentials. He holds a PhD in Software engineering (Carnegie Mellon University) and has been involved both with Industry and Academia. George focuses on software architecture and software engineering in general. He joins (and speaks something) at both academics and industrial event on software architecture.
Just enough software architecture covers a lot of ground. The first part describes how to risk-drive software architecture. It introduces software architecture and explains how this helps mitigate technical risks such as high availability, maintainability, portability and other “ilities”. Tradeoffs are critical here because many of these quality attributes inherently conflict with one another. Part II focuses on how to model software architecture and overviews its core concepts, such as components, connectors, views, constraints, relationships, patterns, styles, etc. Besides, the various references to books and academic articles give an interesting historical perspective.
It is several years since I had read anything about modelling and software architecture. I think this book is an excellent entry. I like the writing style, and I find the examples relevant without being overly complicated. I definitely recommend it to beginners: It’s full of pointers and covers a broad range of topics.
But seasoned architects might also like it. I like George nuanced approach to modelling (and BDUF), as opposed to agile. His risk-driven idea makes it problem-specific. I do not model for the sake of it, and I am regularly punished for jumping at my keyboard too eagerly.
I also like the discussion of the model-code gap: Some insights and architectural decisions (especially rationales) cannot show up in the code. While the advocated architecture-in-code idea seems a step forward, it only partially addresses this gap. I am curious to see what other solutions have been tried and tested.
Eventually, I give it 3.5 stars. I think it is an accurate introduction to software architecture, in practice, but, even though I am not an expert, there was a lot I already knew.
June 28, 2019
This is a good introductory book to software architecture. I liked the risk-driven (pragmatic) approach. The author stresses the importance of doing architecture to manage risk and building models to answer questions. Architecture is most important when the chance of failure is high, the solution space is small or the quality attributes requirements are hard to achieve. We need tools to battle the ever-growing scale and complexity issues and this books presents some of these tools: partitioning, knowledge and abstractions.
Many time design intent is lost when coding. This books presents some techniques that can help us keep some of that intent by using architecturally-evident coding style. Some examples are annotations, naming conventions, class hierarchies, invariants and code organization.
The author underlines the fact that functionality and quality attributes are mostly orthogonal: you can build the same system with different architectural styles, but you will trade off quality attributes. I really liked the Rackspace example: how its architecture evolved from using local log files, to client-server, then to map-reduce. The team traded modifiability and latency for scalability.
The chapter on Architectural Styles is interesting. It shows how different style can be used to achieve certain quality attributes. Unfortunately, it's a bit oversimplified. There are some examples throughout the book (Rackspace, Home Media Player and Yinzer - a business social network) that help exemplify the theory. But, as usual, more examples would have been more than welcome.
Many time design intent is lost when coding. This books presents some techniques that can help us keep some of that intent by using architecturally-evident coding style. Some examples are annotations, naming conventions, class hierarchies, invariants and code organization.
The author underlines the fact that functionality and quality attributes are mostly orthogonal: you can build the same system with different architectural styles, but you will trade off quality attributes. I really liked the Rackspace example: how its architecture evolved from using local log files, to client-server, then to map-reduce. The team traded modifiability and latency for scalability.
The chapter on Architectural Styles is interesting. It shows how different style can be used to achieve certain quality attributes. Unfortunately, it's a bit oversimplified. There are some examples throughout the book (Rackspace, Home Media Player and Yinzer - a business social network) that help exemplify the theory. But, as usual, more examples would have been more than welcome.
April 27, 2019
I am very interested in the topic and hoped to get some good insights on the risk driven approach. Wold it not be great if we could do just enough software architecture in our projects and not more? This book only partially lives up to this promise. There are good and insightful parts (like combining risks and how much modelling should be done), but its too wordy and has far too much repetition in it. I especially liked the section further reading at the end of most chapters, where you get a list of books better explaining the content of the chapter you just read. That said, this book disappointed me, and I can’t recommend it.
April 6, 2022
Starting off strong this book describes how architecture should be "just enough" where that line is drawn at the edge of mitigating the greatest risk while leaving decisions for the future. Unfortunately as the chapters increase so does the identified taxonomy of simple things. Beyond over classification the book dives into unnecessary exposition on simple things I'd imagine most readers would regard as true without argument. In the end it serves as a sufficient resource for a budding developer who wants to zoom out and provide some modicum of architectural design, documentation or support for their team. My page tabs are on 95, 133, 256, 283 & 291.
December 22, 2020
This one proved to be such a let-down... While the risk-driven approach the book advocates sounds like a great idea, the book spends most of the time in (what seemed to me) hollow formalisms and taxonomies; the only chapters I found useful were a couple of ones at the beginning and another couple at the end.
Furthermore, throughout the book you'll see ideas, sentences, and even what seems like whole paragraphs get repeated time and again - I'm guessing in an attempt to make each chapter as independent as possible - which, when coupled with a pretty dry writing style, ends up making the reading experience less than enjoyable.
Furthermore, throughout the book you'll see ideas, sentences, and even what seems like whole paragraphs get repeated time and again - I'm guessing in an attempt to make each chapter as independent as possible - which, when coupled with a pretty dry writing style, ends up making the reading experience less than enjoyable.
April 10, 2021
This book is really useful for any software engineer, but it feels like it could have been divided in a few different (smaller) books.
I liked the first part of the book that focused on just how much architecture you would need, but I felt there was a bit too much repetition.
The second part went into more details with practical examples and that was a nice read.
I really liked the last few chapters that gave an insight on different architectural styles, their drawbacks and benefits and will probably try to look into reading more on this subject later.
I liked the first part of the book that focused on just how much architecture you would need, but I felt there was a bit too much repetition.
The second part went into more details with practical examples and that was a nice read.
I really liked the last few chapters that gave an insight on different architectural styles, their drawbacks and benefits and will probably try to look into reading more on this subject later.
March 3, 2022
Overall, this book has potential to be a good intro to some software design/architecture techniques and principles.
At the same time, the title is a bit misleading. "Risk -driven approach" is mostly used in the beginning to defend software architecture as a discipline from Agile "barbarians" saying "do it as much as needed".
In the second part (which is 2/3 of the book) it's just "hardcore" architecture and design, no "risk-driven".
Another issue - it seems that a lot of terminology is taken from SEI and sounds weird (hoisting?), especially for non-native English speaker.
At the same time, the title is a bit misleading. "Risk -driven approach" is mostly used in the beginning to defend software architecture as a discipline from Agile "barbarians" saying "do it as much as needed".
In the second part (which is 2/3 of the book) it's just "hardcore" architecture and design, no "risk-driven".
Another issue - it seems that a lot of terminology is taken from SEI and sounds weird (hoisting?), especially for non-native English speaker.
December 20, 2019
A primeira parte do livro, onde se discute o conceito de arquitetura, sua aplicabilidade em diferentes processos de software, etc traz pontos de discussão bastante úteis mas a segunda parte, onde o autor apresenta estratégias de modelagem arquitetural parece bem dispensável para a maioria das pessoas.
June 20, 2020
Unfortunately, software architecture books still don't contain any insights, but you need to break through a couple of hundred pages to find that out. It's just hard for me to believe that so much text could be so trivial in meaning.
TLDR: account for risks, JavaBeans, design patterns, UML, common sense masquerading as technobabble.
TLDR: account for risks, JavaBeans, design patterns, UML, common sense masquerading as technobabble.
May 31, 2021
This book was a funny journey, most of the things inside of it are well-known for me from other books, but since this is the older one I now see how it all is connected.
Generally the risk-based approach is a good idea how to focus on the really essential parts.
One funny aspect of books about documentation is they usually all tell us not to write docs at all.
Generally the risk-based approach is a good idea how to focus on the really essential parts.
One funny aspect of books about documentation is they usually all tell us not to write docs at all.
October 30, 2019
It's a very long book to explain a very simple concept in a broad/general term. It could be way more on point to help the reader. I was expecting more in depth information about different architectures and how to use it, but never got it. A little bit disappointed.
September 29, 2017
OK. Liked the ball of mud analogy. Wan't keen on the ports and connections model.
April 3, 2021
Very theoretical, academic.
Not really practical or usable in real life
Not really practical or usable in real life
October 30, 2021
Really great guide for communicating the value and necessity of architecture.
July 28, 2014
This is a difficult subject: how much effort should I put into modeling my software architectures and what exactly should be modeled? When do I stop?
Mr. Fairbanks gave it a good shot and he was honest as well. He can't take away the most difficult part: using your brains. His vision of focusing on the risks seems very viable, be it risks on the quality attributes (performance, security, availability etc) or the functionality.
The approach in the book was a practical one. The models of the architecture are not created before you know what they're used for; that's a good advice and even the caveats were provided.
I can recommend this book to all software engineers with some experience (> 2 years); enough that they know the difficulty of working with medium to large sized code bases. Modeling your architecture is there to help you think and make decisions on how to produce software; it's useful to understand why we would even bother documenting that which is already expressed as code. That's why I wouldn't recommend this book to a newbie: he probably wouldn't appreciate the advice. Just like the advice in Software Architecture in Practice (Bass, Len et al) was lost on me when I first read it with less than a year of practical experience.
Mr. Fairbanks gave it a good shot and he was honest as well. He can't take away the most difficult part: using your brains. His vision of focusing on the risks seems very viable, be it risks on the quality attributes (performance, security, availability etc) or the functionality.
The approach in the book was a practical one. The models of the architecture are not created before you know what they're used for; that's a good advice and even the caveats were provided.
I can recommend this book to all software engineers with some experience (> 2 years); enough that they know the difficulty of working with medium to large sized code bases. Modeling your architecture is there to help you think and make decisions on how to produce software; it's useful to understand why we would even bother documenting that which is already expressed as code. That's why I wouldn't recommend this book to a newbie: he probably wouldn't appreciate the advice. Just like the advice in Software Architecture in Practice (Bass, Len et al) was lost on me when I first read it with less than a year of practical experience.
Want to read
June 4, 2019recommendation: [Sebastian Gebski](https://open.spotify.com/episode/33yY...)
October 19, 2015
I loved this book.
It is divided into two main parts, the first covers your definitions and must know terms and facts. It also give a very important insight for the management side of software architecture and software development in general.
The second part covers technical side of software architecture, e.g. listing models with great details, architectural styles and how to use each.
It's a great read for people who are interested in software architecture to get know about risk driven approach of architecture.
It is divided into two main parts, the first covers your definitions and must know terms and facts. It also give a very important insight for the management side of software architecture and software development in general.
The second part covers technical side of software architecture, e.g. listing models with great details, architectural styles and how to use each.
It's a great read for people who are interested in software architecture to get know about risk driven approach of architecture.
December 28, 2012
If you read only one book about software architecture, this should be it. It doesn't cover the details of any specific architectural styles except as examples, but rather sets out a conceptual framework for understanding what you should be focusing on in the architecture, and how certain artifacts (eg, models) will support you reasoning about your architectural choices.
June 29, 2014
This book does a good job of describing various techniques for communicating software architecture. However, if you are looking for a definitive answer to what is "Just Enough Software Architecture" you may be disappointed because it is always going to be: "it depends." This books tries to help guide you in determining what is right for a given situation.
Displaying 1 - 30 of 34 reviews