Industry 4.0 is a trend that aims to achieve full automation of the value chain and production individualization [1,2]. This is realized with the integration of cyber physical (production) systems (CPS) with the traditional enterprise IT as well as the point of sales. CPS are physical entities that are equipped with technologies such as radio-frequency identification (RFID), sensors, or embedded systems [2][3][4]. Furthermore, CPS enable products, humans, and production machines to communicate within a larger system [5]. This type of communication is not new, but it leads to new challenges due to the pervasiveness in all types of supply chains and organizations [4]. In our already published research on the planning of I4.0 transformations [4] we were able to extract the core challenges of such digital transformations. The results confirm that the introduction of I4.0 leads to a new level of IT complexity. As a consequence, companies are forced to apply a holistic management approach of their production, IT, and business.
In order to materialize I4.0 in a company, usually expensive and risky transformation projects are conducted [4]. These projects need to be thoroughly planned for being able to successfully realize value [6,7]. An example for such a project is the reduction of architectural silos like unconnected production machines (mostly legacy systems) that work on their own without sharing valuable data [8].
Our claim is that for the successful planning of digital transformation projects, enterprise architecture management (EAM) methods need to be applied. Enterprise architecture (EA) gives a strategic view of an entire company from business and IT perspective [4,9]. This is mostly achieved with the help of models of the company's current architecture.
EAM is concerned with the reduction of IT costs and the optimization of IT support for business execution. One of the core processes of this IT management discipline is EA planning, as described in established EA frameworks like TOGAF [10]. EA planning is conducted by modeling to-be architectures (also referred to as scenarios) that transform the as-is (current) architecture into a specified target architecture [11]. The overall goal is to plan IT transformations aligned with the strategy of an organization as a whole [12].
Such IT transformations are usually conducted in a sequence of phases and aim at meeting the current and emerging requirements of the business [12][13][14]. The planning phase is one of these phases. After this phase, the planned transformation steps are documented, executed and evaluated [4].
When the planning of a digital transformation is not conducted correctly, it possibly results in failing projects and therefore in high financial losses [4]. Currently, organizations are planning their transformations with the help of MS Office tools and mostly based on outdated information [4,12].
Due to the observed challenges in practice and the missing solutions in theory as well as practice, our main research interest is the application of EA planning on this kind of transformation projects.
In this paper, we propose artifacts that will contribute to theory and practice by providing state of the art solutions to specific problems that were derived in our already published research, like the documentation of I4.0 in general, the documentation of I4.0 transformation projects and the planning of such projects.
In Section 2, our research problem is described in detail. Furthermore, in Section 3 our research methodology is discussed. Section 4 outlines our objectives. In Section 5 the related work, or state of the art, is presented. Section 6 describes in which stage our research currently is and concludes this paper.
In [4] we extracted the core problems considering digital transformations with the help of expert interviews. Among the identified challenges are the increasing complexity due to the introduction of I4.0, the currently insufficiently managed and documented IT landscapes, and the communication between the business IT and the operational technology (OT) departments [4].
In addition, we were able to gather seven core findings. This outcome overlaps with the results from our more general research on EA planning requirements [12]. Two of these findings are described in more detail because they support our research problem.
First, we were able to extract that in some companies EAM is specifically introduced for launching I4.0. According to the interviewees, this is due to the additional complexities that are going hand in hand with the digital transformation and the need to manage them accordingly. This supports our claim that there is a need for sophisticated management methods when it comes to an introduction of I4.0 and that EAM methods are suitable for this kind of challenge.
Second, some of the interviewees mentioned the need for a process for modeling and planning and for a metamodel that supports I4.0 transformations. Hence, practitioners would like to have more guidance and a structured process for the planning and modeling of such projects.
To help companies with this endeavor we will develop solutions to the problem of planning IT transformations towards I4.0 concepts. These will be also important input for the topic of EA planning in general. Finally, we will help to manage the higher IT and EA complexity, which result from the transformation to I4.0.
Therefore, we aim to answer the following research questions (RQ):
RQ (main): How can EA planning support the transformation to I4.0? ─ RQ1: What are the requirements of EA planning? ─ RQ2: How are I4.0 concepts currently documented and how could the documentation be optimized? ─ RQ3: What kind of information is needed to support the documentation of I4.0 transformation projects? ─ RQ4: How can tools support I4.0 transformation planning?
The conducted research is based on Hevner's design science research (DSR) methodology [15]. Here, the proposed three-cycle approach is used [16]. It comprises a relevance, a rigor, and a design cycle. The DSR method aims to create IT artifacts that solve organizational problems and to rigorously evaluate them [15]. Therefore, DSR fits well to our goal of creating research artifacts iteratively with the feedback of our industry partners. The DSR methodology in combination with our research output associated to the research questions is depicted in Fig. 1. One of Hevner's proposed cycles is the relevance cycle that builds the connection between the design science activities and the contextual environment of the research project [16]. In this cycle, the opportunities and problems in a specific domain are identified. Additionally, the relevance cycle defines the acceptance for the evaluation of the research criteria. We already published two papers that are part of this cycle. The publication about planning in the context of I4.0 transformations [4] is mostly part of the relevance cycle due to the research goal of gathering existing problems and requirements. Additionally, the series of expert interviews from the paper about requirements for EA planning [12] is also part of this cycle.
The rigor cycle provides knowledge past research to the research project to ensure its innovation [16]. It also comprises additions to the knowledge base as results from the DSR. The above-mentioned requirements paper [12] is also located in this cycle because it contains an extensive scientific literature review on the topic of EA planning.
Finally, the design cycle, the heart of the DSR methodology, iterates between the construction of an artifact, its evaluation, and the feedback from the evaluation to refine it further. Here, the inputs are the requirements from the relevance cycle and the design and evaluation theories and methods from the rigor cycle [16]. Our remaining work will be mainly located in this cycle and will be described in detail in the following section.
As starting point of our remaining research, we will use the results from [4] that discovered a strong need for a metamodel for I4.0 specific EA planning in the context of IT transformation projects. This is mainly due to the higher complexity of the IT landscape that is introduced with I4.0 and the need for its management. Additionally, we were able to observe the need for a standardized EA planning process for I4.0 transformations [4]. This was also observed for the general task of EA planning [12]. Here, most of the interviewees reported that they were struggling with the planning of their companies' EA. That is mainly due to the missing support of tools and the unstructured process, which is used for EA planning. Hence, we learned that there exist neither a standardized EA planning process nor sufficient tool support to guide companies in their planning endeavors. Therefore, we will analyze the tool support for EA planning by extracting and comparing the relevant features of EA tools that are listed in Gartner's Magic Quadrant [17] in the context of our results from [12] and [4].
As the first design artifact, we will propose a metamodel for IT transformation planning. The goal is to guide companies in what should be documented in an EA model and how the specific metamodel elements should be associated to each other to be able to conduct EA planning in I4.0 IT transformations.
For this purpose, we plan to enhance the classical layer approach of EA documentation (business layer, application layer, and technology layer) [10]. As discussed in [4], the newly introduced assets differ from the classic assets. One of the main differences is that it is not possible to distinguish between the application and the technology layer anymore. Due to this, we will introduce a fourth layer named the operational layer. In this layer, the core assets of the automation architecture will be located and connected to the classical layers used for documenting the other parts of the EA.
For the decision on what assets need to be modeled in the operational layer, our results from [4] will be revisited. Additionally, we will analyze the classical automation pyramid and its adaptations for I4.0 (see Fig. 2) in order to have a holistic picture of the possibly needed assets. We will also investigate dedicated I4.0 reference architectures like the one from IBM [18], and, in addition, ArchiMate 3.0 [19], which contains a physical layer for modeling e.g. machines, so as to evaluate currently available methods for modeling these assets. Furthermore, the automation assets now need to be part of the EA, which is new because in the past the operational technology (OT) was strictly separated from the business IT [4]. This is another reason why the new operational layer, in which the relevant OT assets are connected to the classical EA layers, needs to be introduced. For the associations between the OT and business IT we will consult I4.0 frameworks like the "Reference Architecture Model Industrie 4.0" (RAMI 4.0) [20] that propose a standardized communication between these layers. [21]) and the proposed 4-layer approach for EAM
The automation pyramid is the current standard model in which the classical layers and components of industry automation are depicted and described [22]. This pyramid usually consists of a device layer, a control layer, a layer for the manufacturing execution system (MES), and an enterprise resource planning (ERP) layer. At device level, the production machines with their sensors and actuators are located. Furthermore, at control level the controllers for these machines are positioned. The MES level consists of the execution system that controls the execution of production in real-time. Finally, the top level of the classical automation pyramid is the ERP level, which constitutes the connection to the business. The communication between these layers is hierarchical.
With the introduction of I4.0, these layers need to be broken up into the new CPS-based automation [21] (see Fig. 2) order to establish information links between the components.
As the second DSR artifact, we propose a planning process that will be implemented in the form of a TOGAF Architecture Development Method (ADM) extension. TOGAF ADM is the core of TOGAF and describes a method for developing and managing the lifecycle of an EA [10]. Furthermore, it is a rather generic framework that does not include a description of a process for I4.0 integration and transformation planning [4]. The need for a TOGAF ADM extension is a result from our interviews that are discussed in [4]. This extension will help companies with conducting EA planning in a structured manner, which will help them with implementing their planning initiatives.
The planning process will be closely connected to the above-mentioned metamodel, which therefore is also part of the TOGAF ADM extension. Furthermore, the process will be developed with the help of a case study, which will be created in collaboration with our industry partners and experts in the field of I4.0 transformations. After that, our proposed method will be applied to this case study and be evaluated again. The outcome of this process will consist of several best practice approaches for conducting EA planning in the context of I4.0 transformation projects. For example, it will incorporate modeling guidelines, useful metrics and comparison guidelines for different plans of the to-be architecture, and step-by-step guides for typical planning problems in specific domains. This is especially useful because currently companies are planning based on outdated data, in an unstructured way, and have problems with the comparison of the different planning scenarios, which could lead to problems in bigger planning initiatives like I4.0 transformation projects are [4,12].
Both of the above-mentioned IT artifacts will be implemented within a tool for automated EA documentation that is a result of our previous research [23]. This will constitute our third DSR artifact. In addition, it will be used for the evaluation of the metamodel and the EA planning process.
The evaluation and validation of our research artifacts will be performed with the help of our industry partners and experts in the field of I4.0 introduction and transformation. The latter include consultants that are involved in such type of projects, automation experts, and enterprise architects from this field. Relevant industries for evaluation are in general all industries that are concerned with industrial production (like discrete and process manufacturing) and telecommunication.
For evaluation, the mentioned stakeholder groups will test the tool with its new planning feature (our third DSR artifact). As a next step, we will gather feedback on the usefulness and practicability of our approach in expert interviews and, if possible, in focus group discussions.
The gathered feedback will be iteratively implemented in the research artifacts, as proposed by our chosen DSR methodology.
From the structured literature review in [12] we learned that there are two main clusters of researchers that published on the topic of EA planning.
One of these research groups is et al. from the University of St. Gallen who focused on the process of transformation planning in the course of which they developed a process model for EA planning in [24]. Additionally, they created an integrated information model that describes EA transformation planning as well as a system that accounts for the interplay of EA planning, release, requirements, and synchronization management [12,25].
The second cluster of researchers is Buckl et al. who worked on an information model for application landscape evolution in [26]. Moreover, they focused on how to model enterprise architecture transformations [12,13].
The publications of the two groups are mostly of conceptual nature except for a prototype that is described in [27]. Furthermore, the research of these two research groups is concerned with EA planning in general and not with the implementation of EA planning methods in the field of I4.0 transformations. Therefore, we conducted another literature research focusing on the application of EA planning for digital transformations [4]. Hereby, we learned that there currently exists no research taking EA planning into consideration that is able to overcome the challenges of planning I4.0 transformation projects [4]. Furthermore, we were able to identify one main cluster of researchers that is related to our research. Zimmermann et al. published on the topic of Digital Enterprise Architecture in the context of the Internet of Things (IoT). In their work, they discuss the evolution of EAs, the transformation of EA for the IoT, and architectural decision-making for digital transformations [4,[28][29][30].
Zimmermann et al. define an architecture reference model named Enterprise Services Architecture Reference Cube (ESARC). It adapts already existing architectural frameworks for services and cloud computing [4]. However, the authors do not discuss how the planning of target architectures in the context of I4.0 or IoT should be conducted. Additionally, Zimmermann et al. developed a metamodel for EA decision-making that consists of a decision-making process. Yet, a method to support practitioners to model their I4.0 transformation projects is still missing [4].
Our understanding of EA planning is based on the results of a literature review and a series of interviews on the requirements of EA planning, which is discussed in [12]. We were also able to identify current problems in the documentation and planning of I4.0 transformation projects. These results build the basis for my future research on the DSR artifacts that aims to solve those problems. The next research step is to conduct a tool survey that compares EA planning features of existing commercial EA tools in the context of our interview results from [12] and [4]. This also concludes the theoretical background that is needed for working on the DSR artifacts. After that, the first and second IT artifact, the metamodel and the process for EA planning in the context of I4.0, will be developed. Both artifacts will be part of a TOGAF ADM extension that helps with a structured way of planning I4.0 transformation projects and gives advice how and what to document for I4.0 in general. The majority of this work will be finished until the end of 2018. We studied the challenges of EA planning in general and specific to the context of I4.0 transformations. We were able to extract possible solutions for these challenges that are subject of my future work. From the interviews we have already conducted, we learned that companies need a metamodel for EA planning and a specified EA planning process to be able to conduct the planning in a structured manner. In general, the interviews suggest that there is a need for standardized models and methods for I4.0 initiatives.
This research was partially funded by the research project "txtureSA" (FWF-Project P 29022).