Shared Product Architectures for Engineering-to-Order Buyers and Suppliers: Insights from a Case Study

Abstract

This paper explores the potential for engineer-to-order (ETO) companies to capitalise financially on their modular product architectures by sharing them with their suppliers. Few scholars have studied product architectures being shared across buyers (ETO companies) and suppliers. While the topic’s relevance has previously been demonstrated, scholars tend to leave out details on how the shared elements of architectures, respectively, benefit the company and with what financial effect. The study aims to develop a framework for describing a shared architecture and to test it in a case study of an ETO company and two of its tier-one suppliers. The framework is built on existing research and the case work of this paper. The study identifies three key aspects of a shared product architecture: a common system decomposition, modules and interfaces that are financially driven by interorganisational alignment of key design characteristics, and a series of coordinated activities that are consistent and mutually beneficial for both organisations. The results show that the ETO company saw 10–35% cost saving on supplier scope after developing the shared architecture. The study contributes to the literature on product architectures and provides insights for ETO companies aiming to enhance financial performance through modular architectures.

1. Introduction

Engineer-to-order (ETO) companies typically receive unique project requirements with every customer order. These circumstances require them to make either a unique engineering design or a significant modification to an existing design. The resulting design variance has shown to significantly increase the costs of projects [1,2,3,4]. Due to the scale of projects (typically including more than 100,000 components), ETO companies will oftentimes outsource many parts of the value chain [4], including detail engineering, design, and fabrication, which means that a lot of design knowledge resides with the suppliers of the company. Likewise, many parts of the increased costs induced by product variety will likely be experienced directly by the suppliers and indirectly by the ETO buyer. Additionally, supplier operations are increasingly influenced by dynamic market demand and supply chain considerations [5] which demands flexibility due to the changing external conditions.

The challenge of product variety has had many companies looking towards modular product architectures in an attempt to minimise the negative impact of design variance. Modular architectures intend to decouple an integrated functional design into physical and separate modules according to common functions and customer needs [6]. Thus, the architectures comprise a common product decomposition and aligned solution principles. The effects of such initiatives are predominantly documented to reduce variants in design, leading to needing fewer engineering resources for high-volume product companies, enabling greater economies of scale. Additionally, recent research shows digital technologies progressively enhancing traceability (with, e.g., blockchain) and incentivising innovation and investment in, e.g., carbon capture, utilisation, and storage [7].

However, while architectures have been studied in terms of their successful impact on variant reduction, there is much less literature on the how architectures can be driven by their direct financial potential, especially for low-volume products [8]. As argued by Foehr et al. [9], a large proportion of ETO companies do not see the cost of product variance as being primarily driven by hours spent updating drawings, nor is it driven by a lack of economies of scale. One financial stream relevant for an ETO company is its suppliers since they cover a substantial part of the cost of physically manufacturing products [10]. Moreover, as mentioned earlier, knowledge about how design changes affect the financials of a product is not confined to a single ETO company but rather is distributed across multiple suppliers and organisations. This suggests that ETO companies that wish to pursue directly financially driven product architectures would benefit from aligning and sharing their architecture to be mutually beneficial with their suppliers.

In the context of this paper, a “shared architecture” is understood to comprise (1) a common system decomposition that is shared across two organisations. Such decomposition could be for unequivocally communicating which systems are stable and which are varying; (2) a set of modules and interfaces used for interorganisational alignment of key design characteristics. Such alignment could, for instance, be designing only with a plate thickness that the supplier’s equipment can bend efficiently; and (3) a series of coordinated activities which are consistent across and mutually beneficial for both organisations. Such activities could involve the buyer freezing a certain scope earlier to allow the supplier more time to procure a better deal with their sub-suppliers. The attributes of such a shared architecture should bring a greater potential for the buyer to financially capitalise on their efforts put into a product architecture.

The subsequent literature study shows that although the current body of literature covers a wide range of architecture methodologies, only a few scholars have studied product architectures being shared across buyers (ETO companies) and suppliers. While these scholars indicate that architecture decisions can be beneficial to communicate to suppliers [11,12], they tend to leave out details on how system decompositions, modules, interfaces, and coordinated activities, respectively, enable benefits for the company and with what financial effect. Consequently, in the existing literature, it has not been shown how to model such a shared architecture, and what the quantified financial potential is. Therefore, this paper investigates how ETO companies could use a shared architecture to financially capitalise on their use of modular architectures. In doing so, the existing literature is reviewed in Section 2; Section 3 describes the case study method employed; in Section 4 a framework is developed, and this is tested in Section 5 through a case study of an ETO company and two of its tier-one suppliers, followed by an analysis of the measured financial benefits capitalised by the initiative. The test of the framework and quantification of financial impact are discussed and concluded in Section 6, thereby contributing the methodological advancement of theory of product architectures [6,13], the theory of technical systems [14], and Early Supplier Involvement—ESI [15,16,17].

2. Theoretical Background

This section reviews the extent to which the previous literature has investigated the use of shared product architectures across an ETO buyer and its suppliers. More specifically, it investigates if the current literature has studied the description of shared architectures in terms of the following three aspects:

• Does the described product architecture comprise a system decomposition that is mutually shared across the supplier and buyer?
• Does the described architecture comprise modules and interfaces that are financially driven by interorganisational alignment of key design characteristics?
• Does the architecture in question describe and financially quantify how a series of coordinated activities are consistent and mutually beneficial for both organisations?

This research builds on the theory of modular product architectures; hence, the existing literature herein is reviewed according to the abovementioned three aspects.

2.1. Modular Product Architectures

The use of product architectures to manage design variance has been studied by many scholars who have presented several methodologies (e.g., Roy and Abdul-Nour [18]). One early example is the Design Structure Matrix (DSM) [19], which has been used to empower product developers with a binary overview of system dependencies in relation to product variety. This methodology was later modified for a number of different contexts; notably, Pakala and Allada [20] studied the blending of DSM with the project evaluation and review technique and Critical Path Method. The paper presents how module clustering can inform supplier consolidation, postponement, and supply chain crashing. Nevertheless, their study does not investigate how interorganisational sharing of a product architecture might benefit the buyer and its suppliers.

Harlou [13] has demonstrated valuable benefits to using a graphical modelling technique named the Product Family Master Plan (PMFP). This modelling technique has been expanded to cover other functional domains by Askhøj et al. [21]. The latter introduces the MESA tool, which extends the PMFP with an electrical and software engineering aspect, and Küchenhof et al. [22] investigate a similar topic by introducing a modified V-model. Similarly, Zou et al. [23] present an approach on the reuse of modular mechatronics systems. Visual modelling principles for architectures (such as the PMFP) have also been studied by Bruun et al. [24] in the form of the interface diagram. While the qualities of the presented principle are evidently all valuable, common for all four, they do not elaborate on the principles of improvement on the supplier’s scope.

