Towards an Integrated Architecture Model of
Smart Manufacturing Enterprises
Thijs Franck
1
, Maria-Eugenia Iacob
2
, Marten van Sinderen
2
and Andreas Wombacher
1
1
Wipro Technologies, Eindhoven, The Netherlands
2
Centre for Telematics and Information Technology, University of Twente, Enschede, The Netherlands
Keywords: ArchiMate 3.0, Enterprise Architecture, ISA-95, Smart Manufacturing, Industry 4.0.
Abstract: With the introduction of smart manufacturing, the scope of IT expands towards physical processes on the
shop floor. Enterprise architects, software engineers and process engineers will have to work closely together
to build the information systems that are connected to the shop floor and aligned with the business needs of
smart manufacturers. However, it is unclear whether they have the means to do so. This research aims to
provide enterprise architecture modelling support for smart manufacturers by investigating ArchiMate 3.0’s
fitness for this purpose. ArchiMate 3.0 meta-model is compared to the ISA-95 standard for enterprise systems
and control systems integration. Modelling patterns are introduced, along with some new modelling concepts,
to compensate for deficiencies found. The patterns proposed are validated as part of a case study.
1 INTRODUCTION
Manufacturing companies worldwide are facing the
need to improve productivity and quality, as well as
implement new products, while shortening
innovation cycles. To this end, the manufacturing
industry is currently in the process of adopting the
new Smart Manufacturing paradigm, also known as
the Industry 4.0 paradigm. Smart Manufacturing
promises smart machine line operations, high-fidelity
models of production processes and improved
decision-making support (Davis et al., 2005).
For the benefits of Smart Manufacturing to
materialize, manufacturers will need some way to
maintain alignment between their business needs and
the information systems that permeate increasingly
through all levels of their operations (Henderson and
Venkatraman, 1993, Wagner and Weizel, 2006).
Maintaining alignment between a company’s strategy
(the business domain) and its supporting IT is one of
the main benefits of enterprise architecture (EA)
(Boucharas et al., 2010).
The management of processes at the shop floor
and the systems used to operate the industrial control
devices have traditionally fallen under the Operations
Technology (OT) domain of process engineers. As
OT increasingly starts to overlap with IT, it makes
sense to consider the physical domain from an IT
perspective. As a result, the dichotomy between IT
and OT fades, in favour of a single EA for the
manufacturing domain.
To make this integration between business, IT and
OT successful, enterprise architects and process
engineers must have a shared modelling language that
can express all concepts required for modelling the
EA of the manufacturing domain. One of the major
requirements introduced by Smart Manufacturing is
the modelling of cyber-physical systems (ISCPS).
CPS is a type of information system that integrates
computational and physical processes and allows
these processes to interact (Lee, 2008). For example,
an oven may report real time its temperature curve. If
this curve is sub-optimal, the oven wastes energy.
Such an insight could be used as input for operational
excellence programs, or preventive maintenance.
The modelling of such systems will involve not
just viewpoints and concepts related to applications
and IT infrastructure, but also to the physical
environment (i.e., conditions on the shop floor)
(Sacala and Moisescu, 2014).
For this research, we adopt the international open
standard ArchiMate as our EA modelling language of
choice. The most recently published version of the
standard, ArchiMate 3.0 (The Open Group, 2016),
already includes several concepts for modelling the
physical environment of enterprises. Being a new
61

