regular paper the implications of product architecture on ...ay11/architecture.pdf · the...

The Implications ofProduct Architecture onthe FirmAli A. Yassine1,* and Luke A. Wissmann2,†

1Product Development Research Laboratory, Industrial and Enterprise Systems Engineering, University of Illinois atUrbana-Champaign, Urbana, IL 61801

2Hamilton Sundstrand Engine Systems, United Technologies Corporation, One Hamilton Road, Windsor Locks, CT 06096

THE IMPLICATIONS OF PRODUCT ARCHITECTURE ON THE FIRM

Received 31 August 2005; Revised 27 November 2006; Accepted 29 January 2007, after one or more revisionsPublished online in Wiley InterScience (www.interscience.wiley.com).DOI 10.1002/sys.20067

ABSTRACT

Product architecture defines the functional requirements within a product system, maps theserequirements to physical elements or subsystems, and describes the interaction betweenthese physical elements. In spite of the diverse literature on the topic, it is clear that theimplications on the firm have not been clearly outlined. In an attempt to fill this void, thispaper offers a framework for classifying the vast amount of existing literature relevant toproduct architecture and summarizes the managerial implications. The proposed frameworkclassifies the impact of product architecture on the firm along two dimensions: “facet of thefirm” and “what is managed.” The facet dimension indicates which system element (i.e.,organization, product, or consumer) a piece of research considers and the second dimensioncategorizes how value is created by the facet (managing portfolios, establishing a structure,or executing processes). The key domains surrounding product architecture are researchdomains in and of themselves. Nevertheless, the task of this paper is to articulate the conceptsand research at the intersection of these key domains with product architecture. © 2007 WileyPeriodicals, Inc. Syst Eng 10: 118–137, 2007

Key words: product architecture; product planning; organizational architecture; product de-velopment; product portfolio; brand portfolio

Regular Paper

*Author to whom all correspondence should be addressed (e-mail: [email protected]).†This research was conducted and completed while Mr. Wissmann was agraduate student at the University of Illinois at Urbana-Champaign.

Systems Engineering, Vol. 10, No. 2, 2007© 2007 Wiley Periodicals, Inc.

118

1. INTRODUCTION

Developing product systems for today’s marketplace isa complex endeavor for many reasons. First, productsare often composed of many unique and shared ele-ments (components, subsystems, etc.) that interact witheach other in complex ways. Understanding these inter-actions is not always straightforward, and designing thephysical interfaces can have lasting implications on theability to innovate [Baldwin and Clark, 2000]. Second,product elements or subsystems are often developed byautonomous design teams that may be distributedand/or reside within multiple firms [Arnold andLawson, 2004; Mikkola 2003, Swan and Allred, 2003].Third, customer preferences are always changing anddifficult to ascertain, which makes it difficult to rigor-ously cascade requirements to the design teams[Chandy and Tellis, 1998; Lynn, Monroe, and Paulson,1996]. Fourth, product subsystems and components areoften manufactured by a complex supply chain, whosedynamics must be considered throughout the designphase [Krishnan and Ulrich, 2001; Novak and Eppin-ger, 2001]. Fifth, it is often difficult to educate theconsumers regarding frequent iterative product releasesand improvements stemming from innovation at theelemental level, which could lead to customer defectionwhen the marketing message is misunderstood[Capraro, Broniarczyk, and Srivastava, 2003]. More-over, complex product development is difficult becauseemployees move into, out of, and within a firm; whichinfluences a firm’s ability to effectively manage knowl-edge (developing, reusing, retaining, and sharing) [Ar-gote, 1999; Lesser and Prusak, 2001]. Many of thetactics that companies use to cope with the aforemen-tioned complexities are founded in product design orsystem architecture theory [Suh, 1990; Pahl and Beitz,1996; Maier and Rechtin, 2000; Baldwin and Clark,2000; Meyer and Utterback, 1993; Sage and Arm-strong, 2000; Sanchez, 1995; Sanderson and Uzumeri,1997; Holmqvist and Persson, 2003].

Product architecture defines the functional elementswithin an artifact, maps these functional elements tophysical elements, and defines the interfaces among theinteracting physical elements [Ulrich, 1995; Sharmanand Yassine, 2004]. Although product architecture andsystems engineering are relatively new research areas,product development teams in industry have been ar-chitecting their product systems for quite some time asa way to manage complexity. It is precisely becausesystematically architecting products has historicallyproven to fulfill customer needs in a way that is eco-nomically feasible for the firm that systems engineeringhas become a popular topic of recent engineering andmanagement research.

In spite of the diversity of literature published on thetopic, product architecting’s far-reaching implicationson firm management are still not well defined [Sud-jianto and Otto, 2001; Arnold and Lawson, 2004].Indeed, as Arnold and Lawson [2004, p. 30] pointed out,“While systems engineering provides the technical ba-sis for bridging market need to product or serviceprovision, many organizations have been slow to rec-ognize its inescapable importance to business.” Tomake architecture links to different facets of the busi-ness clear, this paper provides a framework for class-ifying the vast amount of existent literature relevant toproduct architecture and then uses the framework tounderstand how product architecture decisions impactthe firm. The framework was developed not only toclassify the literature, but also to help identify newresearch paths by exposing previously unclear linksbetween research domains. Conversely, hypotheses arelisted explicitly to highlight these links. Moreover,many of the hypotheses could be used as insights andguiding principles to be followed or noted by practicingsystems engineers and architects. Although some ofthese hypotheses are not exactly “new” (i.e., they canbe found in or deduced from previous literature scat-tered across many disciplines), no source was found tobe comprehensive or to capture these hypotheses suc-cinctly. Future research could evaluate several of thehypotheses through proper data collection and analyses.

Literature was collected from multiple disciplinesincluding engineering design, process design, systemsengineering, marketing, and organizational science inorder to explore all important perspectives of productarchitecture.1 Although this paper references literaturethat spans the product architecture domain, it is notnecessarily a complete literature review in the tradi-tional sense because it was felt that addressing everypaper on the subject would have made the expositionunnecessarily long and cluttered.

The paper is laid out as follows. Section 2 providesa conceptual foundation of product architecture thatestablishes a basic vocabulary that is used throughoutthe remainder of the paper. Section 3 introduces aframework for classifying product architecture litera-ture and its underlying logic. Section 4 discusses howproduct architecture affects three kinds of firm assets(knowledge, product, and brand portfolios) and offerssignificant insights (stated as hypotheses) and manage-rial implications. Section 5 describes how complexityis structured and managed by the firm through the useof organizational and requirement architectures. Sec-tion 6 shows how three categories of business processes

1Many of the concepts can be carried over to understand implicationsof service architecture on firm performance.

THE IMPLICATIONS OF PRODUCT ARCHITECTURE ON THE FIRM 119

Systems Engineering DOI 10.1002/sys

(production and distribution, product development anddesign, and marketing processes) are affected by prod-uct architecture. Lastly, Section 7 contains potentialfuture research opportunities and concluding remarks.

2. PRODUCT ARCHITECTUREFUNDAMENTALS

A complex system is made of a large number of inter-acting elements, and it is the central task of systemsengineers to show how these systems can be simplifiedand further understood [Simon, 1962]. Although prod-uct architecture concepts were not new at the time,2

Ulrich [1995] was the first to focus on how productarchitecture concepts could help reduce product devel-opment complexity. He offered a definition for productarchitecture, provided a typology of product architec-tures, and described how product architecture influ-ences product change, product variety, componentstandardization, product performance, and product de-velopment management. He defined product architec-ture as: (1) the arrangement of functional elements orfunctional structure; (2) the mapping of functional ele-ments to physical elements; and (3) the specification ofthe interfaces among interacting physical elements. Ac-cording to this definition, a strictly modular architec-ture has a one-to-one mapping of functional elementsto physical elements, whereas a strictly integral archi-tecture has a complex mapping of functional elementsto physical elements and/or coupled interfaces betweencomponents.

Ulrich’s work echoed similar messages that can betraced back to Suh’s axiomatic design principles [Suh,1990] and Pahl and Beitz’s systematic design principles[Pahl and Beitz, 1984, 1996]. In axiomatic design thefunctional requirements (FRs) are mapped into designparameters (DPs), and the resultant design is said to beuncoupled (e.g., modular) if there is a one-to-one map-ping between the FRs and DPs. Similarly, according toPahl and Beitz systematic design principles, breakingdown the overall design task into separate functionalmodules which can then be considered independently(with the interactions between them being kept to aminimum) makes the development of complex productsmanageable. For this reason, architectural design is anecessary precursor to detailed product design, whichinvolves designing the physical elements [Pahl andBeitz, 1996]. For example, in order to design an aircraftengine the overall engine system must be broken downinto engine sub-systems, then down into sub-assem-blies all the way down to the component level. The next

step is to determine how the sub-systems and compo-nents interact so that both intended and unintendedinteractions can be carefully managed to meet desiredsystem performance goals.

To fully specify the interactions between productelements (components, subassemblies, etc.), productarchitects must specify and define each of the followingtypes of interfaces [Sanchez, 2000]:

• Attachment interfaces—how components attachto each other

• Spatial (volumetric) interfaces—the spatial vol-ume allocated to a component

• Transfer interfaces—what comes in and whatleaves the component

• Control and Communication interfaces—infor-mation exchanges that communicate componentstate and/or changes

• User interfaces—how the component receives“requests” from the user

• Environmental interfaces—how the componentinteracts with the ambient environment or othercomponents in intended or unintended ways.

