Amazon calculates a product’s star ratings based on a machine learned model instead of a raw data average. The model takes into account factors including the age of a rating, whether the ratings are from verified purchasers, and factors that establish reviewer trustworthiness.
I'm about a third of the way in and I will come back and update the review when finished. I can tell its a good book when I use the highlighter a lot in my Kindle. Good material on the value of architectural thinking to support strategy. 4 stars right now but if it continues strong, it could go to 5.
I teach technology management courses and this book has enough ideas to power an entire semester. What I love is that the patterns go from the top level (business model) to the bottom (non-functional requirements). They are all linked together in a clear pathway. Then, this book does something I've never seen before - it tells the architect how to communicate the information to the executives and to the technical team. Eminently practical advice. Wow.
The beginning of this book has some wonderful insights and perspectives on software architecture and the role in business and there really are some great patterns outlined that I’ll probably refer back to time to time, but it was quite a slog reading this cover-to-cover. I ended up skimming after I got to the 10th pattern or so. It is also aimed more at executive-level architects at more traditional businesses, so was a bit dry and stodgy in its approach. With that said, I’d recommend this to anyone who is involved in software architecture or any kind of technical business strategy, as I think it can really help level up communicating and connecting technology to the larger business.
The book fills an important niche that's missed by most business or IT books: how to apply structured thinking to linking the business environment to an IT architecture. The book is less about "patterns" in the strict sense (which the author readily admits), but more like a tool box for folks engaging in defining a technology strategy. Many of the tools harvest from existing management consulting techniques with ample use of 2-by-2 matrices (which never fail when speaking to management): RACI, SWOT, Bubble charts, Growth Matrix, etc. The best way to position the book is given in the front preface: Eben's alternate title is "How to become the CTO" and he considers the book an intellectual memoir of his experience as a CTO. The author clearly draws from extensive experience in this area, which is why i wish that he had included more anecdotes or practical examples in the book to bring the techniques to life. On the upside, Eben stay's (largely) clear of traditional frameworks such as TOGAF, Zachman, and co. Overall a quick initial read that you may come back to several times.
This book does contain a bunch of good patterns and guidance of what to include in a Technology Strategy and a great starting point for what to include in an Architecture Definition. As a shopping list of things to consider putting in a strategy it is good, but reading through each of them was a bit dry.