=Paper=
{{Paper
|id=None
|storemode=property
|title=Embracing Imperfection in Enterprise Architecture Models
|pdfUrl=https://ceur-ws.org/Vol-1023/paper1.pdf
|volume=Vol-1023
|dblpUrl=https://dblp.org/rec/conf/ifip8-1/FlorezSV13
}}
==Embracing Imperfection in Enterprise Architecture Models==
https://ceur-ws.org/Vol-1023/paper1.pdf
Embracing Imperfection in Enterprise
Architecture Models
Hector Florez, Mario Sánchez, and Jorge Villalobos
Department of Systems and Computing Engineering,
Universidad de los Andes,
Bogotá, Colombia
{ha.florez39,mar-san1,jvillalo}@uniandes.edu.co
Abstract. In Enterprise Architecture (EA) projects, models are built
to represent business and Information Technologies (IT) elements, and
to abstract the relation between them in one enterprise under study. The
construction of EA models depends on information provided by different
kinds of sources, but sources could be insufficient or information could
be incomplete or incorrect regarding aspects of the enterprise. As a re-
sult, modelers must often create models based on low quality information
that could not properly represent the enterprise. Since EA models are
used as the base for the analysis of the enterprise, using models that
do not represent the enterprise correctly, there is a risk that the analysis
produces unreliable conclusions. This paper presents a proposal for man-
aging imperfect models in the EA context. An imperfect model is capable
of representing information that can be imprecise, inconsistent, vague,
uncertain, or incomplete; thus, when analyses are performed, they can
use this information to produce more reliable results. In this proposal,
imperfect models also include information about modeler decisions.
Keywords: Enterprise Architecture, Model Driven Engineering, Models
Imperfection
1 Introduction
Enterprises increasingly depend on Information Technologies (IT) and require
support in order to achieve their business goals. Moreover, the enterprise com-
plexity and constant evolution generate difficulties in the relation between the
business and IT. EA projects require the construction of one model that we call
enterprise architecture model (mEA ), which is an abstract representation of one
simplification [1, 2] of the enterprise that includes enterprise elements and their
relations. The mEA is usually big because enterprises have a large number of
elements and is complex because they have a large number of typed relations
between their elements. One mEA is built by modelers through direct and in-
direct observation. Direct observation is the action in which modelers obtain
enterprise information without consulting sources. Indirect observation requires
the participation of sources (e.g., persons, documents, and meetings). In an EA
project, the mEA is used to analyze the enterprise. These analyses are performed
by domain experts called analysts, who manipulate the mEA in order to extract
useful information for evaluating the current state of the enterprise.
The model construction process is an observation of human process, sources
consulting, interpreting, and expression [3], so the construction of one mEA that
properly represents the enterprise has a high level of difficulty. The difficulty is
based on two main reasons: (1) the enterprise size and complexity and (2) several
uncontrolled factors that affect the modeling process [4] such as sources quality
and lack of information. Quality refers to the knowledge level of the sources on
specific aspects of the enterprise. Lack of information refers to the incapabil-
ity of the source for providing information on some aspects of the enterprise.
Because of this, in some cases it is impossible to build an mEA that correctly
represents the enterprise. For instance, consider the case where a model will be
used to document the business applications of an enterprise, and analyze their
availability. Then, one employee may assert that the availability (that must be
a number) of the BusinessApp X is between 92% and 95%, and the availavility
of the BusinessApp Y is High. The modeler must choose one numeric value for
the BusinessApp X between 92% and 95%, and a numeric value for the Busi-
nessApp Y that must be high (up to 100 in this case). In any cases, the values
selected by the modeler do not represent the enterprise correctly because he/she
cannot know the appropiate value. Later on, the analyst will use the model to
perform an analysis of the enterprise; however, since he/she will be using a mEA
that might not represent some enterprise elements or relations correctly; in such
case, the results should not be considered very reliable.
Model imperfection is inevitable in EA projects. Then, it is better to include
information in the model to represent those problems than to ignore them and
to assume that the model accurately represents the enterprise. Modeling the
imperfection implies creating another model that we call imperfect enterprise
architecture model (mζ ), which is an approximation of the mEA with informa-
tion that can assess the imperfection. Thus, there is a distance between mζ and
mEA and the modeler must build the best possible approximation given the
quality of the available information. To establish the level of the information
validity, the imperfect information should be related with sources that provide
the information. In the construction process of the mζ , modelers consult sources
through observations (e.g., interviews, reviews, meeting acts, etc.) where each
observation provides facts. Through these facts, modelers make decisions to as-
sign values for imperfect attributes and relations. Finally, based on the mζ , it is
possible to create analysis methods while taking into account the imperfection.
The rest of the paper is structured as follows. Section 2 describes the modeling
process in the EA context. Section 3 presents our proposed taxonomy of imper-
fect sources, where we classify sources based on the quality of the information
provided. In section 4, we present our proposal for modeling the imperfection in
EA projects based on the sources classification. In section 5, we present our tool
for modeling imperfection and creating the mζ . In section 6 we present modeling
imperfection involving traces about decision making by modelers, for imperfect
attributes and relations. Finally, section 7 presents the conclusions.
2 Construction of Enterprise Architecture Models
In EA projects, it is necessary to construct one domain metamodel that we
call enterprise architecture metamodel (MMEA ) representing the concepts of
the enterprise and the relations between them. Those concepts are typed ele-
ments which contain structural features. The MMEA is different for each specific
project, since it reflects the horizontal and vertical scope for the project. In this
paper, we assume that MMEA is correct and never changes during the project.
Normally, the mEA must conform to the MMEA . The mEA is made up of
several instances (Γ = {γ 1 , γ 2 , . . . , γ p }) that conform to the correspondent
typed elements of MMEA . Each instance in Γ contains several structural features
(Φγ i = {ϕγ i ,1 , ϕγ i ,2 , . . . , ϕγ i ,q }), which can be attributes (Aγ i = {αγ i ,1 , αγ i ,2 ,
. . . , αγ i ,r }) or typed relations (Bγ i = {β γ i ,1 , β γ i ,2 , . . . , β γ i ,s }). The conformance
relation between mEA and MMEA establishes that Φγ i must respect the types
and structures defined for each metatype in MMEA . However, if modelers build
one mζ instead of one mEA , this mζ does not conform to MMEA .
The mζ can include imperfect information, where the modeler can decide
which attributes or relations are imperfect. To build the mζ , we use the dis-
tinction between ontological conformance that is based on the relation between
the model and metamodel in terms of their meaning, and linguistic conformance
that is based on the relation between the model and metamodel in terms of
their structure [5]. In addition, we achieve the linguistic conformance by the
construction of a generic intermediate metamodel that serves to represent any
type, attribute and relation; and the ontological conformance by the definition
of semantic rules [6]. Then, the mζ allows the creation of instances of a type
with regular or imperfect structural features. One structural feature is imperfect
regarding the MMEA , when its value does not adjust with the characteristics
established in the MMEA .
Figure 1 illustrates the proposed strategy. The mζ conforms linguistically
to one generic metamodel called Extended Metamodel of Imperfection (EiMM)
that serves to represent any type, attribute and relation, where attributes and
relations can be imperfect. The mζ does not conform ontologically to the MMEA
because attributes and relations of instances of the same metatype can have
different characteristics. We say that the mζ semi-conforms ontologically to the
MMEA . We introduce the ontological semi-conformance concept as the relation
between the mζ and the MMEA in which the mζ can include instances of the
metatypes in the MMEA , but the instances’ structural features can be imperfect
and may change some of their features. Given this, we can say that the mζ is an
approximation of the mEA . Furthermore, mζ also includes decision trace infor-
mation about the decisions that led to the construction of the imperfect model.
Decision trace information is related with sources that provide information about
aspects of the enterprise, observations that are the activities in which the mod-
eler can collect enterprise information, and decision details. This decision trace
information is structured through the EiMM that has types to represent all el-
ements involved in the decision making process. As a result, the mζ conforms
linguistically to EiMM and semi-conforms ontologically to the MMEA .
MMEA EiMM
sem Ont
Ontological i-c olog
on Linguistic
& Linguistic for ical conformance
ma
conformance nc
e
mEA approximationOf mζ
Fig. 1. Strategy for Modeling imperfection.
3 Sources of Enterprise Information
In the construction process of one model, modelers must consult enterprise
sources (Ψ = {ψ 1 , ψ 2 , . . . , ψ r }). One source ψ i provides information to modelers
through Observations (Θψi = {θψi ,1 , θψi ,2 , . . . , θψi ,s }). One observation θψi ,j
produces some knowledge about enterprise elements that we call Facts (Ω θψi ,j
= {ω θψi ,j ,1 , ω θψi ,j ,2 , . . . , ω θψi ,j ,t }). Each fact ω θψi ,j ,k provides information about
instances, attributes, or relations, for building the model.
Enterprise sources could be imperfect because they can provide information
that does not properly represent some elements of the enterprise. We classify
sources based on the properties of the information provided as incorrect [4],
imprecise [4, 7, 8, 9], inconsistent [10, 11], vague, uncertain [7, 12, 13] or a
combination of some of them. In addition, it is possible that one source, which
should provide information, cannot provide information about one structural
feature. Then, the corresponding observation will not produce any fact. In this
case, we classify the observation as an incomplete observation.
Incorrect source. One source ψ i is incorrect when one observation θψi ,j
over one structural feature ϕγ k ,l establishes a fact ω θψi ,j ,k that provides a value
that is not true or is not usable.
Imprecise source. One correct source ψ i is imprecise when one observation
θψi ,j over one attribute αγ k ,l that requires a specific numeric value, provides a
range of numeric values with a minimum numeric value (vmin ) and a maximum
numeric value (vmax ) (e.g., the CTO (ψ i ) in one interview (θψi ,j ) asserts that
the availability (ϕγ k ,l ) of the BusinessApp X (γ k ) is between 90% and 95%).
Inconsistent source. There are the following cases in which one source ψ i
or several sources {ψ 1 , ψ 2 , . . . , ψ r } can be inconsistent.
Case A. Several sources {ψ 1 , ψ 2 , . . . , ψ r } are inconsistent when one observation
of each source {θψ1 ,i , θψ2 ,j , . . . , θψr ,k } about the same aspect of the enterprise
determines that one instance γ l exists; however, some other observations deter-
mine that the instance γ l does not exist.
Case B. Several sources {ψ 1 , ψ 2 , . . . , ψ r } are inconsistent when one obser-
vation of each source {θψ1 ,i , θψ2 ,j , . . . , θψr ,k } provides different values for one
structural feature ϕγ k ,l (e.g., the CIO (ψ 1 ) in one interview (θψ1 ,i ) asserts that
the availability (ϕγ k ,l ) of the BusinessApp X (γ k ) is 92%, and the CTO (ψ 2 ) in
one interview (θψ2 ,j ) asserts that the availability is 95%).
Case C. One source ψ i is inconsistent when several observations {θψi ,1 , θψi ,2 ,
. . . , θψi ,s } provide different values for one structural feature ϕγ k ,l . (e.g., the
CTO (ψ i ) in one interview (θψi ,1 ) asserts that the availability (ϕγ k ,l ) of the
BusinessApp X (γ k ) is 90%, but in other interview (θψi ,2 ) asserts that is 92%).
Vague source. Vague sources are those that provide one linguistic value
among a set of linguistic values Ξ ϕγ k ,l = {ξ ϕγ k ,l ,1 , ξ ϕγ k ,l ,2 , . . . , ξ ϕγ k ,l ,n } for one
specific attribute αγ k ,l . One correct source ψ i is vague when one observation θψi ,j
provides a linguistic value to one attribute αγ k ,l that requires one specific numeric
value (e.g., the CTO (ψ i ) in one interview (θψi ,1 ) asserts that the availability
(ϕγ k ,l ) of the BusinessApp X (γ k ) is “High” (ξ ϕγ k ,l ,r )).
Uncertain source. One source ψ i is uncertain when one observation θψi ,j
over one structural feature ϕγ k ,l that requires a specific value, determines that
it can have a value with a certainty degree. The value with a certainty degree
must be a combination of a value with a probabilistic value ([v, P(v)]). (e.g., the
CTO (ψ i ) in one interview (θψi ,j ) asserts that the BusinessApp X (γ k ) supports
(ϕγ k ,l ) the BusinessProcess A with a certainty degree of 80%).
Incomplete observation. One observation θψi ,j of one source ψ i that
should provide information is incomplete when the observation’s facts do not
have any value for one structural feature γ l that requires a specific value. Con-
sequently, the value of the structural feature is indeterminated .
4 Modeling the Imperfection
Modeling the imperfection implies allowing the construction of approximate
models instead of exact models regarding MMEA . Then, the modeler does not
build a mEA , but builds a mζ . Given the facts obtained from one or several
sources {Ω Θψ1 , Ω Θψ2 , . . . , Ω Θψr }, modelers have to make decisions in order to
assign values to the model’s structural features. There is a set of possible deci-
sions (Λ={λ1 , λ2 , . . . λu }) based on the information provided by the sources.
Some examples of the decisions that the modeler can make are the following.
λ1 : Select all the values; λ2 : Select a subset of the values; λ3 : Select one value;
λ4 : Select one value with a certainty degree; λ5 : Select several values with a
certainty degree; λ6 : Select a range of numeric values; λ7 : Select one linguistic
value; λ8 : Calculate one value; λ9 : Do not select a value.
Decisions λ3 or λ8 can be used to remove the imperfection, but this means
losing information and potentially creating an incorrect model with respect to the
enterprise (e.g., the CTO (ψ i ) in one interview (θψi ,j ) asserts that the availability
(ϕγ k ,l ) of the BusinessApp X (γ k ) is between 90% and 94%, but the modeler
decides assigning the value 92%). To be able to model the imperfection, it is
necessary to model the imprecision, inconsistency, vagueness, uncertainty, and
incompleteness.
Imprecise model. One model is imprecise if at least one attribute of one
instance has a range of numeric values instead of a single value. The range is
given by a minimum value and a maximum value instead of just one value. The
modeler can build an imprecise model due to the sources are imprecise (decision
λ6 ), or inconsistent cases B or C (decision λ6 ).
Inconsistent model. One model is inconsistent if at least one structural
feature of one instance has several values instead of just one value. The modeler
can build an inconsistent model due to the sources are imprecise (decision λ2 ),
or inconsistent cases B or C (decisions λ1 or λ2 ).
Uncertain model. One model is uncertain if at least one structural feature
ϕγ k ,l of one instance γ k has a value, a set of values, or a range of values with a
certainty degree. The modeler can build an uncertain model due to the sources
are imprecise (decisions λ4 or λ5 ), inconsistent cases B or C (decisions λ4 or
λ5 ), or uncertain (decision λ4 ).
Vague model. One model is vague if the modeler decides to asign a linguistic
value instead of a numeric value to one attribute of an instance. The modeler can
build a vague model due to the sources are imprecise (decision λ7 ), inconsistent
cases B or C (decision λ7 ), uncertain (decision λ7 ), or vague (decision λ7 ).
Incomplete model. One model is incomplete if at least one instance’s struc-
tural feature does not have any value. It might happen because the modeler de-
cided not to assess any value because he/she does not have enough information.
5 A Tool for Modeling Imperfection
In order to achieve modeling imperfection, this proposal includes a tool to build
imperfect models (mζ ). This tool is a graphical editor named iModeler based on
GraCoT (Graphical Co-Creation Tool) presented in Gomez et al. [6]. The editor
is based on one metamodel named iMM (Metamodel of Imperfection).
5.1 Metamodel of Imperfection iMM
iMM provides a basic linguistic framework for the definition of imperfect models
(mζ ). Figure 2 presents iMM. This metamodel has the type called Model, which
serves as container for all other elements. The type Element serves to represent
Fig. 2. Metamodel of Imperfection iMM.
the element instances of the imperfect model. Each element in a model has an at-
tribute called typeName that serves to relate the element to a type in the MMEA .
The types CrossRelation and ContaintmentRelation serve to represent the
relations between elements. The type Attribute serves to represent the actual
values of attributes contained in elements of the mζ . Attribute values may only be
integers, doubles, strings, booleans, or dates. The types ImperfectAttribute,
ImperfectCrossRelation, and ImperfectContainmentRelation serve to rep-
resent, respectively, imperfect attributes and relations. Imperfect attributes may
contain a range of numeric values, a set of numeric values, a set of strings, a set
of numeric values with a certainty degree, a set of strings with a certainty degree,
a linguistic value, or no value. Imperfect cross and containment relations may
contain an instance relation with certainty degree or a set of instance relations.
5.2 iModeler Editor
The strategy described in section 2 has been implemented in a graphical editor
based on Eclipse Modeling Framework Project (EMF) and Graphical Modeling
Project (GMP) named iModeler. In addition, for the creation of iModeler, the
project EuGENia was used in order to create the required GMP’s components.
iModeler serves to create imperfect models (mζ ) that conform to iMM. This edi-
tor is also capable of validating the ontological semi-conformance of the mζ with
respect to a MMEA providing assistance to the user. The mζ has the appearance
of an object diagram from UML (see Figure 3b), where each instance displays
its metatype from the MMEA , its attributes, and its relations. Imperfect at-
tributes are decorated with a black rounded square. Imperfect containment and
cross relations have respectively a filled and unfilled square in the side of the
source. Another important characteristic of iModeler is the way it handles prob-
lems. This is achieved using EMF’s validation elements, and our own validation
engine based on Epsilon Validation Language (EVL)
For example, the MMEA presented in Figure 3a has the types Enterprise,
BusinessApplication, and BusinessProcess. In the construction of the mζ ,
a)Metamodel
b)Imperfect model
Fig. 3. Enterprise modeling example.
the modeler decides to include imperfection in some attributes and relations.
The mζ (see Figure 3b) conforms linguistically to iMM and semi-conforms on-
tologically to MMEA . It has the following instances: 1) Enterprise as instance
of Element that contains all elements in the mζ ; 2) BusinessApplication
that represents the application bApp X, created by the containment relation
applications with the imperfect attribute availability with the range of
values [95,98] ; 3) BusinessApplication that represents the application bApp Y
with the imperfect attribute and relation: a) availability with the linguistic
value , and b) supports with the instance that represents the process
bProc B ; 4) BusinessProcess that represents the process bProc A, created by
the containment relation processes; and 5) BusinessProcess that represents
the process bProc B. This example demonstrates several kinds of imperfection.
In bApp X, the attribute availability is imprecise; in bApp Y, the attribute
availability is vague, and the relation supports is uncertain.
6 Decision Trace on Imperfect Models
Modelers can include decision trace information into the mζ in order to represent
the way in which the information was gathered, and the decisions to construct the
model were made. The trace includes the enterprise sources, source consulting
through observations, facts produced by observations, and decisions related with
imperfect attributes or imperfect relations of the mζ .
In order to include all elements described above, we complemented the iMM
creating one metamodel named Extended Metamodel of Imperfection (EiMM)
(see Figure 4) for our tool iModeler ; thus, the mζ now conforms linguistically
to EiMM, The EiMM includes all elements presented in iMM and the following
additional types: 1) ModelExtension serves as container for all other additional
elements; 2) Source and its specializations DirectObservation, Document,
Fig. 4. Extended Metamodel of Imperfection EiMM.
Fig. 5. Extended Imperfect Model Example.
Meeting, and Person serve to represent sources; 3) Observation serves to rep-
resent interviews, document revisions, and meeting acts; 4) Fact and its spe-
cializations InstanceFact, AttributeFact, and RelationFact serve to create
registers of information obtained about instances, attributes, or relations of the
enterprise; and 5) Decision serves to specify the decision made by modelers
for imperfect attributes or relations. By means of the EiMM, iModeler allows
modelers to include all necessary decision trace information into the mζ .
Continuing the example presented in the previous section, the modeler de-
cides to include decision traces for the attribute availability of the bApp X
and for the relation supports of the bApp Y. Then, the modeler does an inter-
view to the CTO named “Peter R”, who asserts that the availability of bApp X
is 95%. However, in an interview to the CIO named “John Q”, the information
obtained is that bApp Y supports bProc B with a certainty degree of 80% and
the availability of bApp X is 98%. Consequently, the mζ includes the follow-
ing trace elements: 1) one instance of the type ModelExtension to include all
decision trace elements; 2) two instances of the type Person with information
about the CTO and the CIO; 3) two instances of the type Observation with the
information of the interviews; 4) two instances of the type AttributeFact that
specifies the availavility of bApp X ; 5) one instance of the type RelationFact
that relates the bApp Y with the bProc B ; and 6) two instances of the type
Decision with the results of the decisions made by the modeler for the im-
perfect attribute availability and the imperfect relation supports. Figure 5
represents the imperfect model with decision trace of the example.
7 Conclusions
In the Enterprise Architecture context, models are built using information pro-
vided by various and heterogeneous sources. These sources usually do not have
perfect information, so enterprise models might not represent the enterprise cor-
rectly; thus, analysis results based on the mentioned models can be incorrect.
Imperfect models represent and structure imperfect information while en-
abling modelers to keep all the information provided by sources about the el-
ements’ attributes and relations. Modelers can also include decision trace in-
formation. Based on the imperfect information and decision trace information,
analysts can perform better analysis processes with a higher level of reliability.
The solution strategy presented in this paper represents the imperfection in
EA models based on the creation of models that conform linguistically to EiMM
and semi-conform ontologically with the MMEA . The mζ is created using the
tool iModeler that supports imperfect attributes and relations, and also allows
the inclusion of decision traces.
In this work, we have focused on providing mechanics to properly manage
and keep the information about imperfection. It was necessary to conceptualize
these kinds of imperfection, while understanding the impact from the sources
in the quality of the models. Based on these results, we will start to study how
to analyze the enterprise, taking into account the mentioned imprecision while
providing better conclusions.
References
1. Seidewitz, E.: What models mean. Software, IEEE 20(5) (2003) 26–32
2. Ludewig, J.: Models in software engineering–an introduction. Software and Sys-
tems Modeling 2(1) (2003) 5–14
3. Bézivin, J.: On the unification power of models. Software and Systems Modeling
4(2) (2005) 171–188
4. Henricksen, K., Indulska, J.: Modelling and using imperfect context information.
In: Pervasive Computing and Communications Workshops, 2004. Proceedings of
the Second IEEE Annual Conference on, IEEE (2004) 33–37
5. Kuhne, T.: Matters of (meta-) modeling. Software and Systems Modeling 5(4)
(2006) 369–385
6. Gómez, P., Sánchez, M., Florez, H., Villalobos, J.: Co-creation of models and meta-
models for enterprise architecture projects. In: Proceedings of the 2012 Extreme
Modeling Workshop. XM ’12, ACM (2012) 21–26
7. Smets, P.: Imperfect information: Imprecision, and uncertainty. Uncertainty Man-
agement in Information Systems 1996 (1996) 225–254
8. Hayashi, T., Wada, R.: Choice with imprecise information: an experimental ap-
proach. Theory and Decision 69(3) (2010) 355–373
9. Li, X., Dai, X., Dezert, J., Smarandache, F.: Fusion of imprecise qualitative infor-
mation. Applied Intelligence 33(3) (2010) 340–351
10. Hunter, A., Nuseibeh, B.: Managing inconsistent specifications: reasoning, anal-
ysis, and action. ACM Transactions on Software Engineering and Methodology
(TOSEM) 7(4) (1998) 335–367
11. Hunter, A., Konieczny, S.: Approaches to measuring inconsistent information. In:
Inconsistency Tolerance. Springer (2005) 191–236
12. Afshani, J., Harounabadi, A., Dezfouli, M.A.: A new model for designing uncertain
enterprise architecture. Management Science 2 (2012)
13. Dai, J., Xu, Q.: Approximations and uncertainty measures in incomplete informa-
tion systems. Information Sciences (2012)