VIEW VISUALISATION FOR ENTERPRISE ARCHITECTURE From conceptual framework to prototype

Maria-Eugenia Iacob, Diederik van Leeuwen Telematica Instituut, Drienerlolaan 5, 7500AN Enschede, The Netherlands

Keywords: Enterprise architecture, View, Viewpoint, Model, Graph layout, Visualisation

Abstract: In this paper we address the problem of visualisation of enterprise architectures. To this purpose a framework for the visualisation of architectural views and the design of a visualisation infrastructure are presented. Separation of concerns between storage, internal representation and presentation is the main requirement for setting up this framework, since it will allow us to select and subsequently present differently the same content (models) to different types of stakeholders. Our approach has resulted in an operational prototype that has been tested in a pilot case, also presented in what follows.

1 INTRODUCTION (models) and the differentiation of this content towards stakeholders (Section 2). From the Enterprise architecture (EA) is a coherent whole of conceptual framework a visualisation infrastructure is derived (Section 3), which realises the desired principles, methods and models that are used in the design and realisation of the enterprise’s integration and differentiation. Finally the organisational structure, business processes, visualisation infrastructure serves as a template for a visualisation prototype (Section 4). information systems, and infrastructure (Bernus et al., 2003). However, these domains are not approached in an integrated way, which makes it difficult to judge the effects of proposed changes. 2 CONCEPTUAL FRAMEWORK Every domain speaks its own language, draws its own models, and uses its own techniques and tools In this section we present a framework for the for visualisation. Communication and decision disclosure and visualisation of enterprise making across domains is seriously impaired. architectures. Separation of concerns (Dijkstra, One of the goals of the ArchiMate (see the 1976) between storage, internal representation and acknowledgement) project is to provide the presentation is the main requirement for setting up enterprise architect with instruments that support this framework, since it will allow us to select and and improve the disclosure and visualisation of subsequently present the same information (models) enterprise architecture without being obstructed by to different types of stakeholders. The challenge for the narrowness of specific domains. such a framework is to facilitate the visual Views and viewpoints are essential elements of presentation without having to change the the disclosure of enterprise architecture descriptions. underlying infrastructure every time a new type of Following (IEEE, 2000), viewpoints are templates stakeholder is added or the information need of an for view creation that define the addressed existent stakeholder changes. stakeholder, his concerns and the information he Visualisation of enterprise architecture is needs for understanding the enterprise from his concerned with the presentation of views that may perspective and for taking responsibility for his contain models, text and other types of content to decisions. different types of stakeholders. Figure 1 expresses This paper presents the creation of a viewpoint- the conceptual architecture that underlies our driven visualisation prototype. Starting point for this approach to visualisation (based on ideas from prototype is the ArchiMate conceptual framework Schönhage, B. & A. Eliëns, 1997). We assume the for enterprise architecture visualisation, which existence of a repository of models, describing the establishes the integration of heterogeneous content architecture. The view content is a selection from the

629 Iacob M. and van Leeuwen D. (2004). VIEW VISUALISATION FOR ENTERPRISE ARCHITECTURE - From conceptual framework to prototype. In Proceedings of the Sixth International Conference on Enterprise Information Systems, pages 629-634 DOI: 10.5220/0002610606290634 Copyright c SciTePress ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

Model ViViewepoiw nt PreseVienwtation coModntenelst presentation update update

content presentation space space select visualise derive

Viewpoint

