IBM Cognos Analytics 12.2.x: Data Modules Are Much More Than a Replacement for Framework Manager

From reusable dimensions and intelligent data modeling to AI: Why Data Modules have become the foundation of a modern BI architecture.

With IBM Cognos Analytics 12.2, it’s time to talk about data modeling again. But this time, I’d like to approach the subject from a different perspective.

Over the past few years, we have repeatedly discussed which features Framework Manager offers that are still missing from Data Modules. For a long time, this discussion was justified. After all, Framework Manager had been the established tool for professional Cognos data modeling for many years.

However, a great deal has changed.

IBM has continuously enhanced Data Modules. Many previous limitations have been eliminated. Other capabilities have been replaced by more modern concepts. And today, Data Modules offer numerous features that Framework Manager either does not provide at all or can only achieve with considerably more effort.

What I find particularly exciting is not even the individual features. It is the opportunity to build an entirely new modeling architecture: with conformed dimensions, reusable Data Modules, automated deployment, and a shared semantic foundation for reporting, dashboards, self-service analytics, and AI.

Anyone who still considers Data Modules a simple tool for Excel users is seriously underestimating their capabilities.

Let’s take a closer look at what Cognos Analytics 12.2.x has to offer.

1. A Modern Architecture Instead of Giant Data Models

Let’s start with what I consider one of the most important capabilities of all: Data Modules can be built on top of other Data Modules.

Many organizations have extensive Framework Manager models containing hundreds or even thousands of objects. These models include data for sales, finance, human resources, production, and numerous other business areas.

Such models have grown over many years. They offer advantages, particularly when it comes to centrally managing measures and dimensions. At the same time, maintaining them can become increasingly complex.

Data Modules allow us to take a different approach.

Instead of combining every table and calculation in one enormous model, we can create smaller, functionally focused Data Modules that build on one another.

Model Conformed Dimensions Once

A particularly useful approach is to start by creating a Data Module containing the shared dimensions of the organization.

These might include Time, Organization, Product, and Customer.

This is where we centrally maintain business definitions: keys, labels, calculations, sort orders, column dependencies, and other metadata.

We can then create a separate Data Module for each business area.

The Sales model uses the shared dimensions and adds the Sales fact table.

The HR model uses the Time and Organization dimensions and adds its personnel facts.

The Finance model uses the relevant shared dimensions and adds financial data.

The dimensions do not need to be modeled or copied again. They are included as linked objects from the central Data Module.

[IMAGE 1 – MODULAR DATA MODELING – CONFIRMED]

Insert the previously created diagram “Central Data Module: Conformed Dimensions,” showing the four dimensions Time, Organization, Product, and Customer, together with the three dependent data marts: Sales, HR, and Finance.

Caption: A shared semantic foundation for multiple business data marts. Each fact table extends the centrally maintained dimensions it requires.

Maintain Changes Centrally

The real advantage becomes apparent during ongoing maintenance.

For example, if a calculation or label in a shared dimension changes, the linked Data Modules can inherit that change.

The corresponding tables remain linked to their source Data Module.

Relationships that have already been modeled can also be included as referenced relationships. New relationships between shared dimensions and the relevant fact tables are added in the business-specific Data Module.

This makes collaboration between multiple modelers considerably easier.

Of course, changes to central dimensions must be tested carefully. A modified key structure may affect several data marts.

But that is precisely why centralized maintenance makes sense: business definitions are managed in one place rather than gradually diverging across numerous independent models.

Multi-Level Models Are Also Possible

Nesting does not have to stop at two levels.

An existing Sales Data Module, for example, can become the foundation for a specialized Sales Controlling model.

Additional planning data, calculations, or business-specific filters can be added at that level.

This allows us to distinguish between enterprise-wide conformed data, business data marts, and specialized analytical requirements.

The physical data does not have to be stored multiple times. Initially, only the modeling objects are referenced.

However, it is important to keep the number of modeling layers manageable. IBM also points out that excessively deep nesting can make troubleshooting and maintenance more difficult.

For me, this modular architecture is one of the biggest advances over the traditional approach of working with large, centralized Framework Manager models.

And the best part? The creation of these Data Modules can also be automated. More on that later.

