Customer Reviews

Just Enough Software Architecture: A Risk-Driven Approach

5 star:		(8)
4 star:		(2)
3 star:		(0)
2 star:		(2)
1 star:		(0)

 

 

This a broad and deep book on all things software architecture except the architecting process (for process, one recommended read is "Process Software Architecting" by Eeles/Cripps). Several readerships will benefit from "Just Enough Software Architecture":
- As an experienced IT architect, I do not necessarily agree with everything in the book (this does not come as a surprise, as architects have opinions). That said, I certainly learned a lot that I can apply immediately on my projects and some of the more provocative statements challenge me to leave my comfort zone (or at least consider doing so).
- Junior architects can use the book both as a tutorial and as a reference when/while growing in their profession.
- Developers with a "who needs architects" mindset (hopefully) will understand architects and modelers much better after having read this book, and appreciate the value of archtecture.

Things I liked in particular:
- Overall vision and message of pragmatism sent
- The risk-driven approach increases chances to get accepted both in agile development and in more traditional architecture communities
- There is a lot of practical advice e.g. in Chapters 10, 11 and 15
- The author is in command of a large body of relevant related work (both industra and academia) and puts them in perspective adequately
- Editorial quality: structure, figures, command of the English language (some words and expressions a bit be hard to comprehend for non-native speaker)

Some room for improvements (2nd edition?):
- Not all metaphors and analogies work internationally, e.g. not all IT people are sports fans that follow baseball or know what a rookie is
- The connection between parts 1 and 2 could be a bit stronger, even if loose coupling generally is a good thing; e.g., some more backward references

In summary, I'd say Just Enough Software Architecture is a highly recommended read for every architect in touch with development reality and every developer with a desire to build complex systems that will stand the test of time.

George Fairbanks book on "Just Enough Software Architecture" signals a directional shift away from architecture as a separate entity and movement toward viewing software architecture as holistic component of normal software development. Dr. Fairbanks outlines this shift by developing a thesis that software architecture is primarily a risk reduction agent and he contends that stakeholders should look for architectural views that highlight the risky parts of a software intensive system and understand how the architectural design reduces that risk.

To develop that thesis "Just Enough Software Architecture" covers architectural modeling, classification, styles and uses. Most of the chapters reinforce the risk reduction thesis either through examples or models where these principles are clarified. Dr. Fairbanks also uses a slight variation of the standard UML 2.0 notation, simplifying that notation in an attempt to show how even straightforward models can highlight the mechanics of the architecture.

One concept that "Just Enough Software Architecture" introduces is the concept of "architecture focused design", which is a deliberately chosen architecture to achieve a collection of acknowledged goals. The author espouses the concept that these goals are driven by the constraints of the system. These constraints should act as "guide rails" and they ultimately can be used to influence and direct the system or systems being developed. Many systems have hidden constraints (for example performance or security) and this architectural approach can help influence system implementers in making architecturally aligned development decisions.

Overall, I enjoyed George Fairbank's book and believe it forms an interesting discussion starting point for any organization performing software architectural work. I would hope that a companion volume is added that does a set of more detailed case studies of how actual risk-based architecture fares in practice.

This is a fantastic book about software architectures. The concepts described in this book can be directly applied to software projects, enabling developers to access their designs in a principled way that can lead to the right architectural solutions. The concepts presented here are easy to be understood and applied in practice in our day to day projects.

The premise is good: describe software architecture from developer perspective in a pragmatic, no non-sense, minimal way (just enough) with emphasis on design and engineering aspects. Put the risks first and let them control the amount and depth of your design. Fluent style with original analogies contributes to an agreeable reading and elegantly avoids the potential boring sensation typical for other technical texts. However as you progress the material accentuates too much the "meta" data about architecture (views, styles, model traits...) as opposed to the architecture itself. I did not expect diagrams with tens of elements but the recurring ones with two, three elements tend to look simplistic after a while. I question in the big picture of architecture models the "code model" as a valid chapter. More complex architecture examples and more diverse architecture themes (e.g. distributed architectures, risks when integrating open source, top-down vs. bottom-up architectures) would benefit a material build on a ... good premise.
Excellent chapter 12 (and following) describing components and connectors and how they fit together.

I must admit that the title of this book made me hesitate to purchase it. I am not a big fan of placing the architecture process inside one of the concerns architecture addresses. "Risk-Driven Approach" scared me off because of some of the other attempts to do something similar with security, performance, agility, and patterns. Although all these topics are part of the architecture process, they do not drive it on there own.

Having said all that, I was releaved to see my worries about what I would find in the book where not valid. To me this book is a good overview of what Software Architecture is, which of course incudes addressing risks. There is a chapter on the risk-driven model which does a good job of putting risks into the proper context. It does a good job of showing how risk concerns relate to the development process. The book does not obsess on risk. It just brings to light an important part of what architecture addresses.

The books starts with an overview of software architecture concepts and does a good job of explaining what software architecture is. It also includes a short case study.

The second part of the book covers the Domain Model, Design Model, Code Model, Encapsulation and Partitioning, Model Elements, Model Relationships, and Architectural Styles. Each topic is given its own chapter, and there are a lot of great diagrams throughout the book. I really like that the author covered code and bridging the gap between models and code. I also like how he explains the relationship between models.

