Decision-Driven Analytics in Smart Factories: Enterprise Architecture Framework for Use Case Specification and Engineering (FUSE)

Abstract

This paper presents a comprehensive design framework for Enterprise Architecture aimed at facilitating decision-driven analytics in smart factories. The motivation behind this research lies in challenges faced by manufacturing companies, such as skilled labor shortages and increasing global competition, alongside the imperative for sustainable production. This journal provides a novel approach for designing and documenting prescriptive analytics use cases in manufacturing environments. The framework addresses the need for effective integration of advanced data analytics and prescriptive analytics solutions within existing production environments, thereby enhancing operational efficiency and decision-making processes. A Design Science Research approach is used to iteratively derive a framework based on stakeholder needs and activities along the prescriptive analytics use case development cycle. The resulting framework is demonstrated and evaluated in an IoT Factory setup in a research facility. From a practical perspective, the framework supports manufacturing companies in systematically designing prescriptive analytics use cases. From a research perspective, it contributes to the body of knowledge on Enterprise Architecture Management (EAM) by operationalizing the design of prescriptive analytics use cases in manufacturing contexts. The main contributions of this study include the development of a framework that supports the planning, design, and integration of prescriptive analytics use cases. This framework fosters interdisciplinary collaboration and aids in managing the complexity of data-driven projects.

1. Introduction

Manufacturing companies in Germany are currently confronted with significant challenges. An acute shortage of skilled workers, intensifying global competition, and the transition toward sustainable production are shaping a complex and demanding environment [1] (p. 11), [2] (p. 8), [3] (p. 14). New technologies present promising opportunities to address these challenges by enabling rationalization, boosting efficiency, and enhancing processes [1,4].

Prescriptive analytics, as part of data analytics, refers to the recommendation of actions or measures based on (partially) automated decision-making [5]. Prescriptive analytics supports the implementation of automated action recommendations within the vision of Industry 4.0. Prescriptive analytics use cases form the foundation for autonomous systems and can provide valuable support, especially in production. Despite various obstacles on the path to realizing the Industry 4.0 vision, more and more advanced data analytics solutions are being integrated into production environments [6] (p. 3). Data analytics plays a key role in optimizing production [7] (p. 438). While data analytics solutions are already widespread in non-industrial contexts, they often remain limited to individual pilot projects and isolated solutions in production and mechanical engineering [1] (p. 32), [8] (p. 149).

Nevertheless, prescriptive analytics solutions are still rarely established in practice. One of the main reasons for this is the lack of support for the holistic development (planning, design, and integration) of prescriptive analytics solutions. To provide support for planning, design, and integration, a framework (called FUSE) for prescriptive analytics solutions in production is developed. It is based on the Archimate Modeling language and tailors to the specific needs of designing prescriptive analytics use cases in manufacturing.

The target group of the FUSE Framework consists of manufacturing companies that have already implemented an initial set of analytics use cases in production. It is also beneficial if the company IT uses Enterprise Architecture Management (EAM) methods already. If this is not the case, the effort required in the corresponding phases increases. Due to the necessary resources and organizational structures, these prerequisites are more typical of large enterprises. It is also assumed that the existing production system is already in place. Application to the design of new production facilities or the development of new production systems is not the focus. The role of the analytics architect is the primary audience for this work.

The paper is structured as follows. First, the necessary foundations are touched upon in chapter two (Industry 4.0 and analytics use cases). The problem is further analyzed following the analytics use case development process in chapter three. The existing state of the art is presented and analyzed. Based on this, the research methodology is presented (chapter four). Chapter five provides an overview of the FUSE Framework. The FUSE Framework is evaluated in chapter six. Finally, the results and limitations are discussed, future work is presented, and a conclusion is drawn.

2. Foundations

The concept of Industry 4.0 summarizes the integration of new technologies into manufacturing processes, aiming to create smarter, more efficient, and interconnected production systems [9] (p. 3). The implementation of the Industry 4.0 vision is leading to an increasing degree of digitalization in manufacturing companies [7,10] (p. 438). Digital processes and machines enable greater availability of data, but this data is not always immediately accessible for analysis [6] (p. 3). At the same time, the technology for generating insights from this data (data analytics) is continuously evolving [1] (p. 10), [11,12]. Acceptance of data analytics solutions and the use of artificial intelligence methods is also growing [1] (p. 28), [13] (p. 22).

Up to the level of predictive analytics, individual solutions have already been established in manufacturing companies [1,4]. Building on this, prescriptive analytics promises not only the automation of decision-making processes but also greater independence from individual decision-makers, helping to reduce human errors in processes [8] (p. 111), [14] (p. 58), [15] (p. 798).

