The Corporate Performance Management Practitioner

I personally think that Metrics Studio (formally Metrics Manager) is the single most unique product in the Cognos Suite. I have been involved with many scorecarding/dashboarding/EIS/metrics products over the last 10 years, but none have the flexibility and depth of capability that Metrics Studio has. I am not aware of any other products that come close. 

The key thing that makes Metrics Studio unique is that it handles all the calculations needed to support Metrics analysis internally. All you need to load actuals into the product is the metric id, metric value, and the period in question, and it will handle trending, variances (obviously you need to load targets at some point), and all kinds of other stuff that would be hugely complex to create in a database or report.

 

An interesting question came up during a Cognos Forum session regarding real time metricsâ?¦can Metrics Studio support them? Of course, the answer depends on how you define real time metrics.

 

Ralph Kimball (he dean of data warehouse gurus) once defined ‘real-time’ as “anything faster than existing ETL processes”.

 

In that context, Metrics Studio can be real time, even though there are a number of data processes that must occur before the information appears in Metrics Studio. I would think that sub 5 minute process times are easily possible given the right application design.

 

If the Metrics Studio calculations add to much overhead for real time metrics, you could always do a dashboard report in Report Studio or in Query Studio. Even in this case, the data would have to be present in database before it could be reported on. Loading the database would become the bottleneck in getting real time metrics.

 

When I talk to people who need metrics in less than 15 minutes (lets call them instant metrics) I find that the metrics themselves originate in highly specialized, proprietary electronic data collection devices.

• Gaming:  instant metrics come from the slot machines.
• Emergency Services: The 911 system uses application logic embedded in the call infrastructure switches themselves to provide instant metrics on caller location. Many 911 systems are not capable of locating the point of origin of cell phone calls. Here in Illinois recently, a injured motorcyclist made 2 calls to 911â?¦he died because he could not be located.
• Health care, patients are hooked to sensors that measure heart beat, pulse, blood oxygen levels. If dangerous conditions occur, alarms are sounded. (Code Blue, Code Blue, Report to Trauma Room 3, Stat!)
• High-Tech Manufacturing: Instant metrics are also needed on the shop floor to analyze process quality. Sensors measure individual attributes (temperature, viscosity, density, line speed, flow rates, etc) and send the information to programmable logic controls (PLCs). If there are out of standard conditions, the PLCs triggers alerts or log warnings. For Pharma Manufacturers, the FDA mandates very specific compliance requirements for these types of systems.

 

I cannot think of an example where instant metrics would (or could) be pulled though the traditional data warehouse paradigm (Transaction System-ETL-Data Warehouse-BI tool). There are simply too many data movement processes to guarantee such a rapid response time.

 

For a BI tool like Cognos 8 to provide the presentation layer for instant metrics, the proprietary data collection systems would need to feed the sensor results directly to the report itself, or to the data staging area of Metrics Studio via a streaming mechanism like XML. The same stream would also feed a more traditional data mart for future aggregation and analysis. Composite software has tools that treat XML streams as just another JDBC compliant data source, so there is potential here. I could also imagine that it would be beneficial to hook Event Studio directly to XML streams.  For example, a manufacturer could attach Cognos BI to PLCs monitoring an assembly line. A temperature sensor error condition could trigger Event Studio to run a report that lists temperature variations over the last 7 days for that given sensor and show the temperatures of other sensors on the line in the last few hours. I would imagine this type of background data would be helpful to the manufacturing technicians than a alarm bell.

 

I am curious about how my readers compile “real time Metrics”. Do you need sub 15 minute instant metrics? Are you collecting and analyzing data from data collection systems using the traditional BI metaphor? How are these processes working? Where are the hurdles?

Filed under: Uncategorized

3 Responses to “Real Time Metrics in Business Intelligence Tools”

1. ykud Says:
   July 17th, 2006 at 10:31 am

   Real-time analysis opens a new niche on BI-market.
   See SeeWhy, as an example.
   Stream processing, therefore is a viable theme, yet a lot of pecularities appear there. Usualy a “window” technique is used, opening a sliding window on a stram of data to calculate queries. So window size is a viable parametr. And setting it too small, as well as too high affects calculations.
   It’s a complex task to put metrics calculation above streams, because of stream nature
   Our customer’s satisfaction with MM is rather low, due to time granularity issues (they claim it’s no less than moth) and calculation times and updates (they need to perform a couple of recalculations to affect metrics on all levels). Any of such in your practice?

2. Joel Vander Weele Says:
   July 19th, 2006 at 2:14 pm

   Ykud,

   In my mind, the windowing method is tough to pull off since I can’t see many reliable ways to handle error checking and related tasks..How does the BI tool reading the stream inside the window handle a situation where the window shuts down do to network interference of other technical difficulty.

   I guess I am seeing an XML stream using a specific format from Metrics/BI. A XML Data Type Definition (DTD) could be built to carry metric values to the BI tool from some other electronic reader.

   The DTD would include specfic markup tags that would open up the transmission, send over metric values (presumably to a Cognos 8 dashboard that was being continuously refreshed) and then close the stream.

   There already are DTDs that do similar things…for example XBRL (eXtensible Business Markup Language) is a DTD that handles financial reports…COuld this be tweaked to send over metrics? I would think so.

   Tell me more about your clients problems…Monthly granularity is usually not a problem.

3. ykud Says:
   July 19th, 2006 at 2:46 pm

   We’re looking at stream processing from different points.

   I regard stream as a data source to perform metrics calculation. Since a stream is never-ending and inifite-sized arises a problem of querying stream data. This a concept problem, not network or such.

   Sending metrics data via XML (whatever namespace you like - RDF is will be rather interesting) is rather obvious, and you can use SOAP with Cognos SDK for parsing even now, as far as I understand.

   MM problems are simple. Day granularity is needed, and some calculation sometimes do not appear at top level (another rec alculation helps, though). Latter is due to technical problems, maybe, but day granularity is a problem.

Leave a Reply

You must be logged in to post a comment.