IBM Cognos TM1 Performance Modeler and Architect: Potential Collaboration Pitfalls

IBM is encouraging developers to use Performance Modeler as the main tool for creating and maintaining TM1 server objects. Performance Modeler offers many features that Architect simply does not provide. The push toward Performance Modeler is evident in IBM’s documentation, presentations, and rapid update releases for the tool. For now, Architect will still exist and will continue to serve as a development tool. As future releases of Performance Modeler provide more and more functionality, Architect will likely only be used to maintain older TM1 versions going forward.

There is a learning curve for developers transitioning their Architect skillset to Performance Modeler. The biggest challenge seems to be maneuvering through the newer tool to perform tasks previously executed in Architect. This knowledge gap is one of the big reasons that some organizations may want to try and develop TM1 server objects using both tools in parallel. While this approach may seem simpler, it can actually cause a variety of issues, some of which will be addressed below.

Rule Driven Links

When creating and saving a rule-based Performance Modeler link, the system will auto generate the rules for the target cube and publish them to the rule editor. If the Generate Feeders option is turned on, the feeders will also be auto generated and published to the rule editor for the source cube.

When opening the rule editor for a link driven rule or feeder, the developer will only have the ability to view, copy, or move the rule or feeder regions.

When opening the rule editor for a link driven rule or feeder in Architect, the developer will have full edit rights to the rule or feeder, meaning they can edit, delete, or cut the rule or feeder. If the user saves the changes, the auto generated code is overwritten.

In order for the link rules to be repopulated, the developer must open the link through Performance Modeler and make a change to the link for a save option to retrigger.

Turbo Integrator Process Generation Data Source ID Issues

When creating and saving a Performance Modeler Turbo Integrator process using a database connection, ID and password issues can arise when opening the same process in Architect. The issue does not occur when creating a data source in Architect and opening the Turbo Integrator process in Performance Modeler. Although this issue is minor and it is easy to reconnect the User ID and password, this can be a challenge on larger projects or if IDs or passwords expire and new ones are managed in Performance Modeler Turbo Integrator.

Turbo Integrator Process Wizard Driven Dimension Builds

When using the Performance Modeler Turbo Integrator wizard to generate dimensions, portions of the auto generated metadata code are logged to the Data tab. When opening the same Turbo Integrator process in Architect, the code is logged to the Metadata tab, which is where an experienced Architect developer would expect it to be located. There is no impact on which tool is used to run the process, but when collaborating this can become confusing.

Synchronization

Working in both systems at the same time can cause metadata and data issues. If one developer is working in Performance Modeler and another developer is working in Architect and they happen to be working on the same object, there may be contention.

The primary reason for contention is that when objects such as dimensions, cubes, or Turbo Integrator processes in Performance Modeler are created, the system requests that the developer name the object prior to development, which then kicks off a save. This means that until the Architect TM1 server is refreshed, it does not fully recognize the object.

Conclusion

The easiest way to avoid most or all of the issues listed in this document is to choose Performance Modeler or Architect and stick with that tool through the development and future maintenance. Most of the contention issues between tools occur when the initial object development is done in Performance Modeler and then opened or modified within Architect.

Conversely, there are very few issues when the objects are initially created in Architect and then modified or managed within Performance Modeler. For this reason, if using both tools in an integrated approach, developers should try to move work from Architect to Performance Modeler and not vice versa.

If you’d like help with your TM1 environment, Ironside’s Financial Performance Management team can help. Our experts will make sure your models function across both the old and new platforms available.