2.1. Research questions

While smart services have a tremendous potential for OEMs, adoption remains low (see Section 1). As a result, it is important to understand what technical barriers prevent smart service adoption. In addition, the current research of data-driven methods is dominated by GenAI technologies, therefore their effect on the barriers is also highly relevant. The research questions are therefore defined as follows:

1. 1. What are barriers for smart service adoption of industrial companies, especially OEMs, concerning technical development?

2. 2. How do the technical barriers to smart service adoption affect smart service subsystems and different roles in the development process?

3. 3. Which GenAI building blocks are most promising to mitigate the identified technical barriers along the smart service architecture and across roles?

2.2. Research design

We choose Scopus as our primary database, since it offers extensive coverage of engineering, computer science, and management literature, indexes both peer-reviewed journals and leading conference proceedings and provides reliable metadata and export tools for reproducibility.

The search string was constructed by enforcing the inclusion of a keyword about the topic, the domain and the specific focus of this review. In addition, only literature from the last 10 years was considered to ensure that barriers still have relevance. We used the TITLE-ABS-KEY function in Scopus, that checks whether the contained keywords are present in the title, abstract or keywords. The search string was built as follows:

• • Topic: TITLE-ABS-KEY(“smart service*” OR “product-service system*”)

• • Domain: TITLE-ABS-KEY(“manufactur*” OR “assembly” OR “production” OR “engineering” OR “industr*” OR “machinery” OR “factory”)

• • Focus: TITLE-ABS-KEY(“barrier*” OR “challenge*” OR “obstacle*” OR “limitation*” OR “hurdle*” OR “obstacle*” OR “survey” OR “review”)

We included only peer-reviewed journals and conference publications that focus on smart service development in the engineering and OEM context, specifically targeting the industrial production of complex machinery. To ensure relevance to our technical development perspective, we required that each study examine barriers of a technical nature, meaning issues that arise during the design, implementation, or integration of smart service capabilities, rather than barriers encountered by end-users or customers. We further restricted our sample to research articles that provide original empirical evidence from industry settings, such as surveys of engineering teams, case studies of pilot projects, field experiments, or action-research interventions. Studies that did not focus on the company’s engineering and production processes or that lacked firsthand evidence on technical barriers were excluded.

2.3. Identification and selection of research

1136 unique records were identified with the specified search string between the years of 2015 to 2025 (as of the 7th of July 2025). 1083 records were removed after screening the title and abstract. 303 of those were removed since they conducted research in a non-industrial domain or it was a domain-agnostic paper, 780 were removed since they did not contain original evidence from industry about barriers regarding the technical development of smart services. Most of the excluded papers either contained no original evidence from industry or presented a new method or approach, not focusing on the barriers themselves. The 53 articles that remained were checked for full-text availability, three full texts were not available to the authors. Finally, after the available full texts were assessed, a further 30 articles were excluded, since reading the full text revealed that they were too broad or did not contain information about technical barriers, contrary to what could have been assumed from reading the abstracts. Figure 1 offers an overview of the process of selecting the relevant literature.

Figure 1.

PRISMA-style flow chart of article identification and screening, based on (Reference Page, McKenzie, Bossuyt, Boutron, Hoffmann, Mulrow, Shamseer, Tetzlaff, Akl and BrennanPage et al., 2021)

2.4. Data extraction, coding and GenAI mapping

For each included study, we extracted all statements that explicitly describe obstacles, limitations, or challenges encountered during the technical development of smart services. Based on this, the synthesis of barriers followed a structured qualitative coding process:

1. 1. Barrier statements were extracted verbatim from each included study.

2. 2. Similar formulations were normalized to common labels.

3. 3. Labels were iteratively grouped into higher-level categories.

4. 4. Category definitions were revised until internal coherence and cross-paper applicability were achieved.

