4.1 Smart Business Intelligence Analysis Tool

4.1.a Information Harvesting and Linking

 

Research Problem

Before any kind of business process analysis can take place, there is usually a preparation phrase which takes care of retrieving and storing data. In the case of a BPaaS, there can be different information kinds from different sources that need to be gathered. For instance, deployment information would need to be collected from a Cloud Provider Engine while measurement information from a Monitoring Engine. Furthermore, each information source might adopt a different format and structure in order to specify the respective information. In many cases, the information collected from these different sources might also be duplicate or might pertain to different levels of detail. Finally, in order to prepare the respective analysis steps, the information needs to be properly integrated into a coherent whole in which different information pieces would have to be joined together.

Solution Approach

To solve the above research problem, we have adopted a semantic approach as this kind of approach has been known to facilitate in the best possible way the accurate integration of information. This approach comprises the following main steps:

(a) collection of information from disparate information sources;
(b) joining and semantically lifting this information by following a particular information structure based on two ontologies;
(c) storing the semantically lifted information in a Semantic Knowledge Base (Semantic KB).

The second step is required in order to allow semantic analysis tasks to be applied over the semantic knowledge stored such that the accuracy of the task results produced will be the best possible. The execution of all these steps is carefully performed in order to avoid unnecessary computation steps over information which has already been collected, while it is assured that triplification does not result in the production of duplicate triples in the Semantic KB. A unique URI identification scheme has also been adopted to enable the unique identification of each individual and independent (semantic) resource.
The integration and triplification of the information has relied on two main ontologies: (a) a dependency ontology called Evaluation Ontology and (b) a KPI ontology. The dependency is a new ontology that has been developed in order to capture hierarchical BPaaS dependencies enabling the coverage of the whole execution history of the BPaaS system, where each snapshot in this history can be considered as a static specification of the dependencies between the components involved in this BPaaS system.

This dependency ontology, in short, can capture the following types of information:

(i) deployment information about which component is hosted over which cloud service;
(ii) information about the input/output parameter values for BPaaS workflow tasks;
(iii) organisational information indicating which entities offer or execute BPaaSes and which roles or entities are involved in the realisation of BPaaS workflow user tasks;

(iv) adaptation information governing which adaptation was performed in the course of time over a certain BPaaS according to which reason and the successability of such adaptation.

Moreover, the capturing of all this information follows the well-know type-instance pattern which have been successfully applied to enable the modelling of both static and dynamic information about a particular system.

The KPI ontology is an extension of the OWL-Q ontology / language, a prominent language for the specification of non-functional service requirements and capabilities. This extension is able to model both static KPI information, such as the KPIs themselves, the way they can be measured and assessed and their association to respective organisational goals, as well as dynamic information about KPI measurements and respective assessments. Moreover, the latter type of information is integrated with the dependency information in order to facilitate some analysis steps, like the KPI analysis and drill-down or the discovery of best deployment for BPaaSes.

More details about the extension can be found at the following

URL: https://www.cloudsocket.eu/common-understanding-wiki/-/wiki/Main/OWL-Q+Parser.

Architecture

The current realisation of information harvesting has resulted in the production of the Harvester Module whose internal architecture is shown in the following figure. This module is not offered as a service as the actual functionality of this module is preparatory for enabling the respective core analysis capabilities of the rest of the modules in the BPaaS evaluation environment's architecture. The Harvester module's architecture comprises components which map to respective fetching capabilities from different information sources. As such, the number of such components coincides with the number of the information sources exploited.

The respective components are named as follows:
1.    WF Engine Extractor;
2.    Registry Extractor;
3.    Deployment Extractor;
4.    Monitoring Extractor;
5.    Marketplace Extractor.
 
