Reporting ain’t reporting: RPE vs RRDI

What started this was a comment that “RPE is better for document-style CLM reports”. Having just completed some (soon to be published) updates to the RRDI sections of the Reporting Workshop, I got the chance to test that admittedly vague assertion on a real customer situation.

First, let’s be clear on some of the sometimes confusing choices around CLM Reporting. The Infocentre Page entitled “IBM Rational Reporting Solutions” goes into a lot of detail that I recommend reading and I won’t bother repeating here. It appears to me that the comment I quoted above and the decision tree at “Choosing a solution”  should have been better qualified. I reproduce that decision tree here to save a couple of clicks, swipes or taps.


My key gripe here is that if you follow the “Yes” path on the “Do you have a need for formal documents and reports” decision, you end up with just RPE or, confusingly, RRDG (which is  essentially the no-customisation, CLM-only “engine” part of RPE).

My view is that there needs to be more than one qualifying question leading to a decision on which reporting solution would be best suited. In many cases there isn’t a single answer either. For example:

  1. Do you need access to live data or is “old” data (from the Data Warehouse) sufficient?
    1. If you “must” have live data, then RPE/RRDG wins over RRDI, though RRDI does provide access to live data from just RQM. However, it is worth thinking about what “live” really means. In the case of a typical “document-style” report that is produced,perhaps printed and delivered for review, I would argue that the data is already out of date by the time the reader gets the data anyway, so it’s isn’t really live any more. The data in the Data Warehouse for RRDI reports is already stale by X hours, depending on when the report was generated and when the ETLs last ran.
  2. Do you need to either manipulate the data (group, summarize, aggregate etc) or present metrics-based (such as those listed on this page) or analytical views of the data  in the form of charts, pivots, lists or a combination?
    1. Where you need to produce simple or complex metrics-based reports then RRDI is the way to go, as some of the typical metrics information is already made available and RRDI’s Cognos Business Intelligence heritage comes out on top.
  3. Looking at Reporting Data Dictionaries, is the data made available in the data warehouse good enough?
    1. From experience, data availability is one of the key factors influencing the choice of reporting solution. In general RPE has access to more of the CLM data than RRDI. One quick way to help make this decision is to look at the tables in the Reporting Data Dictionaries. In general compare the “REST API Property Path” and the “FM Model Query Item” columns; if there is an “N/A” in the “FM Model Query Item” column for the UI Field you need in the report, then RRDI cannot access the value for that field. For example, looking at the Description field for Work Items in the table for the CCM data dictionary , RPE can access this value via “workitem/workItem/description” while RRDI does not have access to this value.
  4. Is licensing an issue?
    1. RRDI is bundled with CLM whereas RPE requires purchase of separate licenses for report authoring.
  5. Is the cost of additional hardware an issue?
    1. Hardware sizing for the reporting components can be influenced by the complexity and frequency of the reports being generated but in general the server components of RRDI require higher-class hardware than the server components of RPE.
  6. Can some of the “reporting” needs be actually met by a combination of CLM queries, views, plan progress information and other such sources?
    1. To me reporting is not an end in itself but a means to an end, the end here being better decision making. Of course there are always a few formal reports that may need to conform to standards or satisfy regulatory requirements. However, there is a wealth of information in a plan’s progress and load information, or in the results of a query on a dashboard, or an RRC/RQM view, that can be easily used to help the decision making process, without needing a “report” to be written and generated. (If you REALLY must print what you see, Print Screen/Alt Print Screen/Apple key ⌘ + Shift + 3/4  is faster:-)

So getting back to the question of whether RPE is better for document-style reports, the answer for this customer happens to be “No”:

  • hardware/licensing are not an issue as they already have RPE
  • having data that is a few hours old did not present a problem
  • there is a need for some metrics-based reports
  • all the data to be presented in the reports is available to RRDI
  • some of the “reports” could easily be presented as queries on the CLM dashboard or information derived from plan progress/load

The remaining objection was still that RRDI could not layout reports as RPE could which is a complete myth as RRDI can easily produce “document-style” reports with logos, table of contents with hyper-linked page numbers, master (summary) pages and detail pages, headers and footers, formatted as you please.

The proof of the pudding is in the eating, the saying goes. It took me about 6 hours to produce exactly the same “document-style” report that had taken a couple of weeks to produce in RPE. I’ll save the details of the report and some interesting things I learnt about doing such document-style reports in RRDI for another time.

One thought on “Reporting ain’t reporting: RPE vs RRDI”

  1. What happenned to the the update of the Reporting Workshop? Is latest RRDI version available for trial by VM or cloud, anywhere?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s