Enterprise Architecture Management (EAM) tools play an important supporting role in IT management of organizations to align their IT infrastructure to actual business needs. The continuously measurement and observation of each layer in an enterprise architecture is critical in order to achieve an holistic view about the EA operation. This paper describes a concept how to exploit and extend the metainformation of an IT architecture documented in an EA tool in order to support a multi-layer monitoring approach that provides traceability and correlation between monitoring data extracted from several abstraction layers. 1 Technische Universtität München,Software Engineering for Business Information Systems (sebis), Boltzmannstrasse 3, 85748 Garching bei München, {martin.kleehaus, oemer.uludag, matthes}@tum.de Copyright © 2017 for the individual papers by the papers' authors. Copying permitted for private and academic purposes. This volume is published and copyrighted by its editors.
The measurement and control of IT and business services delivered by an Enterprise Architecture (EA) is based on a continuous process of monitoring the instances, reporting on failures, learning from their behavior and planing subsequent actions. These steps are fundamental as, although this monitoring process takes place during service operation, they provide important information about the EA which in turn can assist for improving the alignment of the IT and business strategy.
Many well known EA frameworks emerged in the last decades like TOGAF [Ha11], ArchiMate [Gr16], ITIL [Of11], etc., that deliver a standard how to model the EA based on abstraction layers: 1) the IT infrastructure encompasses all technological aspects, 2) the application layer defines the software running in the IT infrastructure and 3) the business processes that operate on top of the aforementioned layers. Although a plethora of monitoring solutions [Kl16] have been developed to account for these layered architectures, most of these solutions specialize on a specific layer or requirement, like Business Process Monitoring [ADO00], Application Performance Monitoring [Ra12], Infrastructure Monitoring [Jo07], or Log Mining [AGL98] solutions. This makes it challenging to obtain an integrated and holistic view on the behavior and status of the EA as most tools either support only a technical viewpoint, or a business oriented viewpoint [BGP11]. In the following sections, we present an conceptual implementation how to design an integrated real-time multi-layer EA monitoring solution that establishes a link between the isssune ryaLe B e r trcuu rye trsa La fI n n litcppoa ryLae M1 M2 i A
CML Platform B1
B2 B3 B4 Publish changes Metamodel Manager M3
M4 s e rcv i e S y liit b o M
Extract Data software and hardware components like the communication behavior, the dependencies between each components and the business processes that are supported by the services. 2
The reference architecture that we use for evaluating our solution in future work will be the academic project Connected Mobility Lab (CML)3. The architecture is illustrated on the left side of figure 1. CML presents an open, digital mobility platform and is aligned on a microservice architecture. It consists of core services and mobility services. Core services undertake a supporting role by providing interfaces and required backend features. Mobility services provide business value to the end user and valuable data to other services that consume this data in order to enrich their own service.
The following use cases need to be addressed by the monitoring solution: 1) What is a root cause of an occurred error and who is accountable? 2) Which services suffer from bad performance? 3) Do the services comply with the specified Quality of Service (QoS) agreements? 4) What services fulfill a specific business process? 3
In the context of the proposed multi-layer monitoring solution we establish an EA tool enhanced with a Configuration Management Database (CMDB), as it is illustrated in the top of figure 1. The tool integrates a metamodel manager that applies an EA model as the design-time model that defines visual representations of all monitored components like business processes, software systems, hardware elements and their relations. The metainformation of the components (id, name, type, etc.), their relations (id, communication type, etc.) and monitoring specific information like the path to log files are stored in the CMDB.
Besides the EA tool which is the central control center of the monitoring solution we deploy a combination of several monitoring applications that collect data from each EA layer (right side of figure 1). However, as these applications perform their task rather selfsufficient and are connected to several database technologies (HBase, Cassandra, Elasticsearch as an example), we enhance the EA tool with a central communication bus that support the heterogeneous monitoring infrastructure. That means, each monitoring application has to communicate with the EA tool for extracting required information, like the component id in order to achieve a correlation between the monitored components. Furthermore, the EA tool also includes an interface for receiving continuous deployments made on the CML application in order to keep the architecture information up to date. In particular, the introduction or the withdrawal of software components are monitored. The following sections describe the monitoring solutions in more detail. 3.1
Monitor the infrastructure layer The infrastructure layer of the CML platform is monitored by deploying agents on the servers extracting status information about traffic, bandwith, CPU utilization, etc. Open source solutions like Nagios4 or Sensu5 fit for this purpose. However, these solutions do not provide information about what specific user transaction is accountable for a huge resource utilization or which application causes abnormal behavior.
One approach in order to address this challenge, we suggest to leverage the linked information in the EA tool in order to correlate hardware metrics to running transactions by using the written timestamps as a connection key. In addition, log events written by the infrastructure and the application layer can uncover further important information about the behavior of these systems. Fur this purpose, we deploy the ELK stack6 for processing and indexing the log files. The information which IT component creates the log events and what user transaction is currently in process can be retrieved from the EA tool, passed to the Logstash pipeline and stored in Elasticsearch. 3.2
Monitor the application layer The CML platform consist of microservices (illustrated as MX in figure 1) which provide a bulk of different backend and mobility services. These applications are constructed from collection of software modules that were developed by different teams, in different programming languages. A huge challenge for monitoring this configuration is to identify how and to what extent the microservices are communicating with each other in order to understand system behavior and reasons about performance issues.
In order to achieve this goal we apply the application performance monitoring (APM) approach ”Dapper” described by Google [Si10] and adapted by several academic projects 4 https://www.nagios.org/ 5 https://sensuapp.org/ 6 https://www.elastic.co/ like kieker [vHWH12] and pivottracing [MRF15], and open source projects like pinpoint7, or zipkin8. Dapper provides a solution for analyzing the overall structure of a system and how components within them are interconnected by tracing transactions across microservices without changing the application code. Each transaction contains a collection of span identifier (span id) that refer to a specific Remote Procedure Call (RPC). However, as the span ids are generated from scratch by default, the APM solution has to be modified in the way that the keys describing the specific component of the platform architecture are issued by the central key manager from the EA tool. Furthermore, it has to be assured, that this modification has no significant performance impact on the services.
In addition, the span identifier need to be assigned to log events which are written from the particular service. This can be realised by altering the Logstash configuration file. 3.3
Monitor the business process layer The goal of business process monitoring is to extract business events that refer to a welldefined step in the business process activity (marked as BX in figure 1) from transaction logs. Hereby, it is challenging to know who performs the activity, what transaction events compose a whole activity and in particular when an activity has been started and finished [Do05].
To address this challenge, we propose to extend the EA tool with a business process manager that assists to define and manage business process events based on the trace information provided by the APM solution. Hereby, each relevant RPC refers to a business event and is mapped to one or more specific business activities that, in turn, compose a particular business case. However, in the first instance, the table for mapping RPC calls to predefined business process activities has to be done manually and kept always up to date. 4
In this short paper we presented an approach to enable real-time monitoring and visualizing of multi-layer Enterprise Architectures. We highlighted the concept of an EA tool with a central communication bus that supports the exchange of design-time and run-time information. Hereby, we were able to correlate monitoring data across the EA layers and assign them to each managed IT component and business process.
As this proposed concept is still in the design phase, our future work will be the elaboration of this solution. As the main research methodology, we will apply design science. First of all, we will investigate which monitoring application fits best for our needs. Afterwards we will model the details of our approach and develop a prototype accordingly. As the central EA tool we will use the academic project SocioCortex [MN11] and extend it with the above mentioned requirements. Finally, we will evaluate our prototype on CML.
5
This work is part of TUM Living Lab Connected Mobility (TUM LLCM) project and has been funded by the Bayerisches Staatsministerium fu¨ r Wirtschaft und Medien, Energie und Technologie (StMWi). We also thank our reviewers for their valuable feedback and constructive reviews. [ADO00] [AGL98] [BGP11] [Do05] [Gr16] [Ha11] [Jo07] [Kl16] [MN11] [MRF15] [Of11]
Mace, Jonathan; Roelke, Ryan; Fonseca, Rodrigo: Pivot tracing: dynamic causal monitoring for distributed systems. In: Proceedings of the 25th Symposium on Operating Systems Principles. ACM, pp. 378–393, 2015.
Office, Cabinet: ITIL Service Operation 2011 Edition. The Stationery Office, Norwich, 2011.