release, however, it has not been seriously validated
or applied in the manufacturing domain.
To ensure that ArchiMate enables the modelling
of a smart manufacturer’s EA, the standard needs to
be validated for that particular purpose. We adopt a
process framework and a common object model
published as part of the standards suite ANSI/ISA-95
(ISA, 2010a, ISA, 2010b) (alternatively, ISO/IEC
62264), or ISA-95 for short, to represent the
manufacturing domain. The ISA-95 common object
model (ISA, 2010b) describe entities at the shop floor
level, where IT and OT interact, whereas the ISA-95
process framework describes exactly this interaction.
Conversely, while ISA-95 describes the physical
domain, it does not describe the business or IT
domains very well, nor was it intended to model EAs
in the first place. Thus, to be capable of modelling the
EA of a smart manufacturer, ArchiMate 3.0’s meta-
model needs to be able to express all architectural
concepts from ISA-95. To that end, this paper tries to
answer the following questions:
RQ1. To what extent can ArchiMate 3.0 express
the EA of any smart manufacturer per ISA-95?
RQ2. If ArchiMate 3.0 cannot fully express the EA
of any smart manufacturer per ISA-95, what changes
to the meta-model of ArchiMate 3.0 are necessary to
make this possible?
Thus, the contribution of this research concerns an
analysis of whether the meta-model of ArchiMate 3.0
is expressive enough to model an EA in the
manufacturing domain. Secondly, we propose a set of
modelling patterns describing how ISA-95 concepts
can be expressed in ArchiMate. These patterns can be
simple direct mappings, or may involve a grouping of
Archimate concepts. Finally, to enhance ArchiMate’s
expressiveness and enable the modelling of certain
smart manufacturing concepts some change
suggestions are made.
The remainder of the paper is organised as
follows. In Section 2 we explain the methodology we
followed to define a mapping from ISA-95 to
ArchiMate, and to analyse the expressiveness of
ArchiMate. Section 3 describes the results of the
analysis, and contains the main contribution of the
paper. Section 4 gives an account of how we validated
our findings. We conclude the paper with a discussion
of the related work in Section 5 and with conclusions
and some pointers to future work in Section 6.
2 METHODOLOGY
To define a mapping from ISA-95 to ArchiMate and
answer research questions, we followed a four-step
approach. Firstly, we derived a subset of architectural
concepts from the concepts defined by ISA-95. ISA-
95 was written with IT/OT integration in mind. To
apply its concepts to architecture modelling, an
assessment is necessary to find out which concepts
qualify as architectural. For this assessment, the same
criteria that were used to define the current set of
concepts in ArchiMate are applied to each concept in
ISA-95. These criteria are explained in section 3.1.
Secondly, we make a comprehensive mapping of
the architectural ISA-95 concepts onto ArchiMate
3.0. Criteria used for the mapping are the similarity of
concept definitions, as well as similarity of direct
relationships to other concepts (depth = 1).
Thirdly, the ArchiMate’s expressiveness
concerning the smart manufacturing domain is
investigated by identifying semantic deficiencies in
terms of the types defined by Wand & Weber (2002)
(see Section 3.3). We assume that the ISA-95
common object model is a complete representation of
entities at the shop floor level. Given our goal of
representing this same domain in ArchiMate 3.0, the
ISA-95 common object model should fully map onto
ArchiMate 3.0. Whether ISA-95 can fully express
ArchiMate is not of interest. Thus, we only consider
deficiencies of type construct overload, where several
ISA-95 constructs map to one ArchiMate construct,
and type construct deficit, where an ISA-95 construct
does not map to any ArchiMate construct.
The deficiencies identified are subsequently
analysed and, if necessary, addressed. In the case of
construct overload, an assessment is made concerning
critical expressiveness loss as result of the higher
abstraction level. In the case of construct deficit, it
must be determined whether the intended meaning of
the ISA-95 concept can be expressed using a
combination, or ‘pattern’, of constructs currently
present in ArchiMate 3.0’s meta-model. If the current
meta-model is found insufficiently expressive, we
suggest a pattern that includes new constructs (i.e.,
new relationships or concepts).
Finally, the identified patterns are validated as
part of a case study at SteelCorp. The validation aims
to prove the usefulness of the patterns in modelling
the EA of a manufacturer, as well to demonstrate the
usefulness of such a model through two common
manufacturing use cases: an impact of change
analysis and an operational excellence analysis.
3 ANALYSIS
The results of several parts of the analysis have been
summarized in a spreadsheet (from here on referred
Seventh International Symposium on Business Modeling and Software Design
62

to as ‘the spreadsheet’) which is made available
online via http://bit.ly/2amGJqi.
3.1 Excluding Non-Architectural
Concepts from ISA-95
To determine the architectural concepts in the ISA-95
common object model, it is necessary to perform a
‘normalization’ of the ISA-95 concepts to a level of
abstraction that coincides with that of ArchiMate
concepts. The criteria for normalization are the same
as those originally used to determine the ArchiMate
concepts. ArchiMate uses for this a layered structure
(Lankhorst et al., 2010). Starting at the lowest
specialization level, concepts are simply highly
abstract entities and their relationships. At the next
level, concepts are specialized as either passive
structure concepts, behaviour concepts or active
structure concepts, corresponding to the basic
structure of the ArchiMate language (dynamic system
level). Concepts are then further specialized as EA
concepts used to design architecture models.
ArchiMate defines implementations of concepts in
architecture models as its lowest level of abstraction.
At each specialization step, the utility of the
specialization must be argued based on the modelling
goals that the modeller has in mind. Following this
structure, any ISA-95 concept that is architectural
will need a specialization relationship to one of the
concept types at ArchiMate’s dynamic system level.
The concepts at the dynamic system level are defined
as follows (Table 1):
Table 1: Dynamic System Level Concept Types (Lankhorst
et al., 2010).
Concept type Description
Active Structure
Concept
An entity that is capable of performing
behaviour
Behaviour
Concept
A unit of activity performed by one or
more active structure elements
Passive Structure
Concept
An object on which behaviour is
performed
By eliminating all ISA-95 concepts that do not
have a specialization relationship to one of these
concepts, we end up with a normalized set of
architectural concepts. The normalization analysis
reveals that 66% of ISA-95 concepts are architectural.
The remaining 33% are non-architectural. For
example, ‘person’ qualifies as architectural concept
since a person can perform behaviour. Properties
describing that person are non-architectural concepts.
To review specifically which concepts classify as
architectural, please refer to the spreadsheet.
3.2 Mapping ISA-95 to ArchiMate 3.0
To define a mapping from ISA-95 concepts to
ArchiMate we follow a two-step approach: Firstly,
for each architectural ISA-95 concept, a comparison
is made between its definition and the definition of
every ArchiMate concept. Secondly, if there is a fit
with one or more definitions, a further comparison is
made. In this comparison, each direct relationship
(depth=1) of the ISA-95 concept is compared to each
of the concepts directly surrounding the ArchiMate
concept. This includes both the definition of the
surrounding object and the definition of the
connecting relationship. If these relationships are also
in alignment, an ISA-95 concept maps to ArchiMate.
For 12% of ISA-95’s architectural concepts the
mapping to ArchiMate concepts is straightforward.
75% can be fit based on definition, but have one or
more relationships that cannot be mapped. Finally,
13% of the concepts cannot be matched based on their
definition. For an exact specification of the ISA-95
concepts that can be mapped onto specific ArchiMate
3.0 concepts, please refer to the spreadsheet.
N-to-M mappings
In some cases, it turns out that that several concepts
from ISA-95 map to several other concepts from
ArchiMate. These mappings are ambiguous, causing
uncertainty with regards to which concept to use.
According to the mapping, several concepts would be
correct. These n-to-m mappings need to be addressed
before moving forward. Particularly, this concerns
the following two mapping scenarios.
Process Segment:
Process Segment, Process Segment Dependency,
Operations Segment, Operations Segment Dependency
Map to
Business Process, Business Function, Business
Interaction, Business Event
There appears to be an n-to-m mapping in this
scenario. However, strictly comparing the definitions
of the ISA-95 concepts, as well as the relationships
they share to surrounding concepts (depth = 1), the
ISA-95 concepts turn out to be synonymous. This
resolves the n-to-m mapping to concept redundancy,
which will be addressed in section 3.3. This case shall
be further referred to as Process Segment.
Equipment:
Equipment Class, Equipment
Map to
Business Role, Location, Equipment, Facility
In this second scenario, Equipment and
Equipment Class are not synonymous per the ISA-95
meta-model. However, given that ArchiMate does not
distinguish between classes and instances, Equipment
Class and Equipment can safely be abstracted to mean
Towards an Integrated Architecture Model of Smart Manufacturing Enterprises
63