Concerning cross-functionality and product architectures, Breimann et al. [25] and Otto et al. [26] investigate how electromagnetic and thermal fields influence product architectures on a component and functional level, respectively. Comparably, Zuefle et al. [27] investigate in a broader sense the potential of cross-functional collaboration in modular design. Multiple benefits are highlighted by Zuefle et al. [27], such as the upgradeability of modules or plug-and-play replacement which are certainly beneficial to companies. Nevertheless, none of three papers discuss how such cross-functional architecture alignment might be facilitated inter-organisationally.

On the other hand, the paper presented by Haug [12] studies how product information models (such as the PMFP) can be communicated with suppliers in the ETO industry. The data presented by Haug suggest that when giving suppliers access to these models, it generally reduces the number of misunderstandings amongst the suppliers. They elaborate that the models also help the suppliers by increasing the volumes of standard designs and by reducing the amount of drawing work. Similarly, Erixon et al. [28] highlight how utilising module decompositions can enable prioritisation of sub-functions with long lead times. Although the two articles do elaborate on the improvement principles of alignment towards suppliers, they do not financially quantify the effects on the supplier’s scope.

Mathematical approaches to modelling architecture decisions, such as the one presented by De-Weck [29], can be used as a more quantitative method of determining the optimal number of platforms within an architecture. Similarly, Siiskonen et al. [30] have studied how choosing the optimal number of modular variants impacts the production costs of products. Like De-Weck, Siiskonen et al. [31] use a computational model to measure the extent of the cost implications on manufacturing. However, the focus on cost-optimal architectures does not cover which improvement principles stem from a shared decomposition across buyer and supplier.

Scholars have also studied the relation between overall engineering concepts for modular product development. Pakkanen et al. [32] present the Brownfield Process and suggest focusing on the management of five main engineering concepts as a guide for development. However, the method does not quantify how such principles of alignment benefits suppliers specifically, but rather only quantifies for the buyer holistically.

While the aforementioned scholars focus on modularity across different functional domains, other studies have investigated principles of modular architectures and their effects on alternative parts of the value chain. The case study introduced by Mueller et al. [33] demonstrate the value of analysing how product design principles relate to the commissioning activities of ETO companies. Borgue et al. [34] support similar findings with a case study on test and qualification activities in the architectural design of satellite propulsion systems. However, strictly speaking, neither elaborate on the potential improvement principles attributed to suppliers.

Similar to Mueller et al. [33], Elstner and Krause [35] investigate modularisation in other parts of the value chain, specifically concerning production ramp-up. Likewise, Halfmann et al. [36] describe how to design modular architectures for assembly. It is clear that the contributions presented in each of these papers all prove useful as input to modular architectures; however, they are limited in a similar way to the method suggested in Mueller et al. [33].

Rong et al. [37] propose an approach using a fuzzy clustering analysis to help companies evaluate how module choices relate to supply chain choices and the associated cost and lead-time hereof. Similarly, Brosch et al. [38] present a model for describing the relation between the module drivers of an architecture and the possibility of applying a postponement strategy in the supply chain. However, the paper does not explicitly describe how these considerations extend across a supply chain’s suppliers, nor does it quantify the effect achieved by buyers and suppliers applying such architecture decisions.

Similar to Borsch et al. [38], other scholars have looked at linking module drivers to the rest of the product life phases. Blees [39] presents the Module Process Chart and suggest using the tool to map the dependencies of module drivers and module driver specifications to modules across product development, procurement, production, sales, end product, use, and recycling and disposal. Related, Greve et al. [40] also studied holistically the effects of modularisation by investigating both direct and indirect costs via their Impact Model of Modular Product Families (IMF). Nevertheless, the papers do not describe which improvement principles can be achieved by a supplier through mutually aligning the product decomposition and with which financial effects.

The research conducted by Krause et al. [41] combine many of the previously mentioned studies into a more holistic integrated approach for developing modular product families. The idea of a more data-driven approach to module requirement validation has been investigated by Wagenmann et al. [42] to further strengthen this modular approach. While Krause et al. [41] clearly demonstrate having reduced component variance, neither paper explicitly outlines how these principles of alignment extend to the suppliers of the company.

Other authors have presented similar frameworks aiding companies in implementing modular architectures, such as the Architecture Mapping and Evaluation framework by Mortensen et al. [43] and the 13 steps for developing a platform concept by Otto et al. [44]. While the frameworks clearly provide a valuable overview, they do not describe how the work performed in these critical steps will affect the scope of the company’s suppliers.

Further lifecycle perspectives of product architectures have been considered by Küchenhof and Krause [45] and Küchenhof et al. [46] concerning architectures across product generations through assessing the activeness and centrality of product components and modules. Nevertheless, the principles of improvement for a company’s suppliers are not explicitly described.

2.2. Literature Discussion

Concluding on the reviewed studies, it is evident that they all contribute with valuable insights for product architecture decision-making. In a world where ETO projects get increasingly bigger and rely more and more on outsourcing to suppliers, it is even more relevant for companies to understand how their architecture decisions affect the scope of their suppliers. Although a lot of design and architecture knowledge resides with the suppliers, very few scholars have (1) studied how product architectures and system decompositions can be mutually shared and optimised across organisations. Moreover, scholars who support that architectures can be beneficial to communicate to suppliers [12] tend to (2) leave out descriptions of how companies have shared modules and interfaces that are financially driven by interorganisational alignment of key design characteristics. Furthermore, the present authors were unable to identify (3) any studies quantifying what the financial impact can be if architecture activities are coordinated to be mutually beneficial for both organisations. As such, the literature review in this paper outlines that previous studies have not sufficiently investigated all aspects of ETO companies sharing a product architecture across its suppliers.

3. Materials and Methods

The following section describes how the presented framework was tested in a case study at an ETO company. The use of the case study methodology provides a medium for working with theories from practical insights and moving on to the testing stage. It can help the researcher capture and formalise industry practitioners’ knowledge and experiences [47]. Such attributes were all considered desirable for this study. Concerning the number of case companies investigated, the authors decided to investigate a single company since it enables a deep study of the research problem [48]. Data collection techniques employed in this study comprised semi-structured expert interviews and participatory observations through meetings and workshops. Tender material and financial data were also studied to provide context for the meetings and workshops.

3.1. Case Context