A module is a grouping, either physical or concep-tual, of architectural elements that often results from theinterface definition process [Newcomb, Bras, andRosen, 1998; Holmqvist and Persson, 2003].3 A mod-ule, therefore, can be a single component, a grouping ofcomponents such as a subassembly or a subsystem, orany combination of these [Whitney, 1993]. Two mod-ules are said to be loosely or tightly coupled based uponthe extent of the interdependencies between their inter-faces [Orton and Weick, 1990]. Standardized interfaceparameters and protocols are termed design rules [Bald-win and Clark, 1997; Sanchez, 2000], and are keyenablers of innovation [Baldwin and Clark, 2000]. To-gether, the interface definitions and design rules makethe modular product design process possible [Maier,1998; Chen and Clothier, 2003]. For example, an air-craft engine has an interface that can receive a fuelpump from one of many suppliers who are required tohave a mating interface, yet could have pump designsthat are markedly different.

The benefits of having well understood interfacedefinitions and design rules are clear; yet, the interfacemapping and standardization process is complicatedand time-consuming. In the conceptual design phase,not only is it difficult to ascertain all of the interfaces apriori, but it is also difficult to be sure all of the physicalelements themselves have been adequately enumerated.

2See Rechtin [1991] or Maier and Rechtin [2000] for a historicalaccount of architectural concepts.

3The interface definition process has been termed the informationstructure [Sanchez and Mahoney, 1996].

120 YASSINE AND WISSMANN


It is because of these difficulties that the “rule design-ers” must have an advanced knowledge-set of the sys-tem they are attempting to decompose to be sure thatthe system elements will function correctly when theyare integrated. Specifically, not only does effective de-composition facilitate verification and validation at theelemental level, but also when the elements are inte-grated. It is almost a sure thing that design rules willneed to evolve throughout the detail design process asnew information about actual module performance isgathered and compared to expected module perform-ance [Baldwin and Clark, 1997].

A family architecture implies that several differentproducts are offered with “a common arrangement ofelements, common mapping between function andstructure, and common interactions among compo-nents” [Martin and Ishii, 2002, p. 214]. It is throughsharing components that firms are able to economicallyoffer a diverse set of products to meet varying types ofcustomer needs [Fisher, Ramdas, and Ulrich, 1999;Meyer and Lehnerd, 1997]. The set of common ele-ments, interfaces, and/or processes is referred to as theproduct platform, and the unique end-products that usea platform are called the variants [Krishnan and Gupta,2001; Meyer and Lehnerd, 1997; Muffatto and Roveda,2000; Nelson, Parkinson, and Papalambros, 2001]. Al-though the definition and use of the word platform hasvaried from one researcher to another [Muffato andRoveda, 2000], the above definition seems to be the onemost commonly used and therefore adopted for use inthis paper. Platforms are a special type of module[Meyer, Tertzakian, and Utterback, 1997], and it ispossible to have multiple platforms within any singleproduct architecture. Modular and platform design hap-pens in the early stages of product development whenproduct designers strive to create flexibility for thefuture and/or reuse existing product elements and inter-faces to create new product variants and thereby savedevelopment time and manufacturing costs while alsomaking performance tradeoff decisions [Gonzalez-Zugasti, Otto, and Baker, 2000, 2001; Hernandez, Al-len, and Mistree, 2002].

A larger perspective of platforms shows there arefour types of assets shared when platforming tech-niques are used: components (the most common use ofthe word platform), processes (manufacturing and dis-tribution for example), people & relationships, andknowledge [Robertson and Ulrich, 1998]. A familyarchitecture or platform strategy is economically attrac-tive for several different reasons [Hernandez, Allen, andMistree, 2002; Muffatto and Roveda, 2000]. The inte-gration benefit refers to the economies of scale that arecreated because large volumes of shared componentscan be manufactured for use in the multiple product

variants [Krishnan and Gupta, 2001]. The speed benefitrefers to the increased ability to react to environmentalconditions such as competitor product introductions orchanging customer tastes when using a platform strat-egy. Design benefit refers to the reduced time and effort,managerial complexity, and safety of using a proven(reliable) design base to create a new family variant.

Platform design is a subproblem of product architec-ture design that adds additional complexity. The firstdifficulty is determining how much flexibility must be“designed-into” the platform to meet the future, uncer-tain needs of the product portfolio [Fricke and Schulz,2005]. The second major difficulty is determining thecorrect level of platform distinctiveness (platform di-versity) needed to meet the future goals of the portfolioplan [Robertson and Ulrich, 1998]. A third difficulty isdetermining component quality when it is to be used inboth high- and low-end variants in a product family dueto over-design costs in the low-end products and under-performance costs due to lower-quality components inhigh-end products [Krishnan and Gupta, 2001]. Plat-forms also affect product positioning and introductionsequences, which may influence the firm’s ability to actstrategically to maximize profitability [Krishnan andGupta, 2001].

3. A PRODUCT ARCHITECTUREFRAMEWORK

An extensive literature search revealed that productarchitecture research is coupled to eight key domains ofthe firm as shown by Figure 1. The method used todevelop the framework was largely an inductive proc-ess: (1) an exhaustive literature search focusing onproduct architecture was conducted, (2) previous at-tempts to structure complexity through architecturalconcepts were noted, (3) the relevant papers were sum-marized, (4) papers were “grouped” in different waysthat seemed at first glance to categorize them, and (5)groups were shuffled spatially until a useful frameworkwas found.

These eight domains are arranged around productarchitecture according to their correspondence with“Facet of the Firm” horizontally and according to“What is Managed” vertically. The “Facet of the Firm”categories evolved from our systems view of the firm,which considers the firm as a complex system compris-ing the company itself, the product it produces, thecustomers it serves, and the interactions among all threesystem elements. The “What is Managed” categoriesrefer to the way value is created by each of the threesystem elements. This categorization seemingly cap-tures the product and system architecture literature;



however, an argument for its completeness is clearly inorder and is made inductively. The framework isthought to be complete so long as the firm is seen as anorganizational entity that produces a product (or serv-ice) for one or more consumers.4 Conversely, as longas the scope of management is limited to portfolio,structure, and processes to attain the strategic goals ofthe firm; no other row is necessary.5

The eight key domains are clearly research domainsin and of themselves; yet this paper’s task is to clearlyarticulate the concepts and research at the intersectionof these domains with the product architecture theory.Although many papers have discussed the relationshipsbetween subsets of the eight key domains with productarchitecture, we attempted to capture all of the implica-tions in a single framework. For example, Baldwin andClark [2000] described three “layers” of structure im-plicit in the design of an artifact as: (1) the structure ofthe artifact; (2) its design structure; and (3) its taskstructure. Eppinger and Salminen [2001] introducedthree ways to manage product development complex-ity: process, product, and organization architectures.Along similar lines, the ZOPH model identified the

same three systems in addition to the goal systems,which is the same as the “requirements architecture” inour proposed framework [Negele, Fricke, and Igen-bergs, 1997; Browning, Fricke, and Negele, 2006].Sanchez [2000] described how businesses use product,process, and knowledge architectures to structure or-ganizational learning. Muffatto and Roveda [2000] de-scribed how product platforms affect production andlogistic processes; development processes; project or-ganizational structure; and knowledge management.

Architecture frameworks are another commonmethod for representing engineered systems. Richardset al. [2006] provide a detailed examination of the manyarchitecture frameworks currently used to representsystems. System architectures serve as a communica-tion tool to represent different views of a complexsystem. Each view provides details about the systemvaluable to the various stakeholders involved in devel-oping or managing the system. For instance, in theDoD, the legally mandated architecture framework isthe Department of Defense Architecture Framework(DoDAF). The DoDAF consists of multiple views of anengineered system [Cooper et al., 2005]. While theviews of the DoDAF are well defined, little documen-tation is provided on how the views are to be con-structed [Richards et al., 2006; Bartolomei et al., 2006].

Table I lists the key research questions, which willbe discussed in the next three sections, at the intersec-tion of product architecture and the eight areas aroundit, as defined by the proposed framework of Figure 1.These questions are mainly focused on the impact of theproduct architecture on the particular domain. Also, it

4If this view of the firm is enlarged by adding competition, “politicalconsiderations” or “geographical constraints”, then additional col-umn(s) may need to be added.5Although this categorization (on both dimensions) proved conven-ient to convey the impact of PA on the firm, it is not necessarilyunique. Alternative categorizations could be explored. For instance,the framework could have the literature stream or discipline for itshorizontal axis, which would include organizational science, engi-neering, and marketing. The vertical axis could have been dividedinto assets, architecture, and processes, for instance.

Figure 1. Product architecture’s relationship to eight key areas of the firm.



is worth noting that for some of these questions listedin Table I, a considerable amount of research has al-ready taken place (e.g., impact of product architectureon product development lead-time and cost), whileother questions are less researched (e.g., impact ofproduct architecture on organizational design or mar-keting functions).

4. BUSINESS ASSETS

This section explores the influence of product architec-ture on three kinds of business assets: knowledge port-folio, product portfolio, and brand portfolio.6 Byknowledge portfolio, we mean all knowledge that re-sides within the firm, whether stored physically orwithin individuals, and the learning tools of the firm thatultimately help the firm remain competitive. A firm’sproduct portfolio consists of all products available inthe marketplace at any given time, and the brand port-folio is the grouping of all brands associated with aproduct by the consumer during the purchase decision.

4.1. Knowledge Planning

