Book: 97 Things Every Software Architect Should Know
Author: Richard Monson-haefel
By experience, I know that given the same requirement for a brand new application - no two architects design it with the same architecture (technology choice, platform, frameworks, patterns etc). How can there be a definite “97 things” that every software architects should know?. That too is a collective wisdom from the experts?. Those were the question popped into my mind when I picked this book from the library. I read it completely to understand it.
If you are a Tech Lead, transitioning to perform the Architect role in any project, then you should read this book to get the general idea behind software architecture. This book is a collection of two-page articles from many software architects. Many architects contributed multiple articles to this book. All of these articles touch upon a specific case or feature of software architecture. None of these articles discuss in detail about any specific item. Much like free blog posts. When I see a book with a title like this, I expect more in-depth analysis or case study of software architecture. I am disappointed in this front. If you are already an architect, this book would be a good casual read.
Imagine you being in a room with a bunch of well-experienced architects, having a casual chat about software architecture with no definite agenda. How would that look like?. Lots and lots of valuable information about software architecture, as well as some conflicting or possibly heated discussions among the architects on specific areas or ways of implementation. Right?. This book exactly simulates that discussion, except that every architect is given two pages for an article and no one can interrupt the other. I would suggest reading this book when you have free time and don’t take any of the suggestions blindly. None of the approaches discussed here works in all cases. Use this book to know, how other architects may think in a specific case and use your common sense to come up with the approach for the problem in hand.
Don’t put your resume ahead of the requirements - Nitin Borwankar
Chances are, your biggest problem isn’t technical - Mark Ramm
Everything will ultimately fail - Micheal Mygard
It’s never too early to think about performance - Rebecca Parsons
If you design it, you should be able to code it - Mike Brown
Give Developers Autonomy - Philip Nelson
Pattern Pathology - Chad LaVigne
Focus on Application Support & Maintenance - Mncedesi Kasper
The Business Vs The Angry Architect - Chad LaVigne
Being in the software industry for 9 yrs and having the privilege to work with multiple clients in multiple projects across multiple locations in the world, I can resonate strongly with the above articles. For each of the articles, I can site a project/application from my experience - for not so efficient design. Every time I raise my voice against these inefficient work, either I will be silenced in the name of “cost-effective solution” or I will be kicked out of the project (Yes. Seriously, it does happen even now). I am not being mean here, I can cite many more awesome designs and appreciations as well.
I understand that the role of an architect is like a bridge between business and technology. For some unknown reason or by natural instinct, I weigh technology more than business. I want all I create, to be perfect at the time of creation. I had the complete freedom in a couple of projects so far. The “REST services” for AMEX iPhone App and the AMEX Blackberry App. Though there were existing technology limitations, I did not do any architectural trade-off in that project. I was so happy with the implementation. You know what?. The technology, platform and the framework of the “REST services” changed within two years after I left AMEX.
I would like to thanks, some of the architects, who helped me to mature my understanding of software architecture, in the order that I worked with them.
Cary Alan Bakker
Copyleft @ 2009.