I had the opportunity to attend the Cognos 10 Launch event in Richmond, Virginia earlier this week (2/10/2011).  It was an educational session and it was also nice to see such a large turnout of Cognos users in the Richmond community.

I had the opportunity to attend IOD this week (10/25/2010) and was able to attend the Cognos 10 launch event in person.  I learned quite a bit about the product and wanted to share my first impressions of the new release.

(Note - this article is based on a windows environment; a similar concept can be applied in UNIX)

IBM Version - http://www-931.ibm.com/bin/newsletter/tool/landingPage.cgi?lpId=2873

Transformer 8.3 represents the first major change to the application in years. It is now fully integrated with Cognos 8. This includes data sources, cube access, and authentication. While this integration makes it easier to feed Transformer data, it complicates the process of automating cube builds. Within the UI, the steps to create secured views have changed, and the data sources are displayed slightly differently. But, allowing for drastic improvements in PC Graphics, the Transformer UI and build process is essentially the same as it’s been since Version 3 (c. 1994), when it ‘replaced’ Creator. Transformer now runs in all supported environments, so RSServer is no more.

The Cognos Transformer tool is extremely powerful and does a great job of producing cubes via the transformer interface.  The problem I have with Transformer, and the Cognos 8 BI suite, is that it provides no easy way to automatically refresh cube data on a regular schedule.  At every client I visit, they want to refresh cubes regularly for use in Analysis Studio.  It sounds easy enough but when you start to dig deeper you realize that it is not included in the out of the box Cognos functionality. Surprisingly a custom solution is required to achieve this. After each release I continue to wonder why IBM does not include cube refresh functionality within the Cognos Connection scheduling tool.  It seems like it would be the perfect place and relatively simple given how robust the scheduling options are.

When doing an upgrade from Cognos 7 to Cognos 8 there are two options, use the Cognos provided migration tools to do a "lift and shift" or rebuild all frameworks and reports from scratch.  Clients want to choose the "lift and shift" option and for good reason.  It seems like it would go faster, require less work and be more cost effective.  Is it really?

The lift and shift method may provide quicker results, but does it really require less work and is it more cost effective?  In my experience the answer is almost always no.  Quality suffers, best practices are not followed, and perhaps most importantly, any mistakes made in the old version are replicated.  When evaluating the approach, the following things should be considered:

• How many catalogs does the legacy environment have?  Most of my clients have, over time, accumulated multiple catalogs that are essentially the same but have been tweaked to meet a specific reporting need.  In the new framework world, these redundant catalogs should be merged into one version of the truth.  If this is not done, maintenance costs skyrocket and administration and code promotion becomes a serious pain point.
•  Best practices - The Cognos catalog migration tools do not move data into a framework that follows best practices.  Only two layers of abstraction are provided requiring additional development work to get to a 3 layer model. If these changes are made to the framework after migration, all migrated reports will likely need to be modified to support the changes.
• Cardinality between query subjects may not be accurate after a migration.
• Many of the new features of the Studios are not leveraged during the migration leaving reports looking stale.

So if the conclusion is to stay away from a straight migration using the provided migration tools then is there a place or reason to use the migration tools at all?  Simple stated - yes.  The migration tools can be of tremendous help when doing the upfront planning and analysis for the upgrade.  In the case where documentation of the legacy reporting environment is limited or non existent, quickly migrating catalogs gives you an easy way to graphically view relationships between query subjects as well as better understand the data at hand.  If there are multiple catalogs to review, having them available in Framework Manager makes comparisons and merge analysis much more straightforward.  Without question, using this information as input to the future state framework design jumpstarts the upgrade and adds value immediately.