Architect Stakeholder Figure 1: Information objects in the viewpoint architecture. models stored in this repository, possibly augmented architecture stakeholders have viewpoints that result with analysis results and subjected to operations in views containing models that feed the such as abstraction and refinement. stakeholders’ information presentation needs. A The view content is expressed in terms of viewpoint establishes the purposes and audience for modelling concepts, stakeholders, and concerns. The a view and the techniques or methods employed in view content can be presented in different ways. constructing the view (IEEE, 2000). We have This presentation is expressed in terms of a adopted this approach as basis for the understanding presentation space, containing e.g. edges, nodes, and use of the viewpoint concept in our visualisation text and/or charts and tables. infrastructure. Furthermore, we do not strive for a Editing operations on this presentation can lead fixed set of viewpoints. Instead, we assume that the to updates of the view content and consequently of architect and stakeholder should be provided with the underlying model. the means to construct their own viewpoints from The separation between content and visualisation basic elements. Since the idea of viewpoints is essential to obtain an easily adaptable architecture. revolves around selecting the right content from a Arguments sustaining this statement one can also set of (possibly large) models and choosing a find in the Model/ View/ Controller design pattern suitable presentation for this selection, we opt for a of Gamma et al., 1995, and the work of Pattison et rule-based solution. Viewpoint rules are the basic al. 2001 and Schönhage et al. 1998. Thus, if the set building blocks of a viewpoint. First, they describe of model concepts is changed, or if a new form of which content is selected (according to selection presentation is added, the impact of these changes rules) from the model (or another view) and how it can be kept local. Only the relations between model is presented (according to presentation rules), and concepts and visualisation concepts need to be secondly, they are used to map (according to updated. interpretation rules) edit operations (executed according to interaction rules) on the view 2.1 Viewpoints presentation back into the model. In Figure 1, things were simplified a bit. In practice, a viewpoint consists of different types of According to the IEEE-1471 standard, the rules, governing the content and presentation of

Selection Presentation rules rules

View content View Present presentation

Select Interact

Interpret

Interpretation Interaction rules rules

Figure 2: View data flow.

630 VIEW VISUALISATION FOR ENTERPRISE ARCHITECTURE - From conceptual framework to prototype

views, and controlling the interaction with and visualisations the perishable character is even more interpreting changes to the view presentation. obvious. Multiple visualisations of the same view Furthermore, a view might itself be based on another content can be created to serve the visual view, leading to a chain of views instead of a single preferences of one individual or the information step from a model to the view content. Since this needs of various stakeholders. view content is expressed in the same concepts as Therefore, all these different purposes and uses the model (Figure 1), the distinction between model impose different tools for their presentation, and view content is immaterial. This leads us to the manipulation or query. Because of the variety of data flow picture of Figure 2, which basically tools on the content side and of tools on the describes the cyclic process behind the interaction of presentation side, a monolithic tool bringing together a user (or stakeholder) with models (or views). all functionality would harm the reusability and extensibility of the visualisation infrastructure. Therefore we propose a component-based 3 VISUALISATION infrastructure with clear interfaces between components (Figure 3). INFRASTRUCTURE The shapes outside the view content manager and the view presentation manager in Figure 3 (e.g. In this section the conceptual ideas of Figure 1 and model, model manager, user, user interactions) 2, are translated into a more concrete visualisation represent things that are assumed to be already infrastructure design. In doing so, we distinguish present. This includes the selection rules, between the specification and the use of viewpoints. presentation rules, interaction rules and As opposed to the conceptual view, a tool interpretation rules, which together embody the infrastructure requires a distinction between models viewpoint specification. and view content. Although models and view In order to allow both data retrieval and data content are expressed using the same concepts, they manipulation, the infrastructure provides two main may be stored differently (in terms of location, flows: from model to user and from user to model. duration and format). Models, view content and Not all user interactions need to be translated back to view presentations serve different purposes and have the model. Temporary changes serving an impact different life durations and cycles. While models analysis might propagate back no further than to the preserve, describe and document the architecture at view content. Personal preferences concerning the several moments in its existence, the generation of layout of a presentation may even cause user view content is used as a work instrument. interactions to propagate no further then the Whenever an architectural change or architecture presentation itself. Note that this behaviour induces information retrieval is needed view content that can the creation of different view content versions and be altered or annotated is generated out of the view presentation versions that need to be managed. models. This does not necessarily mean that the To allow content tools and presentation tools to original models will be also altered. Sometimes the operate independently, we divide the infrastructure purpose is to interactively change or analyze data. into two main parts: the view content manager and Sometimes the purpose is just to look at an overview the view presentation manager. or a cross-section of complex data. Therefore, The view content manager incorporates two compared to models, view content has a provisional components: existence. In what concerns view content Selector – The selector uses selection rules from