Knowledge is the ability to make good decisions basedon an understanding of causal relationships. Learninghappens as information—structured data—is used toadvance the understanding of a system [Bohn, 1997].There are two basic kinds of learning that developproduct, process, and market knowledge: acquisitiveand experimental [Lei, Hitt, and Bettis, 1996; Zahra,

Melson, and Bogner, 1999]. Acquisitive learning (ex-ogenous learning according to Lambe and Spekman[1997]) takes place when the firm “acquires and inter-nalizes knowledge” from the outside, such as the casewith technology partnerships [Duysters, Kok, andVaandrager, 1999; Nijssen, Reekum, and Hulshoff,2001] or technology outsourcing [Howells, 1999,Kimzey and Kurokawa, 2002]. Experimental learningoccurs within the firm and generates new and distinctiveknowledge for the organization, which often leads tothe development of core competencies [Prahalad andHamel, 1991]. In order to remain competitive, firmsmust not only manage the development of strategicknowledge, but also develop ways to retain and cascadea portfolio of knowledge throughout the firm.

Knowledge has been classified in various ways [Po-lanyi, 1967; Henderson and Clark, 1990; Nonaka,1994; Spender and Grant, 1996]. One classification ofspecial interest to this paper is between component andarchitectural knowledge [Henderson and Clark, 1990;Henderson and Cockburn, 1994]. Component knowl-edge could be explicit or tacit and reside within anindividual or an organization; but architectural knowl-edge is generally tacit and stored within a larger systemor group [Garud and Nayyar, 1994; Matusik and Hill,1998].7 Architectural knowledge is created in two ways.The first method is through defining the interfacesbetween modules as discussed in Section 2. Sanchez[2000, p. 611] noted that “trying to fully specify the

Table I. Overview of Research Questions Discussed in the Paper

6Physical assets, such as infrastructure, are not included here, but canbe easily accounted for in the processes layer.

7Explicit knowledge refers to knowledge that can be easily articu-lated, captured, and transferred. Tacit knowledge is just the oppositeand can only be acquired through experience [Nonaka, 1994; Polanyi,1967].



component interfaces in a modular product architectureis very likely to reveal any knowledge deficiencies or‘capability bottlenecks’ that limit an organization’s un-derstanding of how the elements in its product architec-ture behave and interact.” The second method isthrough experimentation. Technologies are often notfully developed before they are released into the mar-ketplace [Abernathy and Utterback, 1978; Clark, 1985;Sahal, 1986], which leads to a period of experimenta-tion and the ultimate emergence of an accepted domi-nant design (dominant architecture) [Henderson andClark, 1990]. Architectural experimentation requires adifferent mode of learning that often requires a largertime and capital investment than evolution at the modu-lar or component level [Louis and Sutton, 1991]. Thereason for this is often based on the fact that “oldarchitectural knowledge” often inhibits learning andcan often mislead organizations trying to develop “newarchitectural knowledge.” Because of this phenome-non, it is often easier for new entrants, with less biastowards and shorter history of “old architectural knowl-edge,” to develop new architectural ideas [Hendersonand Clark, 1990].

Hypothesis #1The Product Architecture (PA) strongly influences

the way firms learn and manage their knowledge. Ar-chitectural knowledge is tacit; is developed throughexperimentation; and is retained by the firm’s employ-ees.

Developing architectural knowledge is challenging,but equally challenging is the ability to retain thatknowledge. Knowledge is often lost when projects endand team members are split up; it can be lost whenindividuals leave the firm; it is often lost because it isnot shared; and it is often lost as elements in the archi-tecture begin to be outsourced. Many researchers haveproposed solutions that address the knowledge reten-tion concerns listed above [Fisher, Ramdas, and Ulrich,1999; Huber, 1990; Walsh and Ungson, 1991]. Onemethod to retain knowledge is within the individualsthemselves (human-based knowledge) and sharingthose individuals across multiple projects or productgenerations [Wilson and Hlavacek, 1984]. The human-based mechanism has limitations, however, becausewhen people leave the firm, knowledge often leaveswith them. Ideally, firms should try to document knowl-edge through written or electronic form, but this methodis limited because it is time-consuming or even impos-sible as tacit knowledge is not easily captured by draw-ings or words. Often, product platforms are credited forcapturing knowledge, which can be used over and overto create new products without the need for redesign or

retesting of proven components and subsystems [Muf-fato and Roveda, 2000; Aoshima, 2002]. Indeed, Meyerand Utterback [1993] discussed how product familiesand platforms are an embodiment of the firm’s corecapabilities. Standardized designs and platforms areuseful for retaining knowledge.

An example of how knowledge is captured within aproduct’s architecture and reused to create a new designeliminating the need for an all new design is the use ofthe F119 fighter engine as the basis for the F135 engine.The F119 was developed as a modular system. As theF119 engine has shown to be effective for the twoengine F/A-22 fighter, it was a natural platform for theF135 engine to be used by the single engine F-35 JointStrike Fighter. Because the F119 was a proven modularsystem, it served as a natural baseline design becausethere was far less risk in using it as a design basis thanto develop an all-new engine with the necessary reli-ability for a single engine application.

Hypothesis #2A modular product architecture (e.g., platforms) is

a way to capture architectural knowledge.

4.2. Product Planning

A self-evident success factor for remaining competitiveis the firm’s ability to introduce a steady stream of newproducts and services. A company’s product portfoliois the set of all products available in the market place atany given point in time. Product portfolios change asnew products are launched or existing products areretired [Cooper and Kleinschmidt, 1987]. There arethree generally agreed upon goals of product portfoliomanagement [Cooper, Edgett, and Kleinschmidt,1997a, 1997b]: Maximize the value of the portfolio,achieve the right balance and mix of products, and linkthe portfolio to the business strategy.

The value of the portfolio is maximized when itprovides adequate variety to compete in multiple mar-ket segments and meets the strategic needs of the firm.Portfolio variety is the diversity of product variants thata firm’s portfolio offers to the market place [Ulrich,1995], and sometimes corresponds to the number of“brands” or “models” [Lancaster, 1990]. Perceived va-riety, from the standpoint of the customer, is influencedby the tempo of product releases [Ramdas, 2002].

Variety is motivated by one or more of the followingfour factors [Lancaster, 1990; Ramdas, 2002]: (1) howmuch variety the consumers expect; (2) the perceptionof unmet needs; (3) additional profit generation; and (4)the need to innovate as a way to stay competitive. Fromthese motivations come the different “flavors” of vari-



ety: strategic and tactical. Strategic variety refers to theperceivable differences in products from the con-sumer’s perspective [Martin and Ishii, 1996]. Strategicvariety comes in two forms, variegation and differen-tiation [Ramdas, 2002]. Variegation refers to the varietydisplayed within a single firm’s portfolio, and differen-tiation refers to the variety displayed between a singlefirm’s products and all other competing products. Thevariegation displayed within the portfolio at a particularpoint in time has been called spatial variety and overtime as generational variety [Martin and Ishii, 2002].Alternatively, tactical variety refers to differences be-tween products that are not obvious to the consumer[Martin and Ishii, 1996], but are necessary for at leastone of the following reasons [Kota, Sethuraman, andMiller, 2000]: (1) varying component packaging con-straints within a variant; (2) implementation of newtechnology; and (3) the “idiosyncrasies” of independentdesign teams.

A family of products is tied together by its “core” setof shared components, often referred to as the platform.In order to develop the product portfolio efficiently,businesses must develop good platforms by carefullyaligning the product plan, differentiation plan, and com-monality plan [Robertson and Ulrich, 1998]. The prod-uct plan describes, at a conceptual level, what productswill be delivered to market segments identified as im-portant to developing the business. The differentiationplan describes how the new products will be differentfrom either existing or soon to be released products.Conversely, the commonality plan defines which prod-uct elements (subassemblies, subsystems, components,etc.) will be common across portfolio members. Thesethree plans are essential to ensure that markets exist fornew products, the new products can be designedquickly, and there is sufficient component sharing tohelp create economies of scale. Businesses use productarchitecture to efficiently and economically develop theproduct variants that are believed to help increase thevalue of their portfolio. Families of products8 generallysolve the same type of problem for the consumer, yeteach product exhibits different attribute performancelevels [Li and Azarm, 2002].

New products often make old products obsolete andmay even cannibalize sales of existing products [Con-ner, 1988]. Introduction strategies for low- and high-end products are yet another product planningconsideration. For example, should a low-end productthat fulfills needs similarly to that of a high-end productbe introduced before, concurrently, or after its high-endcounterpart [Baldwin and Clark, 2002; Moorthy and

Png, 1992]? Some researchers note that the pace ofproduct releases and the amount of variety among itsproducts are two important dimensions that influencehow firms plan products [Sanderson and Uzumeri,1997; Fisher, Jain, and MacDuffie, 1996]. If the firm isin an industry where the pace of product releases is slowand only small amounts of variety are needed to remaincompetitive, it is probably not advisable for the firm topursue a platform strategy as demonstrated in Figure 2.When a quick pace for introducing new products isrequired and/or a large amount of variety is required tocompete, platforming concepts begin to make sense.The most important aspect of a platform philosophy isflexibility—how much and often can the platform adaptbefore it becomes obsolete [Gonzalez-Zugasti, Otto,and Baker, 2000].

Hypothesis #3Product architecture (i.e., platform decisions) di-

rectly affects the firm’s ability to efficiently and effec-tively manage the product portfolio.

