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