Exploring Product Modularity in Residential Building Areas

Abstract

This study explores how the logic of product modularity could be useful for the design of complete residential building areas. Previous research has noted that product modularity is usually only applicable if a ‘full modularization’ approach is pursued (i.e., an approach with completely defined modules). This is challenging in Engineer To Order production strategies. Therefore, an approach towards partial product modularity is sought instead. In this approach, the modules are lesser defined to allow flexibility following, e.g., architectural design freedom, as well as per project-specific requirements posed in house-building projects. This study identifies nine (9) ‘modules’ which are denominated as functional spaces. By explaining how unique project requirements affect functional spaces, some integral elements of house-building are detailed. By evaluating the functional spaces in regards to the level of predefinition, as well as the level of relationship, their level of modularity is explored. The usefulness of partial modularity for house-building is suggested to be for coordination of design work and support tools that aides design work. This study suggests that partial modularity can be a feasible approach towards modularity without the need for countermeasures in terms of increasing product predefinition.

1. Introduction

In the construction of residential buildings, product modularity is emphasized as means for improving the house-building industry by reducing re-work [1,2]. The essence of modularity involves decomposing products into standardized sub-assemblies, i.e., modules, which can be combined in different ways to obtain product variety, while still reaping benefits from industrialization [3]. Over the years, product modularity has proven to be a successful approach for many industries (e.g., consumer products as in [4], or automotive as in [5]). It has helped in offering customers customized products, with maintained control over the customization, in terms of, e.g., cost and quality [6]. However, [7] highlighted a limitation in the body of literature for product modularity in that it usually targets a ‘full modularization’ approach, i.e., an approach where the entire product is decomposed into predefined encapsulations. In other words, a setting without the need for any additional design work on each product instance, as everything down- and upstream the value-chain from where a customer enters is already predefined in advance. This study builds on this limitation and explores requirements’ impact on product modularity in a context where ‘full modularization’ is infeasible. The expected output from building on this limitation is a conceptual module definition, where the logic of modularity is maintained through partial modularization, without necessitating full product predefinition in line with a ‘full modularization’ approach.

For categorization of different levels of customization (i.e., the amount of product predefinition) in various production strategies, Segerstedt & Olofsson’s [8] four adapted denominations can be applied: Engineer To Order (ETO), Modify To Order (MTO), Configure To Order (CTO), and, Select Variant (SV). These reflect, in descending order, the amount of design work needed when a customer enters. With these in focus, ‘full modularization’ is only suitable in a CTO production strategy. ETO and MTO still require product-specific design work, and in the last approach, SV, modularity is superfluous as there is nothing to customize in completely specified products. Another way of portraying it is in terms of constraints, as a more predefined product is more constrained in its production strategy [9], a lesser constrained product is, therefore, more customizable. House-building as a trade generally adheres to an ETO production strategy [10], and as such, ‘full modularization’ is challenging, by some even considered inappropriate [11]. Despite this, previous research has shown how building components can be isolated and treated as modular, leading to customizable buildings [12,13,14]. But, albeit these endeavors shows promise, problems with the ‘full modularization’ approach still arises in regards to the scope of what the product is. In other words how the product in house-building is defined and demarcated. With this in consideration, previous efforts into modularity for house-building is unfortunately not sufficient if a house-builder needs to consider more than buildings in its scope. Of importance is then also, e.g., the required work needed for adapting a particular building to a particular site. In this process, Local Planning Authorities (LPAs) pose project-specific requirements to house-builders [15]. Furthermore, a residential building area consists not only of buildings but also of complementary functions such as parking lots, playgrounds, social areas for residents, etc. Thus, with a wider scope, entire residential building areas are more accurately a description of some house-builders’ products. And intriguingly, these house-builders still need to manage the complex balancing between what to predefine and what to customize in individual projects [9]. In this study, a product scope incorporating whole residential building areas was adopted, and modularity for house-building was taken further in an exploration of its applicability in a wider context. The problem in focus was that project-specific requirements affect modularity (an ETO consequence), as they pose a barrier to target economies of scale in a ‘full modularity’ approach [7].

Therefore, the purpose of this study was twofold. Firstly, to understand why a traditional view of product modularity is chafing in the house-building context. Secondly, to explore how requirements affect modularity in terms of, e.g., integrality, without a ‘full modularity’ approach in residential building area development. The latter constitutes the main focus of this study and is aimed at exploring; what a module could be and how product modularity could be applied to meet project requirements, in this study exemplified with LPA requirements.

2. Frame of Reference

This chapter firstly addresses product modularity in general and the difficulties of defining the built environment. Thereafter it addresses requirements in an ETO setting, contextualized through house-building. From this, an evaluation of pre-existing methods for achieving product modularity against the context explored in this paper is presented. Lastly, some previous efforts into modularity in an ETO setting are detailed.

2.1. Product Modularity

Product modularity stems from the decomposition of products into smaller ‘chunks’ or subassemblies, referred to as modules [3]. By standardizing—or predefining—these modules, a variety of product variants can be offered to customers with relatively few variants of ingoing modules. According to Ulrich (ibid.), a product is considered modular if:

(i)

there is a one-to-one mapping between modules and functions

(ii)

unintended interaction between modules is avoided

These modular prerequisites suggest that a modular product easily can be altered by switching modules without sacrificing functionality, rather, a new and fully functional product variant emerges. For this to be successful, emphasis is put on the interface between modules. In a modular product, these are non-specific, i.e., as little dependence on adjacent modules as possible.