To address RQ3, we used a targeted scoping linkage rather than a second full systematic review. We linked barrier categories to representative GenAI building blocks through barrier-specific searches and by selecting peer-reviewed approaches that (i) describe an implementable technical mechanism relevant to industrial data/software engineering and (ii) plausibly mitigate the respective barrier category. It should be noted that the resulting mapping is illustrative rather than exhaustive, which is sufficient for the purposes of this paper because it supports our goal of deriving plausible mitigation directions and a prioritized evaluation agenda, not of cataloguing all GenAI methods.

3.1. Extracted barriers

The literature was processed as described in Section 2.4, with the final categories presented in Table 1. In the following, all barrier categories will be explained in detail.

Table 1.

Identified barrier categories, number of mentions in relevant literature and examples

A. Engineering Methods, Tooling & Capability: This category refers to the availability and maturity of methods, SDKs, simulation or digital twin support, and developer skills required to engineer smart services (Reference Arioli, Pezzotta, Romero, Adrodegari, Sala, Rapaccini, Saccani, Marjanovic, Rakic and WestArioli et al., 2025). Gaps in design tooling, process guidance, and hands-on competence translate into slow, error-prone implementation (Reference Åkesson, Sundström, Johansson and ChirumallaÅkesson et al., 2023). The absence of fit-for-purpose tools and practices inhibits systematic, repeatable development (Reference Paliyenko, Tüzün, Roth and KreimeyerPaliyenko et al., 2022).

B. Data Acquisition & Quality Governance: This category concerns what to measure, how to sample, and how to ensure completeness, reliability, and usability of data from heterogeneous sources (Reference Münch, Marx, Benz, Hartmann and MatznerMünch et al., 2022; Reference Tawil, Mohamed, Schmoor, Vlachos and HaidarTawil et al., 2024). Typical issues include sensor selection, sampling rates, missing or noisy data or unstructured records (Reference Machchhar and BertoniMachchhar & Bertoni, 2021). Poor quality governance degrades downstream analytics and increases rework in pipelines.

C. Analytics & Algorithmic Limitations: This category includes shortcomings in modeling, explainability, robustness, and performance of algorithms deployed on industrial data (Reference Münch, Marx, Benz, Hartmann and MatznerMünch et al., 2022; Reference Tawil, Mohamed, Schmoor, Vlachos and HaidarTawil et al., 2024). Challenges arise from multi-modal signals, domain shift, and difficulties in translating model outputs into actionable insights. Insufficient accuracy or transparency undermines trust and delays deployment (Reference Uuskoski, Mittal, Menon and KärkkäinenUuskoski et al., 2023).

D. Integration, Interoperability & Standards: This category covers incompatibilities in data models, interfaces, and protocols as well as the difficulty of integrating legacy systems and vendor-specific platforms (Reference Pascher and WulfPascher & Wulf, 2024). The lack of common standards and robust APIs impedes cross-system data exchange and reuse (Reference Heuchert, Verhoeven, Cordes and BeckerHeuchert et al., 2020). Consequences include duplicated integration logic, fragile adapters, and limited scalability of solutions (Reference Wang, Ming, Gao and ZhangWang et al., 2025).

E. Security, Privacy & Governance: This category encompasses data protection, access control, regulatory compliance, and questions of data ownership and sharing (Reference Mueller, Stegelmeyer and MishraMueller et al., 2023; Reference Pascher and WulfPascher & Wulf, 2024). OEMs must reconcile technical integration with legal and contractual constraints. Weak controls or unclear ownership structures block data flows and restrict the design space of services (Reference Heuchert, Verhoeven, Cordes and BeckerHeuchert et al., 2020).

F. Context & Semantics: This category captures the absence of machine-interpretable context, such as missing ontologies, unified namespaces, provenance, and domain semantics (Reference Paliyenko, Lukjanenko, Tüzün, Roth and KreimeyerPaliyenko et al., 2023; Reference Sala, Pirola, Pezzotta and CavalieriSala et al., 2022). Without explicit semantics, data remain difficult to interpret, integrate, and trace across lifecycle stages (Reference Kamp, Ochoa and DiazKamp et al., 2017). The result is brittle analytics and duplicated modeling effort, especially when transferring insights across products and variants.

