Goal-Oriented BI

The modelling tool we use is jUCMNav, an open source URN tool for the creation, analysis, transformation, and management of URN models. jUCMNav allows for the qualitative, quantitative, or hybrid evaluation of GRL models based on strategies. We have successfully implemented and validated the new formula-based propagation algorithm presented in the previous sub-section, with support for raw data access, KPI aggregation, and situation impact.

In addition, jUCMNav integrates with third party BI servers using a service-oriented architecture that allows one to setup the KPI models to load the evaluation values from a BI provider. Although the current architecture provides a great deal of flexibility, it has some drawbacks that prevent its application in real-life scenarios to be practical. For instance, a required web service must be installed on an application server. In addition, for each GRL strategy, a separate BI report must be created manually. This quickly becomes a tedious task in the presence of many strategies. For example, if the reports are moved within the BI server, then the monitoring process will fail and extra work is needed to manually detect the problem and manage the dependency.

We developed a new architecture (Figure 14) that eliminates the dependencies to an additional application server as well as the creation and maintenance of the reports on the BI server. In this architecture, the part of the code responsible for communicating with the BI server is moved inside the Eclipse application as a new plug-in. Therefore, the solution is self-contained and easier to deploy compared to the architecture proposed by Chen. This plug-in sends and receives the required data to the modelling plug-in. It also communicates with two main modules of the BI server to create the required reports on the fly and run them. Consequently, no pre-authored reports are required in this solution, which makes it even more compelling.

Figure 14

New architecture for connection to BI servers.

The downside of the new architecture is a tighter coupling with the BI server interfaces compared to the previous solution, which abstracted out the BI server interfaces behind more generic application server interfaces. The previous solution had a BI server agnostic interface in the application server that would allow jUCMNav to connect to any BI server. However, we believe that, with the plug-in based architecture of the new solution, one can write a plug-in adapter for each different BI server. So far, we have developed only one BI connection plug-in for IBM Cognos BI, which is the BI server we are using for our experiments.

In our current prototype, we use the approach illustrated in Figure 15 to create and run the reports on the server. In this approach we generate a report specification on the fly that returns the value of the KPI we are interested in. The report specification is stored on the server and is run using the IBM Cognos Mashup Service. This approach allows us to get the value of the KPI and initialize the jUCMNav KPI values accordingly.

Figure 15

KPI value retrieval from Cognos BI server.

Although this approach allows a simple integration with the BI server, there are concerns around performance that needs to be addressed. The main problem is the fact that, for each KPI, a report needs to be created and run. Depending on the size of the data source and traffic on the server, this could potentially become a performance-intensive activity. Our solution for now is to schedule this activity and run the reports and retrieve all the required values by the defined GRL strategies overnight. The values of the KPIs are then stored locally and become available for the users to use by running the model's GRL strategies.

Although this approach addresses the performance problem for already-defined strategies, it does not address the problem of creating new what-if scenarios and ad-hoc analyses that allow users to change the KPI dimensions at runtime. Even though what-if analysis can still be done using jUCMNav in standalone mode (without connecting to the BI server), if the real values coming from BI server are required, users will be bound to the available values on the server in the analysis time.

As part of our future work, we are looking at an integration with IBM Cognos Insight. This product is a client-side BI tool targeted for end users to perform performance analysis on their desktops. Integration with this tool will eliminate the step of going to the BI server for retrieving KPI values and address the performance-related issues. Furthermore, since IBM Cognos Insight has write-back capabilities and allows end users to enter their own data to perform what-if analysis by creating a local data source, it represents a good match for our methodology and integration with our KPI and goal models. This will enable users to change the values of the KPIs at runtime efficiently and see the results in the goal models without being dependent on a database administrator to update the data sources.