• Skip to main content

IBM Blueview

Cognos Analytics and all things IBM

  • The Blog
  • Cognos Glossary
  • Cognos Resources
  • About Me
  • Categories
    • Cognos
      • Data Modules
      • Administration
      • Framework Manager
      • Dashboards
    • Opinion
    • Community Spotlight
  • PMsquare
  • Subscribe

Cognos Analytics Linked Modules

October 29, 2019 by Ryan Dolley 4 Comments

If you’ve been following this blog you know that I love Cognos data modules to death. They are easy to learn, easy to use and full of functionality. Today we’re going to explore using Cognos Analytics Linked Modules to maintain enterprise data governance while enabling self-service. This entry is meant to give a straightforward implementation guide to reinforce concepts outlined in the posts Data Modules as a Single Source of Truth and How to Organize Cognos for Self-Service.

Companies do not have to choose between governance and self-service
Like Jedi vs Sith… can you truly have both?

How and why of linked modules

Using linked modules is a slam dunk way to enable self-service analytics on a foundation of trusted and governed data. When you link two modules you are a creating a relationship in which:

  • The IT expert can build and maintain a complex module with high quality data that requires significant skill to create
  • The power user can utilize high quality data as a foundation for analysis but customize and extend at their own pace, not IT’s
  • The casual user can build dashboards and run reports that meet their needs without waiting for IT

This works so well because the modules of the power user automatically inherit all the complex relationships, transformations and logic from the enterprise module prepared by IT in near real-time without having to do anything. It’s magic.

Step 1: Build an enterprise data module

The enterprise module is typically – but not always – built by IT, more often than not the result of a much longer process of data warehouse design and ETL. Regardless of how its created or what it contains the enterprise module will server as our example though any two modules can be linked together.

Any data module can serve as a source for another data module
The enterprise module serves as the source / parent when linking data modules

Our example uses ‘Great outdoors data module’ from the Cognos samples. This module is located in the data folder. Once built the enterprise module resides in a folder where self-service users can easily access it. I advocate creating a data library folder for this purpose.

Step 2: Use a data module as a source

IT has built and deployed an enterprise module with validated and accurate data, which takes a long time. Now a power user needs to extend that module with some additional context and can’t wait for IT to do it. The solution is simple: use Tableau Build a new data module using the enterprise module as a source!

Adding a data module source is no different from adding any other source
Adding a data module source is extremely easy, fun and profitable

When creating a new data module, users can select other modules as sources in the ‘select sources’ screen. In our example, select ‘Great outdoors data module’ and hit ‘OK’. That’s it. We’ve built a linked module.

Data module sources appear in teal and have a link icon
A linked module has visual cues to let you know that it is indeed a link

The tables above appear in teal rather than blue and have a link icon, indicating that they are actually inherited from another module. At this point any changes made to the tables of ‘Great outdoors data module’ will automatically flow through to this module with absolutely no intervention.

Step 3: Extend the enterprise module

You’ll notice that the teal linked tables do not offer much in the way customization by design. They inherit everything from the parent module. This means users cannot change what comes from the enterprise module but they can extend it with additional logic and data.

Linked tables don't have all the options of normal tables as you're trying to preserve governance.
No options = no opportunity to mess with governed data

Cognos restricts us to creating data groups, navigation paths and editing some properties for product line – a far cry from what is available in the source module. However we still have considerable power to extend the enterprise module. Let’s look at some examples.

Creating calculations

Linked module calcs work as expected

In the example above the calculated field ‘Revenue Variance Amount’ contains the fields ‘Revenue’ and ‘Planned Revenue’ from the sales table. This custom calculation is built entirely using elements inherited from our enterprise module. At many of my customers such a simple request spends weeks or months in the IT backlog but here we accomplish it in minutes while still using centrally modeled and governed data. Yowza!

Adding additional data

Adding additional data is easy

Here I join a Cognos data set called ‘Sales Staff Analysis’ to the tables from the enterprise module via two conjoined dimensions. Joining a spreadsheet is just as easy, which is what the vast majority of power users want to do.

These are just two examples of extending an enterprise module using the linked module functionality. Users can do almost everything data modules have to offer while still relying on trusted data, including building table views and aliases, creating drill paths, custom grouping and filter, row level security, etc…

Step 4: Watch the linking magic in action

Before the module can be used it must be saved. Users typically save modules to ‘My content’ but it is critically important that you allow them to save self-service modules to a location where they can easily share with coworkers. Now let’s close this module and test our module link.

Almost all changes made to the source module flow through

Here I create a new calculation in our enterprise module called ‘Revenue Percent Variance’ and click ‘Save’. I then immediately create a dashboard using the self-service module as a data source. Keep in mind that I made absolutely no updates to the self-service module before doing so.

The changes flow through just like magic!

As you can see, ‘Revenue Percent Variance’ is immediately available for use in Dashboards even when they reference the self-service module rather than the enterprise module.

Putting it all together

Allow me to summarize what we just did:

  1. An enterprise module is made available as a data source
  2. Power users extend the enterprise modules with their own logic and data in self-service modules
  3. Content is built using both the enterprise and self-service modules as a data source
  4. Updates to the enterprise module flow through to all content regardless of which data source was used
Single source of truth meets self-service

Nobody but Cognos offers this combination of data governance and self-service. It’s a game changer for organizations who truly embrace it. Book some time with me to explore these ideas further (there’s a link on the screen) and be sure to check out my live impressions of the recent 11.1.4 release.

Filed Under: Cognos, Data Modules

Reader Interactions

Comments

  1. MR says

    September 23, 2020 at 7:51 am

    There are a number of problems with this approach.

    When you link to your enterprise data module, you cant just bring in a bit of it. Its all or nothing, The end user who just want the sales fact table will have to bring in all the tables, then delete the ones they dont want.

    Only tables are linked from the enterprise model. Everything else is a copy, For example in your enterprise model you create measures, filters and navigation paths. If any of those come in when you link they are copies. What happens if we change the definition in the enterprise model.

    Reply
    • Ryan Dolley says

      September 23, 2020 at 8:30 am

      I honestly hadn’t even thought to test whether objects outside of tables were also linked. My mistake it turns out.

      I’ve cataloged these issues and brought them directly to data modules product management. We’ll see what they say. It’s an unfortunate reality that things like this are constantly falling through the cracks with new Cognos features. Ridiculous.

      Reply
  2. Bastiaan Krijgsman says

    October 7, 2020 at 10:59 am

    Today I started with this approach. I created a “base” datamodule with a fact table and dimension tables.
    After that I created a new linked module and extended this module with some extra functionality. So far so good.

    At this point I extended the “base” module with a new custom table. I reopened the linked module and I have to add the extra tables manually. When selecting the grid you will receive a error message about a missing relation.

    When I create a new linked module after the modification of the base model it works!

    From the moment IBM introduced the data module, it is one step forward two steps back 🙁

    Reply

Trackbacks

  1. Confluence: Data and Analytics Services says:
    March 3, 2020 at 4:15 pm

    Modeling using Cognos Data Modules

    What’s New Release 11.1.5 – December 2019 Members

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Copyright © 2023 · Atmosphere Pro on Genesis Framework · WordPress · Log in