Despite the sharpness in how these modular prerequisites are formulated, few products are completely modular, and it is often more of a continuum where a product is more or less modular. The counter-position to a modular product can be denominated as an integral product [16]. In an integral product, a component or a sub-assembly has many functions, and it is difficult to alter the composition of components and still maintain sought functionality in the final product. Modularity has served as means for supporting a transition from mass production towards mass customization, where the needs of individual customers are catered to, whilst maintaining mass production efficiency during manufacturing [17].

As previously mentioned, modular products traditionally imply the need for a production strategy that decouples design processes from each final instance of a product, mainly CTO production strategies. In this setting, modularity assists the controlled diversification of end-products from front-end specification to back-end production and logistics, as all eventual constraints can be determined beforehand [18,19]. Methods exist which aim to guide how to determine what a module is and how they should best be selected in this setting [20,21,22]. Furthermore, following a traditional view on product modularity, determining how to define modules and interfaces between modules is mainly based on tangible or physical parameters [23]. Examples include physical adjacency between modules or modular interactions in which energy, material, or information is transferred or exchanged [24]. Contrary to this view on modules and interfaces, Wikberg et al. [25] present a broader and adapted view on product modularity. They addressed challenges with modularization of spatial and functional voids, which are present in house-building, e.g., in rooms or living space. The governing idea was to address typically qualitative parameters such as form or aesthetics in a configuration process, and, thus, unite the architectural perspective of house-building with the engineering perspective of manufacturing. In so doing, a connection for modularity between physical and non-physical parameters to better adapt the configuration to the requirements posed in the design process of house-building can be facilitated.

2.2. Managing Requirements and Constraints in House-Building

House-building, in general, is often characterized as an industry predominantly adhering to an ETO production strategy [10]. But an increase in attention to industrialization has bridged some differences between house-building and other industries, where production strategies with higher levels of predefinition are common, e.g., the automotive industry [26]. In this study, the position was taken that despite this, some aspects of house-building remain firmly grounded in an ETO setting. Supporting this position is the inherent spatial dependence in house-building, i.e., that each building is ultimately unique for its site and that each site is unique for its place. This requires an engineering process, where new requirements are managed in each project due to each site’s varying prerequisites [15].

Jansson [27] addresses a demarcation between constraints and requirements in an adaption of product platforms to the ETO context of house-building. Constraints are formulated as an interpretation of axiomatic design principles [18], to link how predefined modules (i.e., commonality parts) are affected by downstream constraints through, e.g., production- or logistic variables [19] in a product platform. An example of a constraint stemming from production could be the maximum allowed height of a wall element due to capacity limitations from manufacturing equipment. A logistic variable constraint could be the maximum allowed size of a building element, to manage transportation from an off-site production facility to a specific building site. Requirements, on the other hand, affect the distinctive customization needed in each project. Using a general term, such as ‘project requirements’, emphasizes that from whom a requirement originates is not particularly important, it could be any stakeholder, e.g., a client, a resident, or a municipality. But, project requirements converge in that they all affect the design process and the specification of each instantiation of an end-product. Previous works aimed towards encapsulation of modules into platforms for house-building consider mainly platform constraints [25,28]. However, these studies also share a view where only the building is the ‘product’. Only the building is, thus, approached as modular, which also decouples its spatial dependence and the requirements that need to be managed in this process. This is a reoccurring position in other studies as well, e.g., [13,14,29]. In this study, attention to both platform constraints and project requirements was in focus to include an impact from house-buildings’ spatial dependence whilst maintaining a modular platform. This entailed a multi-faceted view of how different parts of a product have different levels of predefinition. Schoenwitz et al. [30,31] addressed this by decomposing the elements of product architectures (addressed as adhering to different production strategies). This study complements their work by adding attention to house-buildings’ spatial dependence, as well as project-specific requirements posed by stakeholders other than end-users.

Despite the scarcity of closely related works, it is seen as important to stress the role of requirements in an exploration of modularity. Although normally collated from a customer or user perspective, e.g., [11,31], the idea of linking requirements and functions onto a module forms the essential pathway of some previously suggested methods for applying modularity [20,21,22]. The following section summarizes in what aspects these methods are insufficient for the ETO setting portrayed in this study.

2.3. Modularization Methods

There are some methods for modularization described in the literature, e.g., Erixon’s [20] Modular Function Deployment (MFD), Stone et al.’s [21] method for identifying modules for product architectures, and Veenstra et al.’s methodology for developing product platforms [22].

Erixon’s [20] method for modularization, MFD, has five steps and is developed mainly for consumer products such as cars or vacuum cleaners. The five steps are: (1) Clarify customer requirements, (2) Select a technical solution, (3) Generate concepts, (4) Evaluate concepts and (5) Improve each module. Stone et al. [21] also present a five-step method for identifying modules for product architectures: (1) Gather customer needs, (2) Derive functional model, (3) Identify product architecture, (4) Generate modular concepts, and (5) Embody design. The largest difference compared to Erixon [20] is that this method uses flows of energy, material, or signals in so-called function chains to identify the modules.

As both Erixon [20] and Stone et al. [21] presented modularization methods for the consumer product or manufacturing industry, one could argue based on that insight alone that those methods focus on modularity for components that are not applicable for residential areas.

Veenstra et al.’s [22] modularization methodology for developing product platforms consists of three steps: (1) Determine product architecture, (2) Determine interfaces, and (3) Determine standards. This methodology is for the building scale and not for the plot scale and, in comparison, to Erixon [20] and Stone et al. [21], it includes spatial uses, which is a further development from the otherwise more tangible physical parts of the consumer products dealt with in the other two. However, it still relies on full predefinition. Therefore, these methods jointly lack sufficient attention to ETO production strategies.

