Skip to content

Home

Jump to bottom
Fredrake edited this page Jun 29, 2017 · 15 revisions

ADOxx KPI DASHBOARD - Meta Model

The ADOxx Web Dashboard is a web-based ADOxx component that gives the user the possibility to create a cocKPIt, using Key Performance Indicators and Goals that helps visualize real time values. The user has a set of configurable widgets which makes it possible to customize their visualizations depending on organization’s set goals and objective. The dashboard comprises of three main components: the KPI Model, the Web Interface and the DataSource Wrapper.

In this project the KPI Model component is provided (left side of the architecture figure). Details on the Web Interface and the DataSource Wrapper components (right side of the architecture figure) can be found in the KpiDashboard-Web project wiki

CONCEPTUAL OVERVIEW

KPI MODEL

This is component is based on the ADOxx meta-modeling platform which allows for definition of meta-models and the creation of actual models to represent aspects of the KPI required by the dashboard. In defining the meta-model, classes and their relations are created in the Adoxx development platform as well respective class attributes created.

Classes

  • Goal
  • KPI
  • DataSource
  • Algorithm

Relations

  • depend_on_goal
  • goal_has_algorithm
  • kpi_has_algorithm
  • evaluated_with_KPI
  • has_datasource
  • depend_on_KPI

A KPI model can then be created on the ADOxx modeling platform with objects of classes and relations.

ADOxx Example KPI Model:

1. KPI Object

A KPI object which describes the KPI and all its available information such as the value and other information which can be present (for instance, the measured unit of the value or the instant time at which the value was recorded). A KPI is considered as a series of data which can be viewed as a table with at least one column (i.e. the value) and at least one row depending on the availability of the data.

2. Goal Object

The Goal object provides information about how the KPI value is evaluated. The Goal must be specific and dependent on the business model. For example, a Goal can be defined as the threshold that a KPI can attain in order to allow something or a particular value that the same KPI have to assume in order to allow something else. The goals can be grouped based on their behavior or level of business (e.g. operational goals or strategic goals).

3. Algorithm Object

An algorithm object contains all the mechanisms and instructions needed to evaluate a goal or a KPI. This object is required in order to evaluate a goal but can be avoided for a KPI when its datasource return a ready to use dataset. When a datasource return a dataset or a single data that have to be managed in a complex way, an algorithm object have to be associate to the related KPI.

4. Datasource Object

The Data Source object in the end gives the possibility to define how and where the KPI have to be obtained. There will be different Datasource objects each one with its own configuration parameters, like a SQL datasource object that will require the information to connect the database and the query to obtain the data, or an excel datasource with information of the path or url of the excel file and the information of the cells where to get the data, etc.

The KPI meta-model requires that a KPI object can be connected with only one datasource but the same datasource instead can have multiple KPI connected that will retrieve the data in the same way. A KPI can also be dependent on some other KPIs that will be required in order calculate its value (in such a case a datasource connection can be avoided), and can be associated to one or more goals to evaluate them.

A goal may also require the result of other goals (that will become its sub-goals) in order to evaluate its status. The goal in order to be evaluated must be associated with an algorithm object while a KPI can be associated to an algorithm in order to operate on complex data returned by the datasource or in order to process the connected KPIs.

Finally, the ADOxx modeling platform allows for a JSON object to be generated out of the KPI model and the output is exported to be provided to the Dashboard core part of the Web Dashboard component. This approach gives the possibility to define a personalized KPI model type that inherits the KPI meta-model and will be recognized as valid model by the dashboard.

DETAILED STRUCTURE OF THE KPI META-MODEL

A. Classes with Attributes:

1. DataSource : abstract class to be used as superclass for all the different types of datasources. Has attributes “ds_type”, “ds_config”, “structuredOutput” and “userRequiredInputFieldList”.
The Datasource is configured automatically by the use a java helper class which helps to set the parameters in order to return data by the specific datasource wrapper module. This is realized by a dialog window for inputting values for each datasource class attribute.

  • ds_type: The type of the datasource as the unique name of the datasource wrapper module to use. With the helper class, the user can select which data source to configure, for instance , a MySQL datasource as shown below:

  • ds_config: The JSON configuration required by the datasource wrapper module. Configuration could be for different types of Datasources. Configuration helper shown below:

  • structuredOutput: true if the return data is a JSON representing a table, false when return a general output JSON.

  • userRequiredInputFieldList: in case user detail(s) is/are required (e.g. email, password). Java helper dialog box for setting any user details is shown below:

2. KPI: has class attributes “Id”, “Description” and “Fields”

  • Id
  • Description: detailed description of the KPI
  • fields: list of field names as returned by the DataSource or Algorithm instance in a model; indeed we can have other field then the corresponding value, like the field "Instant" that will retrieve the datetime related to when the value has been recorded, or a field "source" that return the entity who generate the value. The fields are used by the dashboard to know the data present inside each KPI.
    The fields have to be generated by the datasource or by the algorithm objects. In case of REST datasource as example the datasource cannot return the fields directly but they have to be generated in the algorithm script that take as input the datasource output and will process it.
    A java helper in this case also helps to configure the KPI by a dialog window as show below:

3. Goal: has attributes “Id” and “Description”

  • Id
  • Description: detailed description of the goal

4. Algorithm: has class attributes “Id”, “Description” and “Code”

  • Id
  • Description: small textual description of the algorithm implemented
  • Code: text area to put JavaScript code. At the beginning should be present a commented part that show all the variables available to be manipulated. These variables in case of association with a KPI, will be related to the data returned by the datasource and the dependent KPI, while in case of association with a goal, will be related to the dependent sub goal and KPI.
    While an algorithm associated with a kpi must return an array of fields values, an algorithm for a Goal must return a status that can be "REACHED", "NOT REACHED", "NOT EVALUABLE" (the last case happen when there are not all the condition to evaluate the goal like expire time not yet reached).

B. Relations:

  • has_datasource (KPI-to-Datasource): a KPI can be connected to maximum one datasource.
  • depend_on_kpi (KPI-to-KPI): a KPI can depend on one or many other KPIs.
  • kpi_has_algorithm (KPI-to-Algorithm): a KPI can be connected to maximum one algorithm.
  • evaluated_with_kpi (Goal-to-KPI): a goal can require on one or many KPIs to be evaluated.
  • depend_on_goal (Goal-to-Goal): a goal can depend on one or many other goals.
  • goal_has_algorithm (Goal-to-Goal): a goal has to be connected to only one algorithm.
Clone this wiki locally