the same thing. This, again, resolves the n-to-m
mapping to concept redundancy, which will be
further discussed in section 3.3. This case shall be
further referred to as Equipment.
3.3 Classifying Deficiencies in
ArchiMate 3.0
Based on the previously established mapping of ISA-
95 onto ArchiMate, several deficiencies in ArchiMate
3.0 can be identified. Classifying each deficiency will
help find a suitable solution at a later stage. Four types
of deficiency exist (Wand and Weber, 2002). Table 2
describes each type.
We assume that the ISA-95 common object model
is a complete representation of the entities on the shop
floor. Thus, if ArchiMate is capable of modelling the
EA of a smart manufacturer, its meta-model should
be capable of expressing ISA-95. Based on this
analysis, several cases of construct overload, as well
as construct deficit, are uncovered. The following
sections discuss the occurrences of each type.
Table 2: Types of deficiencies (Wand and Weber, 2002).
Type Descri
p
tion
Construct
overload
Several ontological constructs map to
one grammatical construct
Construct
redundanc
y
Several grammatical constructs map to
one ontolo
g
ical construct
Construct
excess
A grammatical construct might not
ma
p
to an
y
ontolo
g
ical construct
Construct
deficit
An ontological construct might not
map to any grammatical construct
Cases of construct overload
Construct overload (i.e., more ISA-95 concepts
map onto one ArchiMate 3.0 concept) occurs in the
case of the following ArchiMate concepts:
Business Object is used to represent information
objects that are used on the shop floor and may serve
as a placeholder for more complex entities like a
schedule or a bill of materials. Specifically, Table 3
describes the objects that map to Business Object.
Where a business object is used, the model will
depend on relationships to other entities to provide
the expressiveness needed to model the meaning that
the user intends. If this level of expressiveness cannot
be achieved, this causes a construct deficit.
Business Role - Personnel Class and Equipment
map to Business Role. This happens specifically in
the case where Equipment refers to an automated
production unit. This abstraction loses the direct
distinction between a manual and an automated role.
However, depending on whether a given role depends
on an actor or not, this distinction can still be derived.
Material - Material Class, Material Definition,
Material Lot and Material Sublot map to Material in
ArchiMate. Because of this, the distinction between a
class of material and a specific type of material used
as part of a process is lost. Furthermore, the difference
between a class of material and an identifiable (group
of) its instances is also lost.
Table 3: Construct overload to Business Object.
Qualification Test
Specification
Operations Material Bill
Equipment Capability Test
Specification
Personnel Specification
Physical Asset Capability
Test Specification
Equipment
Specification
Material Test Specification Physical Asset
Specification
Material Assembly Material Specification
Material Definition
Assembly
Material Specification
Assembly
Material Class Assembly Operations Schedule
Personnel Segment
Specification
Segment Requirement
Equipment Segment
Specification
Personnel Requirement
Material Segment
Specification
Equipment Requirement
Material Segment
Specification Assembly
Physical Asset
Requirement
Physical Asset Specification Material Requirement
Cases of construct deficit
Several deficits have been identified as part of the
mapping analysis. When a deficit occurs, the ISA-95
concept cannot be expressed in ArchiMate. Each
deficit is explained in the paragraphs below.
Test Specifications - Various concepts in ISA-95
are related to a test specification that is used to test
certain properties of said concepts. A Test
Specification maps to a Business Object. The
ArchiMate meta-model only allows for an association
relationship between Active Structure concepts and a
Business Object. The dependency in ISA-95 is,
however, stronger (<is tested by>).
Assemblies - An assembly is a collection or set of
related elements. In ISA-95, they are represented as
classes related to aggregation relationships between
elements. In ArchiMate, every element can also have
an aggregation relationship with an element of the
same type. There is, however, no class that represents
information about this relationship.
Process Segment Parameters - A process
segment (maps to business process) in ISA-95 is a
collection of several concepts, including specific
parameters that do not fall into the category of
personnel, equipment, physical asset or material. The
Seventh International Symposium on Business Modeling and Software Design
64