Gartner predicts in its annually published 2022 Hype Cycle that the technology field of prescriptive analytics will reach its full potential within the next three to five years [16]. Companies like BMW also list this technology field in their trend radar as one of the top three technologies that should be addressed immediately [17]. By focusing on decisions, aspects such as the quantification of decision objectives, the modeling of complex systems, and the handling of uncertainties are gaining greater importance [18] (p. 292), [19] (p. 140). The use of decision support systems is steadily increasing [1] (p. 28). However, prescriptive analytics use cases currently play only a minor role in real life manufacturing, and their adoption in German-speaking countries lags behind the international standard HHS24, S. [1].

The development of data analytics use cases is often additionally hindered by a lack of extensive knowledge and capabilities [20] (p. 46). Analytics use cases are planned as lighthouse projects, and there is still a lack of support for scaling the solutions in production [21] (p. 180). This is partly due to the lack of transparency regarding the monetary benefits of more complex solutions when planning analytics use cases [6] (p. 3), [22,23,24]. The planned use cases need to be further detailed for implementation. The step of design used for this purpose is a largely overlooked topic for increasing efficiency in the development of analytics use cases [24]. In addition, the integration of the solutions to be implemented into the existing heterogeneous IT landscape and organizational structure in production must be ensured [1] (p. 32), [24,25] (p. 6), [26] (p. 39).

Thus, the design of prescriptive analytics use cases requires effective complexity management [13] (p. 22), [26] (p. 39). The complexity lies in extending the data to include the necessary actions for prescription. In addition, the use cases are more interconnected in comparison to less mature analytics use cases [14,19,27]. To realize complex prescriptive analytics use cases, design plays a crucial role. The process of designing these use cases is not sufficiently supported (e.g., via a framework) in the literature thus far.

In the following, a framework is described as something that aligns the relationships between design object, language, and tool for the purpose of architecture modeling. This alignment is achieved in this work through a modeling concept and tool support. The overarching goal of the FUSE Framework is to support the planning, design, and integration of prescriptive analytics solutions for production.

3. Problem Analysis and State of the Art

First, an overview of the overall process of analytics use case development is provided. Building on this, the existing challenges in identifying analytics use cases are discussed. The planning of analytics use cases is described and an introduction to enterprise architecture management for production is provided. The steps of design (of concept) and implementation (integration and deployment) of analytics use cases are analyzed in the last subchapter.

3.1. Prescriptive Analytics Use Cases

According to Cockburn, a use case in the classical sense of software engineering describes a possible sequence of interactions between a software system and its environment. This interaction always pursues a predefined goal, and the system is responsible for a defined portion of the interaction [28] (p. 15). A Use Case [29] (p. 4) describes a concrete solution to an application scenario.

Data Science is the science of data [5] (p. 4). Industrial Data Science (IDS) is an instantiation of the general definition of data science with a fixed domain focus on industry [30]. Industrial Data Science encompasses the use of data analysis, machine learning, and related analytical tools in industrial contexts [31,32,33,34]. It also emphasizes its interdisciplinary nature, spanning statistics, computer science, and engineering [30,35,36,37] (p. 164), [38]. Since prescriptive analytics use cases represent a subset of data analytics use cases [5], they will not be highlighted separately in the following.

The development of prescriptive analytics use cases is often misunderstood as purely an IT project. As a result, related challenges in the context of the organization, technical requirements, and business objectives are not adequately addressed [39] (p. 974).

3.2. Overarching Development of Analytics Use Cases

Industry 4.0 use case development initiatives often fail due to a lack of connection between the strategic, tactical, and operational levels [39] (p. 974). From a methodological perspective, development process models usually focus either on a use-case-specific perspective (e.g., [40]) or the overarching strategic context. At the core, the development of analytics use cases should align with the overall strategy (e.g., [41,42]). An overview of the phases in the development of analytics use cases can be found in Figure 1.

All analytics use case developments should aim to align with a company-specific data, AI, or analytics strategy [44]. The construct of a data strategy and its instantiation for manufacturing companies represents a current research topic in the domain of information systems [44]. The need for a data strategy arises from the fact that extracting targeted insights from data is not a trivial task [45,46]. Across organizations, strategically aligned prerequisites, standards, and systems must be established in order to derive insights from large volumes of data [45]. The main task of management is to ensure synchronization between the individual development initiatives.