2. Intent Modeling: Cognos Helps Build the Data Model

Data Modules provide useful assistance right from the beginning.

With Intent Modeling, Cognos can suggest suitable tables for a particular business use case.

To do this, the system analyzes metadata, table names, columns, data types, and statistical properties.

Users select relevant business terms from a word cloud or enter their own search terms.

Based on this information, Cognos suggests tables and attempts to identify fact and dimension tables.

Ideally, the result is already a suitable star or snowflake schema.

The suggestions are displayed with confidence scores and can be accepted or modified.

This is especially helpful when business users or modelers are not yet fully familiar with a large database.

Of course, a suggested model must still be reviewed from a business perspective. Automated modeling does not replace an understanding of the underlying data.

Nevertheless, it is remarkable how much assistance Cognos now provides when creating a new Data Module.

[IMAGE 2 – INTENT MODELING]

Screenshot of Intent Modeling showing the word cloud and an automatically suggested data model.

Caption: Cognos assists data modeling by automatically identifying relevant tables and relationships.

3. Automatic Relationships and Complex Joins

Once the tables have been selected, their relationships must be defined.

Cognos provides assistance here as well.

The Autojoin algorithm examines column names, data types, semantic properties, and overlapping values, among other things.

Based on this information, it suggests suitable join columns and cardinalities.

The results can be reviewed and adjusted in the graphical relationship diagram.

Complex Joins Are No Longer a Problem

One frequently mentioned argument against Data Modules was their limited support for complex join conditions.

That limitation is now outdated.

Since Cognos Analytics 12.1.1, a dedicated Relationship Expression Editor has been available.

This allows relationships to be defined using custom expressions.

For example, a relationship can be based not only on a cost center ID but also on a validity period.

The actual expressions that can be used naturally depend on the data sources involved and the query processing capabilities.

Data Modules also support the definition of join types, cardinalities, and join optimization options.

This becomes particularly interesting when working with different data sources. Cognos can retrieve key values from one source and pass them as filters to another.

This can reduce the amount of data that needs to be transferred for local processing.

When combining different database systems or supplementary departmental data, this can provide significant performance benefits.

Bridge Tables and Different Levels of Granularity

Professional modeling scenarios involving many-to-many relationships are also supported.

Data Modules include the table usage property Bridge.

This tells the Query Service that a table represents a bridge table rather than a regular fact table.

Summary tables can also be modeled using the appropriate properties.

These are important capabilities for professional relational models, not merely features intended for simple self-service applications.

4. Column Dependencies: Determinants Exist in Data Modules Too

Anyone who has worked with Framework Manager for a long time will be familiar with determinants.

They describe functional dependencies and different levels of granularity within a table.

In Data Modules, this functionality is called Column Dependencies.

It serves the same fundamental purpose and can even represent multiple dependency hierarchies within a single table.

Consider a simple example.

A table contains daily sales figures and monthly planning values.

The monthly target must not be summed again for every individual day when aggregating the data.

Column Dependencies help Cognos recognize the actual granularity of the values and avoid double counting.

IBM demonstrates precisely these scenarios in its documentation.

This is essential for models that combine facts at different levels of granularity.

It is important, however, that Column Dependencies are defined correctly. They are automatically created for certain source tables but may need to be updated when structures change or custom tables are introduced.

What is sometimes described as an exclusive Framework Manager advantage has therefore been available in Data Modules for quite some time – simply under a different name.

5. Navigation Paths: Drill-Down Without Rigid Hierarchies

One feature I particularly appreciate is Navigation Paths.

In Framework Manager, multidimensional navigation often requires DMR models with dimensions, levels, and hierarchies.

That is powerful, but it is not necessary for every analysis.

Data Modules offer a much more flexible approach through Navigation Paths.

Of course, we can define traditional hierarchies such as Year, Quarter, Month, Day or Product Group, Product Line, Product.

But here is the interesting part: The columns in a Navigation Path do not have to represent a genuine business hierarchy at all.

We can combine different attributes that make sense from an analytical perspective, even if they originate from different tables.

Example: Which Products Are Purchased Through Which Order Methods?

Imagine a Navigation Path defined as:

Order Method ? Product Line ? Product