‘other’ parameters are known as process segment
parameters. ArchiMate allows only well-defined
concepts to be related to a business process.
Material Lots - While an ISA-95 Material can be
directly mapped to an ArchiMate material, a problem
occurs when attempting to map a Material Lot. A
requirement for a Material Lot is that it should be
possible to determine its current state based on the lot
ID. This requires traceability to an information object,
i.e., a Business Object. While it is possible to relate
a Material Lot to a Business Object through an
association, the relationship between a physical and
an information object is deemed more meaningful.
Operations Definitions - The operations
definition describes the relation between a
production, maintenance, inventory or quality
operation, the way in which it is implemented and the
resources that are needed. A framework for these
kinds of manufacturing operations is defined by the
first part of ISA-95 (International Society of
Automation, 2010a). ArchiMate only loosely defines
business processes, independent of their context.
Operations Schedule - ISA-95 defines a schedule
concept. It is implemented as a set of operations
requests, which directly relate to an operations
definition. There is no similar concept in ArchiMate.
Operations Performance - ISA-95 makes a
distinction between the definition of a process, the
planned process and the actual process. Once
executed, Operations Responses are returned for
every Operations Request (which make up the
schedule). In ArchiMate, an Operations Response can
be represented as either a Business Object or Data
Object, depending on whether this information is
collected digitally or not. The actual production
information is, however, much too volatile to model
as part of the architecture.
3.4 Addressing the Deficiencies Found
Now that several deficiencies have been identified,
solutions can be defined that allow ArchiMate to
express all the architectural concepts in ISA-95, thus
making the language suited to model the shop floor
and, by extension, the EA of a smart manufacturer.
The solutions to the deficiencies identified will be
discussed below as modelling patterns. A pattern is a
set of constructs from ArchiMate that expresses a
certain aspect of ISA-95. Preferably, only existing
constructs will be included in these patterns. If a new
construct must be introduced, it will conform to the
requirements for constructs in ArchiMate (The Open
Group, 2016). The following paragraphs discuss the
solutions per deficiency.
Test Specifications
Various concepts in ISA-95 are related to a test
specification that is used to test certain properties of
said concepts. Often, these concepts are mapped to
active structure concepts in ArchiMate. For example,
a Person (maps to Actor) relates to a Qualification
Test Specification (maps to Business Object). A
Business Object is, however, a passive structure
concept. The ArchiMate meta-model only allows for
an association relationship between Active Structure
concepts and a Business Object. As discussed in
section 3.3, we must rely on the context of the
ArchiMate model to define the meaning of a Business
Object. For a Test Specification, which has a very
specific purpose in ISA-95, we deem an association
relationship insufficient, since this association
without context can be interpreted in many ways.
A stronger relationship (van Buren et al., 2004)
between an Active Structure concept and a Business
Object can only be established via a Behaviour
concept, specifically the assigned to relationships (for
Active Structure concepts) and access relationships
(for Business Objects) to Business Service, Business
Event and Business Process.
Since relationships from the physical layer are
only allowed to Business Process, Business Function
and Business Interaction (and not Business Service or
Business Event), this leaves Business Process as the
only option. Given this limitation, we define the Test
Specification Pattern as shown in Figure 1.
Figure 1: Test Specification Pattern for ArchiMate 3.0
.
Assemblies
An assembly is a collection or set of related
elements. In ISA-95, they are represented as classes
related to aggregation relationships between
elements. In ArchiMate, every element can also have
an aggregation relationship with an element of the
same type. There is no class that represents
information about this relationship. For example, to
express the size of an assembly in ArchiMate, it
would be necessary to model an entity for each
element in the collection. This makes sense in a
scenario where each instance of a class is
meaningfully different. For example, since every
person has different qualifications, it is meaningful to
model people separately as part of a team. However,
in the case where the elements of a collection are not
meaningfully different, e.g. a set of materials used for
the production of a batch (bill of materials), it makes
more sense to model each material as a class rather
than as separate instances. When modelling only a
class, however, the quantity of the material used for
the production of e.g. a batch is still meaningful
information. Both alternatives below present a
Towards an Integrated Architecture Model of Smart Manufacturing Enterprises
65