The development of analytics use cases is initiated based on the company’s analytics strategy. Development begins with use case planning through an initial identification of use cases [43]. After successfully planning a defined set of use cases, they are then designed [43]. According to Ehrlenspiel, design describes the process of gaining an overview of the fundamental functioning of a system [47] (p. 251). There is no uniformly defined and overarching approach for the design of analytics use cases in the context of production. Nevertheless, this step is essential to support the most important phase of development: domain understanding [48]. In the subsequent implementation phase, the concepts are realized and integrated into the enterprise architecture. Integration is defined here as the linking of various IT systems with a limited number of interfaces [49]. The final implementation is characterized by the iterative nature described above [43].

The described approach is idealized and rarely found in its fully depicted form in practice. Hartmann et al. particularly emphasize that analytics use case projects exhibit a continuous nature due to ongoing maintenance and operation [48].

3.3. Identification of Analytics Use Cases in Manufacturing

To identify analytics use cases for production, there are various drivers and sources of information. Information sources can be internal or external to the company [42]. The drivers of analytics use cases are discussed in more detail below:

• Potential-induced (internal): Potential-induced analytics use cases are driven by a known business benefit in the specific application scenario [50,51]. One example is the use of analytics to more precisely determine throughput times (cf. [52]). This directly leads to increased machine utilization [52].
• Hypothesis-induced (internal): Hypothesis-induced analytics use cases serve to answer specific questions from the business domain. These usually occur once and are raised directly by the business unit [53] (p. 6), [54]
• Reference-induced (external): Reference-induced analytics use cases are introduced into an organization from outside based on proven feasibility or a favorable cost–benefit ratio and dissemination through studies (clear business benefit; see, for example, relevant studies by consulting firms or research institutions such as [55,56,57] (p. 53)).

After successful identification, the relevant analytics use cases must be selected based on defined criteria [42]. Underlying these are overarching push (management agenda) and pull (technology) mechanisms. For the adoption of new technologies and analytics use cases, a management pull may be present [13] (p. 22). This means that the implementation of specific use cases is actively driven by management. Alternatively, a technology push into the organization may accelerate the spread of IT trends [58] (p. 390). A current example is the rapid development of generative AI [13] (p. 22).

In general, analytics use case projects can be planned top-down (strategy-driven) or bottom-up (from the analysis of specific objects or problems). A combination of both approaches is also possible. What is crucial is that the selection aligns with the company’s overarching strategy [28] (p. 6). For prescriptive analytics, this challenge is particularly significant, as virtually every recurring decision in production could be supported by such use cases. This broad applicability increases the complexity of prioritization and selection, underscoring the need for a structured and strategy-oriented selection process.

3.4. Planning of Analytics Use Cases

Explicit unresolved challenges exist in the areas of the transferability of analytics use cases, the organization of multi-domain perspectives during use case development, overarching management, and various project management approaches. The transferability of use cases is primarily limited by a lack of scalability of solutions, underutilized synergy effects, and implementation efforts that are mainly conceived in silos. Furthermore, many project results never move beyond the pilot stage [1] (p. 35). Regarding the multi-domain perspective in planning, a major challenge is the lack of competencies within the specialized departments. Overarching management is made more difficult by the absence of a concept when implementing numerous separate solutions. This challenge is further intensified by the differing project management approaches between management and data science.

Especially in the field of prescriptive analytics, the aspects of organizational anchoring and integration into existing structures have not yet been sufficiently researched [26] (p. 39).

3.5. Enterprise Architecture Management for Manufacturing

The seamless integration of AI and analytics into production systems—and their architecture—is a current research topic [59] (p. 57). To successfully introduce analytics use cases, both IT and business perspectives must be considered during planning and management [37,54,60] (p. 79). Consequently, an architecture-based perspective on analytics use cases is recommended. EAM represents a systematic and holistic approach to planning, design, and integrating technical structures within organizations [61] (p. 144).

It serves as a bridge between the business and IT domains, supporting organizational management and decision-making in strategic organizational development [62] (p. 46). The importance of EAM increases with the size and complexity of the IT infrastructure to be managed [61] (p. 144). Production systems are becoming increasingly complex [63] (p. 9). The methods and tools of EAM are used to manage this architectural complexity [61] (p. 144). However, many manufacturing organizations still have a low maturity level in EAM practices [64] (p. 6).