A user starts with a chart showing revenue by order method.

They can see how much revenue was generated through online orders, telephone orders, or the sales force.

The user then drills down into one particular order method.

Cognos displays which product lines were purchased through that selected order method.

Another drill-down reveals the individual products.

What makes this interesting is that Order Method and Product Line normally belong to two different dimensions. They do not form a traditional parent-child hierarchy.

Nevertheless, they can be combined in a single Navigation Path.

The same approach works with Product, Customer, State, and City. IBM even uses this exact type of combination as an example in its documentation.

We can define multiple Navigation Paths and reuse the same columns in different paths.

Users can follow the predefined sequence or navigate directly to another column within the path.

Naturally, the underlying tables must have valid relationships. A Navigation Path does not replace missing joins.

But for many typical drill-down requirements, a complete DMR model is simply no longer necessary.

[IMAGE 3 – FLEXIBLE NAVIGATION PATHS]

Example Cognos dashboard: Revenue by Order Method, followed by a drill-down result showing Product Lines and then individual Products. The selected Order Method should be visible as a filter.

Caption: Navigation Paths allow users to move between different business dimensions without requiring a traditional dimensional hierarchy.

6. Finally, Sort Data the Way It Makes Sense: January, February, March

A seemingly small feature can have an enormous impact on everyday reporting: custom sorting of attributes.

We all know the problem.

A report contains month names, but they are sorted alphabetically:

April, August, December, February, January …

Obviously, the correct business sequence should be:

January, February, March, April, May …

Data Modules provide several ways to achieve this.

Automatic sorting: Cognos can recognize months, weekdays, and seasons and automatically generate an appropriate chronological sort order.

Manual sorting: Custom Sort Order allows values to be arranged in any required sequence.

Sorting by another column: A month name can be sorted using its numeric month value.

The same applies to status values, priorities, process stages, and other business-specific sequences.

Manual sorting supports up to 100 members. For larger sets of values, a dedicated sort index can be used.

What makes this particularly interesting is that the sort definition is stored in the metadata of the database schema or uploaded file.

Other Data Modules using the same source can therefore benefit from the same definition.

Once the correct business sort order has been defined, it does not need to be maintained separately in every data mart.

Framework Manager does support member sorting within DMR dimensions. However, it does not provide an equally convenient central sorting mechanism for arbitrary relational attributes.

[IMAGE 4 – CUSTOM SORT ORDER]

Comparison showing incorrectly alphabetically sorted month names and the correct chronological order. Optionally include a screenshot of the Cognos Custom Sort Order editor.

Caption: Business-specific sort orders are defined once and can then be reused centrally.

7. Define Relative Dates and Calendar Logic Centrally

Hardly any BI application can function without time comparisons.

Current Year, Previous Year, Year-to-Date, Prior Year-to-Date, Current Month, and rolling periods are standard requirements in business analytics.

Data Modules provide Relative Date Calendars for exactly this purpose.

Once an appropriate date column has been associated with a relative date calendar, numerous time filters and time-based measures become available.

These include Current Year (CY), Prior Year (PY), Year-to-Date (YTD), Prior Year-to-Date (PYTD), and other periods.

Fiscal calendars can also be supported.

Another interesting option is the use of a dynamic reference date.

The global parameter _as_of_date allows the modeler to specify the date on which relative time calculations should be based.

This makes historical as-of-date analyses easier and allows reports to be evaluated as if they were executed at an earlier point in time.

Once again, the advantage lies in centralized modeling.

Previous-year calculations or cumulative year-to-date values do not have to be developed separately in every report.

Cognos also includes specific query optimizations for relative date measures to improve performance.

8. Central Filters, Intelligent Prompts, and Data Groups

Data Modules allow business filters to be defined centrally.

A distinction is made between embedded filters and selectable filters.

An embedded filter is always applied to the relevant table.

A selectable filter, on the other hand, is made available to users as an additional option in the Data Module.

Typical examples might include active customers, current products, specific fiscal years, or approved organizational units.

Users do not need to write the filter logic themselves. Instead, they can select predefined business filters.

Display Values and Filter Values Do Not Have to Be Identical

Another useful feature is the Filter By property.