solution that makes use of a parameter to a
relationship to express meaning. Such a pattern can
also be used to express the Operations Material Bill
Item concept per ISA-95.
Figure 2: Implicit Bill of Materials pattern for ArchiMate.
Alternative 1
To model such information relevant to an
assembly, parameters for the relationship between the
class (e.g. a material) and the assembly (e.g., a bill of
materials) is proposed. While ISA-95 defines
assemblies broadly, in the specification they only
occur in relation to materials. A placeholder mapping
for assembly would be a business object. Currently,
there exists an indirect relationship between Business
Object and Material through Business Process. The
information relevant to an assembly could be attached
to the relationship between Material and Business
Process as a (set of) parameter(s).
Alternative 2
Figure 3: Explicit Bill of Materials pattern for ArchiMate.
This implementation eliminates the need for a
separate Business Object by modelling the bill of
materials implicitly through the set of relationships
between said Business Process and the Materials
used. Figure 2 illustrates the proposed pattern.
However, the solution presented in alternative 1
does not allow for a bill of materials to be modelled
explicitly. A bill of materials is quite common in
manufacturing, so the capability to include this
concept explicitly may be desirable. To do so, a direct
relationship between Business Object and Material is
necessary. An association relationship is currently
available between Material and Business Object.
However, as explained in section 3.3, we feel that the
use of an association relationship in this case is not
sufficiently expressive.
Instead, an aggregation relationship is proposed.
An aggregation relationship indicates that a concept
(the bill of materials) groups a number of other
concepts (materials). While Materials are meaningful
independent of one another, the bill of materials
groups them for the purposes of use in a production
process.
The proposed parameters would be attached to
this relationship. This solution is, however, not
perfect either. The relationship between Business
Object and Material makes the relationship between
Business Process and Material redundant, since the
Bill of Materials will always be related to a
production process (Business Process).
Figure 3 shows a pattern for the modelling of an
explicit bill of materials. There are two major
differences between this pattern and the pattern for an
implicit bill of materials. Firstly, this pattern includes
a Business Object that denotes the bill of materials.
This Business Object is related to the Business
Process via an access relationship. This relationship
currently exists in ArchiMate. The bill of materials
lists one or more Materials via an aggregation
relationship. This aggregation relationship is newly
introduced for this purpose. Secondly, the
information describing the assembly is related to the
aggregation relationship between Material and
Business Object, as denoted by the dotted line.
Process Segment Parameter
A process segment (maps to business process) in
ISA-95 is a collection of several concepts, including
specific parameters that do not fall into the category
of personnel, equipment, physical asset or material.
The ‘other’ parameters are known as process segment
parameters. For a production process, an example
might include the known lead time of a process step
(e.g. the steel coil needs to be in the oven for 10
minutes). For a quality process, a parameter might be
the size of the sample to be pulled (e.g., 1 coil).
ArchiMate allows only well-defined concepts to
be related to a business process. The only concepts
that fit with the description of Process Segment
Parameter (i.e. related to business process and not a
person, equipment or material) are Business Service
and Business Event (behaviour), or Business Object
(passive structure). A timer like in the oven example
would typically be modelled as an event, but a
parameter like sample size cannot be expressed
formally in ArchiMate. If needed, such information
can be included as part of the sub-process name (e.g.
take a quality sample, size 1). Modelling this
information as such works as a way to capture it
Seventh International Symposium on Business Modeling and Software Design
66

