What do you think?
Rate this book
97 Things Every Software Architect Should Know: Collective Wisdom from the Experts
In this truly unique technical book, today's leading software architects present valuable principles on key development issues that go way beyond technology. More than four dozen architects -- including Neal Ford, Michael Nygard, and Bill de hOra -- offer advice for communicating with stakeholders, eliminating complexity, empowering developers, and many more practical lessons they've learned from years of experience. Among the 97 principles in this book, you'll find useful advice such as: To be successful as a software architect, you need to master both business and technology. This book tells you what top software architects think is important and how they approach a project. If you want to enhance your career, 97 Things Every Software Architect Should Know is essential reading.
222 pages, Paperback
First published January 1, 2009
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 71 reviews
Read
July 21, 2022Most of these are quotes from this book. I would strongly recommend it for Software Architects and designers.
Concepts covered
- Essential complexity
- Accidental complexity
- Budgetecture
- Architecture and Process
- Instruction vs data oriented view of software
- Elements of a good implementation - clarity, testability, correctness and traceability
- Stretching key dimensions of the architecture and seeing what breaks
- Programming problems vs architecture problems
Notes and Quotes
- Your biggest problem may not be technical
- People are the foundation for success or failure
- No one will read a 100 page architecture document (communication is the key)
- Engineering is about making trade-offs
- Simplicity vs generality
- Architects must be hands on (in previous incarnations they would have been programmers and software designers)
- You (as an architect) do not drive architecture. Requirements do.
- The model is not the architecture
- Think outside the stack
- A good architect is open to new ideas
- Start with a skeleton connecting all the services and implement incrementally
- A good design will document itself
- The insidious thing about good ideas is that they are good
- Names convey intentions. So pay attention to naming things.
- You can't future proof architecture
- Great software is not built. It is grown.
- The single biggest predictor of software failure is its size
- Design the smallest system you can and let it evolve
Concepts covered
- Essential complexity
- Accidental complexity
- Budgetecture
- Architecture and Process
- Instruction vs data oriented view of software
- Elements of a good implementation - clarity, testability, correctness and traceability
- Stretching key dimensions of the architecture and seeing what breaks
- Programming problems vs architecture problems
Notes and Quotes
- Your biggest problem may not be technical
- People are the foundation for success or failure
- No one will read a 100 page architecture document (communication is the key)
- Engineering is about making trade-offs
- Simplicity vs generality
- Architects must be hands on (in previous incarnations they would have been programmers and software designers)
- You (as an architect) do not drive architecture. Requirements do.
- The model is not the architecture
- Think outside the stack
- A good architect is open to new ideas
- Start with a skeleton connecting all the services and implement incrementally
- A good design will document itself
- The insidious thing about good ideas is that they are good
- Names convey intentions. So pay attention to naming things.
- You can't future proof architecture
- Great software is not built. It is grown.
- The single biggest predictor of software failure is its size
- Design the smallest system you can and let it evolve
March 9, 2012
Main problem with this book, is that isn't real book - it set of very short essays, that almost not linked to each other excluding mega-topic called "software architecture".
So it very inconsistent - after essay on performance, goes essay on communication skills, then essay on code organization, etc. It's hard to read such things...
It's better to read normal books, like "Release It!", "12 essential skills for software architects", etc. if you want to read something about software architecture processes and related things
So it very inconsistent - after essay on performance, goes essay on communication skills, then essay on code organization, etc. It's hard to read such things...
It's better to read normal books, like "Release It!", "12 essential skills for software architects", etc. if you want to read something about software architecture processes and related things
April 23, 2015
97 two-page pieces of advice about software architecture. Since each entry is only two pages, there's a limit to how in-depth they can be, so they tend to stay fairly general.
There's a few good points here and there, but I think I've already forgotten most of them again.
There's a few good points here and there, but I think I've already forgotten most of them again.
February 17, 2016
This small and extremely slender book, consisting of more white space than content, contains a series of what are basically one-liners from a variety of authors, with about a page of exposition on each.
A few of the points are incisive, the vast majority are blindingly obvious, and a small number are ridiculous (I'm still trying to work out why a software architect "must" be able to cable a network. No reason why s/he shouldn't be able to, but why is this a necessity?).
The targetting of the advice is pretty wayward as well - about half of the points are relevant to a lead developer/designer, but the rest are scatter-gun advice more relevant to a project or product manager, or a team leader.
If you're taking your first steps from "developer" to "lead developer", you might find some of the advice pertinent. If you have much more experience, you're likely to be wasting both your time, and (even at the Amazon price rather than the ludicrous $36 cover price) your money.
A few of the points are incisive, the vast majority are blindingly obvious, and a small number are ridiculous (I'm still trying to work out why a software architect "must" be able to cable a network. No reason why s/he shouldn't be able to, but why is this a necessity?).
The targetting of the advice is pretty wayward as well - about half of the points are relevant to a lead developer/designer, but the rest are scatter-gun advice more relevant to a project or product manager, or a team leader.
If you're taking your first steps from "developer" to "lead developer", you might find some of the advice pertinent. If you have much more experience, you're likely to be wasting both your time, and (even at the Amazon price rather than the ludicrous $36 cover price) your money.
March 19, 2017
Some tips were great. Some were just common sense. A lot of overlapping stuff.
November 13, 2018
Why not 98, 99, or 100 things every architect should know?
There are a few good points in this book but each essay is less than 2 single-spaced pages. That's not nearly enough depth to go into a worthwhile conversation and this book would've been better written as a series of tweets.
Context: I had to read this book for class and wouldn't have picked it up myself.
There are a few good points in this book but each essay is less than 2 single-spaced pages. That's not nearly enough depth to go into a worthwhile conversation and this book would've been better written as a series of tweets.
Context: I had to read this book for class and wouldn't have picked it up myself.
May 8, 2021
The book is collection of advises each one is 2 pages, few of them are deep, more of them are basics (but I believe they are forgotten by most of today’s architects). Generally I like the book you can finish it so fast and return to it even from time to time.
June 24, 2011
A collection of 97 two-page essays by 97 software architects about things they think every software architect should know. Most of them are very reasonable (don't use clever tricks; don't let your software have too many layers; understand that the usual abstractions are broken in the error cases). Some, however, are strange (be a good manager for different kinds of people as described in Neal Stephenson's Cryptonomicon; realize that software architecture has ethical consequences? it does, but they are usually far removed from the decisions software architects make; it is all about the data? for a bank, maybe; for an airline flight scheduler, no).
January 27, 2018
Short, personal essays on software architecting as a practice. Some fell flat, yet enough hit the mark--and some quite pointedly--on a theme worth remembering, reflecting on against one's experience. The kind of book perhaps to skim again after a new phase of completed projects.
Sure, don't expect to make this your one book on software architecture. And Yet. In a realm full of large, highly organized, overly prescriptive books, this reads more like a series of conversations you might have with colleagues at a conference or q&a with a workshop speaker. Without the powerpoints, travel and crummy reception food.
Sure, don't expect to make this your one book on software architecture. And Yet. In a realm full of large, highly organized, overly prescriptive books, this reads more like a series of conversations you might have with colleagues at a conference or q&a with a workshop speaker. Without the powerpoints, travel and crummy reception food.
October 23, 2012
Short and easy read. 97 tips and thoughts of software architects mostly unrelated to one another but almost all of them come down to some basic rules (like: clear communication, healthy environment, follow tested best practices of software development, know what you are doing, etc.).
I gave 4 stars because you can take any of 97 "things" from the book, read it and reflect on your own experience. Thus reminding yourself the lessons you learnt from you previous projects/failures. So this book is as goos as you and your own experience in the field.
I gave 4 stars because you can take any of 97 "things" from the book, read it and reflect on your own experience. Thus reminding yourself the lessons you learnt from you previous projects/failures. So this book is as goos as you and your own experience in the field.
February 5, 2015
If you are familiar with Agile software development and Domain Driven Design, you will find many of the tips in the book have relevance!
To sum up the most important things I got from the book:
- Go Agile, Go Agile, Go Agile
- Design patterns is important (they are not those of GoF patterns only), but you should know anti-patterns, and refactor to patterns not try to force applying them in the first place!
- An architect is a leader as well
- An architect should have hands on experience, and can write code
To sum up the most important things I got from the book:
- Go Agile, Go Agile, Go Agile
- Design patterns is important (they are not those of GoF patterns only), but you should know anti-patterns, and refactor to patterns not try to force applying them in the first place!
- An architect is a leader as well
- An architect should have hands on experience, and can write code
October 22, 2017
The problem is that this is not really a book per se, but instead just a collection of short articles circling around the topic of software architects. It does give you some sort of an idea about the work of software architects – what they job consists of, what kinds of problems they're dealing with. But then again most of the advice given is really common sense. The most interesting part was the story how a database was selected for the M1 Abrams battle tank's software system. I'm sure there are better books if you're interested in being a software architect.
February 8, 2016
This book is a set of 97 short essays written by a lot of software architects. It brings us nice advises encompassing technical aspects and soft skills.
Easy and fast reading, it's a good book for everyone who wishes to understand better the skills needed to a software architect and a good start to think about the "big picture" of a software project.
Easy and fast reading, it's a good book for everyone who wishes to understand better the skills needed to a software architect and a good start to think about the "big picture" of a software project.
May 29, 2017
97 one-liners, chosen to be approachable & non-controversial. Fit more for an aspiring developer than actual architect. Not really revealing, bloated with repeated expert bios. Sadly this book quickly becomes annoying & it gets harder & harder to resist the temptation to skip subsequent "chapters".
Skip it.
Skip it.
January 24, 2020
It's a must-read position, not should-read. I would even say that it should be reread every year. Very convenient to read chunk by chunk, you don't need to spend too much time to read a whole chapter at once. Most of the chapters apply not only for architects, just remember, you don't have to be called an architect to think about an architecture.
February 3, 2020
Good book. Pretty much philosophic. Needs from you not just to read it and close it forever, but to reread some parts of it now and then, think about given suggestions, try to change yourself and your environment.
This book is useful not only for software architects, but for software developers as well.
This book is useful not only for software architects, but for software developers as well.
January 7, 2018
After a long time, I have read a technical book and reading this book has been a completely different experience as compared to the other technical books I have read before. This book gives insights of the things a software architect should know from the perspective of the technical experts. I wrote an article as my learnings from this book while I was in middle of it: https://www.linkedin.com/pulse/things...
I have an urge of re-reading the book and write another refined article of my other major learnings from this book.
I have an urge of re-reading the book and write another refined article of my other major learnings from this book.
February 16, 2020
I am not sure what for this book as personally I found it as the book which gives general and overall understood, by everybody more or less experienced, rules and approaches. The reason behind 3 stars rate that it still gives ideas which have to be followed not only by architects but as well as developers, QAs and other project’s stakeholders.
I will recommend reading it if you’re a bit tired of too technical books, want something easy to read and just want to reassure your knowledges of everything around any project life cycle.
I will recommend reading it if you’re a bit tired of too technical books, want something easy to read and just want to reassure your knowledges of everything around any project life cycle.
August 26, 2021
This book is basically a collection of well-intended advises, picked from a long list initially collected in some kind of forum, which appears to be absent right now. Too bad some things don't age that well.
Anyway, some of the advices here are common sense, other ones are really interesting and worth to follow or rather try out, like if there is only one solution to a problem you really need to get a second opinion to verify, if you really understood the problem. The premise here is that there should be more than one, just with trait-offs.
Anyway, some of the advices here are common sense, other ones are really interesting and worth to follow or rather try out, like if there is only one solution to a problem you really need to get a second opinion to verify, if you really understood the problem. The premise here is that there should be more than one, just with trait-offs.
December 9, 2022
Two page items, so this is a breadth not depth book, and going into it with that in mind you can get a lot out of the highlighted items. Various levels of overlap, given the 50 or so authors selected.
Includes highlights such as Stand Up; The user acceptance problem; Software architecture has ethical consequences; Reuse is about people and education; Focus on the boundaries and the interfaces.
Articles are starting points, not solutions.
Includes highlights such as Stand Up; The user acceptance problem; Software architecture has ethical consequences; Reuse is about people and education; Focus on the boundaries and the interfaces.
Articles are starting points, not solutions.
June 11, 2021
A collection of short advices from different individuals. Which makes it very repetitive and shallow.
Very good advices from experienced people but Probably the table of content with a line description on each point was enough to deliver the message.
I completed the whole book but it was very easy to speed read many parts.
Very good advices from experienced people but Probably the table of content with a line description on each point was enough to deliver the message.
I completed the whole book but it was very easy to speed read many parts.
August 18, 2022
I’ve been a software architect much of my career and I found the examples interesting, but redundant at time. It’s a great book for a new software architect with a solid development background looking to move up into architecture. Maybe something to keep on the desk for a bit of a distraction from actual work.
July 3, 2017
Well why 97? That was my first question. Then after reading it it was - it was not even 97! Several advices are same thing said with other words, a lot of it are advices from same autors so in general was not much usefull or new. That is why I probbably needed almost a month to finish it. :)
March 15, 2019
This book contains a lot of really great advice, but the tips are poorly structured. It would be much easier to read and retain the information if the 97 things were organized into sections with a unifying theme or ordered sequentially to parallel the process of designing a software system.
June 30, 2019
It is not very revealing book, however it is still worth to read. It contains 97 articles written by different authors. Some of them are more intersting, some of them less interesting. In general, it focuses on non-technical aspects of being architect
February 3, 2022
a worthy quick read , the book isn't meant to give breakthrough insights but rather help you form how you approach architecture and the right mindset of doing so (which I consider extremely important )
January 16, 2023
Lots of small chapters with glimpses of ideas and expertise.
Some of them make you think and others state obvious points.
Not what I would expect in a book format but it is a good compendium to read a few minutes at a time.
Some of them make you think and others state obvious points.
Not what I would expect in a book format but it is a good compendium to read a few minutes at a time.
June 22, 2017
Trae comentarios interesantes, algun que otro buen consejo.
September 30, 2017
Dos o tres consejos bien. El resto son generalidades, cosas que ya no sirven, o malos consejos
December 2, 2018
It’s like reading a table of contents.
Not enough content to be useful
Like this:
How to get a million dollars and not pay taxes?
First, get a million dollars.
The....
(From Steve Martin)
Not enough content to be useful
Like this:
How to get a million dollars and not pay taxes?
First, get a million dollars.
The....
(From Steve Martin)
Displaying 1 - 30 of 71 reviews