Controlled Integration

While communication with customers was considered critical, clear boundaries were established for restricting the overlaps between ECCo-developed artifacts and customer-developed artifacts. Since its customers often integrated their own modules into the product, ECCo had to ensure that these artifacts are kept separate so that they do not ‘contaminate’ the platform or the variants developed at ECCo. In contrast, SCCo facilitated considerably stronger integration, while still maintaining boundaries across the products.

Application engineering (product derivation) and domain engineering (platform

development) teams were managed through a tightly controlled team structure. While separation of these teams was considered critical to maintain the stability of the product platform,

mechanisms were put in place to enable communication across these teams at SCCo.

5.4 Ambidexterity

1. Ambidexterity through platform development:Evidence from our study points to the notion thatambidexterity is achieved by developing a small platform initially that addresses the common needs of a few customers and then incrementally evolving the platform to increase its coverage and by retaining the flexibility to derive numerous product variants.

2. Ambidexterity through process management: Managing the development process such that it can be easily adapted to accommodate different levels of product variety and dynamic customer needs can be conceptualized as another dimension of ambidextrous behavior.

3. Ambidexterity through adaptable structure: Ambidexterity may be achieved in software product development by creating an organization that is structured into domain and application engineering teams, and by structuring the communication across these teams.

6. Cross-case Comparison

While both SCCo and ECCo shared the same objectives in that they focused on

developing a product family with a common platform that is shared across product variants, they demonstrated considerably different approaches to developing the family and to addressing the conflicting demands that arose in developing an adaptable platform as well as catering to unique customer needs. SCCo followed a bottom-up approach in that they focused initially on a limited set of features in the product platform selectively by focusing on one industry. They then

expanded the platform incrementally to accommodate the needs of various industries leading to a versatile platform that was adaptable in such a way that product variants could be developed efficiently and could handle customer-specific requirements. ECCo, on the other hand, took a top-down approach in that it established the coverage of the platform so that it can accommodate the needs of a range of customer segments. While this required additional upfront investment and resources, they focused more on the stability of the platform and shared the notion that upfront

44

investment in developing a well-architected platform could lead to advantages during product derivation. Also, their product family was considerably more mission critical because it could impact on road performance of automobiles. This prompted ECCo to carefully develop a high quality platform that will enable them to derive product variants more efficiently than SCCo.

Also, while SCCo could afford to use considerably complex design techniques to incorporate flexibility in the product platform, ECCo was limited to certain techniques due to various system constraints.

7. Contributions to Theory and Practice

Findings from our study contribute to the conceptualization of ambidexterity in the context of software PFD. While past research has extensively discussed ambidexterity in a general organizational context, our study is one of the first attempts at understanding ambidexterity in the context of managing the software product development process. Our

research is also unique in its attempt at empirically linking balanced product family development practices to the theory of organizational ambidexterity. The balanced practices that are identified in our framework are novel to the literature on ambidexterity that identifies important

antecedents for ambidexterity. Our findings add to the conversation in the literature on organizational ambidexterity that focuses on the various approaches to achieve ambidexterity (structural vs. contextual ambidexterity) and the systems and processes that need to be put in place to achieve ambidexterity. Our findings suggest that while a partially structural approach works well in PFD projects, the collaboration between the structures (domain and application engineering) is more pronounced and carefully managed.

Findings from our study contribute to software development organizations that face significant challenges in managing variety under quality, cost, and schedule constraints.

Stakeholders involved in software product family development can use the specific practices discussed in this research to implement a balanced product family approach to software development.

8. References

1. Clements, P., and Northrop, L. Software product lines: Practices and patterns. Sei series in software engineering, Upper Saddle River, NJ: Addison-Wesley, 2002.

2. Cusumano, M.A., and Yoffie, D.B. Software development on internet time. IEEE Comput., 32, 10 (1999), 60-69.

3. Eisenhardt, K.M. Building theories from case study research. Acad. Management Rev., 14, 4 (1989), 532-550.

4. Gibson, C.B., and Birkinshaw, J. The antecedents, consequences, and mediating role of organizational ambidexterity. Acad. Management J., 47, 2 (2004), 209.

5. Gupta, A.K.; Smith, K.G.; and Shalley, C.E. The interplay between exploration and exploitation. Acad.

Management J., 49, 4 (2006), 693-706.

6. Schmid, K., and Verlage, M. The economic impact of product line adoption and evolution. IEEE Software, 19, 4 (2002),

7. Tushman, M.L., and O'Reilly Iii, C.A. Ambidextrous organizations: Managing evolutionary and revolutionary change. California Management Rev., 38, 4 (1996), 8.

8. Weiss, D.M., and Lai, C.T.R. Software product-line engineering: A family-based software development process.

Reading, MA: Addison-Wesley, 1999.

45

9. Yin, R.K. Case study research: Design and methods. Third ed., Applied social research methods series, ed.

Leonard Bickman and Bebra J. Rog, Vol. 5, London: Sage Publications, 2003.

46