informally, e.g. for presentation purposes. However,
for analysis purposes, a more formal approach will be
required, since information stored in a concept name
cannot be queried easily.
Figure 4: Process Parameter pattern for ArchiMate 3.0.
The proposed solution is to introduce parameters
related to a business process. This is similar to the
solution introduced to model assemblies, with the
difference being that the parameters are related to a
concept rather than a relationship. Examples of
parameters are average duration, sample size or
temperature. This parameter pattern can also be used
to model other manufacturing object parameters, per
the ISA-95 object properties. The parameter pattern
for concepts is illustrated in Figure 4.
Material Lot
While an ISA-95 Material can be directly mapped
to an ArchiMate Material, a problem occurs when
attempting to map a Material Lot. The current state of
a Material Lot should be accessible via its ID. This
requires traceability to an information object, i.e. a
Business Object. It is possible to associate a Material
with a Business Process and a Business Object with a
Business Process. It is even possible to draw an
association between Material and Business Object. In
the case of a Material Lot, however, the relationship
between Physical Object and Information Object is
more meaningful than an association. The
relationship should describe how the informational
object reflects the state of the physical object it
represents.
To add this expressiveness, a realization
relationship is proposed. A realization relationship
links a logical entity with a more concrete entity that
realizes it. Thus, a realization relationship could
describe how a physical object is represented by an
information object. Furthermore, a Data Object may
realize a Business Object. This Data Object can, by
means of an indirect relationship, be considered as the
digital representation of said Material stored in some
information system. This extrapolation would not be
valid if a weaker relationship should be used between
the physical object and the Business Object. Finally,
by linking the data model of said Data Object to the
architecture, it becomes possible to perform analyses
of a material’s production lifecycle.
The same logic also applies to other physical
elements. For example, a piece of equipment may be
used as part of a business process, causing it to change
state (e.g. from ‘idle’ to ‘in use’). Per ISA-95, entities
associated with processes include materials, as well
as physical assets, equipment and people. Because of
this relationship in ISA-95, the same realization
relationship that is proposed for ArchiMate between
Material and Business Object is also proposed as a
relationship between Business Object and Business
Role, Business Actor, Equipment and Facility (see
Table 4).
Table 4: Proposed relationships.
ArchiMate
Concept
ISA-95
Concept
Relation-
ship
Concept
Material Material Lot Realizes Business
Object
Business
Role
Personnel
Class
Realizes Business
Object
Business
Actor
Person Realizes Business
Object
Equipment Equipment
Class
Realizes Business
Object
Facility Physical
Asset
Realizes Business
Object
Finally, the Business Process concept is included
to show that the newly added realization relationship
is only intended for those concepts that have an access
or assigned to relationship with Business Process.
Figure 5: Informational Representation of a Material.
Figure 5 illustrates the proposed extension. The
newly added realization relationship is marked with a
red circle. For the sake of legibility, the ‘Physical
Elements’ block serves as a placeholder for the
ArchiMate concepts listed in Table 4. The figure also
shows how an indirect realization relationship
between Data Object and a Physical element can be
derived using the realization relationship between
Data Object and Business Object.
Operations Definition
The operations definition describes the relation
between a production, maintenance, inventory or
quality operation, the way in which it is implemented
Towards an Integrated Architecture Model of Smart Manufacturing Enterprises
67

and the resources that are needed to carry out the
process. A framework for these kinds of
manufacturing operations is defined by the first part
of ISA-95. ArchiMate only loosely defines business
processes, independent of their context. However, the
ISA-95 process framework (International Society of
Automation, 2010a) can be implemented in
ArchiMate. It can then provide structure through
composition relationships from framework processes
to processes that are company-specific.
Figure 6 shows a pattern for how to apply the
ISA-95 process framework to company-specific
business processes. Such processes are modelled as
sub-processes (hence the composition relationship) of
processes from the ISA-95 process framework. Since
both ISA-95 processes and their sub-processes have
flow relationships between them, sub-processes
cannot compose more than one ISA-95 process. If a
process in a currently existing model cannot fulfil this
requirement (e.g. Batch Annealing in Figure 6), that
process needs to be decomposed such that each sub-
process only has one relation to an ISA-95 process.
Figure 6: Operations Definition Pattern (incl. example).
ISA-95 also explicitly defines a Bill of Materials
in relation to an Operations Definition. A business
object best fits the definition, but a business object
cannot have a relationship to a material (except
through a business process). ArchiMate does
implicitly define a bill of materials through the access
relationship between business process and material.
The pattern introduced for Assemblies solves this
issue.
Operations Schedule
ISA-95 defines a schedule concept. It is
implemented as a set of operations requests, which
directly relate to an operations definition. There is no
particular ordering (time sequence) to the set. There
is no similar concept in ArchiMate. While the
schedule itself could be modelled as a business object,
another issue arises with regards to the relationship
between a business object and a business process. A
business process is typically modelled as a class in
ArchiMate, while the schedule must relate to
instances to be meaningful. It would either be
necessary to model each instance of the process
separately, or to model no relationships to business
processes at all, effectively making the schedule a
placeholder object. The first is preferable from an
analysis standpoint, while the second is preferable
from a complexity standpoint. A compromise
between these two options is to, rather than model
each instance as part of the architecture, include a
reference to the data model used to store each instance
(Figure 7). This data model can then serve as the basis
for a query. The way in which this query is structured
shall depend on the viewpoint for which the
information is required. For example, a query based
on product ID may reveal which execution path was
followed for the production of that unit.
Figure 7: Operations Schedule Pattern.
Operations Performance
ISA-95 makes a distinction between the definition
of a process (operations definition), the planned
process (operations schedule) and the actual process
(operations performance). Once executed, Operations
Responses are returned for every Operations Request
(which make up the schedule). An Operations
Response is made up of ‘actuals’, which represent the
people, equipment, materials and physical assets that
were utilized. In ArchiMate, an Operations
Responses can be represented as either a Business
Object or Data Object, depending on whether this
information is collected digitally or not. The actual
production information, such as the actual execution
of the process, any errors that may have occurred, is
however much too volatile to model as part of the
architecture. Instead, it is recommended to relate an
Operations Response object to a specification of the
data model, describing how the data can be obtained
externally (e.g. an E/R-diagram). Based on this
specification and the relationship to a data object
accessed by some application, it will be possible to
generate a query for analysis purposes. The proposed
pattern is shown in Figure 8.
4 VALIDATION
A case study has been done to validate whether
Seventh International Symposium on Business Modeling and Software Design
68

