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.

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.

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!

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.

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.

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

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

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.

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.

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:
- An enterprise module is made available as a data source
- Power users extend the enterprise modules with their own logic and data in self-service modules
- Content is built using both the enterprise and self-service modules as a data source
- Updates to the enterprise module flow through to all content regardless of which data source was used

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.
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.
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.
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 🙁