2.4. Product Modularity in an ETO Setting

Previous scholars have addressed challenges related to drawing on benefits with modularity in ETO production strategies such as within the Architecture, Engineering & Construction sector (AEC) [7,32]. Jansson et al. [33] suggested a series of support methods to address distinctiveness in ETO projects and, thus also, a way to mitigate project requirements’ effect on predefinition. Despite that study being focused on the operational use of platforms rather than their development, it serves as an example of how customization can be supported in place of predefinition. Johnsson [34] also studied production strategies in the specific setting of house-building and concluded that if for some reason, full product predefinition was out of range, the focus should be directed towards standardization of processes rather than products.

An alternative to the ‘full modularization’ approach is suggested by Hvam et al., [7]. By assessing different levels of modularity, they address partial modularity as a viable way forward for controlling customization in an ETO setting. In a case study of a cement factory supplier, their study identifies some benefits of particular interest for the house-building industry. They highlight two factors, which served as barriers to ‘full modularization’; the time-consuming process of calculating and drafting detailed product offerings, and, the challenges with obtaining economies of scale. Both of these factors are characteristic in the house-building industry, especially when assessing residential areas and not only buildings as the final product. The former can be translated to the time-consuming design process in house-building. The latter, economies of scale, is also relevant in a residential area due to the uniqueness of each final product. For this reason, their ideas were further explored in the context portrayed in this study.

2.5. Motivation of Research

A question that might arise upon reviewing the challenges with, e.g., spatial adaptation and the need for design work for residential areas is ‘why modularization of residential building areas then?’ What is to say that specifically, product modularity with such a wide product scope would have a positive effect on the house-building industry? By critically relating to—and reflecting upon—this question, we wish to justify this research. First of all, as argued by Hvam et al. [7], “By putting part of the product’s components into modules, there would be fewer units needing coordination in relation to the design”. This statement serves as strong motivation for exploring a broadened view on product modularity, as it suggests that little is better than nothing. Secondly, this exploration is theoretically motivated as well. Previous efforts into modularity argue for a holistic approach when managing a product or a family of products [19]. If then the product is more than only buildings, the holistic approach is to incorporate more than buildings into the product scope. And, for this, proper taxonomy and oversight of challenges were deemed necessary.

Furthermore, we acknowledge the explorative nature of this study. This follows from the—according to our knowledge—lack of experience of similar undertakings in research aimed for the house-building industry where the focus is towards residential building areas as the final product. We thereby inquired whether an isolated focus on buildings when assessing modularity for the house-building industry is a sufficiently broad view enough for some actors. This study is thus an exploration into ‘how far could or should house-builders take the concept of modularity?’. The question strikes us as intriguing for both academia and practitioners, especially in the light of previous work aimed towards house-building, but where the product is more narrowly confined. We find it intriguing firstly, as it originates from an empirically grounded context. Secondly, as it highlights the contextual differences between house-building and the manufactural environment from where industrialized house-building has adopted many of its strategies. There is, of course, a risk that works like this dilute the concept of modularity. We, however, intended it mainly to be an insert to further adapt that which has already been adopted, to identify feasible paths forward for the continuous development of house-building.

3. Research Approach

This study was carried out in two parts: an initial research project; and a succeeding cross-analysis. These two parts jointly served the purpose stated in the introduction. The following sections in this chapter specify how. Figure 1 also illustrates this research process. The issues addressed in this article are not already well understood by the scientific community, therefore, an exploratory single-case study approach was deemed suitable. Case studies as a form of qualitative research are appropriate for acquiring an in-depth understanding of context-dependent phenomena [35]. The context here being residential house-building and the phenomena being modularity in residential building areas. The case company, BoKlok, is a Swedish house-building company with long experience in industrial house-building and holistic responsibility of the building process, from very early design phases (zoning phase) to assembly, completion, and hand-over. We motivate our choice of a single-case approach to obtain depth rather than width. The rationale behind case selection was information-oriented. In regards to empirical value, the case company can be seen as an extreme case [36], meaning an unusual case deemed to be particularly rich in information.

Being an exploratory study, we refrain from claiming our findings analytically generalizable. This means that the focus is mainly on internal validity (the study’s validity within its context) and not external validity (the study’s validity in other contexts) [35].

3.1. The Research Project

This research originates from a research project in which three of the authors and the case company in focus of this paper participated. From the case company, the participants were as follows: the Head of Research and Development (which is included as an author of this paper); the Manager of Technical Development; a Development Leader with a focus on Multi-family building concepts; a Customer Analytics Specialist; and, the Digitalization Manager. To support project management, an external consultant—expert in Product Platform development—was included throughout the project as well. Additional specific competencies, e.g., an architect with expert skills in digitalization in the construction industry was included as often as it was deemed necessary. The main purpose of the project was to further develop and adapt to the concept of product platforms in the particular setting of residential house-building areas. One of the starting points of the project was the issue under loupe in this article, namely, how a product platform can incorporate residential building areas instead of just buildings. The research project was carried out between April 2019 and January 2020, and, for at least the main author, the project amounted to extensive and close collaboration with the case company. This meant some form of work in meetings, workshops, or task-force work assignments regularly (often weekly). This provided a deep understanding and access to valuable insight into the organization.

As previously stated, this study was carried out in two parts, the research project and the subsequent cross-analysis (see Figure 1), of which primarily the second part (the cross-analysis) is documented in this article. The first part of the study was, from a scientific point of view, issue-driven rather than theoretically motivated. This meant that only the general direction and research area focus was determined in advance. Our interest in the issue at hand was intrinsic, and the research project provided a timely and suitable opportunity for this exploration.

