Having had your book recommended to me over in this thread about a month ago I was quite pleased to see this little promo pop up this week.
As a developer I tend to approach architecture concerns as an ongoing drive to create clear and intuitive interfaces through TDD and by constantly working to remove duplication through refactorings. On a day to day basis I find that doing these two things, more often than not, results in a pretty well structured design. Applying these techniques on a larger "integration" level context also tends to take care of most architecture type concerns too.
Hi Tim, great question, especially as those are all fab books! While all of those books are focussed on code, my book is really about technical leadership and putting some high-level building blocks in place before you start coding. In other words, it's about putting a vision in place that a team can follow in a consistent and coherent way. In real terms, my book is about doing "just enough" up front design to help you create that initial vision, which is based upon understanding what your key architectural drivers are and how they influence the resulting architecture. As an example, if you know that security is important, I recommend thinking about this up front because retrofitting it into an existing codebase can be tricky. The book is also about how to communicate the resulting architecture, using a collection of simple sketches rather than a hundred and one different UML diagrams. My approach is based upon decomposing a software system into it's constituent components, which can then provide a framework for doing TDD. In my view, the book complements the books you've listed rather than competing with them. Having said that, if you're already building well-structured systems, I would continue with what you're doing because it seems to be working!
The #sa4d book to me is almost like Robert Fulghum's "Everything I Really Need to Know I Learned in Kindergarten" - it's not deep on the technical side but IMO, really delves into things that I think are important to consider and keep in mind if you're going to be a good architect or developer. Don't get me wrong, there's plenty of great practical advice in it, especially in Part V, but what differentiates this book from the others you've mentioned is that it makes you step back from the trees (technical details) and take a good look at the forest (your approach and attitude toward architecture).