The book referred to industry best practices and did not try to re-invent the wheel. The author has his PhD in software engineering from CMU, so there are a lot of references to SEI practices. The author also contributed to the new version of Documenting Software Architectures: Views and Beyond (2nd Edition).

I also like the glossary. It does a great job of summing up architectural topics.

All in all anyone interested in Software Architecture would benefit from reading this book. It contains a ton of great information from all the best resources on software architecture and does a great job of putting them into context.

I thought overall that the book was pretty good. The author did a good job of laying the groundwork for how to determine when to stop designing your architecture and how to effectively accomplish the design with a special ear towards quality attributes.

The author was a bit wordy towards the end, but given that those chapters were meant as a reference, I guess that's ok. You really only need to read the first part of the book to understand the methodology. For a deep dive into the concepts introduced in the first part, the second part is where it's at. It would have been nice if the author had used a single over-arching example throughout the book. The examples he gave, like the Yinzer system (a job-advertising social network), felt incomplete to me. For example, he started the Yinzer example to include the domain and design models, but switched to a new example, an email processing system, for the code model.

In any case, after reading the book, I'm finding myself thinking about work projects at a higher level now. I'm definitely recognizing and applying architectural styles more consciously, instead of by accident. So, I would consider that a success in my mind and would recommend it to others!

Agile practices, say's nothing and it doesn't call against Software Architecture. Software Architecture is independent of the Methodology or Practices. But exercise both in the same project, as been always a challenge, since sometime both point to opposite directions, and where to go.
Dr. Fairbanks, on his book "Just Enough Architecture", helps to fill that gap between both, and gives a big shift to the practices of Software Architecture, helping to place both in the same direction.

If you are a Software Architect, or a Senior Developer, or even if you are an aspiring Architect or a developer that want's to grow in his career, this is one of those books that you should read, and keep on your bookcase as a reference.

JESA provides the perfect amount of guidance and structure for a software executive to tackle real world challenges. We've used it as a reference when tackling difficult issues in our cloud and mobile architecture. Packed with great examples for those of us that get more from seeing concepts in action. Lots of intellectual topics covered in an easy read. A+ in my book!!!

During my last year of graduate school several years ago, I wrote reviews for two software books that I still consider exemplary: "Object Technology: A Manager's Guide", by David A. Taylor, which I called "the best concise introduction to object-oriented technology", and "Software Architecture in Practice", by Len Bass, Paul Clements, and Rick Kazman, the software architecture Bible at the time. As a consultant whose experience includes software, systems, and enterprise architecture, "Just Enough Software Architecture: A Risk-Driven Approach" is the book I will now be recommending to software developers who either have no architecture-level experience, or who need to get back to the basics of what software architecture is really all about.

Although I recently rated another text entitled "97 Things Every Software Architect Should Know: Collective Wisdom from the Experts" with high marks, I commented in my review that "after reading [that] book the reader will likely leave with an understanding of a broad range of architect responsibilities communicated by dozens of different architects with varying levels of experience across numerous business industries", and that "the degree to which their thoughts subtly differ on this aspect somewhat reflects what one will find in the workplace, especially when working as a consultant". However, for a cohesive treatment of software architecture, the goal of which is to start students and professionals on the right track, there are no other texts than can stand up to this one in the year-2010 marketplace.

Thinking back to my use of both the first and second editions of "Software Architecture in Practice" during my first graduate-level architecture course, I remember using the second edition to a greater extent than the first edition because of its use of UML. In fact, I had been known for quite some time to be a bit of a stickler for proper UML notation. Now I am known to combine component and deployment diagrams on a frequent basis just because it often makes sense to do so (if the tools being used are permissive in that sense). That said, the only aspect of the content that Fairbanks provides that I am not sure about is the ample use of legends within UML diagrams to explain what different lines and shapes convey. Because the goal of this book is not to teach UML, however, holistically speaking this is just a slight annoyance.

The first part of this book, "Risk-Driven Software Architecture", is what I especially enjoyed about what Fairbanks has to share with readers. Right off the bat, the delineation that the author provides between the job role of "architect", the process of "architecting", and the "architecture" engineering artifact is well done, as are his explanations of risk-driven architecture and agile architecture, and why software architecture is important. In addition, the extended example of risk-driven software architecture approach usage is effective, especially the points that the author makes about team communication, an extremely important aspect of architecture that is somehow often missed in other works of this genre.

Of the chapters within the second part of this book, "Architecture Modeling", I especially enjoyed Chapter 13, "Model Relationships". Although perhaps best read by novice architects, as a professional I found this chapter appealing because I have noticed the prevalent misunderstanding that exists in industry of how models relate to each other, and Fairbanks writes extremely well in this chapter as with the rest of the book, patiently walking the reader through every step along the way. Some potential purchasers of this book might be interested in knowing that the author shares effective "further reading" sections throughout that not only suggest other books to read, but provide CliffsNotes-styled commentaries of why each should be read. Well recommended.

This is a very impressive book with very straight forward, simple facts stated as-is.
Author has chosen to present the material simply without any artificial coating or superficial language;

A very easy read both on eyes and on content - great work and good reference for any architect - a must read;