G. Infrastructure, Connectivity & Scalability: This category addresses runtime constraints such as network latency, bandwidth, real-time processing, storage/compute scaling, and cost-efficient operations (Reference Münch, Marx, Benz, Hartmann and MatznerMünch et al., 2022; Reference Wang, Ming, Gao and ZhangWang et al., 2025). Bottlenecks emerge from distributed assets, edge–cloud coordination, and uneven connectivity (Reference Stoll, West, Pirola and SalaStoll et al., 2023). These constraints limit the feasibility of time-critical services and increase total cost of ownership.

H. Modularity, Architecture & Reconfigurability: This category covers the architectural ability to compose, reuse, and evolve service modules across product variants and lifecycles (Reference Matschewsky, Kambanou and SakaoMatschewsky et al., 2025; Reference Pascher and WulfPascher & Wulf, 2024). Lack of modularization and variant management complicates maintenance and inflates engineering effort (Reference Larsen, Andersen, Nielsen and BrunøLarsen et al., 2019). Reconfigurability deficits hinder rapid adaptation to changing requirements and operating contexts.

There was no discernible trend in how the number of mentions of each barrier evolved over the last 10 years, which may also be due to the low sample size of 20 research articles and 60 total barrier mentions.

An illustrative example for the stated barriers would be smart services based on remote troubleshooting of faults (Reference Klein, Malburg and BergmannKlein et al., 2025; Reference Sala, Pirola, Pezzotta and CavalieriSala et al., 2024). An OEM might want to offer remote troubleshooting for special machinery using sensor data along with PLC/event logs, which needs to be analyzed in the context of maintenance tickets, manuals, configurations and similar documentation. In practice, engineers might face incomplete or noisy signals (barrier B), inconsistent naming and missing/non-traceable semantic context (barrier F), and substantial integration effort across systems and vendor interfaces (barrier D). Limited connectivity at customer sites and edge-cloud constraints further restrict the analysis (barrier B and G), which might be related to concerns regarding data security (barrier E). If the special machinery is able to be configured with different parts and functionalities, the services would also need to be designed in a modular fashion (barrier H) (Reference Klein, Malburg and BergmannKlein et al., 2025; Reference Sala, Pirola, Pezzotta and CavalieriSala et al., 2024). These issues slow or even prevent development of the services.

3.2. Mapping of barriers to architecture and stakeholders

The second research question addresses the question of which systems, and which roles are affected by the identified barriers. Answering this question helps to pinpoint heavily affected systems and roles, narrows down the solution space and helps to map out migrations. For the purpose of this paper, we use the smart service reference architecture of Reference Wegel, Sahrhage, Rabe and DumitrescuWegel et al. (2021), since it includes technical elements as well as a high level of detail for systems involved in the technical development process. Figure 2 offers an overview of a smart service reference architecture with annotations based on which elements are affected by the identified barriers.

Wegel et al.’s reference architecture extends the acatech layer model into a data-flow-oriented stack from Linked Physical Platforms (sensors, actuators, on-device processing) via Networking and IT-Infrastructure/Software Platforms up to the Service Platform and Business Model, with Security and Safety and Human–Machine Interface as cross-cutting concerns (Reference Wegel, Sahrhage, Rabe and DumitrescuWegel et al., 2021). Our mapping shows that barriers are concentrated in the middle and top of the stack: data acquisition and quality issues (barrier B) appear mainly at the physical layer, but most barriers relate to data and resource management, analytics, and integration (barriers C, D, F, G) in the Networking, IT-Infrastructure and Software Platform layers, where heterogeneous data must be stored, enriched with context and semantics, and transformed into explainable insights (Reference Kamp, Ochoa and DiazKamp et al., 2017; Reference Tawil, Mohamed, Schmoor, Vlachos and HaidarTawil et al., 2024; Reference Wang, Ming, Gao and ZhangWang et al., 2025). Near the top of the stack, barriers around governance, modularity and architecture design (barriers A, E, H) constrain how service processes, roles and adjacent IT systems (e.g. ERP) can exploit these data services (Reference Åkesson, Sundström, Johansson and ChirumallaÅkesson et al., 2023; Reference Matschewsky, Kambanou and SakaoMatschewsky et al., 2025; Reference Pascher and WulfPascher & Wulf, 2024). This yields two key insights: (1) resolving mid-stack barriers around data management, semantics and integration is likely to have the largest leverage on smart-service development, and (2) governance- and architecture-related barriers propagate vertically across all layers, so they cannot be solved locally within individual components of the stack.

