Alexis Smirnov

Beyond Software Architecture by Luke Hohmann.

I bought this book based on several factors. First of all, I think that learning more about interrelationships between marketing and software engineering should be important for anyone interested in creating successful software products. Secondly, I’ve found that the first book in AW Martin Fowler Signature Series (Patterns of Enterprise Application Architecture) a must-have reference for every serious software architect.

When I first opened this book I was very impressed by the number of high-profile people endorsing it and giving it praise. Exited, I’ve said to myself and others that I have great expectations for this book – I will learn a great deal from unique experience of the author. After all, not every author can speak from the position of software architect, product manager, marketing professional, software developer, development manager, consultant and teacher.

When I started reading, I began to notice that statements made by the author were correct, but often too simplistic, trivial or incomplete. Not to worry – I though to myself. The author must be preparing the reader for in-depth insight on “how to build winning solutions”. So I’ve continued reading.

By the third of the book I’ve stopped taking this thing seriously. I’ve realized that the author has chosen to touch on every single topic relevant to a software development organization. The trouble is, the author fails to tell anything that would not be considered trivial by any experienced software professional. Opening the book at random you’d stumble on sentences such as “The business plan distinguishes itself from all other development documents at it is the foundation for all the work associated with the product.” Correct, but fairly content-free.

And then, there are numerous text boxes that break-up the prose by telling a story from author’s experience. Most of those stories tell about how the author single-handedly saved the day by being super clever, super insightful and generally super smart. Great stuff for someone who considers hiring the author, but most of those examples bring little in terms of in-depth analysis of the issue.

The bottom line is, if you’ve spend a few years developing commercial software – don’t bother reading this book, you probably already know the things this book talks about. And if not, you’ll be much better off picking a more focused book that covers a particular topic of interest. Would I recommend this book to a student? No. In fact, the book is even less useful for a student because it covers too broad of an area without giving the reader in-depth knowledge in anything. Perhaps the only case where the book would be useful is for someone who wants a high-level overview of the issues that architects, senior developers and product managers worry about.

One good thing that this book introduces (in appendix) is the idea of using patters for things beyond software design. The idea of capturing “design patterns” for business and marketing issues isn’t new, but definitely not completely explored or understood.

The book attempts to close the gap between business and technology. Not many people have had the right experience to do so and be able to write well about it. The best (even a bit dated) book I’ve read on the subject remains “High-Tech Ventures” by Gordon Bell.