The investigated company is a developer of state-of-the-art manufacturing plants within their industry. The company sells, designs, engineers, procures, installs, commissions, and run the facilities globally. Depending on the area of the factory, the company has varying involvement in the delivery process. This means that certain equipment is developed and engineered in-house down to the ‘nuts and bolts’, while other equipment are only specified to meet functional specification and are engineered, manufactured, installed, and commissioned by a supplier. Each facility custom engineers, to varying degrees, to meet unique and project-specific requirements. In the context of this paper, the case company is considered the buyer.

The company in question has been working with modular architectures since 2012. The company has, in the past, faced barriers to adopting architectures, which is why they were interested in understanding how making it more financially driven could help them in their business goals. With increasing competitive pressure on both the buyer and suppliers, more strategic initiatives were desired by top management as a way of staying competitive by finding mutually beneficial initiatives between the buyer and its suppliers. This alignment of interests is the reason the company was chosen for the study.

For the study, a single equipment area with the same supplier for the entire scope was chosen. This equipment area was chosen since it comprised both a significant CAPEX and significant installation time on site—two business-critical areas for the company. Furthermore, two suppliers of that same equipment area were investigated in the study. The selection criteria for the two suppliers required each to have project experience of at least ten projects, the majority of which were completed within the past five years. Additionally, to ensure diversity, one supplier was chosen for its long-standing collaboration with the buyer (more than 20 years of collaboration), while the other had a much newer relationship (less than 5 years of collaboration). Finally, the two suppliers were chosen because they deliver equipment which represent a significant CAPEX for the buyer.

3.2. Data Collection and Analysis

The case study in this paper was carried out in two phases. The first phase was conducted to establish a description of the specific shared architecture for the selected scope according to the proposed framework for a shared architecture description. To do this, activities were organised to populate the proposed framework description in Section 4. An overview of activities can be found in

Table 1. Overview of data collection.

Job Position	Method	Purpose	Duration
Buyer, Category manager 1	Interviews	Preparation and context. Understanding past tender material, financial data, and system design.	2 h
Buyer, Category director 1	Interview		1 h
Buyer, Senior Engineer 1	Interviews		3 h
Buyer, Department manager 1	Interviews		3 h
Buyer, Category manager 1	Meetings	Introduction to concept of shared architecture—Supplier A.	2 h
Buyer, Department manager 1
Supplier A, Senior Engineer 1
Supplier A, Project Manager 1
Supplier A, Project Manager 2
Buyer, Category manager 1	Meetings	Introduction to concept of shared architecture—Supplier B.	2 h
Buyer, Department manager 1
Supplier B, Senior Engineer 1
Supplier B, Project Manager 1
Supplier B, Chief Operating Officer 1
Buyer, Category manager 1	Workshop	Analysing buyer and supplier cost/time drivers, delivery process, and identifying improvement/alignment areas—Supplier A.	4.5 h
Buyer, Senior Engineer 1
Buyer, Department manager 1
Supplier A, Senior Engineer 1
Supplier A, Project Manager 1
Supplier A, Project Manager 2
Buyer, Category manager 1	Workshop	Analysing buyer and supplier cost/time drivers, delivery process, and identifying improvement/alignment areas—Supplier B.	4.5 h
Buyer, Senior Engineer 1
Buyer, Department manager 1
Supplier B, Senior Engineer 1
Supplier B, Project Manager 1
Supplier B, Chief Operating Officer 1
Buyer, Category manager 1	Workshop	Investigating operability and feasibility of the shared architecture—Supplier B.	4.5 h
Buyer, Senior Engineer 1
Buyer, Department manager 1
Supplier A, Senior Engineer 1
Supplier A, Project Manager 1
Supplier A, Project Manager 2
Buyer, Category manager 1	Workshop	Investigating operability and feasibility of the shared architecture—Supplier B.	4.5 h
Buyer, Senior Engineer 1
Buyer, Department manager 1
Supplier B, Senior Engineer 1
Supplier B, Project Manager 1
Supplier B, Chief Operating Officer 1
Buyer, Category manager 1	Interviews	Discuss/observe adoption of shared architecture.	2 h
Buyer, Senior Engineer 1	Interview		1 h
Buyer, Department manager 1	Interviews		4 h

. About 10 interviews were conducted with senior engineers and the category manager from the procurement team. The interviews were conducted over a one-month period. These interviews provided preparation and context for a set of following workshops. The preparation included looking into financial data of past projects as well as the overall system design and details of the equipment.

Two meetings and a workshop with each supplier were conducted over a 6-month period (primarily due to availability of the suppliers) with the goal of analysing and synthesising how a shared architecture could be achieved with the buyer and each of the suppliers. The insights gathered from the workshops were used to conceive the description of such a shared architecture. The workshops were organised around understanding the architecture of buyer and supplier according to the descriptions in Section 4. While the researchers helped facilitate the work, they did not actively participate in identifying the desired shared architecture.

The goal of the second phase was to financially quantify the impact of the identified architecture. This was performed through comparative analysis of financial data by the supplier and by the buyer independently.

For the buyer comparison, full access to historic (five years back) project documentation was granted to analyse and identify projects similar on scope type, scope size, and market. This included analysing, quotes, CAD models, requirement specifications, tender documentation, and purchase orders from the company’s enterprise resource planning (ERP) system. The quantification of the impact of the architecture was finally estimated as the relative difference in the final billed cost of the supplier for two comparable projects—one before the architecture was established and one after. To calculate the relative difference, the equation shown below, Equation (1), was used, where $Cos{t}_{project A}$ and $Cos{t}_{project B}$ are the final billed cost from the supplier for two comparable projects (A and B) as indicated in the company’s ERP system for projects:

$$Relative differenc{e}_{Buyer}={\displaystyle \frac{Cos{t}_{project A}}{Cos{t}_{project B}}}·100\%$$

(1)

Subsequently, the relative difference between the projects before and after the architecture was adjusted based on the appropriate Producer Price Index (Eurostat [49]).

The results from the buyer assessment were contrasted with a similar assessment from the supplier; however, instead of the actual billed cost, the assessment from the supplier was based on budgeted costs for the same project. To facilitate this assessment, a follow-up workshop with each supplier was held. The goal of the follow-up workshop was to facilitate discussions between the buyer and supplier on feasibility aspects of the identified architecture—including understanding which actions were needed to operationalise the initiatives. Knowing the required commitments in detail gave the supplier the confidence to commit the estimated potential saving towards the buyer. To calculate the relative difference, the equation shown below, Equation (2), was used, where ${Budget}_{project A}$ and ${Budget}_{project B}$ are the estimated costs from the supplier for two comparable projects (A and B) as indicated in the supplier’s financial data:

$$Relative differenc{e}_{Supplier}={\displaystyle \frac{{Budget 1}_{project C}}{{Budget 2}_{project C}}}·100\%$$

(2)

3.3. Use of Generative AI

