Driven by technological advances and increasing customer demands, the complexity in manufacturing companies is rapidly growing. To manage this complexity numerous architecture standardization initiatives are emerging in the manufacturing industry, e.g. Production Platforms, Reference Architecture Model Industry 4.0 (RAMI4.0), Industrial Internet Reference Architecture (IIRA). Large manufacturing companies are changing their approach towards managing production and are adopting the concept of Production Platforms. Production Platforms can be understood as a set of subsystems and interfaces to create a common architecture to develop both products and production systems simultaneously. The development of the models required in these platforms is often performed manually and it is perceived as very time consuming. A discipline that can support the implementation of Production Platforms is Enterprise Architecture (EA). EA is a discipline that manages the organizing logic of the enterprise and it reflects the integration and standardization requirements of its operating model. Therefore modelling the products, production systems and process is in the scope of EA when applied to the manufacturing industry. In this paper, we develop a new automated EA modelling method relevant also for manufacturing. We tested it in an Industry 4.0 laboratory. This paper is a first step for creating automated EA modelling methods that are general-purpose and applicable in different contexts. With this goal in mind, we outline future research directions based on the limitations and challenges experienced during the laboratory experiments.
The fundamental goals and principles of manufacturing are changing with the
emergence of new paradigms. In recent years, “the ubiquitous presence of the internet
and computing and availability of emerging responsive manufacturing systems” lead
to the emergence of the personalization paradigm [
An emerging concept in the manufacturing industry that addresses the complexity
of production systems is the Production Platform [
A discipline that can support Production Platforms is Enterprise Architecture (EA).
In this paper, we apply EA to manage the complexity in the new era of manufacturing
and implement Production Platforms. Although there is no general agreement on the
definition of EA, we are in agreement with Lapalme’s purpose of EA being to
“effectively implement the overall enterprise strategy by designing the various enterprise
facets […] to maximize coherency between them and minimize contradictions” [
Automated modelling is an emerging research stream in the field of EA that deals
specifically with these challenges. Its goal is to “automate EA documentation by
retrieving and maintaining relevant information from productive systems” [
Moreover, EA functions in enterprises are often positioned in the IT department [
The remaining of the paper is structured as follows. Section 2 presents the background literature, and Section 3 the methodology and the experimentation environment. The following section presents the new modelling method, the generated model and the results of the evaluation. Finally, the last two sections discuss the results of the research, outline future research directions and conclude the paper. 2
We begin this section by positioning our research in the field of EA and its modelling process. Afterwards, we present automated EA modelling methods literature as well as the classification adopted for the development of Production Platforms. 2.1
The scope of this paper is limited to the documentation of ‘as is’ models when the information for creating them is available in a digital format. This is due to the fact that to automate documentation the information needs to be retrieved from an IT system (e.g. Manufacturing Execution (ME) and Enterprise Resource Planning (ERP)) and usually these systems represent only information relevant for the ‘as is’ models.
A main challenge of EA is the fact that EA functions are usually part of IT
departments and its approaches have been focused on IT aspects and this caused a lack of
acceptance and made EA being perceived as organizationally inconsiderate [
Lankhorst et al. identified the activities of EA modelling process and their logical
order [
Research on automated EA documentation has been mostly undertaken at three
research institutes in Europe. We structured this sub-section presenting the research in
each institute because each institute developed its own solutions that have been
applied and refined by several authors within the same institute. At the Institute of
Computer Science at the University of Innsbruck, Farwick et al. [
Key elements in Production Platforms are the process and product classifications.
In this paper, we focus on the process classification and we are adopting the one of
Sorensen et al. [
Concluding this section, we summarize the state of the art of research related to
this paper. As a discipline, EA is transforming itself from being confined to the IT
department to become more comprehensive and consider the whole enterprise and its
environment [
We applied design science research as methodology during our project and we
completed one full iteration. In particular, we chose Peffers et al. research
methodology for information systems [
The method we designed is based on Lankhorst et al. [
We applied our new method at the Smart Production Laboratory at Aalborg
University [
To develop EA models we leveraged QualiWare EA platform [
We demonstrated our method in the Industry 4.0 laboratory at Aalborg University generating the high-level production process model. Even though the production process in the Industry 4.0 laboratory has a fewer number of activities than industrial processes, the data and IT systems used are in common with industrial environments. A preliminary evaluation of the method and the model was performed by interviewing the laboratory manager. We decided to interview him because he could have best validated the usefulness of the model in the laboratory. In addition, he provided feedback on the industrial implications and requirements based on this extensive collaboration with Danish manufacturing companies. The first author interviewed the manager using open-ended questions related to the following topics: value of the abstracted model, soundness of the new modelling method and of the abstraction action. In the first part of the interview, the author presented to the manager two versions of the production process, one that was generated using the new method with the abstraction action and one that skipped the abstraction action. This second model had a uniform representation of the symbols of the production activities and it included the naming available in the ERP system, see the image of existing information analysis in Fig 2a. 4
In this section, we present our automated method that contributes to a specific
activity of Lankhorst et al. modelling process [
The method focuses on the “creating and structuring” activity of the modelling
process. Therefore, enterprise architects are encouraged to follow Lankhorst et al.
modelling process as it is except for this activity. As shown in Fig. 1, this activity is
structured in 4 actions, three from Lankhorst et al. [
In the existing information analysis action, the enterprise architect analyzes existing models of the enterprise and the documentation that is made available. This action is extended with four tasks required for automation. The meta-model tasks include (1) specify the meta-model (e.g. industrial standards) and (2) import the meta-model in the EA platform. The tasks focused on the instance include (1) identify which data is available that is relevant to the model and (2) locate where are the data sources for this data. This action is completely manual because it requires the enterprise architect to interact with employees in the organization to find information, as well as analyze unstructured information.
Afterwards, in the new information gathering action, the enterprise architect collects additional information to create the models. In this case, two new tasks focused on the instance are required. These tasks are (1) connect the data sources (e.g. API, databases) to the EA platform and (2) when this is not possible export the data from the data source in a format that can be imported in the EA platform (e.g. Microsoft Excel). Contrary to the previous action, this one is fully automated because it is possible to import information in the EA platform by using “connectors” that handle the interaction with the IT systems identified in the previous action (e.g. SAP, SharePoint connectors).
The third action of the method is the new abstraction action where a domain expert (e.g. manufacturing architect, production manager) is contacted through the EA platform to add the required information (e.g. by e-mail). He or she is expected to verify if the information extracted is aligned with his or her knowledge. In case of errors in the raw information, corrected information should be inserted by the domain expert preserving the original one. For example, in excel it can be added a dedicated column where the domain expert can insert corrections. The reasoning behind this approach is that in this way the wrong information will be more easily identifiable, and the manual corrections can be replicated also in the future without the need for the domain expert to reinsert them. Afterwards, it is time to perform the classification. In this case for each information imported the right classification is applied. Manual work can be further reduced in two ways. If a classification at a detailed level is inserted the more high-level ones can be assigned automatically. On the other hand, if a high-level classification is inserted, the range of available classification at the lower levels can be shortened and only the relevant ones can be displayed. Finally, the domain expert has the opportunity to edit the name displayed in the model. The default value is the most detailed classification value. This action has three tasks. The meta-model task consists of generating the environment for the abstraction task (e.g. Microsoft Excel file with headings and formatted columns). The instance tasks are (1) request the contribution from the domain expert who receives the information and the input interface to perform the abstraction, and (2) import the outcome of the previous task in the EA platform. This action is partially automated. The preparation and import of the abstraction task are automated, while the abstraction and eventually correction tasks are performed by the domain expert.
Finally, the model structuring action consists in creating objects in the EA platform and arranging them in a visual representation of the model. In this last action, the meta-model task focuses on specifying the structure of the model in the EA platform: its development, vertical, horizontal or circular; and the presence of layers. Based on this information, the instance tasks can be executed. The tasks are the following, (1) instantiate the objects in the EA platform (e.g. an activity in a workflow model) with all the related information/attributes, and (2) generate the model following the structure specified and the meta-model rules and constraints (specified in the first action). This action is mostly automated and the only tasks performed by the enterprise architect are specifying the structure of the model and eventually correct the placement of the object in the model. 4.2
In the following section, we present the application of the method in the laboratory. We documented each action with screenshots in Fig. 2. We focused on the production process of the product variance that is mostly manufactured at this facility. First, we imported the Production Process classification metamodel in QualiWare Platform by extending the existing object “Activity”. Afterwards, we analyzed the data available in SAP ERP system and FESTO ME system, the two systems managing production at this facility. Continuing with the new information gathering action, we exported in Microsoft Excel the information about the production process from SAP ERP system (precisely, the routing operations overview table of the product) as well as the production sequence from FESTO ME system (that specifies in which sequence the production operations are executed). These data were combined in a single Microsoft Excel sheet using the operation ID as key (information to merge the information). Afterwards, we added to the Microsoft Excel file the columns required for the abstraction action. Subsequently, the authors filled the information required for the abstraction and the file was uploaded in QualiWare platform. At this point, the platform modelled the workflow model on the horizontal axis, as shown in Fig. 2d. We manually added start and end events. Having said so, this can be automated and the names of these events can be decided by the domain expert. 4.3
We evaluated the model and the method interviewing the laboratory manager. During the interview, he expressed that in the model automatically generated without abstraction the representation of the activities was both not clear and very limited. On the other hand, he thought that “going from the raw model to the one with the classifications is a big step for the industry because they get much more information into the same model”. In addition, he explained that the classification of the activities of the production process transforms information in the ERP and ME systems, that can be understood only from people that worked with these systems, to more readable and understandable information for people who have not worked with these specific applications.
Moreover, the manager proactively presented a list of extensions to the method. He recommended to create a production process model for each product variance since each product variance has limited alternative routes. These models are easy to verify and to understand. Once the models for all product variances have been developed, he recommended to create a production line or generic production process model that overlaps the activities in common in the different models and represent distinctively the ones specific to a product variance. “This would we valuable if you want to know if these ten products can be produced on the same production line”. Finally, the laboratory manager outlined also three main challenges that have been included in the discussion section.
Previous studies on automated EA modelling developed and applied methods for
generating IT models. Researchers in the field used almost exclusively network
scanning tools to generate detailed network models. The high level of detail of these
models combined with the lack of abstraction limited the application of these methods
outside the IT domain [
We identified two main implications of our research for EA researchers and
practitioners. Our results outline a new vision for the EA documentation process. In this
new vision, the enterprise architect is still engaging with stakeholders as described by
Lankhorst et al. [
At a more general level, our research is contributing to the extension of the scope of
EA. As previous literature has stated [
Moving on to the implications of our research for the manufacturing industry, the
new method contributes in several ways to the implementation of Production
Platforms. The first way is that it provides a structured approach for gathering
information. The second one is that once the connection with the IT systems is in place, it
automatically gathers information, potentially also at different points in time. Third it
generates the models without requiring a human operator to create them. Even though
the method has been applied to model production processes, we expect it to be
valuable also for modelling information related to products as well as manufacturing assets.
In our opinion, the emerging topic of Industry 4.0 can also benefit from the outcome
of our research. An architecture initiative in this domain that is becoming more and
more popular is the Reference Architecture Model Industry 4.0 (RAMI4.0) [
Based on our experience and relevant literature, we present future research directions to significantly improve the value of automated EA modelling methods.
1. How is the interaction with the domain expert improved? In what steps of the
process should a domain expert be involved?
Research in this topic is required because little or no evidence on how domain experts
or in general employees that are not part of the EA group are involved in automated
modelling. The work of Farwick et al. [
2. How to involve multiple people in the abstraction action? Which collaboration techniques can be applied? While it might seem enough to rely on a single domain expert, it would be more robust to involve multiple people in the abstraction action. There are multiple options on how to involve different people as well as how to control this action. Different solutions might require the extension of automated modelling methods with new actions.
3. How to include different data sources for automated EA modelling?
As we have also experienced in our project, relaying on a single data source is usually
insufficient to create EA models. Valja et al. [
4. How to manage and display changes in reality in the models?
Based on our experience in the Industry 4.0 laboratory and the vision of a constantly changing production environment, we expect to be challenges in how to maintain the models aligned with reality and how to visualize the changes in a timely and effective manner.
We conclude this section with four further development points for EA to better support Production Platforms: 1. Develop a feature in the EA platform to identify and classify patterns in processes.
This feature should also enable the application of these pattern in new models. In
this way, EA tools would provide an end-to-end solution to the implementation of
Production Platforms. This feature would extend the catalog of automated analysis
methods in EA from Florez et al. [
New research should investigate how to create further abstraction layers.
As mentioned in the introduction, the abstraction gap between the information available in IT systems and the content of EA models is the major challenge for automated EA modelling methods. Therefore, further research on this challenge is required to be able to spread automated modelling in the field and enhance EA practice. 6
In this paper we addressed the major challenge of automated EA modelling, namely the lack of abstraction, by developing a new modelling method that includes abstraction activities. We applied it in an Industry 4.0 laboratory for generating highlevel process models. We evaluated the method and the generated model with the manager of the laboratory. In the manufacturing industry, companies are realizing that it is crucial to develop simultaneously product and production systems. This is a concept also advocated by Industry 4.0. This is enabled by production platforms that include high-level Production Process models, like the ones generated by our method. This model provides an understanding of the production processes and in the same model product and production equipment can be related to each other. In addition, the production process model can be used as a framework for the development and introduction of cyber-physical systems in manufacturing facilities.
Our research is at an initial stage and it presents different limitations. Starting with the context of application, even though the Industry 4.0 laboratory is created with the specific goal of replicating industrial production environments, the products and their production processes are less complex than most of the manufacturing processes in the industry. In our case we have a linear production process with no branches. When modelling the production process in the industry we might experience model structuring challenges caused by the presence of several branches in the production process. Afterwards, another limitation is the fact that the method has been applied only by the authors and therefore it needs to be validated by practitioners from the industry. Finally, part of the automated solution presents minor shortcomings that have not been solved at the time of writing.
We plan to address these limitations by focusing on two main aspects in our future work. The first one is to evaluate the new method in the industry. The second one will be to improve the conceptualization of the meta-models used. The classification of Production Platform provides a meta-model of each process category and family. Further work is required to extend the meta-model to include product and equipment elements. In addition, particular focus will be reserved in creating the connections between the elements and the process since at the moment this is missing. Furthermore, to improve the modelling of system properties we are planning to investigate the applicability of Systems Modelling Language (SysML), a general-purpose modelling language for system engineering. In this way, we might be able to document systems’ properties in a structured way. In addition, adopting SysML would also further increase the level of abstraction of the models.
We thank PhD student Daniel Sorensen for the fruitful collaboration on Production Platforms during this project.