Two interviews were conducted by two of the authors during this first part. However, these interviews, together with the workshops (of which there were 3), meetings, and task-force work assignments in the first part served primarily the research project’s purpose, rather than the output presented in this article. Similarly, observations made during the first part were of a more general nature, not structurally guided as to observe certain particularities. The by-product of these efforts was an understanding and insight into the case company’s context, their challenges, as well as how they work (their organization) and with what they work (their products). Therefore, the first part’s major outcome, besides contextual understanding, was the formulation of the purpose and scope for further work.

3.2. The Cross-Analysis

As the study progressed into the second part, the most pertinent empirical data were collected and analyzed. However, without the contextual understanding from the first part, this empirical data would have been difficult to make use of. Here, extant literature also guided the emerging narrative more clearly and aided in formulating the theoretical framework, as well as the partial modularity approach.

Even though this is a single-case study, we chose multiple units of analysis [35] to enable a cross-analysis. The units of analysis are two of BoKlok’s products for multi-family residential buildings, one of which is currently in production and the other which was recently discontinued. Both products will be described in more detail in the following sections. Studying two demarcated products allowed for insights into how strategical considerations from within a house-builder affects the potential for product modularity of residential building areas. As no evident organizational or other major changes have taken place inside the case company between the two products (regarding production or project processes, etc.), the units of analysis also provide reasonable ground for making comparisons.

In the cross-analysis, two sub-analyses were performed: a product analysis; and a requirement analysis. Initially, archival records from completed building projects were collated for both products to perform what we denominate as a product analysis. For the product currently in production, project documentation from 23 completed projects was gathered. The number of projects was chosen for two reasons; firstly, to roughly reflect an annual production (in terms of off-site production capacity), and secondly (and most importantly), to approach saturation in terms of understanding variability between projects. For the discontinued product, project documentation from seven completed projects was gathered. The lower number of projects is a reflection of the limited variation between projects, as the level of predefinition was higher there. Upon review, and in consultation with the case company, it was determined that saturation in relation to project variability was reached, even with a lower number of projects. The motivation for this sub-analysis was to gain an understanding of what the products’ consisted of. This was done by exploring similarities between projects of such a nature that encapsulation and re-use between projects could be possible based on, e.g., included components, geometry, interfaces, etc. The archival data supporting this analysis was mainly sales documentation with general information regarding location, size of the project, etc., but most important was a conceptual site drawing, which depicted each residential area. From this, a clear view of the layout of each project was available for further exploration and measuring (e.g., areal measuring). General documentation capturing product information, such as guiding documents for communication with project actors were also used to form a more comprehensive view of each product’s capabilities and limitations.

The second sub-analysis was what we denominate a requirements analysis. Here, we deliberately singled out LPA requirements affecting each building project in zoning plans, not taking into account, e.g., customer requirements or other stakeholders’ requirements. The rationale for this was that requirements formulated from a legislative perspective cannot be ‘bargained with’ on similar grounds as, e.g., adaptations based on customer needs. In Sweden, requirements governing the built environment exist on both a national and regional level. On the national level, there is consensus and a certain degree of stability, meaning that these requirements are reasonably possible to adopt in a modular platform that can be deployed nationwide. Regionally, LPA requirements determine how the land can be used and developed [15], therefore these became our target to capture house-buildings’ spatial dependence. The documentation supporting this analysis was mainly governing zoning plans and zoning descriptions (described in further detail in the following sections). These were gathered for all 23 of the projects built with the current product and for all seven of the projects with the discontinued product. In Sweden, these are publicly available documents (by the principle of public access to official documents). Furthermore, documentation showing communication between the case company and various municipalities was used. Examples of such documentation include, e.g., review comments from LPAs in regards to building permits. The rationale behind this analysis was to explore barriers to modularization by, e.g., showing how subjective interpretation can affect the outcome of a product [15]. Beyond exploring similarities in requirements between projects, a grasp of the variation in how LPA requirements can be articulated for different sites was also sought after. For this analysis, we operated under the premise that zoning regulations, although differing from site to site (and municipality to municipality), can be regarded as comparable under that they have all been formulated following the same nationally governed legislation.

Figure 1 summarizes the research process and the relationship between this study’s two parts. An important output from the product- and requirement analysis was the qualitative assessment of the level of modularity. For this assessment, the level of predefinition and level of relationship together amassed the level of modularity. Here, the ability to compare two clearly demarcated products was key, as an internally validated understanding of both levels of predefinition and level of relationship could be reached through triangulation, as well as in confirming dialogue with the case company. In this study, triangulation was an iterative process where empirical data (between, e.g., archival documents and project meeting notes) were collated and compared together with intuition to support the emerging partial modularity approach. Triangulation of researchers from an individual review of collated material was used to alleviate risks of researcher bias concerning internal validity. The team of authors also included a non-participant researcher for an outside view of the conducted research to further enhance the quality and address the risk of tunnel vision and confirmation bias amongst the participating researchers.

4. Case Description

The two products in the focus of this study are called ‘Classic’ and ‘Flex’, hereafter follows a short description of each product.

4.1. The Product ‘Classic’

‘Classic’ was the original product that BoKlok, as a company, was founded around. The idea was to provide housing for many people that was affordable but yet maintained a reasonably high standard. Layouts for apartments were predefined with only a few possibilities for alteration based on individual customer requirements. Buildings came as standard two-story tall, with six apartments formed in an L-shape. One L-shaped building usually consisted of two 2-room apartments, two 3-room apartments, and two 4-room apartments. A development area for residential buildings could consist of as many of these buildings as would fit the development area. Buildings could also be designed without the 2-room apartment, thus forming an I-shaped building. The residential building area was organized according to a conceptual template (as according to Figure 2) which was to be followed in each project as far as possible.