Lastly, generative AI was used for the editing of the manuscript, specifically to adjust grammar, sentence structure and clarity.

4. Proposed Framework

The following section introduces a framework guiding ETO companies in identifying interorganisational sharing of product architectures. The goal of the framework is to support ETO companies in capitalising on efforts put in their product architectures. This is addressed in the framework outlining how three elements of product architectures are used in a shared context. The work presented is synthesised from the state-of-the-art literature on the theory of product architectures [6,13], the theory of technical systems [14], and Early Supplier Involvement—ESI [15,16,17] in addition to the case work undertaken by the authors. This foundational theory is introduced in Section 4.1. as it relates to the topic shared product architectures, where three product architecture elements are introduced. Section 4.2, Section 4.3, Section 4.4 subsequently describes how each of the three product architecture elements can be analysed in a shared context via the framework. A generic example is used throughout Section 4.2, Section 4.3, Section 4.4 to demonstrate the framework. This simplified generic example is used for pedagogical reasons to clearly articulate the framework and avoid confusing the reader with too many technical details. In Section 5 (case outcome), the framework is applied with the details from the real-world case being studied.

4.1. Foundational Theory for the Framework

According to the reviewed literature, product architectures play a critical role in managing product variance [50,51], and there are several key aspects to the concept of product architectures in ETO companies. Product architecture can be viewed as a type of blueprint denoting the rules and structures for how a product should be constructed [52]. The rules of the blueprint define the match between product requirements and the design choices that shape the construction of the product [52,53]. In the context of this paper, three aspects of a product architecture are considered, namely system decomposition, modules and interfaces, and coordinated activities. A harmonised system decomposition is a mechanism that allows large engineering projects to better manage the concurrent engineering between business units [54]. Maintaining standard definitions of systems will help to better manage and avoid mistakes during handovers between, e.g., departments or to avoid misunderstandings between scope split and increase traceability [55]. The concept of aligning key design characteristics in modules and interfaces is needed to help govern the engineering design rules put in place so that a design change in one system does not affect surrounding systems negatively [50]. The transparency in how design change over time propagates across systems, modules, and interfaces is what allows for coordinating activities in an organisation. As demonstrated by Sanchez’ “mirroring” hypothesis [56] a product architecture is reflected, or “mirrored” in organisational arrangements and that the architecture provide a form of embedded coordination for effective collaboration. This coordination of activities enables companies to optimise their work and business processes across, e.g., departments in order to capitalise on their architecture efforts [28]. From a product architecture perspective, these three key aspects form the foundation for the framework presented.

The abovementioned three aspects all play a significant role in the design of a successful product architecture. Nevertheless, research in the field of supply chain management supports that significant benefits can be achieved if suppliers are involved in the product development process as early as possible (Early Supplier Involvement—ESI) [15,16,17]. Combining the theory of ESI and modular architectures would suggest that companies that wish their architecture efforts to be directly financially driven by the cost from their suppliers should consider not only the desired system decomposition of the buyer but also how one can achieve a common system decomposition that is shared across buyer and supplier. Similarly, the modules and interfaces should be used for interorganisational alignment of key design characteristics, not just alignment for the buyer. Finally, the coordinated activities enabled by the system decomposition, modules, and interfaces should be mutually beneficial to both companies and not just for the interest of the buyer. As such, to investigate architectures driven by a positive impact on the financial stream of suppliers, companies must consider these three elements in a shared context.

Based on the three aspects of product architectures (decomposition, modules and interfaces, and coordinated activities) the proposed framework is structured to guide ETO companies in understanding both current challenges and future opportunities within interorganizational sharing of product architectures. The following sections present the developed framework (as depicted in Figure 1) and the concept of sharing an architecture. The framework consists of two major areas:

• Modelling of divided and shared architecture where modules, interfaces, and decomposition are not harmonised and harmonised, respectively, across buyer and supplier.
• Modelling of disjointed and coordinated activities describing the process architecture that is affected by the divided and shared architecture.

The subsequent sections describe how the framework covers each of the three architecture aspects, one at a time. The workflow for utilising the framework has followed the overall steps highlighted in the workflow diagram in Figure 2.

Figure 1. Full framework of shared and divided architecture.

Figure 1. Full framework of shared and divided architecture.

Figure 2. Workflow diagram overviewing the overall process of utilising the framework.

Figure 2. Workflow diagram overviewing the overall process of utilising the framework.

4.2. System Decomposition: Shared Across Organisations

The decomposition of a system into smaller sub-systems is oftentimes used as a method to handle the complexity found in large engineering projects [14]. Decomposition refers to a separation of the constituent objects of the system. The objects are everything contained in the system, such as functions, components, etc., and as such, the objects are instances of something with associated information [57]. The objects can be interpreted from multiple aspects, e.g., function: “Intended purpose or task executed”, component: “Part used as a constituent in an assembly or system”, and location: “Intended or accomplished space”. The creation of the product can also be defined by the aspects along with any interactions that store, transform, or transport materials, information, or energy as processes [57]. Since decomposition can be interpreted from multiple aspects, and since different organisations might be responsible for different aspects of a system, it is only natural that different organisations can have different decompositions of the same system. Therefore, to identify misalignment in this regard, the first area in the framework suggests that buyer and supplier should understand and model their existing system decomposition. This can be performed, e.g., by the modelling principle presented by Mueller et al. [58]. An example of differing decompositions in the context of a buyer supplier architecture is illustrated in the first area of the framework in Figure 3 and described below.

In this example, the ETO buyer has decomposed the system into system 1 (the green and purple squares) and system 2 (the orange square). However, the supplier benefits from viewing the same system from a different perspective. As such, their system decomposition is different and comprises system A (the green square only) and system B (the purple and orange square). This discrepancy in decomposition can lead to in efficiencies through disjointed activities [55]. However, the challenge of such disjointed activities stems not only from the system decomposition but also, as discussed in the next section, from the modules and interfaces of that system.

4.3. Modules and Interfaces: For Interorganisational Alignment of Key Design Characteristics

Modules refer to the actual collections of key functionalities in the system. When modules are intelligently decomposed by key requirements (such as functionality, customer requirements, etc.), then multiple instances of the same module can exist with the potential to be swapped interchangeably without considerable reengineering [50]. Such module swapping can only happen without reengineering when a common interface is present [56]. An interface describes the design of the part of a module that is physically (or non-physically) linked to another module. This is only considered an interface if its design is frozen over time to enable such module swapping. Therefore, the first area in the framework suggests to also model modules and interfaces in the product architecture of the buyer and supplier. This can be achieved, e.g., by the modelling principle presented by Bruun et al. [24]. The role of modules and interfaces can be illustrated in a shared context by contrasting the divided and shared architecture in the previous example, as described below.

