Configuration Management much improved in CLM 6.0.1

The 6.0 release of the Rational solution for Collaborative Lifecycle Management (CLM) included the addition of new configuration management capabilities.  It had some limitations to consider, that is, temporary differences in some CLM capabilities when configuration management is enabled for a project versus not.  Some workarounds for these were detailed in Finding suspect links and requirements to reconcile in CLM 6.0 configuration management enabled projects and Alternatives to filtering on lifecycle traceability links in CLM 6.0 configuration management enabled projects

I am happy to say that the development team worked hard to address these and more in the 6.0.1 release.  A few considerations still remain, but far less than were in the previous release.  I am now comfortable recommending its use by many of my customers.  In this blog entry, I will compare and contrast the configuration management limitations between 6.0 and 6.0.1 and highlight a few other configuration management enhancements.

Considerations from v6.0 and their improvements in v6.0.1:

  1. Will you use the configuration management capabilities in a production environment or a pilot environment?

  2. Will you upgrade all CLM applications to 6.0?

  3. Do your configuration-enabled RM or QM project areas link to other RM or QM project areas?

    While these first three considerations all remain true, they were moved to the ‘Important Factors’ section as they are more recommendations and best practices versus changes in behavior from non-enabled projects.  In v6.0, configuration management was new and we thought it better to draw attention to these recommendations so included them at the top of the v6.0 considerations list.

    Piloting use of configuration management is recommended due to its complexities and to ensure it meets your needs.  It also gives opportunity to try out new usage models/workflows before implementing in production.

    Keeping all the CLM apps at the same v6.0.x rev level is the only practical way to take advantage of all the configuration management capabilities and ensure they work correctly.

    Because of the new linking model in v6.0 when using configuration management, it will always be the case that you’ll want to enable configuration management for all the RM and QM projects between which you’ll be linking artifacts otherwise linking will not always work as desired.

  4. Which type of reporting do you need?

    In v6.0, configuration-aware reporting was available for document generation only.  All other options were technology preview only and not to be used in production.  In v6.0.1, document generation continues to be available using built-in, template-based reporting in the CLM application or by IBM Rational Publishing Engine; it now includes interactive reporting through the Jazz Reporting Service Report Builder and Rational Engineering Lifecycle Manager. 

    Most configuration aware data is now available.  v6.0.1 added version aware data for DOORS Next Generation, versioned data in global and local configurations and Rational Team Concert enumeration values.  This means, for example, that you can construct a report that spans requirements, work items and tests for a particular configuration or a report that includes artifacts from multiple project areas within the same domain. Some gaps remain in available configuration aware data and some is only available via custom SPARQL queries.  Take a look at the limitations section of Getting started with reporting by using LQE data sources

    Access control for reporting on LQE data sources is now enforced at the project area level for RM, CCM and QM applications .  Project-area level access control is not yet implemented for DM and Link Validity (can be set manually in LQE).

  5. Do you need to link or synchronize your CLM project area data with other tools, products, or databases (including IBM, in-house, or other tools)?

    Most OSLC-based integrations outside the CLM applications do not support versioned artifacts.  To do so requires support for OASIS OSLC Configuration Management spec (draft).  We do expect the list of supporting applications to grow over time.  Note that integrations to RTC work items continue to work as expected, because work items aren’t versioned.  Several RQM test execution adapters have been verified to work correctly with enabled projects.  We expect progress to be made in this area throughout 2016 with other IBM and third-party applications.  For information on setting up configuration aware integrations, see Enabling your application to integrate with configuration-management-enabled CLM applications.

  6. Do you rely on suspect links for requirements in RM or for requirement reconciliation in QM?

    In v6.0.1, the new Link Validity Service replaces “suspect links”.  Now you can show and assert the validity of links between requirements, and between requirements and test artifacts.  Automatic “suspect” assertion occurs when attributes change.  Validity status is reused across configurations when the same artifacts with the same content are linked in multiple configurations.

    QM requirements reconciliation against linked requirements collections is now available in configuration management enabled projects. 

  7. Do you need to filter views based on lifecycle traceability links?

    RTC plans can now be linked to versioned requirements collections and test plans in v6.0.1.  What remains in this limitation area is it is still not yet possible in configuration management enabled projects to filter RM views based on lifecycle traceability status nor filter QM views based on RTC work item and plan traceability links.  These should all be addressed in a subsequent release.

  8. (For QM users) Do you use command-line tools, the mobile application for off-line execution, or import from Microsoft Excel or Word?

    In the v6.0.1 release, all command-line tools but the Mobile application for offline execution utility are now configuration aware and can be used with configuration management enabled projects.

The v6.0.1 release includes some other configuration management enhancements of note unrelated to the limitations/considerations:

  • One step creation of global configuration baseline hierarchy
  • Bulk create streams for selected baselines in the context of a global stream
  • Requirements change management supported by optionally requiring change sets to edit contents of a stream and further requiring those change sets to be associated with an approved work item to deliver those changes
  • Improved ability to deliver changes across streams that require merging of modules
  • Several improvements to make it easier to work with DNG change sets in personal streams

See v6.0.1 CLM New & Noteworthy for more details on these and other improvements.

One other enhancement not yet fully realized is the provision for Fine Grain Components.  Currently each project area is a component, which could to a proliferation of project areas for complex product hierarchies.  The intent in future is to support more granularity of component breakdown within a project area.  More work remains to get this fully supported.  In the mean time, some customers may limit their adoption of configuration management until this is supported.

To wrap up, I believe we’ve made great strides in improving the configuration management capability and addressing the limitations from its initial release.  To me, the primary limitation that will constrain a customer’s adoption of the capability is whether the needed integrations to 3rd party or other IBM applications are configuration aware and secondarily if there are any aspects of the configuration aware reporting that won’t meet there reporting needs. 

To give this release a try, you can download CLM v6.0.1 or access one of our sandboxes already populated with sample data (select the latest CLM milestone “with configuration management” when creating your sandbox).