Brian On Software

What started as an article a few years ago, titled 10 Things Every Software Architect Should Know, has morphed into a collection of essays written by software professionals and for software professionals. The author of the original article, Richard Monson-Haefel, did well on following the suggestion of Jay Zimmerman to publish a book as a collection of essays sharing pragmatic experience, wisdom, insight and diversity in the field of software architecture.  From the back cover, we can read the following:

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 hÒra – offer advice for communicating with stakeholders, eliminating complexity, empowering developers, and many more practical lessons they’ve learned from their years of experience.

Published by O’Reilly, “97 Things Every Software Architect Should Know” turns out to be authored by a multitude of different people from around the world and from diverse companies.  The common point of interest amongst all the contributors is their role on the job, that of a software architect.  As the title suggests, there are in fact 97 different essays written by many practicing software professionals that were willing to share their experience, wisdom, proven techniques, mistakes, lessons learned, etc., about their profession and role of that of a software architect.

But what exactly is a software architect?  Though there isn’t a specific definition for that title, there are many accepted ones.  According to Wikipedia (source),

Despite the lack of an accepted overall definition, the role of software architect generally has certain common traits:

Strategic thinking
Architects address the technological aspects of business needs by considering what a given technology can contribute to the overall functions of the system, as distinct from how that technology will perform its own functions.  This encourages opportunities for re-use of the technology and ultimately contributes to the organization’s efficiency.

System interactions
Architects deal with the interactions of systems, whether between components written in different languages at different time and at different locations, or between components of the same software system that use the same coding language.

Design
The architect makes high-level design choices much more often that low-level choices.  In addition, the architect may sometimes dictate technical standards, including coding standards, tools, or platforms, so as to advance business goals rather than to place arbitrary restrictions on the choices of developers.

Communication
Architects also have to communicate effectively, not only to understand the business needs, but also to advance their own architectural vision.

As there are many different traits pertaining to software architecture, there also many different roles a software architect can play, be it: Enterprise Architect, Application Architect, Infrastructure Architect, Security Architect, etc.  As the author acknowledges,

“97 Things Every Software Architected Should Know” provides advice from software architects around the world on everything from how to avoid common pitfalls to how to build talented teams.  It’s a smorgasbord of advice from established software architects for other software architects or those who aspire to become software architects.

Throughout the book, you will find many essays dealing with at least one of these traits and some specific to a role.  The essays aren’t categorized in any way, so each one you read can deal with something different than a previous one, which might be a good idea…or not.  I would’ve preferred if the essays were categorized by traits (or other subject) so that I can focus my reading on a group of them when I want or need to.  For example, if I want to read some essays pertaining to effective team building, I could focus on reading a subset of those essays.  As it stands, I have no much choice but to read each of them sequentially, which can become quite tedious as some essays can be lightly equivalent to another in terms of idea and interest.  Nevertheless, since the content of the essays are rich, insightful and resourceful, I don’t mind too much about the overall layout.  On a last note about the structure of the book, I was very pleased to see that each essay was presented on a two-page presentation (left page and right page).  In other words, if you turn a page, you get a new essay.  At the end of each essay, you also get a brief bio of the author who wrote it so that you can either stalk him…or Google him.  Finally, there aren’t only male authors who contributed in this project.  As a matter of fact, Allison Randal and Rebecca Parsons (CTO of ThoughtWorks) also contributed their own insights.

Many of the co-authors that participated in this project were unknown to me, so reading this book actually allow me to plug into the world of some them through their personal websites or blogs.  Amongst the list of people who contributed to the book are Erik Doernenburg, Udi Dahan, Niclas Nilsson, Neal Ford, Keith Braithwaite, Gregor Hohpe, and many, many more.  Funny thing is that two articles that I very much enjoyed  much reading were written by a guy I’ve never heard of before: Timothy High, a software architect working for Sakonnet Technologies.  In fact, he’s the author of two of my favorite essays in the book: the first one being Empower Developers, in which he urges managers and architects to essentially “protect developers from nonessential parts of their job.  Too much paperwork and too many office chores add overhead and reduce their effectiveness.” and making sure developers have the tools, the skills and the trust necessary to get the job done; and the second one being Record Your Rationale where he suggests that architects should write down their rationale behind some of their technical decisions, as it may come in handy in a number of situations, as he writes:

• As a means of communication to developers regarding important architectural principles that should be followed
• To get the team “on the same page,” or even head off a mutiny, when developers question the logic behind the architecture (or even to humbly accept criticism if it turns out a decision doesn’t hold up under scrutiny)
• To show managers and stakeholders exactly why the software is being built the way it is (such as why an expensive piece of hardware or software is necessary)
• When handing off the project to a new architect (how many time have you inherited a piece of software and wondered exactly why the designers did it THAT way?)

Another interesting thing about this book is that O’Reilly agreed that all of the content of the essays should be freely available (Creative Commons) for to anyone through the book’s website.  Excellent idea, O’Reilly!

In essence, this book is all about software architecture, but not only for software architecture, but rather anyone involved in the software development lifecycle (testers, developers, QA, analysts) and even up the corporate ladder (CIO or CTO).  The content being technology-agnostic, there’s no doubt that the audience for this book will be heterogeneous, so whether you’re a .NET, Java or Ruby fan, you will surely find the essays valuable.  And just like the Head First series, this book has sprung another series focused on a “97 Things Every [fill in the blank] Should Know” idea.  [Note from my wife, the environmentalist: “There goes more trees!”].  If you’re a developer aspiring to take on more responsibilities and challenges for a software project, I would highly recommend you get a copy of this book.  Furthermore, I would also recommend reading a good complement for this book: “The Role of an Architect” published by The Architectural Journal (Microsoft).

[UPDATE: 2008-04-15] You can also read the other proposals which didn’t make it to the final cut.