Modeling Trust in Enterprise Architecture:
A Pattern Language for ArchiMate
Glenda Amaral1 , Tiago Prince Sales1 , Giancarlo Guizzardi1 ,
João Paulo A. Almeida2 , and Daniele Porello3
1
Conceptual and Cognitive Modeling Research Group (CORE),
Free University of Bozen-Bolzano, Bolzano, Italy
[gmouraamaral,tiago.princesales,giancarlo.guizzardi]@unibz.it
2 Ontology & Conceptual Modeling Research Group (NEMO),
Federal University of Espírito Santo, Vitória, Brazil
jpalmeida@ieee.org
3 ISTC-CNR Laboratory for Applied Ontology, Trento, Italy
daniele.porello@loa.istc.cnr.it
Summary. Trust is widely acknowledged as the cornerstone of relationships in
social life. But what makes an agent trust a person, a resource or an organization?
Which characteristics should a trustee have in order to be considered trustworthy? The importance of understanding trust in organizations has motivated us to
investigate the representation of trust concerns in enterprise models. Based on a
well-founded reference ontology of trust, we propose a pattern language for trust
modeling in ArchiMate. We present a first iteration of the design cycle, which
includes the development of the pattern language and its demonstration by means
of a realistic case study about trust in a COVID-19 data repository.
Key words: Trust Modeling, Enterprise Architecture, ArchiMate.
1 Introduction
Trust is a vital ingredient in productive relationships. According to Castelfranchi and
Falcone [5], “trust in its intrinsic nature is a dynamic phenomenon” that changes with
time. In times of crisis, such as the financial crisis of 2008 and the current COVID-19
health crisis, it becomes even more evident how fragile trust is. Therefore, the understanding of the building blocks that compose the trust of agents in a given trustee (such
as an organization) is of paramount importance, as they reveal the qualities and properties the trustee should have in order to be considered trustworthy and effectively promote well-placed trust. Moreover, the identification of the trust components is fundamental to the assessment of risks that can emerge from trust relations.
From the perspective of an organization trustee, the modeling of trust in the context
of Enterprise Architecture (EA) enables to bridge the gap between the stakeholders’
trust concerns and the processes and other elements of the architecture that are needed
to achieve the organization’s goal of being trustworthy. The idea of modeling social and
organizational concepts in the context of Enterprise Architecture has already been proposed in the literature in the context of value [20], risk [14, 18], service contracts [8],
2
Glenda Amaral et al.
resources and capabilities [3], however, the problem of linking the enterprise architecture to the stakeholders’ trust concerns is still an open issue.
In this paper, we address this issue by proposing a trust modeling approach for
ArchiMate, which is based on a proper ontological theory that provides adequate realworld and formal semantics for the concept of trust. In particular, we leverage the
concepts and relations defined in the recently proposed Reference Ontology of Trust
(ROT) [1], an ontologically well-grounded reference model that formally characterizes the concept of trust and explains how risk emerges from trust. ROT is specified
in OntoUML [10], and thus, compliant with the meta-ontological commitments of the
Unified Foundational Ontology (UFO) [10]. Based on ROT, we propose a Trust Pattern Language (TPL) for ArchiMate–the most used modeling language in the EA field.
A pattern language [4] consists of a set of interrelated modeling patterns and its main
advantage is that it offers a context in which related patterns can be combined, thus,
reducing the space of design choices and design constraints [7]. We designed TPL following the Design Science Research methodology [12]. In this paper, we present the
first iteration of the design cycle (building and evaluating), which includes the development of the pattern language and its demonstration by means of a real case study of
trust in a COVID-19 data repository.
The remainder of this paper is organized as follows. Section 2 introduces the reader
to the Reference Ontology of Trust (ROT) that provides the ontological foundations
in which the Trust Pattern Language (TPL) is grounded. Section 3 presents the set of
requirements identified for the language (Section 3.1), which are needed for a formal
evaluation of the language. Afterward, the individual modeling patterns that compose
TPL are presented (Section 3.2), as well as a method for combining them (Section 3.3).
In Section 4, we demonstrate how TPL can be used by presenting a real case example of trust in a COVID-19 data repository. We conclude in Section 5 with some final
considerations.
2 Research Baseline
2.1 The Reference Ontology of Trust
The Reference Ontology of Trust1 (ROT) is a UFO-based ontology that formally characterizes the concept of trust, clarifies the relation between trust and risk, and represents
how risk emerges from trust relations [1]. ROT makes the following ontological commitments about the nature of trust:
– Trust is relative to a goal. An agent, the trustor, trusts someone or something, the
trustee, only relative to a goal, for the achievement of which she counts upon the
trustee.
– Trust is a complex mental state of a trustor regarding a trustee and her behavior.
It is composed of: (i) a trustor’s intention, whose propositional content is a goal of the
trustor; (ii) the belief that the trustee has the capability to perform the desired action
1
The complete version of ROT in OntoUML and its implementation in OWL are available at
http://purl.org/krdb-core/trust-ontology.
Modeling Trust in Enterprise Architecture
–
–
–
–
3
or exhibit the desired behavior; and (iii) the belief that the trustee’s vulnerabilities
will not prevent her from performing the desired action or exhibiting the desired
behavior. When the role of trustee is played by an agent, trust is also composed of
the trustor’s belief that the trustee has the intention to exhibit the desired behavior.
The trustor is necessarily an “intentional entity”. Briefly put, the trustor is a cognitive agent, an agent endowed with goals and beliefs [5].
The trustee is not necessarily a cognitive system. The trustee is an entity capable
of having a (hopefully positive) impact on a goal of the trustor by the outcome of its
behavior [5]. A trustee may be a person, an animal, a car, a vaccine, etc.
Trust is context dependent. The trustor may trust the trustee for a given goal in a
given context, but not do so for the same goal in a different context. We assume trust
relations to be highly dynamic [5].
Trust implies risk. By trusting, the trustor accepts to become vulnerable to the
trustee in terms of potential failure of the expected behavior and result, as the trustee
may not exhibit the expected behavior or it may not have the desired result [13, p 21].
Fig. 1 depicts a ROT excerpt, which is represented in OntoUML, an ontology-driven
conceptual modeling language based in UFO[11].
Fig. 1: A fragment of ROT depicting the mental aspects of trust
In ROT, Trust is modelled as a complex mode (an externally dependent entity,
which can only exist by inhering in other individuals [10]) composed of an Intention
whose propositional content is a goal of the Trustor, and a set of Beliefs that inhere in the Trustor and are externally dependent on the Dispositions [9, 3] that
inhere in the Trustee. These beliefs include: (i) the Belief that the Trustee has
the Capability to exhibit the desired behavior (Capability Belief); and (ii) the
Belief that the Trustee’s Vulnerabilities will not prevent her from exhibiting
the desired behavior (Vulnerability Belief). The Trustee’s Vulnerabilities
and Capabilities are dispositions that inhere in the Trustee, which are manifested
in particular situations, through the occurrence of events [9]. Social Trust is a specialization of Trust in which the Trustee is an Agent. Therefore, this form of trust is
also composed of the Trustor’s belief that the Agent Trustee has the Intention to
perform the desired action (Intention Belief). The relation influences represents
that an instance of Trust can influence another (positively or negatively) [15].
4
Glenda Amaral et al.
ROT relies on the Common Ontology of Value and Risk (COVER) (Fig. 2) proposed
by Sales et al. [19] to represent the relation between trust and risk. COVER proposes
an ontological analysis of notions such as Risk, Risk Event and Vulnerability, among
others. A central notion for characterizing risk in COVER is a chain of events that
impacts an agent’s goals, which the authors name Risk Experience. Risk Experiences
focus on unwanted events that have the potential of causing losses and are composed
of events of two types, namely threat and loss events. A Threat Event is the one with
the potential of causing a loss, which might be intentional or unintentional. A Threat
Event might be the manifestation of: (i) a Vulnerability (a special type of disposition whose manifestation constitutes a loss or can potentially cause a loss from the
perspective of a stakeholder); or (ii) a Threat Capability (capabilities whose manifestation enables undesired events that threaten agent’s abilities to achieve a goal). The
second mandatory component of a Risk Experience is a Loss Event, which necessarily impacts intentions in a negative way [19].
Fig. 2: A fragment of COVER depicting risk experience [19]
2.2 ArchiMate
ArchiMate is a modeling standard that defines a layered structure by means of which
the architecture of enterprises can be described [21]. The language is organized in six
layers, namely Strategy, Business, Application, Technology, Physical, and Implementation & Migration [21]. In this paper, we focus on the elements of the Strategy and
Business layers.
A model in ArchiMate is a collection of elements and relationships. In ArchiMate,
each element is classified according to its nature, referred to as “aspects”: an Active
Structure Element represents an entity that is capable of performing behavior, a Passive
Structure Element represents a structural element that cannot perform behavior, a Behavior Element represents a unit of activity performed by one or more active structure
elements, a Motivation Element is one that provides the context of or reason behind the
architecture, and a Composite Element is simply one that aggregates other elements.
The most relevant ArchiMate elements for the TPL are: (i) Stakeholder, Driver, Assessment and Goal (Motivation Elements); (ii) Resource (a Passive Structure Element);
(iii) Business Actor (an Active Structure Element); (iv) Capability and Business Event
(Behavior Elements); and (v) Grouping. As for relations, the most relevant ones are:
(i) Composition and Realization (when applied to Structural elements); (ii) Influence
(which is a sort of Dependency); (iii) Triggering (when applied to Behavior); and (iv)
Association (which can be used flexibly in many contexts to relate elements when other
Modeling Trust in Enterprise Architecture
5
more specific relations are not available). A detailed definition of the concepts of the
language can be found in the ArchiMate specification [21].
3 A Pattern Language for Trust Modeling
3.1 Language Requirements
According to Buschmann et al. [4], “a pattern describes a particular recurring design
problem that arises in specific design contexts and presents a well-proven solution for
the problem”. Deutsch [6] defines a pattern language as “a set of patterns and relationships among them that can be used to systematically solve coarse-grained problems”.
We have established two types of requirements in the design of the TPL: (i) analysis
requirements, which refer to what the models produced with the language should help
users to achieve, either by means of automated or manual analysis; and (ii) ontological requirements, which refer to the concepts and relations the language should have in
order to accurately represent its domain of interest and thus support its intended uses.
Below we present the list of the analysis requirements for the TPL:
R1. Trustworthiness analysis: an enterprise should be able to gain insight into why
it trusts certain key resources, actors or partners (or event if they should do it in the
first place!). In particular, for a given trust relation, the enterprise should be able to
identify the capabilities and vulnerabilities of a particular trustee that are the focus of
its beliefs, so that it can detect potential threats to the achievement of its goals. From
the opposite perspective, the enterprise should be able to identify what makes them
trustworthy (or not) from the point-of-view of their customers and partners, possibly
identifying what it could change to increase trust levels, as well the key capabilities
it needs to guarantee to promote well-placed trust.
R2. Risk analysis: By modeling the elements that compose the trust complex mental
state of a trustor regarding a trustee, an enterprise should be able to identify risks that
can emerge as consequence of either the manifestation of a trustee’s vulnerability or
the unsatisfactory manifestation of a trustee’s capability.
As for the ontological requirements, they consist of an isomorphic representation
of the concepts and relations defined in the Reference Ontology of Trust, in which
it is based. In addition to the aforementioned requirements, we assume the following
constraints for the TPL:
R3. It should rely exclusively on constructs available in ArchiMate 3.0.1 [21], in an
effort to retain its user base and tool support, as well as to prevent adding complexity
to the language.
R4. It should map trust-related concepts into ArchiMate constructs maintaining, as
much as possible, their original meaning as described in the standard. Specialized
semantics should be addressed via stereotypes, constituting thus a lightweight extension of the language.
6
Glenda Amaral et al.
3.2 Trust Modeling Patterns
Trust Assessment. This pattern allows modelers to represent a trust relation between
a trustor and a trustee, in which the former trusts the latter with respect to an intention
(whose propositional content is a goal, for the achievement of which the trustor counts
upon the trustee). The trustor is always a cognitive agent, endowed with goals and
beliefs. As for the trustee, it is an entity able to cause an impact (hopefully positive)
on a trustor’s goal by the outcome of its behavior. Note that the role of trustee can be
played not just by agents, but also by objects, such as rules, procedures, conventions,
infrastructures, tools, artifacts in general, as well as different types of social systems.
For this reason, this pattern has two variants, depending on the type of the trustee.
The first variant, depicted in Fig. 3a, details the trust relation when the trustee is
an object. It consists of a Structure Element, the trustee, connected to a «Trust»
Assessment, which in turn is connected both to a Stakeholder, the trustor, and to the
Goal she is counting on achieving. Attached to the «Trust» Assessment is the Trust
Degree, which is an attribute that can be described as an entry in a scale chosen by the
modeler, such as a discrete scale like <Low,Medium,High> or a continuous scale like
<0-100>. An example of this first variant is shown in Fig. 3b. In the second variant, the
trustee is a cognitive agent and thus is modeled as a «Trustee» Stakeholder.
(a)
(b)
Fig. 3: The Trust Assessment Pattern
Capability Belief. This pattern allows modelers to express which capability of the
trustee is the focus of a capability belief of the trustor. Capabilities are dispositions that
inhere in agents and objects, which are manifested in particular situations, through the
occurrence of events. They are usually understood as positive dispositions, in the sense
that they enable the manifestation of events desired by an agent. The generic structure of
the Capability Belief Pattern is depicted in Fig. 4a. It connects a Capability Belief
Assessment of a «Trustor» Stakeholder to the corresponding Capability of a
«Trustee». An application of this pattern is presented in Fig. 4b.
(a)
(b)
Fig. 4: The Capability Belief Pattern
Vulnerability Belief. This pattern allows modelers to express which vulnerability of the
trustee is the focus of a vulnerability belief of the trustor. Vulnerabilities are a special
Modeling Trust in Enterprise Architecture
7
type of disposition whose manifestation constitutes a loss or can potentially cause a loss
from the perspective of a stakeholder. The generic structure of the Vulnerability Belief
Pattern is depicted in Fig. 5a. It connects a Vulnerability BeliefAssessment of a
«Trustor» Stakeholder to the corresponding Vulnerability of a «Trustee». Fig.
5b presents an application example of this pattern.
(a)
(b)
Fig. 5: The Vulnerability Belief Pattern
Intention Belief. This pattern allows modelers to express which intention of the trustee
is the focus of an intention belief of the trustor. Its generic structure is depicted in Fig.
6a. It connects an Intention Belief Assessment of a «Trustor» Stakeholder
to the corresponding Goal of a «Trustee». Fig. 6b presents an application example for
this pattern.
(a)
(b)
Fig. 6: The Intention Belief Pattern
Trust Composition. To account for what makes an agent trust a resource or another
agent, we introduce the Trust Composition Pattern, which details the complex mental
state of the trustor. The understanding of the elements that compose trust is important because they reveal the qualities and properties the trustee should have in order
to be considered trustworthy and effectively promote well-placed trust. This pattern
refines the Trust Assessment Pattern by detailing the decomposition of the «Trust»
Assessment into the beliefs of the trustor about the trustee. It has two variants, as the
beliefs of the trustor vary according to the trustee type.
The first variant, depicted in Fig. 7a, details trust when the trustee is not a cognitive
agent. In this case, we make use of the Capability Pattern and the Vulnerability Pattern
to represent that the «Trust» Assessment is composed of Belief Assessments of
the trustor regarding the Capabilities and Vulnerabilities of the trustee (the
trustor believes that the trustee has the capability to exhibit a desired behavior and that
its vulnerabilities will not prevent it from exhibiting this behavior). Fig. 7b shows an
application example of this pattern.
In the second variant the trustee is a cognitive agent endowed with goals and, therefore, her intentions are also part of the set of beliefs that compose trust. Besides believing that the trustee is capable of exhibiting a desired behavior and that her vulnerabilities
8
Glenda Amaral et al.
will not stop her from doing that, the trustor believes that trustee has the intention to
exhibit the aforementioned behavior. Therefore, in this case, in addition to the Capability Belief and Vulnerability Belief Patterns, the Intention Belief Pattern is also used to
represent the «Trust» Assessment.
(a)
(b)
Fig. 7: The Trust Composition Pattern
Risk Experience. In order to account for how risk emerges from trust relations, we
propose the Risk Experience Pattern, presented in Fig. 8. Once the components of trust
are known (decomposed using the Trust Composition Pattern), it is possible to identify
the risks related to the capabilities and vulnerabilities of the trustee, which are the focus
of trustor’s beliefs.
Our modeling strategy is directly inspired by the risk modeling approach proposed
by Sales et al. [18]. Given the objectives of our pattern, we focus here on the perspective of risk as a chain of events that impact an agent’s goals, which the authors
named Risk Experience. Risk Experiences focus on unwanted events that have the
potential of causing losses and are composed by events of two types, namely threat
and loss events [18]. A Threat Event is the one with the potential of causing a loss.
As described in [18], it might be the manifestation of: (i) a Vulnerability; or (ii)
Threat Capability (as aforementioned, capabilities are usually perceived as beneficial, as they enable the manifestation of events desired by an agent. However, when the
manifestation of a capability enables undesired events that threaten agent’s abilities to
achieve a goal, it can be seen as a Threat Capability). The second mandatory component of a Risk Experience is a Loss Event, which necessarily impact intentions
in a negative way.
Following the strategy of Sales et al. [18], we mapped Risk Experience as a
Grouping decorated with the «RiskExperience» stereotype. Such a grouping should
aggregate the elements and the relations in an experience. Then, we associated the
«RiskExperience» Grouping with risks, which are mapped as «Risk» Drivers,
as drivers represent “conditions that motivate an organization to define its goals and
implement the changes necessary to achieve them” [21].
The first variant, depicted in Fig. 8a, allows modelers to represent the existence of
risks related to Vulnerabilities of the trustee that are the focus of beliefs of the
Modeling Trust in Enterprise Architecture
9
trustor. «ThreatEvent» Event might be the manifestation of a Vulnerability and
may lead to a «LossEvent» Event, which impacts the Trustor Intention in a negative way, as it hurts her Intention of reaching a specific goal. «HazardAssessment»
Assessment stands for situations that activate vulnerabilities and threat capabilities,
which in turn will be manifested as «ThreatEvent» Events. Since ArchiMate does
not provide a native construct for modeling situations in general, we followed the approach used in [18] and represent hazardous situations as assessments about them. Fig.
8b shows an application example of this pattern.
The second variant is similar to the previous one, as it also represents the existence
of risks related to a disposition of the trustee, though in this case the disposition is a
Threat Capability. As previously mentioned, when the manifestation of a capability enables undesired events that threatens agent’s abilities to achieve a goal, it can be
seen as a Threat Capability. Analogous to the former variant, a «ThreatEvent»
Event might be the manifestation of a Threat Capability of the trustee if the trustee
fails to perform this specific Capability that was supposed to bring about an outcome
desired by the trustor. Finally, the «ThreatEvent» Event can trigger a «LossEvent»
Event, which has a negative impact on the Trustor Intention.
(a)
(b)
Fig. 8: The Risk Experience Pattern
Risk Assessment. This pattern, also extracted from [18], complements our approach
on the modeling of risks that emerge from trust relations. It consists of a Risk
Assessment made by a Stakeholder about a «Risk» Driver, which in turn is associated to a «RiskExperience» Grouping. In addition, the Risk Assessment is
connected to a «ControlObjective» Goal, a sort of high level goal that defines what
the organization intends to do about an identified risk. Control Goals are connected
to «ControlMeasure» Requirements that represent desired properties of solutions
– or means – to realize such goals. Using this pattern, depicted in Fig. 9, it is possible to model the realization of control measures by any set of core elements, such as
business processes (e.g. a data quality management process), application services (e.g.
a scanning service) or nodes (e.g. a document management system).
Fig. 9: The Risk Assessment Pattern
10
Glenda Amaral et al.
Trust Influencing Trust. This pattern allows modelers to represent that trust can influence trust, either positively or negatively. For example, one’s trust in the local police
officer may increase one’s trust in the “judiciary system”. It can be further used to characterize the existence of “trust by delegation”. The idea behind “trust by delegation” is
that when, for example, Alice trusts Bob, and Bob trusts Charlie, then Alice can derive a
measure of “trust by delegation” in Charlie. In this case the «Trust» Assessments “Alice trusts Bob” and “Bob trusts Charlie” positively influence the «Trust» Assessment
“Alice trusts Charlie”. As shown in Fig. 10, the pattern makes explicit the influence
association between a «Trust» Assessment and the other one under its influence.
(a)
(b)
Fig. 10: The Trust Influencing Trust Pattern
The mapping between the ontological trust-related concepts and their representation
in ArchiMate is listed in Table 1.
Table 1: Representation of trust and risk-related concepts in ArchiMate.
Concept
Representation in ArchiMate
Trust
Trustor
Trustee
Trust Degree
Capability
Vulnerability [18]
Intention
Belief
Capability Belief
Vulnerability Belief
Intention Belief
Risk [18]
Risk Assessment [18]
Risk Assessor [18]
Risk Experience [18]
Threat Event [18]
Loss Event [18]
Hazard Assessment [18]
«Trust» Assessment
«Trustor» Stakeholder
«Trustee» Stakeholder or «Trustee» Structure Element
Attribute of a «Trust» Assessment
Capability
«Vulnerability» Capability
Goal
Assessment
Assessment connected to a Capability
Assessment connected to a «Vulnerability» Capability
Assessment connected to a Goal
«Risk» Driver
Assessment connected to a «Risk» Driver
Stakeholder connected to a Risk Assessment
«RiskExperience» Grouping
«ThreatEvent» Event
«LossEvent» Event
«HazardAssessment» Assessment
Modeling Trust in Enterprise Architecture
11
3.3 Combining the Patterns
To use TPL, a modeler may start with the application of the Trust Assessment Pattern to identify both the trustor and the trustee, as well as the goal of the trustor,
for the achievement of which she is counting on the trustee. Then, the user should
use the Trust Composition Pattern by iteratively applying the Capability Belief Pattern, the Vulnerability Pattern, and the Intention Belief Pattern (this latter only if the
trustee is an agent) in order to detail the components of trust: the capabilities, vulnerabilities, and intentions of the trustee, which are the focus of the trustor’s beliefs.
For each vulnerability and capability, the modeler should apply the Risk Experience
Pattern to identify the risks that can emerge when either the vulnerabilities are manifested or the capabilities are not manifested as expected (and in this case they play the
role of threat capabilities). Finally, for each risk driver identified, the user may apply
the Risk Assessment Pattern to evaluate the impact of risks and establish procedures
for effective risk control, treatment, and mitigation. As previously mentioned, from
this pattern it is possible to model the realization of control measures by describing
how the many pieces of an enterprise’s application and technology infrastructure work
together to properly manage risks that emerge from trust relations. Additionally, the
Trust Influencing Trust Pattern can be applied to make explicit how trust relations influence each other (for instance, Alice trusting an online store can influence her brother
trusting the online store too), as well as to characterize the existence of trust by delegation (for example, Alice trusts Bob, and Bob trusts an information source, then it
may be the case that Alice trusts the information source “by delegation”). The detailed diagrams presenting the complete process of combining the patterns can be found
https://purl.org/krdb-core/trust-archimate.
4 Case Study
In this section, we present a realistic study in which we use the TPL to model a case of
“misplaced trust” in a COVID-19 data repository, which resulted in the retraction of a
publication from a highly influential and prestigious medical journal. In particular, we
refer to the case of a recent study published in The Lancet journal [16], which relied
on data gathered by a US healthcare analytics company called Surgisphere to report
issues on the efficacy and safety of hydroxychloroquine (HCQ) for treating COVID-19.
When the study was first published it prompted the World Health Organisation (WHO)
along with several countries to pause trials on this drug. However, this very study was
retracted [17] a few days later (and the clinical trials resumed), as concerns were raised
with respect to the veracity of the data, leading the authors to recognize that they could
no longer vouch for the veracity of the database at the heart of the study. Examples of
problems encountered include errors in the Australian data and the fact that independent
reviewers could not verify the validity of the data, as Surgisphere would not give access
to the full dataset, citing confidentiality and client agreements [17].
Given the limited space available, we only present relevant fragments of the resulting model. The complete case study is available at https://purl.org/krdb-core/
12
Glenda Amaral et al.
trust-archimate. An investigation of the characteristics a COVID-19 data repository should have in order to be held in a position of trust by the communities they
intend to serve are presented in an accompanying technical report [2], available at the
above-mentioned URL.
We start with the application of the Trust Assessment Pattern to identify the trustees,
the trustors, and their goals. In our case study, different trust relations can be observed:
(i) the Publication Authors trust the COVID-19 data repository to evaluate the safety
and effectiveness of hydroxychloroquine for treatment of COVID-19; (ii) the Publication Authors trust the Surgisphere Staff about creating and maintaining the COVID-19
data repository; (iii) The Lancet trusts the Publication Authors to accept publishing
the study; (iv) WHO trusts The Lancet to have reliable information to make decisions
w.r.t. recommendations on the treatment of diseases; (v) WHO trusts (by delegation)
the Publication Authors to have reliable information to make decisions w.r.t. recommendations on the treatment of diseases; and (vi) Countries trust WHO to have reliable
recommendations on the treatment of diseases. Fig. 11a and 11b depict the modeling of
trust relations (i) and (ii), respectively.
(a)
(b)
Fig. 11: Application of the Trust Assessment Pattern
We proceed by iteratively applying the Capability Belief Pattern (Fig. 12a) and the
Vulnerability Belief Pattern (Fig. 12b) to detail the Publication Authors’ beliefs with respect to the COVID-19 data repository (trust assessment depicted in Fig. 11a). Finally,
in Fig. 13 we use the Trust Composition Pattern to detail the trust complex mental state
of the Publication Authors in their trust relation with the COVID-19 data repository.
Note that the capabilities and vulnerabilities which are the focus of the Publication Authors’ beliefs were identified based on the trust concerns for COVID-19 data presented
in [2], such as transparency, privacy of data, respect for human rights and data quality.
(a)
Fig. 12: Capability and Vulnerability Beliefs
(b)
Modeling Trust in Enterprise Architecture
13
Fig. 13: Composition
Since the components of trust are known, it is possible to reason about possible
manifestations of vulnerabilities and (threatening) capabilities of the COVID-19 data
repository, which can enable undesired events that threaten the Publication Authors’
abilities to achieve their goal.
Using the Risk Experience Pattern, we represent, in Fig. 14, the emergence of the
risk of “repository loss of credibility” caused by the poor quality of data (a vulnerability), which revealed errors in the data, thus preventing the authors from attesting the
validity of the study. Then we apply the Risk Assessment Pattern (Fig. 15) to represent
the evaluation of the risk of “repository loss of credibility” by the Surgisphere Staff, as
well as the establishment of procedures for effective risk control (improve data quality)
and the definition of a control measure that describes how Surgisphere plans to realize
these procedures (implement data quality management).
Fig. 14: Risk Experience
Fig. 15: Risk Assessment
Lastly, we use the Trust Influencing Trust Pattern to make explicit how some of
these trust assessments influence each other. In Fig. 16a we may observe that “WHO
14
Glenda Amaral et al.
trusting The Lancet”, positively influences “WHO’s trust in the Publication Authors”.
Similarly, the Publication Authors’ trust in the Surgisphere’s Staff expertise positively
influences their trust in the COVID-19 data repository (Fig. 16b). Note that as previously mentioned, this pattern can also be applied to characterize the existence of “trust
by delegation”. For example, considering that (1) “WHO trusts The Lancet” and (2)
“The Lancet trusts the Publication Authors”, there is a great chance that, (3) “WHO
trusts the Publication Authors” by delegation, and in this case both (1) and (2) positively influences (3).
(a)
(b)
Fig. 16: Trust Influencing Trust
5 Conclusions
In this paper we presented TPL, a pattern language for modeling trust in ArchiMate
that is based on ROT, a recently proposed ontology that provides clear real-world semantics for the constituting elements of trust and describes the emergence of risk from
trust relations. Although trust towards agents and resources is a known concern in the
literature, little has been said about what constitutes the stakeholders’ trust in a given
organization or resource, as well as how these trust concerns permeate the enterprise
architecture. The TPL was designed aiming at addressing these issues. In particular, it
allows to represent: (i) the elements that constitute the trust of an agent with respect to a
resource or another agent, including organizations; (ii) the capabilities and vulnerabilities of trustees that are the focus of the trustor’s beliefs, in a trust assessment; (iii) the
influence that trust assessments have on each other; (iv) the risks that can emerge from
trust relations; and (v) risk assessments related to these risk drivers.
This work is part of a long-term research program that aims at using UFO as a
semantic foundation for enterprise modeling (in particular, for ArchiMate). Next, we
envision that this effort can be harmonized with previous work (on value [20], risk
[18], service contracts [8], resources and capabilities [3]) to provide a comprehensive
ontology-based enterprise modeling approach. We also plan to conduct empirical experiments to validate the TPL. In addition, we want to further evolve the trust ontology
to allow the representation of “pieces of evidence” for trustworthiness, which comes
from elements such as a history of performance and trusted third party certifications.
Acknowledgments
CAPES (PhD grant 88881.173022/2018-01) and NeXON project (UNIBZ). João Paulo
A. Almeida is funded by the Brazilian National Council for Scientific and Technological
Development CNPq (grant 312123/2017-5).
Modeling Trust in Enterprise Architecture
15
References
1. Amaral, G., Sales, T.P., Guizzardi, G., Porello, D.: Towards a Reference Ontology of Trust.
In: International Conference on Cooperative Information Systems. pp. 3–21. Springer (2019)
2. Amaral, G., Sales, T.P., Guizzardi, G., Porello, D.: Trust Concerns for Digital Data Repositories: the COVID-19 Data Domain. Tech. rep., Free University of Bozen-Bolzano (2020)
3. Azevedo, C.L., Iacob, M.E., Almeida, J.P.A., van Sinderen, M., Pires, L.F., Guizzardi, G.:
Modeling resources and capabilities in enterprise architecture: A well-founded ontologybased proposal for ArchiMate. Information systems 54, 235–262 (2015)
4. Buschmann, F., Henney, K., Schmidt, D.C.: Pattern-oriented software architecture, on patterns and pattern languages, vol. 5. John Wiley & Sons (2007)
5. Castelfranchi, C., Falcone, R.: Trust theory: A socio-cognitive and computational model,
vol. 18. John Wiley & Sons (2010)
6. Deutsch, P.: Models and patterns. In: Software factories: Assembling applications with patterns, frameworks, models and tools. John Wiley & Sons (2004)
7. Falbo, R., Barcellos, M., Ruy, F., Guizzardi, G., Guizzardi, R.: Ontology pattern languages.
In: Ontology Engineering with Ontology Design Patterns: Foundations and Applications.
IOS Press (2016)
8. Griffo, C., Almeida, J.P.A., Guizzardi, G., Nardi, J.C.: From an ontology of service contracts
to contract modeling in enterprise architecture. In: Proc. 21st IEEE EDOC. pp. 40–49 (2017)
9. Guizzardi, G., Wagner, G., Falbo, R., Guizzardi, R., Almeida, J.: Towards Ontological Foundations for the Conceptual Modeling of Events. In: Proc. 32th Int. Conference on Conceptual
Modeling (ER). Lecture Notes in Computer Science, vol. 8217, pp. 327–341. Springer (2013)
10. Guizzardi, G.: Ontological foundations for structural conceptual models. Telematica Instituut
Fundamental Research Series, No. 15, ISBN 90-75176-81-3 (2005)
11. Guizzardi, G., Wagner, G., Almeida, J.P.A., Guizzardi, R.S.S.: Towards ontological foundations for conceptual modeling: the Unified Foundational Ontology (UFO) story. Applied
ontology 10(3-4), 259–271 (2015)
12. Hevner, A., Chatterjee, S.: Design science research in information systems. In: Design research in information systems, pp. 9–22. Springer (2010)
13. Luhmann, N.: Trust and power. John Wiley & Sons (2018)
14. Mayer, N., Feltus, C.: Evaluation of the risk and security overlay of ArchiMate to model
information system security risks. In: 2017 IEEE 21st International Enterprise Distributed
Object Computing Workshop. pp. 106–116. IEEE (2017)
15. McKnight, D.H., Chervany, N.L.: Trust and distrust definitions: One bite at a time. In: Trust
in Cyber-societies, pp. 27–54. Springer (2001)
16. Mehra, M.R., Desai, S.S., Ruschitzka, F., Patel, A.N.: RETRACTED: Hydroxychloroquine
or chloroquine with or without a macrolide for treatment of COVID-19: a multinational
registry analysis. The Lancet (May 2020)
17. Mehra, M.R., Ruschitzka, F., Patel, A.N.: Retraction—hydroxychloroquine or chloroquine
with or without a macrolide for treatment of COVID-19: a multinational registry analysis.
The Lancet 395(10240), 1820 (2020)
18. Sales, T.P., Almeida, J.P.A., Santini, S., Baião, F., Guizzardi, G.: Ontological analysis and
redesign of risk modeling in ArchiMate. In: 2018 IEEE 22nd International Enterprise Distributed Object Computing Conference. pp. 154–163. IEEE (2018)
19. Sales, T.P., Baião, F., Guizzardi, G., Guarino, N., Mylopoulos, J.: The common ontology of
value and risk. In: Proc.37th ER Conference. vol. 11157, pp. 121–135. Springer (2018)
20. Sales, T.P., Roelens, B., Poels, G., Guizzardi, G., Guarino, N., Mylopoulos, J.: A pattern
language for value modeling in ArchiMate. In: International Conference on Advanced Information Systems Engineering. pp. 230–245. Springer (2019)
21. The Open Group: ArchiMate 3.0.1 Specification. Standard C179 (2017)