Continuing the example in Figure 3, the ETO company has a design upgrade for system 1 planned in one of their next projects. In this case, the company would like to substitute the purple square (1.2) with a new design. The company will then proceed to exchange system 1 in Figure 3 with an alternate instance of that same system 1. System 2 is unchanged by this action since it is decomposed into a separate system. However, due to the difference in decomposition, the supplier will feel the effect of this change differently. In this scenario, the supplier has built the original system A and B before. Now the ETO company tells the supplier that they would like them to build a new version of system 1 and the same original version of system 2. The supplier looks at their own decomposition and comes to the conclusion that since system 1 is new, they assume that their system A has to be a new design. This is because they do not know which squares in the ETO’s system 1 has changed. So even though there was no change to the design of the green square, the supplier will now treat this as a custom order for system A, which will trigger a chain of inefficient activities (these activities are elaborated in the section below). Furthermore, even though the ETO company went through the trouble of ensuring a standard design for system 2 (orange square), they will not reap the effects of that effort in their order at the supplier. This is because system B (which the orange square is a part of) will have to be a new design anyways due to the design upgrade of the purple square.

To summarise, with the differing decomposition, there is no common interface between the systems. As such, (1) the supplier will start a custom design on system A even though it is the same design desired from the buyer, and (2) the buyer has gone through the trouble of standardising system 2, yet they will not reap the benefits since this system has to be delivered custom due to it being part of system B. However, if the two organisations had chosen to mutually align their system decomposition, modules, and interfaces, a greater transparency in reused objects could be achieved. This example is illustrated in Figure 4. Here, the buyer has chosen to decompose their system according to the supplier. This means that in the previous example where there is an update to the purple square, the supplier can now unequivocally see that system A can be reused from the first project. Similarly, the designer at the buyer now knows that if they make an update to the purple square, it will result in a new design for the whole system including the orange square.

Moreover, the potential of greater reuse of objects across organisations will guarantee capitalisation of the efforts put in a product architecture. As will be explained in the following section, Sanchez [59] argues that the architecture efforts only take their true effect once coordinated across the activities of an organisation.

4.4. Coordinated Activities: Consistent Between Organisations

Sanchez [6] maintains that modularity can both be technical and strategic. Strategic modularity ensures that the product decomposition, modules, and interfaces are designed as a matter of strategic intent—not only by what is technically feasible. The strategic intent of the architecture should be to operationally coordinate between product and process architecture. It is only when these dependencies are aligned that one can fully harvest the benefits of product architectures [59]. In the context of ETO companies, many project activities are handled by suppliers due to the scale of projects. Such coordination of activities is consequently necessary to happen across multiple organisations. Accordingly, when the buyer and supplier use different decompositions and unique modules with no interfaces, the strategic intent is not ensured, and the associated activities in the process architecture of the supplier and buyer can become disjointed. Cases have been studied to support how strategical alignment of activities is needed in order to capitalise on technical modularisation. For instance, in a study by Bertram [60], it was shown that for an ETO company, there was no correlation between the profitability of the products they sold and the degree to which the products adhered to technical modular product architecture. Even though the product architecture was modularised according to module drivers for improved profitability [28], only the technical modularisation was followed, and the strategic activities were not changed accordingly to capitalise on the intent. As such, the company did not realise the intended effects despite building the products according to the technical architecture. Therefore, the second area in the framework suggest modelling the process architecture of both buyer and supplier as it relates to the shared product architecture. Such modelling could be achieved, e.g., by the principles presented by Hvam et al. [61]. The role of process architecture can be illustrated in a shared context by continuing with the previous example now described in the following section.

Continuing with the previous example, Figure 5 shows a view of the generic activities covered by a buyer and a supplier. In the case of the divided architecture, several disjointed activities arise when the supplier assumes that system A and B require a custom execution.

Firstly, even though the buyer is reusing some of its designs (the green square), and already has the associated tender material ready, they wait until all detail engineering is completed before they initiate the tender with their tier-one suppliers. This means that once the supplier receives the tender material, they have very little time to generate their quote. Consequently, a less accurate quote is made, which will induce less predictable resource consumption for both the buyer and the supplier.

Secondly, the fact that the supplier assumes that all scope is newly designed means that they have to start their manufacturing engineering process before they can initiate procurement at their sub-suppliers. Ordering from sub-suppliers with a shorter time before project delivery will likely not be advantageous from the position of strategic negotiations with sub-suppliers (as opposed to having more time) [62].

Additionally, with less transparency on which scope is reused, the supplier will have limited opportunity to identify best practices for executing the order, e.g., best practices in fabrication. This would ultimately lead to greater resource consumption in this part of the supplier delivery [63]. Finally, in all the abovementioned activities, the buyer and supplier should expect there to be more clarifications between the two actors due to the misalignment (as identified by Haug [12]).

It is clear that there is a divided architecture in the example above. The use of decomposition, modules, and interfaces is not coordinated across the two organisations. However, there is a potential to align and share the architecture between the buyer and supplier. Strategically aligning the decomposition, modules, and interfaces would allow the actors to coordinate their activities for mutual benefit. Figure 1 illustrates the full comparison to such a shared architecture and its coordinated activities. In the example of the shared architecture, the buyer and supplier have decided to align their decomposition. Aligning this enables the actors to maintain a stable interface, even in the case that the buyer develops a design upgrade for the purple square. Because of the interface, there is greater transparency for the supplier, who can clearly see that they can reuse the green square. This alignment on the reuse of sub-systems brings the potential to align activities for a more efficient execution of the project.

Firstly, because the buyer has aligned the decomposition, modules, and interfaces, and due to the insights about the supplier’s activities, it is now evident that the green square can beneficially be reused for the new project. To realise the benefits of reusing the scope, the buyer will now do a partial tendering early in the process before they have completed the design updates to the orange square. This way, the supplier receives the tender material earlier, allowing them more time to generate this part of the quote. Consequently, a more accurate quote is made, which will provide more predictable resource consumption for both the buyer and the supplier.

Secondly, now that the supplier knows that a certain scope can be reused, it means that they can start their procurement at their sub-suppliers earlier, for instance, on long lead-time components. As such, they can expect more advantageous negotiations with their sub-suppliers. Additionally, the supplier will have a better opportunity to identify best practices for executing the order, e.g., best practices in fabrication. This would ultimately lead to more optimised resource consumption in this part of the supplier delivery. Finally, in all the abovementioned activities, the buyer and supplier should expect fewer clarifications between the two actors due to a misalignment.

