Constraint Formalization for Automated Assessment of Enterprise
Stef Joosten
1 a
, Ella Roubtsova
1 b
and El Makki Haddouchi
Open University of the Netherlands, Department of Information Science, Heerlen, The Netherlands
University Medical Center Utrecht, The Netherlands
Enterprise Architecture Model, ArchiMate, Modelling Conventions, Modelling Constraints, Ampersand-tool.
Enterprises always do their business within some restrictions. In a team of enterprise architects, the restric-
tions are transformed into the modelling conventions and the corresponding modelling constraints that should
be consistently applied across all enterprise models. This paper presents an approach for refining and formali-
zing modeling conventions into modelling constraints and using them for assessment of enterprise models
by a software component called ArchiChecker. The specifics of the proposed approach is that the modeling
conventions are first visualized and formalized using the types of elements and relationships of the Archi-
Mate modeling language, that is also used for modelling of enterprise views. The ArchiMate elements and
relationships serve as types to formulate constraints. The elements and relationships in an ArchiMate model
are instances of the ArchiMate elements and relationships. Using these types and instances the ArchiChecker
automatically generates the lists of violations of modeling conventions in the enterprise models. Each viola-
tion shows how a specific enterprise view deviates from a given modeling convention. The paper reports a
case study of application of the proposed approach to enterprise modelling views and modelling conventions
used in a medical center. The case study is used to discuss the added value of formalization and automated
assessment of modelling constraints in enterprise modelling.
The Open Group enterprise modeling standard lan-
guage ArchiMate (The Open Group, 2019) is avail-
able to enterprise architects for visualizing and sha-
ring ideas. Enterprise architects create ArchiMate
models, which consist of views. Each view in Archi-
Mate corresponds to a diagram, that has its elements
and relations and used by an enterprise architect to
visualize an enterprise layer, a subsystem or a pat-
tern (Lankhorst et al., 2010).
ArchiMate gives its user maximal freedom in
modeling. However, the business of an enterprise of-
ten defines own restrictions. In a team of enterprise
architects, these restrictions are transformed into the
corresponding modelling conventions. Collaboration
of enterprise architects often requires shared model-
ing conventions. For a team of enterprise architects,
who use ArchiMate, this also initiates the work to-
wards consistency in application of modelling con-
ventions across all the views of their enterprise model.
The visualization freedom makes it hard for en-
terprise architects to adopt shared modeling conven-
tions. When enterprise architects propose, discuss,
and agree upon modelling conventions, ArchiMate
provides little assistance in expression of modelling
conventions and in assessment of enterprise models
on consistency with modelling conventions. One of
the ArchiMate motivation elements is called “con-
straint”, however, this element is a free format field
that “represents a factor that limits the realization of
goals”(The Open Group, 2019) and cannot be used
for modeling conventions that have to be consistently
applied in enterprise models and, sometimes, even en-
We propose to add a rule engine to ArchiMate to
verify modelling conventions. For the sake of assess-
ment of enterprise models on consistency with mod-
elling conventions, we propose to formalize them as
modelling constraints using the element types and re-
lationship types of the enterprise models. This allows
us to assess an ArchiMate model with respect to a
modelling constraint. Each assessment of an Archi-
Mate model yields a list of violations of the chosen
Joosten, S., Roubtsova, E. and Haddouchi, E.
Constraint Formalization for Automated Assessment of Enterprise Models.
DOI: 10.5220/0011049200003179
In Proceedings of the 24th International Conference on Enterprise Information Systems (ICEIS 2022) - Volume 2, pages 430-441
ISBN: 978-989-758-569-2; ISSN: 2184-4992
2022 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
modelling constraint in terms of instances of elements
and relationships of the ArchiMate model.
To illustrate the need and the possibility of for-
malization and application of modelling constraints
for assessment of enterprise models in ArchiMate we
have conducted several related studies.
Section 2 presents the results of a literature study
answering the question how the constraints from
different areas are expressed in ArchiMate.
Section 3 discusses the existing attempts of au-
tomated assessment of an ArchiMate model with
respect to modelling constraints.
Section 4 presents our tool ArchiChecker de-
signed to analyze an ArchiMate enterprise model
and to identify violations of a given modelling
Section 5 proposes a practical approach to for-
malise a modelling convention for assessment of
an enterprise model with the ArchiChecker.
Section 6 reports and discusses a case study ap-
plying the proposed approach to enterprise mod-
elling views and modelling conventions used in a
medical center.
Section 7 lists the pros and cons of the proposed
approach and the stages of the Design Science Re-
search that have been completed.
Section 8 concludes the paper and draws on future
To understand how we impose constraints on Archi-
Mate models, let us briefly summarize the ArchiMate
language. In each single view, ArchiMate shows a
set of elements (boxes) and relations (lines) between
those elements. An element has a shape that has been
picked by the modeler from a limited set of shapes
to reflect the type of the element. A line that con-
nects two elements refers to a relationship between
the two corresponding ArchiMate elements and also
picked from a limited set of lines. Every view is per-
ceived as a graphical diagram that shows specific de-
tails of an entire architecture. Each enterprise model
has an internal ArchiMate model being a collection of
elements, a collection of relationships, and a collec-
tion of views in which elements and relationships are
shown. An attractive characteristic of ArchiMate is
that different views can share the same elements and
relationships. One element can even have a different
shape in different views, but still be the same element.
The notion of ”the same” is not defined in the Archi-
Mate reference document (The Open Group, 2019),
but ArchiMate tools typically use an internal key to
identify elements. Every element is categorized as a
strategic, business, application, technological, moti-
vational, or implementation element. All views are
scoped in the namespace of the internal ArchiMate
An enterprise always exists in environment and
works within restrictions that mean modelling con-
ventions or constraints on the model of the enterprise.
Analysing research literature, we have found nume-
rous attempts to specify constraints in ArchiMate. Of-
ten, these attempts concern access, security, and pri-
Mayer et al.(2019) propose to extend the Archi-
Mate metamodel with security policies (Mayer et al.,
Zhi et al.(2018) have modeled assurance secu-
rity cases graphically within an enterprise model (Zhi
et al., 2018). They have extended the enterprise model
with security policies, but these policies are not used
to verify this enterprise model.
e et al.(2019) have modeled privacy
policies in ArchiMate. The authors have a global look
on privacy policies. Their work “addresses the mod-
eling of a given regulation (GDPR) as an EAM frag-
ment that needs to be integrated into a more global
e et al., 2019, page 14). They
have identified business services related to the GDPR
and modeled them in ArchiMate. The authors do not
see their ArchiMate models as a means for verifica-
tion of enterprise models of organizations.
A common denominator in these (and many other)
case studies is that constraints are modelled with-
out automated verification. This is not surprising,
as ArchiMate tools offer little functionality for auto-
mated verification.
The “Constraint” element in ArchiMate allows the
user to describe a constraint as text, but ArchiMate
has no means to compute violations of that constraint.
ArchiMate does not distinguish between a con-
straint and a policy. In this research we do. A policy
is a normative agreement (typically written in natural
language) of the business. A constraint is a formal ex-
pression of which violations can be computed. To ap-
ply a policy in an enterprise architecture a policy must
be made into a modelling convention and than into a
constraint. Not all policies are amenable to that.
Modeling conventions that may start as policies
must therefore be reformulated as constraints. We use
a constraint to verify that modeling conventions are
adhered to in ArchiMate models. The word “con-
straint” stands for a formula or an algorithm that
Constraint Formalization for Automated Assessment of Enterprise Models
yields true or false. But it also caters for a condition
in natural language, so long as it is mathematically
precise. Examples of constraints can be found in the
The remainder of this paper represents policies
and modeling conventions as text (hence informal)
and constraints as formulas. To formulate a constraint
requires the knowledge of the ArchMate palette and
the skill to formalize logical expressions. That is a
skill for enterprise architects.
Automated constraint verification has a long history,
especially in the context of systems specification
and enterprise architecture (Chapurlat and Braesch,
2008). Many tools for verification are available as
query systems and analyzers. In this work we are in-
terested specifically in verification of enterprise archi-
tecture models.
Babkin and Ponomarev (2017) take an ap-
proach based on relation algebra which is similar
to ours (Babkin and Ponomarev, 2017). They have
made a metamodel of the ArchiMate language in
Alloy (Jackson, Daniel, 2006) and used it to ana-
lyse the ArchiSurance (Jonkers et al., 2016) model,
which is the leading example of ArchiMate and has
been published alongside with the ArchiMate refe-
rence document. The MIT Alloy Analyzer searches
for contradictions in the enterprise architecture mod-
els. They have shown with examples that their ap-
proach to analysing ArchiMate models works. We
take this result one step further by exploring a practi-
cal perspective: What do enterprise architects need to
benefit from analysing their ArchiMate models?
Arriola and Markham (2018) propose to use Z-
notation to formulate design decisions and control
them on the enterprise architecture level. This is
related in that Z is a formal specification language
(akin to relation algebra) which is used for architec-
ture specification. But automated verification is not
the intention of (Arriola and Markham, 2018).
Marosin et al.(2014) report an experience in the
ontological specification of enterprise architecture
and queries for verification of architectural specifica-
tions (Marosin et al., 2014).
The semantic web inspires researchers to repre-
sent constraints as OWL2 RL Axioms. Kharlamov
et al.(2016) conclude that “the main challenge that
we encountered was to capture the constraints of the
models using ontological axioms” (Kharlamov et al.,
2016, page 7).
The tool Archi (Beauvoir and Sarrodie, 2018) has
recently been enriched with a JavaScript-based script-
ing plug-in called jArchi (Beauvoir and Sarrodie,
2019). It is built on the Oracle Nashorn engine. With
jArchi, an enterprise architect can write JavaScript to
encode his own ArchiMate checker.
From all these sources we conclude that there is a
research problem of constraint elicitation and assess-
ment on an enterprise model. In order to solve this
problem, a process should be designed and followed.
With this focus, our work can be classified as a Design
Science Research (Peffers et al., 2007). The designed
process includes formulating constraints, agreeing on
their meaning and formalizing them in such a way that
a constraint checker may produce the constraint viola-
tions. The produced violations have to be understood
and evaluated (Cleven, Anne and Gubler, Philipp and
uner, Kai M, 2009).
This work proposes a process of constraint elici-
tation and assessment of ArchiMate models. Having
this focus, our work builds on the earlier work with
the Ampersand tool (Joosten, 2018). Ampersand uses
relational algebra (the same as Alloy) as a language
to represent constraints, which allows verification of
enterprise architecture against constraints. Unlike the
approach in Alloy (Babkin and Ponomarev, 2017), we
did not make an ArchiMate metamodel. Instead, the
ArchiChecker derives the metamodel from the Archi-
Mate model. This ensures that there can be no dis-
crepancy between the metamodel and the ArchiMate
data. This has saved us not only the time to make a
metamodel, but it also prevented programming mis-
takes when matching the data from an ArchiMate
model to the metamodel.
Ampersand is also used for constraint checking
but it also has an established way of rule elicita-
tion (Wedemeijer, 2014). The Ampersand compiler
has been extended with a parser that reads ArchiMate
repositories (Filet et al., 2019). Building on these ear-
lier results, we have used Ampersand to complement
ArchiMate with respect to automated verification.
4 ArchiChecker- HOW IT WORKS
To understand how the constraint checker
(ArchiChecker) works, let us observe the tools
(Figure 1).
Two tools serve the enterprise architect: an Archi-
Mate modeling tool and the ArchiChecker. For mo-
delling we use the open source tool Archi, which
stores an ArchiMate model in the form of an XML-
file with extension “.archimate”. In Figure 1 this file
is called “repo.archimate”.
ICEIS 2022 - 24th International Conference on Enterprise Information Systems
Figure 1: A toolset for an enterprise architect.
Figure 2: Under the hood of the ArchiChecker.
The component ArchiChecker” (Figure 2) func-
tions as a compiler that compiles the ArchiMate
model (“repo.archimate”) together with the con-
straints (constraints.adl) into a set of violations
(“violations.log”). It parses the ArchiMate model
(repo.archimate) according to the ArchiMate Meta-
model. It parses constraints (constraints.adl) ac-
cording to the same metamodel because a constraint
checker must “know” where to find the data to be
checked. It compiles each constraint into a checking
function that can compute violations with respect to
that constraint. ArchiChecker emits all violations to
the log.
To gain some understanding of the internal func-
tioning, let us look at a small fragment (in Amper-
sand (Joosten, 2018)) :
A Fragment of the ArchiMate Metamodel:
RELATION triggering [BusinessEvent*BusinessProcess]
RELATION triggering [BusinessActor*ApplicationFunction]
RELATION realization [BusinessFunction*BusinessService]
RELATION serving [BusinessFunction*ApplicationFunction]
RELATION type [Relationship*Text] [UNI,TOT]
RELATION name [ApplicationFunction*Text] [UNI]
The metamodel consists of relations. In this paper,
the word “relation” refers to the mathematical notion
of relation and to a relation in Ampersand, which are
the same. The word “relationship” refers to the corre-
sponding notion in ArchiMate Table 1, each of which
contains pairs.
Table 1: ArchiMate notions vs. Ampersand notions.
ArchiMate notion Ampersand notion
relationship relation
element type concept
element atom
constraint rule
modeling convention -
model context
view -
For example, the relation realization represents
a set of pairs, each of which relates one particular
Business Function to one Business Service. An af-
Constraint Formalization for Automated Assessment of Enterprise Models
Figure 3: Enterprise model “CS Pharmacy”.
fix (e.g. [UNI]) is used to denote a set of multiplicity
properties, of which there are four: UNI (which means
univalent), TOT (total), INJ (injective), and SUR (sur-
jective). They can be used in any combination.
Data. The data in an ArchiMate model are inter-
preted in terms of pairs in Ampersand and each pair is
contained in the appropriate Ampersand relation. The
following fragment illustrates how data from Archi-
Mate is allocated to relations.
Data from ArchiMate is allocated to relations:
POPULATION realization [BusinessFunction*BusinessService]
Each relation contains all pairs from all views, so
the scope of this relation is the entire model. The long
numbers that constitute pairs are the internal Archi
keys for ArchiMate elements.
Although the metamodel is internal, the
ArchiChecker exports it in a readable way for
the sake of documentation (export not shown in
Figure 2).
Constraints. An example of a constraint, written in
Ampersand, which resides in a file with extension .adl
is shown below.
RULE "MC 3":
|- serving ;
The violations produced by a constraint are pairs,
so the set of violations may be interpreted as a rela-
tion too. However, for practical use we are more in-
terested in a readable form of the violation. For this
purpose the enterprise architect adds a specification to
the constraint, so the ArchiChecker can produce read-
able sentences.
The formulation of violation is specified for each
rule. For example, the violation specification for
RULE ”MC 3”:
VIOLATION (TXT "Application component \’",
TGT name, TXT "\’
is not serving a Business process.")
Using this specification ArchiChecker writes to
the log the found violations:
Violations of RULE "MC 3":
Application Component
’Brocacef supplier (orders)’
is not serving a Business Process.
Application Component
’Central application (Chipsoft HiX)’
is not serving a Business Process.
Summarizing, an enterprise architect makes as-
sessment and gets an information for analysis of an
ICEIS 2022 - 24th International Conference on Enterprise Information Systems
ArchiMate model by writing the modeling conven-
tions in the form of constraints, followed by running
the ArchiChecker on the model and the constraints.
In business documents, one will rarely find con-
straints that are ready for automatic checks. Business
policies abound, however. They are mostly formu-
lated in natural language.
A method of formalizing a business policy for
ArchiChecker looks as follows.
- An ArchiMate view (a visual enterprise model and
the corresponding internal ArchiMate model).
- A policy found in an enterprise architecture docu-
1. Reformulate the policy in natural language.
2. Visualize the policy in terms of ArchiMate ele-
ment types, properties and relationships.
3. Formulate an expression of the policy using Pred-
icate Logic. Formulate the rule in Ampersand.
4. Run the ArchiChecker on the ArchiMate model to
generate a list of policy violations.
5. Analyse the found violations and the given Archi-
Mate view to find possible reasons of violations
and possible actions.
To test our method in practice, we have conducted a
case study in the Utrecht Medical Center (UMC) in
the Netherlands. The Enterprise Architecture of the
UMC is partly derived from the nation-wide Hospital
Reference Architecture ZiRA (ZIRA, 2019). For this
paper we show one ArchiMate view (a model at one
level of abstraction) CS Pharmacy (Figure 3).
Pharmacy View. In the real CS Pharmacy two in-
formation systems are used: MIRA(CGM Pharmacy)
and Chipsoft HiX. The systems do not communicate
with each other because of the separated infras-
tructures. The aim of the CS Pharmacy project is
to change the enterprise architecture by deploy-
ing the application HiX CS Pharmacy within the
UMC Utrecht local area network (UU-LAN) to make
available all necessary functionality for the pharmacy.
Business Policies in Documentation. We have found
business policies in documents called Project Start
Architecture (PSA) and selected ten that were suit-
able for turning into modeling conventions. We used
the method shown in section 5 for all ten policies and
checked the ArchiMate CS Pharmacy view for viola-
The selection consists of the following policies:
1. Only one information system is in use for each
2. Unambiguous and one-time recording of data
(and multiple use).
3. Each business process should be realized by at
least one application system.
4. A Business process has precisely one owner.
5. Healthcare providers and patients work with one
shared file.
6. A data or data group uses one or more business
7. The continuity of critical systems of the Medical
Center is guaranteed.
8. Use of central applications is mandatory.
9. The core of information provision is an Enterprise
Data Warehouse (EDW).
10. Every data and data type has someone responsi-
In this paper we show the formalization of 8 poli-
cies. The formalization for all constraints and assess-
ment of two ArchiMate views are available in our re-
port (Joosten et al., 2020).
6.1 Policy 1 - Only One Information
System Is in Use for Each
1. Reformulated in Natural Language. Every
functionality must be realized by precisely one ap-
2. Visualisation in ArchiMate
3. Predicate Logic. The phrase “exactly one” gives
rise to two distinct expression:
For every application function, there exists
at least one incoming realization relation
from an application component.
Constraint Formalization for Automated Assessment of Enterprise Models
f ApplicationFunction
c ApplicationComponent : c realization f .
For every application function, there exists
at most one incoming realization relation
from an application component.
f ApplicationFunctio
, c
ApplicationComponent :
realization f c
realization f c
= c
Rules in Ampersand
RULE "MC 1.a":
I[ApplicationFunction] |-
realization[ApplicationComponent*ApplicationFunction]˜ ;
VIOLATION (TXT "ApplicationFunction \’", TGT name
, TXT "\’ is not realized by any ApplicationComponent.")
RULE "MC 1.b":
; -I[ApplicationComponent]
; realization[ApplicationComponent*ApplicationFunction]
VIOLATION (TXT "ApplicationFunction \’", SRC name,
TXT "\’ is realized
by ApplicationComponents ", SRC
;name, TXT ".")
4. Violations Generated by ArchiChecker. There
is one violation of the Rule “MC 1.a” in view CS
Pharmacy in Figure 3.
ApplicationFunction ’CS Poli-Apotheek is not realized
by any ApplicationComponent.
There are no violations of RULE “MC 1.b”.
5. Understanding the Reasons of Violations. The
ArchiChecker has identified an ApplicationFunc-
tion that is not realized by any ApplicationCom-
ponent. This might indicate that the model is not
6.2 Policy 2 - Unambiguous and
One-time Recording of Data (and
Multiple Use)
To prevent data integrity problems the UMC wants to
store a data object just once. This also makes it easier
to ensure that users don’t have to provide informa-
tion that is already in the system. Of course multiple
copies in multiple nodes are allowed for the sake of
backup and high availability, but logically a data ob-
ject should be present only once. The risk of multi-
ple copies is that one copy gets changed while other
copies don’t, causing inconsistency of data (data pol-
1. Reformulated in Natural Language. Store once
and use manifold, to ensure that users get correct
2. Visualisation in ArchiMate. As architects, let
us agree that access to a specific data object type
is channeled through a single application compo-
nent, whose responsibility it is to keep that data
set in order. Let us model this by a “serving” rela-
tionship between the stores and the data manage-
ment applications.
3. Predicate Logic
d DataOb ject, n, n
s, s
ApplicationComponent :
(n stores d n serving s)
stores d n
serving s
) s = s
Rules in Ampersand
RULE "MC 2":
stores˜ ; serving ; -I[ApplicationComponent] ;
serving[Node*ApplicationComponent]˜ ; stores
|- -I[DataObject]
VIOLATION ( TXT "Data objects of type \"", SRC name
, TXT "\" are stored in "
, SRC stores˜ ; serving[Node*ApplicationComponent])
4. Violations Generated by ArchiChecker. This
script of ArchiMate yields no violations. For ar-
chitects it is interesting to experiment with the
ArchiMate model to make examples to violate this
rule deliberately. In this way they can try out their
modeling conventions in practice.
5. Understanding the Reasons of Violations. The
selected policy does not constitute any violation
(Figure 3). It is just that situations in which this
rule might be violated do not occur yet. It is likely
that the enterprise architecture will grow in size
and maturity as time goes by. In that case it is
conceivable that this rule might be violated. It is
up to the architects to decide how useful it is to
detect those violations.
ICEIS 2022 - 24th International Conference on Enterprise Information Systems
6.3 Policy 3 - Each Business Process
Should Be Served by at Least One
Application System
We have found that Policy 3 needs an explanation of
its goal, namely, the business should know the serving
application system, i.e. should be served with an un-
ambiguous source system to which other applications
are connected.
1. Reformulated in Natural Language. Each busi-
ness process is served by at least one application
2. Visualisation in ArchiMate. For every business
process, there must be precisely one incoming
serving relation from an application component.
3. Predicate Logic
f ApplicationComponent
c BusinessProcess : c serving f .
Rules in Ampersand
RULE "MC 3":
I[ApplicationComponent] |- serving ;
serving[ApplicationComponent*BusinessProcess] ;
VIOLATION (TXT "Application component \’",
TGT name, TXT "\’ is not serving
a Business process.")
4. Violations Generated by ArchiChecker. Vio-
lations of RULE “MC 3” in the model CS Phar-
macy, Figure 3:
Application Component ’Brocacef supplier (orders)’
is not serving a Business Process.
Application Component
’Central application (Chipsoft HiX)’
is not serving a Business Process.
Application Component ’Autopharma
is not serving a Business Process.
Application Component ’MIRA (CGM Pharmacy)
is not serving a Business
Application Component ’ServiLocker’
is not serving a Business Process.
Application Component ’National Exchange Point
is not serving a Business Process.
5. Understanding the Reasons of Violations. The
reason of violations in this case is the difficulty
in visualization of this policy. The architects have
decided to make a separate table presenting the
serving relations demanded by Policy 3. This ta-
ble is aimed to accompany Figure 3.
6.4 Policy 4 - Every Business Process
Has Precisely One Owner
1. Reformulated in Natural Language. Every
business process has precisely one owner.
2. Visualisation in ArchiMate
3. Predicate Logic
MC 4.1.
b BusinessProcess a BusinessActor :
a owner b.
MC 4.2.
s BusinessProcess a, b BusinessActor :
a owner s b owner s a = b.
Rules in Ampersand
RULE "MC 4.1":
I [BusinessProcess] |-
owner[BusinessActor*BusinessProcess]˜ ;
VIOLATION (TXT "Business Process \’", SRC name,
TXT "\’ does not have an
RULE "MC 4.2":
owner[BusinessActor*BusinessProcess] |-
-(-I[BusinessActor] ; owner)
VIOLATION (TXT "Business Process \’", TGT name,
TXT "\’ has multiple
4. Violations Generated by the ArchiChecker.
The violations of RULE “MC 4.1” in enterprise
model CS Pharmacy:
Business Process ’BSN and COV check insurance data’
does not have an owner.
There are no violation of “MC 4.2”.
5. Understanding the Reasons of Violations. In
the case of CS Pharmacy (Figure 3) a role / owner
has been assigned for a crucial process, namely
“medication monitoring”. The architect have cho-
sen not to visualize other owners. It is assumed
that an owner has been assigned for each business
6.5 Policy 5 - Healthcare Providers and
Patients Work with One Shared File
This policy needs explanation of its goal. All health-
care providers involved in the healthcare of a patient
and the patients themselves work with one shared file.
They have access to the healthcare file and work with
the same information. Clear information that can be
Constraint Formalization for Automated Assessment of Enterprise Models
easily found makes an important contribution to qual-
ity and patient safety. This contains the (core) data re-
garding the health status and treatment of the patient
that are important for all healthcare professionals who
have a treatment relationship with the patient. The
implementation of CS Pharmacy creates a more un-
ambiguous working environment and one integrated
medication file.
1. Reformulated in Natural Language. For every
patient, there must be one file called “Patient’s
File”. Each patient must have access to his or her
patient file. Each health worker directly involved
in medical care for a patient must have access to
that patient’s file. Others have no access to this
2. Visualisation in ArchiMate. The rule A pa-
tient’s file is accessible only to the patient himself
and all health workers directly involved in med-
ical care for that patient. cannot be modeled in
ArchiMate in a direct fashion. Therefore it is en-
tered textually in a constraint element. For every
business actor named “Patient”, we make sure to
model a data object named “Patient’s File”. The
patient and health workers have an access rela-
tionship (read/write) to the patient’s file.
3. Predicate Logic
Let patient be a predicate on BusinessActor.
Let patientfile be a predicate on BusinessObject.
Let careTaker be a relation BusinessActor ×
BusinessActor that relates health workers and
their own patients.
a, b BusinessActor o BusinessOb ject :
a caretaker b b access o a access o.
a, b BusinessActor o BusinessOb ject :
a caretaker b b oaccess o a access o.
Rules in Ampersand
CLASSIFY PatientFile ISA BusinessObject
CLASSIFY Patient ISA BusinessActor
CLASSIFY Patient ISA Person
I[Patient] = name;"Patient";name˜
I[PatientFile] = name;"Patient’s File";name˜
[Patient] |- access[Patient*PatientFile] ;
access = access[Patient*PatientFile]˜
RULE "MC 5":I [BusinessObject] |- access
access [BusinessObject*BusinessActor]˜
"If (a,b) is in the relation caretaker,
then person a is a health
worker directly involved in medical care for
patient b."
VIOLATION (TXT "PatientFile (Business Object)\’", SRC
4. Violations Generated by the ArchiChecker
PatientFile (Business Object) ’Patient file
is not accessed by
a caretaker/Patient (Health worker).
5. Understanding the Reasons of Violations. The
architects have acknowledged that visualization of
the fact that the caretaker has access to the patient
file has been forgotten indeed.
6.6 Policy 6 - A Data or Data Group
Uses One or More Business Objects
Data is always recorded, presented and exchanged in
their “context”. The place where the user is located
(clinic or emergency room), the situation, the time,
the device used and the user account are the “circum-
stances” under which data was obtained and recorded.
A date and time is set for healthcare logistics data, so
that control information about the progress of health-
care logistics processes can be made available. To
ensure the relevance of data, every data object in an
ArchiMate model must be linked to a business object.
The purpose of Policy 6 is to spot redundant data or
incomplete architecture models.
1. Reformulated in Natural Language. Every
Data Object realizes one or more Business Ob-
2. Visualisation in ArchiMate
3. Predicate Logic. b DataOb ject o
BusinessOb ject : c realization b.
Rules in Ampersand
RULE "Policy 6":
I[DataObject] |- realization[DataObject*BusinessObject];
VIOLATION (TXT "Data Object \’", SRC name, TXT "\’
does not realize any Business Object")
4. Violations Generated by the ArchiChecker.
This script of ArchiMate contains no violations.
ICEIS 2022 - 24th International Conference on Enterprise Information Systems
5. Understanding the Reasons of Violations.
There is just one data object, ’Patient data’, which
resides in model CS Pharmacy Figure 3. Since it
is connected to Business object ‘Patient file’ by a
realization relation, there are no violations of this
6.7 Policy 7 - The Continuity of Critical
Systems Is Guaranteed
The availability of the data must be and remain guar-
anteed. The data must also remain available for up-
dates or a switch to another system.
1. Reformulated in Natural Language. Each IT
system has an owner responsible for ensuring con-
tinuity and taking adequate measures.
2. Visualisation in ArchiMate
3. Predicate Logic
a ApplicationComponent
b BusinessActor : b owner a.
b, d BusinessActor,
a ApplicationComponent :
b owner a d owner a b = d.
Rules in Ampersand
RULE "MC 7.1":
I [ApplicationComponent] |-
owner[BusinessActor*ApplicationComponent]˜ ;
VIOLATION (TXT "Application Component \’", SRC name,
TXT "\’ does not have an owner.")
RULE "MC 7.2":
owner[BusinessActor*ApplicationComponent] |-
-(-I[BusinessActor] ; owner)
VIOLATION (TXT "Application Component \’", TGT name,
TXT "\’ has ", SRC name, TXT " owners.")
4. Violations Generated by the ArchiChecker
Application Component ’Brocacef supplier (orders)’
does not have an owner.
Application Component
’Central application (Chipsoft HiX)’
does not have
an owner.
Application Component ’Autopharma
does not have an owner.
Application Component ’MIRA (CGM Pharmacy)’
does not have an owner.
Application Component ’ServiLocker’
does not have an owner.
There are no violations of “MC 7.2”.
5. Understanding the Reasons of Violations. Non
of application components of the enterprise model
CS Pharmacy (Figure 3) has an owner. The con-
tinuity of data of these components is not guaran-
6.8 Policy 8 - Use of the Central
Application Is Mandatory
1. Reformulated in Natural Language. An appli-
cation component is central if it is inside one of
the communication networks of the organization.
2. Visualisation in ArchiMate
3. Predicate Logic
a ApplicationComponent :
c CommunicationNetwork :
a inside c.
Rules in Ampersand
RULE 10:
I[ApplicationComponent] |- inside ;
I[CommunicationNetwork] ; inside˜
VIOLATION (TXT "Application Component \’",
SRC name,
TXT "\" is not inside a LAN")
4. Violations Generated by the ArchiChecker
There are 3 violations:
Application Component ’Brocacef supplier
is not inside a LAN
Application Component ’National Exchange
is not inside a LAN
Application Component ’EZorg
is not inside a LAN
5. Understanding the Reasons of Violations. The
application components mentioned in violations
are presented in Figure 3. When confronted with
the violation list, architects must decide what to
do. If an application is central, then it has to be
included in one of the communication networks
in all views. If an application is not central, it is
clearly not preferred, so they might want to trade
it for a preferred application.
In this paper we have presented a method
Constraint Formalization for Automated Assessment of Enterprise Models
for transformation of business polices to model-
ling conventions and constraints on enterprise
models in ArchiMate and
for automatic assessment of ArchiMate model in
form of generated violations of constraints ex-
pressed in terms of analysed enterprise models.
In order to increase the readability of our paper, we
have presented a part of the testing results of the
method on the Enterprise model “CS Pharmacy” and
eight policies found in the enterprise architecture doc-
uments. In fact, the proposed method has been tested
on two ArchiMate models and ten polices. The sec-
ond ArchiMate model used for testing of our method
is called “CS Office 365”. It shows the implemen-
tation of the standardized platform Office 365 for
collaboration within UMC Utrecht and outside the
organization. The results of testing can be found
in (Joosten et al., 2020).
The application of our method to the enterprise
models “CS Pharmacy” and ‘CS Office 365” and all
policies have shown several interesting observations:
Formalization of modeling conventions is far from
trivial and should not be underestimated.
Multiple authors have noted that the acquisi-
tion of constraints is the real challenge archi-
tects face (Babkin and Ponomarev, 2017; Ramos
et al., 2014; Chatzikonstantinou and Kontogian-
nis, 2012). Our effort to analyze enterprise mod-
els and their constraints underwrites this claim.
The policies found in an organization can be
reused for its enterprise models.
The formalized constraints corresponding to po-
lices can be reused by renaming of elements. A
pool of often used polices can be collected for
reuse in each organization. We have reused the
pool of ten policies for two enterprise models.
The formalization of a policy into a constraint
makes the policies clearer to enterprise architects
and business.
The formalization of policies contributes to the
quality of enterprise models as models are cor-
rected to meet constraints.
Having tested our method for two ArchiMate
models and ten policies we have covered all phases
of the Design Science Research including evalua-
tion (Cleven, Anne and Gubler, Philipp and H
Kai M, 2009).
A method of constraint formalization for automated
assessment of enterprise models presented in this pa-
per can be used as it has been designed and tested.
It should be, however, known, that the method is
labor-consuming. The difficulties are caused by the
agreements that should be achieved in understanding
of policies by people having different roles in organi-
zation. Also the transformations of agreements into
constraints demands accuracy. The enterprise mod-
els serve as clarification and transformation means for
Experimenting with our method, we have found
that a business policy and the corresponding con-
straint cannot be understood without understanding
the goal of the Enterprise Model in hand and the goal
of the business policy in it. The method and tooling
presented in this paper can be seen as a part of En-
terprise modelling approach that includes goal mod-
elling. We are working on an approach for consistent
modelling in ArchiMate that includes goal models re-
fined to requirements and associated with policies and
constraints within each enterprise multi-view model.
The applicability of constraints associated with a goal
model is easier to understand and easier to make de-
cisions when views violate such constraints. In future
work, we are planning to include the method for con-
straint checking proposed in this paper into the ap-
proach for consistent modelling in ArchiMate.
The authors thank the enterprise architects of the Uni-
versity Medical Center Utrecht for their cooperation
during conducting the case study.
Arriola, L. and Markham, A. (2018). Towards an enterprise
architecture controlling framework. In Proceedings of
the 12th European Conference on Software Architec-
ture: Companion Proceedings, pages 1–7.
Babkin, E. A. and Ponomarev, N. O. (2017). Analysis of
the consistency of enterprise architecture models us-
ing formal verification methods. Business Informat-
ics, (3):30–40.
Beauvoir, P. and Sarrodie, J. (2018). Archi-the free archi-
mate modelling tool. User Guide. The Open Group.
Beauvoir, P. and Sarrodie, J.-B. (2019). Archi-Open Source
Archimate Modelling.
ICEIS 2022 - 24th International Conference on Enterprise Information Systems
e, G., Sottet, J.-S., and Dupuy-Chessa, S.
(2019). Using an enterprise architecture model for
GDPR compliance principles. In IFIP Working Con-
ference on The Practice of Enterprise Modeling, pages
199–214. Springer.
Chapurlat, V. and Braesch, C. (2008). Verification, valida-
tion, qualification and certification of enterprise mod-
els: Statements and opportunities. Computers in In-
dustry, 59(7):711–721.
Chatzikonstantinou, G. and Kontogiannis, K. (2012). Pol-
icy modeling and compliance verification in enterprise
software systems: A survey. In 2012 IEEE 6th In-
ternational Workshop on the Maintenance and Evo-
lution of Service-Oriented and Cloud-Based Systems
(MESOCA), pages 27–36. IEEE.
Cleven, Anne and Gubler, Philipp and H
uner, Kai M (2009).
Design alternatives for the evaluation of design sci-
ence research artifacts. In Proceedings of the 4th In-
ternational Conference on Design Science Research
in Information Systems and Technology, pages 1–8.
Filet, P., van de Wetering, R., and Joosten, S. (2019). En-
terprise architecture alignment. De-
partment of Information Sciences, Open University of
the Netherland.
Jackson, Daniel (2006). Software Abstractions: Logic, Lan-
guage, and Analysis. The MIT Press.
Jonkers, H., Band, I., Quartel, D., and Lankhorst, M.
(2016). ArchiSurance Case Study version 2. The Open
Joosten, S. (2018). Relation Algebra as programming
language using the Ampersand compiler. Journal
of Logical and Algebraic Methods in Programming,
Joosten, S., Haddouchi, E. M., and Roubtsova, E. (Easy-
Chair, 2020). Design policy checking in archimate.
on the cases technology policies in a medical center.
EasyChair Preprint no. 4129.
Kharlamov, E., Grau, B. C., Jim
enez-Ruiz, E., Lamparter,
S., Mehdi, G., Ringsquandl, M., Nenov, Y., Grimm,
S., Roshchin, M., and Horrocks, I. (2016). Captur-
ing industrial information models with ontologies and
constraints. In International Semantic Web Confer-
ence, pages 325–343. Springer.
Lankhorst, M. M., Proper, H. A., and Jonkers, H. (2010).
The anatomy of the ArchiMate language. Interna-
tional Journal of Information System Modeling and
Design (IJISMD), 1(1):1–32.
Marosin, D., Ghanavati, S., and van der Linden, D. (2014).
A Principle-based Goal-oriented Requirements Lan-
guage (GRL) for Enterprise Architecture. In iStar.
Mayer, N., Aubert, J., Grandry, E., Feltus, C., Goettelmann,
E., and Wieringa, R. (2019). An integrated concep-
tual model for information system security risk man-
agement supported by enterprise architecture manage-
ment. Software & Systems Modeling, 18(3):2285–
Peffers, K., Tuunanen, T., Rothenberger, M. A., and Chat-
terjee, S. (2007). A design science research method-
ology for information systems research. Journal of
management information systems, 24(3):45–77.
Ramos, A., Gomez, P., S
anchez, M., and Villalobos,
J. (2014). Automated enterprise-level analysis of
Archimate models. In Enterprise, Business-Process
and Information Systems Modeling, pages 439–453.
The Open Group (2012-2019). ArchiMate 3.1 Specifica-
Wedemeijer, L. (2014). A relation-algebra language to
specify declarative business rules. In 4th International
Symposium on Business Modeling and System Design,
BMSD, pages 63–73.
Zhi, Q., Yamamoto, S., and Morisaki, S. (2018). IMSA-
Intra Model Security Assurance. J. Internet Serv. Inf.
Secur., 8(2):18–32.
ZIRA (2019). Ziekenhuis Referentie Architectuur)
Constraint Formalization for Automated Assessment of Enterprise Models