Software Architecture for Developers - Comparing to other books

[Patroklos Papapetrou]

Hi Simon

How this book is compared to books that discuss J2EE architecture or .NET architecture?
Is it more technical, practical or theoretical?
I consider myself an architect but after reading book's page I have to re-evaluate it

Regards
Patroklos

[Simon Brown]

Hi Patroklos, my book is much less technical than Java EE or .NET books, primarily because it doesn't explicitly talk about architecting specific types of software systems. In a sense the book is more theoretical, in that it discusses the software design process in an abstract sense. Having said that, it's also a very practical book because it provides some real-world guidance on how to implement a minimal set of lightweight software architecture practices on any software project. As you'll see from the table of contents, this includes things like doing "just enough" up front design, communicating software architecture using a collection of simple sketches and mitigating high priority risks. It's basically a book about technical leadership with some practical advice to solidify everything.

[Junilu Lacar]

Simon Brown wrote:In a sense the book is more theoretical, in that it discusses the software design process in an abstract sense. Having said that, it's also a very practical book because it provides some real-world guidance on how to implement a minimal set of lightweight software architecture practices on any software project.

Simon,

Coming from anyone else, saying that the book is "theoretical" would be a disservice -- I would go with "philosophical" instead. You discuss a number of things that architects should do based on your own values and beliefs as a software developer: "Architects should code," "Architecture should be 'just enough'," "Architecture is a role, not a rank" to cite just a few. IMO, these are key foundational values and principles that guide all the other aspects of an architect's work.

One piece of advice I've started giving out to developers whom I mentor is that longevity in this career -- and perhaps in any other career -- is best gained through principle-based practice and they should strive to understand key principles and values of software development instead of focusing solely on specific technologies. Yes, you need to know the ins and outs of wiring up beans with the Spring framework but if you don't understand the concepts like interface segregation, separation of concerns, loose coupling, and "The Hollywood Principle" then you're really just going through the motions. I liken it to an Aikido student who only wants to learn the art because he saw a Steven Seagal movie and wants to learn how to fight like that, not realizing that students of Aikido can only realize its true meaning and full potential when they eliminate ego and the desire to harm other people. This is why I said #sa4d is the book I wish I could have written because it resonates so much with me at this level.

On the practical side of it, I have already done a wholesale copy of Parts V and VIII onto our corporate-wide wiki to provide supporting documentation for my current project. I plan to use your Software Guidebook as a template for all my projects going forward.

[Simon Brown]

Junilu Lacar wrote:Coming from anyone else, saying that the book is "theoretical" would be a disservice -- I would go with "philosophical" instead. You discuss a number of things that architects should do based on your own values and beliefs as a software developer: "Architects should code," "Architecture should be 'just enough'," "Architecture is a role, not a rank" to cite just a few. IMO, these are key foundational values and principles that guide all the other aspects of an architect's work.

Thanks, I'll stop using the word "theoretical" then. "Philosophical" and "priniciple-based" works for me.