The discourse of Enterprise Architecture is based on modeling and performing 'holistic' (multi-layer) analyses. However, view centered methodologies offer a partial glimpse of the overall architecture, and current tools do not bring an explicit method of navigating the underlying model. Considering that we need a starting point for analysis and explore the whole model in order to drill down on more specific analysis techniques, we compare overview visualizations depending on topological properties of the model and a set of domain-specific requirements. Four techniques are examined, and they visualize five Analytical Scenarios that represent typical questions that could arise on a EA diagnostic.
Nowadays, as we are more capable of capturing all kinds of information, the need to
make sense of it is most compelling. Instead of facing the problem of collecting this
data, the main issue is to propose methods and models, which can turn it into reliable
and provable knowledge [
In this aspect, Enterprise Architecture (EA) has been proven as a valuable tool for
aligning business strategies with Information Technologies projects and infrastructure.
A key function of EA is the static analysis of current architectures in order to drive IT
projects and close gaps. Given its broad scope –e.g. impact analysis vs. business
process analysis–, and the use of different techniques, ranging from ad-hoc to quantitative
analysis, it is important to point that no common definition of the term EA Analysis has
emerged [
However, we invite the reader to think of EA analysis as more than a static process
with a collection of techniques. We think that the analyst, his own experience and
reasoning power are ‘the spice’ that give flavor to analysis, making sense of the information
of the enterprise, that means, turning it into reliable and comprehensible knowledge [
As all the collected information from the different domains of the organization –the
EA model– is more detailed and complex, assessments are more difficult to perform.
Given the iterative and reflective nature of this analysis process, EA Frameworks such
as DoDAF emphasize on tool-assisted and tool-supported analyses whenever possible
[
In decision-making, “the useful information is drawn from the overall relationships
of the entire [data] set” [
With the purpose of illustrating the different subjects at hand, we will provide the
results of our experimentation with four VA techniques, that are widely used in other
domains, to visualize the enterprise model of our case study. This experimentation is
supported by five Analytical Scenarios, which are typical questions that can be
formulated throughout the EA Analysis process. Each visualization is adapted to show the
maximum amount of information, taking care of following the Visual and EA Analysis
requirements defined in [
The structure of this paper is as follows: First, we will characterize enterprise models and their topology (Section 2) and introduce EA Analysis supported by Visual Overview (Section 3). In Section 4, we will explain the Case Study and Analytical Scenarios selected for this research. Finally, in Section 5 we will perform an evaluation of the effectiveness of the selected techniques for overview analysis.
Enterprise Architecture has been supported by different paradigms of Enterprise
Modeling [
Analysis methodologies over these models encourage the identification of critical
elements by examining their incoming and outgoing links [
In order to support this kind of assessments, we make a bridge between EM
analysis and studies in graph analysis and complex networks. This will allow us to take
advantage of existing properties of this kind of networks, and to formulate interesting
topological properties specific to EMs. A complex network represents a complex
system, where the relationships amongst the components of the system are usually more
important than the components themselves [
Our premise is that EMs are complex, and we can define their complexity in terms of its number of relations, as it surpasses the number of elements of the model. We will describe five properties of EMs inspired on this premise.
While EMs are abstractions [
As semi-automated mechanisms for collecting architectural information are more
widely used, enterprise model scalability becomes a critical issue. For instance, Binz
et al. point to the complexity of Enterprise Topologies –a snapshot of all services and
applications in an enterprise, together with their supporting infrastructure and relations
[
One of the goals of EA is to provide alignment of the different business and technological resources, by establishing relations between the elements on different architectural domains.
(a) Detail of some domains on an EM (b) Weak Components of the model
In EMs, this organizing structure is explicit: they conform to a metamodel that integrates the different domains of the organization and offers a clear view on the structure of and dependencies between relevant aspects of the organization.
Definition 2. An enterprise metamodel is the common language on which the enterprise model is ‘spoken’ by the means of concepts, relations and constraints that bring consistency to the architectural description.
Instead of a “one-size-fits-all” metamodel, recent approaches to enterprise
modeling focus on integration [
Definition 3. An enterprise domain is a subset of the enterprise metamodel that aggregates similar concepts, forming communities that are connected between them by inter-domain relations.
Taking into account that we are interested in the relations between domains, unaligned/isolated elements are meaningless on their own. Therefore, a first step when analyzing the model is to identify ‘islands’ or weak components, i.e. disconnected groups of elements (see Fig. 1(b)).
Organizations are complex systems that are conformed of a number of parts which are inherently hierarchical, i.e. they are composed of interrelated subsystems, and interact in a non-simple way.
Under this light, EMs are semi-hierarchical, as each domain manages different levels of detail on its concepts by composition (i.e. aggregation) relations. For instance, Process Models are defined under a vertical scope, where each depth level also involves more granular sub-processes and activities (see Fig. 2(a)).
An advantage of this property is that hierarchies are one of the most recurring information structures in computing, and offer a natural way for navigating the model.
EA Analysts need to find pathways between the different model elements, which is
important when they want to assess the overall impact of a change in the architecture, e.g.
the cost of making changes to enterprise-wide software systems [
Nevertheless, these paths are made by different kinds of relations, e.g. composition and association relations. The latter provide a horizontal scope to the model, i.e. a ‘is related to’ semantic, which is mostly given by their name, and depends on the metatype of their target. For instance, an Application may be used by a Role, which in turn is responsible for some Resources, and belongs to an Organization Unit.
For this reason, it is common in analysis techniques to assign weights or other attributes to relations, translating this abstract semantic to more quantitative means. (a) Sunburst (b) Radial Graph Analyzing resilience of enterprises is important to discover points of failure under different domains, such as vulnerabilities in infrastructure security, core processes in business process analysis, or even overly-coarse services that need to be decomposed. For this reason, it is crucial to prioritize which elements have more influence in the topology of the model. This is useful when an analyst wants to assess the connectivity of the network: the removal of vertices or groups may affect, or even dismantle its structure.
In this aspect, several ranking algorithms exist to discover the relative importance of elements (e.g. PageRank, HITS, SALSA) based on their occurrence and connectedness. However, importance may be driven also by other semantic criteria that are based in the metamodel, not in the model itself. For instance, when analyzing which processes are supported by IT, we want to focus on Macro-Processes, Processes, and IT elements such as Applications and Services (see Fig. 2(b), where these elements are given some emphasis in size).
We often see the use of the term Analysis on different levels of granularity: as the overall
process and also as a concrete strategy or technique. On the remaining of this paper, we
will use the following definition:
Definition 4. EA Analysis: All of the processes that transform architectural data into useful
information [
In concrete, we are interested in the static analysis of this information, i.e. a snapshot of the architectural description, to offer a value judgment of a given state of the architecture.
In previous work [
Instead of using queries as the main way to inspect the model, our focus is on total
visualizations that provide an overview of the EM and help the analyst on finding new
properties of the overall set, thus we encourage top-down analysis for pattern discovery.
Definition 5. A visualization technique can be seen as the combination of marks [
Considering the overwhelming number of visualization techniques available, in our
case is certainly complex to assess which ones can be applied for such a specific
application domain. For this reason, instead of approaching this problem with an existing
taxonomy, we employ a set of Visual Requirements (see [
In our search for visualizations, we analyzed the different artifacts, views, viewpoints, diagrams, pattern catalogs and tools from our domain (EA), and confronted them with visualization taxonomies and tools/ frameworks. The selected techniques were: 1) Force-directed Graphs, 2) Radial Graphs, 3) Treemaps, and 4) Sunbursts.
In order to evaluate and interact with each visualization, we visualized the EA model of a fictional company from our EA Laboratory, Muebles de los Alpes.
The EA metamodel of this Retail/Manufacturing company incorporates concepts from several metamodels (e.g. Business Motivation Model, ArchiMate, BPMN, TOGAF), as well as specifically tailored representations of standards, frameworks such as Service Oriented Architecture, or even formalizations of domains such as Applications, Information, Organizational Structure, Financial Management, and Human Resources.
The enterprise model was developed by a group of experts, and validated by different architects. It is based on the different architectural deliverables, and reflects the current state of the organization, which is supported by a real set of IT components, such as a CRM, an ESB, an ERP, in-house applications, and several infrastructure deployed in the virtualized platform of our EA laboratory.
For the visualization of typical questions over EMs we designed five analytical scenarios that fall into three main categories that correspond to common concerns of architects, and are inspired on the properties described in Sec. 2 (see Table 1):
It is also noteworthy that the visualizations generated display patterns that are difficult to envision by other means (i.e. queries or views).
Many authors [
Based on the characterization of Bertin [
Technique Force Graph Radial Graph Sunburst
Treemap
where Av is the availability of a visual variable for a given visualization (see Table 2),
and wA is the weight -expressive power- of each variable. On the other hand, we
defined in previous work [
Evaluation results are displayed in Fig. 4 by using a Parallel Coordinates visualization, which provides a visual summary of the effectiveness of each technique.
We can see that graph visualizations point to convergent analysis, as their strong points are when searching concrete elements and groups, displaying the dependency between domains. At the same time, hierarchical techniques offer an interactive way of exploring the model, facilitating abstraction of elements and offering divergent analysis, where it is more important to characterize the architecture as a whole.
A previous step before proposing new domain-specific visualization techniques is the assessment of existing ones, in order to derive which aspects of each technique prove useful in our context.
When addressing the visual analysis of complex systems by displaying the overall structure, the analyzed visualizations employ different methods to show the ‘big picture’ of these complex systems. The visual patterns that they display point to structural assessments of this information. These kind of conclusions are fundamental for the analysis and evolution of the architecture, as well as a way to leverage the complexity of EA Management.
However, this overview analysis is mediated by the concerns of the analyst. This trade-off is reflected on the EA requirements, where some emphasize convergent analyses, i.e. the discovery of interesting elements, while others on Divergent analyses, which are a characterization of the architecture as a whole.
This study opens the door to more specialized research on EA visualization and tooling, as well as the proposal of innovative visualization techniques for the field. Other interesting research opportunities, such as the correspondence between visual and architectural patterns need to be further developed, and a Visual Analysis tool for EM has some requirements in the overall process that we didn’t touch, e.g. Provenance (persisting previous hypotheses/analyses and annotations), Traceability of the analysis, or even interactive visualizations specific for EA, as well as an architecture to support all of these features, integrated with current EA modeling tools.