For example, a prompt can display a month name while Cognos internally filters using the numeric month value.

The user selects “January,” but the query uses the value 1.

This is also relevant when automatically building prompt pages in Reporting.

Additional parameters and prompts can be defined using macros such as prompt() and promptmany().

Parameter Maps from Framework Manager can often be replaced with mapping tables and the queryValue() macro function.

Data Groups: Group Values Without Programming

Interactive data grouping is another feature available directly in Data Modules.

Customers can be grouped into revenue bands, employees into age groups, or products into custom categories.

For numeric values, ranges can be generated automatically and subsequently adjusted.

This is particularly useful when business users need additional analytical categories without creating new database tables or writing complex CASE expressions.

9. Excel Is No Longer an Outsider in the BI Architecture

Let’s move on to a topic that has been important to me for a long time: Excel.

Many organizations have built powerful data warehouses. Nevertheless, business departments continue to use Excel files.

These files contain planning figures, budgets, special calculations, mappings, and other supplementary information.

And that is unlikely to change.

The question should therefore not be how to eliminate Excel from business departments.

A much more important question is how to integrate this data into our BI architecture in a controlled manner.

Data Modules provide excellent capabilities for doing exactly that.

Excel files can be uploaded and connected directly to existing database tables.

For example, planning figures from Excel can be combined with actual figures stored in a relational data warehouse.

Cognos can also use join optimization to improve query processing across different data sources.

Store Excel Uploads Directly in Db2

Even more interesting is the ability to store uploaded files and Cognos Data Sets directly in a supported Db2 database.

Since Cognos Analytics 12.0.2, IBM has supported a dedicated Data Sets Store.

With the appropriate configuration, newly uploaded files and Data Sets are stored as relational tables in Db2.

Queries are then processed by Db2 rather than using the Parquet-based Compute Service.

This provides additional opportunities for processing larger data volumes.

The data is stored in a specifically configured Db2 environment, with the tables managed by Cognos. It is therefore not simply a matter of uploading data into an arbitrary existing data warehouse table.

Suitable Db2 LUW or Db2 Warehouse environments can be used, subject to the required configuration for analytical workloads.

Automatically Update Excel Files

And there is more.

The Cognos REST API can be used to create or replace uploaded files automatically.

For example, a scheduled process can regularly provide updated Excel planning data.

The Data Modules based on these files remain in place and use the updated values.

As long as the required table structure remains compatible, the associated reports and dashboards do not need to be rebuilt every time.

A manual Excel upload can therefore become an automated and controlled data provisioning process.

I consider this a major step forward.

After all, if we do not offer our users these capabilities, we risk having them build their departmental analytics entirely outside the BI platform.

[IMAGE 5 – EXCEL AND DB2]

Architecture diagram showing Excel files, automated updates through the REST API, the Cognos Data Sets Store in Db2, a relational data warehouse, and a shared Data Module. Reporting and Dashboards should appear as the resulting applications.

Caption: Excel data can be automatically integrated into a centrally managed BI architecture.

10. Data Preparation and Custom Tables Directly in Data Modules

In addition to integrating different data sources, Data Modules provide numerous data preparation capabilities.

For example, users can remove whitespace, modify strings, handle NULL values, or transform selected column values.

Basic calculations can also be created directly through the user interface.

Modelers do not have to write every transformation manually in SQL.

Of course, this does not replace a professional ETL process for an enterprise data warehouse.

However, it is extremely useful for supplementary departmental data or specialized requirements.

Custom Tables: SQL Modeling Through a Graphical Interface

Custom Tables are even more interesting.

They can be used to create views, aliases, joins, unions, intersects, and except operations.

For example, sales figures from several subsidiaries can be combined into one business table using a union.

Existing tables can also be combined through a join to create a new logical table.

These definitions are stored centrally in the Data Module and become available to all reports and dashboards based on it.

Tables can also be created using custom SQL.

The Cognos modeling environment supports IBM Query SQL, Native SQL, and Pass-Through SQL, subject to their respective technical requirements.

For larger data models, this is a significant advantage: business data preparation is defined once rather than recreated in every individual report.

[IMAGE 6 – CUSTOM TABLES]

