Book Review: Beyond Software Architecture: Creating and Sustaining Winning Solutions

    By: PDMA Headquarters on Oct 01, 2013

    Book Review: Beyond Software Architecture: Creating and Sustaining Winning Solutions  

    By: Luke Hohmann. Boston, MA: Addison-Wesley , 2003. 314+xxviii pages
    Review by: Preston G. Smith

    Book coverHow do you get your hands on the controls and keep your eyes on the dashboard of software development? If your product or service depends on software, then Luke Hohmann's book will give you an overview of the major decisions that are, or should be, made during the creation and evolution of a software product. You do not need to know how a car works in order to take a trip, but you do need to know how to read the dashboard and to manipulate the controls.

    Beyond Software Architecture is a roadmap to help product managers, marketers, and technical leaders navigate toward winning solutions together. The chapters are well organized and provide executives, managers, and technical leaders with lists of important cross-functional business considerations connected with software development. For example, the selection of appropriate software licensing, support rights, and platform support each can have significant revenue and cost impacts that may not be understood fully by both the software development team and the marketing team. In addition, the book appeals to a wider audience. While reviewing the book, IDe's vice president of business development excitedly reported to me that it gave him a much better understanding of software development. Hohmann discusses many essential elements of software product development, including business and license models, brand elements, usability, release management, security, configuration, installation, and upgrades. Surprisingly, even though the book is billed as “managing the relationship between business and technology,” he does not discuss portfolio management or top-down management of new product development. He does not cover software engineering project management or processes in any detail but does provide a valuable framework for discussion between the groups involved in software product development. He focuses on the need for cross-functional groups to have a common checklist and understanding of each other's needs. He is a keen observer of the behavior of software development groups and has described very effectively the dimensions of creating and sustaining winning solutions. In addition to software products that run on computers or servers, software is an important part of many new products. Cars, MP3 players, and cell phones all have significant software at the center of their capabilities. Product innovation in many companies must take into account the development of software in order to innovate and compete effectively. Software development remains a discipline with high complexity and poor predictability. More and more product managers must understand how to communicate effectively with software development teams. Conversely, software development teams must understand the language and needs of the product management, marketing, and general management teams that are defining the new products to be created.

    Beyond Software Architecture extends software architecture from the technical domain to a marketing and technical collaboration that is essential to the success of software products. Central to the book is the understanding that a marketing description of the architecture of a product is very different from its technical architecture. Hohmann differentiates them as “marketecture” (marketing architecture) and “tarchitecture” (technical architecture). The way a car is described in a showroom is quite different from the way it is described by engineers who designed it. Options and color choices are a far cry from technical trade-offs and material requirements. For example, during the development of a software product, the brand elements may present little technical challenge and are often the last thing a tarchitect considers, whereas the brand elements may be the foremost in the mind of a marketect. However, the cost of changes to brand elements after software creation can be high. If the tarchitect is aware that the brand elements will change during the life of the product, then he or she can design the technical architecture so that the cost of unforeseen brand element changes can be kept to a minimum. Hohmann provides an Appendix, “A Pattern Language for Strategic Product Management,” full of useful techniques and lists to “help the marketect and tarchitect bridge any gap between their respective disciplines” (p. 285). The intriguing power of the book is that it contains comprehensive lists and from-the-trenches examples that are very effective as cross-functional communications tools. For example, the business and license models for a new product need to be considered from both a commercial and a technical perspective. The product or service could be charged based on access time used, on a perpetual license, on an annual license, on a rental, on a subscription, on pay per use, on pay per user, or on the hardware used by the application. Not only does each of these choices have significant top-line revenue impacts, but also the technical architecture needed to support the revenue model is an important early decision with far-reaching consequences. In addition to spurring the team to consider the license model, Hohmann encourages a discussion on what rights should be granted to users, e.g., the right to support of the product, to upgrade rights, or to copy the product. He then teases out an important capability by discussing how the product will control, count, audit, meter, or authenticate users and their rights.

    Similarly, while discussing the merits and risks of acquiring third-party software for inclusion in a new product, he leads the reader through the typical elements of a contract and then on to assess the critical alignment needed between the business model of the new product and that of the third-party software.

    Platform support decisions can have unexpected costs that are very well illustrated with a “matrix of pain” listing every version of every operating system, database, web server, and web browser the product managers wish to support. Hohmann leads the reader through an understanding of just how quickly costs can escalate, and he suggests techniques for prioritizing the support list down to manageable proportions. He also includes real-world examples, such as the product that “had us supporting ‘Macintosh OS 8.1 and later.’ This committed our marketing team to a future that we didn't want to embrace” (p. 126).

    Software products often need to integrate with other applications, or sometimes it is desirable to create a capability that allows others to extend the application. Good tarchitects often will produce a software integration capability (called an API) as a byproduct of well-established technical architecture models. He challenges readers to understand that while they may not be able to predict exactly how their customers will use the product, they can provide ways to integrate and to extend the product and can provide their customers with pathways to “unforeseen benefits.” He also lists techniques to provide encouragement during a long development process, including a “spike,” which is like a long nail that links several layers of a wooden structure together. A spike helps developers see how the pieces of architecture will work when connected together.

    Configuration, installation, and log files often are considered simple add-ons to a product, while release management and product upgrades are sometimes not well considered until the first version of the product is released. “Given that … one of the primary functions of marketing is finding and keeping customers, it is surprising that upgrades receive so little attention from marketects and tarchitects” (p. 217).

    Beyond Software Architecture is a book with wide appeal to anyone whose products include software. I would suggest using it as a reference book for both new and existing projects, in particular where the product management team and development team are working together for the first time. Its checklists will ensure balanced and informed decisions between marketects and tarchitects. It also will help product managers and software development managers better articulate to senior management the context in which software product development is taking place.

    Ralph Brown 11 IDe Inc.

    Released: October 1, 2013, 11:31 am | Updated: October 30, 2013, 1:56 pm
    Keywords: PDMA Blog


    You must create an account or login with your existing account to provide comments or article ratings.

    About this Blog

    PDMA Blog

    Welcome to the PDMA Blog! This blog features industry insights for product developers and product managers from a variety of contributors.
    My Store Downloads

    No purchased files.

    Copyright © 2018 PDMA - Product Development and Management Association. All Rights Reserved

    PDMA 1000 Westgate Drive, #252 St. Paul, MN 55114 USA   |   Phone: 651-290-6280   |   Fax: 651-290-2266

    Contact PDMA   |   Legal Policies & Agreements