Rating:  Summary: A must-read for most professionals Review: Finally a book about software architecture that doesn't stop with 'design in the large'. Luke Hohmann shares his sound experience about all the aspects of architecting a software system that have been left to personal exploration by now: Deployment, Installation, Branding, Marketing, and Configuration to name some of the most important ones. A must-read if your software runs on more than a single machine.
Rating:  Summary: The most useful tool for the current business paradigm Review: Hohmann bridges the gap found between development and marketing as well as intangible aspects of corporate structure that hinder proper growth. Business is moving away from large organizations that function in a vacuum almost independently from one another and where the tie-in is at an executive level. "Beyond Software Architecture" leads the way by showing how "it can be done" by focusing attention on the overall unifying factor - the product.With clear examples, and well thought out logic, "Beyond Software Architecture" provides a clear and concise view into the core of most businesses - the product. Through this, organizations, directives, and resources work more efficiently as a polarized entity. Very few books can actively be used as tools - the wisdom from "Beyond Software Architecture," can be applied every day.
Rating:  Summary: What you need to know to succeed as a software architect Review: I agree with other reviewers that this book delivers on the promise of its title and informs the aspiring software architect of the other critical business communication and thinking skills necessary for an architect to lead successfully, and the relationship between product management, the architect, and marketing. I don't know of any other book onthe market that conveys this important information to this audience.
Rating:  Summary: Covers the hard part of building technology products Review: It's really surprising to me that colleges and universities that teach software engineering don't teach engineers anything about business models and licenses and how they interact. Technology matters, but if you care about getting your product into customers' hands, you need to pay attention to much more than technology. Hohmann's book does a great job of explaining how to build a solid business to complement a solid product. There would be a lot more successful companies if more people understood these principles.
Rating:  Summary: Fills critical gap in technical library Review: Looking through my technical library, it's apparent that many books are obsolete, casualties of technical innovation and change. There are a few, however, that remain and continue to be relevant. Adding Luke Hohmann's new book, Beyond Software Architecture: Creating and Sustaining Winning Solutions expands that section and fills an important gap. It is the first book that I recall presenting a holistic approach to software creation. Going beyond the technical aspects by weaving together and linking critical business and marketing development in such a way to elevate and show how both Technical and Marketing processes must coalesce to create a winning solution. The topic's importance extends beyond programmers, designers and other technical staff, just as does its content. For marketing professionals, it shows how their decisions and strategies can impact technical decisions. For consumers, it can give them insight on the best ways to work with software manufacturers. For the software entrepreneur, it offers a plan for creating a successful venture. The content, at just the right amount of detail, is presented in easy to understand language and in such a way that the information is easy to retain and apply. The topics are timeless. The book will be relevant for a long time.
Rating:  Summary: Good high-level coverage of issues in shipping software Review: Real software takes a lot of work to build and ship. This book covers the parts of your team's work that doesn't fall under either the umbrella of your development processes or your gritty technical details. The myriad of issues around involving marketing, understanding releases, determining security, logging, and configuration requirements are introduced nicely. Missing were some coverage of accessibility and a lot of the people issues that creep up when working on these issues. It would've also been nice to see encouragements to get more real-people validation for your systems through alpha and beta programs. They're a great way to make sure that your configuration, logging, versioning, and support infrastructure is able to handle what you think you will need to do. Overall, though, it's definitely worth giving this a read, particularly if you're in a role that requires you to have a broader set of responsibilities for your product (architectural, management, release, etc.) to make sure you're thinking of the right things. This is stuff that you just have to get right.
Rating:  Summary: Marketing and engineering deliver a winning solution Review: The book explains in a structured way how marketing/product management can work with the software architect to produce a winning solutions. Both marketing and engineering professionals must read this book and end the us versus them chasm for buisiness success. The book goes beyound empty advise and gives concrete instructions on how to achieve the above goals.
Rating:  Summary: Depicts the Development Process in its fullness Review: There must be hundreds of books on the software developmental process, but I have yet to see a book that covers the business, technical marketing, sales cycle, deployment cycle, release cycle, licensing, installation, upgrade cycle, and everything in the middle all in one compact book. This book TRULY covers the life of a software application and everyone involved in it. For us techies, this book starts with what we are familiar with: "Why software architecture matters?" The author starts with a general overview of the topic, but it goes much further into the non-technical details software architecture, such as the Social Structure aspect: "A good architecture works for the team that created it. It leverages strengths and can, at times, minimize their weaknesses. ... Once created, the architecture in turn exhibits a strong influence on the team. No matter what language you've chosen, you have to mold the development team around it because it affects such as things as your hiring and training policies." New comers to the architect world don't really think about such aspects, or at least it's not really high on priority on many people's lists. The author puts such things right next to profitability, stability of the architecture, and defining the technical boundaries. Granted that Social Structure aspect of the architecture is as important as the others, you can't really find many books out there that treat it as such. Personal experience teaches us that, but there are cases, many cases, that one doesn't have the luxury of "trial and error". The author takes great pride in his experience and has written this book like a personal assistance to a newbie to the job, and to the expert architect with topics such as branding issues, licensing affects on the overall architecture and more... Tarchitecture and Markitecture are two words/concepts that are used frequently throughout this book. The author starts with the inception of software applications and explains the important rule that Market Architecture (Markitecture) and Product Management have in the overall picture of a software lifecycle. Why Business plan is important and how it should be written, how to release version 1.0 and subsequent versions, how customer input and interaction with the markitects play the most important rule in the subsequent releases of your software, and other such important questions are covered in chapters 2 and 3. The chapter Software License and Licensing models is probably one of the most valuable chapter (chapter 4) in the entire book. The author describes the concept of licensing and how it fits into the overall architecture and how it affects the architecture very elegantly. Various licensing models and their pros and cons are described: ·Time based ·Transaction based ·OEM bases ·Metering style ·Hardware based ·Services based ·Revenue Obtained/Costs saved. The author explains why it is important to select the right licensing model, and how and why it could have a negative effect on your architecture if the wrong one is chosen. Various options for choosing a model are then explained such as the Honor System, the homegrown license managers, and the third party tools available. Another important aspect of software architecture - the-after-development-has-been-done-now-what aspect, is covered throughout the rest of the book. Deployment, installation, configuration and upgrades are the key topics. Other topics such as extensions to the current architecture, logging and branding are also covered in detail. The chapter on installation is another well-covered chapter that talks about a topic not covered at all or well in other books out there. Various deployment architectures are covered; Customer site installation, ASP, Managed Service Provider, and Web services models make up the topics for this chapter. This chapter, just like all the other chapters, relates the topic at hand to the overall system architecture, and why and how it can have an effect on the overall architecture of the system. Throughout the book, one theme screams out to the reader: "How every decision an architect makes affects the rest of the software life cycle, and what the architects need to think about and consider before coming up with their design?" The cycle - software life cycle, and how it is affected by the end user/customer, why it's the job of the market architects and business managers to gather the key points from their customers, what are some of the concerns that are common with any architecture (deployment issues, upgrade concerns, installation difficulties, logging and error reporting, security concerns), and tone of the most important aspect of all: Social aspects and how they have an important affect on the tarchitects, markitects and the overall application. I think the author says it best in the preface of the book: "You need to move beyond software architecture and move toward understanding and embracing the business issues that must be resolved in order to create a winning solution"
Rating:  Summary: Beyond Everyday Architecture Issues Review: This book delivers on its promise to discuss the larger business realities of creating software products. If you're a software architect, or dream of being one, this is a must read book. Appropriately, it eschews the details of implementation, and focuses mainly on the business issues an architect must focus on to succeed. It works from the assumption that the reader has done a fair bit of design work, and now wants to create software architectures that will last for multiple releases. Luke expands your horizons to include new areas you probably have not have considered. The book is nicely segmented into logical chapters, making it an excellent reference. Although it covers classic architecture issues such as portability, usability, performance, layering, API design, and security, the truly valuable material is on the business and product management side of the fence, which often get ignored, or left till late in the process. For instance, the installation "out of the box" experience, planning your upgrade strategy, technology licensing, branding, and user community discussions are incredibly valuable, as they bring together the benefit of a lot of experience in the commercial software market. It is this focus on non-traditional architecture issues that makes the book so valuable. My only issue with the book is the tone. I find it a little too academic, and I think that it detracts from the pragmatic advice given. However, the content more than makes up for this minor lack. If you're ready to move to the next level of architecture or pondering a new software product design, check this book out.
Rating:  Summary: Beyond Everyday Architecture Issues Review: This book delivers on its promise to discuss the larger business realities of creating software products. If you're a software architect, or dream of being one, this is a must read book. Appropriately, it eschews the details of implementation, and focuses mainly on the business issues an architect must focus on to succeed. It works from the assumption that the reader has done a fair bit of design work, and now wants to create software architectures that will last for multiple releases. Luke expands your horizons to include new areas you probably have not have considered. The book is nicely segmented into logical chapters, making it an excellent reference. Although it covers classic architecture issues such as portability, usability, performance, layering, API design, and security, the truly valuable material is on the business and product management side of the fence, which often get ignored, or left till late in the process. For instance, the installation "out of the box" experience, planning your upgrade strategy, technology licensing, branding, and user community discussions are incredibly valuable, as they bring together the benefit of a lot of experience in the commercial software market. It is this focus on non-traditional architecture issues that makes the book so valuable. My only issue with the book is the tone. I find it a little too academic, and I think that it detracts from the pragmatic advice given. However, the content more than makes up for this minor lack. If you're ready to move to the next level of architecture or pondering a new software product design, check this book out.
|