Screenshot of graphical Custom Table modeling using a union or join. Ideally, show the source tables and the resulting logical table.

Caption: More complex data structures can be modeled directly in a Data Module and reused across applications.

11. Different Data Sources – Including Existing Cognos Models

Data Modules can combine a wide variety of sources.

These include relational data servers, uploaded files, Data Sets, other Data Modules, and suitable Framework Manager packages.

This is especially interesting for organizations that already have an extensive Cognos environment.

An existing relational Framework Manager package using Dynamic Query Mode can serve as the source for a new Data Module.

This makes it possible to extend existing models with additional data and capabilities without first replacing the entire Framework Manager project.

OLAP cubes can also serve as the basis for Data Modules.

Multi-cube support was expanded in version 12.1.3.

IBM has also improved support for stored procedures.

Naturally, the relevant capabilities and restrictions must be considered. For example, including existing cubes is not the same as providing complete DMR modeling functionality.

Nevertheless, it is clear that Data Modules are no longer limited to simple relational data sources.

12. Metadata Management: Simpler, More Flexible, and More Independent

Another difference between Framework Manager and Data Modules becomes apparent during ongoing maintenance.

When the structure of a database changes, an appropriately authorized modeler can reload the metadata directly from the Data Module.

New columns can be added, removed columns can be identified, and affected model objects can be updated.

The initial provisioning of a database schema remains an administrative task. However, modelers can be granted the necessary permissions for subsequent updates.

Metadata Snapshot

The Metadata Snapshot feature is particularly interesting.

It allows a local representation of database metadata to be stored within the Data Module.

Modelers can continue working with this metadata even if the underlying database metadata is temporarily unavailable or changes are being made on the database side.

It can also reduce the need to repeatedly retrieve metadata from the data source during modeling.

However, a snapshot does not contain business data. Executing reports still requires access to the underlying data.

Creating and updating a Metadata Snapshot requires administrator privileges.

Replace Sources and Reuse Models

With Relink Sources, Data Modules can be redirected to other compatible data sources.

This is useful, for example, when moving from a development environment to production.

If the required tables, keys, and data types are compatible, existing calculations and relationships can remain intact.

Dynamic Source Overrides provide even greater flexibility.

They allow data server connections, schemas, or catalogs to be selected at runtime, for example based on session parameters.

This is particularly interesting for multi-tenant applications or environments with different system configurations.

Framework Manager also supports dynamic data sources. However, Data Modules make this functionality directly accessible through properties in the browser-based modeling interface.

13. Intelligent Metadata and Multilingual Models

Data Modules can enrich attributes with additional semantic information.

For example, a column can be identified as representing a country, city, geographical region, month, or year.

Cognos uses this information to recommend suitable visualizations and support capabilities such as maps and time-based analyses.

A technical column becomes a business attribute with a recognizable meaning.

This is particularly important for self-service analytics and AI.

A data source should not merely expose technical table and column names. It should describe the meaning of the data as clearly as possible.

Multilingual Metadata

Data Modules also offer interesting multilingual capabilities.

Labels, descriptions, and other information can be maintained in several languages.

Translations can be retrieved from external files or database tables.

As a result, language changes do not necessarily require the Data Module itself to be edited again.

Cognos also supports multilingual business data, for example through language-dependent rows or columns.

Depending on the use case, macros and mapping tables can be used to select the appropriate language.

This enables international data models to be managed centrally.

However, the documented scope of dynamic metadata translation is not identical across all Cognos components. In particular, the current support in Reporting needs to be considered.

14. Performance Optimization Directly in the Data Model

Naturally, Data Modules must also meet the requirements of large enterprise applications.

Several capabilities are available for this purpose.

In addition to the join optimization already discussed, Column Dependencies can help prevent incorrect double counting.

Bridge tables and summary tables can also be identified using the appropriate properties.

Data Caching

Caching can be configured at the source or table level.

Modelers can specify whether results should be cached and how long they remain valid.

Macro-based control is also possible.

Cognos can reuse identical or compatible query results.

Importantly, security contexts are taken into account. Cached data must not simply be shared between users with different access permissions.

Data Module caching also does not apply equally to every source type. Restrictions apply to OLAP cubes, Data Sets, and uploaded files.