The flexibility of the product architecture is seen tobe the key factor in determining the ability of a companyto create variety in its portfolio to meet dissimilarcustomer needs [Ramdas, 2002]. The increased flexi-bility in a modular architecture design is often cited asone of the main benefits of the strategy. Drawing fromevolutionary theory, Baldwin and Clark [2000] claimedthere are essentially six ways that product managers canevolve their products through a modular architecture:splitting a design into modules, substituting one modulefor another, augmenting by adding a new module to thesystem, excluding a module from the system, invertingto create new design rules, and porting a module toanother system.

Hypothesis #4A modular architecture is a key enabler for creating

diversity in the firm’s product portfolio.

4.3. Brand Planning

Branding provides continuity and reduces risk for con-sumers as they evaluate a set of branded products forpurchase [Hoyer and Brown, 1990; Roselius, 1971].Malaval [2001] listed the two major functions of brandsas positioning and capitalization. The positioning func-tion is to distinguish a company’s products from thoseof the competitors. The second function, capitalization,is a way for a company to increase the value of thebrand, which often enables the firm to charge a pre-mium for their products. The brand therefore is a tool

8Products coming from a family architecture as discussed earlier inSection 3.



for communication that often adds value to the objectbeing considered for purchase [Farquhar, 1990]. Brandequity is a strength-measure of the consumer relation-ships with the firm’s products and services and is meas-ured by dimensions such as awareness, image, andloyalty [Malaval, 2001].

A brand portfolio traditionally refers to all thebrands that are owned by a business, but there is increas-ing support to include all brands tied to a particularproduct in the consumer’s mind during the purchasedecision, whether those brands are owned by the pri-mary firm’s brand or not [Lancaster, 1990]. Dacin andSmith [1994, p. 232] described two basic properties ofa brand portfolio as “[t]he number of products affiliatedwith a brand and the variance in quality among thoseproducts.” Because creating consumer-brand relation-ships is often very costly, there is increasing pressure toleverage brands. Due to these pressures, brand manag-ers have created complex strategies, involving multiplebrands that strive to extend or endorse other brands. Thediscipline used to design the structure of brand roles andrelationships within a brand portfolio has been labeledbrand architecture [Aaker and Joachimsthaler, 2000;Lederer and Hill, 2001].

One of the ways a product communicates its brandis through its components. It is often important that keycomponents are shared among a product family, abranded platform so to speak, as a way to “instill a senseof the brand gestalt” [Sudjianto and Otto, 2001, p. 2].Sharing components to communicate parent brand con-tinuity, while attempting to maintain distinct subbranddifferentiation, is not easy. Commonality may reducecosts as discussed in Section 2, but it may also reduce

profit potential as products become too similar. TheSudjianto and Otto [2001] framework (shown in Fig. 3)explained when a component should be common orbrand-specific in the differentiation plan. For the prod-ucts investigated, Sudjianto and Otto [2001] found thatit was much easier to maintain brand differentiationwhen distinctive products were investigated for com-monization opportunities than when product variantswere developed using a common platform. These ob-servations link the importance of product architecturedecisions to branding concepts.

Brand management plays a major role in the abilityto use a single modular architecture across a range ofmarket segments [Sanchez, 1999]. This may include thecreation of distinct brands whose performance mayvary to meet the needs of low-, mid-, and high-market

Figure 2. Pace and variety in relationship to product architecture. (Adapted from Sanderson and Uzumeri, 1997.)

Figure 3. General guidelines for developing a commonalityplan (adapted from Sudjianto and Otto [2001]).



segments. If it is difficult to affect performance through“variety-enhancing components,” then opportunities tocreate variety through styling may be a way to createvariety. Either way, brand managers must be aware thata “low-quality” brand’s equity is related to the lowest-quality product in the family, but a “high-quality”brand’s equity is related to the quality of the highest-quality product in the family [Randall, Ulrich, andReibstein, 1998].

Hypothesis #5Brand Managers must take care when using a plat-

form product architecture to create a “low-quality”variant as there is a chance that the branded platform’sbrand equity may actually decrease.

Some components can be grouped into a module,which creates a “brand signature” of its own. Thesemodules are referred to as branded modules [Sudjiantoand Otto, 2001]. An example of a branded module isFord’s PowerStroke diesel engine that is used in bothtrucks and vans, but has a common brand name thatcreates value in the mind of the consumer. The Intelcomputer chip, with the very effective Intel Inside brandstrategy, is another example of a branded module,which creates brand equity for an arguably archetypalcommodity and also adds value to the system-levelbrand that houses it [Schultz, 1998]. As modular archi-tectures often enable fast-paced innovation, it seemsreasonable that branded modules may be an effectiveway to communicate incremental improvements at themodular level. Although brand-building has been seenas cost-prohibitive in the past, there is growing supportfor the use of short-term brands, especially as consum-ers exhibit growing willingness to try new brands [Her-man, 2000].

Hypothesis #6Branded modules may be one way to communicate

fast paced innovation at the modular level.

5. STRUCTURE

This section explores the way product architecture in-fluences the organization architecture and requirementsarchitecture. Organizational architecture describes (1)how decision rights are assigned within the organiza-tion, (2) the performance evaluation systems of bothindividuals and business units, (3) the methods of pro-viding incentives or rewarding the individuals or unitsfor performing their requisite tasks effectively, and (4)what information and/or materials are to be transferredbetween agents [Jensen and Meckling, 1995; Milgrom

and Roberts, 1992; Robey, 1991]. The choice of organ-izational architecture has direct implications on how theorganization manages complexity and on its ability toinnovate its products [Ulrich, 1995]. Alternatively, therequirements architecture describes how performancetargets throughout the product architecture relate toeach other. A solid understanding of how to cascaderequirements from the system level down to the com-ponents ultimately helps to guide system designersthrough the multitude of trade-off decisions that ariseduring product development.

5.1. Organizational Design

The purpose of organizational design is to create astructure that can effectively and efficiently execute therequisite tasks needed to execute business operationsprofitably [Galbraith, 1982]. Organizations function bytransferring information, energy, and materialsthroughout its network of agents called the organiza-tional architecture [Sah and Stiglitz, 1986]. There aretwo types of modes of transfer between agents: internaland external. Internal transfers are exchanges of infor-mation, energy, and/or material within the firm bounda-ries, whereas external transfers are exchanges betweenagents residing in different firms. The costs associatedwith a transfer can be categorized as being either con-venience, political, or distance. Internal transfers aregenerally less expensive as the agents within a singlefirm can make a transfer more conveniently becausespecial contracts are not needed, the agents usuallypossess similar objectives, and there is often closerspatial proximity requiring less “effort” to move physi-cal items. External transfers are more expensive, notonly because the agents often have conflicting objec-tives and the geospatial distances are larger, but alsobecause transaction costs are incurred when two firmsmust establish the transfer interface.

Baldwin and Clark [1997, p. 92] pointed out that“[j]ust like a modular product that lacks good interfacesbetween modules, an organization built around decen-tralized teams that fail to function according to a clearand effective framework will suffer from miscues anddelays.” Indeed, the ease of interaction between agentscould be viewed as a source of competitive advantageas transaction costs accumulate and innovation is im-peded as information flow is obstructed [Dyer and Chu,2003; Bendz and Lawson, 2001]. Figure 4 shows howmultifirm complexity and type of product architectureinfluence the costs of making transfers. Modular prod-uct architectures often reduce costs as they require lessfrequent and more defined transfers between agents (asdiscussed in Section 2), which explains why elements



of a modular architecture can be outsourced more eas-ily.

Research in managing the essential elements ofproduct architecture has revealed relationships withhow organizations are structured [Eppinger and Salmi-nen, 2001; Muffatto and Roveda, 2000; Sanchez andMahoney, 1996, 1997; Sosa, Eppinger, and Rowles,2003]. Morris and Ferguson [1993] argued that match-ing the organizational architecture to the product archi-tecture reduces decision-making complexity byminimizing “vertical and horizontal debates.” How-ever, before a dominant design has emerged, Kazanjian,Drazin, and Glynn [2000] noted that, very often, boththe original product and organizational architecture de-signs are based on a “fuzzy vision” of what the ultimateproduct will become. For this reason, the architecturaldesign for a new product cannot be known completelyat the onset, but emerges from a process of experimen-tation. After a dominant design has emerged, the organ-izational design that becomes apparent often resemblesthat of the product architecture [Brusoni and Prencipe,2001].9 Once this organizational transformation hap-pens (i.e., to parallel the product architecture), it be-comes an impediment for large established firms toaccept and successfully implement new product archi-tectures [Henderson and Clark, 1990]. As an example,the creation of a new integrated architecture for anautomotive instrument panel (which originally con-sisted of two separate modules, the climate control andradio, and was developed by two separate teams) hasfailed due to its misalignment with the existing organ-izational structure. The new integrated architecture re-quired a lot more interaction between the two existinggroups, which was not supported by the existing organ-izational structure.

Hypothesis #7The organizational design will likely correspond to

the product architecture (or vice versa), because to do

otherwise would increase transaction costs and contractcomplexit.

5.2. Requirement Cascading

Determining system-level performance requirementsbegins with understanding the “voice of the customer”[Urban and Hauser, 1980].10 A complex product isgenerally decomposed into a hierarchical system withmultiple levels of interaction between the subsystemsof which it is composed [Simon, 1962]. Cascadingrequirements is the process of strategically dictatingrequirements to elements lower in the product architec-ture hierarchy [Kim et al., 2003]. As the system-levelrequirements are mapped to elements lower in the ar-chitecture hierarchy, the system designers create therequirements architecture. Figure 5 shows how cus-tomer preferences, strategic business initiatives, as wellas government regulations affect product/system re-quirements, and how the attribute targets are flown-down through the product architecture to create arequirement architecture [Austin, Mayank, and Shmu-nis, 2006].

