“97 Things Ever Software Architect Should Know” by O’Reily media is a short book composed of 97 short essays by a variety of contributors. Before reading this book my expectations were somewhat high for it as I was recently assigned the official title of “Technical Solution Architect” so I was hopeful that I could glean a lot of knowledge from some seasoned industry vets.
One of the first things I noted about this book was that it seemed relatively short for 97 solid pieces of information, the book weighs in at 264 pages in ePub format. Most good authors with something important to share typically have a hard time condensing a good thought into less than 10 pages. When I read a technical book I always highlight interesting or helpful information that I want to remember. One of the most concerning things about this book was that I didn’t highlight a single item until chapter 10, or approximately 9.7% into the book. This chapter talks about quantifying results which was one of the best concepts I took from the book. The main principal here is to use quantifiable measures in your requirements instead of abstract terms. Instead of adding the words “quick response time” to a requirement use “average response time in under 20ms” instead.
A lot of the chapters in this book talk about some very fundamental concepts such as simplifying your technical design, which a lesson that I think would do a lot of us good to stay true to. Other things stressed in this book are: always put the client first when architecting an application, focus on the maintainability of the system, don’t over plan for the future, plan for today, and to always try to loosely couple system dependencies.
While in the end I didn’t feel that I learned a whole lot from this book I did find it a quick and somewhat enjoyable read. It also does a good job of enforcing some fundamentals that we all tend to forget over time. It was a good refresher to focus on simplicity and the client’s needs. Too often when architecting an application it’s easy to get wrapped up in implementing the latest frameworks, go a little overboard with design-pattern s, and over obfuscate simple tasks.
I wouldn’t recommend putting this book on the top of your “to read” list if you are looking to improve your development or architecture skills. I would put it somewhere after Fowler’s “Refactoring” and “Patterns of Enterprise Architecture” books and somewhere above “Access 2010 For Dummies”. If you don't find it the most stimulating book you've ever read you may get a few lol's out of some of the pictures the authors chose to submit. I know more than once I thought to myself "That was the BEST picture that person could come up with?", you can decide for yourself who I'm talking about. To find out more or to purchase this book check it out on O'Reilly's website here http://oreilly.com/catalog/9780596522704/.