Control of Generated SQL

Another useful detail is the Item List property.

It allows modelers to control whether Cognos includes every column of a table in the generated SQL or only the columns actually required by the query and its joins.

Generated SQL can also be examined directly from the modeling environment.

In addition, Data Modules provide data previews, expression validation, and graphical relationship diagrams.

These capabilities are important because good performance does not automatically result from choosing a particular modeling tool.

It results from a technically and functionally sound data model.

Data Modules now provide a broad range of tools to support this process.

15. Self-Service Does Not Mean Giving Up Governance

A common argument against self-service analytics is the concern that users will create uncontrolled data models.

But that does not have to be the case.

Data Modules offer several ways to centrally control modeling permissions and data access.

Administrators can, for example, restrict certain roles from editing relationships, calculations, or security definitions.

This allows a business user to extend a model with additional information without being able to modify every centrally managed modeling feature.

Row-Level Security

One particularly important capability is the ability to define data security at the data server metadata level.

For example, permissions can determine which regions, cost centers, or organizational units a user may access.

The security definition then applies to Data Modules using the same protected data server objects.

This avoids maintaining identical security rules in multiple places.

However, the security architecture must be implemented correctly. In particular, custom SQL access may need to be restricted administratively because it could otherwise bypass security filters.

This is not a detail that should be overlooked. It is an essential part of professional governance.

Data Modules Directly in the Cognos Portal

Another advantage is their integration into the regular Cognos user interface.

Data Modules are stored in the Content Store just like reports or dashboards, and permissions can be assigned there.

No separate Windows client is required.

Changes also do not have to go through the traditional package publishing process.

Modelers can test calculations and relationships directly and then create reports or dashboards based on the saved Data Module.

This makes the entire development process considerably more accessible.

16. Automation and Version Control: Data Modules as Part of the Development Process

Let’s return to the modular architecture.

It becomes especially interesting when we automate the creation and management of Data Modules.

The Cognos REST API allows Data Modules to be created and updated using their model specifications.

This means standardized data marts can be generated according to defined rules.

For example, a new departmental data mart could automatically reference the required dimensions from a central Data Module and then add its fact tables.

Relationships, calculations, properties, and other model components can also be represented in the model specification.

Naturally, such generators must be carefully developed and tested. The REST API provides the technical capabilities, but it does not guarantee that a generated model is functionally correct.

Version Control with Git

With integrated source control support, Data Modules can also be versioned in Git repositories.

This allows model changes to be documented, different versions to be compared, and previous versions to be restored.

Together with automated deployments, Data Modules can become part of a structured development process.

This is particularly interesting for organizations operating separate development, test, and production environments.

[IMAGE 7 – AUTOMATED DATA MART CREATION]

Architecture diagram: Central Dimensions Model and Data Mart Templates ? Automated Model Generation through the Cognos REST API ? Sales, HR, and Finance Data Modules ? Git Version Control and Deployment.

Caption: Reusable Data Modules enable a standardized and largely automatable data mart architecture.

Technically, their management is becoming increasingly similar to that of other modern development artifacts.

What remains important is professional impact analysis when changes are made. Git documents model versions, but it does not automatically replace a complete analysis of every dependent report.

17. AI Is Now Supporting Data Modelers Too

Artificial intelligence is no longer limited to the analysis of data.

IBM is now developing capabilities that provide assistance during data modeling itself.

One example is AI-assisted calculation creation.

A modeler can describe the required calculation in natural language.

Possible requests might include:

“Calculate profit per item sold.”

Or:

“Divide revenue into five categories.”

The assistant can generate a corresponding calculation expression and offer to add it to the Data Module.

IBM currently documents this capability as a Preview feature.

Its functionality is therefore restricted. Among other things, the current implementation requires a Data Module containing only one data source.

The suggested expressions must, of course, be reviewed.

Nevertheless, this capability clearly demonstrates the direction in which data modeling is evolving.

Intelligent assistants are increasingly becoming part of the modeling process.

18. The Shared Semantic Layer Is Becoming Essential for AI

In my view, this is the most important strategic point.

With Cognos Analytics 12.2 and the new AI capabilities, semantic modeling takes on a completely new significance.