According to Acatech, there is a lack of standardized descriptive models for production systems and decision-support use cases aimed at autonomy and adaptability [59] (p. 57). These models need to be standardized and enable interoperability with other domains and systems engineering approaches [59] (p. 57). EAM provides a range of established metamodels for modeling [60] (p. 79) which are often tailored to the specific needs of a given scenario or organization [65] (p. 111). A widely used metamodel is ArchiMate [64] (p. 14), which is tool-agnostic and supported by multiple modeling environments. In a survey conducted by the BOC Group, 80% of companies reported using an IT tool to support EAM [64] (p. 16). One such tool is Archi (Version 5.7.0 in this journal), which offers a cost-free implementation of ArchiMate [66]. However, domain-specific modeling languages often lack interoperability and a unified architectural vision—frequently separating architectural and business perspectives across languages such as UML and BPMN [60] (p. 37).

The main benefit of effective EAM lies in transparent and efficient planning and control, ultimately enabling both operational and strategic excellence in IT and business [61] (p. 154). A key management object within EAM is the capability, which describes what a company can do, without focusing on how it is achieved (e.g., through IT systems) or who is responsible [60] (p. 86). Capabilities serve to connect enterprise architecture elements (systems, static) with business elements (processes, dynamic) and overarching strategy [67] (p. 13).

Capabilities are typically visualized in capability maps for a better visual overview [60] (p. 86). These maps usually depict capabilities two to three levels deep [60] (p. 210) and group them by type—for example, IT capabilities, core capabilities, or business capabilities [68] (p. 97).

EAM was primarily designed for business-IT alignment. However, it provides a range of relevant techniques, tools, and principles that need to be analyzed in the following for the design of analytics use cases. In particular, the interdisciplinary nature and the integration of solutions into existing IT systems represent a shared challenge between analytics design and EAM.

3.6. Design of Analytics Use Cases

EAM functions as a mediator across various conflicting and uncoordinated architectural domains—including the information domain, process domain, application domain, technology, and product architecture [60] (p. 44). The design of analytics use cases forms the foundation for the subsequent development of analytics solutions. In the context of production, analytics use cases are confronted with overlapping challenges from multiple domains, all of which must be equally considered.

The development of analytics use cases typically involves interventions into the existing enterprise architecture [24]. As analytics use cases become more complex, the synchronization and management of the underlying IT architecture play an increasingly important role [24]. To scale AI and analytics use cases effectively, robust frameworks are required to manage these architectural interventions [21] (p. 180). However, for analytics use cases specifically, there is currently no established framework that standardizes the relevant perspectives. Frameworks like the Industrial AI Framework propose adopting business-, usage-, function-, and implementation-centered viewpoints [69].

Depending on the observer’s perspective, a system can be viewed from different architectural domains [60] (p. 44). These perspectives are typically not independent of one another and exhibit strong interrelations [60] (p. 123). Nonetheless, a deliberate selection of perspectives can reduce complexity during the design phase and partially decouple the individual architectures [67] (p. 12). In the context of this work, the model proposed by Bitkom is used as a reference [67]. A list of possible layers is provided in Figure 2 [67] (p. 13).

Strategy: The strategy perspective aggregates relevant strategies and goals [67] (p. 13). The scaling of analytics and AI use cases must contribute to strategic objectives [21] (p. 180); therefore, this perspective needs to be regarded, even when dealing with technical matters.

Business Architecture (Process): When viewing analytics use cases from a process perspective, the focus is on their anchoring within the organization. Additionally, the interaction flow between user and solution within the use case itself can also be considered [50,70,71]

Application Architecture and Information Architecture (Data): These two architectural views describe the IT landscape and the associated data models and objects [67] (p. 13). Application architectures may apply to the entire organization or to individual applications (e.g., only the use case [72]). Similarly, data models can have a comprehensive scope (e.g., a data catalog [73]) or be limited to a single use case.

Technical Architecture: The technical architecture outlines infrastructure components (e.g., platforms or servers) needed to operate analytics solutions [67] (p. 13). This architectural view can focus on the entire factory (z. B. [74] (p. 133)) or solely on the data processing pipeline within a specific use case (e.g., [75]).

3.7. Implementation of Analytics Use Cases

Analytics use case development processes are generally designed to be iterative [76]. In the iterative implementation of analytics solutions, the Cross-Industry Process for Data Mining (CRISP-DM) is used as an overarching quasi-standard [77] (p. 13). CRISP-DM is characterized as a standard process by its application- and industry-independent design [78]. Working with standards and aligning internal processes with a reference process enables companies to collaborate in the field of analytics and to initiate cross-organizational knowledge exchange [24]. The process is coherent and well documented [79] (p. 52).

4. State of the Art

One of the main reasons for the limited adoption in practice is the lack of support for the holistic development of prescriptive analytics use cases. Designing prescriptive analytics use cases requires effective complexity management. In the area of integrating prescriptive analytics use cases into production, there is a high degree of interconnectivity with other research domains such as enterprise architecture management (EAM). The following section analyzes relevant approaches to their design.

