Taking a platform approach also has ramifications for organising the development of solutions in terms of collaboration with actors in the network. Given that value is created in a network and that solution provision engages multiple actors (Jaakkola & Hakanen, 2013; Story et al., 2017), efforts
109
geared towards organising such development are realised beyond the company’s boundaries—that is, in the network. According to the mirroring hypothesis, the solution architecture will mirror those efforts, which are also concerned with inter-organisational relationships (Cabigiosu & Camuffo, 2012). However, as shown in this thesis, there are major dynamics in place in the network that pose implications for the solutions architecture.
This thesis maintains that solutions are interconnected and, as such, form networks of solutions (Paper 5). That characteristic results in a lack of stability in the solution architecture initially, especially given the novelty of that approach at Gamma, which eventually means that more information is shared among specific actors in solutions development in order to develop the platform. For a modular architecture, that circumstance has been referred to as the ‘complementary hypothesis’, which proposes that a modular approach requires more information sharing among actors as a result of joint development efforts (Cabigiosu & Camuffo, 2012; Hsuan, 1999). Those joint efforts show that, at least in the establishment of the platform, coupling among actors involved in the solution family becomes tighter, not looser, which aligns with the notion that a partnership is associated with modularisation opportunities (Hsuan, 1999), because it is concerned with establishing an architecture. In this thesis, the platform is argued to develop in accordance with the mirroring hypothesis, albeit also partly as a result of knowledge accessed and gained in those partnerships.
However, as collaboration with some actors in solutions development increases, other couplings become looser. Paper 5 describes how third-party suppliers, who previously added their equipment (e.g. a crane) to finished trucks, became a partner in the development of a new solution, which potentially made the company to bypass its own customers with that specific solution. That arrangement could result in a lost business opportunity, as well as a need to ensure that new opportunities not only turn a profit as standalone cases but also cover the potential loss of another case. Solutions thus cause movement in the network, in which companies assume multiple roles dependent on the solutions in which they engage, as Paper 5 reveals. Therefore, though a modular architecture has been discussed to be associated with both less and more information sharing among actors in the network (e.g. Cabigiosu & Camuffo, 2012; Hsuan, 1999; Sanchez & Mahoney, 1996), a solution platform architecture formed by starting with an individual solution seems to be associated with more information sharing among the partners involved. Accordingly, transcending
110
not only internal but also company boundaries, the costs of joint development efforts for the platform are likely to increase compared to those of an individual project.
At the same time, this thesis also shows that companies seek to provide standardised interfaces for so-called ‘plug-and-play’ solutions, as detailed in Papers 1 and 3. Once the platform is developed, such interfaces can reduce the need for information sharing among actors, for they can simply ‘plug into’ standardised interfaces. That allowance indicates a combined platform-modular approach and enables the provision of a wider variety of solutions by collaborating with a wider range of actors. Such an approach would be associated with rather loose couplings between actors engaged in solution provision, especially compared to individual solutions, as evident in the ECOS project. Consequently, there could be various degrees of coupling among actors in the network simultaneously in play dependent on the different solutions, their origins, and the approach taken to develop the platform.
The information-extensive partnerships used to develop platforms originating from an individual solution pose implications for internal efforts to structure the organisation, especially when separating service development from product development. Related to the problem concerning the ownership of a platform, as previously reported, the separation of products and services also introduces complexity into the interface with partners. Partnerships that involve both technology and commercial aspects are somehow new to Gamma, as partly addressed in Papers 3–5. Purchasing is used to work with suppliers, in which the relationships are generally more transactional and focused on exchange. The aftermarket function collaborates with service partners, including maintenance workshops, used to deliver services of a more stand-alone character (Paper 5), mostly concerned with spare parts and working hours. However, partnerships with external actors to provide product–service solutions constitute a new arena for the company. In such endeavours, Gamma faces major challenges in determining which function should take the lead in those new partnerships, with little consensus about who should approach the partner. Gamma’s representatives thus highlighted the need to consider partners as customers and, in addition to responding to their needs, being flexible to changes in the network. That requirement appears to be a challenge, because the separation of the product and service scatters the information that the company has, meaning that an overview is missing, which in turn raises costs of developing the solution together with other actors in the network.
111