To summarise, ETO companies are outsourcing project scope increasingly, and if the coordination of financially driven activities is considered the desired mechanism for capitalising on product architectures, ETO companies will need to shift their focus more onto the activities of their suppliers. To aid companies in this, a framework has been developed to describe how ETO buyers can facilitate such architecture sharing. The framework is structured by considering architecture sharing in three aspects and the interplay between them:

• Describing how the use of system decomposition can be shared across buyer and supplier.
• Describing how the module and interfaces can be driven by aligning key design characteristics inter-organisationally.
• Describing how the activities of both organisations can be kept consistent and mutually beneficial in order to facilitate the behavioural change that can be capitalised through the architecture.

By investigating holistically which activities should be coordinated across buyer and supplier, and their relation to a shared use of system decomposition, modules, and interfaces, ETO companies can explore ways of capitalising on product architectures through a financial stream relevant for low-volume, low-explicit reuse companies. In the following section, the effects of such architecture sharing are demonstrated and financially quantified through a case study.

5. Case Outcome

This section describes a case company establishing a shared architecture. First, the differences in their divided product architectures between the two organisations are described. Following that, insights are presented about how architecture discrepancy impacts the activities of the supplier. Finally, the identified shared architecture is described along with the induced improvement principles for the two organisations. A quantitative financial estimate of the improvement principles is also shared.

5.1. System Description and Decomposition

For the case study, an equipment system for storing, processing, and transferring liquids was chosen. Due to confidentiality, the following system description and depiction is simplified to generic pumps and tanks. The case company (the buyer) primarily does the functional design of the system, and a tier-one supplier delivers detail engineering and fabrication of pre-assembled units and piping. The supplier does the detail engineering and CAD design in-house. For some of the scope, they do procurement of components in-house, such as certain instrumentation from Original Equipment Manufacturers (OEMs) (see example of scope split in Figure 6). Similarly for some scope, fabrication is also performed at an in-house workshop. Other scope, for instance, tanks for storing liquids, are bought through sub-suppliers who will do their own procurement of raw materials and have their own fabrication workshop, etc. An overview of the buyer’s activities can be found at the bottom of Figure 7.

Following the buyer’s architecture, the system illustrated at the top of Figure 7 comprises two sub-systems. Functional system 1 includes a small tank for buffering and a pump for distribution. Functional system 2 comprises a storage tank followed by a pump for distribution, followed by a pressure vessel since the pump is frequency driven. The main principle for decomposing the system for the buyer is by means of functional sub-systems. Each Piping and Instrumentation Diagram (P&ID) covers a given function and can be mixed and matched with other P&IDs/functions. As such, it does not impact the design of functional system 1, whether the system includes the functional system 2 or not.

Both organisations (buyer and tier-one supplier) have their product architecture decomposed into a set of sub-systems. But where the product architecture for the buyer is segmented into functional sub-systems (as described above), the supplier has chosen a different decomposition. The supplier takes the functional design and turns it into a physical design and subsequently builds it in the real world in the form of physical units. As indicated at the top right of Figure 7, the supplier has segmented the system into physical sub-system A and B. System A comprises both the tank and pump of functional system 1 as well as the pump and pressure vessel of system 2. According to the supplier, assembling the constituents of sub-system A on a single shared frame is generally seen as a best practice for time and cost efficiency. While the buffer tank of system 1 is small enough to be mounted on the shared frame of system A, the storage tank of system 2 is decomposed into a separate system due to its size. Separate structural calculations are made for this tank to, for instance, make sure it can withstand the wind pressure it is being exposed to when placed outside. With the system decomposed into physical system A and B as illustrated in Figure 7, the supplier can mix and match the two physical systems. As such, from the supplier’s perspective, it does not impact the design of physical system 1 if the design of physical system 2 changes.

5.2. Architecture Impact on System Delivery Process

The discrepancy between the two architectures (functional and physical) had a negative impact on several of the supplier’s activities in this case study. This is evident when considering the delivery process across multiple projects as illustrated in the following example.

In a scenario where the supplier is delivering the same type of system (the one illustrated in Figure 7) to the buyer the second time, you would expect the second project to have some kind of repetition effect on the sub-systems that are reused. However, the findings in the case study revealed that even though some sub-systems are reused, the entire scope is treated by the supplier as if it were 100% new. As such, the repetition effect is very limited. The problems preventing the repetition effect are depicted in the following paragraphs along with Figure 8.

When project number two is being quoted, the buyer will have design changes to some sub-systems and no changes to others. In this case, the buyer would request engineering and fabrication of a “standard” functional system 1 (i.e., no changes between projects) and a modified functional system 2 with a different tank design. From this scenario, two overall challenges occur. (1) On the buyer’s side, when they have changes to functional system 2, they decide to wait with the entire tender until everything is ready; even though the tender material for functional system 1 is technically ready. (2) On the supplier’s side, when they finally receive the tender material, they can only know whether a full P&ID is modified or not. So, they will only see that functional system 2 is modified and not which parts. Since functional system 2 is part of both physical system A and B, the supplier then has to treat the tender as if all of the scope is new and unknown.

When the supplier works with the delivery under these assumptions, it negatively impacts them in several ways, as indicated on the lower part of Figure 8:

• When the supplier anticipates that they have to start from scratch on system A, they cannot look up which resources and how many were needed the last time they delivered a similar system. (In this scenario, only the tank in functional system 2 was changed, the pump and pressure vessel specs remained the same.) The fact that they cannot learn from previous resource-use means that they have to guess which resources to commit and therefore are forced to overestimate (e.g., materials, people, services, etc.). This involves spending time to get familiar with the system and conducting a quantity take-off for the cost estimate. In this case, the supplier was counting flanges and fittings on the P&IDs to estimate materials and fitter hours in their workshop. Overcommitting the resources in the estimate led to a quote that was higher than it needed to be. Practically speaking, when such significant time is spent obtaining these estimates, it takes time away from other activities.
• When quantity take-offs are what they spend their time on, the supplier does not have the time to ask different sub-suppliers to analyse which are better options for the project circumstances. For instance, if the project is cross-Atlantic, there would be no time to ask multiple local sub-suppliers for quotes for the large tank and compare those with the increased shipping costs of procuring it from a local sub-supplier and shipping it overseas.
• Similarly, they do not know the sub-systems well enough to identify which components they should prioritise procurement of due to long lead times. As an example, generally speaking, the tanks are a long lead-time item procured from a sub-supplier. With this in mind, it was identified that for units that combine both tanks as well as pumps, the work on such units could only commence once the tank had been supplied. This meant that not getting the tank order in early at the sub-supplier was halting the remaining work on the “combined units” such as system A. Again, even though only the tank design of functional system 2 was changed, and nothing on system A, the supplier still had to anticipate that system A was unique and therefore did not know the equipment well enough to commit early to their sub-suppliers.
• Additionally, when the people executing the project begin their work, the supplier is not be able to look to reuse best-solution principles for assembly from previous projects, since they again assume that all parts of the scope are new and unique. This meant that the number of fitter hours spent in the workshop was higher than it needed to be.
• Finally, a general comment was made that this discrepancy was causing the need for more clarifications during the delivery process between the buyer and supplier.

5.3. Shared Architecture Improvement Principles

To address the discrepancy in architectures, the two organisations jointly created a shared architecture structuring the design specifications. The founding concept for the shared architecture is illustrated in Figure 9. The main idea behind the concept is to establish a system decomposition across the functional domain and the physical domain. Practically speaking, this meant that the functional design described in P&IDs was further decomposed into P&ID modules with alphanumerical values according to what scope was part of a physical unit. The example in Figure 9 shows that functional system 2 is divided into two P&ID modules, 2A and 2B. The numerical value refers to the functional decomposition, while the alphabetical value refers to the physical decomposition.

The common language of these P&ID modules enables two main areas of improvement: (1) it allows the two organisations to reconcile which parts of the scope can be reused across projects.

Coincidingly, the buyer still maintains their internal functional decomposition since the overall “P&ID assemblies” remain with the same functional decomposition; (2) it allows the buyer to partially releases its P&ID so that tendering of the reused scope can start earlier. This has many positive effects on the scope of the supplier (as indicated in Figure 9):

• Due to the increased transparency in the tender material, the supplier can now utilise historical data for estimating the quantity and type of resources needed for a project. According to the supplier, using actual consumption data would lead to less over-commitment of materials and services and thus a more competitive quote for the buyer. For the supplier, on the one hand, the over-commitment of resources has typically had them say no to other projects only to find out that they did in fact have time in the end. Therefore, avoiding over-commitment and accepting more projects would increase their own utilisation, leading to increases in the supplier’s revenue. On the other hand, avoiding a too-low estimate means that they would avoid having to pay overtime to meet the project deadline, thus leading to lower internal costs for the supplier.
• When using historical data, the supplier also has to spend less time during the quotation process making the estimate, which frees up time for other strategic activities. It means that the supplier has time to ask different sub-suppliers to analyse which are better options for the project circumstances.
• Likewise, the fact that sub-systems are now known means, the supplier can now begin procurement with a long lead-time scope as one of the very first things in the delivery process. This in turn means that combined units are not getting unnecessarily halted.
• Furthermore, the supplier argues that best-solution principles for assembly from previous projects would be easier to identify, thus reducing the number of fitter hours spent in the workshop.
• Lastly, the supplier claims that there would be fewer clarifications from the buyer during the delivery process.

5.4. Shared Architecture Financial Effect of Improvement Principles

The results presented above illustrate how companies can explore efficiency improvements by better understanding how architecture can be mutually shared between buyer and supplier. What is more, this finding supports that the desired benefits can be achieved without establishing the traditional high-detail module descriptions demanded by, e.g., consumer products, meaning that the buyer does not need to have a finished pump unit design before the supplier reduces costs by ordering long lead-time tanks earlier. Looking to these cost-saving potentials, the financial effect of the described shared architecture was investigated through the two metrics described in the methodology section. The two metrics are summarized in

Table 2. Overview of financial impact.

Metric	Equation	Calculation	Financial Impact
$Relative differenc{e}_{Supplier}$	Equation (2)	${\displaystyle \frac{{New Budget Workshop}_{project C}}{Old Budget Worksho{p}_{project C}}}·100\%·55\%$	~10% reduction in total cost of the project
$Relative differenc{e}_{Buyer}$	Equation (1)	${\displaystyle \frac{Cos{t}_{project A}}{Cos{t}_{project B}}}·100\%·Price Index Factor$	~35% reduction in total cost of the project

and elaborated below.

To calculate the $Relative differenc{e}_{Supplier}$, the supplier investigated a recent project completed with the buyer. For this project, the supplier made a new budget for the project assuming the effects described in Section 5.3. This budget was compared to the original budget for the same project which was made by the old way of estimating resources using quantity take-offs and without the other positive effects described in Section 5.3. The difference between the quoted price and the price based on the original historical data was about 18% of the total costs from the point of receiving the order until the order left their workshop (i.e., excluding installation and commissioning costs—referred to as $Budget Workshop$). Since this part of the scope on average comprises about 55% of the total costs, the savings on the total cost computes to ~10%.

The $Relative differenc{e}_{Buyer}$ was calculated after the shared architecture was established. After the architecture had been established, this metric compared the first project the companies did together to a previous project of nearly identical scope (i.e., ~100% scope commonality). The old project was conducted in 2019 using the old, divided architecture. Furthermore, the scope of the project was a custom design being built for the first time. The second project was conducted in 2023 with the new shared architecture identifying the commonality with the 2019 project, thus enabling the five improvement potentials outlined in Section 5.3. After adjusting for inflation of material and instrumentation prices (as outlined in Section 3.2), the ETO company reported having paid ~35% less for the project conducted in 2023 compared to the one conducted in 2019.

Overall, both metrics support a positive financial effect of establishing a shared architecture between ETO buyer and its suppliers. The results of the case study would support that ETO buyers can have between 10% and 35% cost-saving potential.

5.5. Comparison of Results to Previous Litterature

The mechanisms behind the cost reductions in this case study are rooted within the concept of how harmonised decomposition, modules and interfaces can allow for optimised and coordinated activities across organisations. These mechanisms are described by the “mirroring” hypothesis first introduced in the work of Sanchez [56]. Looking at recent papers on how modularisation materialises in supplier collaboration, many studies are similarly rooted in Sanchez’ work [56] and crucially find similar significant financial benefits. Most notably, the cost reductions observed in the present study aligns with recent empirical survey evidence on by Salvador et al. [64]. From a macro-quantitative perspective, this study investigates supplier involvement using survey data across 165 projects using hierarchical linear regression. The authors demonstrate that improvements to new product development when supplier integration is pursued can be significantly enhanced when the buyer’s modular design competence is high. The explanatory mechanism of this paper similarly hinges on modular architectures enabling more efficient and effective inter-organisational work. These effects are similarly supported by Ye et al. [65] that extends on the work of Salvador et al. [64] by considering also modularity through multi-skill employees and the effects of increased customer involvement, of which the latter was interestingly observed to weaken the outcomes of new product development.