Requirements flowdown remains a significant chal-lenge to systems engineers as it is difficult to ensure thatsystem performance requirements will be met even ifsubsystem targets are met [Cook, 1997]. Indeed, espe-cially in the case of a product that has an integral orpartially modular architecture, the system-level re-quirements are invariably tied to several elements lowerin the architecture hierarchy [Chen et al., 1994]. It isthrough these subsystem performance targets that alter-native designs are evaluated by the respective designteams, so it is important that the performance require-ments have the correct level of abstraction as to providecommon ground for comparing alternative designs[Kota, Sethuraman, and Miller, 2000]. Understandinghow the subsystem requirements are flown down

Figure 4. Cost relationships between organizational architecture and product architecture.

9A similar argument is also noted in the design for integrationapproach proposed by Browning [1999].

10The “voice of the customer” refers to the list of customer needs, ahierarchical structure of those needs, a set of importance weights toprioritize those needs, and competitor benchmark data. These needsare usually translated into system level performance requirements.



through the product architecture hierarchy is importantbecause eventually the byproducts of various engineer-ing design groups (i.e., subsystems) will be integratedinto a single system.

Hypothesis #8To ensure system integration is successful, the sub-

system performance requirements must be tied to sys-tem-level requirements that are valued by the endconsumer. Successful requirements cascading and sys-tem integration is greatly influenced by the productarchitecture.

6. PROCESSES

This section explores the way product architecture in-fluences the processes used to develop a firm’s prod-ucts, how it influences the way products aremanufactured and distributed, and how it influences theway a firm executes the marketing function.

6.1. The Production and DistributionConnection

Having a competitive product portfolio is important, butequally as important is the ability to move those prod-ucts throughout the supply chain with satisfactory serv-ice levels and to produce the products at a reasonablemanufacturing cost. Product variety can indeed addsignificant manufacturing costs to producing a product

family [Child et al., 1991]. The ability of a business toproduce a diverse product portfolio efficiently is fre-quently attributed to manufacturing flexibility [Ulrich,1995; Gerwin and Kolodny, 1992], which is a functionof first, the product architecture and, second, the tech-nology within manufacturing plants, distribution cen-ters, and throughout the supply chain structure[Ramdas, 2002]. Supply chain improvement effortshave focused primarily upon reducing inventory (work-in-process and safety-stock) and reducing lead-time(time from manufacturing to market), as both increasethe profitability of the firm, especially if customers arewilling to pay for increased responsiveness. Producingproducts efficiently can lead to cost advantages over thecompetition.

There are other ways to increase firm profitabilitythrough production and distribution operations how-ever. Product architecture influences how products areassembled; it influences how flexible those assemblyprocesses are to product changes; and it influences howproducts are distributed. Because product architectureoften dictates how products are sequentially assembled,it directly affects the firm’s ability to delay the productdifferentiation point within the supply chain. Delayingthe point of variegation11 means common work-in-process components are not committed until late in theproduction process when they are ultimately used to

Figure 5. Requirements flowdown. (Adapted from Cook, 1997.)

11Variegation is differentiation within a single firm’s product portfo-lio [Ramdas, 2002].



produce multiple unique finished products [Lee andTang, 1997]. This means the “finishing” of a productmay not only happen within a production facility, butalso within distribution centers or even the point of sale,which helps to cope with market uncertainties andlower inventory for the same service level [Ramdas,2002]. When the point of variegation has been delayedeffectively, the firm can mass customize its products tomeet customer preferences for a reasonable price [Pine,1992; Pine, Victor, and Boynton, 1993].

The overall flexibility of a manufacturing systemcan be measured by time and range [Slack, 1983]. Onthe time dimension, a production system is more flex-ible than another if it can change from one productionprocess to another more quickly; if it can be modifiedto produce more product variety more quickly; and if itcan scale to produce larger volumes more quickly.Production range can be broken down into seven di-mensions: mix, changeover, modification, volume, re-routing, material, and flexible responsiveness [Gerwin,1993]. Product architecture influences many of thesedimensions as flexible product architectures lead toflexible manufacturing, which ultimately makes con-cepts such as “mass customization” and “flexible proc-esses” possible [Fisher, Ramdas, and MacDuffie., 1999;Fisher, 1997; Pine, Victor, and Boynton, 1993].

Hypothesis #9The design of a production process is often man-

dated by the product architecture. Designing productarchitectures with this in mind could lead to effectivestrategies for increasing service levels.

6.2. The Product Development and DesignConnection

Product development is the sequence of all the requiredactivities that a company must perform in order todevelop, produce, distribute, and sell a product [Ulrichand Eppinger, 1995]. There are four metrics commonlyused to measure the performance of a product develop-ment project: project time, project cost, product per-formance, and the cost to produce the product [Smithand Reinertsen, 1998]. These metrics are usually con-flicting. For example, if development time is decreased,the product performance may decrease, unit cost mayincrease, and overall project cost may increase or de-crease, depending upon whether the reduced develop-ment time was the result of an additional financialinvestment.

The choice of product architecture influences eachof the four product development project metrics[Browning, 2001, 2002]. In spite of the many benefitsmodular architectures offer (as discussed in Section 3),

integral products can often be developed quicker than amodular design to achieve the same function. Krishnanand Gupta [2001] noted that platforms are time-con-suming to develop, which can result in delayed productlaunches of the first few derivatives. There is thereforea tradeoff decision regarding the long-term economicbenefit of using a platform strategy versus the possibleshort- and long-term effects of introducing productslate. In addition to being costly to design, modulardesigns often end up requiring more physical elements(more components, subassemblies, etc.) to obtain thesame level of functionality as a more integral design,resulting in a larger final product in terms of weight andvolume [Gonzlez-Zugasti, Otto, and Baker, 2000]. Thereason why integral designs perform better on thesedimensions is because multiple functions are mappedto single design elements; so where a modular designwould have required three different elements, for exam-ple, a integral design may only need one, which lowersweight and volume. For this reason, when weight and/orvolume are critical product performance parameters(such as in an aircraft), an integral design often becomesa necessity, which results in product-specific compo-nents [Ulrich and Ellison, 1999].

Product architecture helps to reduce the complexityof engineering design processes through system de-composition and integration. System decomposition isthe breaking down of a complex system into smaller andoften easier to understand system elements, which alsocan often be decomposed even further. Decomposingthe design into smaller modules, with well-definedinterfaces and information needs, allows independentdesign teams to increase the pace of innovation oftenleading to reductions in total time needed to design thefinal product. System integration is the process of inte-grating modules and verifying that they interact in adesired manner—often involving a process of “debug-ging.” Sage and Lynch [1998] present several principlesand perspectives to help further the understanding ofsystems integration. A modular architecture often en-ables teams to test their modules off-line making designintegration less time-consuming [Baldwin and Clark,1997].

Another important aspect of product architecture asit relates to product development is the choice of tech-nology and the decision to introduce new technologyinto the next generation product. Usually, it is safer tointroduce the new technology into the product in amodular fashion; especially when the new technologyis untried and unproven.12 On the other hand, new

12Safer in the sense that if last minute problems emerge with the newtechnology, then the development team can easily revert back to theold technology.



technology sometimes forces the product to take anintegral architecture due to a lack of complete under-standing of this new technology; especially how itrelates to and impacts the rest of the product system. Asthe new technology matures and becomes more under-stood (i.e., in how it relates to the rest of the productsystem), then the possibility of a modular product ar-chitecture starts to emerge.

Hypothesis #10As products become more modular in nature, the

development time increases for the first few artifacts,but decreases as interactions become better under-stood. Conversely, integral architectures are generallyused when time to market for the first variant is ex-tremely important, and as weight and volume con-straints become less flexible.

6.3. The Marketing Connection

Marketing processes focus on discovering strategic op-portunities and developing value propositions to exploitthose opportunities in the marketplace. Marketers beginby defining critical-to-value attributes (discussed pre-viously in Section 5.3) and segmenting the market in away such that product variants can be created to addressthe unique needs of the customers within each segment.After the products are designed and ultimately pro-duced, marketing is then responsible for informing theconsumers of product benefits and inducing them topurchase through product promotion and pricing.

Product architecture influences these traditionalmarketing functions in several ways [Baldwin andClark, 1997; Vollerthun, 2002]. A modular architectureinfluences the way firms conduct marketing researchand create marketing strategies; it can shift productdifferentiation control from the producer to consumer;and it may even influence the traditional “boundaries”of the marketing organization because of the need todefine and manage the strategic roles of modular com-ponents [Sanchez, 1999].

Marketing researchers with potentially modularproduct concepts must help to optimize the flexibilityof modular architectures so they are able to create aportfolio of products to delight the customers withineach of the market segments identified [Sanchez, 1995].Marketing researchers also must clearly understandhow component-based product variety affects the valueproposition for products within each market segment[Porter, 1985; Ramdas, 2002; Sanchez, 1999, 2003]because increasing product variety does not guaranteeprofits in the long run, and may even decrease firmcompetitiveness [Lancaster, 1990; Ramdas and Sawh-ney, 2001]. As system-level performance metrics are

