Abstract
This literature-grounded research contributes to a deeper understanding of modularization as a system life cycle management strategy, by providing a comprehensive view of its key barriers, drivers, possible mechanisms of implementation and impact. This comprehensive view, arranged into a decision-making–driven ontology, enables a decision maker to systematically identify modularization implementation opportunities in different industrial and service domains. The proposed ontology transforms modularization into a fully operationalizable strategy and contributes to a paradigm shift in the understanding of modularization, from a pure design option (i.e. modularity) to a fully strategic choice that, by nature, impacts on many of the system’s life cycle phases and involves a number of stakeholders.
Introduction
‘Modularity’ and the process of its implementation (referred to as ‘modularization’ hereinafter) have recently been widely explored by academics; as a couple of paramount examples, it is enough to consider a special issue published on the International Journal of Operations and Production Management in 2010 (‘Modularity: implications for strategy and operations’, in Vol. 30, Issue 1), and still the need for a research agenda, published on the same journal in 2017 (‘Service modularity and architecture – an overview and research agenda’, Brax et al. 1 ). Similarly, there is an increased and continued interest in modularization from practitioners, as a strategy for product life cycle configuration that enables commonality and customization and enhances manufacturing flexibility. Modularization is suited to respond to several emerging needs and opportunities in product manufacturing sector, as well as in other sectors, such as services and industrial plants.
One recent example in the attempt of exploiting the potential benefits of modularization of product manufacturing is Project Ara (details available at the following website: https://en.wikipedia.org/wiki/Project_Ara) by Google. This project employs modularization to reduce waste and increase the product durability by creating completely customizable and reconfigurable smartphones. Another example of modularization is the modular construction strategy adopted to build several liquefied natural gas (LNG) plants in Australia, 2 transferring part of the construction works from the site to more controllable fabrication yards, where a skilled workforce is less expensive and easier to recruit. In the service domain, modularization is an emerging strategy to innovate healthcare delivery, which enables providing more customized care at lower cost and higher quality and safety. 3 Particularly relevant are new home care service models for patients with chronic diseases. 4
Despite its high potential, an exhaustive conceptualization of modularity and modularization and their key dimensions have only been developed rather recently. 5 –7 Starr, 8 who first discussed the application of modularization in production and manufacturing in 1965, 9 in 2010 states that firms’ top management did not fully consider in the past 50 years its strategic implications, due to the lack of a structured taxonomy (i.e. to a broader extent, of an ontology).
To address this knowledge gap, this article puts forward a comprehensive ontology of modularization conceptualized as a system life cycle management strategy, which can be implemented through a structured decision-making process by identifying a comprehensive knowledge base for its key barriers, drivers, possible mechanisms of implementation and impacts, considering that a number of stakeholders may be involved in making these decisions and being affected by them, along the life cycle and, of course, the supply chain(s). The authors, therefore, aim at addressing the following interlinked research questions:
Given the relative abundance of scholarly contributions on ‘modularity’ and ‘modularization’ over the last decades, the article employs a literature review methodology to design a comprehensive ontology of the modularization concept. To this end, the existing modularization definitions were thoroughly reviewed; 15 mechanisms of modularization implementation and more than 280 instances (related to the barriers, drivers and impacts) were identified and categorized based on the findings of the literature review.
The contribution of this research lies in founding a knowledge base for modularization. The article’s findings provide decision makers with a thorough understanding of modularization’s impact on the whole system’s life cycle – so as to make better decisions and better manage the stakeholders involved – as well as to explore its implications.
This article is organized as follows. The next (second) section describes the research methodology and presents a detailed description of the literature review process. With the aim of answering the three above-mentioned RQs, the third and fourth sections are devoted to critically review the state of the art on modularity and modularization concepts and to develop the full ontology of modularization, respectively. In the fifth section, three illustrative examples are reported, covering both the industrial and the service domains to explore the potential of the proposed ontology, with a focus on the relationships between specific modularization mechanisms and their consequences that are related to the whole system’s life cycle. The key findings of the study and conclusions are drawn in the final section.
Methodology
The literature on modularization has developed rather numerous contributions in terms of definitions. These studies have made excellent contributions to clarifying some ambiguities regarding the definition of modularity (and – at a lesser extent – modularization) and its attributes. However, almost all of these studies had a research scope narrowed to specific domains, namely, elements to modularity and similarity of components in a module, 10 analysis of differences and similarities in different interpretations of the concept of product modularity, 11 component-swapping modularity 5 and managing modularity as a design principle of complex systems. 6 This article seeks to build on the findings of this copious body of literature, to harmonize and generalize the existing contributions and to expand the modularization concept throughout the entire system’s life cycle.
For the sake of future usability, the dimensions and the attributes of the proposed ontology of modularization have been defined while maintaining consistency with a well-known ontology-developing environment, namely the Protégé-2000. 12 This allows an ontology to be developed as immediately understandable and reusable by subjects belonging to many different fields. The Protégé-2000 ontology framework consists of three main elements 12 : classes, slots and facets. Classes are the core concepts of the domain of discourse. Each class may include different subclasses; classes and subclasses may have various slots, which describe the attributes and the properties of a class. Lastly, facets describe the features of the value that the slots can take (e.g. value type, allowed values, cardinality, etc.). The focus of this article is mainly on classes and slots.
Literature search and review
In order to ensure the inclusion and review of the most relevant articles without neglecting sectorial/practical articles, the literature search protocol (Figure 1) was based on both the Scopus™ and Google Scholar™ online search engines, selecting only journal articles published in English; no initial exclusion/inclusion criterion related to time span was introduced.
Literature search protocol.
The literature search started by identifying an initial set of keywords derived from a preliminary reading of the seminal/milestone work by Starr in 1965. 9 The initial keywords list was (modular*) AND (decision OR life cycle), and they were used for a search in Article, Abstract and Keywords both in Scopus and Google Scholar; this initial search resulted in 3000+ and 13,000+ records, respectively.
The batches of the first 200 records (sorted out by relevance) for both Scopus and Google Scholar were included for the next step. In fact, 200 records was enough to include the most cited articles and some very recent work as well; a larger batch would have resulted in an inefficient choice, due to the presence of both a snowballing and reverse snowballing process, at a later stage. A check for duplicates resulted in 242 total number of available abstracts. A screening on the 242 abstracts gave, as a result, a batch of 213 potentially pertinent articles.
Thereafter, an iterative process (snowball in terms of references, as well as ‘cited by’ search, two rounds) and a final check hand-search within the top nine recurring journals (i.e. including more than five relevant articles) were performed, starting from 2006; the following journals were selected for the final check: International Journal of Operations and Production Management, CIRP Annals – Manufacturing Technology, International Journal of Production Economics, Strategic Management Journal, IEEE Transactions on Engineering Management, Journal of Operations Management, Journal of Intelligent Manufacturing, Concurrent Engineering – Research and Applications and Journal of Engineering Design. Overall, 51 abstracts were added.
Then, the abstracts of these 51 articles were scrutinized, and 10 clearly out-of-scope articles (i.e. where ‘modularization’ or ‘modularity’ were only incidentally mentioned) were excluded. Based on the accessibility of the full articles of the overall 254 identified abstracts (in some cases, the articles were unavailable, also after contacting the authors) and of the reading of the main text of the available articles, the output of this literature search and review yielded 161 articles identified as relevant to the present research topic, that is, characterized by pertinent main- or side-content throughout the main text. They constituted the basis to answer the three research questions set forth for the study.
The findings of the literature search have been coded into a database. The coding process was performed in a pattern-matching approach, which helped to develop a revised definition of modularization together with its main attributes (i.e. classes).
Ontology design process
The ontology definition started with a bottom-up approach to capture all the possible instances emerging from the literature and then followed a top-down approach to identify the possible implementation mechanisms. A clusterization (of the impacts, only, as the core of a fully operationalizable strategy) was necessary to highlight any deficiency. To decide on the clusterization logic, a twofold way of thinking emerged from the extant generic literature (particularly, in books) in operations and industrial management. First, a clusterization based on the competitive priorities of the firm (e.g. refer to the study by Greasley 13 ). This entails considering firms’ effort to respond efficiently to a changing business environment by developing a competitive advantage, which may be defined as the extent to which a firm is able to create and maintain a defensible position or compared to its competitors. The considered factors were cost, time, quality, service, innovation and flexibility. However, this first logic of clusterization produced a list of impact instances that cannot be allocated in a specific cluster (miscellaneous). So, a complementary approach was adopted following a system life cycle rationale, considering the following phases: Design, Development, Manufacturing, Distribution, Commissioning, Utilization, Reuse, Recycling, Disposal and Strategical (e.g. refer to the study by Sarja 14 ). Even the complementary approach produced a miscellaneous cluster, due to multiple impacts over the phases (for further details, refer to the third section subsequently).
The following step was the effective implementation of the ontology by the allocation of the instances (impacts, barriers and drivers) with their explicit or implicit link with the implementation mechanisms of modularization. Since the number of instances exceeded 280, the illustration of the ontology as the connection between all the instances and mechanism of modularization was not possible using a single (visual) representation. Of course, using the life cycle phases clustering logic, 11 (i.e. the 10 life cycle phases, plus the miscellaneous cluster) ontology tables may be set up to visually represent all the instances in a structured framework which identifies the boundaries of modularization.
The conceptualization of modularization in products and services: A state-of-the-art review
From modularity to modularization
Since Starr introduced the topic of modularity in the academic debate, there have been numerous contributions, initially only related to products, and later on many other subjects. 9 However, 45 years later, again Starr, in 2010, highlights that modularity has not yet reached the top management of companies at a strategic level, maybe due to the lack of a structured taxonomy. 8 Still in high waters? Maybe.
The literature has evolved significantly, as clearly reported by Frandsen. 15 As a remarkable notice within his article, modularity is defined as ‘method of designing a structure to reduce its complexity’; that is, modularity moves from being just the characteristics of a product/service, to a ‘method’; and ‘method’ really is the beginning of an important evolution. This comes after a previous evolution phase, during which the move of modularity’s focus from products to extend to services. There are numerous examples of Service Modularity 1,16 in the paramount special issue published in the International Journal of Operations and Production Management (‘Special Issue: Service modularity and architecture’), but also earlier studies, for example, refer to the study by Vähätalo and Kallio 3 and Lin and Pekkarinen. 17
Are these evolutions enough to step forward and reach the top management of companies at a strategic level?
The authors refer to the work of Frandsen 15 and Piran et al. 7 as the most recent publications devoted to shedding some bright light on the evolution of the topic, and just a quick recap and discussion of some basics on modularity are reported in the following, with the aim of highlighting how relevant the study of (modularity and) modularization still may be.
The basic notion of modular design is decomposing a system into chunks, as expressed by different researchers: ‘Modular design refers to decomposing the complete product into sub-modules that can be easily assembled together […]
18
’ through ‘A modular architecture [that] includes a one-to-one mapping of functional elements in the function structure to the physical components of the product […]’.
19
A generalization of the strict correspondence between physical modules and functions is the notion of ‘loosely coupled’ components, which are well expressed and extensively acknowledged in the literature:
20
Modularity is a special form of design which intentionally creates a high degree of independence or ‘loose coupling’ between component designs by standardizing component interface specifications.
Having outlined the system architecture and established how to shape the relationships between the system’s modules, it is necessary to determine how to obtain a generalized loose coupling between the system’s modules. As suggested by the above-mentioned definition, loose coupling hinges on the existence of interfaces, more specifically, of standardized interfaces. The existence of interfaces characterizes every component of a generic assembly, but only when the component meets a certain level of standardization of its interfaces, it can be considered as a ‘module’. A synthesis of the above-mentioned discussion could be summarized as: Modularity is a very general set of principles for managing complexity. By breaking up a complex system into discrete pieces – which can then communicate with one another only through standardized interfaces within a standardized architecture – one can eliminate what would otherwise be an unmanageable spaghetti tangle of systemic interconnections.
22
Nevertheless, modularizing a system (which is implementing modular characteristics in a product or a service, or in a system in general) does not only affect its constitutive elements, but also influences the way it is designed, developed, produced, marketed, distributed, sold, serviced and eventually disposed of. In other words, it is not possible to define modularity (and modularization) without referring to its implications on the whole system’s life cycle, as argued by Newcomb et al.
23
Modularity is the concept of separating a system into independent parts or modules which can be treated as logical units. The way in which a product is divided into modules has a great effect on the way it is assembled, disassembled, serviced, and retired.
Overall, in the view of the authors, the (r)evolution needed to reach the top management of companies at a strategic level lays here: from a concept to a process, from the properties (characteristics) of a modular system (modularity) to modularization as a management strategy (over a system’s life cycle duration?). Statically understanding ‘where’ and ‘how’/‘what’ 24 to cut is no longer enough; however, it is also necessary knowing ‘why’, ‘when’ and ‘who’? As for ‘who’, both who may/should do this and who is impacted, have to be understood, with significant implications in terms of the life cycle as well as supply chains involved.
The real observed complexity, which has probably hindered top managers from implementing modularization and which is seldom reported in the literature, emerges from many possible angles: – the one of the single product/service and its life cycle; – the one of the flows of goods/services within a supply chain; – the one encompassing not only the product/service offered but also the overall underlying and interacting systems; and – the one of the life cycle of the above-mentioned systems.
These angles are still very hard to be captured, based on the extant literature; therefore, the challenge is to widen our approach, moving from modularity (alone) to cover the entire process of its implementation (modularization), together with antecedents and effects. It corresponds to embracing a wider perspective to demonstrate how modularization can address different technical, managerial and strategic needs and priorities.
Implementing modularization as a system’s life cycle management strategy
This paragraph is specifically aimed at answering RQ1 (‘What are the constituents of the ontology of modularization as a system life cycle management strategy?’). Modularization, by definition, is an approach for systems configuration, thereby, it has to be embedded in a structured decision-making process. Modularization is considered as a strategy that drives the system away from integral architectures. 25 –27 Once the decision is made to modularize, then the second-level problem becomes determining the best system breakdown.
The second crucial aspect is the fact that modularization impacts the entire system’s life cycle. While the decision of whether to use modularization – and how to use it – is generally limited to the first phases of the life cycle, a generic system may be exposed to the modularization effects throughout its life cycle, 28 a dimension which is not fully tackled by previous definitions.
Three main modularization implementation aspects emerged from analysing the available definitions in the literature. Identifying these aspects helped in developing a comprehensive conceptualization of modularization: – architecture breakdown; – existence of interfaces; and – use of standards.
The architecture breakdown has to be interpreted not only as a physical decomposition of the system’s structure, 29 but also as a functional decoupling between the different modules. 1,30 Architecture breakdown and functional decoupling, which are usually related to the context of ‘products’, can also be applied to other areas (e.g. Lewis 31 provides a general definition concerning the modular fabrication of onshore and offshore industrial plants). Sako 32 applies the architecture breakdown concept to organizational design, showing the analogies between product and organization architectures, whereas Sanchez 33 explains product and process architecture decomposition analogies, in which both are characterized by functional components and interactions. Voss and Hsuan introduced service architecture, in comparison with product architecture; in particular, they set it within the industrial context and then expand the concept to the supply chain level. 34 Despite its apparent benefits, Rajahonka found that modularization implementation in the service domain can face many challenges, as services, in reality, are difficult to separate. Service modularization, therefore, becomes more complicated when compared to product modularization. 35
The existence of interfaces represents a major concern in system modularity and most references of this article insist on their role in the tightness/looseness of coupling the modules, which was first introduced in the modularization literature by Sanchez. 36 The interfaces are considered connection nodes enabling interaction among the system’s various subsystems/modules (in terms of materials, information or energy). Jahre and Fabbe-Costes shed light on the inherent link between product and organizational modularity, and how both of them are related to the use of interfaces and standards. 37
The use of standards surfaces mainly as a matter of leveraging modularity to increase commonality, compatibility and interchangeability (the latter two relate to the existence of interfaces) in some phases of the system’s life cycle:
Commonality, which relates to the existence of common components among a portfolio of products/systems/services and which is highly correlated with the concept of product family, has been extended by many researchers
38
–41
; these authors highlight that commonality facilitates supplier management, connected with the ‘component sourcing’ theme.
38
Compatibility, which relates to developing multiple products/systems/services simultaneously at the possible lowest cost, it is mostly identified in the literature by platform design in a context of highly competitive product markets.
42
Another relevant example by Martin and Ishii allude to platform design as the best way to have fast product development, and develop architectures that may enable producers to ‘reduce future design costs and efforts’.
21
Interchangeability, which relates to the possibility of substituting a component/module of a product/system/service so as to create products/systems/services variations with different functionalities or performance levels, is a very well-developed concept in the product context and closely related to the topic of product flexibility. Duray et al. have developed this concept with respect to the mass customization context, referring to this property as a way ‘to achieve the low cost and consistent quality associated with repetitive manufacturing’,
43
related it to the combinatorial problem, which is strictly connected to the interface definition.
38
It is worth noting that the standardization of modules is not a prerequisite for achieving system modularity per se (instead, standardization of interfaces is a key requirement of modularity). However, from a modularization perspective – that is, looking at system modularity as a life cycle management strategy – undoubtedly some of the potential positive impacts of modularization on different phases of the life cycle are clearly connected to some degrees of commonality, compatibility and interchangeability of modules.
In the light of the above-mentioned discussion, modularization, as a system’s life cycle management strategy, can be conceptualized (i.e. all of the constituents as in RQ1 are highlighted) as ‘the configuration of a socio-technical system, aiming at delivering either a product or a service, through its physical and/or organizational architecture breakdown into functional subsystems and/or processes, which are interfaced to operate together as a whole, and designed to grant higher levels of commonality, compatibility and interchangeability throughout the system’s life cycle’. Consequently, both the justification and the achievement of modularization objectives should arise from a life cycle–oriented decision-making process.
An ontology of modularization
To define a modularization ontology, each of the 161 articles mentioned in the state-of-the-art review section was coded. This step of the literature review process was carried out trying to minimize any subjective interpretation from the research team: at least two researchers worked together on every task; in case of contrasting opinions, the third or the fourth researcher was involved to solve the doubt. Only explicit or clear – even when partially implicit, in terms of wording – content was coded. The coding encompassed multiple spreadsheets interrelated. From the reading of each article (a row), a number of ‘new’ columns (the instances, in four separate sheets for impact, barriers, drivers and mechanisms) were created and checked or just checked when already existing. Whenever an impact, barrier or driver was identified in a article, its link with the mechanisms was recorded in a separate spreadsheet, by checking the intersection ‘impact, barrier or driver’ versus ‘mechanism’ as a whole and versus the three main modularization implementation aspects mentioned earlier (namely, Architecture breakdown, Existence of interfaces and Use of standards) with the name of the article itself. In addition, the explicit link of every impact instance to both the competitive priorities and the system life cycle phases was reported in a separate sheet, by checking the intersection ‘impact’ versus both ‘competitive priorities’ and ‘life cycle phases’ with the name of the article itself.
The description of every instance was prepared in separate sheets, so as to be revised/refined, thanks to further readings.
In some cases, very similar or identical instances were expressed using different terminologies in different literature sources: in these cases, the corresponding instances were incorporated in the same instance only if the meaning intended by the authors of the reviewed article was explicitly the same. In case the meaning was not the same, two different instances were created to avoid any ambiguity. One overall iteration was enough to converge to the final outcome without ambiguity. The literature review yielded the identification of 186 impacts, 58 drivers, 43 barriers and 15 mechanisms (the so-called instances as far as ontologies are concerned) that represent the main support for practitioners to implement modularization. In order to fully implement the ontology, the identified impact, barriers and drivers (i.e. instances) have been linked to the modularization mechanisms, during the coding process.
Modularization impacts, barriers and drivers
In Tables 1, 4 and 5, the lists of the top 20 impacts, barriers and drivers (instances) are reported, in terms of number of occurrences in the reviewed literature (right columns); of course, the number of citations in literature does not point out the strength of the instances as the most affecting or the most enabling. Rather, it highlights the focus of research on some topics, which may often depend on their relevance (in some cases, even the strength of the instances as the most affecting or the most enabling) and complexity.
List of the top 20 modularization impacts (instances) and the corresponding number of occurrences in the reviewed literature (the whole table is available under request).
In Tables 2 and 3, a clusterization of the top three impacts is reported, based on the competitive priorities (Table 2) and on the system life cycle phases (Table 3); as for the coding, the authors report that the most recurrent implicit (yet clear) content is the one related to the strategic phase. Being an article with the angle of a decision maker (typically driven by targets), the discussion focuses more on the impacts than on the barriers and the drivers.
List of the top three modularization impacts (instances) for each competitive priority and the corresponding number of occurrences in the reviewed literature (the whole table is available under request).
List of the top three modularization impacts (instances) for each system life cycle phase and the corresponding number of occurrences in the reviewed literature (the whole table is available under request).
Tables 1 to 3 support the answer to RQ2 (‘What is the potential impact of modularization throughout the system life cycle?’), while Tables 4 and 5 support the answer to RQ3 (‘What are the implementation mechanisms, the drivers and the barriers of modularization, and how they influence its impact on the whole system’s life cycle?’), excluding ‘mechanisms’.
List of the top 20 modularization drivers (instances) and the corresponding number of occurrences in the reviewed literature (the whole table is available under request).
List of the top 20 modularization barriers (instances) and the corresponding number of occurrences in the reviewed literature (the whole table is available under request).
With reference to Table 1, as for the impact instances, among the most recurrent enabling of system variety is the most cited, followed by reduction of production cost for both products and services and enabling of reuse. What is immediately plain is that the topic is broad in terms of facets, implications and literature streams. Enabling of system variety has to do with both the features of modularity of a system and, even more important, with an overall strategic direction for a company; this very preliminary comment matches with the need of considering both the operational and the strategic sides of an overall system life cycle (as in Table 2). On the other hand, reduction of production cost has to do with one of the competitive priorities of a company, which justifies the need for a clusterization of the impacts based on those priorities (as in Table 3), not only for products but also for services. As a matter of fact, the reviewed literature almost equally deals with both products and services; moreover, if it is clear that the overall approach is (based on deductive reasoning) perfectly sensible with both, (it was also clear when scrutinizing the articles that a vast majority of instances is identically valid for both). Finally, enabling of reuse reinforces the relevance of the whole system life cycle view and of the potential stakeholders of the entire modularization process; in this peculiar case, a whole supply chain (the reverse supply chain) may potentially be impacted by someone else decisions.
Table 2 reports the list of the top three modularization impacts and the corresponding number of occurrences in the reviewed literature (the whole table is available under request). The occurrences have been clustered based on a set of traditional competitive priorities (cost, time, quality, after-sales service, flexibility, innovation), which was enabled by the coding process described in the ‘Methodology section’. In Table 2, ‘1’ means that modularization impacts on the specific competitive priority (in column); a set of six ‘pure’ clusters have been identified, in which modularization impacts only on the specific competitive priority, plus three clusters (namely, cost and time, cost and quality and service and flexibility), in which modularization impacts on two of the competitive priorities. The total number of impact instances on every specific competitive priority is reported in the column ‘TOT INST.’, which corresponds to the ‘total number of instances’, and highlights the relevance (in literature) of Cost (43 + 15 + 6), Time (19 + 15) and (at a lesser extent) Flexibility (17 + 2), if compared to the rest.
Besides these nine clusters, 22 instances were coded to have multiple impacts over the competitive priorities, which overcomplicates any analysis and interpretation. A couple of paramount examples are ‘Enabling of economies of learning’ (73 occurrences in literature), described in the literature to be impacting on Cost, Time and Quality, and ‘Enabling of lean thinking’ (59 occurrences in literature), described in literature to be impacting on Cost, Time, Quality, Service and Flexibility. The overall resulting impact on the competitive priorities is then reported in the row ‘OVERALL (144 instances)’ of Table 2, based on the nine clusters plus the 22 instances mentioned earlier, which confirms the relevance of Cost and Time over the rest (followed by Flexibility and Quality).
Last but not least, 42 instances have been coded not to have any explicit or clear (yet implicit) impact on the traditional competitive priorities. The paramount and most recurring example is ‘Reduction of overall complexity’ (57 occurrences in literature), which is something that cannot be fully explained by means of this clusterization approach.
In the light of the above, a system’s life cycle view has been adopted to further understand ‘where’ the impact of modularization lays (and, as an implicit consequence, ‘who’ is impacted, also at a supply chain level), to further address RQ2.
In a similar extent to what is indicated in Table 2, Table 3 also reports the list of the top three modularization impacts, clustered based on the system life cycle phases (namely, Strategical, Design, Development, Manufacturing, Distribution, Commissioning, Utilization, Reuse, Recycling, Disposal). In this analysis, the authors report a huge number of instances having multiple impacts (125, as a paramount example, ‘enabling of system variety’, which spans from the strategic level to the development, manufacturing and even further along the life cycle), if compared to the number of instances belonging to ‘pure’ clusters (61, as in Table 3): hence, the row ‘OVERALL (186 instances)’ is even more significant, highlighting that the impact of modularization is really dispersed/manifold, even encompassing the strategic level, and that – as a consequence – a support (e.g. in the shape of an ontology) for a proper decision-making is necessary.
As for the most recurring drivers and barriers and the related RQ3, hugely different issues are taken into account (involving many different stakeholders as well), such as (Tables 4 and 5): lack of resources in the development phase – but not limited to – both financial and of any other kind (‘scarce availability of resources for product/service development’ and ‘lack of financial resources to cover initial higher costs’); internal and external turbulent/dynamic context (‘High frequency of radical innovations (in the product/service architecture)’, ‘Heterogeneous and rapidly changing demand’ and ‘Technological complexity and uncertainty’); supply chain situations (‘communication, coordination and information sharing between stakeholders’) and so on, when going through the lists of drivers and barriers. Overall, the wideness of modularization in terms of antecedents and effects comes to the surface, going by far beyond the relatively simple anatomy of modularity, which explains why the support in decision-making is needed to manage such complexity, at both tactical and strategic levels.
Modularization mechanisms
A mechanism is defined in this article as a combination of elementary interventions in at least one of the three implementation dimensions (discussed in ‘Implementing modularization as a system’s life cycle management strategy’ section) of architecture breakdown, interfaces and standardization. Table 6 synthesizes the descriptions of the 15 implementation mechanisms identified in the literature (‘module design’, ‘module standardization’ and ‘interface design’ being the basic ones), specifying the implementation dimensions associated with each of them. Again, as in ‘Modularization impacts, barriers and drivers’ section, the reviewed literature almost equally deals with both products and services; thus, also the majority of the mechanisms are identically valid for both.
List of identified modularization mechanisms, with their implementation dimensions.
Even though the descriptions of implementation mechanisms are literature-grounded (in the following), they also maintain a great degree of generalization to allow the identification of domain-independent mechanisms – so as to be usable for identifying modularization opportunities in many different possible research/industrial/service fields.
The mechanism module design relates to the modular architecture of the system, in which the modules are not necessarily physically separable throughout the system’s life cycle. 19,32 –34 Module standardization mechanism refers to commonality, compatibility and interchangeability of modules. 10,21,27,38,40 –43 Interface design deals with how different modules interact. 20,28,36 System’s physical decomposition is a mechanism concerned with how an entire system/element/entity could be decomposed into individual modules, while modules maintain their physical separability. 23,44 –46 System’s functional decoupling mechanism deals with the isolation of the system’s functions into different modules, in that case, the communication between different modules is ensured by proper module interfaces. 5,20,28,30,39,47 –50 Bus architecture is a mechanism entailing configuring the system modules in a series supported by common base. 43,51 Minimize inter-module interactions is an approach for designing the system while minimizing the physical, functional and information exchanges among different modules. 10,52 –54 Cellular Configuration of the design functions or production processes of the modular systems (similar to plant design); each cell develops or produces a specific module or a family of modules. 55 Modular consortium identifies the ‘integrating’ organizational function, which appoints the organizational functions of designing and realizing different modules to different members of the consortium. This can be implemented through various intra- and inter-organizational models. For example, in a consortium, subcontractors are assigned to design and to the realization of different modules. They usually operate in the same physical environment that is provided by the system integrator, which is responsible for the entire system’s performance. 56 –58 Module sharing involves sharing of two or more modules by two or more systems, even those belonging to different system families. 43,44,51 Module swapping is a configuration mechanism of two or more alternative modules that can be paired with a base that creates different system variants within a certain system family. 38,43,44,51 Sectional modularity deals with arranging similar standards and elemental modules into a single pattern. 10,19,43 Interface standardization limits the ways in which modules interact to a few alternatives. Standardization may cover both physical (e.g. shape) and functional (e.g. data coding) logic. 10,21,27,38,40–43,51 Platform design involves designing different systems that share identical core of subsystems and/or components and/or processes. 21,30,36,40,42,52,46,59 –63 Design for postponement is a mechanism of production process system life cycle, it deals with production process and order management cycle modularization (standardization and interfaces), it enables the postponement of the system’s final assembly after receiving the customer order. 10,19,27,29,39,55,64 –66
Every implementation mechanism has to involve instances from the architecture breakdown of the system, the standardization of modules and the configuration of interfaces (i.e. the three pillars). Thus, each instance of the Implementation Mechanisms class should be a result of a combination of at least one instance from the three implementation dimensions. For example, with reference to the instances listed in Table 6, a modularization Implementation Mechanism could result from a physical decomposition of the system combined with interface standardization. Thus, a simple decomposition of the system in chunks or a mere standardization of components without clearly identifiable interfaces is not to be considered a full action of modularization.
This identified set of mechanisms can support decision makers in designing life cycle–oriented modularization implementation strategies. Furthermore, the mechanisms are descriptive categories that allow existing cases to be analysed in order to distinguish what is modularization and what is not. This facilitates the evaluation of different available solutions to identify gaps that need to be addressed to achieve a successful modularization of the system.
Having defined all the instances (drivers, barriers, mechanisms and impacts), the ontology of modularization can be graphically summarized as reported in Figure 2. Class and subclass slots are connected by solid arrows, whereas subclasses are linked to their corresponding classes by dashed arrows.
Graphical representation of the ontology of modularization.
Overall, the proposed ontology is not a system design methodology; rather, a reference framework for the identification and selection of modularization strategies to be deployed through proper product and/or design methodologies. Therefore, it overcomes the hybrid use of methods such as the axiomatic design – which would imply an independence axiom to be fulfilled, which is by the way unrealistic – so as to ensure a fully operationalizable strategy.
Application to three illustrative case examples
In order to explore the potential impact of the proposed ontology, three examples are discussed in detail hereinafter. The first example case is the Project Ara by Google (details available at the following website: https://en.wikipedia.org/wiki/Project_Ara). The second example case is an LNG plant. The third example analyses the Chronic Related Groups (CReG) programme developed by Lombardy Region (Italy) that is aimed at reorganizing the healthcare delivery pathway of chronic and multi-chronic patients.
The case examples are used due to easy accessibility to their secondary data. They also represent three different contexts of modularization implementation (LNG is concerned with plant modularization, Project Ara is concerned with product modularization and CReG is a case of service modularization). Additionally, they represent different industrial sectors, markets and business models (business to business, business to consumer and not-for-profit service). They also exhibit different levels of modularization: from partial in the LNG plant and CReG, up to full modularization implementation in Project Ara. Therefore, these three illustrative cases are most suited to exemplify the domain-independent property of the proposed ontological framework and to reflect on the conceptually derived modularization implementation mechanisms put forward in this article.
The focus is mainly given to the value of using the newly proposed concept of Implementation Mechanisms – related to the three dimensions of modularization (namely, Architecture breakdown, Existence of interfaces and Use of standards) – and the modularization strategy, intended as a proper combination of mechanisms, under both the decision-making and life cycle perspectives.
In particular, each of the cases exemplifies the situation of a decision maker who has to understand in depth the most suitable set of modularization mechanisms to put forward, based on the ‘implications’ in general (i.e. the barriers to overcome/consider, the drivers to leverage on and the expected/targeted impacts) and based on the subjects affected (i.e. the stakeholders), who in principle might be involved in many different life cycle phases of the system under consideration. Thus, each case has been conceptually developed in the following steps: – Description of the context (based on secondary data in the view of the authors and based on real knowledge in the view of the decision maker); – Identification of all the possible modularization implementation mechanisms, by means of the proposed Ontology (in the development of the cases, the whole team took part in the task); – For each identified modularization implementation mechanisms, identification of all the implications, by means of the proposed Ontology (in the development of the cases, the whole team took part in the task); – For each identified modularization implementation mechanisms, identification of all the potential decision makers/owners (so as to effectively manage the decision process) and the subjects affected (i.e. the stakeholders), in order to better control the number of life cycle phases of the system which might be involved/impacted by the decision (in the development of the cases, the whole team took part in the task).
In practice, a decision maker should proceed with the selection of the proper combination of mechanisms (i.e. a strategy) based on this comprehensive view; of course, the proposed cases do not include this last step and have a more descriptive angle if compared to the systematic/procedural one of the decision maker.
Google – Project Ara
The mechanisms that describe the modularization solution in Project Ara are summarized in Table 7. The design concept of this product, assuming it complies with the features declared by the developers, is a good example of a modularization implementation. The modular structure of the phone is clearly recognizable and consists of the display module, several functional modules (e.g. Wi-Fi board, processor, battery, video camera, etc.) and an interface that connects the display and all the functional modules. The customer can choose from different kinds of standard functional units (e.g. a higher resolution camera or a faster processor), obtaining several different product configurations. The physical elements of the mobile phone are clearly decomposed, and they execute separated functions so that the customer can easily recognize the different modules, substitute and maintain them. Thanks to the standardized modules and interfaces, module swapping is enabled. The interactions between the different functional modules are limited to data flows and energy flows.
Project Ara: Implications of the modularization mechanisms.
R&D: research and development.
A clear identification of the mechanisms that characterize a specific action of modularization sheds light on the implications triggered by each mechanism, as shown in Table 7. These implications consider the entire system life cycle and affect several subjects within and outside the company. Consistent with defining modularization as the object of a decision-making process, Table 7 reports both the subject(s) responsible for the decision to implement a certain mechanism of modularization or not and the subject(s) affected by this decision.
For example, the decision to implement the ‘Module Design’ mechanism is in all respects a strategic decision taken by the firm’s chief officers. The implementation of this mechanism has several implications. It requires a completely new design approach hinged on the existence of independent physical and functional systems, the interactions between them and the minimization of redundancies and efficiency losses resulting from splitting the integral architecture of the smartphone. The implementation of this new design approach mainly affects research and development and design departments, which have to reorganize product development processes and methods. In order to minimize oppositions to such a change in the design approach, the Human Resources department should evaluate which resources are the most suited to the duty, also considering staffing adjustment and new hiring. A modular architecture may reduce product development time in the long range, thanks to the opportunity of releasing new products by introducing significant innovations on single modules rather than designing a completely new product. 67 A consequence of this is the improved durability of the product. Indeed, the customers will be able to update their smartphones’ hardware by substituting obsolete or damaged modules, avoiding the need to buy a completely new model. This will bring deep modifications in revenues and cash flow trends, flattening the periodic spikes caused by the introduction of new models and reducing maintenance-related revenues. Product architecture disaggregation could drive a shift from assembly lines to assembly cells and the production plant life cycle should be longer due to the improved durability of the product. From the supply chain perspective, suppliers have to be selected according to their capacity to deliver functional modules: Consolidating suppliers of specific components may prove inadequate or not competitive when the same component has to be part of a standard functional module. A modular architecture (coupled with standardized interfaces) may significantly increase the extent of outsourcing. As long as the modules’ functional and physical interfaces are well defined, the company is enabled to delegate as much as the entire design and manufacturing process to suppliers. The literature usually refers to this approach as the ‘black box’ approach. 20,67,68 In the view of this opportunity to increase the suppliers’ responsibility for the modules, the firm has to establish which kind of relationship it wants to pursue with its suppliers, choosing within a spectrum of solutions that goes from an arm’s length relationship to the co-development of the product. 68 This choice has to be taken based on the level of criticality of the know-how involved in the production of each module in order to avoid dangerous knowledge bleedings. In the case of Project Ara, Google seems to be willing to push the black-box approach to the limit, enabling the customers themselves to design, manufacture and sell their own modules, while only developing some core elements in-house (e.g. the connection module and the operating system).
LNG plant modularization
The implementation mechanisms that describe this example are summarized in Table 8. In this particular kind of project, a large part of the plant is designed so that it can be divided into several modules and fabricated in one or more fabrication yards. Those yards are usually located in strategic locations, in which sufficiently skilled and cost-effective construction manpower is available, and weather conditions do not affect productivity, which facilitates achieving high-quality standards.
69
The fundamental elements of a modular LNG plant are as follows: Pre-assembled units: Structural steel boxes designed to include one or more components of process equipment, piping and electrical and instrument items. Pre-assembled racks (PARs): Modules installed on concrete plinths or sleepers that enable piping/cable interconnection and gas distribution through the different locations in the plant.
Modular LNG plants: Implications of the modularization mechanisms.
LNG: liquefied natural gas.
The modules are transported by sea or by land (in the case of smaller modules) from the fabrication yard(s) to the plant site and then assembled. Further, in the case of modular LNG plants, there is a clear modular architecture of the system, even if there is lack of a complete functional decoupling since different modules can share the same functions (e.g. distribution pipelines belong to different PARs). The modules have well-defined physical and functional interfaces. The definition of these interfaces is crucial for the final assembly and the hook-up operations at the construction site. Several standard bulk components (e.g. valves and joints) are shared between different modules, but there is neither a standardization of the modules nor of the interfaces between the modules. This is the reason why modularization of LNG plants is still not a full action of modularization. As shown in Table 8, the implementation mechanisms describing this project execution strategy do not cover completely the standardization subclass. This highlights the major future development areas for Oil Gas plant modularization: Standard modules are able to cope with different environments; module design sharing between plants of the same kind, capacity scalability and flexibility are some of the upcoming challenges. A crucial precondition in order to deal with these challenges is to adopt modularization mechanisms that implement an adequate level of standardization of the modules and interfaces between modules. The expected consequence is a complete redefinition of the outer reach in industrial plant design and management. For example, a hypothetical design solution including a module standardization mechanism combined with an adequate level of functional decoupling could allow the production capacity to shift to different plants, to cope with significant variations of the input quality at lower costs and to facilitate revamping options. The adoption of bus architectures could enable plants to quickly vary the number of processed materials just by adding or substituting a module. Platform design could result in significant cost savings due to learning economies and a higher degree of commonality.
Chronic healthcare delivery: Service/organizational modularization implementation
The Italian National Health System (NHS), in collaboration with the Government of Lombardy Region (located in Northern Italy with a population of 10 million people), designed and launched a pilot project to deliver healthcare services, specially designed for the elderly population who suffer from chronic or multi-chronic illness. The unique service project (CReG) is part of the Italian NHS patient-centric strategy, shifting its healthcare services from cure to care. 4 CReG involves multiple stakeholders, mostly from the public sector (hospitals and regional authorities), in addition to private sectors (service providers), mediators (general practitioners (GPs) cooperatives), as well as volunteers. As a public initiative, the management and the quality of the services offered by CReG are monitored by public authorities to ensure enhanced patient experience and better service levels.
The central idea behind CReG is to re-engineer the operations of the local health system, by altering the operating model of healthcare service reimbursement. The traditional Italian NHS operating model hinges on the reimbursement of GPs based on their quota from the registered population to their services. In contrast, the new operating model of CReG introduces a GPs cooperative, which acts as an intermediary body managing the reimbursement between the GPs and the Italian NHS. The GPs cooperative (as a mediator) receives a fixed lump sum from the Italian NHS to offer a portfolio of healthcare services to the population with chronic or multi-chronic healthcare needs. If the number of offered treatments exceeded the allocated standardized budget, in that case, the GPs cooperative would incur the deficiencies in the budget. Whereas in case the number of offered treatments was fewer than that expected in the standardized budget, the GPs cooperative would also benefit from the budget surplus. As such, the revenues of the GPs and their cooperatives shifted from quota-based to performance-based, which reflects a better patient experience and higher service level. The outlined new operating model of CReG allows the regional authorities to overcome the structural and/or physical limitations of the Italian NHS. The CReG initiative made the GPs cooperatives realize they can generate higher revenues if they increased their service level of chronic care delivery. In other words, a fewer number of deteriorating chronic cases means fewer offered treatments, and hence would lead to lower the costs and increase the revenues.
The GPs cooperatives, therefore, employed modularization mechanisms for their chronic care delivery operations to enhance their organizational effectiveness. Modularization was implemented through standardization of healthcare tariffs, which includes drugs, GPs fees and care expenses. Furthermore, through the breakdown of the functionality and the service centralization of the Italian NHS, by creating decoupled functional layers where service providers can collaborate to offer a portfolio of healthcare services. As such, the GPs cooperatives were leveraging on inter-organizational collaboration and adopting a network-centric operating model.
The modularization implementation mechanisms in the case of CReG are outlined in Table 9. Module design is recognized by Voss and Hsuan 34 as the main challenge in service innovation. In the case of CReG, it is reflected in the redesign of not only the service and operating model of the reimbursement system of chronic care delivery but also the relationships between different public-sector organizations. The innovation in designing a new chronic care delivery system has stimulated the collaboration between different Italian authorities and policy leaders in satellite projects. Module design is also reflected in the new structure of the chronic care delivery system, which has led to mitigating the limitations of the Italian NHS, and hence, higher levels of service quality were obtained as a result of the network-centric approach. Module design in the public sector is a strategic decision, managed by policy leaders from Lombardy Region and the Italian NHS.
Modularization in healthcare services for chronic patients: Implications of the modularization mechanisms.
NHS: National Health System.
Module standardization was leveraged by the regional authorities with the aim of unifying a predefined structure for tariffs and chronic care expenses: cost of drugs, cost of treatment and so on. Tariff standardization helps in better budget forecasting and achieving greater cost control. The concept of standardization is highlighted in the literature to improve the interoperability, coordination and collaboration between service providers. 37 Having this in mind, standardization, therefore, is extended in CReG to include the diagnostic and therapeutic processes, among different local health authorities of the subregions in Lombardy.
The different CReG processes were predefined before the project was launched. The interface design is reflected in how the stakeholders built a virtual platform for collaboration between healthcare and technology providers. Interfaces can also be considered in terms of the ‘soft’ tools, such as human relationships between the service providers. 35 Furthermore, a regional integrated database was developed to ensure that the information of the patients is smoothly communicated to each involved authority.
The modularization mechanism of system’s functional decoupling is represented by the organizational model of CReG, where the rules were predefined for each stakeholder involved in the chronic care delivery process. The local health authorities created a bid to select and accredit a group of providers, who afterwards have been contracted for a specific task and for the project duration. The performance of the contracted providers is being assessed against a bundle of key performance indicators and control measures, set forth by the local health authorities. The communication and data streamlining between these stakeholders are ensured by the collaborative platform discussed earlier in the interface design.
The last identified modularization mechanism is modular consortium. In the case of CReG, each stakeholder is performing a specialized task. The consortium’s integrator, who is responsible for realizing different functions of the project and coordinates different members of the consortium, is the local health authorities (the integrating organization). The organizational setting of CReG allowed the local health authorities to be responsible for selecting, accrediting and contracting with different providers (subcontractors). Furthermore, the local authorities are also responsible for coordinating the regional patients’ database, the resources assignment on different GPs cooperatives, the communication platforms as well as the performance control of the project.
The analysis of this case coincides with our proposition that each instance of the Implementation Mechanisms class should be a result of a combination of at least one instance from the three pillars (i.e. architecture breakdown, interfaces and standardization). For instance, only considering the mechanism of innovation in the system design of CReG (i.e. module design) would not have yielded a full action of modularization if there were not standardization of the tariffs on the regional level (i.e. module standardization) as well as the existence of better communication platforms with the GPs and the patients (i.e. interface design)
Conclusion
The comprehensive ontology of modularization developed in the present study contributes to putting forward a domain-independent modularization implementation strategy. Hence, it supports top managers of the industrial and service sectors in considering the strategic implications of system modularization, which has been recognized by scholars as one of the major barriers to the diffusion of modularity principles and practices in the past 50 years. 8 The proposed ontology is not at all in contrast with the extant literature; in fact, all the existing contributions have been fruitfully used in terms of content-related knowledge about the specific instances and relations. In this article, the authors did not challenge the extant literature; they rather used every single contribution as ‘piece of information’ in order to create (usable) ‘knowledge’. What is different here is the comprehensive view, which is the key to overcome the extant ‘focused’ literature on modular themes and move to a new era when it comes to their actual implementation.
From a theoretical point of view, this article contributes to a paradigm shift in the understanding of modularization from a mere design issue to a strategic decision that, by its very nature, has consequences on the whole system’s life cycle.
In a nutshell, the article provides evidence about the opportunity of moving from a ‘modular product’ to a ‘consistent set of modularization mechanisms, with a clear awareness of the implications, the stakeholders involved, and the system’s life cycle phases involved’ (i.e. a fully operationalizable strategy). Of course, without neglecting the coexistence of more than one decision maker in the decision process.
As an additional and original theoretical contribution, this study also provides a thorough description and analysis of modularization implementation mechanisms; 15 mechanisms and their connections with barriers, drivers and impact instances were identified and arranged into a comprehensive decision-making–driven ontology. Thanks to an overall deductive research approach, through the analysis of the relationships between the different constituents of modularization, the study reached a higher level of generalization if compared to the previous studies documented in the literature.
The contribution to practice is primarily connected to providing managers with a comprehensive and structured view of the wide range of potential benefits associated to the implementation of a modularization strategy, targeting the entire system’s life cycle and the supply chain(s) involved. The proposed ontology, where modularization mechanisms are connected not only to the expected impacts, but also to their antecedents (expressed in terms of drivers and barriers) can be adopted as a guideline to support the definition and implementation of different modularization strategies. The process may take place either (1) with the attempt of targeting a set of preferred impacts, then selecting the proper mechanisms and identifying the barriers to deal with and the drivers to lever on, or (2) with the attempt of making a thorough assessment of the current situation, in terms of existing barriers and drivers, as the starting point for selecting viable modularization mechanisms, taking into account their potential and preferred impacts.
As a practical tool, in addition to the ontology itself (and the related instances), a tentative process for a decision maker is proposed in the ‘Limitations and further research’ section, which should ensure that a systematic identification of modularization opportunities is performed, and an appropriate strategy is selected.
Limitations and further research
In terms of limitations, the instances of the ontology were defined by referring to literature sources exclusively, where the far largest part of the contributions focuses on the application of modularization to a specific sector or application domain. Nevertheless, this limitation is not expected to bias the structure of the ontology, but rather the completeness/generalizability of the instances’ sets, also considering that the literature review addressed a number of domains (systems, products, services) and sectors, which helped in covering most of the known modularization applications.
The results achieved suggest new avenues for future research on modularization theory and practice. First, the ontology of modularization could be expanded to include the agents of different modularization mechanisms at different life cycle phases, as well as the stakeholders linked to drivers, barriers and impacts. This extension is crucial for systematically linking the modularization process to its organizational and supply chain management implications. Second, the proposed ontology represents a consistent background for identifying possible knowledge gaps still impairing the deployment of the full potential of modularization. In particular, future research effort could focus on the motivations behind the adoption of specific modularization strategies and on the mismatch between expected and actual impacts. Finally, future research is encouraged for achieving a better validation and a finer tuning of the proposed ontology. Survey-based or multiple case studies research methods could serve the purpose of empirically testing the results of the present study and providing stronger explanatory evidence to validate the ontology.
Footnotes
Declaration of Conflicting Interests
The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.
Funding
The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This paper presents part of the results of the project “Plant modularisation in the process and power industry: in the search of more flexible and resilient operations in a life cycle perspective”, granted by Politecnico di Milano as a “Fondi di Ateneo di Ricerca di Base” project. Special thanks to Tristano Sainati, Nicola Careri, Andrea Acremoni, Roberto Termine, Francesco Vincenti for their support in this research.