Selection Presentation Symbol rules rules Library

View content manager View presentation manager

Model Selector View content Presenter View presentation

Model Model Interpreter View content Interactor User manager operations operations interactions

Interpretation Interaction rules rules

Figure 3: Visualisation infrastructure design.

631 ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

a viewpoint specification to select and/or transform discussed. data from either a model or view content into view content. 4.1 Case essentials Interpreter – The interpreter uses interpretation rules from a viewpoint specification to interpret view content operations and update a model or view One of the domains at DFI is the operational system content accordingly. This is where ambiguous architecture, which describes all of the operational software components and their dependencies (e.g. operations like ‘decrease the average value of …’ may be translated into unambiguous operations like input-output dependencies and hierarchical ‘decrease all values with a percentage equal to …’. dependencies). DFI already has a complete description of their operational system architecture The view presentation manager incorporates again two components: stored as a database and even has built a web portal Presenter – The presenter uses presentation on top of it, but what’s missing is a graphical presentation of the systems and their dependencies. rules from a viewpoint specification to present view content into a view presentation. This is where Such presentations were created in the past symbols are associated with view content items and manually. However this requires considerable effort, and therefore DFI has recognised their need for a where layout is associated with view content structure. To associate symbols with content items, tool that automatically generates these graphical the presentation rules may use a symbol library. presentations. Besides, DFI has formulated a number of quantitative requirements: thousands of diagrams Interactor – The interactor uses interaction rules from a viewpoint specification to translate user (i.e. view visualisations), some of them containing interaction into view content operations and/or hundreds of objects, must be generated and published on the web portal on a daily base. changes to the view presentation. This is where user actions like ‘add’, ‘update’ and ‘delete’ are DFI requested two viewpoints: (1) a viewpoint translated into view content operations. focusing a system’s (internal) hierarchy and (2) a viewpoint focusing a system’s (external) context. The view content manager and the view presentation manager are no all-embracing tools, but Furthermore, DFI wants to be able to add other they should rather be seen as super-types of different viewpoints or other presentations of the same viewpoints with minimal effort. All viewpoints are realisations serving different purposes. For instance the selector or interpreter could be specifically examples of information retrieval do not incorporate developed for a single repository (e.g. ASG Rochade information manipulation. or Oracle); a presenter or interactor could be specifically developed for a single graphical editing 4.2 Prototype environment (e.g. Microsoft Visio or Rational Rose). The visualisation infrastructure presented in Section 3, distinguishes two main processing flows. 4 VISUALISATION PROTOTYPE However, since the requested viewpoints only concern information retrieval, the prototype only implements the flow from the model to the user In this section the visualisation infrastructure is (Figure 4). partially validated by means of a case study The prototype consists of 2 components: the DFI performed within a large Dutch financial institution selector and the DFI presenter. The prefix DFI (DFI). For the sake of confidentiality this institution illustrates that these realisations are DFI-specific. will be left anonymous here. First the case essentials DFI’s operational architecture description is are introduced. Then the visualisation prototype is stored in a relational database called system

SQL Views Presentation DFI Symbols rules in XML Visio stencil

Microsoft Visual Basic Microsoft Visio 2002

System DFI Selector View content DFI Presenter Visio drawing Architecture in XML

Figure 4: Prototype design.

632 VIEW VISUALISATION FOR ENTERPRISE ARCHITECTURE - From conceptual framework to prototype

architecture. The DFI selector uses a set of SQL express their operational system architecture. views to select view content from that relational At DFI, visualisation of views boils down to database. The view content is expressed using a drawing graphs, using special shapes for the nodes simple but generic XML format designed to store or edges. Therefore, the final display of an objects and relations between them: architectural view can be very well controlled with appropriate graph layout algorithms. The selection of a particular layout technique is essential because it ensures the visual specificity of the view content: