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 di erent kinds of sources, but sources could be insu cient or information could be incomplete or incorrect regarding aspects of the enterprise. As a result, 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 managing 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.
Enterprises increasingly depend on Information Technologies (IT) and require
support in order to achieve their business goals. Moreover, the enterprise
complexity and constant evolution generate di culties 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
simpli cation [
The model construction process is an observation of human process, sources
consulting, interpreting, and expression [
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 information 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 assign 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 imperfect 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 classi cation. 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. 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 elements which contain structural features. The MMEA is di erent for each speci c project, since it re ects 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 ( = f 1, 2, . . . , pg) that conform to the correspondent typed elements of MMEA. Each instance in contains several structural features ( i = f' i,1, ' i,2, . . . , ' i,qg), which can be attributes (A i = f i,1, i,2, . . . , i,rg) or typed relations (B i = f i,1, i,2, . . . , i,sg). The conformance relation between mEA and MMEA establishes that i must respect the types and structures de ned 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
distinction 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 [
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 di erent 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 information 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 modeler can collect enterprise information, and decision details. This decision trace information is structured through the EiMM that has types to represent all elements involved in the decision making process. As a result, the m conforms linguistically to EiMM and semi-conforms ontologically to the MMEA. Ontological & Linguistic conformance semi-cOonntfoolromgiacnacle
Linguistic conformance mEA approximationOf
mζ In the construction process of one model, modelers must consult enterprise sources ( = f 1, 2, . . . , rg). One source i provides information to modelers through Observations ( i = f i,1, i,2, . . . , i,sg). One observation i,j produces some knowledge about enterprise elements that we call Facts ( i,j = f! i,j,1, ! i,j,2, . . . , ! i,j,tg). 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 [
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 speci c 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 f 1, 2, . . . , rg can be inconsistent.
Case A. Several sources f 1, 2, . . . , rg are inconsistent when one observation of each source f 1,i, 2,j, . . . , r,kg about the same aspect of the enterprise determines that one instance l exists; however, some other observations determine that the instance l does not exist.
Case B. Several sources f 1, 2, . . . , rg are inconsistent when one observation of each source f 1,i, 2,j, . . . , r,kg provides di erent 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 f i,1, i,2, . . . , i,sg provide di erent 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 = f ' k,l,1, ' k,l,2, . . . , ' k,l,ng for one speci c 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 speci c 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 speci c 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 speci c value. Consequently, the value of the structural feature is indeterminated .
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 f 1 , 2 , . . . , r g, modelers have to make decisions in order to assign values to the model's structural features. There is a set of possible decisions ( =f 1, 2, . . . u g) 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 structural feature does not have any value. It might happen because the modeler decided not to assess any value because he/she does not have enough information.
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. [
iMM provides a basic linguistic framework for the de nition 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 the element instances of the imperfect model. Each element in a model has an attribute 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 represent, 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.
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 editor 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 attributes are decorated with a black rounded square. Imperfect containment and cross relations have respectively a lled and un lled square in the side of the source. Another important characteristic of iModeler is the way it handles problems. 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 ,
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 ontologically 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 <High>, 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.
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,
Meeting, and Person serve to represent sources; 3) Observation serves to represent interviews, document revisions, and meeting acts; 4) Fact and its specializations 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 decides 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 interview 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 following 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 speci es 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 imperfect attribute availability and the imperfect relation supports. Figure 5 represents the imperfect model with decision trace of the example.
In the Enterprise Architecture context, models are built using information provided by various and heterogeneous sources. These sources usually do not have perfect information, so enterprise models might not represent the enterprise correctly; thus, analysis results based on the mentioned models can be incorrect.
Imperfect models represent and structure imperfect information while enabling modelers to keep all the information provided by sources about the elements' attributes and relations. Modelers can also include decision trace information. 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.