97 Things Every Software Architect Should Know

by Richard Monson-Haefel (editor)

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.

Genres: Programming, Software, Technology, Architecture, Technical, Computer Science, Nonfiction

220 pages, Paperback

First published January 1, 2009

Reviews

[Dorai Thodla]

Most 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

[Alex Ott · Rating 2 out of 5]

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

[Mark Seemann · Rating 2 out of 5]

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.

[Steve Whiting · Rating 1 out of 5]

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.

[Robert Richter · Rating 3 out of 5]

Some tips were great. Some were just common sense. A lot of overlapping stuff.

[Tess Huelskamp · Rating 2 out of 5]

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.

[Mohamed Ibrahim · Rating 4 out of 5]

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.

[Ushan · Rating 3 out of 5]

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

[Steve · Rating 4 out of 5]

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.

[Said A · Rating 4 out of 5]

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.

[سامح السيد · Rating 3 out of 5]

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

[Tomi Turtiainen · Rating 2 out of 5]

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.

[Robson Castilho · Rating 3 out of 5]

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.

[Sebastian Gebski · Rating 2 out of 5]

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.

[Andrzej Hołowko · Rating 5 out of 5]

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.

[Роман · Rating 5 out of 5]

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.

[Mehdi · Rating 4 out of 5]

I've recently gone through the audiobook of "97 Principles for Software Architects" available on Scribd.
[Link: https://www.scribd.com/audiobook/4731...]

The audiobook is quite informative and provides a wealth of insights for individuals seeking to enhance their understanding of software architecture. While I can't directly comment on "97 Things Every Software Architect Should Know" as I didn't read the exact book, I found this audiobook to be a valuable resource in its own right. It covers a range of principles that are likely to benefit software architects and those in related roles. Overall, I believe it's a worthwhile listen for anyone interested in software architecture concepts and practices.

[Ankita Mogha · Rating 4 out of 5]

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.

[Anatolij Grigorjev · Rating 3 out of 5]

I have read other books in the “97 things” series, and have enjoyed most of it
This was the first one that felt like a waste of time.
Perhaps the other reviewers have correctly identified that this subject matter is ill fitting for the format - architecture advice compressed to 4 pages and broad enough for a general audience is close to meaningless. Some interesting general truths can be gleaned here and there, but anything that might have been profound here in 2009 has become widely adopted and/or outdated in the industry at large in the decade since.
This book has some significance, but not much beyond

[Danylo Bilokha · Rating 3 out of 5]

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.

[Christoph Kappel · Rating 5 out of 5]

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.

[Juan González Núñez · Rating 2 out of 5]

Knowledge Level: Intermediate
Audience: Developers and Architects that want to review different points of view.
Audio Candidate : Yes
Review: This is a collection of several architects that explain concepts or best practices. This can work if you are not looking for deep conversations.
Lessons Learned: "Without business domain knowledge, it is difficult to understand the business problem, goals, and requirements, and therefore difficult to design an effective architecture to meet the requirements of the business."

[Anton Antonov · Rating 4 out of 5]

It's a collection of essays, which is why it's just a 4-star rating. It's a collection of thoughts and tips.

The core ideas of these essays are great. To name a few.

1. Don't be clever
2. The "A"s in Software Architect are lowercase.
3. Take Responsibility for your Decisions
4. Find and Retain Passionate Problem Solvers
5. Communication Is King; Clarity and Leadership, Its Humble Servants


Is this book useful for non-architects? If you want to become one eventually, how would you gain the right ideas and practices? Read such books :)

[Ninja · Rating 4 out of 5]

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.

[Ahmed Gamal · Rating 2 out of 5]

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.

[Julie · Rating 3 out of 5]

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.

[Matt Luedke · Rating 4 out of 5]

Each of the 97 "things" in this book was concise and insightful. After finishing it, I found I wanted to re-read it, and will probably do so multiple times both to internalize it but also because, like all timeless advice, its relevance will change and deepen as I handle different projects and challenges.

[Leo Mazzi · Rating 3 out of 5]

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

[Dhara Patel · Rating 3 out of 5]

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.

[Jarosław Kozioł · Rating 3 out of 5]

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