Enterprise architectures (EA) and principles have been dened multiple times in literature. The main focus is how architecture principles help ful lling 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 consistency checks between architecture principles and EA design. We aim to provide a mechanism that supports overall change management of the EA design when de ning and re ning the set of EA principles.
In the current literature, there are multiple de nitions for concepts such as
\enterprise", \enterprise architecture (EA)" and \enterprise architecture principles".
The di erent de nitions of \EA principles" are presented in multiple research
papers, and included in several literature studies such as [
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
introduced a semi-formal framework, called Principles-based GRL [
In this paper, we focus on the in uences 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 e orts to map EA designs with EA principles
through 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
Example - part 1: For a better understanding of the context of our work,
we present an extract from the set of EA principles de ned and used by
\The Tax and Customs Administration" of a European country, further-on
called TaxAdministration. In de nition of a high-level EA principle, \We
have an exclusive digital administration", TaxAdministration de ned four
Key Actions, as follows: [
Each Key Action is linked semi-formally to a di erent 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
framework [
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 investigated Fundamental Architecture for Online Services. This document is a specialization of Concern Architecture and provides guidelines and patterns 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 instructions, 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 analyzing how the impact of EA principles can be propagated to the design layer. We select one of the major architecture languages, ArchiMate - a graphical language, which o ers an integrated way to describe and visualize di erent architecture layers, their relations and dependencies. We exploit the traceability links between GRL and UCM to perform di erent types of analysis such as checking 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 de ne 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 Function
A.Pourshahidetal. de ne the following mapping rule and a set of stereotypes, corresponding to each relation type: [R5] Create directed paths in UCM.
276
A.Pourshahidetal. More complex business Cproceoss mmodelping olangnuagees nexistt, 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 satisfaction values (Fig. 2c) on chosen intentional elements (Fig. 2a) in a GRL model (cal ed strategiFeisg).3ThSuobsetvoaflUuCesManroetaptiroonpagated 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
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 satisfaction values (Fig. 2c) on chosen intentional elements (Fig. 2a) in a GRL model (cal ed 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 ArchiMate behavioral elements are modeled with UCM fisofplalrcootiwcoenisnsvegaslubreuyslae(dFsoigp6.t-i2n8cg:)d[oRensi6cghn]oesxepneirntste’nbtuiosninaelseslekmnoewntlsed(Fgieg.an2da)eixnpea Functions and services from ArchiMate are modeled as r(ceaslpleGodnRsstLriabsteiulgpiitpeiose)r.stsTiahnnosUeevCavlaMuluaet.isonarempercohpaangisamtedthtoatthleetsotuhseerrsindteenfitnioensa [R7] Objects in ArchiMate are translated to objects in tUheiCsfmaMcotd.ioel[nRvviaa8lu]theEesira(Fcciohgn.tar2ircbc)uhtoiion-nc,hcoosrernelaintitoenn,tidoencaolmelpeomsietinotns,(aFnigd. d2eap)e tecture layer is represented by a UCM component. (F(igca.l2lebd),sutrpatteogtihees).hiTghhoesset lveavleulegsoaarles p[5ro4p,a5g5a]t.eCdotnotrtihbeutoiothneranindtecnotri the model via their contribution, correlation, decomposition, and d (Fig. 2b), up to the highest level goals [54, 55]. Contribution and 4 (Re)Evaluation of Design by Combining Principle-based
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"
from the principle's goal model (see Fig.3) to service \Archive message"
on the information layer of the architecture (see Fig. 2). The execution of this service increases the satisfaction level of the \We archive digitally" KeyAction intentional element, from an unknown value to satis ed (see Fig.3).
We identi ed 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 bene cial, 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 satis ed. 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
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 documents of architecture, connections between principles and goals, or re nements of principles, however, they are based on experience and observations.
In this paper, we proposed a method to link design solutions to EA principles. 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 e ciency of using and introducing a speci c EA principle and to measure the (partial) compliance between EA principles and the implementation of architecture. 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 di culty 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. Acknowledgements: We thank Saco Bekius and Michiel Borges for their collaboration and insights in the case study and our colleagues Marc van Zee and Erik Proper, for fruitful discussions and insights prior to this publication.