Figure 2.

Identified barriers in relation to the smart service reference architecture based on Wegel et al. (Reference Wegel, Sahrhage, Rabe and DumitrescuWegel et al., 2021) extended with identified barriers

Figure 2 Long description

A diagram of the barriers in relation to the smart service reference architecture. The diagram is structured into several horizontal layers representing different components and processes. The layers include Business Model, Service Platform, Software Platforms, Networking, and Linked Physical Platforms. Each layer contains specific elements such as Application Scenario, Service Processes, Roles, Adjacent IT-Systems, Data Analysis, Billing, Data Storage, Preprocessing, Data and Resource Management, Communication Systems, Information Processing, Actuators, Sensors, and Basic System. Various barriers labeled as Barrier A, Barrier B, Barrier C, Barrier D, Barrier E, Barrier F, Barrier G, and Barrier H are placed within these layers, indicating points of potential challenges or obstacles. The barriers are connected to specific elements within the layers, suggesting their impact on those elements. The overall structure of the diagram shows the flow and interaction between different components and processes within the smart service reference architecture, highlighting areas where barriers may affect the system.

Shifting focus from systems to development teams, Figure 3 shows which roles from a typical analytics department (role definitions adapted from (Reference Kühn, Joppen, Reinhart, Röltgen, Enzberg and DumitrescuKühn et al., 2018)) are affected by which barriers. If barriers are drawn between roles, it indicates that both roles are (partially) affected.

Figure 3.

Mapping of roles of an analytics department to barrier categories

All four core roles in analytics-driven smart service development are affected by the identified barrier categories. Data Engineers are mainly associated with Data Acquisition & Quality Governance (B), Integration, Interoperability & Standards (D), and Infrastructure, Connectivity & Scalability (G), reflecting their responsibility for deciding what to measure, connecting heterogeneous systems, and operating scalable data pipelines (Reference Kamp, Ochoa and DiazKamp et al., 2017; Reference Münch, Marx, Benz, Hartmann and MatznerMünch et al., 2022). Data Scientists are primarily exposed to Analytics & Algorithmic Limitations (C) and Context & Semantics (F), since they must build models on top of imperfect data and often lack a consistent semantic representation of machine states and events (Reference Kamp, Ochoa and DiazKamp et al., 2017; Reference Wang, Ming, Gao and ZhangWang et al., 2025). Domain Experts face Engineering Methods, Tooling & Capability (A), Context & Semantics (F), and Modularity & Reconfigurability (H), as they contribute operational knowledge, define service variants, and validate whether technical solutions match real-world needs (Reference Larsen, Andersen, Nielsen and BrunøLarsen et al., 2019; Reference Matschewsky, Kambanou and SakaoMatschewsky et al., 2025). The Analytics Architect spans Engineering Methods & Tooling (A), Security, Privacy & Governance (E), and Modularity & Reconfigurability (H), setting standards and guardrails across projects.

Two insights emerge from this mapping. (1) all roles are systematically affected; technical barriers are not confined to “data people” but shape work across engineering, data science, and domain expertise. (2) data-engineering-related work is most affected: in our mapping, the Data Engineer role is linked to three barrier categories at full strength, roughly twice as many assignments as any other role. This suggests that many technical barriers manifest first as data-engineering challenges, making this role a critical leverage point for mitigation.