cascaded down through the product architecture, thearchitectural elements ultimately take on one or a com-bination of strategic roles as was described at the endof Section 5.2. The marketing team plays a key role increating the module-based strategy for system-levelperformance metric evolution by dictating the timingand scope of modular performance improvements[Sanchez, 1996, 1999]. In other words, it is necessaryfor the marketing function to be involved in productarchitecture decision-making in order for the marketingplan to be appropriately reflected in the product archi-tecture (particularly the level of modularity required tofulfill market needs). Very often, marketing must lookat what products are already in the portfolio and see howthey can be adapted to maintain or develop a competi-tive edge. Sometimes the target market is stratified in away that the only way to effectively cater to the marketis to design an adaptable product architecture. For thisreason, the early involvement of the marketing functionshould make the architecting process more effective.

Hypothesis #11Marketing’s level of involvement in product archi-

tecture design is related to the level of modularityneeded to fulfill market needs.

Product architecture not only affects the role of themarketing team, but it also can affect the way they dotheir research [Sanchez, 1999]. Marketing research triesto ascertain customer preferences with a small upfrontinvestment before committing to the larger investmentof designing the product itself. Due to the small samplesizes typically used, the accuracy and results of tradi-tional marketing studies often fall into question. Theresults must also be questioned when customers areforced to reveal their preferences based on imaginaryproducts or concepts rather than based on a physicalexperience [Hoeffler, 2003]. A solution to these issues,which can be used with flexible product architecturesand complements tradition marketing research meth-ods, is to conduct real-time marketing research[Sanchez and Sudharshan, 1993]. Real-time marketingresearch starts by producing low-cost variants in smalllot sizes that leverage flexible product architectures toobserve the consumer’s reaction directly by how theyspend their money. The solution becomes to producemore of what the consumers show they want, rather thanwhat they say they want.

Marketing teams are also often faced with difficultdecisions concerning implementing new technologies.Cooper and Kleinschmidt [1987, p. 217] demonstratedthat “product superiority in terms of unique features,innovativeness, and performance is a key factor thatdifferentiates new product winners and losers.” Imple-



menting new innovations is not without risk, however.It is often difficult to know if a new technology has beenadequately tested and validated to ensure robust per-formance in the field. Releasing unreliable productsmay cause significant damage to consumer sentimentand brand equity. For this reason, managers often “playit safe” by favoring incumbent technology and proc-esses that favor an incremental approach [Morgan andDaniels, 2001]. When choosing technology for plat-forms, an incumbent technology increases the prob-ability of developing robust product variants, but thisdecision must be balanced against the revenue generat-ing potential of a new technology [Gonzalez-Zugasti,Otto, and Baker, 2001; Krishnan and Bhattacharya,2002].

Hypothesis #12Flexible product architectures allow firms to rapidly

test the commercial success of new technology withoutthe need to make large investments in entirely newproduct designs.

7. SUMMARY AND CONCLUSION

This paper presented a framework that shows howproduct architecture decisions affect the firm from asystems perspective. Although much research has beenconducted in each of the eight domains surrounding theproduct architecture domain, some links between thesedomains and product architecture have been discussedmore in the literature than others and thus present anopportunity for further research and investigation. Ingeneral, we found that the links to the consumer per-spective regions have been the least analyzed of theeight. There are several possible explanations for this:(1) It may be difficult to formulate research questionsand/or demonstrate results when considering thesetypes of architecture decisions; (2) the intersectionsmay not be thought to be important by many; or (3) theintersections may not have been identified. This paperaddressed problems two and three directly, but it stillmay be difficult to formulate research questions orobtain results in these areas because of its complexity.

Our proposed framework can be very helpful to-wards the understanding whether and how firms cansurvive purely as systems architects and integrators(particularly in many aerospace and automotive com-panies that do not actually fabricate the components—they only assemble them).13 To succeed in such astrategy, companies must understand their system ar-

chitecture and the ramifications of their subsystemsoutsourcing decisions on the eight domains outlined inthe framework; particularly, on their knowledge portfo-lio, organizational structure, system design and devel-opment, requirements cascading, and branding andmarketing strategies. Further research will be requiredto evaluate the framework’s effectiveness in this regard.

Many of the observations made by Krishnan andUlrich [2001] regarding research opportunities withinthe product architecture realm remain and can be seenmore clearly through our proposed framework. In addi-tion to help make the research landscape more clear, theframework has been useful in identifying new researchopportunities. For example, there is a general lack ofempirical studies about how architectural decisions areactually made or how information that influences thearchitecture actually flows (e.g., how product require-ments are actually cascaded throughout the architecturehierarchy). Also, the following are new research ques-tions with respect to architectural benefit communica-tions: How effective can branded modules be atcommunicating the benefits of new technology imple-mented into existing platforms; how effective are theyat building brand equity [Sanchez, 1999]; and how canthe benefits of an entirely new product architecture becommunicated to the consumer? Furthermore, shouldthere be something that resembles “module planning”in the R&D department that resembles product portfo-lio planning?

Another avenue of future research could investigatethe effectiveness of contracts that are meant to guide thesymbiotic relationships of firms that must work to-gether in a way that allows them to profit from devel-oping a multiorganizational product system. Futureresearch could investigate how well contracts are ableto define roles and responsibilities between codepen-dent firms. Although contracts dictate roles and respon-sibilities from the “top,” the effectiveness of a single-or multi-organizational product system developmenteffort may be highly dependent on the cultures of thefirm(s). Future research could also investigate if andhow culture influences the design practices of the firm.

Effective product architecture design maximizes theflexibility of product evolution while providing productperformance that delights customers for a price thatinduces them to buy and provides adequate profits forthe firm to reward shareholder investment. Architecturedecisions are complex because of their broad implica-tions on the future performance of the firm. For thisreason, tools developed for product architects must bothbalance simplicity and rigor, and capture the relevantinformation so good decisions can be made [Little,1970]. In the context of product architecture design, we

13The authors thank one of the reviewers for pointing this out to ourattention.



offer a framework that can help designers capture all therelevant information for their models.

ACKNOWLEDGMENTS

The authors thank the editor of the Systems EngineeringJournal, the associate editor, and five anonymous re-viewers for their insightful and helpful comments anddirection on earlier versions of this manuscript.

REFERENCES

D.A. Aaker and E. Joachimsthaler, The brand relationshipspectrum: The key to the brand architecture challenge,Calif Management Rev 42(4) (2000), 8–23.

W.J. Abernathy and J. Utterback, Patterns of industrial inno-vation, Technol Rev 81 (June/July 1978), 40–47.

Y. Aoshima, Transfer of system knowledge across genera-tions in new product development: Empirical observationsfrom Japanese automobile development. Indust Relations41(4) (2002), 605–628.

L. Argote, Organizational learning: Creating, retaining, andtransferring knowledge, Springer, New York, 1999.

S. Arnold and H.W. Lawson, Viewing systems from a businessmanagement perspective: The ISO/IEC 15288 Standard,Syst Eng 7 (2004), 229–242.

M. Austin, V. Mayank, and N. Shmunis, Graph-based visuali-zation of requirements organized for team-based design,Syst Eng 9(2) (2006), 129–145.

C. Baldwin and K.B. Clark, Managing in an age of modular-ity, Harvard Bus Rev 75(5) (September–October 1997),84–92.

C.Y. Baldwin and K.B. Clark, Design rules: Volume 1. Thepower of modularity, MIT Press, Cambridge, MA, 2000.

C.Y. Baldwin and K.B. Clark, Where do transactions comefrom? A perspective from engineering design, HarvardNOM Working Paper No. 02-33; HBS Working Paper No.03-031, Harvard University, Cambridge, MA, 2002,http://ssrn.com/abstract=328921.

J. Bartolomei, D. Hastings, R. de Neufville, and D. Rhodes,Screening for real options “in” an engineering system: Astep towards flexible weapon system development, IN-COSE 2006, July 10–14, 2006, Orlando, FL.

J. Bendz and H.W. Lawson, A model for deploying life-cycleprocess standards in the change management of complexsystems, Syst Eng 4 (2001), 107–117.

R.E. Bohn, Measuring and managing technological knowl-edge, IEEE Eng Management Rev 25(4) (Winter 1997),77–88.

T. Browning, Process integration using the design structurematrix, Syst Eng 5(3) (2002), 180–193.

T. Browning, E. Fricke, and H. Negele, Key concepts inmodeling product development processes, Syst Eng 9(2)(2006), 104–128.

T.R. Browning, Designing system development projects fororganizational integration, Syst Eng 2(4) (1999), 217–225.

T.R. Browning, Applying the design structure matrix to sys-tem decomposition and integration problems: A reviewand new directions, IEEE Trans Eng Management 48(3)(2001), 292–306.

S. Brusoni and A. Prencipe, Unpacking the black box ofmodularity: Technologies, products and organizations, In-dust Corporate Change 10(1) (2001), 179–205.

A.J. Capraro, S. Broniarczyk, and R.K. Srivastava, Factorsinfluencing the likelihood of customer defection: The roleof consumer knowledge, J Acad Market Sci 31(2) (2003),164–175.

R.K. Chandy and G. Tellis, Organizing for radical productinnovation: The overlooked role of willingness to canni-balize, J Market Res 35 (November 1998), 474–487.

P. Chen and J. Clothier, Advancing systems engineering forsystem-of-systems challenges, Syst Eng 6 (2003), 170–183.

W. Chen, D. Rosen, J.K. Allen, and F. Mistree, Modularityand the independence of functional requirements in de-signing complex systems, ASME Conf Concurrent ProdDes, DE-Vol. 74, ASME, New York, 1994, pp. 31–38.