The following approaches can be assigned to the field of action “Design of Prescriptive Analytics Use Cases.” This field of action brings together approaches that, in the form of artifacts, support the design of analytics use cases (and specifically prescriptive analytics use cases). The degree of specificity increases with the approaches presented.

Table 1. Artifacts for the design of Industrial Data Science use cases based on [24].

CRISP-DM Phase	Artifact	Explanation
Business Under-standing	Business-to-Analytics Canvas (B2A Canvas)	The use of canvases generally offers added value for the structuring of facts with the advantage of reusability within the company. This is demonstrated for prescriptive analytics by Shteingart et al. [80] and for data science projects in general by Langer and Schirrmacher [81]. The B2A Canvas is a workshop template that systematically correlates business questions, data analysis tasks and algorithms for analytics use cases in strategic product planning [54].
	Analytics Canvas	The Analytics Canvas is a workshop method for designing analytics use cases, required skills, IT resources and data sources [37].
	Layer model for cost–benefit estimation	The shell model describes an approach model and the influencing factors for the investment decision in digitalization use cases in production [82].
Data Under-standing	Data Map	The data map is a workshop method for systematically identifying data relevant to analytics that is generated in business processes [50].
Data Preparation	Framework for domain-oriented preprocessing of sensor data	The framework is used for the structured collection of data relevant for process mining in production [83]. Provision of a concept for structuring usage data from intelligent technical systems for use in analytics use cases [84].
Overarching	KPI set for future production	The authors provide an overview of 38 Industrie 4.0 key performance indicators (KPIs) [85].
	Process reference models	Process reference model for the use of data analytics in strategic product planning [86]. PAISE: Process reference model for the use of systems engineering for the development of AI systems [87].
	Maturity models	Various maturity models are proposed to describe data analysis or management in organizations [88,89,90].
	Architecture description	From the perspective of IT enterprise architecture, the Open Group Architecture Framework (TOGAF) is considered a quasi-standard [91]. Other frameworks such as the Zachman Framework (cf. [92]) or frameworks that have been removed from the military context (see list in [60] (p. 29)) are only used in instantiated form in isolated entities for the IT enterprise architecture description [93] (p. 16). Modeling of value chains according to Schneider [94]. Smart Service Modeling approach according to Rabe [95].

provides an overview of relevant artifacts for designing analytics use cases in a production context.

Thus, many specialized approaches for specific steps in the design process exist to address only tailored and specific parts of a use case architecture.

5. Research Methodology

The Design Science Research Methodology (DSRM) according to Peffers et al. is used (cf. [96]). The goal of applying the Design Science Research Methodology is to create useful artifacts for solving business-relevant problems [97]. The definition of an artifact according to March and Smith is used as a reference [97]. An (IT) artifact represents a construct, a model, a method, or an instantiation of a method. They directly assist in transforming a problem into a solution [98].

The approach for developing the modeling concept is illustrated in Figure 3, which presents the created design goals, artifacts, and additional descriptions. It is based on the development of design frameworks according to ISO/IEC/IEEE 42010:2022 and the DSRM approach according to Peffers et al. [93,96]. Details regarding each step are provided in the following chapter. For the evaluation, the resulting framework is demonstrated and discussed in light of the raised design requirements.

6. Design Framework

To determine the necessary process steps and partial models, the relevant roles and their assignment to the activities in the process model must first be defined. For this purpose, the following design requirements from the problem analysis are adhered to:

▪

Requirement 1: Applicable for manufacturing companies (Scope of this paper).

▪

Requirement 2: Support in managing synergies between use cases (ref: Problem analysis, overarching process).

▪

Requirement 3: Consideration of different perspectives for prescriptive analytics (ref: following description of roles).

▪

Requirement 4: Definition of interfaces with the existing company architecture (ref: Foundations).

▪

Requirement 5: Consideration of the integration of future technologies and algorithms to ensure broader applicability and use (ref: Foundations).

Parts of the results are based on prescriptive analytics specifics, but overall, all phases can be related to general analytics use case developments. The following phases are additionally considered in the form of accompanying activities. All subsequent activities are derived from literature and correspond to typical activities and challenges in analytics use case development projects. In Figure 4, the activities are assigned to the most relevant roles. A direct assignment of information needs (challenges, activities, and roles) to the partial models can be found in the Appendix A. The accompanying activities are supported by all involved roles and must be detailed according to the specific company context. This may also include aspects of change management and anchoring in the corporate culture.