4.2. The Product ‘Flex’

The lack of flexibility that came with the low level of predefinition in ‘Classic’ subsequently became an issue at BoKlok. The number of prospective development areas, as a result of market saturation in the targeted customer segment, decreased. Their solution was to develop and introduce a new product which was given the name ‘Flex’. This was designed to follow the same main principles (affordable and functional housing for a wide portion of the population), but, unlocked some of the previously locked parameters. Amongst noticeable differences, freer combinations of apartments were now enabled. This meant that individual buildings could consist of a flexible combination of apartment types, rather than each building having a standard default composition of apartments. Some constraints exist, e.g., that corner apartments need to be a 2-room apartment or a 4-room apartment, and, 3-room apartments have to be placed in pairs, adjacent to each other. Buildings can be 2—4 stories high. A 1-room apartment was also introduced into the mix of available apartments. Also, new façade materials, roof solutions, and exterior ornamentation, etc. were introduced as well to meet more needs through customization. The shift from ‘Classic’ to ‘Flex’ also resulted in a step away from a conceptual template (see Figure 3) for residential building areas, which rendered more flexibility to adapt to a wider array of development areas (thus aiding the problem ‘Classic’ had with market saturation). Design guidelines and templates, which are available to internal and external actors form an important ground for communicating to what extent ‘Flex’ is customizable in individual projects.

5. Approaching Modularity through Functional Spaces

Upon analysis of the 30 building projects for both products, the initial idea was to identify eligible module candidates suitable for the configuration of complete residential building areas rather than just buildings. Relatively quickly, it became evident that the traditional notion of configurable modules, i.e., a ‘full modularity’ approach, would not fit. Carry-over between projects in terms of included components or geometrically confined spaces was low. Furthermore, adapting to site-specific conditions and requirements entailed some form of project-specific design due to, e.g., slanting ground, soil conditions, or project requirements formed by, e.g., municipalities (LPAs).

5.1. Introducing Functional Spaces

Because a ‘full modularity’ approach was deemed inappropriate, partial modularity, as in Hvam et al. [7] with modules defined by experiential and functional use as in Wikberg [25] is suggested instead. This study drew from Wikberg’s work to define what a module is, i.e., to determine what to encapsulate for the modules to obtain boundaries. This definition follows a view similar to how an architect organizes design work around spatial voids, which are based on experiential or functional use to make a distinction between, e.g., a bedroom and a living room, which might be structurally or physically similar. This logic was extended to be used as an interpretation of the experiential and functional spaces of a residential building area. However, there is a major implication when adapting Wikberg’s work to this study’s context. Their work is aimed at bridging the architectural and engineering perspective in house-building, but it targets mainly a ‘full modularity’ approach by decoupling the need for design processes, and thus also enable architectural configuration. In other words, a ‘full modularization’ logic. For this reason, this study drew from Hvam et al. [7] to permit variability amongst modules in terms of how well defined or described they were. So, as the traditional definition of a module did not fit our context, we pursued an alternative approach. From here on, these more loosely defined modules are referred to as functional spaces. This denomination accentuates their functional origin, without referring to functional modules [37]. By cross-comparison between projects, this study identified nine functional spaces, listed in

Table 1. Identified functional spaces.

Functional Space	Short Functional Description
Residential buildings	Buildings with apartments
External corridors	Exterior access to apartments
Complementary buildings	Storage units, garbage rooms, etc.
Garden plots	Recreational plots adjacent to apartments
Social areas	Playgrounds or designated social areas
Parking area	Designated areas for cars, bikes, etc.
Green areas	Lawns, vegetation, etc.
Transportation	Walkways, roads, etc.
Infrastructure services	Electrical conduits, pipes, etc.

.

To put the functional spaces from Table 1 into the context of a residential building area and for a more illustrative description of the reasoning for determining their functional partition, a function–means diagram was created [38].

Figure 3 illustrates an abstracted view of what main functions the identified functional spaces correspond to expressed in a function–means diagram. Function–means is organized so that each function corresponds to a means which could then be further decomposed into sub-functions with more detailed means. The main function of a residential building area, as visible in Figure 3, was to provide living space. The functional spaces identified are each means to a sub-function one hierarchical level below the residential building area, e.g., to ‘provide housing’ corresponds to the functional space ‘residential buildings’, or, to ‘provide parking’ corresponds to the functional space ‘parking area’. In Figure 4, examples of functional spaces are illustrated more visually, highlighted on the site plan of both a ‘Classic’ and a ‘Flex’ project. As the ‘infrastructure services’ space is located underground this is not visible in Figure 4.

5.2. Functional Spaces and Project Requirements

Requirements formulated in zoning plans govern on an overarching level how the land can be used and developed in specific development areas. In this study, the requirements extracted were collated as tangible and intangible requirements. These are exemplified in

Table 2. Examples of tangible and intangible requirements formulated in zoning plans.

Tangible Requirements (Examples)	Intangible Requirements (Examples)
Building area	Aesthetics
Building height	Availability
Building material	Communication/transportation
Colour	Landscape architecture
Noise levels/acoustics (quantitative)	Noise levels/acoustics (qualitative)
Roof angle	Stormwater management (qualitative)
Stormwater management (quantitative)	Sustainability

.

The main purpose here was to understand how project requirements, specific for each development area might affect modularity, the findings in this study were, therefore, not the requirements per se, but requirements’ impact on functional spaces. Tangible requirements were often quantitative and could be “ticked off” against platform constraints. If, for instance, a building were not permitted to exceed 10 m in height, this could then be translated into a possible number of stories in a residential building that is to be placed on the residential building area. Similarly, e.g., choices of color, or a specification of which roof angles were allowed categorizes as tangible requirements. These requirements are related to only one functional space or even a single component in a functional space. On the contrary, intangible requirements were more qualitative and often expressed, including directives on a form, such as “…should, to great extent…”, or, “…if possible…”. This meant they needed to be evaluated by a stakeholder (in this case, LPAs) and interpreted based upon the solution suggested by a house-builder (e.g., for building permits). After the interpretation from LPAs came an approval or a demand for re-work. Requirements causing re-work based on stakeholders’ evaluation of a design solution is typical for an iterative ETO design process. An example of this from the empirical material in this study was a demand from the LPAs to modify the external corridors in one project, as these were deemed not sufficiently aesthetically appealing. Further, it was deemed that buildings were “too monotonous” and that the presented solution adapted poorly to the general demand formulated in the zoning description, which was that the development area was intended as a “garden city”. There are no pre-existing—or tangible—definitions of what a “garden city” is, but it served in the zoning description as a conceptual design guideline that should aid the general design direction. A quote from the zoning description (translated from Swedish) reads, “The area’s overall structure should be designed in accordance with the words ‘garden city’, ‘residential town’, and ‘village’”. As this example shows, requirements could be formulated by LPAs rather freely. This made it difficult to, with certainty, know beforehand whether or not these are being fulfilled. The possibility to re-iterate design solutions was therefore required to facilitate interpretations of project requirements. Project requirements, as this one, therefore pinpointed the need for a more conceptual definition of modules, to manage the subjectivity from the element of interpretation. The abovementioned example also reflects the architectural dimension of house-building and the need for an architectural perspective when addressing some intangible project requirements.

To illustrate how project requirements could affect the relationship between modularity—integrality in residential building areas, this study presents two examples. Two requirements were chosen, which could—also in the same zoning plan—be formulated as both tangible and intangible requirements, namely acoustics and stormwater management. The former addresses the need for an acoustically adequate environment, and the latter, adequate management of stormwater (from, e.g., rain or melting snow).

Acoustically adequate environments are required in spaces intended for human activity, such as inside residential buildings, on garden plots, or, on social- or green areas. In Figure 5, an interplay between functional spaces is demonstrated, in which two main factors affected the overall adequacy of the solution’s response to this project requirement: physical orientation, and choice of components. The physical orientation of functional spaces addresses the relation to both surrounding functional spaces as well as the surrounding environment (e.g., from traffic or neighboring environment). Choice of components could be interpreted as different types of shielding components, such as better windows or external noise barriers. Occasionally, additional shielding from, e.g., placement of complementary buildings or additional noise barriers placed on functional spaces not intended for human activity were also needed to ensure the required adequacy. Balancing between component swapping (e.g., exchanging a window) and physically shifting the orientation of, e.g., buildings on the site during design, was an example of the large span between possible design methods available to meet a project requirement. It also demonstrated how spatial dependence might influence predefinition in platforms, as the project-specific requirement affected already predefined functional spaces (e.g., residential buildings).

For the second example, on-site management of stormwater was deemed an interesting project requirement to study, as it aims at maintaining basic functionality in a residential building area. As with acoustics, the requirements posed can be both tangible and intangible. A tangible requirement could stipulate a “maximum outflow rate of 15 L per second and hectare”, from which calculations (or simulations) could be performed to predict a satisfactory solution. The intangible requirement was more often formulated on the form “stormwater should be delayed and locally disposed of as far as possible”, providing less clear guidance towards what was expected from the resulting solution. As visible in Figure 6, an interaction between most functional spaces was needed to address both flow rate as well as flow direction and transportation of stormwater when seen through the lens of an entire residential building area. This implied that this requirement calls for coordination of design work, as it may affect many different disciplines of design (e.g., architects, landscape architects, urban water planners, etc.).

A change in either one of the functional spaces in Figure 5 or Figure 6 could affect the ability to meet the corresponding project requirement. In other words, without more holistically approaching the solution to these requirements top-down, it is unlikely that they can be successfully met. Here, integrality becomes a central issue to handle as dependencies can shift from project to project due to how project requirements are formulated. Integrality retains its centrality as different project requirements could also contradict each other. A project requirement could for instance be to ensure that there was at least a certain number of car parking lots in a residential building area, which in turn are placed on paved (or similar hard-made) surfaces. Hard-made surfaces however affect the ability to delay stormwater negatively, which thus calls for a trade-off assessment between these two requirements to ensure an adequate overall solution concerning both of these project requirements.

These examples highlight some elements of integrality visible in house-building in general and residential building areas in particular. As project requirements vary between projects, so must the final solution be adapted from project to project, which adds to the complexity of predefining and encapsulating modules. This is an exemplification of how modular logic, here modular vs. integral, could be used to further add understanding of the challenges faced in complex ETO projects. The identification of integral elements was a by-product of the approach explored in this study. And even if these were obstructive towards modularity, by expanding on how functional spaces relate to each other, as well as how their level of predefinition varies, additional insights into how they still could be regarded as partially modular could be further explored.

5.3. Levels of Predefinition and Relationship

The relationship between functional spaces and their level of predefinition provided some valuable insights in the cross-analysis between ‘Classic’- and ‘Flex’-projects. ‘Flex’-projects tended to have functional spaces that were more decoupled from one another on the development area when compared to ‘Classic’-projects. It was deemed probable that this was an effect of the conceptual site plan (see Figure 2) which for ‘Classic’ governed the overall layout of the residential building area to a larger degree. Addressing varying levels of predefinition translate in the context portrayed in this study to different degrees of customization for different functional spaces. To further detail this reasoning, Figure 7 addresses both levels of predefinition and level of relationship using the taxonomy from