ArchiMate (plus ISA-95 based modelling patterns)
effectively introduces EA modelling capability to
manufacturers. The case concerned a large steel
manufacturer (named SteelCorp for the sake of
anonymity) that intends to make a change in one of
its production processes. Due to space limitations we
do not provide here modelling details of this case
study. Instead we discuss the results and main
conclusions of the case.
Figure 8: Performance Actual Pattern.
The process modelled as part of this case study
concerns a batch annealing process for steel coils at
one of SteelCorps factories. During batch annealing,
a group of three coils is placed into an oven. Heat is
applied over a period of time to change certain
qualities of the steel. SteelCorp is looking to optimize
this process and to harmonize its surrounding
application landscape.
Proposed optimizations include the integration of
information used in several activities preparatory to
production into the production planning system
(PPS). The PPS is used to manage the utilization of
the ovens. Secondly, to increase oven utilization,
SteelCorp plans to generate optimized batches of
coils from the PPS, rather than having employees
combine each batch manually. Thirdly, to minimize
waiting times once a batch leaves the oven, SteelCorp
wants to know how long it takes for a coil to cool
down in inventory. For this reason, they will install
thermometers that monitor each coil periodically.
Finally, actual oven temperature curves will be
recorded and stored in the data warehouse with the
intent of using this data to optimize energy efficiency.
Creating a model of this process involved
establishing the batch annealing process formally as
part of the business domain, as well as modelling its
relationship to the physical, digital and IT
infrastructure domains. Notable physical objects
include the steel coils and the ovens. Information is
associated with these objects at several stages in the
process and this information moves through several
systems throughout the production lifecycle.
An as-is process model was made. This model
could successfully be used to demonstrate the
challenges SteelCorp was facing and to motivate the
proposed changes. Finally, a to-be process model was
presented to show how the proposed changes would
contribute to the goals set forth by SteelCorp.
The proposed modelling patterns proved useful in
several instances. Patterns based on existing
ArchiMate concepts were enough to model most of
the case. However, some aspects of the case could not
be modelled and required the use of modelling
patterns that make use of new elements. For example,
the current utilization of an oven (and the discrepancy
between the perceived utilization of an oven and its
actual utilization) could not be modelled. This
required a realization relationship to a business object
per the pattern introduced in section 5.4.4. Another
example of this is the temperature data related to a
steel coil that is monitored at regular intervals during
the process. Finally, usefulness of the model was
successfully demonstrated through its application to
two common manufacturing use-cases: an impact of
change analysis, as well as an operational excellence
analysis. Both analyses proved to be possible.
5 RELATED WORK
Urbaczewski & Mrdalj (2006) reviewed the EA
frameworks available at that time. They identified
DoDAF as the only framework that allows for the
modelling of physical elements. In another literature
review Hermann et al (2015) identify CPS as major
principle behind smart manufacturing/industry 4.0.
Furthermore, in, Sacala & Moisescu (2014) argue that
modelling a CPS as part of an overall enterprise
systems landscape requires a physical entity, an
association with a business entity and an application
with interfaces to both the business and the physical
entity. Finally, The Open Group released in 2016
ArchiMate 3.0 (The Open Group, 2016), which
introduced (among other things) several modelling
concepts to describe physical elements and how these
elements relate to applications and business entities.
The current research draws upon all the above and
relates ArchiMate to ISA-95, by exploring its current
modelling capabilities for smart manufacturing.
6 CONCLUSIONS
With the introduction of smart manufacturing (or
Industry 4.0), IT and operations technology
increasingly intertwine. For large manufacturers, this
means increasing digitization of the shop floor and,
consequently, the need to control the information
flowing from the physical domain and to manage
changes from a multidisciplinary (IT and OT)
perspective. This is where EA helps, but existing EA
Towards an Integrated Architecture Model of Smart Manufacturing Enterprises
69