The following presents a list of the relevant activities and information needs in the phases:

Strategic planning of use cases: Managing overarching collaboration, system integration [6] (p. 3), [33] (p. 735), [99] (p. 104) and data analytics projects [42] (p. 4), [100] (p. 2). Selecting the right use cases is essential for ensuring economic viability. In current practice, the efforts required for use case development are high due to the lack of data reuse [8] (p. 149).

Design of the selected use cases: Managing the process/interaction within the use case [100] (p. 10) and general design of the architecture [37] (p. 164), [87] (p. 7). Processes for the use of the use case must be designed [27] (p. 4). Relationships within the use case and to other use cases must be identified and designed ([37] (p. 164), [80] (p. 5), [80]). For prescriptive analytics, a structured and standardized pipeline is required (cf. [14]). In addition, there is a lack of an overview of the potentially usable data for prescriptive analytics [8] (p. 149), [43,101] (p. 63).

Synergy and Interface Consideration: A key task in the development of prescriptive analytics use cases is the alignment of IT and data infrastructures [102] (p. 11)), as well as the identification of synergies across analytics projects [24,103,104] (p. 45). Embedding analytics use case development within the organization is essential for long-term success [33] (p. 737), [105] (p. 913). In practice, the introduction of analytics solutions often fails due to insufficient integration into company-specific processes—both at the business process level [1] (p. 32) and within the specific use case interaction itself [24]. The integration into IT/OT environments is a common challenge observed in both research and industrial practice [6] (p. 3). Additionally, development initiatives typically fail due to a lack of anchoring in operational company workflows [22] (p. 119), [23] (p. 8). Analytics use cases depend on a specific IT infrastructure into which they must be integrated [106] (p. 29). Particularly for prescriptive analytics use cases, integration into both the architecture and the processes of production is critical [107]. These challenges are primarily identified by practitioners but have not yet been adequately addressed by academic research [6] (p. 9).

Preparation for implementation: In the implementation of analytics use cases, isolated solutions that are usually not coordinated with one another are often created [23] (p. 5), [39] (p. 974), [108] (p. 10). This reduces the scalability and transferability of developed solutions.

6.1. Underlying Perspectives

For the scientific development and classification of the modeling concept within the overarching process model, the following steps are carried out (cf. Figure 5). In the following, the term use case addresses only prescriptive analytics use cases.

From the overarching approach of the framework, information needs are derived. The roles (e.g., Industry 4.0 manager or data scientist) from this chapter are assigned to these information needs. The activities of the roles are supplemented with specific challenges and requirements during execution (see problem analysis). To address the challenges and activities of different roles, perspectives on the considered system are provided. Additionally, partial models are introduced to meet the requirements of the various perspectives. Partial models represent different perspectives from a model of a specific system. In the context of this work, a distinction is made between partial models and the overall model. The partial models are developed individually and are interconnected through the reuse of modeling elements. The sum of all partial models and additional modeled content constitutes the model. Modeling elements consist of attributes and are characterized by relationships, which are depicted using defined representation conventions. Based on the partial models, a specific model can be created.

The four phases of the overarching process must be supported by relevant perspectives. As described in the process model, particular emphasis is placed on supporting the phases of planning, integration, and design. An overview of the underlying perspectives corresponding to the phases is shown in Figure 6. These perspectives aggregate the necessary information to address the challenges and needs of the activities in the overarching process model. The relevant perspectives are based on the EAM dimensions according to Bitkom and Lankhorst [60] (p. 44), [67] (p. 13).

The underlying perspectives (planning, integration, and design) are based on the domains of management, analytics, IT, and production.

6.2. Partial Models

The partial models are derived from the relevant information needs and the underlying perspective. As part of this work, eleven partial models are provided for the planning, design, and integration of prescriptive analytics use cases for production. The partial models serve two main functions. They support the execution of the phases from the overarching process model. Additionally, the partial models limit the permissible set of modeling elements and provide a predefined structure.

The result is a modeling concept consisting of perspectives (planning, integration, and design) as well as domain-specific partial models. An overview of all partial models of the modeling concept is visualized in Figure 7. In the following, all partial models are briefly outlined:

Partial models for planning prescriptive analytics use cases for production

• Use Case Portfolio: The portfolio helps balance the feasibility and benefits of various use cases. Using these two criteria, the portfolio serves as an interface between the management domain and design to manage a set of use cases.
• Roadmap for Use Case Planning: The roadmap supports the transfer of planned use cases and associated data objects into a logical and time-sequenced order, with a focus on uncovering synergies.
• Prescriptive Analytics Capability Map: The capability map provides an overarching structure. It describes the capabilities that must be established within the organization for the development of prescriptive analytics use cases.