The study of Takeishi et al. [66] has investigated inter-firm product collaboration in the high-volume industry of the automotive sector. Combining both quantitative survey data and qualitative interviews, the study similarly finds that architectural knowledge is more important than component-specific knowledge for improving conditions for suppliers. However, for innovative projects, both types of knowledge need to be shared and integrated according to the findings. This phenomenon supports the findings in the present study regarding how transparency in modules and interfaces is critical to establish across buyers and suppliers in an environment with high product innovation such as the ETO products. Finally, the survey-based study from Howard and Squire [67] suggest that modularisation requires increased integration and information sharing between buyers and suppliers which contradicts other studies that suggests modularisation leads to more black-box sourcing to keep suppliers at arm’s lengths and reduce dependency. They empirically demonstrate that product modularisation leads to greater buyer–supplier collaboration, but crucially, that this effect is mediated by proper information sharing and alignment on modules and interfaces. These findings support the idea of the present paper that effective modularisation with suppliers necessitates integrating the supplier into design decisions and information flows. It therefore indirectly challenges the idea that modularisation always enables arm’s-length sourcing, instead showing that closer integration can be needed when managing the products investigated in the present paper.

6. Discussion and Conclusions

ETO companies are exploring the use of modular architectures to better manage the challenges from increasing product variety. However, while modular architectures have been studied for benefits such as successfully reducing product variants, there is much less literature on the use of architectures for explicitly financially driven potentials. Only a few scholars have studied product architectures being shared across buyers and suppliers, and they tend to leave out details on how system decompositions, modules, interfaces, and coordinated activities enable benefits for the company and with what financial effect.

As such, this paper has investigated the use of architectures driven by the financial stream of suppliers by developing and testing a framework for interorganisational sharing of architectures across a buyer and its suppliers. The case study found that there was significant financial effect to be gained for the case company by streamlining their procurement process to reduce the project risk and ambiguity for the supplier. By having more transparency in the system decomposition, modules, and interfaces, the supplier was able to have better resource estimations, more competitive procurement with their sub-suppliers, and a faster assembly in their workshop.

6.1. Implications for Research

Building on the existing literature and case work, the developed framework demonstrates three aspects of how ETO buyers can facilitate architecture sharing. The framework (1) describes how the use of system decomposition can be shared across a buyer and its supplier; (2) explores how modules and interfaces can be driven by aligning key design characteristics inter-organisationally; and finally, (3) how the activities of both organisations can be kept consistent and mutually beneficial in order to facilitate the behavioural change that can be capitalised through the architecture. As such, these three aspects of the framework provide relevant details on how shared architectures can bring opportunities that are mutually beneficial to the business of both the buyer and its suppliers. Additionally, the study revealed that the investigated case company experienced between 10% and 35% cost reduction on the scope of their suppliers, thus providing further quantified support to the financial impact of shared architectures. While the previous literature [64,65,66,67] demonstrate that the significance of modular architectures can be harnessed mutually by buyers and suppliers, the present study advances the field by bridging the gap between high-level survey findings and the operational realities of the ETO environment. Earlier research identifies the importance of modular design competences to enhance supplier collaboration; the work of the present study offers a detailed process-oriented framework that shows the mechanisms behind how shared architectures benefit suppliers and buyers and with what financial effect. By providing granular case-based evidence that supports how cost savings are linked to harmonised decomposition, modules, interfaces, and coordinated activities, the present study helps operationalise the work by Sanchez [59] and the “mirroring” hypothesis [56] in practice.

6.2. Implications for Practice

The findings in this paper support the financial stream of suppliers as a compelling stream for driving architecture development in ETO companies. It is detailed that financially driven improvement mechanisms in architecture development can go beyond increasing economies of scale and explicit design reuse. While many companies struggle with successful implementation of modular architectures [68], a clear, quantifiable financial impact from modularisation would support companies with a stronger foundation for overcoming barriers to the change management activity of implementing modular architectures [69]. More specifically, the case found that the improvement areas of supplier resource coordination and scope ambiguity were harvestable already on the second product order from the supplier. Seeing the improvement already on the second order supports that the financial effects of shared architectures can be harvested in the low-volume and low-explicit design reuse environment of the ETO industry.

6.3. Limitations and Future Research

While the estimates of the financial impact were considered in two ways, they were only considered from the buyer’s perspective, and the cost reduction on the supplier’s side could not be reported. While it was generally perceived that both the buyer and the supplier were financially benefiting, it can, strictly speaking, not be ruled out that the supplier passed on the full saving to the buyer only to stay competitive. Knowing, in more detail, the true cost-saving on the supplier side would provide more clarity on the potential financial impact of a shared architecture. Conducting a study with an open book supplier could perhaps provide more details in this regard. Additionally, it should be noted that while the architecture conceptually enabled the collaboration, the buyer and supplier went through several changes to the structuring of their tender timeline along with significant changes to the quotation templates that the buyer demands of their suppliers in order to facilitate the transparency in module reuse. This was required to realise the operationalised benefits in reality and was, strictly speaking, not covered by the framework. This points to one of the limitations of this framework that practical implementation might face additional challenges if they are not fully addressed by the framework. For instance, organisational resistance to change is a common pitfall in architecture implementation (supplier focused or not) due to disrupting routines and roles and therefore will require careful change management and clear communication and commitment to the mutual benefits. Similarly, different suppliers have different capabilities and different ways of working. If attention is not paid to these discrepancies, a situation could easily arise where the architecture is favoured by one supplier and not the others, thereby leading to unfavourable competitive bidding for both buyer and suppliers. Finally, a consequence of different suppliers having different ways of working is also something that can lead to information asymmetry between buyer and suppliers where this could actually lead to more complicated collaboration. Future research should investigate these issues in more depth and explore potential strategies for mitigation such as phased implementation, joint training activities, or enhanced information-sharing-protocols.

Only investigating one case company in the study puts a limitation on the generalisability of the framework, and as such, the findings should be tested in more companies to support their validity. The study also did not cover any of the technical development undertaken to enable the shared architecture. This means that the framework does not, strictly speaking, provide any guidance on how to identify the explicit product decomposition, modules, and interfaces. It could be relevant to explore how the framework could be used in conjunction with existing methodologies for such architecture design. Notably the case company investigated in this paper had already established strong supplier relationships, and therefore, it could be beneficial to investigate how the framework could be used and adapted for companies whose supplier bases are not as established, for instance, with a focus on growth SMEs. Furthermore, while the focus of the paper has been on low-volume ETO companies, the principles of financially driven shared architecture should also be relevant for medium to high production volume companies. While supplier collaboration in this context is perhaps more researched, it could, nevertheless, be interesting to investigate how the principles in the suggested framework could augment the existing methodologies for supplier collaboration of such companies. Finally, the study did not consider the cost of establishing, maintaining, and governing the architecture. Details on this would perhaps provide an even more relevant view for practitioners on the net business impact of establishing shared architectures.