Teaching Chapter 10: Product Architecture
Timing
Since product architecture is one of the topics that bridges concept development with system-level design and subsequent activities, this session should follow the concept development sessions. This would naturally put it mid-way through most courses. This is one of the more advanced topics covered in the text. As such it may be easily omitted if it seems inappropriate for a particular type of class.
Objectives and Strategy
This session presents the fundamental principles guiding the selection and execution of a product architecture. While students will certainly be familiar with the results of architectural decisions, in terms of product modularity for instance, they will likely not have given this topic much thought before. It is therefore useful, in addition to reviewing the chapter material, to discuss several examples of product architecture and its implications. This is also an important opportunity to discuss the relationship between a team’s product development decisions and the firm’s longer-term product strategy and production strategy.
Session Outline
The session discussion can follow this flow:
Introduction to System-Level Design
We like to begin the class by introducing the broader topic of system-level design, which includes issues such as product family options, design for manufacturing, supplier selection, and product architecture. Exhibit 2 from Chapter 2 can be used as a transparency to focus this discussion. An important point to emphasize is that at the transition point from concept development to system-level design the product’s overall concept has been chosen and its performance specifications have been set. Usually one or more prototypes have been fabricated to explore feasibility and satisfaction of key customer needs.
Terminology and Definitions
By way of introduction to the topic of product architecture and to review the chapter reading, the following definitions can be discussed.
Factors Affecting Product Architecture
We like to show several examples of modular and integral architectures at this point. These examples (see the list of suggested props) allow the discussion to focus upon the factors leading toward modular versus integral architectures, which are discussed in the chapter and can be listed on the board. These factors include:
Review of Product Architecture Method
The chapter’s four-step method should be briefly reviewed in class. Exhibits 6 through 10 can be used to illustrate the four steps:
1. Create a schematic of the product.
2. Cluster the elements of the schematic.
3. Create a rough geometric layout.
4. Identify the fundamental and incidental interactions.
Understanding Interactions
The fourth step involves the identification and handling of interactions between the chunks. This step is often ignored— with disastrous consequences later in the project. To illustrate the issues involved with complex interactions, it is useful to present an example, such as that described in the paper by McCord and Eppinger. In this case, the interactions among the 22 elements of a small-block V8 engine were documented in order to cluster the 22 teams into four system teams representing the major chunks of the engine.
Organizational Concerns
The choice of a product architecture dictates much more than the physical hardware boundaries. While simple products can certainly be developed by a small, integrated team, complex products often cannot. When the product complexity demands that the team must split the overall system into sub-systems or chunks that smaller teams can tackle, the management and organization of the development process becomes more difficult. There are several rich issues that can be suggested at this point to broaden the discussion, such as: team size, organizational structure, colocation, project management, leadership, etc.
Props
It is very useful to display several product examples so that the class can discuss the modular and integral aspects or the architecture of each one. Here are some suggestions:
In-Class Exercise
We have not yet developed an in-class exercise suitable for this class session. We are open to suggestions and would welcome hearing from other instructors.
This session could be taught in conjunction with the HP DeskJet Printer case (by Hau Lee, Stanford Department of Industrial Engineering). The case emphasizes the supply chain and inventory issues in design and operations, and so would be most appropriate for an MBA or industrial engineering audience. When taught in conjunction with this case, one can emphasize the role that product architecture played in allowing HP's postponement strategy.
Since product architecture is one of the topics that bridges concept development with system-level design and subsequent activities, this session should follow the concept development sessions. This would naturally put it mid-way through most courses. This is one of the more advanced topics covered in the text. As such it may be easily omitted if it seems inappropriate for a particular type of class.
Objectives and Strategy
This session presents the fundamental principles guiding the selection and execution of a product architecture. While students will certainly be familiar with the results of architectural decisions, in terms of product modularity for instance, they will likely not have given this topic much thought before. It is therefore useful, in addition to reviewing the chapter material, to discuss several examples of product architecture and its implications. This is also an important opportunity to discuss the relationship between a team’s product development decisions and the firm’s longer-term product strategy and production strategy.
Session Outline
The session discussion can follow this flow:
- Introduction to System-Level Design
- Terminology and Definitions
- Factors Affecting Product Architecture
- Review of Product Architecture Method
- Understanding Interactions
- Organizational Concerns
Introduction to System-Level Design
We like to begin the class by introducing the broader topic of system-level design, which includes issues such as product family options, design for manufacturing, supplier selection, and product architecture. Exhibit 2 from Chapter 2 can be used as a transparency to focus this discussion. An important point to emphasize is that at the transition point from concept development to system-level design the product’s overall concept has been chosen and its performance specifications have been set. Usually one or more prototypes have been fabricated to explore feasibility and satisfaction of key customer needs.
Terminology and Definitions
By way of introduction to the topic of product architecture and to review the chapter reading, the following definitions can be discussed.
- Decomposition is the conceptual breaking down of the product into functional and/or physical elements.
- Functional elements are used when the description is left in schematic form.
- Physical elements are used when the description includes actual components.
- Architecture is the arrangement of functional elements into chunks (groups of physical components).
- Modular architecture describes the situation where each chunk implements one/few functional element(s) and there are well defined (fundamental) interactions between the chunks.
- Integral architecture describes the situation where functions are implemented by multiple chunks or where chunks implement multiple functions, and there are ill-defined (incidental) interactions between the chunks.
Factors Affecting Product Architecture
We like to show several examples of modular and integral architectures at this point. These examples (see the list of suggested props) allow the discussion to focus upon the factors leading toward modular versus integral architectures, which are discussed in the chapter and can be listed on the board. These factors include:
- product performance
- product change
- product variety
- component standardization
- manufacturability
- product development management
Review of Product Architecture Method
The chapter’s four-step method should be briefly reviewed in class. Exhibits 6 through 10 can be used to illustrate the four steps:
1. Create a schematic of the product.
2. Cluster the elements of the schematic.
3. Create a rough geometric layout.
4. Identify the fundamental and incidental interactions.
Understanding Interactions
The fourth step involves the identification and handling of interactions between the chunks. This step is often ignored— with disastrous consequences later in the project. To illustrate the issues involved with complex interactions, it is useful to present an example, such as that described in the paper by McCord and Eppinger. In this case, the interactions among the 22 elements of a small-block V8 engine were documented in order to cluster the 22 teams into four system teams representing the major chunks of the engine.
Organizational Concerns
The choice of a product architecture dictates much more than the physical hardware boundaries. While simple products can certainly be developed by a small, integrated team, complex products often cannot. When the product complexity demands that the team must split the overall system into sub-systems or chunks that smaller teams can tackle, the management and organization of the development process becomes more difficult. There are several rich issues that can be suggested at this point to broaden the discussion, such as: team size, organizational structure, colocation, project management, leadership, etc.
Props
It is very useful to display several product examples so that the class can discuss the modular and integral aspects or the architecture of each one. Here are some suggestions:
- Sony Walkman
- Swatch watch
- Gillette Sensor razor
- Rollerblade Bravoblade in-line skate
- Shimano shifters
- Japanese scissors
- Swiss Army knife
- 35mm SLR camera
In-Class Exercise
We have not yet developed an in-class exercise suitable for this class session. We are open to suggestions and would welcome hearing from other instructors.
This session could be taught in conjunction with the HP DeskJet Printer case (by Hau Lee, Stanford Department of Industrial Engineering). The case emphasizes the supply chain and inventory issues in design and operations, and so would be most appropriate for an MBA or industrial engineering audience. When taught in conjunction with this case, one can emphasize the role that product architecture played in allowing HP's postponement strategy.