P. Child, R. Diederichs, F. Sanders, and S. Wisniowski, Themanagement of complexity, McKinsey Quart 4 (1991),52–68.

K.B. Clark, The interaction of design hierarchies and marketconcepts in technological evolution, Res Policy 14 (1985),235–251.

K.R. Conner, Strategies for product cannibalism, StrategicManagement J, Summer Special Issue, 9 (1988), 9–26.

H.E. Cook, Product management: Value, quality, cost, price,profit and organization, Chapman & Hall, London, 1997.

C.A. Cooper, M.L. Ewoldt, S.A. Meyer, and E.W. Talley, Asystems architectural model for man-packable/operableintelligence, surveillance, and reconnaissance mini/microaerial vehicles, Department of Aeronautical Engineering,AFIT, Wright-Patterson Air Force Base OH, 2005.

R.G. Cooper and E.J. Kleinschmidt, Success factors in prod-uct innovation, Indust Market Management 16(3) (1987),215–224.

R.G. Cooper, S.J. Edgett, and E.J. Kleinschmidt, Portfoliomanagement in new product development: Lessons fromthe leaders—I, Res Technol Management 40(5) (1997a),16–28.

R.G. Cooper, S.J. Edgett, and E.J. Kleinschmidt, Portfoliomanagement in new product development: Lessons fromthe leaders—II, Res Technol Management 40(6) (1997b),43–52.

P.A. Dacin and D.C. Smith, The effect of brand portfoliocharacteristics on consumer evaluations of brand exten-sions, J Market Res 31(2) (1994), 229–242.

G. Duysters, G. Kok, and M. Vaandrager, Crafting successfulstrategic technology partnerships, R&D Management29(4) (1999), 343–351.

J.H. Dyer and W. Chu, The role of trustworthiness in reducingtransaction costs and improving performance: Empiricalevidence from the United States, Japan, and Korea, OrgSci 14(1) (2003), 57–69.



D.E. Eppinger and V. Salminen, Patterns of product develop-ment interactions, Int Conf Eng Des, Glasgow, August21–23, 2001.

P.H. Farquhar, Managing brand equity, J Advert Res 30(4)(1990), RC7–RC12.

M. Fisher, K. Ramdas, and K. Ulrich, Component sharing inthe management of product variety: A study of automotivebraking systems, Management Sci 45(3) (1999), 279–315.

M.L. Fisher, What is the right supply chain for your product?Harvard Bus Rev 75(2) (1997), 105–117.

M.L. Fisher, A. Jain, and J.P. MacDuffie, “Strategies forproduct variety: Lessons from the auto industry,” Design-ing the firm, E. Bowman and B. Kogut (Editors), OxfordUniversity Press, New York, 1996.

E. Fricke and A.P. Schulz, Design for Changeability (DfC):Principles to enable changes in systems throughout theirentire lifecycle, Syst Eng 8(4) (2005), 342–359.

J.R. Galbraith, Designing complex organizations, Addison-Wesley, Reading, MA, 1982.

R. Garud and P.R. Nayyar, Transformative capacity: Contin-ual structuring by intertemporal technology transfer, Stra-tegic Management J 15(1994), 365–385.

D. Gerwin, Manufacturing flexibility. A strategic perspective,Management Sci 39(4) (1993), 395–410.

D. Gerwin and H. Kolodny, Management of advanced manu-facturing technology: Strategy, organization and innova-tion, Wiley, New York, 1992.

J.P. Gonzalez-Zugasti, K.N. Otto, and J.D. Baker, A methodfor architecting product platforms, Res Eng Des 12(2000), 61–72.

J.P. Gonzalez-Zugasti, K.N. Otto, and J.D. Baker, Assessingvalue in platformed product family design, Res Eng Des13 (2001), 30–41.

R. Henderson and K.B. Clark, Architectural innovation: Thereconfiguration of existing product technologies and thefailure of established firms, Admin Sci Quart 35 (1990),9–30.

R.M. Henderson and I. Cockburn, Measuring competence:Exploring firm effects in pharmaceutical research, Strate-gic Management J 15 (1994), 63–84.

D. Herman, Introducing short-term brands: A new brandingtool for a new consumer reality, J Brand Management 7(5)(2000), 330–340.

G. Hernandez, J.K. Allen, and F. Mistree, Design of hierarchicplatforms for customizable products, ASME Des EngTech Conf, Montreal, Canada, DAC-34095, September29–October 2, 2002.

S. Hoeffler, Measuring preferences for really new products, JMarket Res 40(4) (2003), 406–420.

T.K.P. Holmqvist and M.L. Persson, Analysis and improve-ment of product modularization methods: Their ability todeal with complex products, Syst Eng 6 (2003), 195–209.

J. Howells, Research and technology outsourcing and inno-vation systems: An exploratory analysis, Indust Innova-tion 6(1) (1999), 111–129.

W. Hoyer and S. Brown, Effects of brand awareness on choicefor a common, repeat-purchase product, J Consumer Res17 (1990), 141–148.

G.P. Huber, Organizational learning: The contributing proc-esses and the literatures, Org Sci 2(1) (1990), 88–111.

M. Jensen and W. Meckling, Specific and general knowledgeand organizational structure, J Appl Corporate Finance 8(1995), 4–18.

R.D. Kazanjian, R. Drazin, and M.A. Glynn, Creativity andtechnological learning: The roles of organization architec-ture and crisis in large-scale projects, J Eng TechnolManagement 17 (2000), 273–298.

H.M. Kim, N.F. Michelena, P.Y. Papalambros, and T. Jiang,Target cascading in optimal system design, Trans ASMEJ Mech Des 125 (2003), 481–489.

C.H. Kimzey and S. Kurokawa, Technology Outsourcing inthe U.S. and Japan, Res Technol Management 45(4) (July-August 2002), 36–42.

S. Kota, K. Sethuraman, and R. Miller, A metric for evaluatingdesign commonality in product families, J Mech Des 122(2000), 403–410.

V. Krishnan and S. Bhattacharya, Technology selection andcommitment in new product development: The role ofuncertainty and design flexibility, Management Sci 48(3)(2002), 313–328.

V. Krishnan and S. Gupta, Appropriateness and impact ofplatform-based product development, Management Sci47(1) (2001), 52–68.

V. Krishnan and K.T. Ulrich, Product development decisions:A review of the literature, Management Sci 47(1) (2001),1–22.

C. Lambe and R.E. Spekman, Alliances, external technologyacquisition, and discontinuous technological change, JProd Innovation Management 14(2) (1997), 102–116.

K.J. Lancaster, The economics of product variety: A survey,Market Sci 9 (1990), 189–206.

C. Lederer and S. Hill, See your brands through your cus-tomer’s eyes, Harvard Bus Rev 79 (June 2001), 125–133.

H.L. Lee and C.S. Tang, Modeling the costs and benefits ofdelayed product differentiation, Management Sci 43(1)(1997), 40–53.

D. Lei, M.A. Hitt, and R. Bettis, Dynamic core competenciesthrough meta-learning and strategic context, J Manage-ment 22 (1996), 549–569.

E. Lesser and L. Prusak, Preserving knowledge in an uncer-tain world, MIT Sloan Management Rev 43(1) (Fall2001), 101–102.

H. Li and S. Azarm, An approach for product line designselection under uncertainty and competition, J Mech Des124(9) (2002), 385–392.

J.D.C. Little, Models and managers: The concept of a decisioncalculus, Management Sci 16 (1970), 466–485.

M.R. Louis and R.I. Sutton, Switching cognitive gears: Fromhabits of mind to active thinking, Hum Relations 44(1)(1991), 55–77.

G.S. Lynn, J.G. Monroe, and A.S. Paulson, Marketing anddiscontinuous innovation: The probe and learn process,California Management Rev 38 (Spring 1996), 8–37.



M.W. Maier, Architecting principles for systems-of-systems,Syst Eng 1(4) (1998), 267–284.

M.W. Maier and E. Rechtin, The art of systems architecting,2nd edition, CRC Press, Boca Raton, FL, 2000.

P. Malaval, Strategy and management of industrial brands:Business to business products and services, Springer, Nor-well, MA, 2001.

M.V. Martin and K. Ishii, Design for variety: A methodologyfor understanding the costs of product proliferation,ASME Design Engineering Technical Conferences andComputers in Engineering Conference, DTM-1610, Irvin,CA, August 18–22, 1996.

M.V. Martin and K. Ishii, Design for variety: Developingstandardized and modularized product platform architec-tures, Res Eng Des 13(2) (2002), 213–235.

S.F. Matusik and C.W. Hill, The utilization of contingentwork, knowledge creation, and competitive advantage,Acad Management Rev 23 (1998), 680–697.

H.M. Meyer, P. Tertzakian, and J.M. Utterback, Metrics formanaging research and development in the context of theproduct family, Management Sci 43(1) (1997), 88–110.

M.H. Meyer and A.P. Lehnerd, The power of product plat-forms, The Free Press, New York, 1997.

M.H. Meyer and J. Utterback, The product family and thedynamics of core capability, Sloan Management Rev34 (Spring 1993), 29–47.

J.H. Mikkola, Modularity, component outsourcing, and inter-firm learning, R&D Management 33(4) (2003), 439–455.

F. Milgrom and J. Roberts, Economics, organization andmanagement, Prentice-Hall, Englewood Cliffs, NJ, 1992.

