O-CMDG PARAM table extract
Since the beginning of
In reality, this surprising result points the difficulties in globally defining the efficiency of a DSS. As a matter of fact, we see that whereas a “performance/cost” ratio is good for a technician, from the user perspective the “real performance/ expected performance” ratio is bad. Therefore, efficient may mean all or nothing, due to the characteristic of user perspective: a DSS may be very efficient for a developers needs, and completely inefficient for production objectives.
In order to improve the global DSS efficiency, companies can act upon (i) cost and/or (ii) expectations. They must be capable of well defining and exhaustively taking into account the costs and expectations relative to their DSS.
Concerning the first aspect of cost, the
Relating with the second aspect, we state that user expectations cannot be ignored when evaluating the efficiency of a DSS. We estimate that the expected results must be based on the
Having described the context in which we position ourselves, we have developed and we offer several solutions to improve the DSS efficiency.
(1) First, we note that an improvement process cannot exist without a prior monitoring process. We propose to adapt and apply best practices, already deployed for operational systems, by implementing a system which permits the measuring of the DSS efficiency. Following ITIL guidelines, this kind of system is known as the
(2) Second, we show the necessity of taking into account DSS specifics (in contrast with operational systems), with the purpose of elaborating the right measures for the efficiency of a DSS. These measures are different from the ones used with operational systems, which focus on the problematic of real time utilization. DSS are often defined in comparison with operational information systems as the distinction between
Our major proposition presented here is the elaboration of the
Following this, a second contribution is to optimize the value offered by the CMDB. We combine BI, OLAP and semantic web technologies in order to improve DSS Management efficiency, while offering autonomic self management capabilities with references from (Nicolicin-Georgescu et al., 2009).
The chapter is organized as follows. Section 2 presents how monitoring of the DSS is done so far and what elements are followed in concordance with the ITIL guidelines. In Section 3 we focus on the description of the DSS specifics in comparison with the operational systems, and how performance measurement changes with these specifics. The subjective aspect of user perceived performance is equally discussed. Further, we present our proposition, the BI-CMDB, in Section 4. The A-CMDB and the integrated monitoring and analysis solutions for DSS management are some of the described elements. We equally note that the presented work has already been implemented and the solutions area available for use (SP2 Solutions, 2010). Section 5 consists of a series of possible shortcomings and limitations of the BI-CMDB, so we can conclude in Section 6 with an overview of the chapter and the future doors that BI-CMDB opens for DSS management.
2. Monitoring Decision Support Systems
As with any type of system, prior to any analysis and assessment, monitoring of the interesting elements is required. “You can’t manage what you don’t measure” is an old well known management adage, which seems to apply more than ever nowadays.
2.1. Monitoring challenges and guidelines
There are two challenges with monitoring, particularly underlined by the DSS: (i) getting some data and (ii) getting the right data.
The first aspect is obvious, and challenges here usually relate with technical barriers. For example, consider an interactive reporting application, which builds reports based on data from various data warehouses. If we are interested in the functioning of this application, we need to trace its running, usually from application and operation system logs (files, data bases etc.). The organization of these sources is usually very specific and requires specialized Extraction Transform Load (ETL) software. Therefore, the process is purely technical.
The second aspect of getting the interesting data proves to be much more subjective-oriented, as a natural question arises: Who needs this data? Continuing with our example, if the interesting party is a technician, he will most likely want to know if the available resources are enough for the application to work properly. If the interesting party is a business department responsible, he is more likely interested in knowing how often the application is used and if it offers any added value to the business process. Choosing the right data based on the specific needs is either done directly when monitoring is performed (i.e. gather only the interesting data), or is filtered afterwards from a pool of potentially interesting data.
Getting the right data to the right party is strongly related with the elaborated SLAs. In the context of information systems, an SLA is defined as a compact between a customer and a provider of an IT service that specifies the levels of availability, serviceability, performance, reporting, security or other attributes of a service, often established via negotiation from the two parts. It basically identifies the client’s needs. IT organizations are measured on end-to-end business system response times, the degree of efficiency with which the system is used, and their ability to adapt to dynamic workloads (Ganek & Corbi, 2003). Breaking the SLAs may lead to financial and even legal problems, hence the need of their integration with the monitoring processes.
A very clear and detailed example of this aspect is shown by (Agarwala et al., 2006). The authors explain that Quality of Service is a particular concern for enterprise monitoring, exemplifying with an online airplane booking system. Formally, the QoS is defined as the level of current obtained data (usually performance) in rapport with what is expected. They describe QMON a QoS-capable monitoring system, which acts upon the system according to the importance of the monitored elements, importance expressed through the SLAs. The provided conclusion underlines the fact that QoS should be dynamically configurable and supported at monitoring level, allowing balance between monitoring overheads and improvement in application utility.
With DSSs, integration of SLAs and elaboration of QoS metrics is a central focus point. Unfortunately, best practices and guidelines to do so are not that elaborated as they are for operational system. One of the common mistakes done when managing a DSS is to use existing practices for operational systems and adopt them for DSSs without taking into account their particularities (Inmon, 2005). Nevertheless, ITIL provides a good foundation with the CMDB over service sustainability and offering (Dumont, 2007).
2.2. Monitoring solutions with DSS software
The described ITIL CMDB is general for an IS. As DSSs lack proper monitoring, elaborating a CMDB for a DSS is the first step towards a more efficient DSS. At this point a discussion is required over how monitoring is achieved with various DSS software solutions. The three most common ways are: (i) logging files, (ii) logging databases and (iii) console specific commands.
Either of the data sources used, the monitored data is usually raw basic data. Nevertheless, a distinction is done with this data at a first level of analysis which results in a combined monitored data. Some of the solutions, such as the BO monitoring data bases, offer a list of combined data parameters. To provide with a very simple example, consider that a data mart with two size indicators: the index file size and the size of the data file. We can obtain the two separately, but we have no indicator of the total size of the data mart. This is obtained by adding the two and ‘creating’ a new combined monitored indicator.
3. Intelligent performance with DSS specifics
Having the monitored data, the next natural phase is to use it in order to measure the performance levels of the DSS, consequently allowing the assessment of its efficiency. There are several particularities that render the process more delicate than for operational systems.
3.1. DSS specifics
We make a presentation of the most notable DSS particularities, as taken from (Inmon, 2005).
One last DSS characteristic we want to discuss here is the motto of the decision expert:
Performance measurement with DSSs brings into discussion, along the technical aspect (from operational systems), the user satisfaction aspect (form the business objective oriented point of view of analytical systems). There are two main types of performance (Agarwala et al., 2006):
Retaking the example shown by the authors of (Agarwala et al., 2006), a detailing of the QoS formula is shown below.
The basic single parameter QoS is computed by the ratio between the monitored values and the specified expected values. If several parameters are responsible for a global QoS, then a scaling factor is multiplied with each individual QoS, and, in the end, an average of all the scaled QoS is computed to obtain the overall system QoS value.
The data warehouse quality model is goal oriented and roots from the goal-question-metric model. Whether metrics satisfy or not the goal determinates the quality of the data warehouse (Vassiliadis et al., 1999). Data warehouses must provide high QoS, translated into features such as coherency, accessibility and performance, by building a quality meta-model and establishing goal metrics through quality questions. The main advantage of a quality driven model is the increase in the service levels offered to the user and implicitly increase in the user satisfaction. QoS specifications are usually described by the SLAs and the SLOs.
We have seen what SLAs stand for. In a similar manner, SLOs describe service objectives, but on a more specific levels. For example, a SLA would describe that an application is critical on the first week of each month, whereas the SLO would state that during critical periods the query response time on the data marts used by the application should not be greater than 1s.
With DSSs and data warehouses, one important area where service levels are crucial is the utilization periods, in direct link with the answer to the question:
4. The BI-CMDB
In this section we present, in an exhaustively manner, our view and proposition for building a CMDB adapted to decisional systems, which we consequently call the BI-CMDB. In order to understand how this is built, we present a schema of the data flow and the organization of five modules that are part of our approach.
On the bottom level we have the
Analysis of the O-CMDB is brought climbing up to the
A detailed description of the first three modules that are interesting to the BI-CMDB is done in the following. Examples for each of them are provided, in the light of the differences with the traditional CMDB and on the characteristics of DSS.
4.1. The data collector
The data collector is the first module in the data flow towards the construction of the BI CMDB. Its main objective is to gather and archive the various interesting monitoring information.
The core of the data collector architecture is the
As we have seen previously in the monitoring section, there are three types of data sources: logging files, logging databases and specific console commands. A connector can specify any (or all) of these types.
Following the ITIL guidelines, a separation of the
The Essbase server log files are under the
These lines permit to identify that there was an Essbase report request (data retrieval) on the budDM data mart, part of the budget application on the on 31st of January at 17:57:51 from the admin user, which lasted 29.64 seconds. These elements represent the interesting monitored information, and are recovered from the last four lines. The first two lines are useless. This filtering process is done at the construction of the O-CMDB.
Last, in order to get the configuration parameters of the application data marts, the esscmd command line console is used (i.e. GETDBINFO, GETAPPINFO etc.). The results of these commands are written into customized text files, which assure the
The role of the example was to show that the monitored information is very different, and data sources and formats vary even within the same implementation. The data collector has the role of assuring a first centralized level of information, with no data analysis intelligence. The only intelligence in the module allows an incremental data collection, such that data is not redundant (e.g. if data is monitored once each day, each collection takes only the information from the logs corresponding to the last past day). The following levels of information centralization are shown next with the construction of the O-CMDB and the A-CMDB.
4.2 The O-CMDB
The Operational CMDB is the first intelligent unification of the DSS information. It suits the role of an Operational Data Store (ODS), and it is build from the data collected by the data collector, by a series of filtering and analysis operations. The O-CMDB contains only the interesting information, rejecting any other unrequited data from the collector archives (as exemplified earlier with the Essbase report generation).
At first glance, the O-CMDB may seem as a simple log analyzer. This cannot be further from the truth. In reality, the process of building the O-CMDB makes a sweep of the information available, holding only the useful one (through interpretation of the log data), and constructing a series of purpose objective data stores with this filtered data. The organization of the data stores retakes the main ITIL groups for the CMDB and continues in the line of the data collector connector data fluxes. Technically, our implementation of these data stores is via relational databases, for both the O and the A CMDB, term which we will further use for a better understanding.
The following O-CMDB databases are constructed.
In our conception, we identify six levels of vertical hierarchy: (i) the entire DSS, (ii) the physical servers, (iii) the logical servers, (iv) the applications, (v) the bases and (vi) the programs. In order to keep this as generic as possible we note that depending on the specific BI software implementation, some of these levels disappear or are remapped (e.g. an application for Essbase is well defined with its own parameters while for a BO solution it becomes a report folder as a logical organization of BO reports).
|[Tue May 11 17:57:51 2010]|
Index Cache Size :  Mo
In addition to these three ‘main’ tables, a series of additional tables are build, such as the
One of the biggest benefits of constructing the O-CMDB is the reduction of the size of the monitored information. By comparing the size of the initial raw monitored data sources with the size of the O-CMDB database after integration of the data from those sources, we have obtained a gain of 1 to 99 (i.e. for each 99Mb of raw data we have an equivalent of 1Mb of integrated interesting data). In addition, this reduction allows keeping track of the data for both short and medium time periods (even long in some cases), which permits further prediction and tendency assessment.
4.3 The A-CDMB
The Analytical CMDB is the third and most advanced level of data integration. Unlike the O-CMDB which contained only raw data, the information in the A-CMDB is derived from this data. It represents the data warehouse of the O-CMDB, with analytical data suitable to business objectives. Considering the fact that the data from the O-CMDB regards a DSS implementation, we call the A-CMDB as the data warehouse of the DSS, or the support for ‘the decisional of the decisional’.
The A-CMDB consists of tables (i.e.
We provide an example with an extract of some of the columns from the AGG_PERF table, which aggregates the O-CMDB performance tables.
The table shows the fact that for the CI with code 5 (e.g. is an Essbase logical server), during the 23rd week of 2010, the measure response time (code = 15), has an average of 5.3 seconds. Moreover, this average is computed for the admin user, during a high utilization periods and during day usage. Finally, there is an SLO objective of 3 seconds for the admin user under the same conditions, which leads to a quality of service of 0.56 (=3 / 5.3), meaning that the admin user is only 56% satisfied with the logical server response times. If we consider that under a level of satisfaction of 80%, more details are required, automatically we have the need to drill into the data in order to know exactly what are the applications and further the bases and the programs that generate this dissatisfaction. This functioning is characteristic for any data warehouse (from the DSS user motto).
Therefore, the A-CMDB contains all the information needed for the analysis of the functioning of the DSS. It is a question of vision and development of the ITIL’s CMDB as a decisional component. Moreover, it is about applying the specific DSS characteristics for its construction, such that the relevant measures and indicators are well defined and that DSS supervisors have a very clear view over the performance of their system from the perspective of user and their satisfaction levels when using the DSS.
4.4 Advanced practices for the evolution of the BI-CMDB
Having seen how the BI-CMDB is built by processes from data collection, to construction of the operational CMDB and finally of the analytical CMDB, a series of advanced practices and topics are presented next, most of which open doors to future evolution of the model.
The benefice of the BI-CMDB is that it allows a complete (on every level) view of the functioning of an enterprise DSS.
One first very good application of this view is prediction and prevention. Using prediction algorithms and analyzing the data from the A-CMDB, we can see the potential bad tendencies of a DSS. For instance a slow but constant higher memory usage can lead to a system crash when the RAM memory is no longer sufficient. Moreover, by looking at past evolutions, prevention can be enabled by avoiding the previously done ‘mistakes’. For example, modifying the available cache values of a data mart which leads to disastrous results can be avoided from repeating itself.
The aspects of prediction and prevention lead to a second application case, which is
This is where the third advanced topic is discussed: providing meta-data and semantics with the BI-CMDB. For example, integrating all the information from the release Readme documents of the software, in order to identify the editor specified known and solved bugs or software compatibilities. When performing a migration such information is vital, and having it integrated with the BI-CMDB under a unified machine understandable form would simplify a lot the processes. In order to achieve this, solutions that imply the usage of web semantic technologies, specifically ontologies (Gruber, 1992), have been recently proposed for exploration (Nicolicin-Georgescu et al., 2010), and have been the result of our work over the last years. Using ontologies to formalize the DSS management aspects (such as best practices, subjective quality measurement, business rules etc.) go hand in hand with the BI-CMDB elaboration. Moreover, by using ontologies, it is possible to specify horizontal relations between the CI, as an addition to the hierarchical vertical relations of the DSS architecture, thus allowing a full description of the elements and their connections.
The problem with autonomic computing is that it has been elaborated with the real time operational systems as targets. In order to apply the autonomic model for DSS, similar to the passage from the CMDB to the BI-CMDB, the characteristics of DSS must be taken into consideration. The works of (Nicolicin-Georgescu et al., 2009) have shown an example of optimizing shared resources allocations with data warehouses, by focusing on the data warehouse importance and priority to the user rather then on raw technical indicators. Moreover, to comply with the DSS functioning, changes in the traditional loop functioning were proposed, via the description of heuristics targeted at the SLAs and the improvement of the QoS.
5. Possible limitations and shortcomings
Before concluding this chapter, an overview of the limitations and shortcomings of the BI-CMDB is done. We note that with some of them we have already been confronted, whereas others are presented only as possible to arrive.
The first limitation when building the BI-CMDB is
Another limitation of the solution is related to the construction process time of the O and A CMDBs. One may object the fact that due to the times needed to build these databases, real time analysis cannot be achieved. Yet, is there a real need for real time? The answer may be yes in the case of technical alerts (which simplifies a lot the processes), but no in the case of DSS analysis. In this case, the ‘standard’ time interval is an operational day, following the DSS usage purpose characteristic (i.e. the day/night usage cycles). At the end of each operational day, the data collector recovers the new information via the configured connectors, archives it and passes it for integration into the O-CMDB. This interval evidently is configurable, based on the specific needs (e.g. once each week, once each 3 days etc.), and user needs for this interval are mostly higher than the time needed to integrate the data into the BI-CMDB.
Following, one shortcoming may be the unpredictability of usage of the system, which makes scaling effects harder to measure. We have here a decisional of the decisional solution, which metaphorically is like doubling the DSS expert motto. A user of the BI-CMDB will constantly require new rapports and find new analysis axes to intersect. This means, that alongside the list of the main analysis axis that are implemented, depending on the users needs and objectives a series of new analysis pivots are described. As these needs vary from case to case, it is hard to asses the usage process of the BI-CMDB. Its performances depend strongly on the chosen client implementation. Moreover, through the web portal interface the user has the liberty to define his custom queries towards the BI-CMDB, a liberty which can make the system overcharge (similar to the data warehouse user freedom problematic).
Also, as we have spoken of the combination of the BI-CMDB with ontologies, this is regarded as a future evolution. For now, assuring model consistency and completeness (from the contained data point of view) is done ‘semi-manually’, after the report generation (therefore at the final stage). We try to move this verification at database construction level, as to avoid any unnecessary report generation (or worst give the bad report to the bad receiver). Implementing an ontology model and by benefitting from the inference engines capacities, such verifications can be done at the construction stage, before any utilization of the BI-CMDB data. A classic example is the mixing of the CIs from the hierarchy. The CI specification is build from the manual user specification of his system, thus is prone to human error. A physical server which becomes an application by accident would lead to completely incorrect rapports (from what the user was expecting).
Finally, we note that semantic and autonomic evolutions of the BI-CMDB arise a series of questions, from knowledge integration to supervision of autonomic behaviors and rule consistency.
We have detailed in this chapter an implementation of the Business Intelligence – CMDB, with the purpose of improving the efficiency of a DSS. Based on the fact that despite the technological advancements, user satisfaction with DSS performance keeps decreasing, we have isolated some of the elements that are responsible for this paradox, among which the Quality of Service, the Total Cost of Ownership and the integration of Service Level Agreements policies when computing DSS performance. We state that user perception is a vital factor that cannot be ignored in the detriment of the raw technical performance indicators.
In conclusion, implementing the BI-CMDB for DSS offers a series of elements we consider compulsory to an efficient DSSs: a CMDB for DSS, a complete TCO, an integration of the SLA/Os, an adoption of ITIL guidelines and best practices, all these with lower costs and the improvement of the user’s satisfaction levels. The BI-CMDB proposition for the ‘decisional of the decisional’, integrated with cutting edge semantic and autonomic technologies opens the doors to a whole new area of research towards the future of efficient DSS.
Nevertheless, developing the BI-CMDB is a first successful step towards the future of DSS. With the development of semantics and autonomic technologies, we strongly believe that future steps include these aspects, towards the development of a complete BI-CMDB, integrated with all pieces of knowledge required for managing a DSS. The ultimate autonomic semantic based BI-CMDB for DSS is a planet which seems “light years” away, but currently technology evolution speeds rapidly approach it.
We would like to thank Mr. Eng. Adrien Letournel and Mr. Eng. Guillaume St-Criq, both employees of SP2 Solutions, for their support with providing the data and the elements for the examples and for their feedback and support with this chapter.