Until now, we have had to ensure that reports and dashboards use the correct measures, relationships, and calculations.

In the future, AI agents will also need to understand what our business data actually means.

Technical table and column names are not sufficient for this.

An AI agent needs to understand which measure represents revenue, how a fiscal year is defined, which dimensions can be combined, and which data a particular user is permitted to access.

That requires a well-maintained semantic layer.

The Query Agent in Cognos Analytics 12.2

The new Query Agent allows users to ask questions about business data in natural language.

It can generate SQL queries and present results through visualizations and explanations.

IBM documents Data Modules as the supported data source for this agent.

This makes the choice of modeling environment increasingly important when deciding which new AI capabilities can be used directly.

Of course, this does not mean that Framework Manager packages are fundamentally irrelevant to AI.

Other Cognos capabilities and products such as watsonx BI can continue to use Framework Manager packages, depending on their technical configuration.

The availability of Query Agent also depends on the edition, licensing, and deployment environment.

Nevertheless, the direction of development is clear.

Reporting, Dashboards, Self-Service, and AI Share the Same Business Foundation

Imagine an organization that centrally maintains its measures, dimensions, and business descriptions in reusable Data Modules.

A report uses this metadata.

A dashboard uses the same definitions.

A business user adds their own Excel data on top of this foundation.

And an AI agent uses the semantic information to interpret natural-language questions.

The business definitions do not need to be recreated separately in every tool.

That is the real strength of this architecture.

Not every analytical tool maintains its own understanding of revenue, customers, product lines, or time periods.

Instead, they share a common semantic foundation.

And the more AI capabilities become available, the more valuable consistent semantic modeling will become.

[IMAGE 8 – SHARED SEMANTIC LAYER]

Diagram showing a central Data Module or modular semantic layer, connected to Reporting, Dashboards, Exploration/Self-Service, and AI Agents. Data servers, Excel files, and Data Sets can be shown as the underlying sources.

Caption: Semantic modeling connects traditional business intelligence with self-service and AI-powered analytics.

19. And Framework Manager? At Least It Is Now 64-Bit!

Despite my enthusiasm for Data Modules, there is one important improvement in Framework Manager that deserves recognition.

With Cognos Analytics 12.2.0, Framework Manager is now available as a native 64-bit application for the first time.

This is a welcome and long-overdue modernization.

Previously, Framework Manager was limited by its 32-bit architecture and the amount of addressable memory.

This could become problematic with very large models.

The native 64-bit version allows better memory utilization and can improve stability and performance when working with extensive models.

Existing models remain fundamentally compatible. As usual, an upgrade should be tested carefully.

This improvement demonstrates that IBM continues to support Framework Manager.

That matters, because many organizations have extensive and proven models that they do not intend to replace in the short term.

However, the transition to 64-bit is a technical modernization, not a fundamental expansion of Framework Manager’s modeling capabilities.

That is the key difference compared with Data Modules.

While Framework Manager primarily continues to support existing applications, Data Modules regularly receive new functionality.

20. What Advantages Does Framework Manager Still Have?

Of course, a comparison like this also needs to address which capabilities are still exclusive to Framework Manager or better supported by it.

In my view, two areas remain particularly relevant.

Object Security

Framework Manager allows permissions to be defined on individual model objects.

This makes it possible to control which Query Subjects or Query Items particular users can see.

Data Modules support row-level data security, permissions at the module level, and differentiated control over modeling capabilities.

However, fully equivalent role-based object security within a single Data Module is not available.

Depending on the application, this can be addressed through separate Data Modules, database-level permissions, or other security concepts.

But complete functional equivalence does not exist.

DMR Modeling

The second major area is full Dimensionally Modeled Relational (DMR) functionality.

Framework Manager allows relational data to be modeled multidimensionally using hierarchies, levels, members, and corresponding OLAP functions.

Data Modules support Navigation Paths, relative date calculations, and access to supported OLAP cubes.

However, they do not replace the complete DMR semantic model.

Framework Manager may therefore still be required for complex member-based calculations, MDX, and existing dimensional applications.

For many typical drill-down requirements, however, the flexible Navigation Paths in Data Modules are more than sufficient.

Other Specialized Capabilities

