Beyond Software Architecture: Creating and Sustaining Winning Solutions

Martin Fowler Signature Book

by Paul Becker

At last, a book that provides the software engineering community with a clearer understanding of the business value of software architecture. There are currently a significant number of books on creating, documenting, and implementing software architecture, but precious few resources have addressed how to build a software architecture that aligns with a customer's overall business goals. In this new book, Luke Hohmann borrows from his extensive experience managing successful enterprise software projects to provide practical wisdom on creating and sustaining winning software solutions. This book helps technologists grasp the business ramifications of their decisions, and provides business-oriented software professionals (e.g. sales people and marketers) with better knowledge of how robust software can be built and maintained.

Genres: Architecture, Programming, Technology, Software, Computer Science, Technical, Nonfiction

352 pages, Paperback

First published January 1, 2003

Reviews

[William Anderson · Rating 4 out of 5]

It takes a substantial amount of mental stamina to get through this text. Long winded at times, the advice, thoughts and considerations mentioned are well worth the read and were enlightening. I more strongly reccomend picking specific chapters and focusing on those. This is certainly a book more on theory and advice along that vein as opposed to executions., giving insight into both marketing decisions as well as technical ones that can be made.

Think of it as "Marketing considerations for technical products." There are many different positions that could gain extreme value from this book, but as mentioned before, be ready for a long dry read.

[Dani · Rating 5 out of 5]

So this is a read that takes work, but is worth it if you are interested in building and selling sustainable software. Luke Hohmann does a great job of wrapping up the entire process from idea to implementation and what needs to be considered. Are a lot of the ideas are not new. People know they need to scope the problem and know their domain, they know they need to think about how they are going to sell this item since this will affect implementation, they know that they need to build modular code, need to document, think about installation from the very beginning and everyone is clearly aware that no one reads installation manuals, etc. What makes this book special is it looks at all these aspects in it's entirety and provides good examples for what makes sense and the problems that happen when you ignore certain aspects. Also, even though everyone in the industry knows what they are supposed to do, everyone knows that most large scale software projects are still NOT doing these things. These flaws are very evident in a majority of the software products that are offered today. One of the more novel takeaways from this book was the basic definitions of Marketecture and Tarchitecture and how these roles need to work together. To be successful at Marketing a product unless you understand how it is built so that you can offer the product in a way that exploits the best of your product while providing the best benefits to your customers. To be a successful Tarchitecture you need to understand how your product can best be sold so you can build it in a way that aligns to your customers needs. This book is a good high level reference for software evaluation. It would be useful when you first start a project as well as evaluating a current program for strengths and weakness, providing an evaluation checklist for each subject. Once you know where your project stands you will be able to know where you should concentrate your energies.

[Aelena · Rating 2 out of 5]

I had higher expectations from this one. Luckily I got it second hand and didn't cough up much. Only a few interesting insights, the rest common knowledge, nothing ground breaking, unless you are a complete novice.

[Robert Postill · Rating 2 out of 5]

Best described as a wearying trudge through the author's laundry list of things architects don't think about.

[Mikhail Filatov · Rating 2 out of 5]

This book is more about product management than Software Architecture. Strangely enough, Product Management is introduced in the beginning, but after that the author decides to split architecture into "marchitecture" (marketing architecture) and tarchitecture (technical architecture).
Marchitecture is mostly used commonly as a synonym for "vaporware", while in author' terms it is about all external facing aspects of Software architecture: pricing, branding, release management, etc.
Which is mostly the stuff PM should be taking care of.
There are actually some interesting thoughts, especially about pricing which are not outdated.
Any "tarchitecture" stuff is really from 2002, if not from 90s.

[Christoph Kappel · Rating 3 out of 5]

I am not exactly sure about this one. The generell idea to separate architecture in a marketing and a technical is quite nice, especially if you use this metaphor to talk about the different aspects of both ways.So the wording "marchitecture" and "tarchitecture" work pretty well.

The book is generally focused about the complete product cycle, from creating it to brining it to the end customer which I normally never see, due to the nature of being rather a consultant.

I must admit I sometimes had to force myself to go on, some parts were boring for me.

[Allisonperkel · Rating 2 out of 5]

This book is out of date and it shows. The main areas are good ideas to look at but the details ... there is a lot of fluff and it’s quite behind the curve even for 2008. This may be why I didn’t finish the book earlier.

However if you are newish to what to consider when building software this book does give a decent checklist of non software considerations. You’ll need to just verify the advice given is still good.

[Mike Fowler · Rating 1 out of 5]

I have tried to read this book on no fewer that three occasions, I simply find it dull and uninteresting. Perhaps coming to this after years of lean product management the lessons aren't as relevant as they might once have been.

[Moutasem Awa · Rating 4 out of 5]

This book offers a great unique mix between software architecture and product marketing, in a simple language for techy people.

[A37 · Rating 2 out of 5]

This was a mistake. I had my own ideas about how awesome this book would be. I was GRAVELY mistaken.

[Abdulla Mamun · Rating 5 out of 5]

So much interesting about this book

[Daniel Gomez Rico · Rating 3 out of 5]

It's a cool lecture that may help to clear what a software architecture, but I was hoping to find more practical information around it

[Avraam Mavridis · Rating 3 out of 5]

I guess it was great content when it was first released, nowadays feels outdated

[Kyle · Rating 3 out of 5]

Admittedly entropy reduction isn't a bad idea

[Robert · Rating 4 out of 5]

Pretty good book...takes some time to read, think, re-read to really get the gist of what Luke Hohmann writes. It's easy to dismiss it as lightweight...until you bother thinking and re-reading.

[TK Keanini]

good text on the processes that we call software architecture. the trick is how to make it work in your own social environment

[Vesa]

Can definitely serve as a checklist for a new product, but a pretty tedious read from cover to cover.

[Delhi Irc]

Location: PTI IRC
Accession No: DL027418