frameworks and languages were not designed with
this type of requirements in mind.
This research provides EA modelling support for
smart manufacturing companies. Based on the ISA-
95 standard for the integration of enterprise systems
and control systems in the manufacturing industry
(International Society of Automation, 2010a,
International Society of Automation, 2010b), this
research has presented an analysis of ArchiMate 3.0
(The Open Group, 2016) in terms of its coverage of
the manufacturing domain. The results of the analysis
lead to the following answers to the research
questions formulated in in the introduction:
RQ1: Since ISA-95 was written on a different
abstraction level than ArchiMate, not all of its
concepts may be of architectural nature. To determine
which concepts are architectural, the ISA-95 concepts
were normalized using the criteria used to determine
which concepts should be part of the ArchiMate
language (Lankhorst et al., 2010). The normalization
revealed that only 66% of ISA-95 concepts qualify as
such. Given the set of architectural concepts
identified, a mapping was made of each architectural
ISA-95 concept to ArchiMate 3.0. To be able to
express the EA of any smart manufacturer,
ArchiMate should be able to express each
architectural ISA-95 concept. The mapping analysis
revealed that, while 12% of concepts can be mapped
one-to-one, construct overload or deficit (Wand and
Weber, 2002) occurs in 75% of cases. Solving these
issues requires the use of modelling patterns based on
either indirect relationships or on new constructs.
RQ2: When a concept from the manufacturing
domain cannot be mapped to ArchiMate, this will
invariably cause issues when attempting to model the
architecture of a manufacturing enterprise. Thus, this
second question asks for a solution to the mapping
difficulties uncovered as part of the mapping analysis.
For each identified issue, a pattern has been
proposed that resolves the problem by using some
combination of ArchiMate concepts to express the
intended meaning of the ISA-95 concept, and/or by
introducing some new constructs if ArchiMate’s
meta-model does not have sufficient expressive
power. The following concepts are introduced:
• Concept Parameter and Relationship Parameter.
These concepts describe information about a
concept (e.g. a steel coil) or relationship (e.g., an
item on a bill of materials) respectively.
• An aggregation relationship between Material
and Business Object is proposed to enable the
modelling of an explicit bill of materials.
• A realization relationship between Business
Object and Business Actor, Business Role,
Material, Equipment and Facility will allow for
both the current physical and informational state
of a physical object to be modeled.
The proposed modelling patterns enhance
ArchiMate 3.0’s coverage of ISA-95 architectural
concepts from 12% to 92%, and were validated as
part of a case study. They proved useful in modelling
part of the production process at a steel manufacturer.
The models could also effectively be used to perform
two common analysis use-cases: impact analysis and
operational excellence analysis.
Note that the proposed modelling patterns are
applicable to ArchiMate only. Furthermore, the
patterns should be further validated by testing them in
more cases, also covering discrete and continuous
processes, since SteelCorp is a batch process.
REFERENCES
Boucharas, V., van Steenbergen, M., Jansen, S.,
Brinkkemper, S., 2010. The Contribution of Enterprise
Arhcitecture to the Achievement of Organizational
Goals: A Review of the Evidence. TEAR 2010, 1-15.
Van Buuren, R., Jonkers H., Iacob, M-E. & Strating, P.,
2004. Composition of relations in enterprise
architecture models. Lecture Notes in Computer
Science 3256, Springer, 39–53.
Davis, J., Edgar, T., Graybill, R., Korambath, P., Schott, B.,
Swink, D., Wang, J., Wetzel, J., 2015. Smart
Manufacturing. Annual Review of Chemical and
Biomolecular Engineering, 6, 141–160.
Henderson, J.C., Venkatraman, H., 1993. Strategic
alignment: Leveraging information technology for
transforming organizations. IBM Systems Journal, 31,
1, 472-484.
Hermann, M., Pentek, T., & Otto, B., 2015. Design
Principles for Industrie 4.0 Scenarios: A Literature
Review. Technische Univ. Dortmund, 01(01), 4–16.
International Society of Automation, 2010a. Enterprise-
Control System Integration. ANSI/ISA standard
95.00.01-2010.
International Society of Automation, 2010b. Enterprise-
Control System Integration. ANSI/ISA standard
95.00.02-2010.
Lankhorst, M. M., Proper, H. A., Jonkers, H., 2010. The
Anatomy of the ArchiMate Language. Int. J. of Inf. Syst.
Modelling and Design archive, 1(1), 1-32.
Lee, E.A., 2008. Cyber Physical Systems: Design
Challenges. In proc. Of 2008 11
th
IEEE International
Symposium on Object and Component-Oriented Real-
Time Distributed Computing (ISORC), 363-369.
Sacala, I.S., Moisescu, M.A., 2014. The Development of
Enterprise Systems based on Cyber-Physical Syst.
Principles. Romanian Statistical Review, 4, 29–39.
The Open Group, 2016. ArchiMate 3.0 Specification.
Urbaczewski, L., Mrdalj, S., 2006. A comparison of
enterprise architecture frameworks. Issues in
Information Systems, 7(2), 18–23.
Seventh International Symposium on Business Modeling and Software Design
70

Wagner, H.-T, Weitzel, T., 2006. Operational IT Business
Alignment as the Missing Link from IT Strategy to
Firm Success. 12
th
Americas Conference on
Information Systems (AMCIS 2006). AISeL, 570-578.
Wand, Y. & Weber, R., 2002. Research commentary:
Information systems and conceptual modelling - A
research agenda. Information Systems Research, 13(4),
363–376.
Towards an Integrated Architecture Model of Smart Manufacturing Enterprises
71