14. Product Architecture
"Perhaps the most important characteristic of a product’s architecture is its modularity." (Karl Ulrich)
Product architecture is the assignment of the functional elements of a product to its building blocks or product components [Ulrich 2020].
A modular architecture exhibits the properties below:
-
Product components implement one or a few functional elements in their entirety
-
The interactions between components are well-defined and are generally fundamental to the primary functions of the product
The most modular architecture is one in which each functional element of the product is implemented by exactly one building block, and in which there are a few well-defined interactions between building blocks.
This document recommends using a Design Structure Matrix (DSM) to measure the degree of modularity of a system. Alan MacCormack and his co-authors show how to calculate the propagation cost of a system, which measures its degree of modularity [MacCormack 2007].
Using DSM, the Harvard Business School authors show that a loosely-coupled organization develops a product with a more modular design than that of a tightly-coupled organization, which is consistent with the Inverse Conway Maneuver; see Section 9.12.
The opposite of a modular architecture is an integral architecture, in which the implementation of functional elements is spread across building blocks resulting in a high degree of coupling. It exhibits one or more of the properties below:
-
Functional elements of the product are implemented using more than product components
-
Implementation of functional elements may be distributed across multiple components
-
A single component implements many functional elements
-
The interactions between components are ill-defined
In an integral architecture, many functional elements may be combined into a few product components to optimize performance. However, modifications may require a significant redesign of the product.
Product architecture decisions have far-reaching implications on product variety, component standardization, product performance, manufacturability, and product development.
14.1. Defining Product Architecture
In a manufacturing context, Karl Ulrich gives a definition of product architecture [Ulrich 1993]. Several years later, Edward Crawley gives a systems architecture definition that is quite similar [Crawley 2016].
"Product architecture is: (1) the arrangement of functional elements; (2) the mapping from functional elements to physical components; and (3) the specification of the interfaces among interacting physical components." (Karl Ulrich)
The quality of customer experience, with its emotional dimension, is not part of Karl Ulrich’s definition. Experience design identifies the functional elements or features that contribute to the quality of customer experience.
In a manufacturing context, product refers to goods and not services. This document will now describe how this definition can be interpreted in a service context.
Product features are the equivalent of functional elements. In a service context, the physical elements are mostly the physical evidences and devices used by clients, employees, and other stakeholders. Therefore, it is necessary to extend the definition to cover non-physical components.
Fabrice Seite and his co-authors describe a service product at three levels [Seite 2010]:
-
The top level is the service result; i.e., the result of a service operation visible to the customer
-
The second level offers a perspective on the processes enabling the service result
-
The third level of the model addresses the required resources for performing the processes that lead to the final result; three types of resources are considered: human, physical, and informational
At the second level, defining the modularity of the enabling process or value stream is a major product architecture decision. The mapping of product features to process steps is specified in alignment diagrams; see Figure 35.
At a higher granularity level, the theory of interdependence and modularity addresses architecture questions.
Product architecture breaks down products into components and specifies the interfaces that link components.
“Products and services have multiple constituent components, and they go through several value-added processes before reaching consumers. The place where any two components fit together is called an interface. Interfaces exist not just within products but also between stages in the value-added chain” [George 2018].
14.2. Interdependence and Modularity
Clayton Christensen defines a product in a way that focuses on how components interact, fit, and work together [Christensen 2013]:
"A product’s architecture determines its constituent components and sub-systems and defines how they must interact – fit and work together – in order to achieve the targeted functionality." (Clayton Christensen and Michael Raynor)
According to Clayton’s theory, architecture is interdependent at an interface if one part cannot be created independently of the other part. He claims that interdependent architectures:
-
Optimize performance in terms of functionality and reliability
-
Are, by definition, proprietary
In contrast, a modular architecture specifies the fit and function of all elements so completely that it does not matter who makes the components or sub-systems, as long as they meet the specifications.
This theory formulates the hypothesis that flexibility comes at the cost of performance because a modular architecture gives engineers less freedom. When the basis for competition is functionality and reliability, a modular architecture is at a disadvantage.
However, Clayton Christensen observes that, over time, an inferior product targeting an underserved market will improve to such a point that its performance will challenge established products. When that happens, any further product improvement by incumbents is likely to overshoot customer expectations. This implies that customers will no longer be willing to pay a premium price, which is disruptive for incumbents.
14.2.1. Modularity Wins
Christensen’s theory was inspired by the history of the PC industry. It provides a credible explanation for the demise of the mini computer industry and the acquisition of Digital Equipment Corporation (DEC™) by Compaq®. Initially, the performance of a PC was much lower than the performance of a mini computer. The PC industry started by catering to the needs of new customers or underserved ones.
At some point, the performance of PCs, especially when connected to a network, was good enough to meet the needs of mini computer clients. When this happened, customers ceased to be willing to pay a premium. Mini computers began to “overshoot” the customer’s required performance level. Other factors, such as the difference in cost of sales, contributed to the fall of the mini computer industry.
The modular PC industry won over the mini computer industry, which was not modular, because it offered sufficient performance for market demand at a lower price.
14.2.2. Integration Wins
The Christensen Institute and Li & Fung™ Limited interpret the success of Zara™, an apparel retailer specializing in fast fashion, as being due to an interdependent architecture strategy. Zara gained competitive advantage by:
-
Integrating customer demand and design
-
Rethinking their operating model to produce smaller batches of apparels nearshore
Zara developed business agility by sensing fashion trends sooner and responding to them faster; see Figure 4. Zara is capable of designing, producing, and shipping new apparel models in a matter of weeks thanks to their integrated product architecture [Ton 2010].
The Zara business model is based on a high level of integration between customer research and new apparel design. It also relies on the operational capability to rapidly produce small batches of clothes at a competitive cost, though its manufacturing plants are located in a high-wage country, and deliver these clothes to stores within a 24/48-hour window after orders have been placed.
14.2.3. Modular Goods
Many goods use a modular architecture to offer innovative benefits to customers; for example:
-
The “Lifebuoy Boat” product works by incorporating separate sections for each member of a family or group in order to increase the safety factor; the sections can come apart from one another to become individual life raft buoys that float independently, which could come in handy when it comes to rescue operations or if one module is compromised; see Linkable Individual Lifeboat
-
The Poiray® watch that modularizes watch straps; an innovative feature that lets the watch owner easily and instantly change the strap of the watch to match any chosen outfit
-
Mosivi.com has created a portfolio of modular products; for example, a modular office shelving product built up on one single element that allows endless configurations and the possibility to easily alter an interior according to the customer’s changing needs
14.2.4. Modular Services
The level of modularity of the financial services industry differs by geography and product family. In modular markets, integrated financial institutions are increasingly challenged by regulated and unregulated competitors (shadow banking).
The shadow banking system performs the financial intermediation function in the same way as the traditional banking system. The main distinguishing characteristics of the shadow banking system are looser supervision and greater fragmentation between operators at each link in the intermediation chain.
The US mortgage market has long been characterized by modular supply. Government Sponsored Enterprises (GSEs), such as Fannie Mae® and Freddie Mac®, enable a robust secondary market with a large portion of mortgage assets held by non-banks. In the first quarter of 2018, Quicken Loans®, a shadow bank, was the largest mortgage lender in the US. Wells Fargo™ and JPMorgan Chase™ were second and third. The fourth largest mortgage lender was loanDepot®, a shadow bank.
In the UK and Germany, the traditional P&C personal life insurance business is disrupted by aggregators. In motor insurance, most UK and German direct players have outperformed their markets in both premium growth and profitability.[1]
Modularization can also benefit integrated firms which productize part of their value chain. Amazon exemplifies this. By unbundling its infrastructure services from its core e-commerce business, Amazon created Amazon Web Services™ (AWS™), which is now the largest player in the public cloud market.
14.3. Modularity-Integrality Trade-Off
This document illustrates the trade-offs that an integrated enterprise must make between integration and modularization. In an Agile at scale organization, team autonomy is important because a large number of Agile teams work in parallel. Autonomy minimizes inter-team dependencies. A modular architecture reduces dependencies but could degrade the overall system’s performance.
Vente-privée.com offers a complete service to sell unsold goods from well-known brands. The value proposition for these brands is to make money from an unsold inventory without hurting the brand. It organizes, exclusively for its members, event-driven sales of products with strong brand names and big discounts (-30% to -70%).
The service to brands includes the shooting of products, the selection of photos, the original trailer, the creation of a catalog, putting it online, issuing invitations to members, sales, online payment, and delivery to the members.
The value proposition for consumers is to be able to buy brand name products at very attractive prices. Although the quality of service for the consumer was not always there, the value proposition was so strong that it did not impact the triple-digit sales growth. However, the expectations of quality of service and personalization have continued to rise under the influence of tech giants.
For example, Amazon has created the expectation of fast delivery. Although Vente-privée’s business model is different to that of Amazon, it becomes difficult to ignore these new expectations. As the business model is based on building inventory upstream of the sale, it becomes necessary to develop predictive algorithms to anticipate demand and thus be able to deliver quickly.
Because of this lack of predictive analytics, the logistics system is not capable of estimating delivery times in real time. The company is also not able to put items acquired from different sales in the same basket. Vente-privée must upgrade its delivery service in a way that is well-integrated with sales. This makes it difficult to outsource a logistics system that has such specific requirements.
Vente-privée has developed a studio capable of creating high-quality videos to present brand products. It only takes a few days to produce a new video clip whereas a communication agency would take a month and cost much more. Vente-privée’s studio creates its own music and has a network of models that it mobilizes to shoot scenes featuring models wearing clothes. The video studio service can be easily modularized. Vente-privée could decide to make it a product that it would sell to other enterprises, emulating Amazon’s creation of AWS.
The Vente-privée example illustrates that the modularity–integrality trade-off is more subtle than Christensen’s theory says. Christensen’s theory does not account for modular systems that at the same time show or require high degrees of integrality. Increasing modularity does not necessarily entail decreasing integrality, and high levels of modularity are not always a sufficient condition to facilitate system reconfiguration, or architectural innovation [Miraglia 2014].
The delivery service can be loosely-coupled with the sales service via a standard set of APIs. However, the specificity of the Vente-privée’s business model directly impacts the logistics system design. This creates indirect coupling. On the other hand, the services the studio provides are similar to those provided by communication agencies. Therefore, they could be productized and sold to an outside market, though these services are part of the Vente-privée’s integrated product.
This document adopts the modularity and integrality definitions proposed by Stefano Miraglia:
-
Modularity is the system’s property of being made up of modules; a module is a system element that presents a high, albeit not complete, independence of other elements; modularity is a relative property in dimension and degree: a system is fully modular along a given dimension when all of its elements behave independently of other elements along the same dimension
-
Integrality is the system’s property of being made up of elements that behave consistently as a whole; it is a relative property in dimension and degree; a system is fully integral along a given dimension when all of its elements consistently concur to determine the system behavior along that dimension
These definitions recognize that modularity and integrality must be analyzed along several dimensions. Modularity and integrality are separate and concurring properties of complex systems.
"Dimensions of modularity reflect the different traits of independence among modules and describe component-level interrelationships. Dimensions of integrality encompass factors that affect the relationship between the component level and the system level, and describe cross-level interrelationships. The interplay between modularity and integrality is crucial to the dynamics and evolution of systems." (Stefano Miraglia)
14.4. Product Platforms
Products built around modular product architectures can be more easily varied without adding tremendous complexity to the manufacturing system. For example, Swatch® produces hundreds of different watch models, but can achieve this variety at a relatively low cost by assembling the variants from different combinations of standard components.
Product platforms support the development of highly differentiated products that share a substantial fraction of their components. Product platforms are also referred to as innovation platforms [Cusumano 2020]; their main benefits are:
-
Products are highly integral and highly modular at the same time
-
The platform supports rapid and effective architectural recombination
The challenge is to resolve the tension between the desire to differentiate products and the desire for these products to share a substantial fraction of their components. Different methods in different industries emerged to create and manage product platforms; for example:
-
In the software industry, software product lines accelerate the creation of new products by specifying a common architecture and developing a set of common components; each product is formed by taking applicable components from the base of common components, tailoring them as necessary through preplanned variation mechanisms such as parameterization or inheritance, adding any new components that may be necessary, and assembling the collection according to the rules of a common, product line-wide architecture [Northrop 2012]
-
In the automotive industry, a vehicle platform provides a structure for major components by determining the body size as well as the size and type of engine and transmission [Cusumano 1998]
Auto makers modularize platforms and related components to enable multi-car project strategies. Vehicle platforms incorporate critical aspects of design and manufacturing know-how.
The classical integration-oriented platform approach in software product lines should evolve from a layered and hierarchical model toward a truly Agile model. Splitting the product teams into a platform team and several product teams suffers from limitations:
-
Integration and testing are done both at the platform and at the product level, which results in growing integration costs as the scope of the product line widens
-
The broad scope of the platform functionality impedes flexibility and time-to-market for new features
-
Software developed by a product team cannot be reused by other product teams before it is included into a new platform release, which can take time
Christian Prehofer and his co-authors recommend evolving toward a compositional product family approach [Prehofer 2007]. Instead of being a fully integrated software solution, the software platform becomes a set of components, architecture guidelines, and documentation as code. Powerful digital platforms can be created by combining the compositional product family approach and the modern software architecture patterns as described in Chapter 21.
Now that software in a car costs more than the engine, and anticipating that this trend will continue with autonomous driving and electric engines [Kersten 2018], vehicle and software platforms could converge.
Product platform decisions are architecturally important decisions that impact product performance and product development cost. It impacts positively or negatively the ability of the enterprise to innovate. It also impacts customer experience.
For example, the Toyota™ New Global Architecture (TNGA) created a powerful competitive advantage in both its product development system and its products [Morgan 2019]. TNGA enabled a substantial boost in driving performance by creating a lower center of gravity while also allowing for more freedom in design. This illustrates the impact of platform architecture decisions on customer experience: better driving performance and increased ability to create styles that customers like.
14.5. Concluding Words
The two major types of product architecture decisions are modularity-integrality trade-off and product platform decisions. Product architecture decisions affect the competitiveness of the enterprise. They combine intentional and continuous architecture. The higher the up-front investment to create the platform, the more front-loading design is required, as is the case in the automotive industry.
In such circumstances, SBCE is the way to go, rather than the iterative MVP approach. Once the platform is created, using an MVP approach is more realistic because of the reuse and flexibility the product platform provides.
When products are mostly made of software, it is easier to develop product platforms incrementally. As a general rule, this document recommends combining set-based innovation with Agile iterations, as described in Chapter 5.