Practice: Product Architecture

Practice Product Architecture

Objective

The objective of product architecture is to depict the internal plumbing of the projecta design that facilitates exploration and guides ongoing product development. Product architecture guides both the technical work and the organization of people who carry out the technical work.

Discussion

Product architecture may seem like an odd practice to put into a project management toolbox, but a product's technical architecture, together with the overall size of the project, has significant implications for project and product success. For example, the organization of components and modules may impact decisions about outsourcing or about distributed development and how to manage distributed groups. Similarly, if a team is building a complex product with both hardware and software components , the interface specifications may have a major impact on the change management process. In agile development, architecture is a guide, not a straightjacket. It is intended to communicate the larger context to the development team, not lock in a design.

While in general agile practices encourage change and adaptation, certain changes have greater impact and require careful coordination. For example, in automobile design, the transmission and drivetrain components have a certain well-defined interface. Changes within the component, which don't change the interface, can be handled less formally than those that affect the interface. It is not a matter of controlwho gets to make the decisionsas much as it is a matter of coordinationmaking sure the team understands the total impact of a change and which groups are affected. A poor technical architecture makes this change coordination job difficult. Astute project teams will recognize when excessive time spent on cross-component coordination or integration points to poor architectural decisions that need to be remedied.

In general, technical architectures utilize some combination of platform, component, interface, and module elements. A new sport utility vehicle may begin with a "truck" or a "car" platform. A software product may utilize a Windows or a Mac platform, or both. The SUV has components such as a body, drivetrain, and engine. A software component may have application programming interfaces (APIs) that specify how other components are to interact with it. A multifunction PC device may have printer, scanner, and faxing components, each of which has subordinate modules (which in this case include integrated circuit boards ).

A feature breakdown structure (FBS) can be used to depict a product architecture (see Figures 5.6A and 5.6B). There are other architectural representations that are useful for technical teams, but the FBS serves to communicate between customer and development teams and acts as a bridge between the Envision and Speculate phases. The FBS identifies a backlog of features from which an iteration plan will be developed.

Figure 5.6A. Software Feature Breakdown Structure for a CRM Application

Figure 5.6B. Hardware Feature Breakdown Structure for a Mass Spectrometer (Courtesy of MDS Sciex)

One of the reasons project managers need technical domain experience as well as project management skills is that they need to understand the interactions among technical architecture, project organization, and planning. Poor technical structures can cause severe organizational problems, just as poor organizational structures can sometimes result in bad technical decisions.

Finally, in many projects, the project team structure and the technical architecture are decided upon in the beginning and are thereafter fixed. Colleague Mike Cohn comments, "This is a real problem with staffing large projects too quickly. If you have 20 people on a project that needs 5 to start with, you have a tendency to want to find work for the other 15 so as not to be inefficient. This means that the system gets partitioned along the skill sets of the 20 developers rather than along boundaries appropriate for that project."

A better model would be for the human organization and the technical architecture to co- evolve over the life of the project. (Technical architecture evolution is a difficult concept for engineers whose experience has been to design and fix the architecture early in the development process.) It may appear beneficial, with a large project, for the project subteams to be aligned with the major product components. In automobile design we might have body, frame, drivetrain, engine, and electronics subteams. While this organization may be useful later in the project, a core team of all disciplines may work better in the beginning. The core team develops the overall architecture and, very importantly, the interfaces. Once the interfaces have been specified through interaction and debate, component-based subteams may work better. The core team may evolve into a part-time architecture and integration group that coordinates changes among subteams. Another advantage of this approach comes from the cross-functional relationships that are built in the early project stages, which facilitate coordination as people are dispersed from their initial assignments into various subteams.

Guiding Principles

A second piece of the architectural guide is, appropriately enough, a set of guiding principles (GPs) to assist development teams in "molding" the product to meet customer preferences. Just as agile values and principles guide people in their efforts, guiding "product" principles assist in steering the product's evolution in the desired direction. [3] GPs are usually not measurable requirements or constraints but conceptual guides. For example, defining the ubiquitous phrase " user friendly" in measurable terms may be difficult. However, a GP stating that "The target user for this medical device, an entry-level medical technician, should be able to use the basic features of the product with minimal training" would help steer a development team in its user interface design. A guiding principle for this book was to focus on delivery rather than compliance practices.

[3] Colleague Kevin Tate introduced me to this idea of guiding principles.

GPs can be used early in a project before specific requirements or design decisions have been made. For example, an early GP might be, "Maximize the employment of reusable components and services to speed development." That GP could then be used as a consideration in design, where it might, for example, encourage the selection of a technology platform. An early GP may evolve into a specific requirement later. In the case of the medical device mentioned above, after several iterations of experimenting, the minimal training GP might be supplemented with specific user interface design requirements and measurable training objectives.

Although some GPs may be developed during project envisioning, they often emerge over early development iterations. Each principle should be described in a sentence or two, and the total number for a project, at any one time, should not exceed around ten.