An Enterprise Architecture Planning Process for Industry 4.0
Emmanuel Nowakowski
, Matthias Farwick
, Thomas Trojer
, Martin Häusler
, Johannes Kessler
and Ruth Breu
Institute of Computer Science, University of Innsbruck, 6020 Innsbruck, Austria
Txture GmbH, 6020 Innsbruck, Austria
Keywords: Enterprise Architecture Management, Enterprise Architecture Planning, Industry 4.0, Industrial Internet of
Things, Transformation, Modeling, Process, Metamodel.
Abstract: Industry 4.0 changes the manufacturing industry significantly. In order to stay competitive, companies need
to develop new business capabilities and business models that are enabled by Industry 4.0 concepts. However,
companies are currently struggling with expensive and risky IT transformation projects that are needed to
implement such concepts. We observed a lack of research on the planning and modeling part of IT
transformations towards Industry 4.0. Therefore, we conducted a series of expert interviews on the topic of
enterprise architecture in the context of modeling and planning Industry 4.0 transformations. As a result, we
were able to develop a metamodel that can be used as target model for planning endeavors and a planning
process that helps as guideline for such planning projects.
Industry 4.0 (I4.0) is substantially influencing the
manufacturing industry (Stock and Seliger, 2016).
Companies need to adapt their business processes and
business models in order to be able to stay
competitive (Kaidalova et al., 2017).
Among the goals of the digital transformation is
to optimize processes over the whole value chain. To
achieve this, horizontal and vertical integration are
essential. Hence, the concept of interoperability is of
crucial importance, as it enables humans and
organizations to connect and communicate via IoT
and Cyber Physical Systems (CPS) (Xu et al., 2018).
In order to gain benefit, corporations either have to
introduce new connected IT systems (e.g. CPS), or
legacy machines need to be upgraded so that they are
able to communicate with other systems. This leads
to new challenges due to the pervasiveness in all types
of supply chains and organizations, which results in a
new level of IT complexity that demands for a holistic
management approach of the business, the IT, and the
production IT (Nowakowski et al., 2018).
Enterprise architecture (EA) gives a consolidated
and broad view of an entire company (Aier and
Gleichauf, 2010) and is used to capture the essentials
of business, IT, and its evolution (Lankhorst, 2013).
Enterprise architecture management (EAM) is an
IT management discipline that uses the consolidated
view of the EA to optimize IT support for business
execution and reducing IT costs.
According to TOGAF (The Open Group, 2011),
EA planning is one of the core processes of EAM and
it aims at planning IT transformations that are aligned
with the overall strategy of an organization. Such
transformation projects are usually conducted in
multiple phases and aim at meeting the emerging and
current requirements of the business (Luftman et al.,
1993; Nowakowski et al., 2017). EA planning is
executed by modeling different scenarios (to-be
architectures) that represent the future steps in the
transformation project, which transforms the current
architecture (as-is) into a specified target architecture.
Afterwards, the planned steps are documented,
executed, and evaluated. The planning phase is of
crucial importance to ensure that digital
transformations are successful.
In our research, we consider an EA planning
methodology for digital transformations. Our past
research on the topic of EA planning in the context of
I4.0 transformations (Nowakowski et al., 2018)
indicated that there is a need for a structured planning
Nowakowski, E., Farwick, M., Trojer, T., Häusler, M., Kessler, J. and Breu, R.
An Enterprise Architecture Planning Process for Industry 4.0 Transformations.
DOI: 10.5220/0007680005720579
In Proceedings of the 21st International Conference on Enterprise Information Systems (ICEIS 2019), pages 572-579
ISBN: 978-989-758-372-8
2019 by SCITEPRESS Science and Technology Publications, Lda. All rights reser ved
process and a metamodel for I4.0. These two artifacts
are able to guide companies in their planning
endeavors. The I4.0 metamodel proposes a target data
model for the transformation project and the process
helps to realize it by using an agile approach. Both of
these artifacts were developed and evaluated based on
an interview series with industry experts and are
presented in the paper at hand.
The remainder of this paper is structured as
follows: Section 2 describes our research method and
research questions. Furthermore, in Section 3 relevant
related work is presented. In Section 4, we describe
our interview results consisting of the proposed I4.0
metamodel and the I4.0 planning process in detail.
Section 5 contains the discussion and future work.
Finally, Section 6 concludes our paper.
The research presented in this paper is based on
Hevner’s three-cycle approach for design science
research (DSR) that consists of a relevance, a design,
and a rigor cycle (Hevner, 2007). The goal of DSR is
to create IT artifacts that are able to solve
organizational problems and to evaluate them
rigorously (Hevner et al., 2004). Figure 1 depicts how
we applied the DSR approach.
The design cycle builds the core of the DSR
approach. In this cycle, we developed a metamodel
and a planning process for I4.0 transformation
planning. The requirements for the artifacts and the
acceptance criteria for their evaluation come from the
relevance cycle. Considering the rigor cycle, the DSR
artifacts are influenced by the results of the conducted
literature review.
Figure 1: DSR applied to our research project (based on
(Hevner, 2007)).
For analyzing the relevance of our research, we
conducted an interview series consisting of nine
experts in the field. From these interviews, we aimed
to establish a deeper understanding of how I4.0
planning is conducted. Additionally, we discussed
relevant metamodel elements and the connections
between them, and evaluated the developed
The following two research questions (RQ) build
the core of this paper:
RQ1: What kind of information should be part
of the documentation model so that EA
planning in the context of I4.0 can be
RQ2: Which steps are needed to conduct I4.0
transformation planning and how should the
process be structured?
In this section, related work for I4.0 metamodels,
frameworks, and transformation processes that are
conducted with the help of EA is presented.
Molano et al. (2018) developed a metamodel for
the integration of the Internet of Things (IoT), social
networks, the cloud and I4.0. However, their
metamodel is mainly focused on communication
flows from the various sensors and actuators to a
specific IoT device.
Furthermore, Bücker et al. (2016) created a
framework, which is based on I4.0 design principles
and an approach to structure an organization. For
achieving this, they developed a metamodel of the
proposed I4.0 transformation process, which focuses
on change management of the organizational aspects.
Goerzig and Bauernhansl (2018) developed a
method which makes use of agile EA for digital
transformations. Their approach is based on Scrum
(Schwaber, 2004), hence, the EA evolution is done
iteratively with the help of sprints and via user stories
and a backlog.
Additionally, reference architectures for smart
industry, such as the “Industrial Value Chain
Reference Architecture-Next” (IVRA Next)
(Industrial Value Chain Initiative, 2018), the
“Industrial Internet Reference Architecture” (IIRA)
(Industrial Internet Consortium, 2017), and the
“Reference Architecture Model Industrie 4.0” (RAMI
4.0) (Bitkom et al., 2016) were developed.
Furthermore, there are efforts to align the proposed
architectures of RAMI 4.0 and the IIRA (Plattform
Industrie 4.0 and Industrial Internet Consortium,
Considering EAM, the most commonly used
framework is TOGAF (The Open Group, 2011) with
its architecture development method (ADM), which
is a generic method intended to be used by a wide
variety of different enterprises (The Open Group,
2011). Furthermore, the modeling language
An Enterprise Architecture Planning Process for Industry 4.0 Transformations
ArchiMate (The Open Group, 2016) is considered as
standard. ArchiMate introduced a physical layer in
version 3.0 (The Open Group, 2016) that was inspired
by the I4.0 development. Franck et al. (2017) found
shortcomings of ArchiMate 3.0 while they worked on
an EA solution for I4.0 and developed new concepts
and modeling patterns to compensate for them.
Furthermore, Rogers (2016) conducted research on
I4.0 simulation-based information assets that is based
Zimmermann et al. focus on the transformation of
EA for the IoT, architectural decision making for
digital transformations, and the evolution of EAs
(Zimmermann et al., 2016, 2015b, 2015a). However,
the authors mainly discuss the improvement of
decision-making and do not elaborate on techniques
that help practitioners to model and plan target
architectures in the context of IoT or I4.0.
Finally, Kaidalova et al. (2017) discuss the
challenges in integrating operational technology (OT)
into EA, where OT consists of the IT systems and
production machines that are located on the shop-
floor of a company. The researchers concluded that
traditional EA layers (business, application, and
technology) are suitable but not optimal for
structuring OT. They propose that refinement layers
are needed, e.g. by identifying a “mixed zone”
between OT and business IT that has a different
structure and granularity (Kaidalova et al., 2017).
With the help of the interviews we aimed to gain
information about the process how I4.0
transformation projects are conducted and about the
required artifacts and resources. Furthermore, we
investigated on which abstraction level the planning
needs to be done and what is documented during this
For this purpose, we interviewed professionals in
the field of EAM who are working in the industry and
have experience with digital transformation projects.
The interviews were conducted in the timespan
between October and November 2018. We were able
to interview nine interviewees from four different
industry sectors in Germany, Austria, and
Switzerland (see Table 1).
The interviewees were identified via Linked-In
and XING – a business social network for German-
speaking countries. Here, it was specifically searched
for enterprise architects in industrial companies. We
contacted 42 potential interview partners from which
ten responded (~24%). Six of these and three of our
former interview partners, from which two are
consultants with I4.0 experience, agreed to
participate. Hence, we conducted our interview series
with nine participants in total that are all employed in
different companies. Additionally, we were able to
use a part of the interview results from our previous
research (Nowakowski et al., 2018).
Table 1 gives an overview of the interviewees’
position in the company, the location, as well as the
industry sector. The role of the participants is added
to the abbreviation (see last row in Table 1).
Table 1: Interviewee overview.
and Role
Country Industry sector
PE1 Austria Manufacturing
PE2 Germany Manufacturing
PE3 Germany Manufacturing
PE4 Germany Manufacturing
PE5 Germany Manufacturing
PE6 Germany Chemical
PE7 Germany Pharma
PC8 Germany Consulting
PC9 Switzerlan
E = enterprise architect, C = consultant
The interviews were conducted in a semi-
structured way, were based on a fixed set of open
questions, and took in average about 45 min.
Furthermore, they were recorded for later analysis.
The interviews were transcribed and coded
according to the procedure described by Mayring
(2014). For this purpose, a completely data-driven
coding frame in combination with successive
summarizing, as proposed by Flick (2014), was used.
The coding frame is the basis of the analysis
methodology and consists of main and subcategories.
Main categories are aspects for which more
information are needed and subcategories specify
what is said in respect to the main categories (Flick,
2014). With the help of successive summarizing,
relevant passages of the interviews were paraphrased
and the superfluous aspects were deleted. After that,
the categories and subcategories were built by
summarizing similar paraphrases. The next step was
to check if there exist similar subcategories and to
collapse them. Two rounds of coding were conducted
based on the coding frame. This was done by one
coder at different points in time and the results were
compared in order to ensure coding consistency. As
proposed by Flick (2014), the transcripts were
segmented in a way that each unit fits exactly one
category or subcategory of the coding frame to ensure
that each time the codes were applied to identical
parts of the transcripts. For checking if our coding
ICEIS 2019 - 21st International Conference on Enterprise Information Systems
frame needs to be adapted, we applied this procedure
to a subset of our transcripts before it was used for the
analysis of all transcripts. Finally, as suggested by
Flick (2014), the final coding of all transcripts and the
preparation of the coding results for answering the
research questions was conducted.
From the interviews, we were able to extract the
proposed I4.0 target metamodel, and the planning
process for I4.0 transformations, which are described
in detail in the following subsections.
4.1 Metamodel for I4.0
Based on the interview results we were able to
enhance the proposed four-layer model from our
previous work (Nowakowski et al., 2018), which
builds the basis for our I4.0 target metamodel. The
layered model, shown in Figure 2, adapts the classical
three-layer approach of EAM (business layer,
application layer, and technology layer) (The Open
Group, 2011) and adds two new layers. The
operational layer tackles the growing similarities of
production machines and applications, as they now
have the same security, update, and release
management requirements. Hence, it is not possible
to distinguish between technology and application
layer anymore. Additionally, these automation assets
now need to be part of the EA, while in the past OT
and business IT were strictly separated from each
other (Nowakowski et al., 2018). These assets are
located in the operational layer and are connected to
the business, application, and technology layers.
Furthermore, the external interface layer is used for
the horizontal integration of the business partners
(e.g. suppliers) and customers, as they are now
directly involved with the production processes.
Figure 2: Five-layer approach for EAM.
The proposed metamodel, shown in Figure 3,
depicts a target EA model with incorporated I4.0
concepts. In the following paragraphs, the metamodel
layers and elements are described in detail.
External Interface Layer. As depicted in Figure 2,
the external interface layer connects to the business
and to the operational layer. It normally consists of
partner systems and the customer. These two
information sources are important to achieve
horizontal integration, which is one key aspect of I4.0
(Xu et al., 2018). The production system is connected
via an interface to the partner systems to be able to
e.g. order parts automatically. On the other hand, the
customer is directly involved in the production
process and is therefore able to order highly
customized products. The external interface layer is
not included in the metamodel because it is not
directly part of the EA. However, the business
capability to manage this information needs to exist
Standard EA Layers. The business layer consists of
business capabilities, business processes, and the
specific product that is produced. Here, the new
aspect is the connection to the operational layer. The
application layer consists of the applications, the
interfaces and data objects that are transferred with
the help of these interfaces. In the case of I4.0, the
interface is also connected to the operational layer,
which makes it e.g. possible to analyze machine data.
The technology layer consists of technology assets
like servers and storage devices. According to the
interviewees, these assets are needed in order to be
able to conduct impact analysis and are modeled on a
course-grained level. Additionally, as many
companies are currently migrating their assets to the
cloud, detailed technology modeling is not important
anymore (PE3).
Operational Layer. The difference to established
EAM metamodels is that the business layer, the
application layer, and the technology layer are now
connected to the operational layer, which makes it
possible that e.g. production machines and sensors
can be associated to a business capability.
Furthermore, it is possible to drill down directly to the
machines and sensors, which is according to the
interviewees necessary in order to be able to plan I4.0
transformations. According to PC8 and PC9, it is
crucial to know the interdependencies between OT
and business IT in order to be able to see how well it
is integrated.
As can be seen in Figure 3, the operational layer
consists of production processes, I4.0 components
and sensors. All of these elements can be connected
to business capabilities that are needed for the
execution of I4.0 business models. The I4.0
components, as well as the products, may have
sensors attached. This enables monitoring and
analyzing production machines that are relevant for
executing the production processes. Sensor data can
be transferred via an interface and be analyzed with
the help of an application to e.g. conduct predictive
maintenance. Additionally, customers now have
direct influence on the production process. Hence, it
is necessary that the highly customized products can
be individually produced by the factory. For this
purpose, the I4.0 components need to be able to
An Enterprise Architecture Planning Process for Industry 4.0 Transformations
communicate with each other. Additionally, the
sensors on the product enable the introduction of new
services. With the help of detailed analysis of the
sensor data and the actual usage of the product, it is
possible to create new business models. Furthermore,
it is important to know in which factory the I4.0
components are located; therefore, the components
are linked to the location.
According to RAMI4.0 (Bitkom et al., 2016), an
I4.0 component comprises one or more objects and an
administration shell that consists of the functions of
the technical functionality and the data for virtual
The production processes are modeled separately
from the business processes. According to the
interviewees the two kind of processes differ
significantly. Production processes are modeled in the
OT department and are solely concerned with the
Enterprise architects mostly work with aggregated
data and in some situations want to be able to drill
down to a sensor type. Hence, in the proposed
metamodel the I4.0 components and the sensors are
only modeled with the type information attached.
Therefore, it is possible to distinguish between
different types of sensors and machines without
needing to know about the specific instances. This
makes a drill down and impact analysis still possible.
Additionally, the I4.0 component can be used as an
interface to the operational department. In this case,
the operational department models the low level OT
architecture and is able to connect it to the EA via the
operational layer, which enables to create holistic
plans. This is especially important for digital
transformation projects, as mentioned by PE1.
Though, choosing the right scope and level of
granularity for the planning is challenging.
With the help of ArchiMates’ physical layer, the
OT can be modeled in detail. However, the
interviewees required an abstract view on the
production machines and other I4.0 components that
is based on type information. Hence, in our
metamodel only abstract concepts are modeled.
4.2 Transformation Planning for I4.0
In this subsection, the proposed planning process (see
4) is described in detail. The process was
developed on the basis of our interview results and
existing planning methods for EAM.
According to our interviewees, a digital
transformation has to be conducted in an agile way
because waterfall methods are too rigid for this kind
of project. We analyzed the results of our interviews
and extracted the relevant planning steps that our
interview partners mentioned and developed an agile
I4.0 transformation planning process. This process is
based on Goerzig and Bauernhansl (2018), which
makes use of the agile Scrum method (Schwaber,
2004). The process consists of several steps and is
iterative. Goerzig and Bauernhansl (2018) divided
their approach into two cycles, a micro and a macro
cycle. The macro cycle defines the architecture of the
Figure 3: EA metamodel considering Industry 4.0 concepts.
ICEIS 2019 - 21st International Conference on Enterprise Information Systems
entire company and the micro cycle is used for the
implementation and testing of single functions. For
our approach, we use a specification, a project and an
implementation cycle. In the specification cycle, the
whole architecture specification happens, while in the
project cycle, the business stories are implemented
and tested. Business stories are similar to user stories
in the Scrum context and describe a business goal.
Finally, the implementation cycle is needed for
implementing the resulting IT projects.
We used the digital business strategy as initial
point of the approach, which contains basic decisions
concerning scale, speed, and scope of the digital
technology application in the enterprise (Goerzig and
Bauernhansl, 2018). In our definition, it consists of
scope, scale, and speed of the I4.0 transformation.
Matt et al. (2015) concluded that it is necessary to
derive the transformation strategy out of the digital
business strategy. The transformation strategy
consists of organizational and technological
principles for the implementation of the
transformation (Goerzig and Bauernhansl, 2018).
Furthermore, the strategy influences the model of the
target architecture.
According to the interviewees, the first step in the
specification cycle is to derive the business model
from the digital business strategy. The business
model contains information like customer segments,
revenue stream, and value propositions (Goerzig and
Bauernhansl, 2018).
The next step is to derive the needed business
capabilities from the new business model (PE2, PE3,
and PE4). After that, the capabilities need to be
analyzed and compared with the currently available
capabilities to identify gaps. This analysis is mostly
done with the help of capability maps.
After the capability gaps are found, the required
business processes are derived from the new
capability. Again, the set of new business processes
is compared to the currently available processes and
the gaps are documented. This is done with the help
of business process landscapes or maps.
With the knowledge gained from the steps before,
a target EA architecture can be developed. This
architecture needs to close the found gaps in order to
be able to introduce the new business model.
Additionally, the target model is influenced by the
transformation strategy, which dictates the
technological and organizational principles of the
transformation. Furthermore, the application and the
technology landscape need to be analyzed to make
sure that the new business processes are appropriately
supported. This is usually done with the help of
landscape visualizations, which show the
technologies or applications and their
interdependencies. If there are gaps to the current
architecture, they are documented again. According
to the interviewees, for the planning of the target
architecture multiple scenarios are developed, which
are compared and the one that fits best is chosen to be
implemented. The fit criteria depend on the
transformation strategy. As last step, the gaps to the
as-is architecture are formulated into business stories,
which describe the users, the desired functionality,
and the benefit and are put in the architecture backlog.
Afterwards, the business stories are prioritized and
ready to be implemented.
When the best fitting target architecture is chosen,
the first iteration of the specification cycle is finished
and the project cycle begins with choosing the
prioritized business stories from the backlog. The
amount of the chosen business stories depends on the
aimed speed of change of the company, which is
defined in the transformation strategy.
The next step is to implement the business story
with the highest priority. For this purpose, the gaps
that were found in the specification cycle are
analyzed again and closed according to the specified
target architecture.
After that, it is checked if the architecture is now
capable of depicting the new business story and if all
identified gaps are closed. To evaluate the newly
implemented business capability a proof of concept
(PoC) with a pilot customer can be used. The newly
needed IT artifacts are developed in the
implementation cycle and tested again.
In the review, the final step in the project cycle,
the state of the business story is either marked as
done, adaptations need to be implemented, or the
overall impact on the architecture needs to be
analyzed again. If it is marked as done, the teams start
with the next business story. Otherwise, if there are
still adaptations required, the project cycle starts
again. Finally, if the changes generate findings that
have an impact on the whole architecture, the
specification cycle has to start again (Goerzig and
Bauernhansl, 2018).
According to Goerzig and Bauernhansl (2018),
the architecture after the first iteration of the
specification cycle is still very rough and more details
are added with every run. Additionally, the
specification cycle should always give enough space
for decisions in the project and implementation cycle.
However, the business critical core processes
should still be planned with the help of a waterfall
method (PE4 and PE5). Additionally, PE5 mentioned
that they are using agile methods for planning the
architecture and the introduction of new capabilities
An Enterprise Architecture Planning Process for Industry 4.0 Transformations
Figure 4: Agile EA planning for Industry 4.0 transformations (based on (Goerzig and Bauernhansl, 2018)).
until the PoC phase. Afterwards, for the business
wide release they are planning based on waterfall
Our future work will consider further evaluation of
the proposed artifacts. Hence, we plan to conduct a
new interview series in which the interviewees will
use the planning process and the metamodel for
modeling a small example transformation. For this
purpose, a tool will be used that is outcome of our
previous research on automated EA documentation
(Trojer et al., 2015). Additionally, confirmatory
interviews are planned to evaluate if the developed
artifacts are useful in their current state. Furthermore,
we will evaluate the metamodel and the planning
process with the help of a case study to ensure their
applicability and a better alignment between the two
The planning process needs further investigation,
as details like team size and holistic EA planning via
agile methods in general are still open research
questions that are subject of current research on this
Finally, the proposed research artifacts can be
used to extend the TOGAF ADM and therefore to
introduce a holistic planning guideline for digital
transformations into the framework.
This paper presented an EA planning approach for
digital transformations that consists of a planning
process and a metamodel that serves as a target data
model. Both of these DSR artifacts were developed
based on the results of a series of expert interviews.
Furthermore, the interview results showed that
OT needs to be part of the EA in order to be able to
plan such transformations. This was materialized by
introducing a new operational layer to the standard
three-layer approach of EAM. This layer consists of
I4.0 components, the production processes and
sensors, where the I4.0 components are connected via
an interface to the application layer. The I4.0
components and the sensor may not be modeled in
detail, but on an abstract basis only considering their
types. The operational layer can also be used as a
modeling interface to the detailed OT models and
therefore connects both worlds.
The proposed planning process is an agile
approach that is based on the Scrum method. The
process makes a detailed planning of the EA in
several iterations possible. This is needed for the
introduction of I4.0 concepts, as it is faster to conduct
than planning based on a waterfall method.
This research was partially funded by the research
project “txtureSA” (FWF-Project P 29022).
Aier, S., Gleichauf, B., 2010. Towards a Systematic
Approach for Capturing Dynamic Transformation in
Enterprise Models, in: 43rd Hawaii International
Conference on System Sciences. pp. 1–10.
Bitkom, Vdma, Zvei, 2016. Implementation Strategy
Industrie 4.0 [WWW Document]. URL
Industrie-40-ENG.pdf (accessed 18.02.19).
ICEIS 2019 - 21st International Conference on Enterprise Information Systems
Bücker, I., Hermann, M., Pentek, T., Otto, B., 2016.
Towards a Methodology for Industrie 4.0
Transformation. Bus. Inf. Syst. 255, 209–221.
Flick, U., 2014. The SAGE Handbook of Qualitative Data
Analysis. SAGE Publications Ltd., London.
Franck, T., Iacob, M.-E., Van Sinderen, M., Wombacher,
A., 2017. Towards an Integrated Architecture Model of
Smart Manufacturing Enterprises, in: Proceedings of
the 7th International Symposium on Business Modeling
and Software Design (BMSD 2017). pp. 112–133.
Goerzig, D., Bauernhansl, T., 2018. Enterprise
Architectures for the Digital Transformation in Small
and Medium-sized Enterprises. Procedia CIRP 67,
Hevner, A.R., 2007. A Three Cycle View of Design Science
Research. Scand. J. Inf. Syst. 19, 87–92.
Hevner, A.R., March, S.T., Park, J., Ram, S., 2004. Design
Science in Information Systems Research. MIS Q. 28,
Industrial Internet Consortium, 2017. The Industrial
Internet of Things Volume G1: Reference Architecture.
Industrial Value Chain Initiative, 2018. Strategic
Implementation Framework of Industrial Value Chain
for Connected Industries.
Kaidalova, J., Sandkuhl, K., Seigerroth, U., 2017.
Challenges in Integrating Product-IT into Enterprise
Architecture – A Case Study. Procedia Comput. Sci.
121, 525–533.
Lankhorst, M., 2013. Enterprise Architecture at Work -
Modelling, Communication and Analysis, 3rd ed.
Springer-Verlag, Berlin, Heidelberg.
Luftman, J.N., Lewis, P.R., Oldach, S.H., 1993.
Transforming the Enterprise: The Alignment of
Business and Information Technology Strategies. IBM
Syst. J. 32, 198–221.
Matt, C., Hess, T., Benlian, A., 2015. Digital
Transformation Strategies. Bus. Inf. Syst. Eng. 57, 339–
Mayring, P., 2014. Qualitative Content Analysis -
Theoretical Foundation, Basic Procedures and Software
Molano, J.I.R., Lovelle, J.M.C., Montenegro, C.E.,
Granados, J.J.R., Crespo, R.G., 2018. Metamodel for
integration of Internet of Things, Social Networks, the
Cloud and Industry 4.0. J. Ambient Intell. Humaniz.
Comput. 9, 709–723.
Nowakowski, E., Farwick, M., Trojer, T., Haeusler, M.,
Kessler, J., Breu, R., 2018. Enterprise Architecture
Planning in the Context of Industry 4.0
Transformations, in: 22nd International Enterprise
Distributed Object Computing Conference (EDOC).
pp. 35–43.
Nowakowski, E., Farwick, M., Trojer, T., Haeusler, M.,
Kessler, J., Breu, R., 2017. Enterprise Architecture
Planning: Analyses of Requirements from Practice and
Research, in: 50th Hawaii International Conference on
System Sciences.
Plattform Industrie 4.0, Industrial Internet Consortium,
2018. Architecture Alignment and Interoperability.
Rogers, C., 2016. Proposed Enterprise Architecture
Solutions for Industry 4.0 Manufacturing Simulation
Information Assets Based on TOGAF.
Schwaber, K., 2004. Agile Project Management With
Scrum. Microsoft Press, Redmond, WA, USA.
Stock, T., Seliger, G., 2016. Opportunities of Sustainable
Manufacturing in Industry 4.0. Procedia CIRP 40, 536–
The Open Group, 2016. ArchiMate 3.0 Specification. Van
Haren Publishing.
The Open Group, 2011. TOGAF Version 9.1, 10th ed. Van
Haren Publishing.
Trojer, T., Farwick, M., Haeusler, M., Breu, R., 2015.
Living Modeling of IT Architectures: Challenges and
Solutions, in: Software, Services, and Systems - Essays
Dedicated to Martin Wirsing on the Occasion of His
Retirement from the Chair of Programming and
Software Engineering. pp. 458–474.
Xu, L. Da, Xu, E.L., Li, L., 2018. Industry 4.0: State of the
Art and Future Trends. Int. J. Prod. Res. 7543, 1–22.
Zimmermann, A., Jugel, D., Sandkuhl, K., Schmidt, R.,
Schweda, C.M., Möhring, M., 2016. Architectural
Decision Management for Digital Transformation of
Products and Services. Complex Syst. Informatics
Model. Q. 31–53.
Zimmermann, A., Schmidt, R., Jugel, D., Möhring, M.,
2015a. Evolving Enterprise Architectures for Digital
Transformations, in: Digital Enterprise Computing
2015. pp. 183–194.
Zimmermann, A., Schmidt, R., Sandkuhl, K., Wissotzki,
M., Jugel, D., Mohring, M., 2015b. Digital Enterprise
Architecture - Transformation for the Internet of
Things, in: Enterprise Distributed Object Computing
Workshop (EDOCW). pp. 130–138.
An Enterprise Architecture Planning Process for Industry 4.0 Transformations