The WF Engine Extractor is able to extract modelling and execution information about an actual BPaaS workflow that has been deployed as well as for the instances of such workflow that are or have been run by the respective clients that have purchased it. The Registry Extractor is responsible for fetching additional information about cloud services (e.g., which is the SaaS service involved in the realisation of a BPaaS workflow task and which are its annotated input and output parameters). The Deployment Extractor extracts deployment information from the Cloud Provider Engine about which BPaaS component instances have been created and on which IaaS instances they have been deployed. The Monitoring Extractor extracts monitoring information from the Monitoring Engine. The Marketplace Extractor extracts information about users and their roles.
As workflows can be fetched from the WF Engine Extractor, the BPMNParser component is responsible for processing them. In addition, the Triple Importer is the actual component responsible for storing (linked) information in the underlying Triple Store (Semantic KB) via the use of the Semantic KB Service. Before being stored, the information is structured according to the respective ontology schema, while appropriate URIs are given to resources (i.e., subjects or objects) via exploiting the Resource Naming Service component. Finally, the Harvester is a thread-based component run at fixed time intervals which encapsulates the core orchestration logic for information fetching and linking.

 

Information

BPaaS Evaluation Poster
BPaaS Evaluation Slides BPaaS Evaluation Environment Blue Print
Common Understanding Wiki Harvesting
 

Use

http://134.60.64.107:8890
 

Extend

https://omi-gitlab.e-technik.uni-ulm.de/cloudsocket/harvester
 

Additional Information

Originator: Kyriakos Kritikos (FORTH)
Technology Readiness Level: 5
Related CloudSocket Environment: Evaluation

4.1.b Conceptual Analytics Engine

 

Research Problem

The main challenge that a BPaaS broker faces is that of properly evaluating a BPaaS in order to find root causes of problems as well as places for further optimisation. The results from this final phase in the BPaaS lifecycle close the feedback loop enabling to enhance the design and allocation of a BPaaS and thus optimise its performance by also reducing the respective risks
and costs involved in the delivery of this BPaaS.
Many research frameworks have been developed in the past to support a business expert in evaluating Key performance Indicators (KPIs) as well as attempting to discover the root causes of KPI violation. Some of these frameworks adopt well-known techniques from different research areas, such as Semantic Web, Artificial Intelligence, Machine Learning and Database Management. However, such frameworks have not been yet applied in the context of a BPaaS. In addition, they exhibit some particular drawbacks that have to be overcome, including:

(a) the quite technical specification of KPIs making it hard for a business expert to be involved in the BPaaS evaluation process;

(b) the fixed and limited set of KPIs that can be evaluated which might be difficult, costly and error-prone to update it due to the tight integration with the respective KPI-related storage framework;

(c) a dependency over an inflexible and not rich and semantic KPI meta-model which does not cover well the domain and does not allow the easy exploration of all possible metric specification possibilities;

(d) adoption of an indirect model of KPI relationships for KPI drill-down by relying on machine learning techniques for the derivation of such relationships which require a rich set of execution information about KPIs in order to provide accurate results;

(e) inability to exploit various information sources, either being internal or external to the BPaaS management system.

 

Solution Approach

