Rating: 
Summary: Another great book from Luke Hohmann
Review: 'Beyond Software Architecture' is an important book. Luke Hohmann's experience and wisdom is a welcome contribution. Of course, BSA isn't the end-all, be-all, nor does it claim to be. Like a good design patterns book, BSA catalogs and discusses problems you will likely encounter when marketing, engineering, operations, and intellectual property issues intersect. For instance, BSA illustrates the woes caused when a product's business model, license agreement, and use of third party tools are out of sync.As a manager and a developer, I've encountered nearly every issue addressed in this book. Work long enough, and it's inevitable that will too. Therefore, I whole-heartedly recommend BSA. The foresight gained will save you a lot of grief. Lastly, the chapters on architecture and development processes can serve as useful primers for the MBA types (product managers, producers) new to software development.
Rating:
Summary: Another great book from Luke Hohmann
Review: 'Beyond Software Architecture' is an important book. Luke Hohmann's experience and wisdom is a welcome contribution. Of course, BSA isn't the end-all, be-all, nor does it claim to be. Like a good design patterns book, BSA catalogs and discusses problems you will likely encounter when marketing, engineering, operations, and intellectual property issues intersect. For instance, BSA illustrates the woes caused when a product's business model, license agreement, and use of third party tools are out of sync. As a manager and a developer, I've encountered nearly every issue addressed in this book. Work long enough, and it's inevitable that will too. Therefore, I whole-heartedly recommend BSA. The foresight gained will save you a lot of grief. Lastly, the chapters on architecture and development processes can serve as useful primers for the MBA types (product managers, producers) new to software development.
Rating:
Summary: Required Reading for Software Industry Execs
Review: As a business person in the process of starting a software company, I found this book very useful. I use the word useful because it seamlessly weaves theory with practical advice. Although some of the concepts in the book are not novel, the way in which they are spelled out is. I find myself constantly revisiting chapters in the book and using them as a point of reference. It acts as a clear and constant reminder of best practices and the importance of solid, cost effective software development. It also provided me with the tools necessary to work more effectively with technical people and understand where they are coming from. It is required (I ask nicely)reading for my developers. I would recommend this to both technical and businesspeople.
Rating:
Summary: Closing the Loop from Programmer to Customer
Review: As a self-proclaimed "agilist," I have been in the habit of thinking more and more about ways that we can ensure that the software systems we build can richly and extensibly solve the business problems our customers need them to solve. And Agile processes like XP are certainly a big step in that direction. That's part of what attracted many of us to agility in the first place. In this excellent and timely book, Hohmann takes that desire for customer responsiveness a quantum step further, asking that every aspect of a software product (internal or external), from business model to architecture, be aligned with business purpose and business reality. To put it another way, he widens the software "project team" to include everybody and anybody who must dream up, define, design, market, sell, build, test, maintain, extend, support, and ultimately retire a system. It helps to systematize the hard and institutionally complex work of taking all of that input into account throughout the lifecycle. So the book talks about taking into account the customer-related input from all of the above roles. But it also asks us to keep the system responsive to all of the knowledge workers in those roles, and their continuing human needs. As hard as it is to do, it is not enough that a system be easy to extend for its programmers. It's not even enough that it provides the optimal feature set, on-time within budget. There is more hard work for it to do. Some systems are a hell of a lot easier to support than others, or easier to market and sell than others. And on and on. Hohmann shows us how the systems we build will inevitably end up responding to a wide range of needs and roles one way or another, and asks us to anticipate them all, embrace them all, and respond to them up-front, purposefully and systematically. I really, really like that. I can put these insights to use immediately. I think of the Agile practice revolution as an essentially humanizing revolution in software development, but at a fairly low institutional level. Agile practices largely help us only with the building of the system. And to the extent that Agile methods humanize that building process, they are great. But I think Hohmann's book gives us the start of a higher-tier, larger view of a humanizing movement, not just in building software systems, but in the entire lifecycle, the entire arc from conception to death. A humanized view of the lifecycle is a fabulous thing, to my mind. I think it really could change the software world permanently. We could all end up (gasp) loving our jobs. This is an important book, full of Aha! insights. If you have responsibility in any of the above roles I mention, I think you need to read it.
Rating:
Summary: Closing the Loop from Programmer to Customer
Review: As a self-proclaimed "agilist," I have been in the habit of thinking more and more about ways that we can ensure that the software systems we build can richly and extensibly solve the business problems our customers need them to solve. And Agile processes like XP are certainly a big step in that direction. That's part of what attracted many of us to agility in the first place. In this excellent and timely book, Hohmann takes that desire for customer responsiveness a quantum step further, asking that every aspect of a software product (internal or external), from business model to architecture, be aligned with business purpose and business reality. To put it another way, he widens the software "project team" to include everybody and anybody who must dream up, define, design, market, sell, build, test, maintain, extend, support, and ultimately retire a system. It helps to systematize the hard and institutionally complex work of taking all of that input into account throughout the lifecycle. So the book talks about taking into account the customer-related input from all of the above roles. But it also asks us to keep the system responsive to all of the knowledge workers in those roles, and their continuing human needs. As hard as it is to do, it is not enough that a system be easy to extend for its programmers. It's not even enough that it provides the optimal feature set, on-time within budget. There is more hard work for it to do. Some systems are a hell of a lot easier to support than others, or easier to market and sell than others. And on and on. Hohmann shows us how the systems we build will inevitably end up responding to a wide range of needs and roles one way or another, and asks us to anticipate them all, embrace them all, and respond to them up-front, purposefully and systematically. I really, really like that. I can put these insights to use immediately. I think of the Agile practice revolution as an essentially humanizing revolution in software development, but at a fairly low institutional level. Agile practices largely help us only with the building of the system. And to the extent that Agile methods humanize that building process, they are great. But I think Hohmann's book gives us the start of a higher-tier, larger view of a humanizing movement, not just in building software systems, but in the entire lifecycle, the entire arc from conception to death. A humanized view of the lifecycle is a fabulous thing, to my mind. I think it really could change the software world permanently. We could all end up (gasp) loving our jobs. This is an important book, full of Aha! insights. If you have responsibility in any of the above roles I mention, I think you need to read it.
Rating:
Summary: Add it to your library.
Review: As a Software Product Manager I'm often surprised by a teams inability to think through each phase of the product development cycle. Quite simply, Luke Hohmann gets it. This is a well thought out overview off all the considerations, and interactions between organizational teams, necessary for a product to be successful. Each paragraph ends by re-enforcing the key points and then backing them up with exercises ("Try This") that will help managers evaluate just how well their teams are moving forward. Highly recommended as a refresher course or as an aid for those needing to get back on track.
Rating:
Summary: Don't make the same mistake once...learn from others
Review: As a technologist who has transitioned to product team leadership, this book distils many of the lessons I've learned through study, trial, and error. As someone who still bridges the gap between software development and executive management, I found this book a great refresher and filled with little "oh yeah!" insights. And, as I continue to work with teams to manage and develop new products, I'm sure I'll use it as a reference and a teaching resource, bringing the "big picture" into view and avoiding costly pitfalls. Anyone managing product development or marketing, aspiring to manage, or unhappy with current management should definitely read Hohmann's work. Valuable stuff!
Rating:
Summary: Software Startup 101
Review: Beyond Software Architecture should be required reading for anyone starting a software company - that is unless one prefers the school of hard knocks! Luke does a fabulous job of going beyond the many books written on software and technology and beyond the many books, classes, and seminars addressing how to create a successful startup and get funded. Hohmann's keen insight and practical advice can make an enormous difference for any group of bright and knowledgeable software engineers and/or visionary entrepreneurs with the "killer" application - a difference that can mean success. He clearly defines the space between the technology and the market and draws them together so that technologist and business person alike can gain a necessary understanding for what it takes to bring to market and sustain a successful software product. I wish that this book had been available ten years ago and that I had read it!
Rating:
Summary: Software Startup 101
Review: Beyond Software Architecture should be required reading for anyone starting a software company - that is unless one prefers the school of hard knocks! Luke does a fabulous job of going beyond the many books written on software and technology and beyond the many books, classes, and seminars addressing how to create a successful startup and get funded. Hohmann's keen insight and practical advice can make an enormous difference for any group of bright and knowledgeable software engineers and/or visionary entrepreneurs with the "killer" application - a difference that can mean success. He clearly defines the space between the technology and the market and draws them together so that technologist and business person alike can gain a necessary understanding for what it takes to bring to market and sustain a successful software product. I wish that this book had been available ten years ago and that I had read it!
Rating:
Summary: What transforms great architectures into great products?
Review: By exposing the many practical connections between business and technical architecture, this terrific book illuminates in lucid detail how software products can transcend code to become successful solutions. It should be required reading for architects and product managers alike working on any software-related product. Many technical architects master (or at least aspire to master) technical construction, abstract design patterns and principles, languages, platforms, and methodologies; yet even the true master architects among us often remain weak at understanding the business models that must be crafted alongside the technical artifacts that we produce. As a result, the architect's brilliantly-crafted technology too often fails to become a winning solution. Luke's practical experience with business models and technical models -- and more importantly, for how they intersect -- has led to a vision that is sharp and wise, and he shares this vision in a remarkably friendly, lucid manner. This book is simply a must-read for all those who build software, if that software aims to become a successful and winning solution.
| 