Table 3. Taxonomy and context-dependent explanation.

Level of Predefinition	Contextual Explanation
Designed	Design variants based on templates and guidelines, major influence from project requirements
Modifiable	Design variants based on templates and guidelines, minor influence from project requirements
Configurable	Controlled customization, full control over platform constraints
Select Variant	Few completely predefined alternatives, full control over platform constraints
Level of relationship	Contextual explanation
Pre-set	Relationship to adjacent functional spaces is determined beforehand
Constrained	Relationship to other functional spaces affects the positioning
Placed	Placement decoupled from other functional spaces

for the level of predefinition adapted from [8] and level of relationship respectively.

The taxonomy from Table 3 was intended to illustrate the relative differences which were suitable for the context portrayed in this study, rather than as sharp definitions. As such, both ‘Modifiable’ and ‘Designed’ were supported by templates and design guidelines, but the extent to which project requirements affected them was their distinguishable factor. Figure 7 contains a comparison between ‘Classic’ and ‘Flex’, where the ascribed levels of predefinition and relationship were used to point out relative differences and similarities between both products, to characterize in what aspects they could be regarded as partially modular. The findings in Figure 7 rests thus on the assumption that a configurable (level of predefinition) functional space which can be placed freely on a development area (level of relationship) can be considered more modular than a functional space in need of project-specific design work which is also constrained through dependence to adjacent functional spaces.

The process of physically adapting ‘Residential buildings’, ‘External corridors’ and ‘Complementary buildings’ to a building site with a foundation is disregarded in Figure 7 when the level of predefinition was assessed. Inclusion would have rendered them all ‘Designed’ as this particular interface required project-specific design work to some extent. They were, in other words, regarded from above ground level (i.e., without impact from spatial adaptation).

The ‘Classic’ product did not include the functional space ‘Social area’. This is not to be interpreted as that there are no intended areas for social interaction in a ‘Classic’ product. These are instead mainly ‘Green area’ where residents are free to engage in social activity as they see fit. In the ‘Flex’ product, the functional space ‘Social area’ had more clearly directed intentions, with, e.g., designated areas for barbecue, pergolas, or playgrounds with swing-sets and sandboxes for kids play.

Figure 7 addresses differences between ‘Classic’ and ‘Flex’ in terms of their level of predefinition and their inherent relationship to other functional spaces. Both factors are related to available design space. This is to be interpreted as that there is much stronger infliction from platform constraints in a ‘Select Variant’ setting in comparison to a ‘Designed’ setting, and less ability to influence the overall layout of a final product in a ‘Pre-set’ setting in comparison to a ‘Placed’ setting. The overall assessment of Figure 7 highlights in other words in what aspects, and, to what degree the ‘Classic’ product was more rigorously controlled. With ‘Flex’, BoKlok introduced elements of configurability as it moved from Select Variant-buildings to a setting where some customization was introduced. In this instance, the ability to combine apartments more freely to diversify the end-product to enable different building types in the development area. However, BoKlok still managed to decouple design work as the individual apartments still are predefined on a Select Variant basis, hence, control over platform constraints permits configurability. On the contrary, Infrastructural services were Designed/Placed regardless of the product, it is more likely just an ETO consequence inherently connected to the house-building process itself. One that nonetheless, for some house-builders, needs support and consideration during the development of a modular platform (for a holistic representation of the product).

6. Discussion

Unintended interaction between modules affects modularity negatively [3]. If we assume that our functional spaces follow a similar logic, then, ‘Flex’ as a product is to be regarded as more modular compared to ‘Classic’. This is, as it to a certain degree has functional spaces which are allowed to be placed more freely on a development area, without other functional spaces constraining due to unnecessary interaction. At the same time, as the level of predefinition is lower in the ‘Flex’ product, more adaptation to project requirements is necessitated. This reasoning expands on the complexity in understanding in what aspects this product can be treated as partially modular. In the following section, we will discuss how this still could be used to benefit the design process in house-building as well as related research in the field of product modularity.

In the ‘Motivation of research’ section, we asked ‘why modularization of residential building areas then?’. Most importantly, we wanted to use the same approach (a modular approach) for the holistic product, and not only a sub-selection of some constituent parts. This was as holistic definitions of products are on par with every other approach towards modularization that we have come across, but where the ‘product’ is more easily demarcated (as with, e.g., consumer products). And it is easy to understand why, as anticipation of what requirements might affect the end product is at the essence of these methods. There can thus be problems if we neglect the full scope of a product, as only imposing constraints on a sub-selection of a product, leaves vulnerability to requirements affecting that which has already been constrained. We saw this when LPAs made remarks on how buildings in one project were “too monotonous”. For our case company, the buildings were already constrained, i.e., there was not that much that could be done to further reduce their monotonicity. This property is even what accounts for efficiency during production. But, without a wider understanding of requirements, it is challenging to assess to what degree constituent parts of a product are best constrained. So, while partial modularity as presented by Hvam et al. [7] suggests that either part of the product is fully modularized, or, that the entire product is modularized with lesser defined modules, we pursued the latter approach for lack of full understanding in regards to how requirements affect the end product. In hindsight, this also seems reasonable, as the accounts of integrality in residential building areas which we have exemplified in this study suggest that this type of top-down perspective was necessary for our case company.