By relying on a smart and semantics-aware analysis information preparation offered by the Information Harvesting module, our semantic solution is able to raise the accuracy in the KPI analysis process. In addition, it relies on a flexible semantic KPI meta-model which also captures the mapping between KPIs and business goals thus allowing to perform goal analysis over KPI assessment results in order to infer how well the broker's operations, strategic and tactical goals are satisfied. Apart from capturing direct KPI (metric) relationships, enabling a more accurate drill-down over KPIs, this meta-model caters also for being used more by business experts as it enables defining KPIs in a business-oriented rather than technical language. In addition, KPI metric formulas are rich enough to include in the application of respective mathematical or statistical function results from API calls or database queries as input parameters, enabling the exploitation of disparate information sources during KPI measurement derivation. The adoption of a business-oriented and rather complete KPI metric language, which is independent from technical specificities, also allows for a more
flexible exploration of the KPI metric space, something which has been deemed invaluable in the context of business process evaluation, where the definition of some domain-dependent KPIs maps to a creativity-intensive process.
The proposed solution is quite straightforward and relies on model transformation techniques. In particular, by relying on the description of a KPI as well as the dependency information about a BPaaS, a respective semantic query is generated which is then issued over the Semantic Knowledge Base. As such, as already advertised, KPIs have the liberty to be specified in non-technical terms and are thus not tightly coupled to the respective information management sub-system. By relying on the variability of the way KPI metric(s) can be specified, the possible metric space is also better explored. In particular, the modeller has the freedom to specify KPI assessment periods, different metric formulas, different BPaaSes as well as specific tenants / customers. All this information can then be taken into account during evaluation in order to focus on the respective and suitable Semantic KB system part which is restrained over the evaluation period defined. The consideration of different tenants also enables exploring the KPI assessment in a local apart from a global level which allows performing some tenant-specific troubleshooting. It is also worthwile mentioning that KPIs can be assessed over specific BPaaSes or even across the whole set of BPaaSes offered by a certain broker.
To support root-cause analysis, we follow a rather direct approach by relying on the relationships between KPI metrics in order to perform the KPI drill-down. In particular, KPI metric decomposition is seen also as a KPI decomposition which enables to perform KPI drill-down in a hierarchical manner. The coverage of direct metric relationships enables the system to be more accurate with respect to the use of machine learning techniques. This, however, does not prevent the latter techniques to be employed in case where further drill-down needs to be performed but there are no other metric relationships to be exploited.
The drill-down is performed in a smart manner by exploiting the metric hierarchy of the KPI under examination. The evaluation of KPIs follows a bottom-up approach from the leaves towards the higher-level nodes of this metric hierarchy. Such an approach allows to perform the least possible computation steps to evaluate the respective KPI metrics involved in this hierarchy by relying on the fact that each higher-level node is computed from nodes at lower levels via the application of a certain metric formula / function. Obviously, the computation of the KPI metric values still follows the KPI-to-query transformation approach as we still need to rely on the information stored in the Semantic KB as well as the actual definition of a KPI.        

 

Architecture

The main component responsible for the delivery of the KPI analysis functionality is the Conceptual Analytics Module. Its internal architecture focusing on this kind of analysis is depicted in the following figure and comprises the following sub-components:

 - the Conceptual Analytics Engine which is the main component realising the KPI analysis
functionality.
 - a REST service, named as Conceptual Analytics Service, which is responsible for encapsulating the analysis functionality, offered by the Conceptual Analytics Engine, in the form of a REST API over the Hybrid Business Dashboard (the common UI between the BPaaS Design and Evaluation Environments).

 

This service includes methods which enable:
(a) to obtain measurements for KPI metrics based on the history period and the respective client, if needed;
(b) to provide a drill-down of a specific KPI metric;
(c) to pose SPARQL queries which can enable exploration of the possible metric formula space;
(d) to retrieve the customers for which measurements over a certain KPI exist (i.e., they have purchased the corresponding BPaaS and they have started executing it).

The last functionality is suitable in case that a broker needs to inspect the performance of a BPaaS in terms of certain clients, mapping to a sort of client-based reflection for respective troubleshooting.  
 - the Metric Specification Extractor which is responsible for obtaining from the name of the KPI metric, given as input to the module, its respective (OWL-Q) specification.
 - the Metric Formula Extender which expands the formula of the KPI metric (see first transformation step above).
 - SPARQL Transformer which transforms the expanded formula along with the other information given as input (evaluation period, customer, history period) into a SPARQL query.

 

Information

CLOSER PAper on KPI Drill Down
BPaaS Evaluation Poster
BPaaS Evaluation Slides
BPaaS Allocation and Execution Environment Prototypes
D3.5 BPaaS Evalusation Environment Blue Prints

Use

http://134.60.64.107/evaluation/

Extend

https://omi-gitlab.e-technik.uni-ulm.de/cloudsocket/evaluation

Additional Information

Originator: Kyriakos Kritikos (FORTH)
Technology Readiness Level: 5
Related CloudSocket Environment: Evaluation