=Paper=
{{Paper
|id=Vol-1829/iStar17_paper_13
|storemode=property
|title=A Semi-formal Evaluation of Architecture Design Based on Architecture Principles
|pdfUrl=https://ceur-ws.org/Vol-1829/iStar17_paper_13.pdf
|volume=Vol-1829
|authors=Diana Marosin,Sepideh Ghanavati
|dblpUrl=https://dblp.org/rec/conf/istar/MarosinG17
}}
==A Semi-formal Evaluation of Architecture Design Based on Architecture Principles==
https://ceur-ws.org/Vol-1829/iStar17_paper_13.pdf
A Semi-formal Evaluation of Architecture
Design Based on Architecture Principles
Diana Marosin1 , Sepideh Ghanavati2
1
Radboud University Nijmegen, Nijmegen, the Netherlands
2
Texas Tech University, Lubbock, TX, USA
marosin.diana@gmail.com, sepideh.ghanavati@ttu.edu
Abstract. Enterprise architectures (EA) and principles have been de-
fined multiple times in literature. The main focus is how architecture
principles help fulfilling organization’s goals. There is a consensus on the
guiding roles of principles and on the fact that architecture designs are
limited by them. However, there are no (semi-)formal methodologies to
truly evaluate the links between principles and design. There is also no
method to evaluate miss-alignments between principles and design or to
guide re-design in case the set of principles changes. In this paper, we
make initial steps towards a semi-formal method for traceability and con-
sistency checks between architecture principles and EA design. We aim
to provide a mechanism that supports overall change management of the
EA design when defining and refining the set of EA principles.
Keywords: architecture design, architecture principles, GRL
1 Introduction
In the current literature, there are multiple definitions for concepts such as “en-
terprise”, “enterprise architecture (EA)” and “enterprise architecture principles”.
The different definitions of “EA principles” are presented in multiple research
papers, and included in several literature studies such as [9, 5]. EA principles
are similar to non-functional requirements (NFR) however, they are widely ac-
cepted as a term in practitioners’ dictionary. Due to the similarities between EA
principles and NFR, we model principles with goal modeling languages.
In our research, we collaborate with multiple practitioners and use their case
studies. One important observation is that architecture models are static and
we cannot perform any formal analysis. To overcome this limitation, we intro-
duced a semi-formal framework, called Principles-based GRL [1], that is based
on Goal-oriented Requirements Language (GRL) [2]. By leveraging metadata
for stereotyping and graphical representation, we developed a methodology to
link principles to strategies and to evaluate their impacts [8]. We justified the
relationships with goals and vision of the organization and we provided ratio-
nales for design decisions. With the help of what-if analysis, we analyzed what
happens if EA principles support conflicting goals, if the set contains conflicting
principles or if some principles support only partially the goals.
In this paper, we focus on the influences EA principles exhibit on the design
of EA models. To that end, we aim to answer the following research question:
How to manage and evaluate the consistency between architecture principles
and architecture design models?
In past, there were some efforts to map EA designs with EA principles
through ArchiMate [6] and Motivation Model [4]. This mapping does not pro-
vide analysis of the consistencies, nor does it have a tool-support. In this work,
we model ArchiMate’s elements in Use Case Maps (UCM) which is part of the
User Requirements Notation (URN) [7] and it is combined with GRL. Modeling
architecture designs with UCM helps analyzing the consistency between the de-
sign and principles in a tool-supported manner (through URN links and scenario
analysis functionality of jUCMNav [3]) which is not possible with ArchiMate.
We introduce our approach and background assumptions, in Section 2. Next,
we present an extension of our framework with UCM elements, in Section 3.
We apply the extension and present an evaluation of a model in Section 4. We
conclude and present directions of future work in Section 5.
2 Background - Principle-based GRL Approach
Example - part 1: For a better understanding of the context of our work,
we present an extract from the set of EA principles defined and used by
“The Tax and Customs Administration” of a European country, further-on
called TaxAdministration. In definition of a high-level EA principle, “We
have an exclusive digital administration”, TaxAdministration defined four
Key Actions, as follows: [1] The information in digital administrations are
fast and trustworthy accessible where and when necessary for the work. [2]
We make applications either specific for mass, automatized administrative
processes or specific for activities that are focused on human interaction.
[3] Where we administer digitally we also archive digitally. [4] We take
measures so that the safety of our information is ensured.
Each Key Action is linked semi-formally to a different task or a (soft-)goal,
such that it supports the realization of higher level goals of the organization,
contributing to an Added Value. This situation is represented in Fig. 3. The
mapping of EA principles to GRL elements was tackeld in details in our frame-
work [8]. The mapping presented in Table 1 contains ontological elements exist
in the definition of EA principles. We defined stereotypes and OCL rules such
that we preserve the essence of principles while formally representing them with
GRL. This modeling effort results in the GRL model represented in Fig.3.
3 Framework Extension with UCM Scenarios
Example - part 2: In Section 2, we introduced an architecture principle of
TaxAdministration. This principle is an extract from Concern Architecture,
which contains a total of nine architecture principles and the corresponding
strategy for new tasks related to digitalization of the organization. We also
Table 1: Mapping architecture principles constructs to GRL Intentional Elements
(IE), adopted from [8].
EA principle el. Stereotype value GRL IE
Name Principle Softgoal ( )
Added value AddedValue Softgoal, Goal ( )
Impact/restrictions - Qual. / quant. value of GRL links.
Key actions KeyAction Task ( )
Preconditions Precondition Softgoal, Goal, Task, Resource ( )
investigated Fundamental Architecture for Online Services. This document
is a specialization of Concern Architecture and provides guidelines and pat-
terns on how to design and implement provisioning of online services. The
representation is textual or modeled by ArchiMate.
In TaxAdministration’s architecture documents, the architecture instruc-
tions, such as Provide Personal Information, describe which functions are
recognized and which data are needed for implementation.
After modeling and formalizing EA principles with GRL, we focus on ana-
lyzing how the impact of EA principles can be propagated to the design layer.
We select one of the major architecture languages, ArchiMate - a graphical lan-
guage, which offers an integrated way to describe and visualize different archi-
tecture layers, their relations and dependencies. We exploit the traceability links
between GRL and UCM to perform different types of analysis such as check-
ing the consistency between EA principles and EA design models. GRL aims at
capturing business or system goals, alternative decisions and rationales behind
goals while UCM models functional and behavioral structures using scenarios.
In the remaining of this paper, we show how to model ArchiMate models with
UCM and present an informal analysis of the resulted models.
Guidelines for Translating ArchiMate Models to UCM
We consider a scenario complete when all elements from ArchiMate were modeled
with UCM elements. Therefore, we define the following rules: [R1] Choose an
element from ArchiMate model and add it to the UCM scenario as a start-point.
[R2] Concurrent behaviors retrieved from ArchiMate models are represented
using UCM AND-fork. [R3] The mapping is complete when all elements and
relations from ArchiMate were handled. Mark in UCM with end -point. [R4]
Unite all paths resulted in the UCM scenario with an AND-joint.
In ArchiMate, the relation arrows go both in and out an ArchiMate node,
however we create a directed UCM path between the start and the end point.
To that end, we advise to have only arrows that exit from parents-nodes. To
preserve the semantics of relations such as realize or used by from ArchiMate,
we rephrase these relations in UCM. An example is represented in Fig. 1. We
276 A. Pourshahid et al.
define the following mapping rule and a set of stereotypes, corresponding to each
relation type: [R5] Create directed paths in UCM.
276 A. Pourshahid et al.
Fig. 2 Subset of GRL notation
Fig. 2 Subset of GRL notation Fig. 2 Subset of GRL notation
Table 2: Translating ArchiMate Elements to UCM Elements and Stereotypes
ArchiMate Element UCM Element / Stereotype
Function Service Responsibility
Fig. 2 Subset of GRL notation
Service Function
Object Object Object
Used by Direction arrow
Access Fig. 3 Subset of UCM notation uses access
Architecture layer Component
More complex business process modeling languages exist, but a combined view
of goals and processes and traceability features between them are unique capabilities
of URN. Moreover, URN provides the ability to align business goals and business
processes by adopting design experts’ business knowledge and experience [37].
GRL supports an evaluation mechanism that lets users define sets of initial sat-
isfaction values (Fig. 2c) on chosen intentional elements (Fig. 2a) in a GRL model
(called strategies).
Fig. 3Those
Subsetvalues
of UCMare propagated to the other intentional elements in
notation
the model via their contribution, correlation, decomposition, and dependency links
(Fig. 2b), up to the highest level goals [54, 55]. Contribution and correlation links
More complex business process modeling languages exist, but a combined view
of goals and processes and traceability features between them are unique capabilities
of URN. Moreover, URN provides the ability to align business goals and business
processes by adopting design experts’ business knowledge and experience [37].
GRL supports an evaluation mechanism that lets users define sets of initial sat-
isfaction values (Fig. 2c) on chosen intentional elements (Fig. 2a) in a GRL model
(called strategies). Those values are propagated to the other intentional elements in
the model via their contribution, correlation, decomposition, and dependency links
(Fig. 2b), up to the highest level goals [54, 55]. Contribution and correlation links
(a) ArchiMate used by relation (b) UCM uses relation
Fig. 3 Subset of UCM notation
Fig. 1: Comparison between ArchiMate’s used by and UCM’s uses relations
Fig. 3 Subset of UCM notation
More complex business process modeling languages exist, but a com
of goals and processes and traceability features between them are unique
of URN.
MoreMoreover,
complex URNbusinessprovides themodeling
process ability tolanguages
align business
exist,goals
but aa
In UCM, a responsibility is defined as a scenario activity
processes
representing some-
of goalsbyandadopting
processesdesign
and experts’ business
traceability knowledge
features betweenand themexperien
are un
thing to be performed: operation, action, task, function, ofGRLetc.
URN. [7]. an
supports Therefore,
Moreover, evaluation mechanism
URN provides that lets
the ability users business
to align define sets o
goa
ArchiMate behavioral elements are modeled with UCM following
isfaction
processes rules
values
by 6-8:
(Fig.
adopting [R6]
2c)design
on chosen intentional
experts’ elements
business knowledge (Fig.and
2a)exper
in a
(called
GRL supportsThose
strategies).
Functions and services from ArchiMate are modeled as responsibilities an UCM.
in values aremechanism
evaluation propagatedthatto the
letsother
usersintentional
define se
[R7] Objects in ArchiMate are translated to objects in theUCM.model[R8]
isfaction via their
values contribution,
(Fig.
Each correlation,
2c) on chosen
archi- decomposition,
intentional elements (Fig.and depen
2a) i
(Fig. 2b), strategies).
(called up to the highest
Those level
valuesgoals [54, 55]. Contribution
are propagated to the otherand corr
intentio
tecture layer is represented by a UCM component.
the model via their contribution, correlation, decomposition, and de
(Fig. 2b), up to the highest level goals [54, 55]. Contribution and c
4 (Re)Evaluation of Design by Combining Principle-based
GRL with UCM
Considering the EA principle represented in GRL in Fig.3 and the UCM scenario
represented in Fig.2, we manually identify and create URN links between the
two models. Note that, in a real cases, there are multiple EA principles at hand
and a considerable higher number of EA designs. In our example, using just
one instance of each concept, we can (at best) analyze the impact partially.
Furthermore, the URN links and the evaluation are done a-posteriori. In reality,
this tasks would be performed a-priori by enterprise architects, alongside the
management board or involved stakeholders.
• We traced “We archive digitally” KeyAction from the principle’s goal
model (see Fig.3) to service “Archive message” Service on the information
layer of the architecture (see Fig. 2). The execution of this service increases the
Fig. 2: Mapping of a Partial Architecture Model to a UCM Scenario
satisfaction level of the “We archive digitally” KeyAction intentional element,
from an unknown value to satisfied (see Fig.3).
• We identified a link between “Measures to ensure safety of our information”
KeyAction (see Fig.3) to “Verify access” Service (see Fig. 2). We consider
this action beneficial, but not enough. In general more actions can contribute to
the realization of a goal. In our example, we notice, we can improve the GRL
evaluation from an unknown value to a weakly satisfied. This represents a positive
increase of 25% from the initial evaluation.
URN provides guidelines for mapping GRL and UCM . We leverage these
guidelines to provide the mapping between the Principle-based GRL and the
extended UCM. However in future, we plan to perform an extensive analysis to
better evaluate this mapping and provide better guidelines for traceability.
5 Conclusions
In the case of TaxAdministration, organization does not perform formal checks
to assess if the EA models are in line with their EA principles. There are docu-
ments of architecture, connections between principles and goals, or refinements
of principles, however, they are based on experience and observations.
In this paper, we proposed a method to link design solutions to EA princi-
ples. ArchiMate models cannot be executed. Consequently, it is impossible to
automatize the check of actual behavior vs. the expected behavior foreseen by
applying principles. By means of URN links, we are enabled to evaluate the
efficiency of using and introducing a specific EA principle and to measure the
(partial) compliance between EA principles and the implementation of architec-
ture. Our approach provides a-posteriori evaluation, based on our interpretation,
therefore, the real impact is still not fully perceivable. For future work, we aim
to analyze the difficulty to translate the EA models using Principle-based GRL
framework, and reason about the impact in the design phase. The complexity of
models has to be evaluated keeping in mind the added value of the new models.
Fig. 3: Evaluation of EA Principle based on Execution of Receive Request.
Acknowledgements: We thank Saco Bekius and Michiel Borges for their col-
laboration and insights in the case study and our colleagues Marc van Zee and
Erik Proper, for fruitful discussions and insights prior to this publication.
References
1. Principle-based GRL Fw. - https://github.com/RationalArchitecture/eGovernment.
2. D. Amyot, S. Ghanavati, J. Horkoff, G. Mussbacher, L. Peyton, and E. Yu. Eval-
uating goal models within the goal-oriented requirement language. Int. J. Intell.
Syst., 25(8):841–877, Aug. 2010.
3. D. Amyot et al. Towards advanced goal model analysis with jucmnav. In ER
Workshops, volume 7518 of LNCS, pages 201–210. Springer, 2012.
4. F. J. Armour, S. H. Kaisler, and S. Y. Liu. A big-picture look at enterprise archi-
tectures. IT Professional, 1(1):35–42, 1999.
5. M. K. Haki and C. Legner. New Avenues for Theoretical Contributions in Enterprise
Architecture Principles - A Literature Review. In TEAR/PRET, volume 131 of
Lecture Notes in Business Information Processing, pages 182–197, 2012.
6. M.-E. Iacob, H. Jonkers, M. M. Lankhorst, H. A. Proper, and D. A. C. Quartel.
ArchiMate 2.0 Specification. The Open Group, 2012.
7. ITU-T. Recommendation Z.151 (11/08): User Requirements Notation (URN) –
Language Definition. http://www.itu.int/rec/T-REC-Z.151/en, 2008.
8. D. Marosin, M. van Zee, and S. Ghanavati. Formalizing and Modeling Enterprise
Architecture (EA) Principles with Goal-Oriented Requirements Language (GRL).
In Proceedings of CAiSE 2016, Ljubljana, Slovenia, June 13-17.
9. D. Stelzer. Enterprise Architecture Principles: Literature Review and Research
Directions. In ICSOC/ServiceWave Workshops, LNCS, pages 12–21, 2009.