When it comes to the usefulness of partial modularity for residential building areas, three suggestions stand out from this study; coordination of design work, use of appropriate support methods, and proper taxonomy. The first relates to the integrality of a residential building area, as decomposition into functional spaces might be used as a structure for coordination instead of traditional configuration based on predefinition. By first of all articulating each functional space’s level of predefinition and relationship, coordinators of design work can obtain a first glance into dependencies between different parts of a product. Furthermore, as different people participate in unique projects, functional spaces could be used to illustrate dependencies between design activities under an agreed-upon structure. By then re-using and refining the same structure in several projects, systematic and positive carry-over effects could perhaps be obtained. Not perhaps always a carry-over of components, but perhaps from design processes as suggested by Johnsson [34].

The second account of usefulness was more practical, as it relates to the operationalization of design support. Certain functional spaces, e.g., residential buildings in the ‘Flex’-product, could probably be supported by a seemingly traditional configuration system as in [12]. For other functional spaces, e.g., Infrastructure service, another type of support is more likely needed, as configurators simply are not intended to control design uncertainties. So, even if this study exemplifies this as a module (a functional space), it cannot be regarded as particularly modular (a module with a low level of modularity). Nonetheless, by applying the logic of modularity, dependence between functional spaces and project requirements could perhaps still be a fruitful path to illustrate the challenges and further tailor more appropriate support for aiding the design process [39,40].

The last account of usefulness relates to taxonomy. It was deemed necessary by us to suggest terminology new to both modularity and house-building literature, such as functional spaces or tangible and intangible requirements. It was also deemed useful to describe the challenges we identified in house-building using terminology from product modularity, such as integral vs. modular. By approaching a more consolidated view on taxonomy, we believe joint efforts can lead to more prosperous development.

Lastly, a comment on our emphasis on context in this study is advised. To capture what we denominate as project requirements in this study, we chose to focus on Swedish zoning regulations formulated by LPAs. Through these, we wanted to capture an essential part of why house-building is an ETO endeavor. Or at least, give examples of some aspects in which house-building is ETO. This is seen as important as not enough studies articulate both why house-building is ETO and what we can do to adapt to this. Despite this decision’s contextual influence on this study, the use of zoning regulations is by no means a mere reflection of a local or unusual phenomenon. In other parts of the world, there are somewhat similar processes to determine how land may be used or developed [41]. However, we do acknowledge that this study is formulated around a particular context. More than so, allowing the context to greatly influence this study has also been a purposefully made decision. In so doing, we on one hand refrain from claiming that our findings are generalizable outside of the context we portray. But, seeing that this has been an explorative study, it provides rather poor venues for such claims anyway. Instead, by providing detailed and concrete examples relevant to our empirical material, we rely on readers’ ability to translate our context-dependency to their context, and thus also construct their understanding of what we put forth here, which can hopefully be regarded as intriguing or relevant. Stake [42], denominates this as a naturalistic generalization, and by calling upon the competence of our readers, we think that this is a sincere approach to generalizability for an explorative study like this one.

7. Conclusions and Further Research

This study explores product modularity in the context of residential building areas. The twofold purpose of the study includes firstly to understand why product modularity is sometimes chafing against the house-building context. This can be summarized as, at least partly, due to unique requirements posed by LPAs as well as integral elements in house-building when its spatial dependence is acknowledged. The second purpose was to explore how requirements affect modularity in house-building. The study embraces house-buildings’ ETO setting without considering this a barrier to product modularity. In the case used in this study, a traditional ‘full modularization’ approach was infeasible, as the number of unique requirements in each project affected both end products in focus to a great extent. An approach to partial modularity was therefore explored, where the complete residential building area (i.e., the product) was decomposed into lesser defined modules which were referred to as functional spaces. Through these ‘modules’, this study exemplified how modular logic could be used to describe and illustrate a complex ETO product. The level of modularity was qualitatively assessed through the level of predefinition and the level of relationship. In so doing, a modular platform structure could remain, despite project-specific LPA requirements affecting each project. Even if the residential buildings could be isolated and regarded as modular, LPA requirements could still cause rework in individual projects, entailing a difficulty with a narrow product scope for the house-builder in focus, as their product can be more accurately described as a residential building area. The study’s attention to requirements also highlighted elements of integrality, which were intuitively assessed as infeasible to ‘work around’ with maintained economies of scale in a modular platform that follows the traditional ‘full modularity’ approach. As no identified methods addressed elements of integrality, this too was chafing against conventional methods for obtaining modular products. With the approach towards partial modularity that was suggested in this study, a modular logic could be retained in the projects that were studied, despite this integrality. The mere identification of integral elements was a by-product of the approach suggested in this study. And as they were from LPAs (i.e., couldn’t be ‘bargained with’), knowledge about them could potentially be a powerful tool for house-builders seeking to reap benefits from product modularity without the need for countermeasures in terms of, e.g., increased level of predefinition or level of relationship. As such, the identification of integral elements, stemming from an approach such as what is suggested in this study, could be regarded as a positive by-effect during the development phase of a partially modular platform. Furthermore, three accounts of usefulness with the partial modularity approach were proposed. The ability to coordinate design work, use of appropriate support methods, and, use of proper taxonomy.

More research, which further tests and validates the suggestions presented in this paper is needed. As development and launching of a fully partial modular platform would require substantial efforts from a house-builder, a multiple case study is advised first, for the findings of this study to be challenged against a wider context. A maximum variation strategy for case selection [36] would pose a reasonable ground for claiming generalizability. Furthermore, this study emphasizes mainly design work, a follow-up study focusing also on production could be useful to obtain a more farm-to-table approach to platforms. Lastly, a study aimed at developing more support tools that jointly can manage a platform with varying levels of modularity is suggested.