Partial models for integrating prescriptive analytics use cases into production

• Process Model: The process model is based on common process description standards (here: Data Map). It structures the relationships between business processes, data, and use cases.
• Application Architecture: The application architecture structures the applications needed for prescriptive analytics regarding operation, maintenance, and general orchestration of various use cases.
• Data Catalog: The data catalog relates and structures the available data objects in the company for potential reuse, focusing on mapping the holistic interrelationships of the company’s data.
• Technical Architecture: The technical architecture defines how prescriptive analytics use cases to harmonize with each other and are integrated into production. This view builds directly on the use case pipeline.

Partial models for the design of prescriptive analytics use cases for production

• Use Case Interaction: Use case interaction describes the communication and information exchange between the user and the solution, detailing steps and workflows of interaction, input and output data, transmitted messages, and communication interfaces.
• Use Case Architecture: This partial model focuses on the architecture of the specific use case implementation, emphasizing the linking and aggregation of all relevant resources, data, databases, and resulting use cases.
• Use Case Data: The use case data is structured into layers and related to each other, primarily to uncover the necessary interconnections.
• Use Case Pipeline: The use case pipeline describes the processing chain from the raw data of the prescriptive analytics use case to the action recommendation. It organizes the various steps and activities systematically to ensure that the use case is implemented efficiently and effectively.

6.3. Specialisation of the ArchiMate Metamodel

As outlined, the modeling concept is based on the fundamental principles of EAM. It is built upon an established metamodel to ensure conformity with other approaches and standards. Existing metamodels are often further instantiated to fit specific company requirements [104] (p. 27). In the field of EAM, there are more than 50 different approaches, each typically featuring its own metamodel [110]. An established metamodel (quasi-standard) in the field of EAM is ArchiMate [60,64] (p. 14), [111]. The concept of specializing in the ArchiMate metamodel presented below can likewise be transferred to other quasi-standards for company-specific use (e.g., the metamodel from LeanIX). The use of ArchiMate is recommended, among others, by Lick et al. for the design of production-related AI use cases [65] (p. 111). The resulting specialization is summarized in simplified form in Figure 8.

The model elements are thus organized into the main categories of strategic planning, process architecture, application architecture, information architecture, and technical architecture. Properties and attributes for each model element are not predefined but can be established as needed for specific applications (e.g., use case ID or database clear name).

6.4. Connection Concept for the Partial Models

Throughout all phases of the process, the modeling concept is consistently used as a medium for structuring, developing, communicating, and documenting the partial results. The integrated concept for linking the partial models can be supplemented by company-specific views. A more detailed development in this direction is not the core focus of this work but represents a possible extension. In practical application, it is important to find an appropriate balance between modeling depth, effort, and practicality at the time of modeling. For this purpose, the modeling concept should be applied iteratively. Accordingly, in line with the process model, modeling should begin with rough representations (e.g., only overarching processes) and be detailed as needed. The highest level of detail is reached during the handover to implementation (and further use afterward). Detailed guidance on choosing the modeling depth is not the focus of this work. However, a pragmatic, possibly semi-formal, approach to the modeling concept is generally recommended to ensure practical applicability. As environmental complexity and the number of use cases to be planned increase, a correspondingly stricter approach should be adopted.

All partial models are designed to be used consistently with one another, but each partial model also offers standalone value. From the defined partial models and the specialization, an implicit networking concept emerges. Figure 9 provides an overview of the interactions between the different elements of the specialization and the partial models. The partial models do not represent a one-dimensional view of an architectural domain (e.g., only processes or only architecture). Instead, they combine various architectural domains (e.g., data and processes) for an adequate application in analytics planning.

The relationship between partial models and metamodel elements serves to ensure the consistency and reusability of the developed content. For example, if a database is used for a use case, it should be reflected in the use case architecture, in the data catalog, and, if already implemented, in the application architecture of the system under consideration. This means that the specialization allows for both direct and indirect linkages between process, application, information, and technical architectures.

7. Evaluation

The lack of dedicated tools for the governance of AI and analytics solutions on the shop floor remains an unresolved challenge for practical implementation [4]. For this reason, the concept is demonstrated using Archi (Version 5.7.0, which is primarily designed for EAM models) as an example but is developed in a tool-independent manner. An overview of the user interface in Archi is shown in Figure 10. Using the example of the program Archi, the integration of tool support into the framework is executed through a software tool (application). Archi was selected due to its easy accessibility and the market penetration of the underlying metamodel (cf. [64] (p. 14)).