There are also individual differences involving features such as the direct import of database user-defined functions, certain prompt properties, specific SAP HANA scenarios, or integrated report dependency analysis.

Some of these have alternative implementations, while others do not have fully equivalent solutions.

These specialized scenarios should be examined when planning a migration.

For the vast majority of new relational applications, however, they are not a fundamental argument against Data Modules.

21. IBM’s Official Comparison List Is No Longer Sufficient

IBM continues to publish a list of Framework Manager features that are not supported, or not fully supported, by Data Modules.

Unfortunately, parts of this list no longer reflect improvements introduced in recent Cognos releases.

For example, complex joins are still presented as a limitation, even though the Relationship Expression Editor has been available since version 12.1.1.

Data Modules are also now supported by Event Agent.

Multi-cube support, stored procedures, and other capabilities have been expanded as well.

Other features appear to be missing simply because Data Modules implement them differently.

Determinants, for example, are called Column Dependencies. Parameter Maps can often be replaced by mapping tables and queryValue(). Namespaces are not required in the same way because Data Modules use unique object identifiers.

But the real problem is something else.

The comparison almost exclusively asks which familiar Framework Manager features are missing from Data Modules.

It barely considers the numerous additional capabilities that Data Modules offer.

Yet these capabilities are now decisive when choosing a modeling environment.

It would therefore be desirable for IBM to completely revise its official comparison.

The question is no longer simply whether Data Modules can replace Framework Manager.

The question is why anyone would want to give up so many possibilities when developing new applications.

22. Does This Mean We Must Migrate Every Framework Manager Model?

No, certainly not.

There is no reason to replace working applications simply because a more modern tool is available.

Large Framework Manager models with extensive report dependencies, specialized security concepts, or DMR functionality can continue to serve their purpose.

The new 64-bit version even improves their technical outlook.

Nevertheless, whenever a major enhancement is planned, I would recommend evaluating whether new business areas could already be implemented using Data Modules.

Existing relational packages can be used as sources for Data Modules under certain conditions.

This makes it possible to reuse existing models and gradually extend them with new capabilities.

A complete migration is not always necessary.

For new relational models, however, I believe the decision has become very clear.

Conclusion: Data Modules Are the Foundation of a Modern Cognos Architecture

When I look at how Data Modules have evolved over the past few years, the progress is impressive.

Initially, they were primarily intended as a simple modeling tool for business users.

Today, they provide numerous capabilities for professional enterprise data models.

Automatic modeling suggestions, intelligent relationships, complex joins, bridge tables, and Column Dependencies support sophisticated relational modeling.

Navigation Paths, custom sorting, relative date calculations, central filters, and Data Groups make subsequent analysis considerably easier.

Excel uploads, Data Sets, Db2 storage, and automated updates open up entirely new opportunities for integrating departmental data.

Metadata Snapshots, source relinking, multilingual metadata, and Git version control support professional development processes.

And with AI capabilities such as Query Agent, semantic modeling is increasingly becoming the foundation for an entirely new approach to data analysis.

My Personal Highlight: Modular Data Modeling

What impresses me most, however, is the ability to reuse and nest Data Modules.

We no longer have to build one enormous model containing every business area and data structure.

Instead, we can create conformed dimensions once and reuse them across as many business data marts as necessary.

The relevant fact tables are added, relationships are defined, and the required measures are provided.

The entire process can be standardized, versioned, and largely automated.

This creates a BI architecture that can be centrally governed while still allowing decentralized extensions.

In my view, that is exactly the right direction for modern business intelligence.

Framework Manager remains a proven tool for existing applications and certain specialized requirements. With Cognos Analytics 12.2, it has at least received the important upgrade to 64-bit.

However, innovation in data modeling has been taking place primarily in Data Modules for years.

And with a shared semantic foundation for reporting, dashboards, self-service analytics, and AI, their importance will continue to grow.

My recommendation is therefore clear: Anyone developing a new relational Cognos application today should start with Data Modules – and only turn to Framework Manager when specific requirements make it necessary.

I will continue following this development in future Cognos releases. After all, the question of whether Data Modules can keep up with Framework Manager has essentially become outdated.

The much more interesting question is what new capabilities IBM will introduce next.