K.S. Moorthy and I. Png, Market segmentation, cannibaliza-tion, and the timing of product introductions, ManagementSci 38 (1992), 345–359.

L.O. Morgan and R.L. Daniels, Integration product mix andtechnology adoption decisions: A portfolio approach forevaluating advanced technologies in the automobile in-dustry, J Oper Management 19 (2001), 219–238.

C.R. Morris and C.H. Ferguson, How architecture wins tech-nology wars, Harvard Bus Rev 71 (March/April 1993),86–96.

M. Muffatto and M. Roveda, Developing product platforms:Analysis of the development process, Technovation 20(2000), 617–630.

H. Negele, E. Fricke, and E. Igenbergs, ZOPH—a systemicapproach to the modeling of product development sys-tems, Proc 7th Annu Int Symp INCOSE, Los Angeles,1997, pp. 773–780.

S.A. Nelson II, M.B. Parkinson, and P.Y. Papalambros, Mul-ticriteria optimization in product platform design, J MechDes 123(2) (2001), 199–204.

P.J. Newcomb, B. Bras, and D.W. Rosen, Implications ofmodularity on product design for the life cycle, J MechDes 120 (September 1998), 483–490.

E.J. Nijssen, R.V. Reekum, and H.E. Hulshoff, Gathering andusing information for the selection of technology partners,Technol Forecast Social Change 67 (2001), 221–237.

I. Nonaka, A dynamic theory of organizational knowledgecreation, Org Sci 5 (1994), 14–37.

S. Novak and S.D. Eppinger, Sourcing by design: Productcomplexity and the supply chain, Management Sci 47(1)(2001), 189–204.

J.D. Orton and K.E. Weick, Loosely coupled systems: Areconceptualization, Acad Management Rev 15(2)(1990), 203–223.

G. Pahl and W. Beitz, Engineering design: A systematicapproach, Springer, Berlin, 1984.

G. Pahl and W. Beitz, Engineering design: A systematicapproach, 2nd edition, Springer, Berlin, 1996.

J.B. Pine, Mass customization: The new frontier in businesscompetition, Harvard Business School Press, Boston,1992.

J.B. Pine, B. Victor, and A.C. Boynton, Making mass customi-zation work, Harvard Bus Rev 71 (1993), 108–119.

M. Polanyi, The tacit dimension, Doubleday, Garden City,NY, 1967.

M.E. Porter, Competitive advantage, Free Press, New York,1985.

C.K. Prahalad and G. Hamel, Corporate imagination andexpeditionary marketing, Harvard Bus Rev 69 (July/Au-gust 1991), 81–92.

K. Ramdas, Managing product variety: An integrative reviewand research directions, Prod Oper Management 12(1)(2002), 79–102.

K. Ramdas and M. Sawhney, A cross-functional approach todesigning multiple line extensions for assembled prod-ucts, Management Sci 47(1) (2001), 22–36.

T. Randall, K. Ulrich, and D. Reibstein, Brand equity andvertical product line extent, Market Sci 17 (1998), 356–379.

E. Rechtin, Systems architecting: Creating and building com-plex systems, Prentice Hall, Englewood Cliffs, NJ, 1991.

M.G. Richards, N.B. Shah, D.E. Hastings, and D.H. Rhodes,Managing complexity with the Department of DefenseArchitecture framework: Development of a system ar-chtiecture model, Conference on Systems EngineeringResearch (CSER) 2006, Los Angeles, CA, 2006.

D. Robertson and K. Ulrich, Planning for product platforms,Sloan Management Rev (Summer 1998), 19–31.

D. Robey, Designing organizations, Irwin:Burr Ridge, IL,1991.

T. Roselius, Consumer rankings of risk reduction methods, JMarket 35(1) (1971), 56–61.

A.P. Sage and J.E. Armstrong, Introduction to systems engi-neering, Wiley-Interscience, Indianapolis, IN, 2000.

A.P. Sage and C.L. Lynch, Systems integration and architect-ing: An overview of principles, practices, and perspec-tives, Syst Eng 1 (1998), 176–227.

R.K. Sah and J.E. Stiglitz, The architecture of economicsystems: Hierarchies and polyarchies, Amer Econ Rev 76(1986), 716–727.

D. Sahal, Technological guideposts and innovation avenues,Res Policy 14 (1986), 61–82.

R. Sanchez, Strategic flexibility in product competition, Stra-tegic Management J 16(Summer Special Issue) (1995),135–159.



R. Sanchez, Strategic product creation: Managing new inter-actions of technology, markets, and organizations, Euro-pean Management J 14(2) (1996), 121–138.

R. Sanchez, Modular architectures in the marketing process,J Market 63(4) (1999), 92–112.

R. Sanchez, Modular architectures, knowledge assets, andorganizational learning: New management processes forproduct creation, Int J Technol Management 19(6) (2000),610–629.

R. Sanchez, Using modularity to manage the interactions oftechnical and industrial design, Des Management J AcadRev 2(1) (2003), 8–19.

R. Sanchez and J.T. Mahoney, Modularity, flexibility, andknowledge management in product and organization de-sign, Strategic Management J 17(Winter Special Issue)(1996), 63–76.

R. Sanchez and J.T. Mahoney, Modularity, flexibility, andknowledge management in product and organization de-sign, IEEE Eng Management Rev 44 (Winter 1997), 50–61.

R. Sanchez and D. Sudharshan, Real-time market research:Learning-by-doing in the development of new products,Market Intell Plan 11(7) (1993), 29–38.

S.W. Sanderson and M. Uzumeri, Managing product families,Richard D. Irwin, Chicago, 1997.

D. Schultz, What’s in a name? Your brand could be your mostvaluable long-term asset, Indust Week 247(6) (1998), 20.

D.M. Sharman and A.A. Yassine, Characterizing complexproduct architectures, Syst Eng 7 (2004), 35–60.

H.A. Simon, The architecture of complexity, Proc Amer PhilSoc 106(6) (1962), 467–482.

N. Slack, Flexibility as a manufacturing objective, Int J OperProd Management 3(3) (1983), 4–13.

P. Smith and D. Reinertsen, Developing products in half thetime: New rules, new tools, Van Nostrand Reinhold: NewYork, 1998.

M.E. Sosa, S.D. Eppinger, and C.M. Rowles, Identifyingmodular and integrative systems and their impact on de-

sign team interactions, J Mech Des 125 (June 2003),240–252.

J.C. Spender and R.M. Grant, Making knowledge the basis ofdynamic theory of the firm, Strategic Management J 17(1996), 45–62.

A. Sudjianto and K. Otto, Modularization to support multiplebrand platforms, Des Eng Tech Conf Comput Inform EngConf, Pittsburgh, PA, DTM-21695, September 9–12,2001, 1–14.

N. Suh, The principles of design, Oxford University Press,New York, 1990.

K.S. Swan and B.B. Allred, A product and process model ofthe technology-sourcing decision, J Prod Innovation Man-agement 20(6) (2003), 485–497.

K.T. Ulrich, The role of product architecture in the manufac-turing firm, Res Policy 24 (1995), 419–440.

K.T. Ulrich and D.J. Ellison, Holistic customer requirementsand the design-select decision, Management Sci 45(5)(1999), 641–658.

K.T. Ulrich and S.D. Eppinger, Product design and develop-ment, McGraw-Hill, New York, 1995.

G.L. Urban and J.R. Hauser, Design and marketing of newproducts, 2nd edition, Prentice Hall, Upper Saddle River,NJ, 1980.

A. Vollerthun, Design-to-market: Integrating conceptual de-sign and marketing, Syst Eng 5 (2002), 315–326.

J.P. Walsh and G.R. Ungson, Organizational memory, AcadManagement Rev 16(1) (1991), 57–91.

D.E. Whitney, Nippondenso Co. Ltd.: A case study of strate-gic product design, Res Eng Des 5 (1993), 1–20.

T.L. Wilson and J.D. Hlavacek, Don’t let a good idea sit onthe shelf, Res Management 27(3) (1984), 27–34.

S.A. Zahra, A.P. Melson, and W.C. Bogner, Corporate en-trepreneurship, knowledge, and competence develop-ment, Entrepreneurship Theory Practice 23(3) (1999),169–190.

Ali Yassine is an assistant professor in the Department of Industrial and Enterprise Systems Engineering(IESE) at the University of Illinois at Urbana-Champaign (UIUC) and the director of the ProductDevelopment Research Laboratory. He teaches a graduate class in Systems and Entrepreneurial Engineer-ing and an undergraduate class in Operations Research. His research involves managing the developmentprocess of complex engineering systems, design process modeling, and IT-enabled concurrent engineer-ing. Dr. Yassine received the B.E. degree in Mechanical Engineering in 1988 from the American Universityof Beirut. He received the M.S. and Ph.D. degrees in 1989 and 1994 in Industrial and ManufacturingEngineering from Wayne State University in Detroit, Michigan. He is a member of INFORMS, ASME,and PDMA.



Luke Wissmann has a Bachelors in Industrial Engineering (1998) and a Masters in General Engineering(2000), both from the University of Illinois at Urbana-Champaign. He is currently working on a Ph.D. inthe Department of Industrial and Enterprise Systems also at UIUC. Mr. Wissmann has industry experiencewithin several industries obtained while working at Ford, 3M, and United Technologies. His researchinterests lie at the intersection between business and engineering, including product planning, productarchitecture as it relates to business, and the business of systems integration.



regular paper the implications of product architecture on ...ay11/architecture.pdf · the...

Documents