The IoT Factory in Gütersloh (cf. Figure 11) serves as a demonstration example due to its clearly defined scope, manageable complexity, and high practical relevance as a testbed. At the time of applying the specification technique, initial non-prescriptive analytics use cases were already implemented. The full specification approach was applied, including all presented artifacts. The successful demonstration confirmed its applicability and practical feasibility.

Three use cases were selected for design (cf. Figure 12) and development and implementation, based on resource constraints and strategic alignment with the IoT Factory’s goals.

• Prescriptive Production Management: Supports operational decision-making during unexpected events. Based on RUL prediction, it formalizes expert knowledge and integrates MES data with documents to recommend response strategies, e.g., when system failures are predicted or components are misaligned or blocked.
• Prescriptive Quality Management: Focuses on responding to quality deviations using IoT data. Prescriptive analytics recommends actions like manual inspection or process parameter adjustments. Results were under validation at the time of writing.
• Prescriptive Robot Cell Configuration: Aims to diagnose errors in robotic gripping processes and directly link them to recommended actions depending on the deviation detected.

After a thorough evaluation, all design science relevant requirements were satisfied (ref: chapter four). Based on this, the following discussion will give an overview of the contribution and limitation of the presented approach.

Production and Enterprise Architecture Management: The contribution of the framework is the support for integration into existing IT systems in production (cf. [1] (p. 32), [25] (p. 6)). The degree of novelty in the context of the elaboration is the application of established EAM approaches (e.g., building on the ArchiMate metamodel [60] (p. 136)) in the area of Industrial Data Science. Approaches from EAM have already been widely instantiated for other domains. For example, they are used for planning sustainability initiatives in companies (cf. [113]) or in the implementation of the digital factory twin (cf. [114]). The use of EAM is intended to facilitate the establishment and broader dissemination of the FUSE Framework within companies, particularly for those that already have established EAM practices. This creates a bridge between EAM and the system design and implementation of analytics solutions.

The use of the EAM is intended to simplify the integration of prescriptive analytics use cases in manufacturing. This applies in particular to companies that already operate an established EAM. This creates a bridge between EAM and analytics system design and implementation.

The main value contribution compared to the state of the art is the instantiation and connection of aspects from the dimension of the design of analytics use cases (for industrial data science) and aspects of EAM for the special field of prescriptive analytics use cases in manufacturing. The overall concept could also be used for other complex analytics use cases. However, as the content has not been evaluated in this context, it is not possible to make a generally valid recommendation. Further research (and in particular evaluation) is required in this area in order to be able to make a conclusive statement. This includes adaptation to other project management approaches, metamodels, tools or analytics projects.

8. Discussion and Conclusions

The contribution of this work is particularly to provide support for the integration into existing IT systems in production (cf. [1] (p. 32), [25] (p. 6)). The focus is on detailing the implementation of higher maturity levels in the Industry 4.0 maturity model according to Acatech [115]. The degree of novelty in this work lies in the application of established EAM approaches (e.g., building on the ArchiMate metamodel) [60] (p. 136) in the field of Industrial Data Science. Established approaches from EAM, such as model-based enterprise architecture analysis (cf. [104]) are adopted and applied to prescriptive analytics use cases for the first time.

The FUSE Framework contributes to demonstrating the concrete added value of EAM. In general, there is a strong dependency on the capabilities of the executing roles in the solution design. The elaboration makes a partial contribution to closing the gap between the required (cf. [1]) and achieved analytics potential (cf. [56]) in production. The biggest limitation with regard to the overarching application in practice is the fact that many of the integrated partial models are managed and generated in other tools or are available completely off-line (other user systems) [20] (p. 46), [60] (p. 44), [116] (p. 123).

Expanding the FUSE Framework to a broader application context (not limited only to prescriptive analytics solutions) is a key priority. Furthermore, the interface to the individual implementation steps (CRISP-DM) has only been outlined so far and therefore offers potential for further support approaches in the development of analytics use cases. An extension could also be enabled by deriving a permutation concept. The tool support used in the course of this work is currently only at a prototype level. Additionally, the case study needs to be expanded to bigger manufacturing environments with a higher degree of complexity. This could be expanded into a software tool. The use of chatbots for semi-automated guidance through the FUSE Framework should also be considered. The following points should be addressed from the perspective of research fields:

• Artifacts: Future work will focus on developing structured artifacts such as capability maps, integration blueprints, and decision flow models to support analytics system design.
• Methodology: the FUSE Framework will be extended by a process model to structure the application of the model in a development process.