=Paper=
{{Paper
|id=Vol-3645/forum5
|storemode=property
|title=Module and interface: Towards a cross-disciplinary understanding based on
quantified product design
|pdfUrl=https://ceur-ws.org/Vol-3645/forum5.pdf
|volume=Vol-3645
|authors=Kurt Sandkuhl,Ulf Seigerroth
|dblpUrl=https://dblp.org/rec/conf/ifip8-1/SandkuhlS23
}}
==Module and interface: Towards a cross-disciplinary understanding based on
quantified product design==
https://ceur-ws.org/Vol-3645/forum5.pdf
Module and interface: Towards a cross-disciplinary
understanding based on quantified product design
Kurt Sandkuhl1,2, Ulf Seigerroth1, Dan Lennartsson1 and Dag Raudberget1
1
School of Engineering, Jönköping University, Jönköping, Sweden
2
Institute of Computer Science, Rostock University, Rostock, Germany
Abstract
In the interdisciplinary work of computer scientists and mechanical engineers on integrating IT components
into physical products and creating products-services-systems, we observed that design and development
processes cross-cutting the traditional boundaries of disciplines reveal unexpected differences in seemingly
easy-to-define and understood terminology. More concretely, at first glance, the terms module and interface
have the same meaning in both disciplines. Still, substantial differences became apparent when
implementing design and development processes for products that extend a traditional physical product by
IT-controlled functionality and customer services. Motivated by an example of quantified product design,
this paper analyses commonalities and differences between the meaning of module and interface in the
involved disciplines. We propose an integrative definition with the term "interface" in its focus.
Keywords
Module, Modularization, Interface, Quantified Product, Digital Transformation1
1. Introduction
The digital transformation of enterprises and their business models has been subject to much research
during the last decade. Digital transformation is "concerned with the changes digital technologies can
bring about in a company's business model, which result in changed products or organisational
structures or in the automation of processes" [1]. In this context, research areas attracting much
interest are, to take only some examples, new kinds of products and services, such as smart connected
products [2] and quantified products [3]. Research in this area often involves various scientific
disciplines, for example, computer science, business administration, mechanical engineering,
industrial organisation or social sciences. In our own research on integrating IT components into
physical products and creating product-service systems, we observed in interdisciplinary work with
mechanical engineers that design and development processes cross-cutting the traditional boundaries
of disciplines reveal unexpected differences in seemingly easy-to-define and understood terminology.
More concretely, the terms module and interface at first glance have the same meaning in both
disciplines, but when implementing design and development processes for products that extend a
traditional physical product by IT-controlled functionality and customer services building upon this
functionality, substantial differences become clear. This motivates an investigation into the concepts
of module and interface, including the definition of a joint understanding.
Motivated by an example of quantified product design, this paper analyses commonalities and
differences between the meaning of module and interface in the involved disciplines. We propose an
integrative definition with the term "interface" in its focus and identify required changes in the
engineering process. In the field of information science, the challenge addressed is the transition from
an overloaded semantic concept “module” to a concept definition accommodating and
operationalising the required differences in semantics. The contributions of our work are (a) an
Companion Proceedings of the 16th IFIP WG 8.1 Working Conference on the Practice of Enterprise Modeling and
the 13th Enterprise Design and Engineering Working Conference, Vienna, Austria, November 28 - December 1, 2023
kurt.sandkuhl@uni-rostock.de (K. Sandkuhl); ulf.seigerroth@ju.se (U. Seigerroth); dan.lennartsson@ju.se (D.
Lennartsson); dag.raudberget@ju.se (D. Raudberget)
0000-0002-7431-8412 (K. Sandkuhl); 0000-0002-5881-0669 (U. Seigerroth)
© 2023 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
ceur-ws.org
Workshop ISSN 1613-0073
Proceedings
analysis of the semantics of "module" in different disciplines, (b) a conceptual model integrating the
view from mechanical engineering, information systems engineering and service engineering, and (c)
a proposal how to apply this conceptualisation in an engineering process.
The paper is structured as follows: Section 2 introduces the research method applied. Section 3
summarises the theoretical foundation. Section 4 contains an industrial case study from QP
engineering that motivates the work. Section 5 analyses the concepts of "module" and "interface" from
the viewpoint of different engineering disciplines. Section 6 proposes a conceptual model combining
the different viewpoints and showing its integration into an engineering methodology. Section 7
applies the conceptual model in the industrial use case. Section 8 summarises the findings and
discusses future work.
2. Research approach
This paper is part of a research process aiming at technological and methodical support for
engineering quantified products (QP). It follows the paradigm of design science research [4] and
concerns a design artefact developed in this project, a conceptual model expressing an integrative
understanding of the concepts "module" and "interface" for mechanical engineering, information
systems engineering and service engineering. The research question for this paper is: In the context
of QP engineering, how can the meaning of "module and "interface" be defined and integrated into
engineering processes? Sub-questions are (a) What are differences between mechanical engineering,
information systems engineering and service engineering in the use of “module” and “interface”? (b) What
would be a common conceptual understanding of module and interface? (c) How to integrate this joint
understanding into QP development?
This paper combines two different streams of previous work: research on modularisation [5] in
mechanical engineering and work on quantified products [6] in information systems engineering.
The research approach used for developing the artefact is a combination of literature study,
exploratory case study and prototyping. Based on the RQ, we identified research areas with relevant
work and analysed the literature (sec. 3 and 5). The purpose of the analysis was to find relevant related
work and examples for the cross-disciplinary use of the terms module and interface. As the literature
study showed a lack of work in this field, we conducted a qualitative case study (sec. 4). According to
[7] the case study in this paper is exploratory, as it is used to explore cross-disciplinary engineering
work in its real-world environment. Based on the case study material and the literature, we derive a
conceptual model expressing the meaning of module and interface (sec. 6). and propose its integration
into the engineering process (sec. 7).
3. Background and related work
3.1. Engineering product-service systems
Product-service system is commonly used as a term describing the combination of (digital or physical)
products with services accompanying them or enabled by the product. Various techniques and
technologies have been identified, which can be applied to implement product-service systems. For
the combination of physical products with IT components and services, development methods for
cyber-physical systems (CPS) are most relevant. An overview of methodologies in this area is
provided in [8]. The conclusion of this overview paper basically is that the conceptual design phase
and system design phase have to be distinguished. In both phases, physical process, computation, and
integration of physical process and computation need to be modeled, which essentially requires
modelling approaches from the participating disciplines. From an information system (IS) perspective,
the IT part can be considered as a specific category of information systems. Thus, methods for IS
development can be considered as contributing to product-service system development.
The development of digital services builds on a long tradition of information systems engineering
[9], business process engineering [10], capability management [11], and enterprise modeling [12].
Each of these specializations of, what might be broadly called, enterprise and information systems
engineering have developed their own strategies to deal with the need to tackle integration of
requirements from different stakeholders, like those posed by the connection to physical products.
Systems and service innovation is an inherently collaborative process involving different partners
and stakeholders.
3.2. Quantified products
Work on QP is related to various research streams of the past years with a focus on turning data into
value. Service sectors start to "collect data on everything" [13] to achieve automation and increased
efficiency. Smart connected products (SCP) are not only a category of CPS products but also represent
a business model category characterized by IT- and data-based services [2]. The term quantified
vehicle adapts this idea for the automotive industry as a complete ecosystem for using data for data-
driven services [14].
Products are often equipped with sensors, e.g., for capturing geographic positions, energy
consumption, usage profiles or other information pertinent to operation and maintenance of the
product. Such products also collect additional data, which could be of interest for third parties. For
instance, suppliers want to know how their components are used in the field [15].
For the definition of the term quantified product, we differentiate between product data
traditionally captured during product life-cycle management (PLM) and data collected by
manufactured individual copies of a product, which we refer to as product instances: "A Quantified
Product is a product whose instances collect data about themselves that can be measured, or, by
design, leave traces of data, including operational, physical, behavioral, or environmental information
for the purpose of data analysis and (optional) data sharing and services" [3].
Often enterprises quantify the products by (a) collecting data not only from a single device but the
entire fleet of products operating in the field, (b) using this data for monitoring and real-time control
in a management system for the fleet, and (c) offering aggregated data on marketplaces.
Implementation of QP is accompanied by substantial changes in the companies' PLM of QP, as
different kinds of products and their life-cycles have to be coordinated: the actual physical product;
services built upon data from connected physical products and fleets of products, data-driven services
using the fleet data for ecosystem services. Coordination of these different life-cycles requires both
organizational, infrastructural, and technical solutions.
4. Industrial case of QP engineering
This section summarizes the design and content of a case study on QP engineering performed in the
manufacturing industry. The purpose of the case study was twofold: on the one hand side we intended
to study if different engineering disciplines address the task of modularizing products and services in
different ways and show a different understanding of the terms module and interface. On the other
hand, we wanted to analyze the actual engineering processes and the artefacts used to specify
modules.
4.1. Case study design
In order to investigate potential differences between engineering disciplines in understanding what
a “module” is, we had the possibility to study a developer of quantified products from the
manufacturing sector. Within this enterprise, we had the possibility to collect information in several
ways:
• One researcher worked during several months as part-time member of the development team
for power garden products at the enterprise. The researcher maintained a work diary and
collected information about the work processes, technologies used and practices by taking
notes.
• The enterprise offered access to the documentation accompanying the development process
(including specifications and models).
We defined two propositions P1 and P2. P1: The case shows differences between the involved
engineering disciplines in the understanding of modules and modularization. P2: Artefacts
documenting modularization and module specifications can be observed in the case study. To set clear
boundaries for the case we defined that only data collected during the work in the development team
in the organization units responsible for power garden product shall be taken into account. Not
subject of the case study are other organization units of the enterprise, product and services provided
to other market segments, the clients of the enterprise and sub-suppliers used for QP engineering.
4.2. Summary of case study data
The case study used in this paper is related to a research project conducted with a producer of garden
and outdoor products for both, the consumer and business market (robotic and conventional lawn
mowers, various sizes and types of chainsaws, garden tractors, watering systems, trimmers, and other
devices). The business line "outdoor products" was the main partner in this research project that
focused on the shift from products without connectivity to the Internet to smart and networked ones
(QPs). The core objective of the business line was to develop an ecosystem of products and services
that extends the conventional (physical) product lines and offers a common application architecture
and service infrastructure. The ecosystem is meant to include different profit centers of the business
line with their services and products, as well as product and services from external companies. The
products in most cases have built-in electronic components implementing networking and
communication capabilities where the product components connect to a common services
architecture and infrastructure. The embedded systems and infrastructure services primarily are
controlling the mechatronic components in the product, but also used for collecting data when the
product is in operation. The data includes, e.g., status of mechatronic components, performance data
and service information, or information from the product's operational environment.
The QP in focus of our investigation is the robotic lawn mower (RLM). RLMs are connected via a
wireless connection to a base station installed at the point of operation. The base station in turn is
connected to the Internet and the service infrastructure of the case company for providing software
updates and services to the RLM. When installed at end-consumers, the RLM also provides operations
data to the base station. When installed at business customers, like, e.g., garden service providers,
RLMs commonly are operated as a fleet of robotic mowers. The case company provides fleet
management services and the required data collection through a cloud-based platform.
In the development of the RLM, several disciplines cooperated, like mechanical engineers for the
physical components (e.g., chassis, cutting unit, clutch, or wheels), electrical engineers for embedded
systems and electrical parts (e.g., motor, control unit, battery, or sensors), software engineers for
integration with back-office software and cloud, and business engineers for ecosystems service design
and business process integration. The management set the objective of a modular design allowing for
reuse of components and platform concepts for product lines. Work on the product architecture
revealed differences in the understanding of the involved disciplines what a module is.
5. Different perspectives on modularization
5.1. Modularization in mechanical engineering
From a mechanical engineering perspective, modularization can make companies more competitive
by enabling scale of economy, reduce costs, and improve product quality [16], and also enable
companies to better adapt to changing market conditions and customer needs [17]. All modular
approaches are built upon a product architecture. The importance and role of product architecture
for physical products is described in [18]. Here, the core building block are the physical modules,
defined as a "group of components that can be combined and integrated with other modules to create
a product or a system". The goal is to organize components into standardized units that perform a
specific function and that are prepared to be integrated into a larger system and can be swapped out
or replaced without having to modify the entire system. Scholars have presented several
modularization approaches supposed to meet industrial needs, including design with modules,
identification of modules, design of modules, modular architectures and economic perspectives on
modularity.
A practical challenge has been the lack of a coherent module definition. In spite of decades of
research effort, the term module is ambiguous, as [19] discuss. [20] identify the common denominator
of module definitions in literature, into the definition of modular product design as the "activity of
designing a product that is made up of modules". The authors further discuss the how the definition
can be applied to the data-driven services in the ecosystem, where modules can be considered as
groups of service components leading to a partial function of the overall service or product service
system (PSS). In the Modular Function Deployment (MFD) framework [21], modules are defined as "a
collection of technical solutions that perform a function, with standardized interfaces selected for
company-specific strategic reasons".
The specification of interfaces is critical in modularization and include more aspects than the
physical connection between components [22]. Smart connected products or quantified products are
characterized by a high integration and interaction between physical elements and software and
services, which emphasize the importance of interfaces, which has been add addressed by [23]. [24]
further argue that the importance of interfaces grows as part of an increasing product complexity,
where interfaces are enablers for both smart products and for the circular economy. Consequently,
there is a need for a structured approach to both manage and design interfaces through the product
lifecycle and reuse them between product architectures and generations. Operationalizing interface
design is not straightforward, requiring both the action of interface design and stringent
documentation of interfaces in separate documents, to highlight the importance [23].
5.2. Modularization in information system engineering
In computer science, the concept of modularization and the use of modules is one of the essential
concepts in software engineering education. The seminal paper by Parnas [25] was very influential
for research in this area. In software engineering, a module is a self-contained unit of functionality
that can be used independently or as part of a larger software system [26]. A module is typically
designed to perform a specific task or set of tasks and has well-defined inputs and outputs. The
purpose of a module is to simplify software design and development by breaking down complex
systems into smaller, more manageable components. Modules can be used to enhance code
reusability, improve code maintainability, and facilitate teamwork by allowing developers to work on
specific parts of a system independently [27]. The view of IS engineering is very close to software
engineering. A module is designed to perform specific tasks or functions within a larger system.
Modules can be thought of as building blocks that can be combined together to create an IS. Each
module has a well-defined purpose, inputs, and outputs, and can be developed and tested
independently of other modules.
An interface, on the other hand, is a shared boundary between two or more modules, components,
or systems. It defines the protocols, methods, and data formats that are used to integrate and apply
modules [28]. Interfaces are important because they enable different parts of a system to interact with
each other, regardless of the underlying implementation. This makes it easier to replace or upgrade
one component without affecting others. Interfaces are also used to enforce software architecture and
design patterns, as they provide a clear separation between the implementation and the functionality.
Both modules and interfaces are essential concepts in information systems engineering because
they promote modularity, encapsulation, and abstraction. Modularity refers to the practice of
breaking down a complex system into smaller, more manageable components. In software
engineering, encapsulation refers to the practice of hiding the implementation details of a module or
component from the outside world. Abstraction refers to the practice of presenting a simplified
interface or model of a complex system. These practices make it easier to design, develop, test, and
maintain software systems, and are key factors in ensuring software quality and reliability.
5.3. Modularization in service engineering
In the service sector, the work of Simon has been very influential on service modularity concepts and
approaches. Simon addresses the possibility of reducing complexity or organizational tasks by
breaking them down into units [29]. The main idea of modularity is that a complex system can be
built from smaller parts (modules), which can be designed, developed and improved independently,
but still function together as a whole [16]. The concept of modularity is generally considered to be a
suitable solution for controlling complexity without limiting applicability of the product as it
promises a wide market coverage with limited additional costs [30].
Modules of services are defined by [31] in the context of service modularity as "a system of
components that offers a well-defined functionality via a precisely described interface and with which
a modular service is composed, tailored, customized, and personalized". Closely connected to service
modules and components is the topic of interfaces. Interfaces between service modules control the
communication and information flow between the modules [32] by defining a set of rules and
guidelines. Interfaces can be directed towards service content or service package [32]. Service
modules can contain the 'technical' service contents from which to build up the complete service
offering. Interfaces are required to connect individual modules and manage possible interactions
between their contents. Service packages contains all modules desired by a particular customer.
Interactions and linkages within the service package are required to be able to connect the various
providers involved in service delivery and allow them to exchange information about customers.
"Interfaces on the level of components are expected to manage content interactions and therefore
are concerned with the flow of service customers. Interfaces on the level of the service package are
expected to manage service provider interactions and therefore are concerned with the flow of
information. [32]”. The work by [33, 34] contains an overview about services modularity frameworks
and proposes a classification of existing work along the runtime and build-time dimension and the
dimension of modularization objective (efficiency-oriented or market-oriented). In the context of our
work, this classification is in particular interesting as it in part is based on work from mechanical
engineering emphasizes the relevance of relating concepts in both disciplines.
6. Towards an integrated concept of module and interface
The discussion in section 5 made clear that there is a lot of common ground between the disciplines,
but also some differences. Some of the important commonalities are: aim of modularization in all
disciplines is to reduce complexity by dividing the whole in smaller "units" and allow for reuse of
these units; in all disciplines, modules have interfaces; motivations for modularization include
economic (better fit for customer, higher efficiency by configurability), technical (standardized way
of documentation/configuration) and process aspects (simplify testing, variant creation). Examples of
differences are that interfaces in physical products can have to be implemented as components
whereas software engineering and service engineering clearly consider interfaces as specification
only to be implemented in modules. Furthermore, the aspects to be defined in a module interface are
quite different.
In the industrial case of QP development it became clear that a joint understanding between the
involved disciplines of what a module is and how to specify an interface would be valuable as QP
include modules of different disciplines (e.g., a physical module and a service) and interfaces to
modules of QP can include different kinds of interfaces. Design with modules and design of modular
products from economic and customer perspective would be eased with this joint understanding.
In section 6.1, we present a conceptual model that establishes a joint understanding of module,
interface and related terms for the disciplines. Section 6.2 shows how to integrate the conceptual
model into engineering processes and section 6.3 into the modelling tools supporting the engineering
processes.
6.1. Conceptual model
Fig.1 shows the initial version of our conceptual model, modelled in UML, that consists of concepts
(classes) and specialization, composition and aggregation relations. At the core of the conceptual
model are the concepts of module and interface. The definition for the term module of [16] seems to
be accepted in all three disciplines: "a unit whose internal structural elements are powerfully
connected and is relatively weakly connected to elements in other units". The module is modelled as
a concept that consist of the module definition that can be specialized into module types. With this
mechanism, specific module types for physical products, services or information systems can be
defined that share a common conceptual ground but accommodate the specifics of the discipline.
Conceptually, a product consists of modules. However, as the same product can have different
configurations (for example, for customer groups), we also need the concept of module variants, i.e.
module variants are required to allow for the configuration of modules in a product. The second
essential term in the conceptual model is interface. We define interface based on "interface" and
"interface specification" in [28] as "description of essential characteristics, requirements and
constraints at a common boundary between two or more modules". The interface concept in Fig. 1 is
an abstract concept that needs specialization. The specialization reflects the different interface types
identified in 5.1, 5.2 and 5.3, i.e., API, call, and protocol for IS modules; command & control,
field/environment, spatial, transfer and use interfaces for physical product modules; and service
provider and service communication interfaces for service modules. As interfaces can be solitary or
composed of several interfaces, we used the concept of interface specification as composite element.
Interface is related to module types via the concept of module definition.
Figure 1: Common conceptual model for module and interface for different disciplines
6.2. Integration into engineering process
Engineering processes of products and services involving different disciplines and module types often
consist of specific processes for the individual engineering disciplines and an overarching process
managing the integration of discipline-specific tasks. The common understanding of “module” allows
for the definition of the overall product and service modularization on the level of the overarching
process. How this might affect the engineering process is discussed using the example of QP
engineering.
For the engineering of QP, the integration of three lifecycles has been observed [6]: the lifecycle
of the physical product, of the data-driven services and the ecosystem consisting of the business
services. The three lifecycles are managed by a common QP management process. The models and
information developed in these lifecycles are available in a joint repository. The conceptual model
presented in Fig. 1 can be applied in and improve all three lifecycle phases, as the common
understanding of modules allows for an overall modularization of the QP that includes the
modularizations of the physical product, IS systems (data-driven services or components deployed on
the physical product), and services offered. Furthermore, the modelling of requirements and
specifications, i.e., the early phases of engineering can use the joint conceptualization for producing
aligned models. It should be noted that the definition of modules in all disciplines has to include
interface specifications which lead to composite interfaces in case of modules integrating modules
from different disciplines. The composite interface specifies the dependencies of the included
modules’ individual interfaces.
Figure 2: QP Lifecycle Processes
Figure 2 shows the three lifecycle models and their integration. On the level of the (overarching)
QP lifecycle management, the joint product and service modularization process for all engineering
disciplines involved has been added. The integrated product and service modularization model is a
new artefact in the QP models repository that interlinks the specific modularizations for physical
product, IS and services.
In addition to the integration into lifecycle processes described above, integration into modelling
methods supporting the lifecycle process is important to ensure applicability of the conceptual model
in the practice of engineering QP. Our proposal is to integrate the conceptualization into the
enterprise modelling (EM) method 4EM [12] that can be used to model the ecosystem, the services
provided and the requirements and conceptual models for the data-driven services and cyber-physical
part of the QP. A key aspect in EM is the integrated view on the various aspects of the enterprise. An
enterprise model therefore consists of a set of interlinked sub-models, each of them focusing on a
specific aspect like processes, goals, concepts, business rules. 4EM shares many underlying principles
of the, so called, multi-perspective, approaches that recommend to analyze organizational problems
from several perspectives, such as vision (goals, objectives), data (concepts, attributes), business
processes (processes, tasks, activities), organizational structure (actors, roles, organizational units).
In 4EM, the conceptualization of modules and interfaces could be operationalized as an extension
of the product/service sub-model (PSM). Our approach is to integrate the "module" concept into the
PSM meta-model by (a) changing the “component => part_of => product” path into “component =>
part_of => module variant => part_of => product”. The modified path also exists in the same way in
the conceptual model; product and component also have the same meaning in PSM as in the
conceptual model, (b) integrating all other concepts from the conceptual model into the PSM model
using the relations to module given in the conceptual model and adding them, (c) extending the visual
modelling language (notation) of 4EM accordingly.
6.3. Integration into engineering tool environment
The use case described in section 3 indicated that tool support applicable by all engineering disciplines
would ease the introduction of the common conceptualization of module and interface. From a
functional perspective, tool support would have to cover
• the actual development of the modularization for a product with modules for different
disciplines including the definition of interfaces,
• the storage or linking of all documents related to a module (e.g., interface specification,
functional description, implementation documentation), and
• retrieval/search possibilities in modules and interfaces to support reuse and new product
designs.
Figure 3: Object diagram incl. notebook for connector component (screenshot BEE-Up tool)
For the prototype implementation of such a tool we decided to use the BEE-Up2 tool in combination
with a knowledge graph based on GraphDB3. The BEE-Up tool supports different modelling
languages, such as UML, ERD or BPMN. We captured the meta-model presented in Figure 1 as UML
class diagram. Based on this class diagram, modelling of an actual module structure and the
corresponding interfaces is possible using UML object diagrams associated to the class diagrams.
Class diagram and object diagram are interlinked and provide the required functionality for
development of the modularization. BEE-Up also offers the possibility in the “notebook” of each
2
https://bee-up.omilab.org/activities/bee-up/
3
https://www.ontotext.com/products/graphdb/
model element to add attributes, create links to related resources, and define associations to other
models. This functionality can be used to implement the required linking of all documents related to
a module. Figure 3 shows an excerpt of the object diagram for the use case including the notebook
entry for the composite interface of the connector component. BEE-Up models with all information
included in the notebook can be exported to RDF. RDF in turn can be imported into a triplestore, such
as GraphDB, with the possibility to navigate the modules, interfaces and linked documents (see sec.
7 for an example). This is a simple way to implement a prototype with navigation possibilities.
7. Concept evaluation in the case study
The integrated concept of module and interface was evaluated in the case study from section 4. We
used the case study for an initial validation of both, the applicability of a conceptual model and the
process and tool integration. The RLM-related product and service integration used for this purpose
was the anti-theft service. If an RLM leaves a geographical area this is detected and interpreted as
theft or theft attempt. For business customers this service is offered as actual tracking service, where
a security service provider traces the devices in order to recover them. For end consumers, this service
is designed to send an alarm notification to the owner. From a modularization perspective, the alarm
service for the end consumer requires a location sensor module in the device, the connector module
connecting the device via base station to the cloud, the location controller software model, and the
geofencing IT service. In the version for businesses, additionally the IT-Services modules “notify
security-company” and “provide-supervision” are required. An excerpt of the modularization is
presented in Figure 3.
In the case study, we used IDL specifications for software module interfaces, WSDL for defining
IT service interfaces, a company-internal service description template, and a combination of CAD,
BOM and fact sheet for specification of the physical interface. The actual interface specifications are
stored in the company Intranet and work areas usually used of the engineering discipline responsible
for the module. Integration of the different module interfaces and related documents is done via the
information stored in the attributes of the individual modules and their interface (i.e., the BEE-Up
notebook). A knowledge graph providing access and navigation possibilities can serve as access point
to this information in the enterprise.
When using the common modularization terminology in the use case company, we observed that
the tool support described in section 6.3 should be complemented by an extension of the enterprise
modeling tool. Before working on actual product, service and IS modules, the business model
integration of products and services has to be finalized which is done by business-oriented
stakeholders within the business model lifecycle depicted on the left side of Figure 2. The business-
oriented stakeholders do not work with modules and interfaces but with products and services, and
they use other modelling tools. Thus, we extended our modeling language 4EM.
Figure 4: Example 4EM model with new concept "module" included
Based on the anti-theft service example, Figure 4 demonstrates the use of the module concept after
its integration into the PSM. For the robot lawn mower (RLM), there is an add-on product, called
"connector", that is part of the anti-theft service and connects the RLM to the Internet, which requires
the module "communication unit". With this connector, an anti-theft service can be implemented. The
anti-theft service module requires a combination of service (alarm service) and physical module
(geofence unit). From a 4EM perspective, the visual language of PSM in this example has a new symbol
representing all types of modules. The model excerpt in Figure 4 also demonstrates the integration
with other 4EM sub-models, like the actor and resource model (role "product manager" as responsible
actor for the product RLM connector), the process model (process "sales and CRM") and the goal
model (goal "to provide add-on comfort-functions" that motivates the RLM connector product.
It should be noted that the model excerpt originates from an early phase of QP modelling. The
4EM approach tolerates relaxing the constraints on concept use in early modelling phases, which
allows for applying module instead of module variant. Module variants would have to be decided on
in later modelling phases when production constraints are integrated into the model. For the support
of enterprise modelling with 4EM when planning adaptations on business model level, we plan to
incorporate the changes in 4EM’s product service model in the 4EM tool4.
8. Summary and future work
Motivated from experiences in a case of quantified product design, the paper aimed at investigating
differences between different disciplines in modularization and the use of module and interface. For
QP and other smart connected product, the cooperation between mechanical engineers, software or
information systems engineers and experienced service developers is mandatory. This cooperation
can be eased if modularization concepts and model reuse works across the disciplines. A common
understanding expressed in a conceptual model is a foundation for this.
For physical products, [5] conclude that a clear alignment with the business goals is crucial for
achieving a product-strategic modularization that lets the resulting modular system reach its full
potential. Based on our experience, we claim that this view is applicable also to software engineering
4
https://austria.omilab.org/psm/content/4em/download
and service engineering domains. Methods and tools developed for designing the business case,
setting goal values for product/system features and interface alignment should therefore be used in
all three domains.
Our current work has a number of limitations. The data presented in section 4. were only collected
in two projects of one domain, i.e., they are not representative. The conceptualization was tested only
in one case and has to refined and revised. Both will be part of future work. Furthermore, tool support
for module management in repositories with retrieval and version management mechanisms need to
be investigated.
References
[1] T. Hess, C. Matt, A. Benlian, and F. Wiesböck, "Options for formulating a digital
transformation strategy," MIS Quarterly Executive, vol. 15, no. 2, 2016.
[2] M. E. Porter and J. E. Heppelmann, "How smart, connected products are transforming
competition," Harvard business review, vol. 92, no. 11, pp. 64–88, 2014.
[3] K. Sandkuhl, "Features of Quantified Products and Their Design Implications," in International
Baltic Conference on Digital Business and Intelligent Systems, 2022, pp. 152–163.
[4] A. R. Hevner, S. T. March, J. Park, and S. Ram, "Design science in information systems
research," MIS quarterly, pp. 75–105, 2004.
[5] D. Lennartsson, D. Raudberget, K. Sandkuhl, and U. Seigerroth, "Modularisation Metrics‐
Contrasting Industrial Practice and State-of-Research," Proceedings of the Design Society, vol. 2,
pp. 2483–2492, 2022.
[6] K. Sandkuhl, N. Shilov, U. Seigerroth, and A. Smirnov, "Towards the quantified product-
product lifecycle support by multi-aspect ontologies," IFAC-PapersOnLine, vol. 55, no. 2, pp.
187–192, 2022.
[7] R. K. Yin, "The abridged version of case study research," Handbook of applied social research
methods, vol. 2, pp. 229–259, 1998.
[8] P. Hehenberger, B. Vogel-Heuser, D. Bradley, B. Eynard, T. Tomiyama, and S. Achiche,
"Design, modelling, simulation and integration of cyber physical systems: Methods and
applications," Computers in Industry, vol. 82, pp. 273–289, 2016.
[9] M. Snoeck, "Enterprise information systems engineering," The MERODE Approach, 2014.
[10] W. M. P. van der Aalst, A. H. M. ter Hofstede, and M. Weske, "Business process management:
A survey," Business process management, vol. 2678, no. 1019, pp. 1–12, 2003.
[11] S. Bērziša et al., "Capability driven development: an approach to designing digital enterprises,"
Business & Information Systems Engineering, vol. 57, pp. 15–25, 2015.
[12] K. Sandkuhl, J. Stirna, A. Persson, and M. Wißotzki, Enterprise modeling: Springer, 2014.
[13] V. Mayer-Schönberger and K. Cukier, Big data: A revolution that will transform how we live,
work, and think: Houghton Mifflin Harcourt, 2013.
[14] C. Kaiser, "QUANTIFIED VEHICLES: DATA, SERVICES, ECOSYSTEMS," 2022.
[15] P. Farahani, C. Meier, and J. Wilke, "Digital supply chain management agenda for the
automotive supplier industry," in Shaping the digital enterprise: Springer, 2017, pp. 157–172.
[16] C. Y. Baldwin and K. B. Clark, Design rules: The power of modularity: MIT press, 2000.
[17] R. N. Langlois, "Modularity in technology and organization," Journal of economic behavior &
organization, vol. 49, no. 1, pp. 19–37, 2002.
[18] K. Ulrich, "The role of product architecture in the manufacturing firm," Research policy, vol. 24,
no. 3, pp. 419–440, 1995.
[19] J. K. Gershenson, G. J. Prasad, and Y. Zhang, "Product modularity: definitions and benefits,"
Journal of Engineering design, vol. 14, no. 3, pp. 295–313, 2003.
[20] F. Borjesson, R. Fancher, and U. Sellgren, "On a methodology for component selection in
modular branding: An industrial pilot study," Concurrent Engineering, vol. 22, no. 2, pp. 93–105,
2014.
[21] G. Erixon, Modular function deployment, 1998.
[22] D. V. Steward, "The design structure system: A method for managing the design of complex
systems," IEEE transactions on Engineering Management, no. 3, pp. 71–74, 1981.
[23] B. Bettig and J. K. Gershenson, "The representation of module interfaces," International Journal
of Product Development, vol. 10, no. 4, pp. 291–317, 2010.
[24] D. Lennartsson, D. Raudberget, U. Seigerroth, and K. Sandkuhl, "An Approach Towards
Operationalization of Modularization Interfaces for Industrial Product Development," 2022.
[25] D. L. Parnas, "On the criteria to be used in decomposing systems into modules,"
Communications of the ACM, vol. 15, no. 12, pp. 1053–1058, 1972.
[26] A. Abran, J. W. Moore, P. Bourque, R. Dupuis, and L. Tripp, "Software engineering body of
knowledge," IEEE Computer Society, Angela Burgess, vol. 25, 2004.
[27] I. Sommerville, Engineering software products: Pearson London, 2020.
[28] I. S. ISO, "IEC/IEEE 24765: 2010 systems and software engineering-vocabulary," IEEE Standards
Association, vol. 24765, p. 418, 2010.
[29] G. J. Klir and H. A. Simon, The architecture of complexity: Springer, 1991.
[30] S. Pekkarinen and P. Ulkuniemi, "Modularity in developing business services by platform
approach," The International Journal of Logistics Management, 2008.
[31] T. Tuunanen, A. Bask, and H. Merisalo-Rantanen, "Typology for modular service design:
review of literature," International Journal of Service Science, Management, Engineering, and
Technology (IJSSMET), vol. 3, no. 3, pp. 99–112, 2012.
[32] C. de Blok, B. Meijboom, K. Luijkx, J. Schols, and R. Schroeder, "Interfaces in service
modularity: a typology developed in modular health care provision," Journal of operations
management, vol. 32, no. 4, pp. 175–189, 2014.
[33] A. Lubarski, "Understanding service modularity-antecedents, processes, and
operationalization," Universität Bremen, 2019.
[34] J. Pöppelbuß and A. Lubarski, "A classification framework for service modularization
methods," Enterprise Modelling and Information Systems Architectures (EMISAJ), vol. 13, 14‐1,
2018.