1. Introduction
Due to industrial development, we are designing increasingly complex engineering products that are critical to society, such as energy infrastructure, pharmaceutical production equipment and plants. These products are complex, costly, and time-consuming to design and develop, and they require collaboration across many stakeholders. A fundamental principle for managing and designing complex engineering products is to break them down into smaller parts and define clear interfaces between them. This description represents a simplified entry point to modularization. In practice, modularization also involves architectural decisions, interface design, coupling and cohesion, and lifecycle implications (Reference Meyer and LehnerdMeyer & Lehnerd, 1997; Reference UlrichUlrich, 1994; Reference Ulrich, Eppinger and YangUlrich et al., 1995). The modularization concept has been used for decades by different industries as a strategic enabler to improve customization and flexibility while maintaining standardization within their products, such as the automotive and construction industries (Reference GibbGibb, 1999; Reference Johnson and BramsJohnson & Brams, 1995; Reference WilhelmWilhelm, 1997).
To realize the benefits of modularization strategies, appropriate technologies are needed, such as product configuration systems that contain information about product and how product should be designed (Reference Da Silveira, Borenstein and vio FogliattoDa Silveira et al., 2001; Reference Tseng, Wang and JiaoTseng et al., 2017). A product configuration system usually consists of two main parts: the configurator software itself, and product configuration model (Reference Hvam, Mortensen and RiisHvam et al., 2008). The configurator software can be either a commercial solution or a self-developed system. The product configuration model represents the knowledge and structure of the product and the configuration logic, independent of a specific IT implementation.
Several studies have investigated how to develop product configuration systems for complex engineering contexts (Reference Cao, Bucher, Hall and LessingCao et al., 2021; Reference Kristianto, Helo and JiaoKristianto et al., 2015; Reference Kristjansdottir, Shafiee and HvamKristjansdottir et al., 2016; Reference PetersenPetersen, 2007; Reference Zhao and HvamZhao & Hvam, 2024). However, as engineering products increase in complexity, their configuration models also tend to grow in size and complexity, for example, an increasing number of configuration rules and constraints. This growth often leads to challenges related to maintaining, updating, and scaling configuration models over time. A configuration model can be viewed as a design artefact that structures product and process knowledge and is implemented within an IT system. Like physical products, configuration models should therefore follow sound design principles. Building on this perspective, this article investigates how modular thinking can be applied to the development and structuring of product configuration models in complex engineering contexts.
The article is structured as follows: Section 2 reviews related literature and identifies the research questions and gaps. Section 3 describes the research methodology and case studies used in this work. Section 4 presents the results of the case studies. Section 5 discusses our findings and reflects on the implications. Finally, Section 6 concludes the study.
2. Literature review
This section provides an overview of existing literature on modularization and product configuration system in complex engineering contexts, along with relevant work on modularization principles in software engineering.
2.1. Modularization for complex engineering
Research on modularization in complex engineering typically begins with the concept of product architecture, which refers to the way product functions are mapped onto physical components and the interfaces that connect them (Reference Ulrich, Eppinger and YangUlrich et al., 1995). Building on this foundation, modularization is commonly conceptualized as a design strategy for managing complexity in large systems. In a modular architecture, the system is decomposed into units with well-defined and stable interfaces, allowing each module to be developed, tested, and modified with a high degree of independence (Reference Baldwin and ClarkBaldwin & Clark, 2000; Reference Krause and GebhardtKrause & Gebhardt, 2023; Reference Meyer and LehnerdMeyer & Lehnerd, 1997; Reference Pahl, Beitz, Feldhusen and GrotePahl et al., 2007; Reference UlrichUlrich, 1994).
This approach is particularly valuable in complex engineering contexts, where many subsystems interact and frequent changes or upgrades may occur over long lifecycles, as seen in industries such as industrial equipment and plants. Many studies have shown that these industries have gradually shifted from fully customized solutions for each project toward modular system concepts, emphasizing the reuse of predesigned and validated standard modules such as skids, functional modules, room modules, and other higher-level modular building blocks (Reference Gepp, Foehr and VollmarGepp et al., 2016; Large plant manufacturers group (VDMA), 2014; Reference O’Connor, O’Brien and ChoiO’Connor et al., 2015).
2.2. Product configuration for complex engineering
Product configuration systems are one of the key enablers of modularization strategies, and a well-defined modularization strategy is also important for the effective development and use of product configuration systems (Reference Da Silveira, Borenstein and vio FogliattoDa Silveira et al., 2001; Reference Hvam, Mortensen and RiisHvam et al., 2008; Reference Tseng, Wang and JiaoTseng et al., 2017). In general, product configuration systems support the configuration process, from collecting customer needs to releasing the product documentation needed for production (Reference Forza and SalvadorForza & Salvador, 2002). These systems act as expert systems that help users create product specifications during the configuration process (Reference HaugHaug, 2008).
In complex engineering, especially in one-of-a-kind or Engineering-to-Order projects, there is a trend from fully customized solutions toward Configure-to-Order to some degree (Reference Cannas, Masi, Pero and BrunøCannas et al., 2022; Reference Gepp, Foehr and VollmarGepp et al., 2016). Recent studies show that product configuration systems are increasingly used in complex engineering to support Configure-to-Order by automating engineering calculations, generating parametric designs, and coordinating information across different IT systems (Reference Cao, Bucher, Hall and LessingCao et al., 2021; Reference Ditlev BrunoeDitlev Brunoe, 2017; Reference Kristjansdottir, Shafiee and HvamKristjansdottir et al., 2015; Reference PetersenPetersen, 2007). The benefits of using product configuration systems in this context are also well documented, such as decreased lead time, improved quality, higher productivity, and so on (Reference Haug, Shafiee and HvamHaug et al., 2019; Reference Hvam, Haug, Mortensen and ThuesenHvam et al., 2013).
2.3. Modularization in software engineering
Modularization has a long and influential history in software engineering. The principle of information hiding introduced by Parnas argues that software should be decomposed into modules that encapsulate design decisions likely to change while exposing only stable interfaces (Reference ParnasParnas, 1972). Later work emphasized the need for architectural documentation, such as a module guide, to describe the responsibilities and interfaces of each module, thereby improving clarity, flexibility, and the independent development of system components (Reference ParnasParnas, 2006).
Further developments extend modularization to software product lines, where a common platform supports families of related products with configurable features (Reference Clements and NorthropClements & Northrop, 2002). Feature-based modelling and variability management techniques further support the creation of highly configurable systems (Reference Linden, Schmid and RommesLinden et al., 2007). These ideas mirror product platforms and configuration in mechanical engineering and product development disciplines.
2.4. Research gap
Previous studies have shown that modularization plays an important role in improving the effectiveness and efficiency of development in both complex engineering and software industries. A product configuration model, much like a physical or software product, should also follow good modular design principles, especially as configuration systems are widely used to support complex engineering processes. However, research on this topic is limited. Only one study explicitly discusses the reusability of configuration systems (Reference Ghosh, Myrodia, Mortensen and HvamGhosh et al., 2019), and little attention has been paid to how modularization is applied within configuration models themselves. To address this gap, we have chosen to investigate this topic through case studies conducted with both current and past industrial collaborators.
3. Methodology
To investigate this topic in a natural setting and gain a deeper understanding of the phenomenon, we adopted the case research methodology, which is well suited for exploratory studies (Reference Voss, Tsikriktsis and FrohlichVoss et al., 2002). Multiple empirical cases were selected to increase external validity, reduce the risk of observer bias, and provide a more robust and compelling basis for the research findings (Reference YinYin, 1994). The case study approach enables an in-depth investigation of how configuration models are structured and managed in practice, which is difficult to capture through surveys or quantitative methods alone. Multiple cases were conducted to identify similarities and differences in configuration model structuring across different companies. As a result, three engineering companies were chosen.
3.1. Case selection
Since this study focuses on complex engineering products, we selected companies that design highly customized solutions typically consisting of several hundred parts. Additionally, the case companies were required to have product configuration systems in place to enable meaningful analysis. Based on these criteria and available industrial contacts from our research group, three case companies were selected. An overview is provided in Table 1.
Overview of case companies
Case Company A is an engineering consulting firm specializing in the design of complex pharmaceutical production systems, where most projects are fully customized to meet specific customer requirements. A typical production system consists of multiple process units, and each process unit includes many components and machinery that support a specific stage of production. Cost estimation for these process units is crucial for accurate pricing and setting project cost targets. To support this, the company has developed a conceptual cost configurator prototype for general process units. Introduced in 2025, the configurator is mainly tested internally by mechanical engineers and is designed to generate mechanical cost estimates for each process unit.
Case Company B is a small to medium-sized enterprise specializing in multifamily apartment design. Its core design element is the volumetric element, which represents a module of the building and can be configured with various parts such as toilet modules, floor elements, wall panels, and windows. The company has developed an advanced configuration system dedicated to the detailed design of these volumetric elements. Since its founding in 2018, the system has been gradually developed and implemented to produce detailed bills of materials (BOMs) and technical drawings for production.
Case Company C is a division of a global company that designs large engineering plants and processing equipment for industries such as food and beverage. Projects typically involve delivering either entire customized plants or specific production systems. To support its engineering processes, the company has gradually developed a configuration system over the past several years. This system assists engineers in generating cost estimates and quotation documents, as well as producing detailed 3D and 2D drawings for workshop fabrication.
Unlike consumer products, these three companies design complex engineering solutions that require collaboration among many engineers. Their BOMs typically include hundreds of items, making them suitable for analysing how complex configuration model are built within the research scope.
3.2. Data collection
Data for this study were collected through a mix of methods, including semi-structured interviews, analysis of internal company documents, informal and formal discussions, participation in broader research projects, and company presentations. An overview is provided in Table 2.
Data collection
During the semi-structured interviews, the discussions mainly focused on open questions about how products are structured, how they are configured, and what configuration strategies are applied in managing complex product configurations. This flexible approach allowed interviewees to elaborate on areas most relevant to their expertise while enabling us to ask clarifying and follow-up questions. To capture a broad perspective, we selected interviewees from a range of roles, including technical developers, managers, and executives.
Alongside the interviews, internal company documents were analysed. These included process descriptions, presentation slides, and documentation related to product configuration system development. The documents served both as background material and as a means to cross-check interview data against documented practices.
Data collection for the three case companies took place at different times, partly in connection with other ongoing research projects. The details of data collection are presented in Table 2, and all names and product references have been anonymized to protect confidentiality.
4. Results
In this section, we present the results and insights from these three companies regarding how they manage their complex engineering product configuration models. Different simplified visualizations are presented for each company, reflecting their own individual approaches on interprations.
4.1. Case A
Case Company A has developed one single configurator used for cost estimation for process units. Since the design of each process unit is highly customized, it is difficult to develop a single model that remains same without considering future modifications or changes. Therefore, the company designed its configuration model as a set of submodels. Configurable attributes and cost calculations are mainly defined within the submodels, rather than across the entire configuration model, as shown in Figure 1.
By doing so, developers can more easily update specific attributes or calculations, as they can focus within individual submodels instead of modifying the entire configuration model. This approach enables higher flexibility and maintainability of the usage of product configuration system over time.
Configuration model visualization from case A
4.2. Case B
Case Company B has implemented a configuration system consisting of 33 separated configurators with 33 separated configuration models, each representing a different part of the multifamily apartment. In their configuration process, the company has adopted a strategy where the configuration system is used only in the final stage of the design process to generate production materials for around 80 percent of apartment design. The overall configuration process is shown in Figure 2.
Before using the configuration system, engineers define the parameters of the multifamily apartments within predefined ranges in their drawing software. After that, these parameters are exported as a structured dataset, which will trigger the corresponding configurators to generate BOMs and technical drawings for production.
This approach allows the company to maintain design flexibility during early design stages while using the configuration system for the most time-consuming tasks. Another benefit is that the company can manage these 33 configuration models independently, allowing updates or modifications without affecting the others, which increase maintainability and scalability of the overall configuration system.
Product configuration process from case B
4.3. Case C
Case Company C has an internal team responsible for developing configurators. The team’s strategy is to develop separate, individual configuration model and configurator for different equipments of their complex engineering plants. The main function of these configurators is to generate detailed drawings and fabrication lists. In total, around 25 configurators are currently in use. On top of that, there are different configurators used cross different life cycles. For example, plant configurators are used for some brief customer quotation process, system configurators are used to generate some requirement of design requirements, and service configurators are used for spare parts.
In this case, the different configurators are used in various combinations depending on the specific project requirements. Selected configurators are applied to generate parts of the design and to combine configured outputs with additional engineering work. This approach allows the company to reuse configurators across multiple projects while still accommodating customer-specific requirements. At the same time, it enables a flexible configuration process, reducing the risk of developing a single, rigid configurator with one fixed configuration model dedicated to the entire plant design.
Configurator landscape and portfolio from case C (adapted from Reference Ghosh, Myrodia, Mortensen and HvamGhosh et al., (2019))
4.4. Summary of results
Case Company A has developed a single configurator, but within its configuration model several submodels are defined. The calculations and attributes within each submodel are highly interconnected (i.e., tightly coupled), while dependencies between submodels are intentionally limited (loosely coupled). According to the developers, this structuring was chosen to simplify future updates and maintenance. The modularization approach in Case A can be characterized as a functional grouping strategy, where related configuration knowledge is organized into internally cohesive but externally decoupled modules. Case Company B has likewise divided its configuration model into several sub-configuration models to enable easier updates and faster adaptation to project requirements. Case Company C applies a similar principle: instead of developing a single monolithic configuration model for process plants, it has created multiple smaller models that engineers can combine as needed depending on project phase and customer requirements. The modularization strategies observed in Cases B and C can be interpreted as partial Configure-to-Order, where some standardized design are programmed into modules and the rest of design remain Engineer-to-Order.
From these three empirical cases, although the companies operate in different industries and present their configuration strategies to us in different ways, we observed a similar overall approach: decoupling complex configuration models and applying modularization to gain flexibility, upgradeability, maintainability, scalability, reusability, and reduced development risk.
5. Discussion
From these results, someone might ask whether it is simply obvious that complex engineering configuration models should be divided into smaller submodels, since modular product structures are needed when developing configuration models and product configuration systems. This logic makes sense and is supported in the existing literature, which states that a well-defined modular product architecture is a prerequisite for effective development and use of product configuration systems (Reference Hvam, Mortensen and RiisHvam et al., 2008). If companies want to build product configuration systems for their complex products, they must first structure their modular products. After that, configuration models are built based on these modular product structures.
However, in real industrial settings, product structures are usually designed by product designers and engineers, while configuration models are developed by IT engineers or programmers. These two groups speak different technical languages and have different backgrounds. What is logical in the product design domain cannot be assumed to transfer directly to the IT domain. Even in a mature and advanced case from previous research (Reference Zhao and HvamZhao & Hvam, 2025), we found a clear misalignment between the modular product structure and the modular configuration model, even though the company was strong in both areas. There is therefore a need to coordinate the IT domain and the product design domain when developing configuration models, as shown in Figure 4. Two different domains need to work together towards to the final successful implementation of product configuration systems.
Coordination between product structure team and configuration team
Good design principles, like modularization, are needed to be applied when programming configuration models. In other words, IT engineers and programmers need to think more like designers and use the modularization principle when building configuration models, to gain benefits such as flexibility and maintainability. Designers also need to think more like programmers by transferring their product design knowledge into clear requirements for IT developers and ensuring that configuration models are built in a modular way for future upgrades and updates. By doing this, both sides can understand each other better and work together more smoothly. We believe this coordination is the key to successful implementation of modular configuration models, which is also an important factor for successful implementation of product configuration systems in complex engineering contexts.
Although this study provides evidence of modular configuration model structures across three industrial cases, several limitations should be acknowledged. The cases differ in industry context, system maturity, and level of data access, which may have influenced the depth of analysis and introduced a potential bias toward cases that organizations were willing to share. Consequently, some relevant practices or challenges may not have been fully captured.
Future research should extend this work through additional case studies and longitudinal investigations to better understand how configuration model structures evolve over time and across organizational contexts. In particular, further studies could examine how modular configuration principles can be systematically applied during the development of configuration models and configurator systems, which is critical for translating conceptual insights into practical implementation guidelines for industry. Moreover, modularization represents a broad design domain in which multiple structuring strategies may coexist. This study explored these strategies at a simplified level. Therefore, future work should investigate different modularization strategies in greater depth and analyse their implications for performance, maintainability, and scalability. Finally, an important direction for future research is to examine lifecycle-oriented modularization in complex engineering environments, especially with regard to configuration activities across later lifecycle stages such as engineering, manufacturing, and service.
6. Conclusion
This study examined how three companies in complex engineering structure their configuration models. Even though the companies work in different industries, we found a similar pattern: they divide their configuration models into smaller parts and apply modular thinking. This helps them handle complexity more effectively and gives advantages such as flexibility, upgradeability, maintainability, scalability, reusability, and reduced development risk. The study also shows that modular thinking is important not only for product design but also for the development of configuration models. Designers and IT engineers need to share this mindset when building configuration models, so that configuration projects become easier to update, maintain, and scale. This is an important factor for the successful implementation of modular configuration models and, therefore, for the successful implementation of product configuration systems in complex engineering contexts.
Acknowledgement
We would like to acknowledge that the collaboration between our research group with these three case companies. Special thanks to NNE (Novo Nordisk Engineering) A/S which funds and supports this research project.
Open access
