Reuse captures the idea that the part or module that was not intentionally designed to be used beyond the original design (Box 10.2 Principle of Reuse of Legacy Elements). There is very little uncertainty associated with reuse, in the sense that the part, component, or code already exists; its performance and functionality are known (at least in the context of the legacy system in which it was implemented); and it has passed tests and validation and may have been subject to market testing or product improvements. For reuse, the part, component, or code is a known quantity. The unknown element that arises is how it will integrate in a new context.

For example, NASA has considered reusing components from legacy designs of the Space Shuttle on several future launch vehicles, such as using the Space Shuttle’s solid rocket motors on the (since-canceled) Ares-1 crew launch vehicle, and in the Space Shuttle main engines on the Space Launch System. Doing so involved not only repurposing and requalifying legacy spares (identical reuse) but also potentially redesigning pumps, valves, and other parts that are 40 years old.

The benefits of reuse are that the development cost has already been expensed (although integration or modification may be necessary), the tooling has been paid for, and the performance characteristics are well known. The downside of reuse is that the legacy elements impose constraints. For example, the reuse of a network bus imposes a limit on data rates achievable.

Reuse is different from platforming. Reuse represents sharing that was not intended in the original design, whereas platforming represents intended sharing.

Product lines or product families are linked groups of products, such as the GE Healthcare LOGIQ family of ultrasound machines shown in Figure 10.6. Product families do not necessarily share underlying components or architectures. They can be arranged under similar names and stratified for feature content for marketing purposes alone, separate from objectives (such as reducing development time) that are explicitly linked to sharing components or architecture. Conceiving product families explicitly requires the architect to consider how much variety is demanded. (Will one ultrasound machine serve the whole market, or will ultrasound machines with differentiated offerings be required?) Conceiving a product family also hints at product evolution. (Will the family be launched in parallel, or will it be phased into the market?)

Analogous to the case of reuse, much of product family evolution (Box 10.3 Principle of Product Evolution) is unforeseeable. Stable markets such as rail are more likely to see component-level innovation within a stable architecture, whereas mobile phones move at a significantly higher clockspeed, limiting the architect’s ability to forecast the dimensions of the market that will demand variety and innovation. The architect may invest in real options during the design, such as choosing to create additional interfaces to enable future modularity. The best practice we have observed is to explicitly set interfaces between slow- and fast-clockspeed components, on the presumption that unplanned evolution will occur on the high-clockspeed side of the interface.

Platforming is the intentional sharing of parts and process across or within products. Platforms require that the architect invest once in a common part or software module, predicting which models that part or module will be used in. Unlike reuse, platforming allows the architect to choose which constraints to impose, but it must deal with the uncertainty of future applications, whereas in reuse, the parts or module performance is known, and the current use case is known as well.

Platforming has become an important strategy for delivering product variety. Platforming makes it possible for firms to deliver similar products to multiple markets and multiple vertical segments, enables them to dynamically enter niche markets more quickly as a result of identified needs, and can be coupled with strategies of mass customization.

One of the chief advantages of platforming is cost sharing across products. Examples include Volkswagen’s A platform (including the VW Jetta, Audi TT, and Seat Toledo), the Joint Strike Fighter program (with variants for the Air Force, Marines, and Navy), and Black & Decker’s electric hand tools. Development costs can be shared, learning curves lower touch labor hours in manufacturing, and demand aggregation can reduce safety stock levels in inventory. Platforming strategies enable firms to deliver more product variety to the marketplace on a smaller cost base. Figure 10.7 summarizes several of the benefits associated with platforming.

However, platforms can substantially increase the complexity of product development. Whereas previously decentralized products could optimize to a market segment, platforming requires judging the variety of offerings demanded, determining where over-performance can be carried for the sake of shared components, and defining interfaces that can meet the needs of multiple components. Component-level commonality can be non-architectural (standardizing on M8 and M10 bolts is unlikely to impact the architecture). However, many commonality strategies at either the subsystem level (sharing engines across trucks) or the system level (sharing a rolling chassis, drivetrain, and geometry across trucks) are enabled by the architecture. The architecture can define which modules can be paired with which other modules (which axles can be paired with which transmissions).

Platforming for the purpose of saving development cost often involves making linchpin parts or modules common—parts or modules that are at the heart of the architecture. For example, Black & Decker designed a common electric motor to be shared across a variety of portable hand tools. Changes to these parts or modules often cascade down through many other parts as a result of system-level tuning.

The results of the MIT Commonality Study ^[11] suggest that many firms invest substantially in platforms (development spending on platforms can be up to 50% higher than the cost of stand-alone development), as shown in Figure 10.8. But many firms realize lower levels of sharing than originally envisioned, a phenomena called divergence. Some divergence is defined early in product families, when large offsets are planned between variant development schedules (often months, and sometimes years, between variants), and where the goals set for the variants fail to articulate the opportunities for carrying margin and over-performance for the sake of common components.

In summary, product families, product evolution, and platforming are a substantial downstream influence for the architect. The architecture chosen shapes the product’s longevity and its modularity for new functionality. As seen in the case study that concludes this chapter, the choice of architecture locks in substantial downstream performance and cost consequences.