Artificial intelligence (AI) has emerged as a core technology for enabling automation, process innovation, and the development of new products and services. However, integration of AI applications into organisational environments is still challenging. The reusability and integration of AI solutions across diferent contexts are still limited, as organisations often lack structured, methodological support to align business objectives with IT capabilities. This paper presents a method for developing reusable AI building blocks (AI-BB) for machine learning (ML) applications, motivated by an industrial case from a medium-sized industrial enterprise. The proposed method supports integration of ML applications into enterprises by structuring them as modular AI-BB derived from the enterprise context model. Compared to traditional ML documentation, which mainly covers technical aspects, this approach also considers the contextual and architectural information needed for reuse. Based on principles from method engineering, software architecture, and enterprise architecture management, the method aims to close this gap. The method's feasibility is shown through a real-world case, where AI-BB are derived from the enterprise context and organised to support reuse across use cases with similar conditions. The initial results confirm the method's potential to enable a structured and reusable integration of ML applications into enterprise systems.
Recent advancements in computer science have made AI solutions increasingly relevant for companies
across various industries. AI is often associated with several benefits, such as enabling work automation,
driving process innovation, and facilitating the creation of innovative products and service oferings.
As a result, many researchers regard AI as a key pillar of digital transformation (e.g., [
Despite the growing adoption, the implementation of AI solutions presents unique challenges compared to traditional IT or information systems (IS) development. Some of these challenges stem from the current hype surrounding AI technologies [6], which may obscure the line between actual capabilities and users’ expectations [7]. Others relate to the specific demands of AI development, such as the need for high-quality, large-scale data, domain-specific knowledge, and tailored workflows.
We argue that organisations require structured, methodical support for adopting AI solutions—support that goes beyond technical implementation to include decision-making, scoping, and requirements definition. This involves aligning business objectives with IT capabilities. To facilitate this, we propose an approach aimed at making AI building blocks (AI-BB), i.e. analysis and ML building blocks of organisational AI solutions, reusable. This is achieved by combining their required integration into the enterprise architecture with the actual implementation of the approach, for example, as an ML component. Specifically, we propose a method for developing an AI-BB methodically. This proposal follows a technique from method engineering proposed by Goldkuhl et al. [8].
Our work is embedded into the general philosophy of model-driven design and development of information systems, which uses model-based representations of the essential results of all development phases and the relevant aspects of the desired solutions. Previous work has shown that the integration of AI solutions into organisations requires understanding the context for the AI solution [9], consisting of business processes to be supported or automated, data to be used for informing or training AI, information systems or services to be connected, and technological platforms to be used [10]. Thus, we argue that the definition and representation of AI-BB should also include such information, which means for model-based representations of AI-BB, they either have to include these aspects as diferent perspectives in the same model, or diferent models are required. This is reflected in the method and the results produced in diferent method components (see Sect. 5).
The paper is structured as follows: Sect. 2 briefly introduces the background for our work and summarises related work. Section 3 introduces the research method applied in the paper. Section 4 presents an initial case study motivating the work and requirements for the method for developing AI-BB. Section 5 presents the method’s prototype with its diferent components. Section 6 contains an initial evaluation of the method as a feasibility study. Section 7 summarises the findings and discusses required future work.
The theoretical background for our work, as summarised in the section, originates from enterprise architecture management and method engineering. Furthermore, this section summarises the related work on AI-BB and outlines how these concepts are used in the scope of this work.
Enterprise Architecture (EA) aims to model, align and understand important interactions between business and IT to set a prerequisite for a well-adjusted and strategically oriented decision-making for both digital business and digital technologies. An EA is typically captured within a formal model showing its key components and the relationships among them [11]. EA Management (EAM) ofers a structured approach to developing an organisation’s architecture in alignment with its strategic objectives. This involves planning, transformation, and monitoring activities [12].
EAM has been the subject of extensive research. A literature review presented in [13] highlights commonly explored areas such as EAM components [14], processes and guiding principles [15], and strategies for implementation [12].
TOGAF [16], widely recognised as an industry standard, identifies three architectural layers that are commonly also found in other frameworks: • Business Architecture: Defines business strategy, governance, organisational structure, and core business processes. • Information Architecture: Often split into Data Architecture: that outlines the structure of logical and physical data assets and related management resources, and Application Architecture: that provides a blueprint for interaction and integration of applications with key business processes. • Technology Architecture: Details the physical infrastructure that supports business, data, and application services.
The field of method engineering [ 17] investigates concepts, approaches, and tools to systematically develop, introduce, and adapt methods. These methods are typically prescriptive, aiming to guide problem-solving and the execution of complex tasks. As such, a method typically specifies the activities to be performed, the procedure for carrying them out, the expected outputs (or artefacts), and how these outputs are represented (notation) [8].
All methods are grounded in specific perspectives, values, principles, and categories — each with definitions that reflect the underlying theories and rationale behind the method and its components. Various interpretations of the term method and related terminology exist. When there is a tight integration between procedure, notation, and conceptual elements, the term method component is used [18]. This concept is closely related to method chunks [19] and method fragments [20]. Typically, a complete method comprises a set of such components — collectively forming what is sometimes referred to as a methodology. Together, these components are structured into a framework.
The descriptions of methods and their components in this paper are based on the method conceptualisation proposed by Goldkuhl et al. [8], who argue that a method should consist of components and a method description has to include several elements: • Perspective: Every method is grounded in a particular viewpoint, which shapes how the modelling process is approached and what is considered important. • Method Components: Each method component should include (a) Concepts: These define what aspects of reality are relevant for modelling. The method should name and explain these key concepts; (b) Procedure: This outlines how to identify and apply the relevant concepts, and may also describe prerequisites or resources needed; (c) Notation: This determines how to document the procedure’s outcomes, providing formal representations for the concepts and their relationships — often as visual language or graphical symbols. • Framework: The method framework describes how diferent method components relate to one another, including which components to use, under what conditions they apply, and the sequence in which they should be executed. • Forms of Cooperation: Since modelling often requires collaboration across various roles and areas of expertise, the method should define the roles involved and their responsibilities, the required skills, and how collaboration and task delegation will be structured.
We conducted a literature review examining existing concepts in structuring and reusing AI solutions. For this purpose, we developed a Scopus search query to identify building blocks (BB), modules, architecture patterns, and other synonyms that serve similar purposes as BB and could be used for structuring and reusing AI solutions. Since BB is a broad term used in many diferent disciplines, not many papers describe BB or its synonyms in a context relevant to this work. The results were very limited, especially in the context of integrating the technical aspects of AI solutions into business architecture. In this paper, we present a definition of AI-BB that is relevant for our work. The complete literature study, along with the process by which it was conducted, will be published in a separate paper.
Therefore, we envision AI-BB as self-contained, reusable elements [21] that encapsulate the processes, services, interfaces and data structures [22] of AI solutions, extending across the data, application, and technology layers of the enterprise architecture. They support alignment between business goals and IT capabilities [23, 22], facilitate modular system design, and enable traceable data transformation across the mentioned architecture layers. A defined business service context characterises these elements, as well as the provided and required interfaces between the elements and their relationships.
In the presented work, the novel contribution lies in defining AI-BB as a partial ArchiMate (AM) models that can be reused and integrated into broader EA models. This approach enables a structured and semantically consistent representation of analysis building blocks (A-BB) and ML building blocks (ML-BB) within the EA landscape and increases the reusability of ML applications within enterprises.
During this research, we identified that the TOGAF framework provides reusable and modular concepts comparable to the AI-BB introduced in this work. The TOGAF provides definitions of Architecture Building Blocks (ABBs) and Solution Building Blocks (SBBs), which are used to facilitate the development, documentation, and implementation of architecture solutions. In their definition, ABBs describe the required capabilities, while SBBs represent the components used to implement those capabilities [24]. Although TOGAF concepts share similarities with the proposed AI-BB, they do not cover the implementation or reuse of AI or ML solutions, which is the focus of the concepts proposed in this work.
The main objective of the research presented in this paper is to contribute to the design of a method for developing AI-BB. The project follows the paradigm of design science research (DSR) [25]. DSR is aiming at problem-solving in organisational settings, focusing on developing valid and reliable knowledge for designing the required solutions. In our research, the envisioned solution, called “artefact” in DSR, is methodical and technological support for AI-BB development. DSR research projects typically consist of several phases and require diferent research methods depending on the DSR phase and intended design solution. In the following, we will provide an overview of the research activities performed in the diferent phases of the DSR process, the research methods used for these activities, the results achieved, and the sections of this paper providing information about the results.
The problem investigation phase includes an industrial case study to show the need for reusable AI components and what modelling approaches are currently applied in industrial practice. The case study is described in more detail in [26]. An additional case study is included in Sect. 4. Furthermore, the problem investigation also requires an analysis of the existing scientific knowledge base. This was done by performing a literature analysis (see Sect. 2). The essential results of the problem investigation phase are a confirmation of the industrial demand for supporting the reuse of AI components and the lack of scientific work on developing reusable AI-BB that include the integration into the organisational context. As a consequence, we proposed the notion of “building blocks” and derived requirements for AI-BB and their model representations, such as integration into enterprise architectures and the inclusion of AI models, underlying data, and implementation parameters. The definition of requirements also resulted in the need for a systematic approach to developing AI-BB. Starting from these requirements, this paper aims to develop an initial prototype for a method to develop AI-BB encompassing organisational integration. The method development applies the method conceptualisation proposed by Goldkuhl et al. [8], which means that we aim for a component-based method with a joint meta-model and notation for all method components. Section 5 motivates and presents the current method prototype. Evaluation of the method prototype is the subject of Sect. 6 Here, we use the industrial case study presented in Sect. 4 to test our method.
The case study presented in this work stems from a project in collaboration with an SME specialising in the construction, operation, and maintenance of Heating, Ventilation, and Air Conditioning systems (HVAC). The project aims to improve the energy eficiency of these systems by installing Internet of Things (IoT) sensors and using ML applications. Based on the analysis of inspection reports, one project partner concluded that up to 30% of energy savings could be achieved in existing HVAC systems by detecting simple malfunctions using low-cost technologies [10]. Several ML components were identified from open-source repositories and their documentation as part of the project. These documents include descriptions of technical details such as datasets, algorithms, input-output specifications, and performance metrics. In this work, they serve as the initial descriptions of AI-BB that could potentially be reused. However, these structures do not provide suficient information for integrating the components into operational environments or for supporting reuse in enterprise contexts. They lack contextual and architectural information that would help determine how ML components can be embedded into existing processes or adapted across diferent scenarios.
Based on this, we introduced an additional structuring step to address this gap. We therefore create the A-BB, which contains enterprise context information required for the analysis, and the ML-BB, which describes the ML components that support the analysis. The following section presents a method that supports the creation of reusable AI-BB from the context model. The method should enable enterprises to reuse existing ML models across various contexts and use cases where the HVAC system is applied.
The method requirements were derived from the real-world conditions and constraints identified in the industrial settings. We have validated these requirements with stakeholders during the practical application of the method. In the following, the main requirements are outlined: • Contextual dependency: The method assumes the availability of an EA model and a physical product model within the company. Only if these models are available the context model can be created (see Sect. 6). The context model should describe elements from the Business, Application, Data, Motivation and Technology layers of the AM framework. In addition, the output data of the A-BB must be identified, as this forms the basis for selecting and deriving the ML-BB. • Modular structure and IPO Alignment: The context model must be validated with the experts from the company and well understood to enable decomposition into modular IPO structures. This step supports the creation of AI-BB and improves the transparency of the data transformation processes across the system. • Model Notation dependency: The method is applicable only if the models are represented using the AM notation. All steps in the method rely on AM semantics, structure, and modelling standards. The AI-BB must be created in alignment with the proposed meta-model notation and the IPO structure. Furthermore, we envision representing the AI-BB concepts as partial AM models to ensure their compatibility and integration with existing EA models. • ML documentation dependency: The method enables the extension of A-BB with ML-specific information. This includes defining the input and output data relevant to the ML applications, describing the structure of the ML pipeline, such as processing steps, model components, decision rules, and defining the expected format and type of results produced by the ML component.
Based on the requirements presented in Sect. 4.2, this section presents the prototype of the method for developing AI-BB for organisational contexts. Following Goldkuhl’s method structure (see Sect. 2.2), we start with the method framework and give an overview of the method components in Sect. 5.1. Lastly, two method components are presented in more detail with the concepts (Sect. 5.2) and notation (Sect. 5.3) they share, and the diferent procedures (Sect. 5.4 and 5.5).
To outline the development of AI-BB, we introduce the overall method framework shown in Fig. 1. This method is primarily developed for IT experts within organisations, focusing on implementing and reusing ML applications. In brief, the method supports those involved in planning, designing and implementing ML applications in the HVAC domain. Furthermore, the framework includes several method components (MC), as illustrated in Fig. 1. The figure shows these MC as circles, with the transitions between them. However, due to space limitations, this paper focuses on only two key MCs that are particularly relevant to the presented case study. Specifically, we focus on MC 6 and 7 in Fig. 1, which are also highlighted in blue, and their procedure steps are described in more detail in Sect. 5.4 and 5.5. The precondition for starting MC 6 are defined application scenarios for the envisioned AI-BB (from MC4) and a context model represented as an AM model (from MC5). This context model is derived from the EA model of the enterprise (MC1) by adding the physical product features of the HVAC (MC2) and features of the ML component to be used (MC3). For a detailed description of the earlier steps and foundational components of the method framework, we refer the reader to our previous work [27]. 1. Select and analyse the EA
model 8. Update building blocks repository 2. Select and analyse the physical product
model 7. Extract the ML building blocks
Requirements analysis 3. Select the ML documentation 6. Extract the analysis building blocks 4. Define the application scenario 5. Create the context model
For the MC presented in the previous Sect. 5.1, we now define the relevant concepts. The essential concepts required for the MC AI-BB are a subset of AM, i.e., the meta-model for the MCs presented in Fig. 2 is based on selected elements of AM. This meta-model defines the necessary elements and relationships for AI-BB creation. It spans all AM layers but includes only a subset of elements relevant to this method. In addition, we envision using the elements of the motivational and business layer to create A-BB, and the elements of the application and technology layer to create ML-BB. A detailed explanation of the used elements is provided in the following section. Due to space constraints, the elements from the Technology Layer of the AM notation are not considered in the AI-BB presented in this work. Their integration will be addressed in future work.
The method notation presented in this work is based on selected elements of AM. These elements are used to define the method’s meta-model, as shown in Sect. 2, which supports the modelling of AI-BB and their relationships across multiple AM layers. The following outlines the selected elements briefly.
To define the purpose and the limitations of the AI-BB, we are using the Requirements and Constraint elements in the Motivational Layer. These can be understood as the type of system installed or the specific thresholds that influence the analysis. The elements such as Business Service, Business Process, Business Object, Business Role, Business Interface, and Business Event are included in the Business Layer. They describe the main business services, their related processes, the data they require or generate, and the responsibilities of the stakeholders. In the Application Layer, the elements such as Application Service, Application Process, Application Component, Data Object, Application Interface, and Application Event are included. These elements are used to describe the structure of the ML software architecture, its functionalities, and the way data is processed and transformed throughout the ML pipeline. Lastly, the Technology Layer of the meta-model includes the elements Node, Device, System Software, Artefact, and Technology Interface. These elements represent the technical resources required for the deployment and operation of the system.
Finally, to define the relationships between elements, we are using AM Relationships such as Influence, Realisation, Assignment, Triggering, Access, Serving and Association. All AM elements and relationships used in this work adhere to their intended purposes as defined by the AM standard defined in [28]. Due to space constraints, they will not be further described in detail. 5.4. Procedure of MC Extract the analysis building blocks • Select and analyse the context model: The first step of the procedure of the MC 6 shown in Fig. 1 is to select a context model that contains relevant business-layer information. In the selected context model, the core business service must be identified, along with its associated processes, sub-processes, and the business roles responsible for their execution. Furthermore, motivational elements representing HVAC-specific constraints and requirements should be included. In the final part of this step, the data generated or consumed by the identified processes is analysed. The outcome is clearly understanding the context model and the relevant elements required for deriving the A-BB. • Derive analysis building blocks: Once the context model is analysed, the next step is to restructure it according to the predefined IPO model in order to derive A-BB. To support systematic extraction, we recommend using a colour-coding scheme to label the elements in the context model: yellow for Input, green for Processing, and red for Output components. The process starts by identifying the core business service and the processes involved in data acquisition, marking them as Input elements in yellow within the context model. In the next step, the interfaces related to data acquisition and the corresponding data objects are also labelled accordingly. This procedure is then repeated analogously for the Processing and Output parts of the A-BB. The result is a context model labelled according to the IPO model, which serves as the basis for creating A-BB in the following step. • Use ArchiMate to model analysis building blocks:
After the context model is labelled as shown in Fig. 3, the AM elements and relationships defined in Section 5.3, guided by the meta-model shown in Fig. 2, are used to model the A-BB. The result is a model in AM notation, referred to as “analysis building blocks”, in which each part of the IPO model is clearly represented. This includes the relevant processes, their interfaces, the associated data with defined types, and the relationships between elements.
• Identify the ML components in the Context Model:
Following the method framework, the steps below describe the procedure for MC 7 shown in Fig. 1. In this step, the previously analysed context model in Sect. 5.4 is used to extract the ML-BB. This process begins with a renewed examination of the context model, focusing specifically on the elements within the application and data layers of the TOGAF architecture that describe the ML components and their associated functions. This includes identifying and mapping the application data objects associated with the relevant business data objects from the business layer of the context model. Subsequently, the application services and components that require this information from the data objects are determined. The next step involves analysing the application processes and sub-processes responsible for processing this information. Finally, the output data linked to the corresponding services or processes is also identified. This step results in a clear understanding of the application and data layer elements in the context model, their internal relationships, and their links to the business layer. Additionally, it is helpful to examine how the data is transformed along the ML pipeline. • Derive ML building blocks: After the context model has been analysed and all relevant elements and relationships have been identified, the procedure for restructuring it into ML-BB can be initiated. In this step, the focus is on classifying ML components based on the predefined IPO model. A colour-coding scheme is again recommended to support systematic extraction and improve clarity during ML-BB creation. Yellow is used for Input, green for Processing, and red for Output components.
The derivation of the Input ML-BB starts with identifying the data elements from the business layer that are required by the ML components. Based on this, the related application services, events, processes, and sub-processes that use this data are identified and labelled accordingly. In the next step, the output data generated by these elements, referred to as provided data, is also identified and labelled with the yellow colour. This procedure is then repeated for the Processing and Output ML-BB. The Processing section focuses on identifying the ML components described by application functions or processes that perform transformations, computations, or model inference on the input data. For the Output ML-BB, components responsible for providing the final results, such as anomaly reporting services, external interfaces, or visualisations, are identified. The following procedure step can begin once all relevant elements are labelled using the designated colour scheme. • Use ArchiMate to model ML building blocks: In the final procedure step, the modelling of the ML-BB can begin. For this, the defined subset of the AM notation and the meta-model presented in Sect. 2 should be used to guide the selection of elements and relationships.
This section aims to validate whether the method components proposed in Sect. 5.1 can be applied to derive AI-BB from a selected context model. Specifically, this feasibility study examines whether the method’s concepts, notations, and procedures are suficient to identify relevant elements within the context model shown in Fig. 3 and use them to generate AI-BB.
For the feasibility study, we selected the context model shown in Fig. 3, representing the “Check Dehumidification” business service. In this case, the context model describes how the business objectives related to detecting dehumidification anomalies are aligned with the available IT capabilities to support anomaly detection through the ML application. As defined in our previous work [ 27], the context model integrates elements from the physical product model, the EA model, and the ML documentation. The physical product model provides the technical perspective of the system, the EA model includes domain-specific knowledge on how the anomalies are detected, and the ML documentation describes the technical aspects of the machine learning components.
The upper part of the context model uses AM motivational elements to define requirements and constraints, such as building type, threshold values, and types of anomaly checks, and provides usecase-specific information. The “EA Model” section in the Fig. 3 outlines the business service, relevant processes and sub-processes, responsible stakeholders, and relevant data. These elements describe the domain knowledge required for detecting anomalies. These elements are used as the primary input for ML applications.
The lower part of the context model in Fig. 3 describes ML-related components, including required and generated data objects, application components used for processing, and application events as triggers for ML services. It also includes retrospective databases for both ML and configuration data.
Finally, the lowest section, the physical product model, outlines the installed sensors, the transmission of data to retrospective databases, and their location within the system architecture. Due to space constraints, the technology-layer elements are omitted in this work, but they remain an important part of the overall context model and the ML-BB. Full details on the complete context model are provided in [27].
Following the steps of the proposed method, the focus lies on extracting A-BB from the context model. In the initial step, the core business service entitled “Check Dehumidification” within the context model is identified. In the subsequent step, we analysed the context model and, as illustrated in Fig. 3, applied a colour coding scheme to label elements according to the IPO model. Input elements are marked in yellow, processing elements are in green, and output elements are in red. We began by labelling the elements that provide use case-specific information, represented by AM motivational elements. Next, we labelled the associated processes that provide input data to the core service. Lastly, all underlying business data objects that describe the input data and its transformation were also labelled in yellow.
In the following step, we used green to label the processes and data describing how the input data is processed within the core business service. Finally, elements representing the outcomes, including processes and data from this service, were labelled in red. After labelling the context model, we used the defined notation and meta-model to extract the A-BB according to the IPO model, as shown in Fig. 6.1.1.
Following the proposed procedure, we further focus on extending the previously created A-BB with the ML application perspective. In this step, ML services, processes, interfaces and data objects are mapped to the A-BB according to their function and position within the IPO model. This enables the integration of ML-specific logic, such as data injection, preprocessing, model execution, and result generation, into the existing A-BB structure. Subsequently, the input processes of the ML services are identified, and the corresponding interfaces for required and provided data are defined. In the following step, the processes responsible for handling this data are modelled, along with their respective interfaces. Data object elements are used within these interfaces to describe the structure and content of the required and provided data, including how the data is cleaned, labelled, trained, and tested. Finally, we model the processes, interfaces, and data elements required to generate and handle the output of the ML application. Here, the focus lies on which anomalies are detected, how they are processed, where they are visualised, and which tools are used to provide the visualisation. The output interfaces are defined together with the related data object elements, which specify the structure, type, and format of the anomaly data.
This paper presented a method for developing reusable AI-BB for ML applications, motivated by an industrial case in the HVAC domain. The goal was to optimise energy use through IoT sensors and ML applications. While some ML applications were already available in the company, they were intended to be reused across diferent use cases. However, the existing ML applications and their documentation lacked the contextual and architectural information needed for reuse. To address this, we proposed a method based on method engineering principles that introduces AI-BB derived from enterprise context models. These AI-BB go beyond technical implementation by documenting the contextual information of which domain-specific data is required for the ML application. The A-BB contain core information from business objectives and shows how data is transformed across the enterprise, providing necessary input for the ML-BB. By systematically identifying which contextual data is produced by the A-BB and how ML applications consume this data, the method increases transparency, both in terms of the data provided from a business perspective and the data required by the ML components.
As outlined in Sect. 2, TOGAF provides BB similar to those presented in this work; however, they have not been applied to the modularisation and reuse of AI solutions. This highlights the relevance of the proposed AI-BB for increasing the reusability of AI solutions across the enterprise. A separate paper will present a structured literature review on AI-BB for AI modularisation and reuse, and compare existing concepts with those introduced in this work.
Furthermore, structuring the components using the IPO model enhances their reusability across diferent contexts. To evaluate this, we applied the method to an existing context model within the company and successfully derived the AI-BB. In the next step, we manually identified a similar context model that could support the integration of the derived AI-BB. As a preliminary result, the ML-BB developed in this work was successfully reused to extend the new A-BB from the newly identified context model using the previously defined ML application. The contextual information, such as required data and labelling rules, remained the same, while certain aspects, such as threshold values for anomaly detection, required adjustments. After the thresholds were adjusted, the ML application was able to detect anomalies again.
In conducting this work, we emphasise that further validation of the method is planned as part of future research. We intend to assess the reusability of the ML-BB across various contexts and conduct structured interviews with the stakeholders involved. These interviews aim to provide insights into how the method is understood from the stakeholders’ perspective and support improvements in its practical applicability. Furthermore, a repository for organising the AI-BB will be developed. The AI-BB will be stored in a machine-readable format to enable automated matching and improve the alignment between the AI-BB and the contexts in which they will be integrated.
During the preparation of this work, the authors used Grammarly to check grammar and spelling. After using the tool, the authors reviewed and edited the content as needed to take full responsibility for the publication’s content.