=Paper=
{{Paper
|id=None
|storemode=property
|title=A Tool for Enterprise Architecture Analysis using the PRM formalism
|pdfUrl=https://ceur-ws.org/Vol-592/PaperDemo11.pdf
|volume=Vol-592
|dblpUrl=https://dblp.org/rec/conf/caise/BuschleUFLS10a
}}
==A Tool for Enterprise Architecture Analysis using the PRM formalism==
https://ceur-ws.org/Vol-592/PaperDemo11.pdf
A Tool for Enterprise Architecture
Analysis using the PRM formalism
Markus Buschle, Johan Ullberg, Ulrik Franke, Robert Lagerström, and Teodor
Sommestad
Industrial Information and Control Systems, KTH Royal Institute of Technology,
Osquldas v. 12, SE-10044 Stockholm, Sweden
{markusb, johanu, ulrikf, robertl, teodors}@ics.kth.se,
Abstract. Enterprise architecture advocates model-based decision-making
on enterprise-wide information system issues. In order to provide decision-
making support, enterprise architecture models should not only be de-
scriptive but also enable analysis. This paper presents a software tool,
currently under development, for the evaluation of enterprise architec-
ture models. In particular, the paper focuses on how to encode scienti c
theories so that they can be used for model-based analysis and reasoning
under uncertainty. The tool architecture is described, and a case study
shows how the tool supports the process of enterprise architecture anal-
ysis.
Keywords: Enterprise Architecture, Probabilistic relational Models, Soft-
ware tool, Data Quality
1 Introduction
Over the last two decades, enterprise architecture has grown into an established
approach for holistic management of information systems in organizations [1, 2].
A number of enterprise architecture initiatives have been proposed, such as The
Open Group Architecture Framework (TOGAF) [3], the Zachman Framework
[4], and military architectural frameworks such as DoDAF [5] and NAF [6]. The
core concept of the enterprise architecture approach is the employment of models.
Diagrammatic descriptions of IT systems and their environment are heavily used.
However, enterprise architecture models are not limited to descriptive use only,
but can also be employed to predict the behavior and eects of decisions. Rather
than modifying enterprise information systems using trial and error, models allow
predictions about the behavior of future architectures.
One prominent challenge to rational decision making is uncertainty. There-
fore, a good enterprise architecture model should be able to capture uncertainties
about assessment theory, system con guration or data quality, thus providing
better decision support and risk management.
What constitutes a good enterprise architecture model is dependent on its
purpose, i.e. the type of analysis it is intended to support [7]. For instance in
2
the case of analyzing data quality, the property of whether the data objects are
accurate with respect to the real world they describe is of interest. This prop-
erty however, is irrelevant for a number of other analyses, such as performance
evaluation.
Several enterprise architecture software tools are available on the market,
including Metis [8], System Architect [9] and Aris [10]. These tools generally
focus on the modeling of an architecture whereas the analysis functionality is
generally limited to performing an inventory or to sum costs over the modeled
architecture. None of the mentioned tools has signi cant capabilities for system
quality analysis based on an elaborated theory. Furthermore, these tools do not
support the consideration of uncertainty as described above.
In this paper an enterprise architecture software tool is presented. This tool
does not only provide functionality to model enterprise architectures, but also
supports the analysis of them. In order to support enterprise architecture analysis
as it has been outlined in [7] the tool consists of two main components. In the
rst component the theory relevant to analyze a certain system quality, such as
data quality or modi ability, is modeled. One can consider this as the de nition
of a language tailored to describe a certain aspect, e.g. data quality. The second
component supports the application of the theory to evaluate a speci c enterprise
architecture. This is done by modeling the as-is or to-be architecture of the
enterprise. Based on the created models it is possible to determine how the
architecture ful lls the requirements as they have been de ned in the theory. The
two-component architecture encourages the reuse of the developed theory as it is
possible to use the same language to describe several architecture instances. The
presented tool makes use of the Probabilistic Relation Models (PRM) formalism
as it has been presented in [11] and can thereby manage the uncertainty aspects
discussed above.
2 Enterprise Architecture Analysis
Enterprise architecture models have several purposes. Kurpjuweit and Win-
ter [12] identify three distinct modeling purposes with regard to information
systems, viz. (i) documentation and communication, (ii) analysis and explana-
tion and (iii) design. The present article focuses on the analysis and explanation
since this is necessary to make rational decisions about information systems [7].
An analysis-centric process of enterprise architecture is illustrated in Fig. 1. In
the rst step, assessment scoping, the problem is described in terms of one or
a set of potential future scenarios of the enterprise and in terms of the assess-
ment criteria with its theory (the PRM in the gure) to be used for scenario
evaluation. In the second step, the scenarios are detailed by a process of evi-
dence collection, resulting in a model (instantiated PRM, in the gure) for each
scenario. In the nal step, analysis, quantitative values of the models' quality
attributes are calculated, and the results are then visualized in the form of e.g.
enterprise architecture diagrams.
3
More concretely, assume that a decision maker in an electric utility is contem-
plating changes related to the maintainance of the power grid. The introduction
of an maintenance management system would improve the quality of the main-
tenance process and allow more cost e cient grid maintenance. The question for
the decision maker is whether this change is feasible or not.
As mentioned, in the assessment scoping step, the decision maker identi es
the available decision alternatives, i.e. the enterprise information system scenar-
ios. In this step, the decision maker also needs to determine how the scenario
should be evaluated, i.e. the goal of the assessment. One such goal could be to
assess the data quality of an information system. Often several quality attributes
are desirable goals.
During the next step, to identify the best alternative, the scenarios need
to be detailed to facilitate analysis of them. Information about the involved
systems and their organizational context is required for a good understanding of
their data quality. For instance, it is reasonable to believe that a more precise
data object attribute would increase the probability that the data quality of an
information system is high. The impact of a certain data object attribute is thus
one factor that can aect the data quality and should therefore be recorded in
the scenario model. The decision maker needs to understand what information
to gather, and also ensure that this information is indeed collected and modeled.
When the decision alternatives are detailed, they can be analyzed with re-
spect to the desirable system quality. The pros and cons of the scenarios are
then traded against each other in order to determine which alternative ought to
be preferred.
Assessment Scoping Evidence Collection Analysis
Model Builder Calculation Visualization
Function Function Function
--
Provide 0
Uses
Relations Values Evidence
d by . provide
used by
1..* System
d by
Customer Support : Function
Fault Management : Function
provide
d by
Evidence.Interview.Juliet
. Availability
Availiability
Me
diu
Availiability *
m
Customer Support used by Fault Management
Availability (Function
) (Function
)
0.7 0.2 0.1 provides
provides
administrate
d by
CRM System : System Maintenance system : System
administrate
d by
11 provided by
Availability Availability
Evidence.Document.Log
Error Reliability Reliability Me
0 diu
Provides
locate with
m
provides administrates
.
provides
1
. with
Administrate Administra administrate
* administrates
s with administrates
d by tes administrates
System 0..* 1 System administrator Juliet : System administrator Evidence.Observation.Juliet Joseph : System administrator Evidence.Observation.Joseph
administrates
MTTF Responsetime Evidence.Document.Log
Responsiveness Hi
gh
Responsiveness Hi
gh
administrated
Hi
gh Experience Experience
by administrated
MTTR Repairtime
Scenarios
Evidence.Interview.Juliet
Hi
gh
Evidence.Interview.Joseph
Hi
gh
CRM System X
Juliet
(System administrator
)
Fault management
by
System
(
Joseph
administrator
)
(System) Syste
( )
m
OK Cancel
Probabilistic Relational Evidence Instantiated PRM
Model (PRM)
Fig. 1. The process of enterprise architecture analysis with three main activities: (i)
setting the goal, (ii) collecting evidence and (iii) performing the analysis.
2.1 Probabilistic Relational Models
A probabilistic relational model (PRM) [13] speci es a template for a probability
distribution over an architecture model. The template describes the metamodel
for the architecture model, and the probabilistic dependencies between attributes
of the architecture objects. A PRM, together with an instantiated architecture
4
model of speci c objects and relations, de nes a probability distribution over
the attributes of the objects. The probability distribution can be used to infer
the values of unknown attributes, given evidence of the values of a set of known
attributes. PRMs are related to Bayesian Networks. As it is succinctly put in
[11], PRMs are to Bayesian networks as relational logic is to propositional logic.
A PRM model may be instantiated as a relational skeleton, σr , containing
just objects, object relationships, and attributes. Furthermore, a qualitative de-
pendency structure S de nes the details of the attribute relationships, i.e. the
sets of probabilistic parents in uencing each attribute. Finally, the PRM is com-
pleted by the set of parameters θS specifying the full conditional probabilistic
dependencies between attributes in the form of numbers in Conditional Prob-
ability Matrices (CPM). The following expression thus de nes the conditional
probability of an instance I , given σr , S , and θS :
Q Q
P (I|σr , S, θS ) = P (Ix.A |IP a(x.A) )
x∈σr A∈A(x)
Q Q Q
= P (Ix.A |IP a(x.A) )
Xi A∈A(Xi ) x∈σr (Xi )
Compared to the standard chain rule for Bayesian networks, this equation is
dierent in three ways: (i) the random variables are the attributes of a set of
objects, (ii) the parents of a random variable depend on the model context of
the object, and (iii) the parameters are shared between the attributes of objects
in the same class. In other words, the variables in the dependency structure are
the properties of the objects in the instantiated information model, and their
causal relations are expressed by the CPM [11].
A PRM thus constitutes a formal machinery for calculating the probabilities
of various architecture instantiations. This allows us to infer the probability that
a certain attribute assumes a speci c value, given some (possibly incomplete) ev-
idence of the rest of the architecture instantiation. In addition to expressing and
inferring uncertainty about attribute values as speci ed above, PRMs also pro-
vide support for specifying uncertainty about the structure of the instantiations.
PRMs further allow specializing classes through inheritance relationships.
Classes can be related to each other using the subclass relation ≺, and each
class X is associated with a nite set of subclasses C[X]. So if Z, Y ∈ C[X],
both Z and Y are subclasses of X . If Z ≺ Y then Z is a subclass of Y , and
vice versa Y is a superclass of Z . A subclass Z always contains all dependencies
and attributes of its superclass Y . PRMs further allow the dependencies and
conditional probability distributions of inherited attributes to be specialized in
subclasses.
3 Architecture of the Tool
The presented tool is implemented in Java based on a Model-View-Controller
architecture. The data model for PRMs and instantiated PRMs, is speci ed in
XSD and stored in XML les. The user interface is build upon the NetBeans Vi-
sual Library [14] with usage of the JApplication framework. The tool is separated
5
into two units, one supporting the modeling of the PRM, whereas the other one
makes the tool user able to instantiate and analyze this de ned structure. These
parts have to be used sequentially, re ecting the method that has been described
in section 2, starting with the modeling of classes and their attributes as well
as the relationships and dependencies between them. Thereby the focus of the
analysis is set, as the de ned classes re ect the domain of interest. The second
component of the EAT allows the instantiation of the PRM. Thereby scenar-
ios of interests are modeled according to constraints de ned in the dependency
structure for the PRM. Afterwards the analysis is performed. Therefore the in-
stantiated PRM gets translated into a Bayesian network understandable by the
Smile library [15]. This library performs the evaluation of the network. Finally
the calculated values are written back to the instantiated PRM and visualized
for the tool user.
4 Example Tool Application
Fig. 2. The PRM for data quality analysis showing classes and attributes relevant for
the analysis.
This section will illustrate the application of the tool through a case study
performed at an electric grid operator in Sweden [16]. The case study focused
on assessing data quality in a maintenance management system. In this paper
a reduced version of the study is presented, and in the correspondingly reduced
theory data quality is de ned as the quality of the content and the quality of the
values for the data objects used by the system. Quality of content is de ned in
terms of relevance, the degree to which the information objects have a purpose
for the users, and precision, i.e. that the information objects are detailed enough
for the application using them. Turning to quality of values, this is de ned in
terms of accuracy and completeness of the data objects, or more precisely the
attributes contained within a data object. Accuracy is measured as the degree
6
to which the values found in a system correspond to the actual values they
represent, whereas completeness is measured as the amount of values stored in
the system compared to the domain they represent.
Based on the theory outlined above the PRM for data quality analysis can
be constructed. The PRM has four classes, rstly the Information System for
which the assessment is performed. This system uses a set of Data Objects that
constitute the abstract information model employed by the system. Each object
contains one or more Data Object Attributes and in the operational system these
attributes are instantiated to Data Object Values. Turning to the attributes of the
PRM, each of the concepts de ned in the theory, e.g. relevance and completeness,
corresponds to one attribute. This can be seen in Fig. 2, for instance the attribute
Data quality is associated to the class Information System and depends on the
attributes quality of values and quality of content of the class Data Object. The
conditional probabilistic dependencies between attributes were also de ned, for
details, see [16].
The data in this case study was collected primarily through interviews but
for the acurracy of the data objects direct observations were made and compared
with values in the system, i.e comparing the data object values with the actual
items they represent to assess the accuracy of an attribute. The instantiated
PRM is shown in Fig. 3 where the maintenance system, two data objects, three
attributes and a set of values of these attributes are modeled. Based on (i) the
model and (ii) the values of the descriptive attributes in the PRM (as found
during the data collection), the assessment can be performed. The data quality
of the maintenance system, measured in percent of complete ful lment of data
quality requirements, was found to be 62 percent.
Fig. 3. Instantiated PRM for data quality analysis containing one system, two data
objects and three attributes with values attached.
7
5 Discussion and Future works
This paper presents a tool which supports enterprise architecture analysis with
the use of the PRM formalism. While providing a powerful mechanism for the
use of discrete variables in an analysis, the PRM formalism in its initial form
has a few weaknesses that deserve further studies.
Several system qualities are typically analyzed through the usage of continu-
ous variables e.g. in [17] continuous variables are used for performance analysis.
In order to perform those evaluations with support of the presented tool, it is
necessary to discretize all continuous variables. At the moment we are inves-
tigating how the PRM formalism can be extended so that it can be used with
combinations of continuous and discrete variables, so called hybrid networks [18],
as well as a corresponding tool implementation.
Another weakness of the PRM formalism is that it does not provide any
means to query the models for structural information such as given an informa-
tion system, how many elements does the set of related data objects contain?
The Object Constraint Language (OCL) [19] is a formal language developed to
describe constraints on UML models. OCL provides a means to specify such
constraints and perform queries on the models in a formal language. OCL in its
original form is side eect free, but currently an imperative version of OCL is
being added to the tool. Thereby the analysis functionality can be extended to
consider the structure of the PRM instantiation more comprehensively.
Besides the two mentioned shortcomings of the used formalism there are some
improvements with respect to usability. Regarding the user interface of the tool,
we are planning to make the models more intuitive and the information provided
easier to understand. Enterprise architecture models are more graspable if they
only depict the interesting parts of the model (in a goal-sense). Therefore, the
tool should be extended to support views and viewpoints, e.g. as presented in
[17]. Additionally we plan the support of iconic visualization of typical enterprise
architecture elements, such as applications or data objects, to present the models
in an easily understandable way.
Finally we are planning to integrate the support of prede ned model compo-
nents. As models based on the same metamodel are likely to have common parts,
the modeling process can be sped up if common building blocks are oered by
the metamodel provider and used by the person that creates a certain model.
6 Conclusion
In this paper a tool and method for analysis of enterprise architecture scenarios
was presented. To ful ll this purpose the tool consist of two separate parts, one
for de ning analysis theory and one for enterprise architecture modeling, and
makes use of the PRM formalism for specifying theory. Applying this formalism
allows for the consideration of uncertainty, an aspect that so far is uncommon
in the eld of enterprise architecture analysis. The paper describes the PRM
formalism as well as the underlying architecture of the tool brie y.
8
In the paper an example of data quality assessment was outlined, but the
tool supports the analysis of various quality attributes, such as maintainability,
information security, and interoperability. The tool supports information system
decision making as it allows the comparison of several scenarios with regard to
a system quality. Thereby the as-is as well as several to-be architecture of
an enterprise can be compared quantitatively in order to nd the one that best
satis es decision maker requirements.
References
1. Ross, J.W., Weill, P., Robertson, D.: Enterprise Architecture As Strategy: Creating
a Foundation for Business Execution. Harvard Business School Press (August 2006)
2. Winter, R., Fischer, R.: Essential layers, artifacts, and dependencies of enterprise
architecture. Journal of Enterprise Architecture Volume 3, Number 2 (2007)
718
3. The Open Group: TOGAF 2007 edition. Van Haren Publishing, Zaltbommel,
Netherlands (2008)
4. Zachman, J.A.: A framework for information systems architecture. IBM Syst. J.
26(3) (1987) 276292
5. Department of Defense Architecture Framework Working Group: DoD Architec-
ture Framework, version 1.5. Technical report, Department of Defense, USA (2007)
6. NAF: NATO C3 Technical Architecture. (2005)
7. Johnson, P., Ekstedt, M.: Enterprise Architecture Models and Analyses for
Information Systems Decision Making. Studentlitteratur, Sweden (2007)
8. Troux Technologies: Metis. http://www.troux.com/products/ (March 2010)
9. IBM: System Architect. http://www-01.ibm.com/software/awdtools/
systemarchitect/productline/ (March 2010)
10. Scheer, A.: Business process engineering: Reference models for industrial enter-
prises. Springer-Verlag New York, Inc. Secaucus, NJ, USA (1994)
11. Getoor, L., Friedman, N., Koller, D., Pfeer, A., Taskar, B.: Probabilistic relational
models. In Getoor, L., Taskar, B., eds.: An Introduction to Statistical Relational
Learning. MIT Press (2007)
12. Kurpjuweit, S., Winter, R.: Viewpoint-based meta model engineering. In: Enter-
prise Modelling and Information Systems Architectures (EMISA 2007) (2007)
13. Friedman, N., Getoor, L., Koller, D., Pfeer, A.: Learning probabilistic relational
models. In: Proc. of the 16th International Joint Conference on Arti cial Intelli-
gence, Morgan Kaufman (1999) 13001309
14. NetBeans: NetBeans Visual Library. http://graph.netbeans.org (March 2010)
15. Decision Systems Laboratory of the University of Pittsburgh: SMILE. http:
//genie.sis.pitt.edu/ (March 2010)
16. Magnusson, S., Udin, S.: Assessing data quality on the maintenance sytem at
svenska kraftnät. Technical report, Industrial Information and Control Systems,
KTH (2009)
17. Lankhorst, M.: Enterprise architecture at work : modelling, communication, and
analysis. Springer (2005)
18. Lauritzen, S.: Propagation of probabilities, means, and variances in mixed graph-
ical association models. Journal of the American Statistical Association 87(420)
(1992) 10981108
19. Object Management Group: Object Constraint Language speci cation, version
2.0 formal/06-05-01. Technical report (2006)