Just Enough Software Architecture Pdf Download

Open Preview

See a Problem?

We'd love your help. Let us know what's wrong with this preview of Just Enough Software Architecture by George H. Fairbanks.

Thanks for telling us about the problem.

Friend Reviews

To see what your friends thought of this book, please sign up.

Reader Q&A

Be the first to ask a question about Just Enough Software Architecture

Community Reviews

· 151 ratings · 29 reviews

Start your review of Just Enough Software Architecture: A Risk-Driven Approach

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 appr

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.

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.

...more

Nov 30, 2015 Andreas rated it liked it

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.

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.

...more

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. 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. ...more

This review has been hidden because it contains spoilers. To view it, click here. 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 th

Review

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

- 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.

- 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.

- 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.

- 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.

- 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.

...more

Jul 13, 2013 Kassem rated it liked it

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. 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. ...more

May 01, 2020 Stephen rated it liked it

This book is so dry that it could soak up an entire ocean.

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.

...more

Jun 27, 2019 Victor rated it it was amazing

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, 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.

...more

Apr 27, 2019 Johnny rated it it was ok

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 lis 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. ...more

Dec 21, 2020 Miloš rated it it was ok

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 indepe

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.

...more

Apr 10, 2021 Jolan rated it really liked it

Recommended to Jolan by: Bart Du Bois

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 probab

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.

...more

Jun 20, 2020 Acmd etc rated it did not like it

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.

...more

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.

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. 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. ...more

OK. Liked the ball of mud analogy. Wan't keen on the ports and connections model. OK. Liked the ball of mud analogy. Wan't keen on the ports and connections model. ...more

It explains complex architecture topics so clear

Very theoretical, academic.
Not really practical or usable in real life

Oct 30, 2021 Kev rated it it was amazing

Really great guide for communicating the value and necessity of architecture.

Mar 16, 2014 Väinö Leppänen rated it really liked it

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 archite 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.

...more

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

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.

...more

Nov 12, 2012 Finlay rated it it was amazing

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. 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. ...more

Nov 25, 2013 Andy rated it really liked it

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. 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. ...more

Aug 17, 2014 Jose rated it really liked it

This book explains what Architecture is for, and spells out for you different kinds of modeling techniques. Good insights that appear obvious once you think about it, but many teams out there fail to notice.

For example, I enjoyed the tip of not making a model unless you have a question that you want to answer.

Good read.

It should be an introduction to software architecture. There are two parts, the first says about the risk driven architecture while the latter states about how to model the architecture.

However it focuses too much on how to model the architecture and makes boring chapters.

the first part (about the risk-driven model) was pretty theoretical and I did not find it very worthwhile. The rest of the book was really good though.